Software Engineering

-Amruta Patil

This courseware material are to be used in conjunction with "Software Engineering: A practitioner's Approach" 7/e
and are provided with permission by R.S. Pressman and associates. The course material is also having contents
copied from internet. Changes are made wrt Pune University Syllabus
 Project Planning,
Management And Estimation
UNIT-IV
 Project Planning
• After the project has been defined and the project team has been appointed, you are ready to enter
the second phase in the project management life cycle: the detailed project planning phase.
• Project planning is at the heart of the project life cycle.
• The planning phase is when the project plans are documented, the project deliverables and
requirements are defined, and the project schedule is created.
• The plans created during this phase will help you manage time, cost, quality, changes, risk, and
related issues.
• In this phase, management approval is taken and proceed to the next phase.
• Most challenging phase for a project manager, as you need to make an educated guess about the
staff, resources, and equipment needed to complete your project.
The basic processes of project planning are:

• Scope planning – specifying the in-scope requirements for the project to facilitate creating the work
breakdown structure
• Preparation of the work breakdown structure – spelling out the breakdown of the project into tasks
and sub-tasks
• Project schedule development – listing the entire schedule of the activities and detailing their sequence
of implementation
• Resource planning – indicating who will do what work, at which time, and if any special skills are
needed to accomplish the project tasks
• Budget planning – specifying the budgeted cost to be incurred at the completion of the project
• Procurement planning – focusing on vendors outside your company and subcontracting
• Risk management – planning for possible risks and considering optional contingency plans and
mitigation strategies
• Quality planning – assessing quality criteria to be used for the project
• Communication planning – designing the communication strategy with all project stakeholders
 Project Initiation
• First phase within the project management life cycle
• Starting up a new project
• A solution is defined, a project is formed, and a project team is appointed to build and deliver the
solution to the customer.
• The business case includes:
• A detailed description of the problem or opportunity with headings such as Introduction, Business
Objectives, Problem/Opportunity Statement, Assumptions, and Constraints
• A list of the alternative solutions available
• An analysis of the business benefits, costs, risks, and issues
• A description of the preferred solution
• Main project requirements
• A summarized plan for implementation that includes a schedule and financial analysis
Project management Philosophy : Method or Madness?
Imagine an office
manager has contracted
a painter to paint
his office.
His goal or objective is
to have the office
painted a pleasing blue
color.
Consider the
conversation that occurs
in Figure after the job
was finished.
 Project scope
• Project scope sets the boundaries for your project and defines the project goals, deadlines, and
deliverables.
• The entire team should be involved in defining the project scope.
• The scope is defined by understanding the project requirements and the client’s expectations.
• The scope statement usually contains,
• project objectives
• project deliverables
• exclusions
• project constraints and
• project assumptions.
 Planning Scope Management
• A scope management plan outlines the processes involved in executing your project and serves as a
guideline to keep the project within specific limits.
• It is responsibility of project manager to guide your team through the project life cycle
• Ex: Driving a car
• A scope management process helps you avoid common problems, including:
• Constantly changing requirements
• Overspending
• Wasted time
• Failure to meet deadlines
• Realizing that the final outcome isn’t what was expected
• Falling behind the project deadlines
 Scope creep
• Scope creep occurs when your project exceeds your initial scope statement.
• scope creep may occur if a stakeholder adds an additional project deliverable after the project has
begun
• Unexpected project changes can lead to increased project risks like missed timelines, increased
budgets, overwork, or a low-quality end product.
• Some reasons for scope creep:
• Unclear project scope
• Unrealistic project objectives
• Too many stakeholders
• Poor scope management
• Poor communication with stakeholders
 Work Breakdown Structure
• WBS is a hierarchical decomposition of the project into phases, deliverables, and work packages.
• All the work that is part of the WBS must be identified, estimated, scheduled, and budgeted.
• It is a tree structure, which shows a subdivision of effort required to achieve an objective (e.g., a
program, project, and contract).
• The WBS creation involves:
• Listing all the project outputs (deliverables and other direct results)
• Identifying all the activities required to deliver the outputs
• Subdividing these activities into sub activities and tasks
• Identifying the deliverable and milestone(s) of each task
• Identifying the time usage of all the resources (personnel and material) required to complete
each task
The purpose of developing a WBS is to:
• Allow easier management of each component
• Allow accurate estimation of time, cost, and resource requirements
• Allow easier assignment of human resources
• Allow easier assignment of responsibility for activities

Example of a WBS:
If I want to clean a room …….
8/80 rule in project management:

• The 8-80 rule suggests that Work packages must be chunks of work that can be completed within 8 hours (1
day) to 80 hours (10 days).
• For very small projects the affinity of the work packages must be towards 8 hours.
• For large projects it must be towards 80 hours.
 Project Scheduling
• Project-task scheduling is a significant project planning activity.
• To schedule the project plan, a software project manager wants to do the following:
1. Identify all the functions required to complete the project.
2. Break down large functions into small activities.
3. Determine the dependency among various activities.
4. Establish the most likely size for the time duration required to complete the activities.
5. Allocate resources to activities.
6. Plan the beginning and ending dates for different activities.
7. Determine the critical path. A critical way is the group of activities that decide the duration of
the project.
 Fig: The project scheduling process

Project activities are the basic planning element.

Each activity has:
1. A duration in calendar days or months.
2. An effort estimate, which reflects the number of person-days or person-months to complete the work.
3. A deadline by which the activity should be completed.
4. A defined endpoint. This represents the tangible result of completing the activity.

This could be a document, the holding of a review meeting, the successful execution of all tests, etc.
Fig: Tasks, durations, and
dependencies

Fig: Activity bar

chart
 Importance of project scheduling
• It brings together all the project-related information in one place that opens doors
for seamless communication between the project manager and stakeholders.

• Project scheduling also enables task prioritization.

• It makes easy for managers to procure the right resources for the right job.

• The internal team conflicts are minimized when the entire team, stakeholders, and managers
are on the same page.

• Resources are aware of the task dependencies and work diligently to ensure that the overall
delivery is not affected.
 Developing the Schedule
• Projects that involve more than one person and/or more than one step pose the following questions:
• What tasks need to be done to complete the project?
• When and in what order will these tasks be done?
• Who will do each task?
• What are the intermediate deadlines (e.g., status reports), and what will be done by these
deadlines?
• To answer these questions, additional issues arise, such as:
• How long will each task take?
• What dependencies exist between tasks?
• Who has the knowledge/skill/time to do each task?
• What external constraints exist (e.g., time to order parts)?

The Gantt, PERT, and CPM charts describe the answers to these questions in time-oriented
diagrams.
In all cases, the “task” is the basic unit of interest.

Tasks are given:

• a name/description ex - research literature survey
• an estimate of the amount of calendar time required
• a list of other tasks (if any) that must be completed before this task can begin (or end)—i.e., dependencies.

Besides tasks, other information is required, such as:

• the overall project start/end dates
• other deadlines or milestones (e.g., reports, etc.)
• factors affecting time available (e.g., holidays, breaks, other classes, presentations, etc.)
 Gantt chart
• The Gantt chart was invented in the early 1900’s by Henry L. Gantt, an American engineer and social
scientist.
• It is commonly used in project management, is one of the most popular and useful ways of showing activities
(tasks or events) displayed against time.
• 6 Steps to Make a Gantt Chart
• Step 1 - Review Scope Baseline
• Step 2 - Create Activities
• Step 3 - Sequence Activities
• Step 4 - Estimate Resources
• Step 5 - Estimate Durations
• Step 6 - Develop Schedule
Example of Gantt Chart
Advantages of the Gantt chart are
• time is explicit (and linear)
• all tasks visible in relationship to others
• deadlines are shown
• project status at intermediate times is shown
• can show progress by “filling in” task boxes
Shortcomings:
• tasks might not be associated with people
• person-hours are not indicated, only calendar time
• dependencies are not explicit
• no summary of the load on a person
• other resources not shown (e.g., financial)
• critical paths are not explicit
• does not record difference between original plan and actual and lower (estimated)
 PERT
• Program Evaluation and Review Technique
• The PERT chart uses a connected series of nodes to make explicit dependencies between tasks.
• The order of tasks is given by the flow of the connections left to right
• But the horizontal axis is not necessarily linear in time.
 CPM
• The CPM (Critical Path Management) chart is similar to the PERT chart but includes an explicit
indication of the “critical path” - that sequence of tasks that defines the minimum amount of time
for the project.
• CPM shares the same strengths and weaknesses as the PERT
• For complex, time-critical projects, the CPM/PERT charts might be useful
• These charts provides a clear indication of the critical sequences of tasks necessary to keep the
project on schedule.
Advantages of CPM
•Provides an outline for long term coordination and planning of a project
•Recognizes critical activities
•Easy to plan, schedule and control project
•It improves productivity
•Manages the resource needed
Disadvantages of CPM
•For beginners, its difficult to understand
•Software too expensive
•Sometimes, to structure CPM is too time-consuming
•It cannot control and form the schedule of a person involved in the project
•Allocation of resources cannot be monitored properly
 Project Management : The Management
Spectrum
• Effective software project management focuses on the four P’s
1. People:
• Most important component of a product and its successful implementation is human resources.
• Roles: project manager, team leaders, stakeholders, analysts, and other IT professionals.
2. Product:
• the deliverable or the result of the project
• The product can consist of both tangible or intangible such as shifting the company to a new place or getting a new
software in a company.
3. Process:
• a clearly defined process is the key to the success of any product.
• Umbrella activities are independent of any one framework activity and occur throughout the process.
4. Project:
• A blueprint of process
• Project managers are responsible to guide the team members to achieve the project’s target and objectives
 People
• The Stakeholders :
• Senior managers who define the business issues
• Project (technical) managers who must plan, motivate, organize, and control software work.
• Practitioners who deliver the technical skills
• Customers who specify the requirements for the software to be engineered
• End users who interact with the software once it is released for production use.
• Team Leaders
• The Software Team
• Agile Teams
 Product
• This is the deliverable or the result of the project.
• The product can consist of both tangible or intangible such as shifting the company to a new
place or getting a new software in a company.
• It is the responsibility of the Project Manager to explain the scope of the project to the team
members.
• In turn, every member of the team can stay clear about the outcome the management expects from
the project
 Process
• Melding the Product and the Process
- communication, planning, modeling, construction, and deployment
• Process Decomposition
• The Process has several steps involved like, documentation phase, implementation phase,
deployment phase, and interaction phase.
• For the successful framing of the process, the Project Manager along with team members should
frame a methodology.
 Project
• Five-part common sense approach to software projects
1. Start on the right foot
2. Maintain momentum
3. Track progress
4. Make smart decisions
5. Conduct a postmortem analysis

The Project Manager is responsible not only for coordinating but also for controlling the entire
project.

Project Manager also keeps an eye on the budget and keeps track of deliverables and budget at every
phase of the project towards the final goal.
 The W5HH Principle
• The W5HH principle in software management exists to help project managers guide objectives,
timelines, responsibilities, management styles, and resources.
• W5HH questions :
1. Why is the system being developed?
2. What will be done?
3. When will it be done?
4. Who is responsible for a function?
5. Where are they located organizationally?
6. How will the job be done technically and managerially?
7. How much of each resource is needed?
Boehm’s W5HH Principle is applicable regardless of the size or complexity of a software project.
 Metrics in the Process and Project Domains
• Process Metrics provide a set of process indicators that lead to long-term software process
improvement.
• Project metrics enable a software project manager to
(1) assess the status of an ongoing project,
(2) track potential risks,
(3) uncover problem areas before they go “critical,”
(4) adjust workflow or tasks, and
(5) evaluate the project team’s ability to control quality of software work products
Process Metrics and Software Process Improvement:
Etiquettes:
1. Use common sense and organizational sensitivity when
interpreting metrics data.
2. Provide regular feedback to the individuals and teams
who collect measures and metrics.
3. Don’t use metrics to appraise individuals.
4. Work with practitioners and teams to set clear goals
and metrics that will be used to achieve them.
5. Never use metrics to threaten individuals or teams.
6. Metrics data that indicate a problem area should not be
considered “negative”.
7. Don’t obsess on a single metric to the exclusion of
other important metrics
Project Metrics:
• Software process metrics that are used for strategic purposes while software project measures are tactical.
• Project Metrics includes project workflow and technical activities.
• Data from the past projects are used to collect various metrics, like time and cost.
• As the project proceeds, the project manager will check its progress from time-to-time and will compare
the effort, cost, and time with the original effort, cost and time.
• These metrics are used to decrease the development costs, time efforts and risks.
 Software Measurement
• A measurement is a manifestation of the size, quantity, amount, or dimension of a
particular attribute of a product or process.
• The software measurement process is defined and governed by ISO Standard.
• Software Measurement Principles:
1. Formulation

2. Collection

3. Analysis

4. Interpretation

5. Feedback
Types of software measurements:

1. Direct Measurement:

In direct measurement, the product, process, or thing is measured directly using a standard scale.

2. Indirect Measurement:

In indirect measurement, the quantity or quality to be measured is measured using related

parameters i.e. by use of reference.

 Size-Oriented Metrics
• It concentrates on the size of the program created.
• We can calculate Size-Oriented Metrics by averaging out quality and productivity.
• Based on
1. LOC
2. Function Point
3. Token Count
Set of Size Measures
• Quality = Errors per KLOC
• Cost = $ per KLOC
• Documentation = Pages of documentation per KLOC
• Errors = Errors per person-month
• Productivity = LOC per person-month
• Here KLOC means Thousands of Lines of Code.
 Line Of Code(LOC) Metrics
• Size of a software program or codebase.
• It is commonly used to calculate and compare programmers’ productivity.
• Advantage of LOC
1. In cost estimate, this is the most commonly used metric.
2. When compared to this statistic, its alternatives have numerous flaws.
3. Estimating the effort is extremely simple.
• Disadvantages of LOC
1. Increases productivity while allowing for more code lines to be written.
2. Less efficient code.
3. It makes no allowance for intricacy.
 Function-Oriented Metrics
• Function-Oriented Metrics is a method that is developed by Albrecht in 1979 for IBM.
• Also known as Function Point Model.
• It focuses on the functionality of the software application being delivered.
• A function point is a unit of measurement that measures the business functionality provided by the
business product.
• It is to measure and provide the software application functional size to the client, customer, and the
stakeholder on their request.
• It also measures its maintenance, consistently throughout the project irrespective of the tools and
the technologies.
Types of FP Attributes
Measurements Examples Low Average High
Parameters Weight Weight Weight

1.Number of External Input screen and tables 3 4 6

Inputs(EI)

2. Number of External Output screens and reports 4 5 7

Output (EO)

3. Number of external Prompts and interrupts. 3 4 6

inquiries (EQ)

4. Number of internal files Databases and directories 7 10 15

(ILF)

5. Number of external Shared databases and shared 5 7 10

interfaces (EIF) routines.
 Complexity Adjustment Factor
1. Does the system require reliable backup and recovery?
2. Are specialized data communications required to transfer information to or from the application?
3. Are there distributed processing functions?
4. Is performance critical?
5. Will the system run in an existing, heavily utilized operational environment?
6. Does the system require online data entry?
7. Does the online data entry require the input transaction to be built over multiple screens or operations?
8. Are the ILFs updated online?
9. Are the inputs, outputs, files, or inquiries complex?
10. Is the internal processing complex?
11. Is the code designed to be reusable?
12. Are conversion and installation included in the design?
13. Is the system designed for multiple installations in different organizations?
14. Is the application designed to facilitate change and ease of use by the user?
Each of these questions is answered using a scale that ranges from 0 (not important or applicable) to 5 (absolutely essential).
The Function Point (FP) :
FP = Count-total * [0.65 + 0.01 * ∑(fi)]
= Count-total * CAF (complexity adjustment factor)
Where, ∑(fi) is the sum of all 14 questionnaires and 0 <= ∑(fi) <=70

Based on the FP measure of software many other metrics can be computed:

1.Errors/FP
2.$/FP.
3.Defects/FP
4.Pages of documentation/FP
5.Errors/PM.
6.Productivity = FP/PM (effort is measured in person-months).
7.$/Page of Documentation.
8. LOCs of an application can be estimated from FPs. That is, they are interconvertible. This process is known as
backfiring. For example, 1 FP is equal to about 100 lines of COBOL code.
 Differentiate between FP and LOC

FP LOC

1. FP is specification based. 1. LOC is an analogy based.

2. FP is language independent. 2. LOC is language dependent.

3. FP is user-oriented. 3. LOC is design-oriented.

4. It is extendible to LOC. 4. It is convertible to FP (backfiring)

 Software Project Estimation
• Software cost and effort estimation will never be an exact science
• Variables affect the ultimate cost —human, technical, environmental, political
• Empirical estimation model
d = f (vi)
where d is one of a number of estimated values (e.g., effort, cost, project duration)
and vi are selected independent parameters (e.g., estimated LOC or FP).
• Six critical elements of a project estimations:
1. Cost
2. Time
3. Size or Scope
4. Risk
5. Resources
6. Quality
 Decomposition Techniques
• Estimation uses decomposition of problem and decomposition of process
1. Software Sizing
2. Problem-Based Estimation
3. LOC-Based Estimation
4. Process-Based Estimation
5. Estimation with Use Cases
Fig: LOC based project estimation

Fig: FP Based project estimation

 Cost Estimation Tools and Techniques
1. Expert Judgement
2. Analogous Estimation - similar
3. Parametric Estimation – historical data
4. Bottom-up estimation
5. Three-Point Estimation
• M – Most Likely – realistic solution
• O – Optimistic: Estimation based on best case scenario
• P – Pessimistic: Estimation based on worst case scenario
• Formula: Triangular Distribution – (O+M+P)/3
• Beta distribution – (O+4M+P)/6
6. Project Management Software
7. Cost of quality
 Cost estimation Techniques

Delphi Technique Expert

Judgement COCOMO Model
 Cocomo (Constructive Cost Model)
• Proposed by Barry Boehm in 1981
• Regression model based on LOC
• Process of reliably predicting the various parameters associated with making a project
such as size, effort, cost, time, and quality.
• Cocomo are primarily Effort & Schedule
• projects are categorized into three types:
1.Organic – simple inventory management system
2.Semidetached – OS, DMBS, complex inventory management system
3.Embedded – coupled with complex hardware system – ATM, Air Traffic control
According to Boehm, software cost estimation should be done through three stages:

1.Basic Model :
• Estimates the software roughly and quickly.
• Use to effort, development time, average staff size and productivity
Effort= a *(KLOC)^b PM
Tdev= c *(efforts)^d Months
AverageStaffSize = Effort/Tdev
Prod = KLOC/Effort
Where
Effort = total effort required to develop the software product, expressed in person months (PMs).
a, b, c, d are constants for each group of software products,
Tdev is the estimated time to develop the software, expressed in months

Organic: Effort = 2.4(KLOC) 1.05 PM

Semi-detached: Effort = 3.0(KLOC) 1.12 PM
Embedded: Effort = 3.6(KLOC) 1.20 PM

Organic: Tdev = 2.5(Effort) 0.38 Months

Semi-detached: Tdev = 2.5(Effort) 0.35 Months
Embedded: Tdev = 2.5(Effort) 0.32 Months
2. Intermediate Model:
• Cost Drivers such as reliability, experience, and
Capability
• Intermediate Model utilizes 15 such drivers for Personnel attributes -
cost estimation
•Analyst capability
Product attributes -
• Required software reliability extent •Software engineering capability

• Size of the application database •Applications experience

• The complexity of the product •Virtual machine experience
Hardware attributes - •Programming language experience
• Run-time performance constraints Project attributes -
• Memory constraints
•Use of software tools
• The volatility of the virtual machine environment
•Application of software engineering methods
• Required turnabout time
•Required development schedule
3. Detailed COCOMO Model:

In detailed Cocomo, the whole software is differentiated into multiple modules, and then we apply
COCOMO in various modules to estimate effort and then sum the effort.

The Six phases of detailed COCOMO are:

1.Planning and requirements
2.System structure
3.Complete structure
4.Module code and test
5.Integration and test
6.Cost Constructive model
Advantages of the COCOMO model:
1.Provides a systematic way to estimate the cost and effort of a software project.
2.Can be used to estimate the cost and effort of a software project at different stages of the development
process.
3.Helps in identifying the factors that have the greatest impact on the cost and effort of a software
project.
4.Can be used to evaluate the feasibility of a software project by estimating the cost and effort required
to complete it.

Disadvantages of the COCOMO model:

1.Assumes that the size of the software is the main factor that determines the cost and effort of a
software project, which may not always be the case.
2.Does not take into account the specific characteristics of the development team, which can have a
significant impact on the cost and effort of a software project.
3.Does not provide a precise estimate of the cost and effort of a software project, as it is based on
assumptions and averages.
 COCOMO – II Model
• Developed at University of Southern California
• Allows to estimate the cost, effort and schedule
• Three sub modules:
1. End User Programming –
Spreadsheet, report generator
1. Intermediate Sector –
Lotus, GUI, Embedded systems
2. Infrastructure Sector
OS, DBMS, Network System
Stages of COCOMO – II

1. Stage – I:
• estimation of prototyping
• uses Application Composition Estimation Model.
2. Stage –II:
• estimation in the early design stage of the project
• Uses Early Design Estimation Model
3. Stage – III:
• estimation in the post architecture stage of a project.
• Uses Post Architecture Estimation Model.
 COCOMO I COCOMO II

COCOMO I is useful in the waterfall models of the software COCOMO II is useful in non-sequential, rapid development
development cycle. and reuse models of software.

It provides estimates that represent one standard deviation

It provides estimates of effort and schedule.
around the most likely estimate.

This model is based upon the linear reuse formula. This model is based upon the non linear reuse formula

This model is also based upon the assumption of reasonably This model is also based upon reuse model which looks at
stable requirements. effort needed to understand and estimate.

Effort equation’s exponent is determined by 3 development

Effort equation’s exponent is determined by 5 scale factors.
modes.

Development begins with the requirements assigned to the

It follows a spiral type of development.
software.

Number of submodels in COCOMO I is 3 and 15 cost drivers In COCOMO II, Number of submodel are 4 and 17 cost
are assigned drivers are assigned

Size of software stated in terms of Object points, function

Size of software stated in terms of Lines of code
points and lines of code
 Typical Problems with IT Cost Estimates
1. Poorly derived project requirements
2. Resource constraints
3. Quality of available data
4. Shortage of Competent Resources
5. Dividing One Task Among Multiple Persons
6. Failed to consider the project risks
7. Consistency
8. Not Analyzing the Lessons Learned from Past
 Case Study
• Project Management tool like OpenProj or MS Project