Software Project Management

Chapter One – Introduction:

What is Software?
It is a product of engineering just like an airplane, automobile, television, or another object that requires a high degree of
skill to turn a raw material into a usable product. But software is developed or engineered, not manufactured!
What is a Project?
It is a temporary endeavor (having specific start and completion dates) undertaken to create a unique product or service
 Temporary means that every project has a definite beginning and definite end
 End is reached when project’s objectives have been achieved OR it is clear that objective will not be met. The project
is terminated in such a situation
 Unique means that the product or service is different in some distinguishing way from all similar products or services
What is Management?
It is a set of activities and tasks undertaken by one or more persons for the purpose of planning & controlling the activities
of others in order to achieve an objective or complete an activity that could not be achieved by others acting
independently.
Components of Management:
 Planning
Pre-determining course of action to achieve the objectives
 Organizing
Establishing relationship among work units and granting responsibility and authority to obtain the objectives
 Staffing
Selecting and training people
 Directing (Leading)
Creating an atmosphere that will assist & motivate people to achieve the desired end results
 Controlling
Establishing, measuring, and evaluating performance of activities towards planned objectives
What is Project Management?
It is the discipline of planning, organizing, and managing resources to bring about the successful completion of specific
project goals and objectives
What is Software Project Management?
A sub-discipline of project management in which software projects are planned, monitored and controlled
 Software development is a complex undertaking particularly when it involves many people working over a relatively
long time. Hence software development projects need to be managed.
Managerial Skills:
 Technical skills
 Knowledge of & proficiency in activities involving methods, processes & procedures.
 Working with tools & specific techniques.
  Human skills
 Ability to work with people.  Cooperative effort, team work.
 Creating a conducive environment for people/ workers.
 Conceptual skills
 Ability to see the “big picture”.
 Ability to recognize significant elements in a situation & to understand the relationship among them.
 Design skills
 Ability to solve problems that will eventually benefit the enterprise.
 The skill to design effective & practical solutions to problems rather than becoming “problem watcher” only.
 Important for upper level managers.
Project Management Skills:
 Leadership  Negotiating  Process and technical
expertise
 Communications  Influencing the Organization
 Problem Solving  Mentoring
The five basic process groups are:
 Initiating  Monitoring and Controlling
 Planning  Closing
 Executing
The nine suggested Knowledge Areas are:
 Project Integration Management  Project Human Resource Management
 Project Scope Management  Project Communications Management
 Project Time Management  Project Risk Management
 Project Cost Management  Project Procurement Management
 Project Quality Management
____________________________________________

Chapter Two - Project Management:

Effective software project management focuses on the four’s:
 People  Product  Process  Project
 “People factor” is very important in success of a software project.
 “Companies that sensibly manage their investment in people will prosper in the long run” Tim & Tom.
 Cultivation of motivated and highly skilled software people has always been important for software organizations.
People involved in Software Process are:
 Stakeholders  Team Leaders  Software Team
Stakeholders can be categorized into one of the following:
 Senior Managers
 they define business issues that often have significant influence on business
  Project (technical) managers
 they must plan, motivate, organize and control the practitioners who do software work
 Practitioners
 They deliver the technical skills necessary to engineer a product or application
 Customers
 They specify the requirements for the software to be engineered
 End Users
 They interact with the software after it is released for production use
 Competent Practitioners often make poor team leaders as they lack the right mix of people skills.
 MOI model of Leadership
 Motivation
 encourage technical people (by “push” or “pull” ) to produce
 Organization
 Apply , improve processes efficiently
 Ideas or Innovation
 Make people feel creative
 Be Creative
Characteristics of an effective project managers:
 Problem Solving
 Diagnostic  Skill to solve  Ability to design solution
 Managerial Identity
 Take charge and control the project  Allow good technical people to follow their instincts

 Achievement
 Reward Initiative & accomplishment  Encourage Controlled risk taking
 Influence and team building
 Influence the team  Read people’s mind and react to their needs
 Be controlled in stress situations
Democratic decentralized
 No permanent leader  Communication is horizontal
 Suitable for small projects requiring less than 5 to 6 engineers, research-oriented projects
 Advantages
 At different times, different members within the team provide technical leadership.
 High morale and job satisfaction due to autonomy, hence less employee turnover.
 Disadvantages
 Team members may waste time arguing about trivial points due to absence of any authority in the team.
Controlled centralized
  Defined team leader  Communication is vertical
 Problem solving , communication and management by team leader
 Advantages
 The senior engineer/leader partitions tasks, verifies and integrates the products developed by members.
 Disadvantages
 Too much responsibility & authority is assigned to leader, possibility of single point of failure
Controlled decentralized
 Defined team Leader  Suitable for large organizations
 Horizontal communication  Draws upon the ideas from both earlier
structures
 Problem solving is a group activity
Seven factors that should be considered when planning team structure:
 Difficulty of task  Rigidity of delivery date (schedule)
 Size of resultant code (no. of lines)  Degree of communication
 Time that team will stay together  Required quality and reliability of the system
being built
 Degree of modularization
The People - Agile Teams
 Agile software development encourages customer satisfaction and early incremental delivery of software with overall simplicity.

 Agile teams are small, highly motivated teams.

 They adopt many characteristics of successful software project teams and avoid toxins that create problems.
 They are self-organizing and do not necessarily maintain a single team structure (use elements of Constantine’s paradigms)

 Agile process models give significant autonomy to agile teams.

 Planning is kept to minimum.
 The agile team is allowed to select its own approach (e.g., process, methods, and tools).
 The agile team may have daily team meetings to coordinate and synchronize the day’s work.
 With each passing day, this self-organization and collaboration move the team towards a completed software increment

The People - Communication & coordination Issues

 Formal approaches
 Writings (SE documentation, Customer requests, etc.)
 Structured meetings (e.g., Status review meetings)
 Design and code inspections
 Other non-interactive and impersonal comm. channels
 Informal approaches (more personal)
 Interpersonal networking
 Sharing of ideas on ad hoc basis
 Seeking help from inside or outside the project team when problem arises
 Electronic Communication (e.g., e-mail, electronic bulletin boards, video conferencing)
People Management Capability Maturity Model (PM-CMM):
 Developed by SEI
 “to enhance the readiness of s/w organizations to undertake increasingly complex applications by helping to attract, grow,
motivate, deploy, and retain the talent needed to improve their software development capability”

 In simple words - to enhance the people’s capabilities through personnel development

 Key Practice Areas of PM-CMM
 Recruiting  Compensation
 Selection  Career development
 Performance Management  Organization and work design
 Training  Team/culture development
 Organizations that achieve high levels of maturity in PM-CMM have a higher likelihood of implementing effective
software engineering practices
The Product:
 The product and the problem it is intended to solve must be examined at very beginning of the software project.
 Before project planning :
 Product objectives & scope must be established,
 Alternative solutions should be considered (to select best approach within constraints),
 Technical and management constraints should be identified.
 Without the above, cost estimates, risk assessment, realistic work breakdown and scheduling is impossible.
Scope is defined by
 Context (1st step)
 Functional location of the software product into a large system, product or business context
 Constraints involved
 Information Objectives (2nd step)
 What data objects are required as i/p or o/p
 Function and Performance (3rd step)
 What function does the software system perform on i/p to produce o/p
 What level of performance is required
The scope of product must be established and bounded:
 Bounded scope means
 establishing quantitative data (e.g., no. of simultaneous users, max. allowable response time) are explicitly stated

 constraints and limitations (e.g., product cost restricts memory size) are noted
 and mitigating factors (e.g., algorithms are well understood) described
The Product - Problem Decomposition
 Also called partitioning OR problem elaboration. The problem that the product is addressing must be decomposed
 This activity is at core of requirements analysis. Divide and conquer policy for complex problems
 Decompose problem in tasks
  Decomposition in 2 major areas
 Functionality that must be delivered  Process that will be used to deliver product
 A complex problem is partitioned into smaller problems that are more manageable.
 Decomposition make planning easier.
 Software functions, defined in scope, are evaluated and refined to provide more detail before estimation (part of planning) begins.

The Process:
 A software process provides the framework from which a comprehensive plan for software development can be established.

 Common process framework activities which are applicable to all software projects are:
 Communication  Modeling  Deployment
 Planning  Construction
 Process models
 Linear sequential, Prototyping, RAD, Spiral, Formal
 The problem is to select the process model that is appropriate for the software to be engineered by the project team.

 Project manager must decide about which model to use depending on

 customers who have requested the product & people who will work on it
 characteristics of the product
 project environment in which people will work
 Project planning begins after process model is selected and later process decomposition takes place.
 Process decomposition
 The way a process is decomposed depends on project complexity
 Decomposition involves outlining of work tasks involved in each process framework activity
 Example of decomposition for ‘communication’ activity for a simple project:
 Develop a list of clarification issues
 Meet with customer to discuss clarification issues
 Jointly develop statement of scope
 Review the statement of scope with all concerned
 Modify the statement of scope id required
The Project
 The software projects must be planned and controlled effectively to avoid complexities.
 The project managers and engineers must understand the critical success factors and develop a common sense
approach for planning, monitoring and controlling the project.
John Reel describes ten signs that indicate that project is in jeopardy:
 Software people don’t understand customer needs
 Product scope is poorly defined
 Changes are managed poorly  Deadlines are unrealistic
 The chosen technology changes  Users are resistant
 Business needs change  Sponsorship is lost
  Team lacks skills  Managers avoid best practices
John Reel suggests the following:
 Start on the right foot
 Involves detailed understanding of project  Selecting the right team
 setting realistic objectives & expectations  Facilitating the team
 Maintain Momentum
 Provide incentives
 Reduce bureaucracy and give autonomy to team members but with supervision
 Track Progress
 Assess progress as work products are produced
 Make smart decisions
 When possible, use existing software components / COTS software
 Choose standard approaches and keep it simple
 Avoid risks and allocate more time than needed for complex/risky tasks
 Conduct a postmortem analysis
 Compare planned and actual schedule
 Collect and analyze project metrics (standards)
 Get feedback from team and customers
 Establish record of lessons learnt for each project
W5HH principle
 Why is the system being develop?
 Answer to this questions help assess validity of business reason for the software work.
 It answers if the business purpose justifies the expenditure of people, time and money
 What will be done?
 Answer to this question establishes the task set required for project
 When will it be done?
 Answer to this question helps the team establish a project schedule by identifying when tasks have to be
conducted and when milestones are to be reached
 Who is responsible for a function?
 Answer to this question establishes roles and responsibility of each team member
 Where they are organizationally located?
 Answer to this question indicates that all roles and responsibilities are not limited to the software team
itself, the customers, users and stakeholders also have responsibilities.
 How will be job done technically and managerially?
 Once product scope is establishes, a technical and management strategy must be defined for it.
 How much of each resource is needed?
 Answer to this question is derived by developing estimates based on answers to earlier questions.
  Excellent planning outline for project managers and software team
 Applicable to all sizes of software projects
 It is an approach to address
 project objectives  Responsibilities  Required resources
 Milestones & schedule  Management & technical
approaches
__________________________________________________

Chapter Three - Metrics for Process and Projects:

Metrics for Process and Projects
 Software process and project metrics are quantitative measures that enable software engineers to gain insight into
efficacy of the software process and projects that are conducted using the process as a framework.
 Basic quality & productivity data (called measures) are collected.
 These data are then analyzed, compared against past averages (for similar projects), and assessed to determine
whether productivity & quality improvements have occurred.
 Metrics also indicate problem areas in processes and projects which can then be rectified / corrected.
 Project metrics contribute to development of process metrics
What is Measurement?
 It is the act of obtaining a measure.  It is a mechanism of objective evaluation.
 It enables managers and practitioners to improve software process.
 It assists in planning, tracking and controlling a software project and assessing product quality.
What is a Measure?
 To ascertain / determine or appraise by comparing to a standard
 A standard or unit of measurement; the extent, dimensions, capacity, etc., of anything, especially as determined by a standard.
What is a Metric?
 A metric is quantitative measure of the degree to which a system, component or process possesses a given attribute.
 A metric is the degree to which a particular subject possesses the quality that is being measured. It is based upon two or measures

Difference between terms:

 Measure: It is a value which does not provide enough information to make meaningful decisions
 Metric: A comparison of two or more measures, e.g., temperature values over time, errors per KLOC
 Indicator: Compares a metric against a base-line or expected result and helps in making decisions
How to improve a process
 Measure specific attributes of process
 Develop meaningful metrics based on these attributes
 These metrics provide indicators that lead to strategy for improvement
Example
 Metrics can be derived from the following process outcomes/attributes
o Errors uncovered before software release, o Defects delivered to & reported by end-user,
 o Work products delivered, o Calendar time expended,
o Human efforts expended, o Schedule conformance and other measures.
How to Improve Software Quality & Organizational Performance
 It is important to note that process is only one of the many controllable factors in improving software quality and
organizational performance. Other factors connected with the ‘process’ that have significant influence on the same are:
 The skill and motivation of people
 The complexity of the product  The technology
Project Metrics
 Used by project managers and software team to adapt project workflow and technical activities.
 Objective is
 To minimize the development schedule by making adjustments that can avoid delays and mitigate potential problems.

 To assess product quality on an ongoing basis and when necessary, modify technical approach to improve quality.

 Most first application of project metrics on software projects occurs during estimation (of time, effort).
 More project metrics are used as technical work of project commences.
Software Measurement
 Software measurement can be categorized in two ways
 (1) direct measures of software process and product
 (2) indirect measures of software product
 Direct Measures
 of software process are
 Cost and effort
 of software product are
 Line of Code (LOC)  Defects over specified period of time
 Execution Speed
 Indirect Measures
 Of product are
 Functionality  Efficiency  Other Abilities

 Quality  Reliability
 Complexity  Maintainability
Size Oriented Metrics
 These are derived by normalizing quality and/or productivity measures by considering the size of software that
has been produced.
 Size-oriented metrics are widely used but not universally accepted as best way to measure a software process
 Proponents claim:
o LOC is easy to count
o Many existing estimation models use LOC or KLOC as key input
o Large literature & data based on LOC exists
  But opponents argue that
o LOC measures are programming language dependent
o When considering productivity, LOC criteria penalizes well designed short programs
o Cannot accommodate non procedural languages
o Planner must estimate LOC long before analysis and design
Function-oriented Metrics
 These use a measure of the functionality delivered by application as a normalization value.
 Most widely used function-oriented metric is function point (FP)
 FP’s computation is based on characteristics of software information domain and complexity.
 Function points are a measure of the size of computer applications and the projects that build them.
 The size is measured from a functional or user, point of view.
 It is independent of the computer language, development methodology, technology or capability of the project
team used to develop the application.
 First proposed by Albrecht; can be used to measure functionality delivered by a system.
 Using historical data, FP can be used to:
o Estimate cost and effort required to design, code and test the software,
o Predict no. of errors that will be encountered during testing,
o Forecast the no. of components and/or project source lines in the implemented system.
 Following empirical relationship is used to compute Function Point (FP)
FP= count total x [0.65+ 0.01 x Σ(Fi)]
 Fi (i=1 to 14 ) are VAF (Value adjustment factors) or simply ‘adjustment values’ based on answers to some
questions (See list of 14 Qs on Page 473 from book 6th edition )
 Answer to these questions are on a scale of 0 (not applicable) to 5 (absolutely essential)
 Count total is calculated using the following information domain values:
o External inputs (EIs) o Internal logic files (ILFs)
o External outputs (EOs) o External interface files (EIFs)
o External inquiries (EQs)
 Each information domain value is multiplied by a weighting factor (simple, average or complex) and all values are
added to get count total.
 Like LOC, FP is also controversial
 Proponents claim
o It is programming Language independent, hence ideal for conventional and non-procedural languages
o Based on data that can be known early phases of projects
 Opponents claim
o Computation is based on subjective rather than objective data
o counts of information domain may be difficult to collect
o FP is just a number and has no physical meaning
Object-oriented Metrics
 FP and LOC can be used to estimate OO software projects but these metrics do not address all aspects of such projects.

 Hence OO metrics are used for object-oriented projects

 Set of metrics for OO projects:
 Number of scenario scripts
 These are detailed sequence of steps about user and application interaction
 These are directly correlated to application size and no. of test cases
 Number of key classes
 Key classes are independent components
 They Indicate amount of development effort and potential reuse
 Number of support classes
 Required to implement the system but not directly related to problem domain, e.g., UI classes, DB access, etc.
 These indicate amount of development effort and potential reuse
 Average number of support classes per key class
 If these are known then estimation (based on total no. of classes) would be much simplified.
 Number of sub systems (aggregation of classes)
 If identified, it is easier to lay out the schedule in which work on subsystems is partitioned among project staff.

Use-case oriented Metrics

 Use-cases describe user visible functions and features.
 They are defined early in software process and can be used as normalization measure before significant activities are initiated.

 They are independent of programming language

 No. of use cases directly proportional to
 size of application in LOC &
 no. of test cases that will be designed
 There is no standard size of a use case as they are created at different levels of abstraction
 For this reason, it is a suspect as a normalization measure
Software Quality Metrics
 Measuring quality through
 Correctness
 It is degree to which software performs its required function
 Common measure= defects per KLOC
 For quality assessment defects are counted typically for 1 year
 Maintainability
 It is the ease with which a program can be
 corrected if an error is found  Enhanced if customer desires
 Adapted if environment changes or
  Measured indirectly, e.g., Mean-time-to change (MTTC)
 Maintainable programs -> lower MTTC
 Integrity
 System’s ability to withstand (accidental & intentional) attacks
 Two more attributes that help determine integrity
 threat = probability of attack within a given time (that causes failure)
 security = probability that an attack will be repelled
 Integrity =  [1 – (threat * (1 – security))]
 Usability
 It quantifies ease of use and learning (time)
Defect Removal Efficiency
 DRE is a measure of the filtering ability of the quality assurance and control activities as they are applied throughout
the process framework
 When considered for project as a whole, it is defined as
 DRE = E / (E + D)
 E = no. of errors found before delivery  D = no. of defects found after delivery
 Ideal value of DRE is 1
 Realistically D will be greater than 0
 As E increases, DRE begins to approach 1
 If used as a metric that provides an indicator of the filtering ability of the quality assurance and control activities.
 DRE encourages a software project team to institute techniques for finding as many errors as possible before delivery.
 DRE can also be applied on each process framework activity and hence find the team’s ability to assess errors before
they are passed to next activity or software engineering task.
 DRE = Ei / (Ei + Ei+1)
 Ei = errors in activity i
 Ei+1 = errors in activity i+1 that were not discovered in activity i
Arguments for Software Metrics
 Majority of software developers do not collect measures.
 Without measurement it is impossible to tell whether a process is improving or not.
 Measurement is used to establish a process baseline from which improvements can be assessed.
Establishing a Baseline
 The metrics baseline consists of data from past software development projects.
 Baselines can be as simple as data in table or as complex as a complete database having numerous measures and
metrics derived from them.
 To be used effectively in process improvement and/or cost estimation, baseline data must have the following attributes.

 Baseline data attributes:

 Data must be accurate (no guess work)
  Data should be collected from as many projects as possible
 Measures must be consistent across all such projects
 Baseline data/applications should be similar to the work that is to be estimated
Metrics for Small Organizations:
 Most software organizations have fewer than 20 software engineers.
 It is unreasonable to expect that such small organizations will develop comprehensive software metrics program.
 However, it is reasonable to suggest that software organizations of all sizes should measure and then use the
resultant metrics to improve their local software process, quality and timelines of product delivery.
 Best advice is to “Keep it simple”, i.e., choose simple metrics that provide value to the organization and don’t
require a lot of effort to collect.
 Improvement target: “to reduce the time to evaluate and implement change requests”
 A small organization may select the following measures to achieve the target:
 Time elapsed from the time a request is made until evaluation is complete
 Effort to perform evaluation
 Time elapsed from completion of evaluation to assignment of change order to personnel
 Effort required to make the change
 Time required to make the change
 Errors uncovered during work to make the change
 Defects uncovered after change is released to the customer
Establishing Software Metrics Program:
 SEI has suggested the following guidelines for establishing a “goal-driven” Software Metrics Program:
1. Identify business goal
2. Identify what you want to know
3. Identify sub goals
4. Identify sub goal entities and attributes
5. Formalize measurement goals
6. Identify quantifiable questions and indicators related to sub goals
7. Identify data elements needed to be collected to construct the indicators
8. Define measures to be used and create operational definitions for them
9. Identify actions needed to implement the measures
10. Prepare a plan to implement the measures
Summary:
 Measurements result in change in working-culture.
 Measurement helps practitioners and managers to improve the process.
 Data collection, metrics computation and their analysis are the core steps to begin a ‘metrics program’.
____________________________________________________
Chapter Four - Estimation:
 Software Project Management begins with 'Project Planning’ activities which include:
 Estimation  Quality Management Planning
 Scheduling  Change Management Planning
 Risk Analysis
 Estimation is to determine how much…
 Money/cost,  efforts,  resources and  time
Will be required to build a specific software based system or product.
 Estimation is done by software project managers using information solicited from
 Stakeholders,  Software metrics data from past project.
 Software engineers and
Estimation Steps – Summary
 Description of product scope.
 Decomposition of problem into set of smaller problems.
 Each sub problem is estimated using historical data, software metrics and experience (from past projects) as guides.

 Problem complexity and risks are considered before final estimate is made.
Estimation and Risk
 Estimation carries inherent risk, and risk leads to uncertainty.
 Estimation risk is measured by the degree of uncertainty in the quantitative estimates established for resources, cost, and schedule.

 Availability of comprehensive historical information and software metrics (from past projects) helps establish better
estimates and hence reduces risk factors.

 If project scope is poorly understood or requirements are subject to change then uncertainty and estimation risk
become dangerously high.
 Thus variability in software requirements means instability in cost and schedule.
 However, a project manager should not become obsessive about estimation as modern software engineering
approaches are iterative in nature hence making it possible to revise estimates.
Software Project Planning Process
 Software project planning provides a framework that enables the manager to make reasonable estimates of
resources, cost and schedule.
 Although there is inherent uncertainty, the team embarks on a project plan.
 But, this plan must be adapted and updated as the project progresses.
Software Project Planning Activities
 Establish project scope
 Determine feasibility
 Analyze risks
 Define resources
 Estimate cost and effort
 Develop project schedule
Software Scope
 It is defined in one of the following ways:
 A narrative description developed after communication with all stakeholders
 A set of use-cases developed by end-user
 It describes
 functions & features to be delivered to end-user
 Input and output data
 “content” presented to users as they use the software
 Performance considerations (processing and response time, etc)
 Constraints (limits placed on software by external hardware, available memory, or existing systems),
interfaces and reliability that bound the system
Software Feasibility
 Feasibility check is conducted after scope identification.
 It addresses questions like
 Can we build software to meet this scope?
 Is the project feasible?
 These questions are very crucial but often overlooked either by software engineers or by the impatient customers
and managers
 Putnam and Myers address feasibility in four dimensions
 Technology
 Is the project technically feasible? Is it within state of the art? Can defects be reduced as needed?
 Finance
 Is it financially feasible? Can the development be completed at a cost that the software
organization, the client or the market can afford
 Time
 Will the project’s time-to-market beat the competition?
 Resources
 Does the organization have enough resources needed to succeed?
 After scope and feasibility, next comes estimation of resources. Three major categories of resources are:
 People/Human resources
 Reusable software components
 Development environment (s/w & h/w tools)
 Each resource has 4 characteristics
 Description of resource
 Statement of availability
 Time when resource will be required
 Duration of time when resource will be applied
Human resources
 This estimation involves
 Selecting Skills (required to complete development)
 Specifying organizational positions (manager, senior s/w engineering, ..) and specialty
 Determining number of people based on development effort
 For small projects, single person can do all s/w engineering tasks
 For large projects, more number of people involved which may be geographically distributed. So,
location of resource also specified
 No. of people can be determined after estimating development effort (e.g., person-months)
Reusable Software Resources
 CBSE emphasizes the creation and reuse of software building blocks (components)
 4 categories of software components
 Off-the-shelf components
 Ready-to-use existing software acquired from third party (COTS) or from (internal) past projects
 Full-experience components
 Existing specifications, designs, code, test data from past projects similar to software to be
developed (for current project). May require little modifications
 Partial experience component
 Existing specifications, designs, code, test data from past projects related to software to be
developed (for current project) but will require substantial modifications
 New components
 Software components that must be built for current project
(Development) Environment resources
 Software Engineering Environment (SEE) includes hardware and software support for a software project
 Hardware and software elements availability and time window must be specified
Software Project Estimation
 Options for cost and effort estimates:
 Delay estimation until late in project
 Not a practical approach
 Base estimation on similar past projects
 Reasonable approach but not always successful
 Use simple decomposition techniques to generate estimates
 Divide and conquer approach. Divide project into major activities/functions and make estimates
 Use some empirical model for estimation
 Complements decomposition techniques
 Which option is better?
 Each approach can be used as a cross-check for the other
Decomposition Techniques
 Decomposition can be performed in two aspects
 Decomposition of problem
 Decomposition of process
 Estimation uses one or both forms of decompositions. But before this, software size must be estimated.
Software Sizing
 Proper estimation of software size and mapping of size estimate to human effort, calendar time and cost are
important things which contribute to accuracy of overall software project estimation.
 In project planning, size refers to a quantifiable outcome.
 Direct approach – size is measured as LOC
 Indirect approach – size is measured as function-points
 Putnam and Myers suggested 4 different approaches for sizing problem
 Fuzzy logic sizing
 Function point sizing
 Standard component sizing
 Change sizing
Other types of estimations…
 Problem based estimation (LOC-based and FP-based)
 Process-based estimation
 Use-case based estimation
Empirical Estimation Models
 An estimation model for software uses empirically derived formulas.
 These formulas can predict effort as a function of LOC or FP.
 Empirical data that support most estimation models are derived from limited sample of projects, that is why, no
estimation model is appropriate for all classes of software and in all development environments.
 Estimation model must be calibrated to reflect local conditions.
Structure of Estimation Models
 A typical empirical model is derived using regression analysis on data collected from past projects
 Overall structure of such models takes the form
E= A+B x (ev)C
 A, B and C are empirically derived constants, E is effort in person-months and ev is estimation variable
(either LOC or FP)
The COCOMO Model
 In his classic book “Software Engineering Economics”, Barry Boehm suggested the COnstructive COst MOdel (COCOMO).

 COCOMO is a software cost estimation method for estimating effort, cost, and schedule for software projects.
 It is based on a set of empirically derived equations.
 These equations incorporate variables considered to be the major cost drivers of software development and maintenance.

 The original COCOMO (COCOMO 81) was first published in 1981 and reflected the software development practices of the day.
 A decade and a half later, the software development techniques changed dramatically and the original COCOMO
became problematic.
 It then evolved into COCOMO II to fulfill the changing needs.
 There are three versions of COCOMO 81:
o Basic
 Used for rough, early estimates
o Intermediate
 The most commonly used version which includes 15 different factors to account for the influence of various
project attributes such as personnel capability, hardware constraints, etc.
o Detailed
 This version accounts for influence of different factors on individual project phases.
 It is not used often.
 COCOMO applies to three classes of software projects:
o Organic projects - "small" teams with "good" experience working with "less than rigid" requirements
o Semi-detached projects - "medium" teams with mixed experience working with a mix of rigid and less than
rigid requirements
o Embedded projects - developed within a set of "tight" constraints (hardware, software, operational, ...), may
require new technology, unfamiliar algorithms, or new problem solving method
 COCOMO II is actually a hierarchy of estimation models that address the following areas:
o Application composition model
 Used during the early stages of s/w engg. When prototyping of UI, s/w and system interaction,
performance assessment and tech. evaluation are paramount.
o Early design stage model
 Used once requirements have been stabilized and basic architecture has been established
o Post-architecture stage model
 Used during the construction of software
 Like all estimation models for software, the COCOMO II requires sizing information.
 Three different sizing options available as part of model hierarchy are:
o object points,
o function points and
o Lines of source code.
 COCOMO II Application composition model uses object points
o Object points is an indirect software measure computed using counts of number of
 Screens (at UI)
 Reports
 Components likely to be required to build the application
o Each object instance is classified into one of these complexity levels (simple, medium, difficult) on criteria
suggested by Boehm.
 o Complexity is a function of number of client and server tables required to generate a screen or report and
number of sections or views within a screen or report
o After determining complexity, no. of screens, reports and components are weighted as in figure (23.6).
o The object point count is then determined by multiplying the original no. of object instances by weighting factor
and summing to obtain a total object point count.
 For component-based development or when software reuse is applied, the %reuse is estimated and object point
count is adjusted:
o NOP = (object points) x [(100 - %reuse)/100]
 NOP is new object points
 To derive estimate of effort based on computed NOP value, a productivity rate must be derived
o PROD = NOP / person-month
 Estimate of project effort can be derived as:
o Estimated effort = NOP/PROD
The Software Equation
 Suggested by Putnam & Myers
 It is a multivariable model
 It assumes a specific distribution of effort over life of s/w project
 It has been derived from productivity data collected for over 4000 modern-day s/w projects
 E = [LOC x B0.333 / P]3 x (1/t4)
 E = effort in person-months or person-years
 B = special skills factor
 P = productivity factor
 t = project duration (months or years)
 P reflects
 Overall process maturity
 Management practices
 Extent to which good s/w engg practices are used
 Level of prog. Languages used
 State of s/w environment
 Skills & experience of team
 Application complexity
 Typical values of P
 P= 2000 - for a real-time embedded s/w
 P= 10,000 - for telecomm. & systems s/w
 P= 28,000 for business applications
 Value of B
 Increases slowly as “the need for integration, testing, quality assurance, documentation and management skills grows”.
  For small programs (KLOC=5 to 15), B= 0.16, for larger programs (KLOC=more than 70), B=0.39
 Software equation has two independent parameters
 LOC
 t
 Minimum dev. Time equations derived from software equation
 tmin= 8.14 (LOC/P)0.43
 in months for tmin> 6 months
 E = 180 Bt3
 In person-months for E>= 20 person-months
Estimating Cost
 It involves developing an approximation of the costs of resources needed to complete project activities.

Inputs to Cost Estimating

 Work Breakdown Structure
 It organizes cost estimates and ensures that all identified work has been estimated.
 Resource Requirements
 Involves description of what type of resources are required and in what quantities for each element of WBS.

 Resource Rates
 Unit rates (e.g., staff cost per hour, bulk material cost per cubic yard) for each resource must be known to
calculate project cost.
 Activity duration estimates
 These affect cost estimates on any project where project budget includes an allowance for cost of financing
(i.e., interest charges)
 Estimating publications
 Commercially available data on cost estimating.
 Historical Information
 Historical data can be obtained from one or more of the following:
 Previous Project files,
  Commercial cost estimating databases
 Project team knowledge
 Chart of accounts
 It describes coding structure used by performing organization to report financial information in its general ledger.

 Risks
 The project team considers the extent to which the effect of risk is included in the cost estimates for each activity.

Tools and Techniques for Cost Estimating

 Analogous estimating
 It is also called top-down estimating, as actual cost of similar previous project is used as basis for current
estimating cost of current project.
 It is a less costly than other techniques but generally less accurate.
 It is most reliable when
 previous projects are similar in fact not just in appearance and
 People making the estimates have the required expertise.
 Parametric modeling
 It involves using project parameters in a mathematical model to predict project costs.
 Cost and accuracy of this technique varies.
 It is reliable when
 the historical info used to develop model was accurate,
 the parameters used are quantifiable and
 The model is scalable (works for both very small and very large projects).
 Bottom-up estimating
 It involves cost estimation of individual activities or work packages, then summarizing and rolling up the
individual estimates to get a project total.
 The cost and accuracy of this technique is driven by size and complexity of individual activity or work
package.
 Smaller activities increase the cost and accuracy of the estimating process.
 Computerized tools
 These include project management software spreadsheets and simulation/statistical tools.
 Other cost estimating methods
 For example, vendor bid analysis.
Outputs from Cost Estimating
 Cost estimates
 These are quantitative assessments of likely costs of resources (e.g., labor, material, supplies, etc.)
required to complete project activities.
 They are expressed in units of currency.
 Supporting detail
 Description of scope of work estimated (by reference to WBS)
  Documentation about how estimate was developed.
 Documentation of any assumptions made.
 An indication of range of possible results, e.g., $10,000 + $1,000 to indicate cost between $9,000 and
$11,000
 Cost Management Plan
 It describes how cost variances will be managed.
 It may be formal or informal, highly detailed or broadly framed, based on the needs of the project
stakeholders.
The Make/Buy decision
 Often it is more cost effective to acquire rather than develop a software
 Software managers have following options while making make/buy decisions
 Software may be purchased (or licensed) off the shelf
 “Full experience” or “partial experience” software components may be acquired and then modified as needed

 Software may be custom-built by an outside contractor to meet specifications

 Software criticality to be purchased and the end cost also affect acquisition process
 For each of the discussed acquisition options, the Make/Buy decision is made based on following conditions
 Will the software product be available sooner than internally developed software?
 Will the acquisition cost plus cost of customization be less than cost of developing the software internally?
 Will the cost of outside support (e.g., maintenance contract) be less than the cost of internal support?
Outsourcing
 Acquisition of software (or components) from a source outside the organization
 Software engineering activities are contracted to a third party who does the work at lower cost and (hopefully) at higher quality

 Software work within the company is reduced to contract management activity

 Outsourcing is often a financial decision
 Positive side
 Cost saving can usually be achieved by reducing own resources (people & infrastructure)
 Negative side
 Company loses some control over the software and bears the risk of putting its fate in hands of a third party

_____________________________________________

Chapter Five - Scheduling:

 When…
 Appropriate process model has been selected,
 Software engineering tasks have been identified,
 Estimation of amount of work & people has been done,
 Risk have been considered and deadline is known…
 Then it's time to connect the dots to create a network of tasks for achieving the software engineering tasks. This
network creation is called ‘software project scheduling’
What is Project Scheduling?
 An activity that distributes estimated effort across the planned project duration by allocating the effort to specific
software engineering task.
 Creating a network of software engineering tasks to complete the project and assign responsibilities of tasks and
timing of tasks.
What is Project Tracking?
 Tracking is the process to make sure that all tasks are completed according to assigned responsibility and schedule.
Proper Project Scheduling requires:
 All tasks should appear in the network,
 Interdependencies between tasks are indicated,
 Effort and timing are intelligently allocated to tasks,
 Resources are allocated to tasks,
 Closely spaced milestones are provided for progress tracking.
Who creates Project Schedule?
 At the project level, it is done by project managers using information solicited from software engineers.
Reasons for late software delivery
 Unrealistic deadline established by someone outside the software development group & enforced.
 Changing customer requirements that are not reflected in schedule change.
 An honest underestimate of the amount of work and/or resources required.
 Risks that were not considered at project commencement.
 Technical difficulties not foreseen in advance.
 Miscommunication among project staff.
 A failure by project management to recognize that the project is falling behind schedule and a lack of action to
correct the problem.
Dealing with Project Deadlines
 Aggressive (actually unrealistic) deadlines are a fact of life in software business.
 If best estimates indicate that deadline is unrealistic Project Manager should :
“Protect his/her team from undue (schedule) pressure… and reflect pressure back to its originators.”
 Recommended steps for such situations:
1. Perform a detailed estimate using historical data from past projects. Determine estimated effort and
duration for project.
2. Use incremental model, develop a strategy that will deliver critical functionality within imposed deadline,
but delay other functionality until later. Document the plan.
3. Meet the customer and explain why imposed deadline is unrealistic. Explain what is the new time required
to complete this project.
4. Offer incremental development strategy as alternative. For example, offer some options:
 First, we can increase the budget and have bring resources to get this job done in due time. But
this contains increased risk of poor quality due to tight timeline.
 Second, we can remove some software functions, and provide remaining functionality later.
  Third, dispense with reality and wish to complete software in due time, say nine months (third
option may be unacceptable).
5. By presenting solid estimates and references to past projects, it is likely that, negotiated versions of option
1 and 2 will be accepted by customer.
Project Scheduling (Evolution)
 It is important to note that the project schedule evolves over time.
 During early stages of project planning, a macroscopic schedule is developed.
 This schedule identifies all major process framework activities and the product functions to which they are applied.
 As the project proceeds, each entry on the macroscopic schedule gets refined into detailed schedule.
 Specific tasks are identified to achieve each activity and are scheduled.
Project Scheduling - Basic Principles
 Compartmentalization
 Both the product and the process are decomposed into a number of manageable activities/tasks
 Interdependency
 Interdependencies among decomposed activities must be identified.
 Some tasks can be performed in sequence and other can be done in parallel.
 Some activities cannot be performed without completion of another and some can be totally independent
 Time Allocation
 Each task must be allocated work units (person-days of effort)
 Start and end time must be allocated considering interdependencies & whether work will conducted be
part-time or full-time
 Effort validation
 Project manager must ensure that no more than the allocated no. of people have been scheduled at any
given time
 Defined responsibilities
 Every scheduled task must be assigned to a specific team member
 Defined outcomes
 Work products must be defined for every scheduled task
 Defined milestones
 Every task/group of tasks must be associated with a project milestone. A milestone is accomplished after
one or more related work products has been reviewed for quality and approved
Relationship between People and Effort
 Common Myth …
 “If we fall behind schedule, we can always add more programmers and catch up later in the project!”
 Doing so is often disruptive rather than productive causing further delays. Reasons:
 learning time for added people
 teaching takes time away from productive work
 Addition of people increases communication paths – hence increased complexity
  Putnam-Norden-Rayleigh (PNR) Curve indicates the relationship between effort applied and delivery time for a
software project.

 to = delivery time that will result in least effort expended

 As we move left to to, i.e. as we try to accelerate delivery, curve rises nonlinearly
 As we try to reduce accelerate delivery, curve rises sharply to left of td indicating, project delivery time can not be
compressed much beyond 0.75td
 As we try further, the project moves into impossible region and failure risk becomes high

PNR Curve & Software Eqn.

 The software equation is derived from the PNR curve
 It demonstrates a highly nonlinear relationship between time to complete project and human effort applied to
the project
 Lines of Code (L) is related to effort (E) and development time (t) as:
 L = P x E 1/3 t 4/3
 Rearranging the equation, we get the expression for development effort
 E = L3 / P3t4
Effort Distribution
 A recommended distribution of effort across software process is often referred to as 40-20-40 rule
 40% allocated to analysis & design
  20% allocated to coding
 40% allocated to testing
 Use the above as a guideline only as each project dictates its own distribution effort, e.g. criticality of the software
often dictates the amount of testing and hence testing effort
Defining Task Set For the Software Project
 Task set is a collection of software engineering work tasks , milestones and deliverables that must be accomplished
to complete a particular software project.
 Task sets are different for different types of projects.
 Most organizations encounter following types of projects
o Concept development projects
 Explore some new business concept or application of new technology.
o New application development projects
 Undertaken as a consequence of specific customer request
o Application Enhancement projects
 Involve modification to functions, performance or interfaces (observable by end-user) in existing
software
o Application maintenance projects
 That correct, adapt or extend existing software in ways that may not be obvious to end user
o Reengineering projects
 Undertaken for rebuilding an existing system in whole or part
Factors Influencing Task Set Selection in Projects
 Size of project
 Number of potential users
 Mission criticality
 Application longevity
 Stability of requirements
 Ease of customer/develop communication
 Maturity of applicable technology
 Performance constraints
 Embedded, non-embedded characteristics
 Project staff
 Reengineering factors
 These factors also provide an indication of the degree of rigor with which the software process should be applied
Refinement of Major Tasks
 The major tasks described earlier may be used to define a macroscopic schedule for project.
 The macroscopic schedule must be refined to create a detailed schedule.
 For this each major task is decomposed into a set of subtasks (with related work products and milestones)
  As an example consider task 1.1 – concept scoping. The refinement is shown on next slide:
Defining a Task Network
 Also known as activity network.
 It is a graphic representation of the task flow for a project.
 Displays interdependencies and parallelism.
 Project manager should be aware of those tasks that lie on the critical path
Scheduling
 Two Project Scheduling methods that can be applied to software development:
 Program evaluation and review technique (PERT)
 Critical Path Method (CPM)
 Both are driven by Info already developed:
 Estimates of effort
 A decomposition of product function
 The selection of appropriate process model and task set
 Decomposition of tasks
Timeline Charts
 When creating software project schedule, the planner begins with a set of tasks (work breakdown structure)
 If automated tools are used, the work breakdown is input as a task network
 Effort, duration and start date are then input for each task
 As a result of this input, a timeline chart or Gantt chart is generated
Tracking Schedule
 Accomplished in a no. of ways
 Conducting periodic project status meetings in which each team member reports progress & problems
 Evaluating results of all reviews conducted throughout the s/w engineering process
 Determining whether formal project milestones have been accomplished by scheduled date
 Comparing actual start date to planned date for each project task
 Meeting practitioners to get their assessment of progress to date and problems encountered
 Use earned value analysis to assess progress quantitatively
Earned Value Analysis
 Earned Value Analysis (EVA) provides a quantitative indication of progress of a project.
 Humphrey discusses earned value as:
 “The earned value system provides a common value scale for every [software project] task, regardless of
the type of work being performed. The total hours to do the whole project are estimated and every task is
given an earned value based on its estimated percentage of the total”
 It compares the PLANNED work with the actually COMPLETED work, to determine if COST, SCHEDULE, and WORK
ACCOMPLISHED are progressing as planned.
  EVA is accomplished using Earned Value Management.
Earned Value Management (EVM)
 EVM is a project management technique for measuring project progress.
 If applied properly, it provides an early warning of performance and
 Improves definition of scope
 Communicates progress to stakeholders
 And keeps the project team focused on achieving progress.
 EVM implementation includes
 A project plan that identifies work to be accomplished or WBS,
 A valuation of planned work called Planned Value (PV) or Budgeted Cost of Work Scheduled (BCWS)
 Predefined “earning rules” (a.k.a. metrics) to quantify the accomplishment of work called Earned Value
(EV) or Budgeted Cost of Work Performed (BCWP)
 BCWP value is sum of the BCWS values for all work tasks that have actually been completed by a
point in time on the project schedule
Earned Value Management
 Wilkens’ gives distinction between BCWS and BCWP as:
 BCWS represents the budget of activities that were planned to be completed
 and BCWP represents the budget of activities that were actually completed
 EVM for large projects includes many more features such as indicators and forecast of cost performance and
schedule performance.
 Important progress indicators can be computed based on BCWS, BAC, BCWP values
 SPI = BCWP/BCWS
 Schedule performance index indicates efficiency with which project is using scheduled resources. SPI value
1.0 indicates efficient execution of project schedule
 SV = BCWP – BCWS
 Schedule variance is simply an absolute indication of variance from planned schedule
 Percent scheduled for completion= BCWS/BAC
 Where BAC is Budget at completion computed as: BAC = ∑(BCWSk) for all k tasks
 Percent complete= BCWP/BAC
 Provides indication of percent of completeness of the project at a given point in time t.
 CPI = BCWP/ACWP
 Cost performance index value close to 1.0 indicates project is within its defined budget
 Actual Cost of Work Performed ACWP is sum of effort actually expended on work tasks that have been
completed by a point in time on project schedule
 CV = BCWP – ACWP
 Cost Variance is an absolute indication of cost savings against planed or shortfall at a particular stage of
project
Project Tracking without EVM
Blue line =the cumulative budget for this project as a function of time .
Red line = the cumulative actual cost of the project through week 8.

Project Tracking without EVM

 To those unfamiliar with EVM, it might appear that this project was over budget through week 4 and then under
budget from week 6 through week 8.
 However, this chart does not indicate how much work has been accomplished during the project.
 If the project was actually completed at week 8, then the project would actually be well under budget and well
ahead of schedule .
 If, on the other hand, the project is only 10% complete at week 8, the project is significantly over budget and
behind schedule .
 A method is needed to measure technical performance (progress) objectively and quantitatively, and that is what
EVM accomplishes .
Project Tracking with EVM
 Consider the same project, except this time the project plan includes pre-defined methods of quantifying the
accomplishment of work .
 At the end of each week, the project manager identifies every detailed element of work that has been completed,
and sums the PV for each of these completed elements .
 Earned value may be accumulated monthly, weekly, or as progress is made.
Green line = EV curve ,Blue line = PV curve

 The chart indicates that progress started more rapidly than planned, but slowed significantly and fell behind
schedule at week 7 and 8.
 This chart illustrates the schedule performance aspect of EVM .