Software Engineering

1
Software Engineering

• scope

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

3
Cost estimation techniques

• Techniques
• Expert Judgment
• Algorithmic
• Model developed

4
Example of expert judgment
5
Typical Cost Estimation Roadmap
1A. 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.
6
Cost estimation

• Techniques for expert judgment
• Estimation by analogy
• Parkinsons law (work expands to fill the time
  available)
• Time avail x people available (12 mos X 5 people
  60 person months)
• Not good can get in trouble big time
• Pricing to win (Market Share)
• ditto

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

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

9
RATING SCHEME FOR INTERFACE LEVEL OF EFFORT
10
Type I Interface into SAP, O Interface out
of SAP, E Enhancement, A Assumption R/B
R Real time, B Batch
Estimating Difficulty
11
(No Transcript)
12
(No Transcript)
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)

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

15
Step 2 Function Point Computation for a Single
Function (IFPUG)
External Inquiries (EIN)
Internal Logical Files (ILF)
Function
Logical group of user data
Logical group of user data
Logical group of user data
External Outputs (EO)
External Inputs (EI)
External Logical Files (ELF)
file
file
Internal logical grouping of user data into
files
file
16
Definitions
17
Function Point Computations (IFPUG) (Unadjusted
-- to be followed by applying adjustment process)
PARAMETER simple complex
Ext. inputs EI? 3 or 4 or
... 6 ___
Ext. outputs EO? 4 or 5 or
... 7 ___
Ext. inquiries EIN? 3 or 4 or
... 6 ___
Int. logical files ILF? ... 7 or 10 or
... 15 ___
Ext. logical files ELF? ... 5 or 7 or
... 10 ___
countTotal
18
Unadjusted Function Point Computation for First
Encounter FunctionsSet up
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
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.
20
General Characteristics for FP Adjustment 1-7
incidental
average essential
0
1
2
3
4
5
none moderate
significant

• 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

21
General Characteristics for FP Adjustment 8-14
incidental
average essential
0
1
2
3
4
5
none moderate
significant

• 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

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

23
Computation of Adjusted Function Points (IFPUG)
(Adjusted) Function points Unadjusted
function points(41) r 0.65 0.01 r (
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)
24
Basic COCOMO Formulae (Boehm)
Effort in Person-months a???KLOC b Duration
c??? Effort d
Organic stand alone Embedded hardware
software systems Semi detached - mix
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
25
Computing COCOMO Case Study ModelsVERY EARLY
ESTIMATES
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
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)

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

28
A Use Case Based Method

• Begin with actors
• Determine if simple average or complex

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

30
Determine the unadjusted use case points (UUCP)

• Weighted Actors Weighted Use Cases UUCP
• 10 50 60

31
(No Transcript)
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 SzUC 60 1.02 61.2
33
Calculate the Experience Factor for the team
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

35
Finally Calculate the Use Case Points (UCP) and
Effort

• 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
• Calculate Man Hours
• count the number of factor E1-E6 that are below
  3 and the number of E7-E8 that are above 3 if
  total islt 2, use ER 20 if total is 3 or 4 use
  ER 28 if total is 5 or more consider
  restructuring the team
• ER UCP total ManHours
• 20 63.648 1,272.96
• 28 63.648 1782.44

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
37
Estimate Cost and Duration Very Early in Project

• 1. Use the function point method to estimate
  lines of code
• 2. Use Boehms formulas to estimate labor
  required
• 3. Use the labor estimate and Boehms formula to
  estimate duration

38
Sample Scope Tracking
 
Access data base discussion