1. Contents Introduction Requirements Engineering Project Management
Software Design
Detailed Design and Coding
Quality Assurance
Maintenance
PVK-HT05

2. Project Management Project Management Activities Project Scheduling
Cost Estimation
PVK-HT05

3. Project Management Activities
Project acquisition
Project planning
Resource assessment
Risk and option analysis
Cost estimation
Project scheduling
Work breakdown structure
Effort distribution
Resource assignment
Project tracking and control
Reporting
PVK-HT05

4. Project Resources People Hardware and software tools Required skills
Availability
Duration of tasks
Start date
Hardware and software tools
Description
Duration of use
Delivery date
PVK-HT05

5. Risk Analysis What is a risk?
Risk impact: the loss associated with the event
Risk probability: the likelihood that the event will occur
Risk control: the degree to which we can change the outcome
Risk exposure = (risk probability) x (risk impact)
PVK-HT05

6. Top Ten Project Risks Staff deficiencies
Unrealistic schedules and budgets
Developing the wrong functions
Developing the wrong interface
Over-engineering
Changing requirements
Externally developed items
Externally performed tasks
Performance problems
Assumptions on technology
PVK-HT05

7. Define Work Breakdown Structure
Activity
Major work unit
Start date
End date
Consumes resources
Results in work products (and milestones)
Project function
Continue throughout the project
Not bound to specific phases
Step 1
Step 2
Activity 1
Activity 2
Activity 3
Phase 1
Step 1
Step 2
Activity 1
Activity 2
Task 1
Task 2
Task 3
Project
Phase 2
Step 1
Step 2
Phase N
PVK-HT05

8. Schedule Activities
Almost all activities depend on the completion of some other activities
Many activities can be performed in parallel
Organisation necessary to balance work-load, costs, and duration
PERT chart (activity network/task graph)
Critical path
Project Time-line (Gantt chart)
Resource table
PVK-HT05

9. PERT Charts Program Evaluation and Review Technique Graph Compute
Nodes = activities/tasks and estimated duration
Edges = dependencies
Compute
Slack time = available time - estimated duration
Critical path
A path is critical when it contains an activity that, if delayed, will cause a delay of the whole project.
PVK-HT05

10. Example PERT Chart
PVK-HT05

11. Gantt charts
A Gantt chart is used to graphically present the start and end dates of each software engineering task
One axis shows time.
The other axis shows the activities that will be performed.
The black bars are the top-level tasks.
The white bars are subtasks
The diamonds are milestones:
Important deadline dates, at which specific events may occur
PVK-HT05

12. A Gantt Chart (Project Time Line)
PVK-HT05

13. Another Gantt Chart
PVK-HT05

14. Cost Estimation Approach Problems: Use empirical and historical data
Decompose problem
Check for experiences/ data on sub problems
Make qualified estimations
(Make at least two independent estimates)
Problems:
What are good measures?
Do the estimates affect the result?
Does the type of software affect the result?
Does the project environment affect the result?
...
Use empirical and historical data
Algorithmic cost modelling
COCOMO (based on LOC)
FP (based on function points)
PVK-HT05

15. COCOMO Constructive Cost Modelling [Boehm 81]
Based on publicly available historical data of 63 TRW projects
Basic assumptions:
Requirements change only slightly during the project
There is good project management
The historical data is representative
Assigning more resources to the project does NOT result in linear decreasing development time
PVK-HT05

16. Basic Model Effort = a (KDSI)b Schedule = c (Effort)d a b c d 2.4
KDSI = Kilo Delivered Source Instructions ( LOC - comments)
The a, b, c, and d factors vary depending on the type of project
Effort is measured in PM (Person Months = 152h of work)
Schedule is the Development Time measured in Months a b c d
2.4
3.0
3.6
1.05
1.12
1.20
2.5
0.38
0.35
0.32
Organic
In-house IS, Development in a familiar environment
OM: Organic Mode projects
Small teams which are familiar with the type of application with low communication overhead Development in a familiar environment
EM: Embedded Mode projects
Large and inexperienced teams Many constraints are those that develop complex hardware software systems. Experience level is low since most projects are one of a kind.
SDM: Semi Detached Mode projects
Between OM- and EM projects are those projects made up of experienced and inexperienced staff.
Organic Familiar environment, small team of experienced programmers are main characteristics of organic mode projects. For example, a personnel system project for an organization which is located on a single building with Local Area Network facilities only.
Semi Detached Semi-detached mode projects are intermediate projects between organic mode and embedded mode. Such projects partially shows both characteristics. For example, a software project for a large bank, including daily customer operations and the ATM machine activities on a Wide Area Network can be considered as of type semi-detached..
Embedded In the embedded mode, projects has tight constrains, more than one processor and various types of peripherals exist. Uncertainties in the problem definition is another characteristics of such projects. Hardware driving projects are good examples of embedded types. For example, a software project related to control the production of various automobile parts is of embedded type.
Effort PM: Person Months
2.4 (KDSI)1.05 for OM projects
3 (KDSI)1.12 for SDM projects
3.6 (KDSI)1.20 for EM projects
TDEV: Time for DEVelopment
2.5 (PM)0.38 for OM projects
2.5 (PM)0.35 for SDM projects
2.5 (PM)0.32 for EM projects
N: Number of personnel PM / TDEV
Semi-detached
Between OM- and EM projects
Embedded
Large and inexperienced teams, many constraints
PVK-HT05
Boehm, Software Engineering Economics, Prentice-Hall, 1981.

17. COCOMO Summary Works quite well in practice Needs KLOC as input
Problems:
Estimating KLOC in early project stages
Comparison of projects using different LOC counts
Outdated metrics base (70s)
Solutions:
Cross-check using an other estimation technique
Standardised LOC counts
Continuous model calibration
COCOMO II is a recent new version
PVK-HT05

18. COCOMO II
Goal: To develop a software cost and schedule estimation model tuned to the life cycle practices of the 1990’s and 2000’s
3 Models
Application Composition: prototyping to resolve high-risk user interface issues, 2 environment drivers, 0 process drivers, Sizing in Object Points
Early Design Model: to explore alternative architectures and concepts,7 environment drivers, 5 process drivers, Sizing in Function Points or SLOC
Post Architecture Model: development has begun, 17 environment drivers, 5 process drivers, Sizing in Function Points or SLOC
Why ?
allow for spiral model instead of waterfall model only
Use FP and LOC for Sizing
Assumptions
COCOMO II includes same activities as COCOMO 81
development activities are included: documentation, planning& control, software configuration management (CM)
excluded: database management, general CM, Management
COCOMO II has add-on effort for back-end Transition Phase (conversion, installation, training)
Labour categories: direct project-charged + overhead (e.g. project mgr), but not secretaries, higher management, computer centre operators, ...
PVK-HT05

19. Effort and schedule in COCOMO 2
Application Composition Model
Effort = NOP/productivity
NOP = OP * [(100 -%reuse)/100]
Productivity = NOP/man-months, 5 productivity levels depending on the 2 environment drivers (table 3.12 course book)
Early Design and Post-architecture Model æ ö
Environment [ ] ( )
Factors
Scale
Process
Effort = ç ÷
Size ç ÷
Multipliers è ø
Environment: product, platform, people, project factors
Process: constraint, risk/architecture, team, maturity factors ( ) [ ]
Effort ( )
Factors
Scale
Process
Schedule =
Multiplier
PVK-HT05

20. COCOMO II Model Stages Overestimated Underestimated4x
Overestimated 2x
Early Design
(13 parameters)
1.5x
1.25x
Relative
Size Range x
0.8x
Post-Architecture
0.67x
(23 parameters)
0.5x
Underestimated
Applications
Composition
(3 parameters)
0.25x
Product
Detail
Concept of
Rqts.
Design
Design
Accepted
Operation
Spec.
Spec.
Spec.
Software
Feasibility
Plans
Product
Detail
Devel.
and
Design
Design
and Test
Rqts.
PVK-HT05
Phases and Milestones

21. COCOMO II summary COCOMO II
allow for spiral model instead of waterfall model only
Size of project can be listed as object points, function points or source lines of code (SLOC)
The environmental multipliers are calculated from seventeen cost drivers better suited for today's methods
Calibration is difficult, but can improve accuracy by a factor of five
Problems with CoCoMo II
Not developed for Web apps
Estimates driven by SLOC count
PVK-HT05

22. Function Points
Function Point Analysis (FPA) measures the size of a software product in terms of the functionality it delivers to the users. A.J. Albrecht 1979
What the software must do from the user’s perspective
Irrespective of software construction
Based on five function types:
Inputs
Outputs
Inquiries
Logic Files
Interfaces
PVK-HT05

23. Project plan contents Documentation plan Project scope
Data management plan
Resource management plan
Test plan
Training plan
Security plan
Risk management plan
Maintenance plan
Project scope
Project schedule
Project team organization
Technical description of system
Project standards and procedures
Quality assurance plan
Configuration management plan
PVK-HT05

24. Difficulties and Risks in Project Management
Accurately estimating costs is a constant challenge
It is very difficult to measure progress and meet deadlines
It is difficult to deal with lack of human resources or technology needed to successfully run a project
Communicating effectively in a large project is hard
It is hard to obtain agreement and commitment from others
PVK-HT05