sfwr eng 3ko4 slide 1 management of software engineering chapter 8: fundamentals of software...
TRANSCRIPT
SFWR ENG 3KO4 Slide 1
Management of Software Engineering
Chapter 8:
Fundamentals of Software Engineering
C. Ghezzi, M. Jazayeri, D. Mandrioli
SFWR ENG 3KO4 Slide 2
Outline Why is management needed?
What are the main tasks of managers?
What is special in the case of software?
How can productivity be measured?
Which tools may be used for planning and monitoring?
How can teams be organized?
How can organizations' capabilities be defined and measured?
SFWR ENG 3KO4 Slide 3
Management
Software engineering projects involve many software engineers
Management is needed to coordinate the activities and resources involved in projects
"The creation and maintenance of an internal environment in an enterprise where individuals, working together in groups, can perform efficiently and effectively toward the attainment of group goals" (Koontz et al, 1980)
SFWR ENG 3KO4 Slide 4
Making decision is difficult! Invest on modern tools?
Invest on formal techniques?
Short time-to-market?
Adding new features?
Develop or purchase?
Re-engineering or development?
State-of-practice in project management is to make judgments, check themagainst expert opinions, try to achieve consensus, and if possible, calibrateit against the data on previous similar projects within the same organization
SFWR ENG 3KO4 Slide 5
Management tasks Planning: What resources are required to achieve the objectives
Organizing: defining the responsibilities and authorities for group activities to achieve the goals
Staffing: hiring personnel for the positions that are identified by the organizational structure
Directing: guiding the groups to understand the goals of the enterprise
Controlling: measuring and correcting activities to make sure the goals are achieved.
… and dealing with deviations from the plan
“Plan the work and work the plan”
SFWR ENG 3KO4 Slide 6
Management challenges
Balance conflicting goals
Deliver a high-quality product with limited resources
Organize an activity that is fundamentally intellectual this complicates the traditional techniques for productivity measurement,
project planning, cost and schedule estimation
SFWR ENG 3KO4 Slide 7
Software productivity
How to define/measure it? TV production VS. Software production
In terms of lines of code produced few tens per day Student project VS. professional program
.. but what do engineers do? up to half of their time spent in meetings, administrative matters,
communication with team members
SFWR ENG 3KO4 Slide 8
Function points
A productivity measure, empirically justified
Motivation: define and measure the amount of valuevalue (or functionality) produced per time unit
Principle: determine complexity of an application as its function point
SFWR ENG 3KO4 Slide 9
Function point definition
A weighted sum of 5 characteristic factors
Item Weight Number of inputs 4 Number of outputs 5 Number of inquiries 4 Number of files 10 Number of interfaces 7
SFWR ENG 3KO4 Slide 10
A byproduct
Function points used to measure the relative power of different languages
compute number of source lines required to code a function point
numbers range from 320 (assembler languages), 128 (C), 91 (Pascal), 71 (Ada83), 53 (C++, Java), 6 (“spreadsheet languages”)
SFWR ENG 3KO4 Slide 11
Size of code
Size of code produced per unit of time as productivity measure
must define exactly what "size of code" means
• Delivered Source Instructions (DSI)
• Non-commented source statements (NCSS)
.. but how good is this metric?
SFWR ENG 3KO4 Slide 12
Factors affecting productivity
Professionals' capabilities
Product complexity
Schedule constraints
Previous experience(Overly aggressive scheduling may have negative effect)
SFWR ENG 3KO4 Slide 13
People and productivity
Because software engineering is an intellectual activity, the most important ingredient for producing high-quality software efficiently is people
Large variability in productivity between engineers
SFWR ENG 3KO4 Slide 14
Cost estimation
We need predictive methods to estimate the complexity of software before it has been developed, then:
Predict size of the software
Use it as input for deriving the required effort
SFWR ENG 3KO4 Slide 15
Generic formula for effort
PM = c KLOCk
Legend• PM: person month• KLOC: K lines of code• c, k depend on the model• k>1 (non-linear growth)
Initial estimate then calibrated using a number of "cost drivers"
SFWR ENG 3KO4 Slide 16
Typical cost driver categories
ProductProduct e.g., reliability requirements or inherent complexity
ComputerComputer e.g., are there execution time or storage constraints?
PersonnelPersonnel e.g., are the personnel experienced in the application area or the programming
language being used?
ProjectProject e.g., are sophisticated software tools being used?
SFWR ENG 3KO4 Slide 17
Cost estimation procedure
Estimate software size, and use it in the model’s formula to get initial effort estimate (Person Month)
Revise effort estimate by using the cost driver or other scaling factors given by the model
Apply the model’s tools to the estimate effort derived in step 2 above to determine the total effort, activity distribution, etc.
SFWR ENG 3KO4 Slide 18
COCOMO models Constructive Cost Model
proposed by B. Boehm
evolved from COCOMO to COCOMO II
SFWR ENG 3KO4 Slide 19
COCOMO
Size estimate based on delivered source instructions, KDSI
Categorizes the software as different modes: organic semidetached embedded
• each has an associated formula for nominal development effort based on estimated code size
SFWR ENG 3KO4 Slide 20
Examples of software modes Organic:
In the organic mode, relatively small software teams develop software in a highly familiar, in-house environment. Most people connected with the project have extensive experience in working with related systems within the organization, and have a thorough understanding of how the system under development will contribute to the organizations objectives. Very few organic-mode projects have developed products with more than 50 thousand delivered source instructions (KDSI)
Scientific models, business models, Familiar OS or compilers
Semidetached: The semidetached mode of software development represents an intermediate stage
between the organic and embedded modes. "Intermediate" may mean either of two things: An intermediate level of project characteristic. A mixture of the organic and embedded mode characteristics. The size range of a semidetached mode product generally extends up to 300 KDSI
Most transaction processing systems, New OS, DBMS, ambitious inventory production control, simple command control
SFWR ENG 3KO4 Slide 21
Examples of software modes Embedded
The major distinguishing factor of an embedded-mode software project is a need to operate within tight constraints. The product must operate within (is embedded in) a strongly coupled complex of hardware, software, regulations, and operational procedures.
Large complex transaction processing systems, ambitious very large OS, avionics, ambitious Command and Control systems.
SFWR ENG 3KO4 Slide 22
Mode
Feature Organic Semidetached Embedded
Organizational understanding of
product objectives
Thorough Considerable General
Experience in working with related
software systems
Extensive Considerable Moderate
Need for software conformance with
pre -es tablished requirements
Basic Considerable Full
Need for software conformance with
external interface specifications
Basic Considerable Full
Concurrent development of
associated new hardware and
operational procedures
Some Moderate Extensive
Need for innovative data processing
architectures, algorithms
Minimal Some Considerable
Premium on early completionProduct size range
Low<50 KDSI
Medium<300 KDSI
HighAll sizes
SFWR ENG 3KO4 Slide 23
COCOMO nominal effort and schedule equations
Development Mode Nominal effort Schedule Organic (PM) NOM=3.2(KDSI) 1.05 TDEV=2.5(PM DEV))0.38 Semidetached (PM) NOM=3.0(KDSI) 1.12 TDEV=2.5(PM DEV))0.35 Embedded (PM) NOM=2.8(KDSI) 1.20 TDEV=2.5(PM DEV))0.32
SFWR ENG 3KO4 Slide 24
Ratings
Cost Drivers Very low Low Nominal High Very High
Extra High
Product attributes Required software
reliability
.75 .88 1.00 1.15 1.40
Data base size .94 1.00 1.08 1.16 Product complexity .70 .85 1.00 1.15 1.30 1.65
Comput er attributes Execution time constraints 1.00 1.11 1.30 1.66 Main storage constraints 1.00 1.06 1.21 1.56 Virtual machine volatility* .87 1.00 1.15 1.30 Computer turnaround time .87 1.00 1.07 1.15 Personnel attributes Anal yst capability 1.46 1.19 1.00 .86 .71 Applications experience 1.29 1.13 1.00 .91 .82 Programmer capability 1.42 1.17 1.00 .86 .70 Virtual machine
experience*
1.21 1.10 1.00 .90
Programming language
experience
1.14 1.07 1.00 .95
Project attributes Use of modern
programming practices
1.24 1.10 1.00 .91 .82
Use of software tools 1.24 1.10 1.00 .91 .83 Required development
schedule
1.23 1.08 1.00 1.04 1.10
COCOMO scaling factors
The nominal effort estimation is multiplied by these ratingsto produce the estimated effort for a specific project