1. Part 4 Managing Software Project
Software Engineering: A Practitioner’s Approach, 6th edition
by Roger S. Pressman

2. Chapter 21 Project Management Concepts
Software Engineering: A Practitioner’s Approach, 6th edition
by Roger S. Pressman

3. The 4 P’s People — the most important element of a successful project
Product — the software to be built
Process — the set of framework activities and software engineering tasks to get the job done
Project — all work required to make the product a reality

4. Stakeholders
Senior managers who define the business issues that often have significant influence on the project.
Project (technical) managers who must plan, motivate, organize, and control the practitioners who do software work.
Practitioners who deliver the technical skills that are necessary to engineer a product or application.
Customers who specify the requirements for the software to be engineered and other stakeholders who have a peripheral interest in the outcome.
End-users who interact with the software once it is released for production use.

5. Software Teams How to lead? How to organize? How to collaborate?
How to motivate?
How to create good ideas?

6. Team Leader : The MOI Model
Motivation. The ability to encourage (by “push or pull”) technical people to produce to their best ability.
Organization. The ability to mold existing processes (or invent new ones) that will enable the initial concept to be translated into a final product.
Ideas or innovation. The ability to encourage people to create and feel creative even when they must work within bounds established for a particular software product or application.

7. Software Teams The difficulty of the problem to be solved
The size of the resultant program(s) in lines of code or function points
The time that the team will stay together (team lifetime)
The degree to which the problem can be modularized
The required quality and reliability of the system to be built
The rigidity of the delivery date
The degree of sociability (communication) required for the project
The following factors must be considered when selecting a software project team structure ...

8. Organizational Paradigms
Closed paradigm—structures a team along a traditional hierarchy of authority
Random paradigm—structures a team loosely and depends on individual initiative of the team members
Open paradigm—attempts to structure a team in a manner that achieves some of the controls associated with the closed paradigm but also much of the innovation that occurs when using the random paradigm
Synchronous paradigm—relies on the natural compartmentalization of a problem and organizes team members to work on pieces of the problem with little active communication among themselves

9. Agile Teams Team members must have trust in one another.
Agility encourages customer satisfaction, early incremental delivery of s/w, highly motivated team(AGILE TEAM), minimal work product & overall development simplicity.
Team is “self-organizing”
An adaptive team structure
Uses elements of closed, random, open, and synchronous paradigms
Planning kept minimum & allowed to select it’s own approach.
To accomplish it, might conduct daily meetings to coordinate the work done……… this process repeats till completed s/w increment.

10. The Product Scope Scope:
Context. How does the software to be built fit into a larger system, product, or business context and what constraints are imposed as a result of the context?
Information objectives. What customer-visible data objects are produced as output from the software? What data objects are required for input?
Function and performance. What function does the software perform to transform input data into output? Are any special performance characteristics to be addressed?
Software project scope must be unambiguous and understandable at the management and technical levels.

11. Problem Decomposition
Sometimes called partitioning or problem elaboration
Once scope is defined …
It is decomposed into functions & content that must be delivered
It is decomposed into user-visible data objects
or into a set of problem classes
Decomposition process continues until all functions or problem classes have been defined

12. The Process Once a process framework has been established
Consider project characteristics, Determine the degree
Define a task set for each software engineering activity
Task set =Software engineering tasks, Work products, Quality assurance points, Milestones
Decide which process model is most appropriate for the customer, end user, characteristics of product, environment in which project team works.

13. The Project Projects get into trouble when …
1.Software people don’t understand their customer’s needs.
2. The product scope is poorly defined.
3. Changes are managed poorly.
4.The chosen technology changes.
5.Business needs change [or are ill-defined].
6. Deadlines are unrealistic.
7. Users are resistant.
8. Sponsorship is lost
9.The project team lacks people with appropriate skills.
10.Managers [and practitioners] avoid best practices and lessons learned.

14. Common-Sense Approach to Projects (Project Manager)
Start on the right foot. This is accomplished by working hard to understand the problem that is to be solved and then setting realistic objectives and expectations.
Maintain momentum. The project manager must provide incentives to keep turnover of personnel to an absolute minimum, the team should emphasize quality in every task it performs, and senior management should do everything possible to stay out of the team’s way.
Track progress. For a software project, progress is tracked as work products are produced and approved (using formal technical reviews) as part of a quality assurance activity.
Make smart decisions. In essence, the decisions of the project manager and the software team should be to “keep it simple.”
Conduct a postmortem analysis. Establish a consistent mechanism for extracting lessons learned for each project.

15. To Get to the Essence of a Project (W5HH Principle)
Why is the system being developed?
What will be done? (task set is defined)
When will it be done?(project schedule & milestones)
Who is responsible?(Role of each member)
Where are they organizationally located?(other roles)
How will the job be done technically and managerially?
How much of each resource (e.g., people, software, tools, database) will be needed?(developing estimates)
Barry Boehm

16. Critical Practices Formal risk management
Empirical cost and schedule estimation
Metrics-based project management
Earned value tracking
Defect tracking against quality targets
People aware project management

17. Chapter 22 Process and Project Metrics
Software Engineering: A Practitioner’s Approach, 6th edition
by Roger S. Pressman

18. A Good Manager Measures
process
process metrics
project metrics
measurement
product metrics
product
What do we
use as a
basis?
• size?
• function?

19. Why Do We Measure? assess the status of an ongoing project
track potential risks
uncover problem areas before they go “critical,”
adjust work flow or tasks,
evaluate the project team’s ability to control quality of software work products.

20. Process Measurement
We measure the efficiency of a software process indirectly.
That is, we derive a set of metrics based on the outcomes that can be derived from the process.
Outcomes include
measures of errors uncovered before release of the software
defects delivered to and reported by end-users
work products delivered (productivity)
human effort expended
calendar time expended
schedule conformance
We also derive process metrics by measuring the characteristics of specific software engineering tasks.

21. Process Metrics Guidelines
Use common sense and organizational sensitivity when interpreting metrics data.
Provide regular feedback to the individuals and teams who collect measures and metrics.
Don’t use metrics to assess individuals.
Work with practitioners and teams to set clear goals and metrics that will be used to achieve them.
Never use metrics to threaten individuals or teams.
Metrics data that indicate a problem area should not be considered “negative.” These data are merely an indicator for process improvement.

22. Software Process Improvement
Process model
SPI
Process improvement
recommendations
Improvement goals
Process metrics

23. Project Metrics
used to minimize the development schedule by making the adjustments necessary to avoid delays and moderate potential problems and risks
used to assess product quality on an ongoing basis and, when necessary, modify the technical approach to improve quality.
every project should measure:
inputs—measures of the resources (e.g., people, tools) required to do the work.
outputs—measures of the deliverables or work products created during the software engineering process.
results—measures that indicate the effectiveness of the deliverables.

24. Typical Project Metrics
Effort/time per software engineering task
Errors uncovered per review hour
Scheduled vs. actual milestone dates
Changes (number) and their characteristics
Distribution of effort on software engineering tasks

25. Metrics Guidelines
Use common sense and organizational sensitivity when interpreting metrics data.
Provide regular feedback to the individuals and teams who have worked to collect measures and metrics.
Don’t use metrics to appraise individuals
Work with practitioners and teams to set clear goals and metrics that will be used to achieve them.
Never use metrics to threaten individuals or teams.
Metrics data that indicate a problem area should not be considered “negative.” These data are merely an indicator for process improvement.

26. Typical Size-Oriented Metrics
errors per KLOC (thousand lines of code)
defects per KLOC
$ per LOC
pages of documentation per KLOC
errors per person-month
Errors per review hour
LOC per person-month
$ per page of documentation

27. Typical Function-Oriented Metrics
Use a measure of functionality delivered by application as a normalization value. (Function Point [FP])
errors per FP (thousand lines of code)
defects per FP
$ per FP
pages of documentation per FP
FP per person-month

28. Comparing LOC and FP
Representative values developed by QSM

29. Why Opt for FP? Programming language independent
Used readily countable characteristics that are determined early in the software process
Does not “punish” inventive (short) implementations that use fewer LOC that other more clumsy versions
Makes it easier to measure the impact of reusable components

30. Object-Oriented Metrics
Number of scenario scripts (use-cases)
No. of key classes (highly independent components)
Number of support classes (required to implement the system but are not immediately related to the problem domain)
Average number of support classes per key class (analysis class)
Number of subsystems (an aggregation of classes that support a function that is visible to the end-user of a system)

31. WebApp Project Metrics
Number of static Web pages (the end-user has no control over the content displayed on the page)
Number of dynamic Web pages (end-user actions result in customized content displayed on the page)
Number of internal page links (internal page links are pointers that provide a hyperlink to some other Web page within the WebApp)
Number of persistent data objects
Number of external systems interfaced
Number of static content objects
Number of dynamic content objects
Number of executable functions

32. Measuring Quality
Correctness — the degree to which a program operates according to specification
Maintainability—the degree to which a program is amenable to change
Integrity—the degree to which a program is impervious to outside attack
Usability—the degree to which a program is easy to use

33. Defect Removal Efficiency
A Quality metric that provides benefit at both project & process level.
DRE is a measure of filtering ability of quality assurance & control actions applied throughout all process activities.
DRE = E /(E + D)
E is the number of errors found before delivery of the software to the end-user
D is the number of defects found after delivery.

34. Chapter 23 Estimation for Software Projects
Software Engineering: A Practitioner’s Approach, 6th edition
by Roger S. Pressman

35. Software Project Planning
The overall goal of project planning is to establish a pragmatic strategy for controlling, tracking, and monitoring a complex technical project.
Why?
So the end result gets done on time, with quality!

36. Project Planning Task Set-I
Establish project scope
Determine feasibility
Analyze risks
Define required resources
Determine required human resources
Define reusable software resources
Identify environmental resources

37. Project Planning Task Set-II
Estimate cost and effort
Decompose the problem
Develop two or more estimates using size, function points, process tasks or use-cases
Reconcile the estimates
Develop a project schedule
Establish a meaningful task set
Define a task network
Use scheduling tools to develop a timeline chart
Define schedule tracking mechanisms

38. Estimation
Estimation of resources, cost, and schedule for a software engineering effort requires
experience
access to good historical information (metrics
the courage to commit to quantitative predictions when qualitative information is all that exists
Estimation carries inherent risk and this risk leads to uncertainty

39. Write it Down! Project Scope Software Estimates Project Risks Plan
Schedule
Control strategy
Software
Project
Plan

40. To Understand Scope ... Understand the customers needs
understand the business context
understand the project boundaries
understand the customer’s motivation
understand the likely paths for change
understand that ...
Even when you understand,
nothing is guaranteed!

41. What is Scope? Software scope describes
the functions and features that are to be delivered to end-users
the data that are input and output
the “content” that is presented to users as a consequence of using the software
the performance, constraints, interfaces, and reliability that bound the system.
Scope is defined using one of two techniques:
A narrative description of software scope is developed after communication with all stakeholders.
A set of use-cases is developed by end-users.

42. Resources

43. Project Estimation Project scope must be understood
Elaboration (decomposition) is necessary
Historical metrics are very helpful
At least two different techniques should be used
Uncertainty is inherent in the process

44. Estimation Techniques
Past (similar) project experience
Conventional estimation techniques
task breakdown and effort estimates
size (e.g., FP) estimates
Empirical models
Automated tools

45. Estimation Accuracy Predicated on …
the degree to which the planner has properly estimated the size of the product to be built
the ability to translate the size estimate into human effort, calendar time, and dollars (a function of the availability of reliable software metrics from past projects)
the degree to which the project plan reflects the abilities of the software team
the stability of product requirements and the environment that supports the software engineering effort.

46. Functional Decomposition
Statement of
Scope
functional
decomposition
Perform a Grammatical “parse”

47. Conventional Methods: LOC/FP Approach
compute LOC/FP using estimates of information domain values
use historical data to build estimates for the project

48. Process-Based Estimation
Obtained from “process framework”
framework activities
application
functions
Effort required to accomplish
each framework activity for each application function

49. Process-Based Estimation Example
Based on an average burdened labor rate of $8,000 per month, the total estimated project cost is $368,000 and the estimated effort is 46 person-months.

50. Tool-Based Estimation
project characteristics
calibration factors
LOC/FP data

51. Estimation with Use-Cases
Using 620 LOC/pm as the average productivity for systems of this type and a burdened labor rate of $8000 per month, the cost per line of code is approximately $13. Based on the use-case estimate and the historical productivity data, the total estimated project cost is $552,000 and the estimated effort is 68 person-months.

52. Estimation with Use-Cases
LOC estimate= N x LOCavg + [(Sa/Sh -1) + (Pa/Ph -1)] x LOC adjust
Where
N= actual no. of use cases
LOCavg= historical average LOC per use case
LOCadjust= adjustment based on n % of LOCavg, n represents difference between this project & average project.
Sa= actual scenarios per use case
Sh = average scenarios per use case
Pa = actual pages per use case
Ph = average pages per use case

53. Empirical Estimation Models
General form:
exponent
effort = tuning coefficient * size
usually derived
empirically
as person-months
derived
of effort required
usually LOC but
may also be
function point
either a constant or
a number derived based
on complexity of project

54. COCOMO-II
COCOMO II is actually a hierarchy of estimation models that address the following areas:
Application composition model. Used during the early stages of software engineering, when prototyping of user interfaces, consideration of software and system interaction, assessment of performance, and evaluation of technology maturity are paramount.
Early design stage model. Used once requirements have been stabilized and basic software architecture has been established.
Post-architecture-stage model. Used during the construction of the software.

55. The Software Equation A dynamic multivariable model
E = [LOC x B0.333/P]3 x (1/t4)
where
E = effort in person-months or person-years
t = project duration in months or years
B = “special skills factor”
P = “productivity parameter”

56. Estimation for OO Projects-I
Develop estimates using effort decomposition, FP analysis, and any other method that is applicable for conventional applications.
Using object-oriented analysis modeling (Chapter 8), develop use-cases and determine a count.
From the analysis model, determine the number of key classes (called analysis classes in Chapter 8).
Categorize the type of interface for the application and develop a multiplier for support classes:
Interface type Multiplier
No GUI
Text-based user interface
GUI
Complex GUI

57. Estimation for OO Projects-II
Multiply the number of key classes (step 3) by the multiplier to obtain an estimate for the number of support classes.
Multiply the total number of classes (key + support) by the average number of work-units per class. Lorenz and Kidd suggest 15 to 20 person-days per class.
Cross check the class-based estimate by multiplying the average number of work-units per use-case

58. Estimation for Agile Projects
Each user scenario (a mini-use-case) is considered separately for estimation purposes.
The scenario is decomposed into the set of software engineering tasks that will be required to develop it.
Each task is estimated separately. Note: estimation can be based on historical data, an empirical model, or “experience.”
Alternatively, the ‘volume’ of the scenario can be estimated in LOC, FP or some other volume-oriented measure (e.g., use-case count).
Estimates for each task are summed to create an estimate for the scenario.
Alternatively, the volume estimate for the scenario is translated into effort using historical data.
The effort estimates for all scenarios that are to be implemented for a given software increment are summed to develop the effort estimate for the increment.

59. The Make-Buy Decision

60. Computing Expected Cost
(path probability) x (estimated path cost) i i
For example, the expected cost to build is:
expected cost = 0.30 ($380K) ($450K)
build
= $429 K
similarly,
expected cost = $382K
reuse
expected cost = $267K
buy
expected cost = $410K
contr