SOFTWARE

SOFTWARE PROJECT
PROJECT
MANAGEMENT
MANAGEMENT
(KOE-068)
(KOE-068)
Faculty: Rajanish Jain
Course: B.Tech 6th Semester
Session 2021-22
Department of Computer Science & Engineering
04/05/2024 1
 University Syllabus
Unit-2: Project Life Cycle and Effort Estimation:

Software process and Process Models – Choice of Process models – Rapid

Application development – Agile methods – Dynamic System Development Method –
Extreme Programming– Managing interactive processes – Basics of Software
estimation – Effort and Cost estimation techniques – COSMIC Full function points –
COCOMO II – a Parametric Productivity Model.
.

04/05/2024 2
Text books:
1. Bob Hughes, Mike Cotterell and Rajib Mall: Software Project Management – Fifth
Edition, McGraw Hill, New Delhi, 2012.
2. Robert K. Wysocki ―Effective
Software Project Management – Wiley Publication, 2011. 3.
Walker Royce: ―Software Project Management- Addison-Wesley, 1998.
4.Gopalaswamy Ramesh, ―Managing Global Software Projects – McGraw
Hill Education (India), Fourteenth Reprint 2013.

04/05/2024 3
 UNIT-2
UNIT-2
LECTURE-1
LECTURE-1
Project
Project Life
Life Cycle
Cycle and
and Effort
Effort Estimation
Estimation

Faculty: Rajanish Jain

Department of Computer Science &
Engineering
04/05/2024 4
 The Software process
 A structured set of activities required to develop a software system.
 Many different software processes but all involve:
 Specification – defining what the system should do;
 Design and implementation – defining the organization of the system and
implementing the system;
 Validation – checking that it does what the customer wants;
 Evolution – changing the system in response to changing customer
needs.
 A software process model is an abstract representation of a process. It
presents a description of a process from some particular perspective.

04/05/2024 5
2
 Software process descriptions
 When we describe and discuss processes, we usually talk about the
activities in these processes such as specifying a data model, designing a
user interface, etc. and the ordering of these activities.
 Process descriptions may also include:
 Products, which are the outcomes of a process activity;
 Roles, which reflect the responsibilities of the people involved in the
process;
 Pre- and post-conditions, which are statements that are true
before and after a process activity has been enacted or a product
produced.

04/05/2024 6
Plan-driven and agile processes
 Plan-driven processes are processes where all of the process
activities are planned in advance and progress is measured against
this plan.
 In agile processes, planning is incremental and it is easier to
change the process to reflect changing customer
requirements.
 In practice, most practical processes include elements of both plan-
driven and agile approaches.
 There are no right or wrong software processes.

04/05/2024 7
 Software process models
 The waterfall model
 Plan-driven model. Separate and distinct phases of
specification and development.
 Incremental development
 Specification, development and validation are interleaved. May
be plan-driven or agile.
 Reuse-oriented software engineering
 The system is assembled from existing components. May
be plan-driven or agile.
 In practice, most large systems are developed using a process
that incorporates elements from all of these models.
04/05/2024 8
 The waterfall model

04/05/2024 9
 Waterfall model phases
 There are separate identified phases in the waterfall model:
 Requirements analysis and definition
 System and software design
 Implementation and unit testing
 Integration and system testing
 Operation and maintenance
 The main drawback of the waterfall model is the difficulty of
accommodating change after the process is underway. In principle,
a phase has to be complete before moving onto the next phase.

04/05/2024 10
 Waterfall model problems
 Inflexible partitioning of the project into distinct stages makes it
difficult to respond to changing customer requirements.
 Therefore, this model is only appropriate when the
requirements are well-understood and changes will be fairly
limited during the design process.
 Few business systems have stable requirements.
 The waterfall model is mostly used for large systems
engineering projects where a system is developed at several
sites.
 In those circumstances, the plan-driven nature of the
waterfall model helps coordinate the work.
04/05/2024 11
 V-process model

Another way of looking at the waterfall model

04/05/2024 12
• V-Model also referred to as the Verification and Validation Model. In this,
each phase of SDLC must complete before the next phase starts.
• It follows a sequential design process same as the waterfall model. Testing
of the device is planned in parallel with a corresponding stage of
development.
• Verification: It involves a static analysis method (review) done without
executing code. It is the process of evaluation of the product development
process to find whether specified requirements meet.
• Validation: It involves dynamic analysis method (functional, non-
functional), testing is done by executing code. Validation is the process to
classify the software after the completion of the development process to
determine whether the software meets the customer expectations and
requirements.
04/05/2024 13
 Spiral model
 Process is represented as a spiral rather than as
sequence of activities with backtracking.
 Each loop in the spiral represents a phase in the
process.
 No fixed phases such as specification or design - loops
in the spiral are chosen depending on what is required.
 Risks are explicitly assessed and resolved throughout the
process.

04/05/2024 14
 Spiral model of the software process

04/05/2024 15
 Spiral model sectors
 Objective setting
 Specific objectives for the phase are identified.
 Risk assessment and reduction
 Risks are assessed and activities put in place to reduce the key
risks.
 Development and validation
 A development model for the system is chosen which can be
any of the generic models.
 Planning
 The project is reviewed and the next phase of the spiral is
04/05/2024planned. 16
Spiral model usage
 Spiral model has been very influential in helping people think about
iteration in software processes and introducing the risk-driven
approach to development.
 In practice, however, the model is rarely used as published
for practical software development.

04/05/2024 17
 Software prototyping
 A prototype is an initial version of a system used to
demonstrate concepts and try out design options.
 A prototype can be used in:
 The requirements engineering process to help with
requirements
elicitation and validation;
 In design processes to explore options and develop a UI design;
 In the testing process to run back-to-back tests.

04/05/2024 18
 Reducing the costs of rework
 Change avoidance, where the software process includes activities
that can anticipate possible changes before significant rework is
required.
 For example, a prototype system may be developed to
show some key features of the system to customers.
 Change tolerance, where the process is designed so that changes
can be accommodated at relatively low cost.
 This normally involves some form of incremental development.
Proposed changes may be implemented in increments that
have not yet been developed. If this is impossible, then only a
single increment (a small part of the system) may have be
altered to incorporate the change.
04/05/2024 19
 Benefits of prototyping
 Improved system usability.
 A closer match to users’ real needs.
 Improved design quality.
 Improved maintainability.
 Reduced development effort.

04/05/2024 20
 The process of prototype development

04/05/2024 21
 Prototype development
 May be based on rapid prototyping languages or tools
 May involve leaving out functionality
 Prototype should focus on areas of the product that are not
well- understood;
 Error checking and recovery may not be included in the
prototype;
 Focus on functional rather than non-functional
requirements such as reliability and security

04/05/2024 22
 Throw-away prototypes
 Prototypes should be discarded after development as
they are not a good basis for a production system:
 It may be impossible to tune the system to meet non-
functional requirements;
 Prototypes are normally undocumented;
 The prototype structure is usually degraded through rapid
change;
 The prototype probably will not meet normal
organisational quality standards.

04/05/2024 23
 Incremental delivery
 Rather than deliver the system as a single delivery, the
development and delivery is broken down into increments with
each increment delivering part of the required functionality.
 User requirements are prioritised and the highest priority
requirements are included in early increments.
 Once the development of an increment is started, the
requirements are frozen though requirements for later increments
can continue to evolve.

04/05/2024 24
 Incremental development and delivery
 Incremental development
 Develop the system in increments and evaluate each
increment before proceeding to the development of the next
increment;
 Normal approach used in agile methods;
 Evaluation done by user/customer proxy.
 Incremental delivery
 Deploy an increment for use by end-users;
 More realistic evaluation about practical use of software;
 Difficult to implement for replacement systems as
04/05/2024increments have less functionality than the system being 25
 Incremental delivery

04/05/2024 26
 Incremental delivery advantages
 Customer value can be delivered with each increment so
system functionality is available earlier.
 Early increments act as a prototype to help elicit
requirements for later increments.
 Lower risk of overall project failure.
 The highest priority system services tend to receive the
most testing.

04/05/2024 27
 Incremental delivery problems
 Most systems require a set of basic facilities that are used
by different parts of the system.
 As requirements are not defined in detail until an increment is to
be implemented, it can be hard to identify common facilities that
are needed by all increments.
 The essence of iterative processes is that the
specification is developed in conjunction with the
software.
 However, this conflicts with the procurement model of many
organizations, where the complete system specification is part of
the system development contract.
04/05/2024 28
 Incremental development

04/05/2024 29
 Incremental delivery
delivered
system
design build install evaluate
increment
first incremental delivery 1

design build install evaluate increment

2
second incremental delivery
increment
design build install evaluate
3

third incremental delivery

04/05/2024 30
 The incremental process

Intentional
incremental
delivery

04/05/2024 31
 Incremental development benefits
 The cost of accommodating changing customer
requirements is reduced.
 The amount of analysis and documentation that has to be
redone is much less than is required with the waterfall
model.
 It is easier to get customer feedback on the development work that
has been done.
 Customers can comment on demonstrations of the software
and see how much has been implemented.
 More rapid delivery and deployment of useful software to the
customer is possible.
 Customers are able to use and gain value from the
04/05/2024 32
Incremental development problems
 The process is not visible.
 Managers need regular deliverables to measure progress. If
systems are developed quickly, it is not cost-effective to
produce documents that reflect every version of the system.
 System structure tends to degrade as new increments are
added.
 Unless time and money is spent on refactoring to improve
the software, regular change tends to corrupt its structure.
Incorporating further software changes becomes increasingly
difficult and costly.

04/05/2024 33
 The outline incremental plan
• steps ideally 1% to 5% of the total project
• non-computer steps should be included
• ideal if a step takes one month or less:
– not more than three months
• each step should deliver some benefit to the user
• some steps will be physically dependent on others

04/05/2024 34
 Which step first?
• some steps will be pre-requisite because of physical
dependencies
• others may be in any order
• value to cost ratios may be used
– V/C where
– V is a score 1-10 representing value to customer
– C is a score 0-10 representing value to developers

04/05/2024 35
 V/C ratios: an example
step value cost ratio
profit reports 9 1 9 2nd
online database 1 9 0.11 5th
ad hoc enquiry 5 5 1 4th
purchasing plans 9 4 2.25 3rd
profit- based pay 9 0 inf 1st
for managers

04/05/2024 36
 ‘Agile’ methods

structured development methods have some perceived

advantages
– produce large amounts of documentation which can
be largely unread
– documentation has to be kept up to date
– division into specialist groups and need to follow
procedures stifles communication
– users can be excluded from decision process
– long lead times to deliver anything etc. etc
The answer? ‘Agile’ methods?
04/05/2024 37
• The meaning of Agile is swift or versatile."Agile process model"
refers to a software development approach based on iterative
development.
• Agile methods break tasks into smaller iterations, or parts do not
directly involve long term planning.
• The project scope and requirements are laid down at the beginning
of the development process.
• Plans regarding the number of iterations, the duration and the
scope of each iteration are clearly defined in advance.
04/05/2024 38
• Each iteration is considered as a short time "frame" in the Agile
process model, which typically lasts from one to four weeks.
• The division of the entire project into smaller parts helps to minimize
the project risk and to reduce the overall project delivery time
requirements.
• Each iteration involves a team working through a full software
development life cycle including planning, requirements analysis,
design, coding, and testing before a working product is
demonstrated to the client.

04/05/2024 39
04/05/2024 40
04/05/2024 41
 Dynamic system development method
• UK-based consortium
• arguably DSDM can be seen as replacement for SSADM
( Structured System Analysis and Design)
• DSDM is more a project management approach than a
development approach
• Can still use DFDs, LDSs etc!

04/05/2024 42
 Nine core DSDM principles
1. Active user involvement
2. Teams empowered to make decisions
3. Frequent delivery of products
4. Fitness for business purpose
5. Iterative and incremental delivery
6. Changes are reversible
7. Requirements base-lined at a high level
8. Testing integrated with development
9. Collaborative and co-operative approach

04/05/2024 43
 DSDM framework

Figure 4.6 here

DSDM process model

04/05/2024 44
 DSDM: Time-Boxing
• time-box fixed deadline by which something has to be
delivered
• typically two to six weeks
• MOSCOW priorities
– Must have - essential
– Should have - very important, but system could
operate without
– Could have
– Want - but probably won’t get!

04/05/2024 45
 Extreme programming
• increments of one to three weeks
– customer can suggest improvement at any point
• argued that distinction between design and building of
software are artificial
• code to be developed to meet current needs only
• frequent re-factoring to keep code structured
• developers work in pairs
• test cases and expected results devised before software design
• after testing of increment, test cases added to a consolidated
set of test cases
04/05/2024 46