38
06/23/22 1 Software Engineering scope

notes 23

Embed Size (px)

Citation preview

Page 1: notes 23

04/13/23 1

Software Engineering

scope

Page 2: notes 23

04/13/23 2

Project Management – Project Scope Function of

Functionality Resources Time

The Mythical Man-Month, Anniversary Edition : Essays on Software Engineeringby Frederick P. Brooks

Establishing Minimum User acceptance Reasonable probability of success

Page 3: notes 23

04/13/23 3

Cost estimation techniques

Techniques Expert Judgment Algorithmic

Model developed

Page 4: notes 23

04/13/23 4

Example of expert judgment

Page 5: notes 23

04/13/23 5

Typical Cost Estimation Roadmap1A. Use comparisons with past jobs to estimate cost & duration directly or to estimate lines of code (Expert Judgment).

and / or

1B. Use function point method to estimate lines of code

1B.1 Compute un-adjusted function points.

1B.2 Apply adjustment process.

2. Use lines of code estimates to compute labor and duration using COCOMO formulas.

Page 6: notes 23

04/13/23 6

Cost estimation

Techniques for expert judgment Estimation by analogy Parkinson’s law (work expands to fill the time

available) Time avail x people available (12 mo’s X 5

people = 60 person months) Not good can get in trouble big time

Pricing to win (Market Share) ditto

Page 7: notes 23

04/13/23 7

Estimate Task Durations Based on Expert Judgment

1.  Estimate the minimum amount of time it would take to perform the task. We'll call this the optimistic duration (OD).

2.  Estimate the maximum amount of time it would take to perform the task. We'll call this the pessimistic duration (PD).

3.  Estimate the expected duration (ED) that will be needed to perform the task.

4.  Calculate the most likely duration (D) as follows:

D = (1 x OD) + (4 x ED) + (1 x PD) 6

Page 8: notes 23

04/13/23 8

Assumptions Requirements are categorized as either Essential (needed to support 3 shifts, multiple

plants and more vehicle types) or Recommended. The requirements are interrelated. Omitting or changing a requirement may affect the

estimates for other requirements. The estimates are “rough order of magnitude” having a degree of accuracy of +100% to –

50%. Estimates are for planning/budgeting purposes. Engineering changes implemented on day boundary. Business system assigns system indicator and plant executes schedule. No dynamic

routing of vehicles by plant. Same model can be built at multiple plants with different part effectivity or part numbers. No shop calendar by model. Same model built on multiple system within a plant Plant operates 3 shifts, 5 days/week. Customer may require training for new tools and processes. Backups are taken during CICS downtime. (same as today) Applications support only English language. Estimates include requirements definition, design, specifications, coding, testing,

installation, project management, documentation and function points. Modifications to user developed applications (Focus) not included. Financial, Warranty, HR, and client server application modifications not included in estimate

Page 9: notes 23

04/13/23 9

RATING SCHEME FOR INTERFACE LEVEL OF EFFORT

  Low Medium High Extra

Conversions Up to 15 days (A)

16 – 30 days 31 – 45 days 30-90 days

Interfaces Up to 15 days 16 – 30 days 31 – 45 days 30-90 days

Reports Up to 10 days 11 – 20 days 21 – 35 days 30-90 days 

Enhancements Up to 15 days 16 – 30 days 31 – 45 days 30-30 days

Page 10: notes 23

04/13/23 10

Type

R/B

Description Size Comments

ANEMS

I B BOM - Vehicle part structure. Parts List (APO30)

EXTRA

Assumption is EIM for current and future. Include OPsheet data in interface file if needed to support LCCN

I B Unit BOM structures (axles, engines etc)

MEDIUM

Process code

I B Part master add information MEDIUM

From design changes, replaces ECW part add function. (mastered data)

I B Part master reconciliation for class, process code etc.

LOW Developing model segment data, balance out,/carry over/new, part description

Type: I = Interface into SAP, O = Interface out of SAP, E = Enhancement, A = Assumption R/B: R = Real time, B = Batch

Estimating Difficulty

Page 11: notes 23

04/13/23 11

ANEMSFunctions and Assumptions E/R Est. Hrs.

Internal Cleanup (100 pgms)-part number format-dead fields/screens-mis-labeled fields/data integrity-navigation-100 pgms

R 2,000

Activate multi-plant capability E 2,000

New BOM -feed from ANEMS-populate/reconcile new bill of material (ANEMS => DB2)

E 1,000

New BOM is facility specific-BOM unique at each facility-convert existing structures (one time extract)

E 400

New BOM functionality-stand alone bills (maintained in COPICS today)-easier maintenance-independent parts (Brazil, China, Mexico)-what if-where used-estimate 6 CICS pgms

E 1,000

Propagate new BOM to other systems-estimate 50 pgms to change

E 4,000

Implement the equivalent of a single EIPL per day (parts list) E 1,000

Implement more automatic releasing within ANEMSRelieve labor intensive input and release of design notes

R 400

Eliminate/replace ECW to eliminate duplicate data kept in ANEMS and Part Master-estimate 11 screens and 1 database

R 1,600

Total Hours 13,400

Page 12: notes 23

04/13/23 12

Assumptions

Stay with IMS/DC where possible

Anems remains and feeds new BOM

New BOM replaces COPICS

Engineering changes implemented on day boundary

Same model can be built at multiple plants with different parts or part effectivity

Customer Process Changes

Parts Arrangement owns and maintains new BOM

Total Hours 69,880 for 16 applications

Page 13: notes 23

04/13/23 13

Estimating LOE wuth Function Point Analysis FPA is a method to break systems into smaller

components, so they can be better understood and analyzed

Function Points measure software by quantifying its functionality provided to the user based primarily on the logical design

Function Point Analysis tries to understand the dynamic relationship between transactions and data stores. On a conceptual level, function point analysis helps

define two abstract levels of data - data at rest and data in motion.

See www.ifpug.com (International Function Point Users Group web site)

Page 14: notes 23

04/13/23 14

Steps in FP method

Identify functions in the system Compute each functions contribution Apply difficulty factors to each function Compute the general characteristic

contributions (weights) Calculate the adjusted function point

total

Page 15: notes 23

04/13/23 15

Step 2 Function Point Computation for a Single Function (IFPUG)

Function

External Inputs (EI)

External Inquiries (EIN)

External Outputs (EO)

fileExternal Logical Files (ELF)

filefile

Internal Logical Files (ILF)*

* Internal logical grouping of user data into files

Logicalgroup ofuser data

Logicalgroup ofuser data

Logicalgroup ofuser data

Page 16: notes 23

04/13/23 16

Definitions

EI External Inputs (EI) - is an elementary process in which data crosses the boundary from outside to inside.

EIF External Interface Files (EIF) - a user identifiable group of logically related data that is used for reference purposes only

EO External Outputs (EO) - an elementary process in which derived data passes across the boundary from inside to outside

EQ External Inquiry (EQ) - an elementary process with both input and output components that result in data retrieval from one or more internal logical files and external interface files.

ILF Internal Logical Files (ILF) - a user identifiable group of logically related data that resides entirely within the application boundary and is maintained through External Input

Page 17: notes 23

04/13/23 17

Function Point Computations (IFPUG) (Unadjusted -- to be followed by applying adjustment process)

Ext. inputs EI … 3 or… 4 or ... 6 = ___

Ext. outputs EO … 4 or … 5 or ... 7 = ___

Ext. inquiries EIN … 3 or … 4 or ... 6 = ___

Ext. logical files ELF ... 5 or …7 or ... 10 = ___

Int. logical files ILF ... 7 or …10 or ... 15 = ___

PARAMETER simple complex

countTotal

Page 18: notes 23

04/13/23 18

Unadjusted Function Point Computation for First Encounter Functions:“Set up”

Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

Page 19: notes 23

04/13/23 19

Unadjusted Function Point Computation a set of processes

Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

Page 20: notes 23

04/13/23 20

General Characteristics for FP Adjustment 1-7

1. Requires backup/recovery? 0-2

2. Data communications required? 0-1

3. Distributed processing functions? 0

4. Performance critical? 3-4

5. Run on existing heavily utilized environmt.? 0-1

6. Requires on-line data entry? 5

7. Multiple screens for input? .... continued 4-5

0 incidental average essential

1 2 3 4 5none moderate significant

Page 21: notes 23

04/13/23 21

8. Master fields updated on-line? 3-4

9. Inputs, outputs, inquiries of files complex? 1-2

10. Internal processing complex? 1-3

11. Code designed for re-use? 2-4

12. Conversion and installation included? 0-2

13. Multiple installation in different orgs.? 1-3

14. Must facilitate change & ease-of-use

by user? 4-5

0 1 2 3 4 5

General Characteristics for FP Adjustment 8-14 incidental average essential

none moderate significant

Page 22: notes 23

04/13/23 22

Costs - productivity

Object Counts When 4gl and higher level language used Count objects (not to be confused with object classes)

Object points Screens produced - 1-3 Number of reports 2/5/8 Number of 3GL modules to be developed to support 4GL 10

points

Function point + Code estimation Code size = AVC x FPC

4GL 2-40 loc/fp Assembler 200-300 loc/fp Java 53 loc/fp

Page 23: notes 23

04/13/23 23

Computation of Adjusted Function Points (IFPUG)

(Adjusted) Function points =

[ Unadjusted function points(41) ]

[ 0.65 + 0.01 ( total general characteristics ) ]

41 x [0.65 + 0.01 x (24 to 41))] = 36 to 43

Loc = (36 to 43) x 53 =1.9 to 2.3 kloc (java)

Page 24: notes 23

04/13/23 24

Basic COCOMO Formulae (Boehm)

Effort in Person-months = aKLOC b

Duration = cEffort d

Software Project a b c d

Organic 2.4 1.05 2.5 0.38

Semidetached 3.0 1.12 2.5 0.35

Embedded 3.6 1.20 2.5 0.32

Due to Boehm [Bo]

Organic – stand aloneEmbedded – hardware software systemsSemi detached - mix

Page 25: notes 23

04/13/23 25

Computing COCOMO Case Study ModelsVERY EARLY ESTIMATES

Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

Page 26: notes 23

04/13/23 26

Later revisions to estimate

Need to account for Product reliability and complexity (RCPX) Reuse required (RUSE) Platform difficulty (PDIF) Personnel Capability (PERS) Personnel Experience (PREX) Schedule (SCED) Facilities (FCIL)

Effort =a x Kb x M M=(RCPX)(RUSE)(PDIF)(PERS)(PREX)(SCHED)(FCIL)

Page 27: notes 23

04/13/23 27

Use Case size and effort estimation

Count key aspects of the requirements Unadjusted point count

Use several question sets about the team and the environment Create a fudge factor

Multiply the unadjusted count by the fudge factor Yields the adjusted point count Translate into person hours LOE (level of effort)

estimate Karner* proposes 20 person hours /UCP * Gustav Karner 1993 M.Sc. thesis

Page 28: notes 23

04/13/23 28

A Use Case Based Method

Begin with actors Determine if simple average or complex

Page 29: notes 23

04/13/23 29

A Use Case Based Method

Weight Use Cases Based on the number of transactions

(scenarios) in the use case Can use Analysis classes instead, if they have

been identified

Page 30: notes 23

04/13/23 30

Determine the unadjusted use case points (UUCP) Weighted Actors + Weighted Use Cases =

UUCP

10 + 50 = 60

Page 31: notes 23

04/13/23 31

Page 32: notes 23

04/13/23 32

Determine the total Technical Complexity Factor (TCF)

(0.01 * Tfactor) + 0.6 = TCF or(0.01 * 42) = 0.6 = 1.02tcf

Then calculate the size of the software (Use Case) project by multiplying UUCP by TCF

UUCP * TCF = SzUC60 * 1.02 = 61.2

Page 33: notes 23

04/13/23 33

Calculate the Experience Factor for the team

Page 34: notes 23

04/13/23 34

Calculate the Experience Facto

Add all the factors to get the total EF = 12

Calculate the Experience Factor (EF) by multiplying EF by -0.03 and adding 1.4 (-0.03 *EFactor) + 1.4 = EF (-0.03 * 12) = 1.4 = 1.04

Page 35: notes 23

04/13/23 35

Finally Calculate the Use Case Points (UCP) and Effort1. Calculate total points (UCP)

SzUC * EF = UCP 61.2 * 1.04 = 63.648 Or

UUCP * TCF * EF = UCP 60 * 1.02 * 1.04 = 63.648

2. Calculate Man Hours1. count the number of factor E1-E6 that are below 3 and the number of E7-E8 that

are above 3; if total is<= 2, use ER = 20; if total is 3 or 4 use ER = 28; if total is 5 or more consider restructuring the teamER * UCP = total ManHours20 * 63.648 = 1,272.9628* 63.648 = 1782.44

Page 36: notes 23

04/13/23 36

Risk and Reports Adjust for Risk

Use a historically derived risk coefficient Multiply Man hours by 1+ coefficient Assume for demo .05 (1.0 + .05) * 1,782.144 = 1.871.25 (adjusted man hours)

Adjust for reports List all reports if possible. Assign simple, average, complex ratings Based on historical data assign man hours by level Compute total additional hours and add to total

1871.25 + 940 = 2,811.25 total man hours

Page 37: notes 23

04/13/23 37

Estimate Cost and Duration Very Early in Project

1. Use the function point method to estimate lines

of code

2. Use Boehm’s formulas to estimate labor

required

3. Use the labor estimate and Boehm’s formula to

estimate duration

Page 38: notes 23

04/13/23 38

Sample Scope Tracking

Access data base discussion