BA-Mod 5-Modeling IT Systems v0.4

8/7/2019 BA-Mod 5-Modeling IT Systems v0.4

1/40

Module 5

Software EstimationModeling IT Systems


2/40

Topics in Estimation

Software Estimation

Size Estimation

Effort Estimation

Schedule Estimation

Agile Size Estimation


3/40


4/40


5/40

Sources of Uncertainty

Will the customer want Feature X?

Will the customer want the cheap orexpensive version of Feature X?

If you implement the cheap versionof Feature X, will the customer later

want the expensive version after all? How will Feature X be designed?

What will be the quality level ofFeature X?

How long will it take to debug andcorrect the mistakes made in theimplementation of Feature X?

How long will it take to integrateFeature X with all the other features?


6/40

Estimate Convergence Graph


7/40

Estimation process overview

Estimate the size of the product (number oflines of code or function points) Use an algorithmic approach e.g. function

points, that estimates size from program features

Use size-estimation software

If you have worked on a previous project that issimilar you can estimate from that

Estimate the effort (person-months)

Estimate the schedule (calendar months)

A more general step (a meta-step) Provide estimates in ranges and periodically

refine the ranges to provide increasing precisionas the project progresses


8/40

Size Estimation

Algorithmic approach such as function points, that estimates program

size from program features

Use size-estimation software that estimatesprogram size from your description of

program features screens, dialogs, files, database tables, etc.

If you have already worked on a similarproject and know its size Estimate each major piece of the new system as a

% of the size of a similar piece of the old system. Add up all the estimated sizes of the pieces


9/40

Function-Point Estimation

This kind of size estimation is often used ina projects early stages

Based on counting

Inputs screens, forms, dialog boxes,

controls etc.Outputs screens, reports, graphs etc.

Inquiries input/output combinations

Logical internal files files controlled by

the programExternal interface files files controlled by

other programs


10/40

Function-Point Multipliers

LowComplexit

y

x3

x 4

x 3

x 7

x 5

Medium

Complexity

x 4

x 5

x 4

x 10

x 7

High

Complexity

x 6

x 7

x 6

x 15

x 10

ProgramCharacteristics

Number of inputsNumber of outputs

Inquiries

Logical internalfiles

Logical interfacefiles

Function Points


11/40

Estimation Tips

Avoid off-the-cuff estimates

Allow time for the estimate, and plan it

Use data from previous projects

Use developer-based estimates

Estimate by walkthrough Estimate by categories e.g. easy, medium,

hard

Estimate at a low level of detail

Dont omit common tasks

Use software estimation tools Use several different estimation techniques,

and compare the results

Change estimation practices as the project

progresses


12/40

Estimate Presentation Styles

Plus-or-minus qualifiers

Ranges

Risk quantification

Cases Best case, planned case, current case, worstcase

Coarse dates and time periods

Confidence factors E.g. delivery date April 1, probability of

delivering on time 5%

May 1, probability of delivering on time 50%

June 1, probability of delivering on time 95%


13/40

Effort Estimation

Once you have the sizeestimate you derive theeffortestimate Use estimation software to

create an effort estimate

directly from the sizeestimate Use your organizations

historical data to determinehow much effort previousprojects of the estimated

size took Use an algorithmic

approach to convert a lines-of-code estimate into aneffort estimate


14/40

Schedule Estimation

The third step (the first is estimating sizeand the second is estimating effort) inestimating a software project is tocompute the schedule estimate

Software Schedule Equation Schedule in months = 3.0 * Person-months1/3

Once youve estimated that it will take 65man-months to build the project, theequation says that the optimal schedule is12 months (3.0 * 65 1/3 )

If you end up with an optimal schedule of12 months to do a project that requires65-man-months you will need 5-6 teammembers (65 man months divided by 12months)


15/40

Agile Size Estimates


16/40

Story Points The huge-ness of a

task

Relative deduction,factors are Complexity

Scope

Relative values arewhat is important: A login screen is a 2

A search feature is an 8

Points are unit-less

Scale of 1-10 ideally

Average task 5


17/40

Ideal Days Time taken if

its all you worked on you had no

interruptions and everything you

need is available

The ideal time of afootball game is 90minutes Two 45-minute halves

The elapsed time ismuch longer (3hours?)


18/40


19/40

Comparing Approaches

Story points help drive cross-functional behavior Story point estimates do not decay

Story points are a pure measure of size

Estimating in story points is typically faster

My ideal days cannot be added to your ideal days

Ideal days are easier to explain outside the team Ideal days are easier to estimate at first

Ideal days can force companies to confront timewasting activities


20/40

How huge are these? Read a high-level, 10 page overview of agile

software development in a business magazine

Read a densely written 5 page research paperabout agile software development in aacademic journal

Write the product backlog for a simpleeCommerce site that sells only beer

Recruit, interview, and hire a new member foryour team

Create a 60 minute presentation about agile

estimating and planning for your co-workers Read a 150-page book on agile software

development

Write a 8-page summary of this session for yourboss


21/40

Agile Estimation Methods


22/40

Triangulation Comparing a user

story to others This story is like that

story, so its estimate iswhat that storysestimate was.

Dont use a singlegold standard

Triangulate instead Confirm estimates by

comparing the story tomultiple other stories.

Group like-sized storieson table or whiteboard


23/40

Planning Poker An iterative approach to

estimating Steps

Each estimator is given adeck of cards, each card hasa valid estimate written on it

Product owner reads a story

and its discussed briefly Each estimator selects a card

thats his or her estimate

Cards are turned over so allcan see them

Discuss differences

(especially outliners) Re-estimate until estimatesconverge


24/40

IT Systems Modeling


25/40

Statement on IT System Modeling

A picture is worth thousand words


26/40

IT System Modeling

Modeling Functions

Use Case Modeling

Structured SystemAnalysis and Design


27/40

IT System Modeling

Use Case Modeling

Actor User Role

Another system

Time

Use Case

System Boundary

Association Include

Extend Pls. draw fig 10.2

on P.162

Set up Project

Assign Resources

Track Progress

Print ProgressReport

Provide InvoiceData

Print PersonalSchedule

SummarizeProjects

IdentifyProjects

ProjectManager

Programm

Manager

Team Member

Financesystem

Project ControlSystem


28/40

IT System Modeling

Modeling Data

Data attributes that theorganization (system)needs to maintain

Grouping of data

attributes (Entities) Relationships between

the entities

Entities can be

Physical Conceptual

Entity Type Vs. EntityOccurrence


29/40

IT System Modeling

Entity Relations

One to One May not require additional

entity

One to Many Office to Employees

Mandatory

Optional

Many to Many Books and Publishers


30/40

IT System Modeling

Object Modeling

Objects Items for which system

maintains data

Class Object Type

Attributes

Methods

Optional

Inheritance and

generalization


31/40

Case Study on DataModeling


32/40

Information Resource

Management


33/40

IT System Modeling

Data Modeling

Also known as DataManagement

Data vs. Context

Data context is also

known as Meta Data Data management is

associated withmanaging raw data as

well as meta data


34/40

Effect of Poor Data Management

People maintain and collect data that is notneeded any more;

The organisation has historic information that isno longer used;

The organisation holds a lot of data that isinaccessible to potential users;

Information is disseminated to more peoplethan it should be;

The organisation uses inefficient and out-of-date methods to collect, analyze, store andretrieve the data;

The organisation fails to collect data that itneeds.


35/40

Challenges of Data QualityManagement

Lack of proper validation

Multiple non-integrateddata storage

Incomplete data

Proliferation of local PCs

Not considering non-electronic forms of data

Non-structured data suchas images, audio and video

No central agency for datamanagement


36/40

Valuing and Classifying Data

Valuing data by availability

Valuing lost data

Data life cycle

Classifying data Operational ortransactional data

Tactical data (MIS, BI)

Strategic data


37/40

Data Warehousing

Primarily used for what-if analysis

Contains historical data

Data de-normalized for

quicker data analysis


38/40


39/40

End of Module

Any Questions?

Any Suggestions forImprovement?


40/40

Documents

BA-Mod 5-Modeling IT Systems v0.4