IT PROJECT MANAGEMENT

MODULE – 2

PROJECT LIFE CYCLE AND EFFORT ESTIMATION:

Software Process and Process Models

A Software Process (also known as software methodology) is a set of related activities that leads
to the production of the software. These activities may involve the development of the software
from the scratch, or, modifying an existing system.

Activities of any software process are:

1. Software specification (or requirements engineering): Define the main

functionalities of the software and the constraints around them.
2. Software design and implementation: The software is to be designed and
programmed.
3. Software verification and validation: The software must conform to its
specification and meet the customer needs.
4. Software evolution (software maintenance): The software is being modified to meet
customer and market requirements changes.

A software process model is an abstraction of the software development process. The models
specify the stages and order of a process. So, think of this as a representation of the order of
activities of the process and the sequence in which they are performed.
A model will define the following:
• The tasks to be performed
• The input and output of each task
• The pre and post conditions for each task
• The flow and sequence of each task
Choice of Process Models

• The word process is sometimes used to emphasize the idea of a system in action. In order
to achieve an outcome, the system will have to execute one or more activities: this is its
process.
• This idea can be applied to the development of computer-based systems where a number of
interrelated activities have to be undertaken to create a local product. These activities can be
organized in different ways and we can call these process models.
• A major part of the planning will be the choosing of the development methods to be used
and the slotting of these into an overall process model.
• The planner needs not only to select methods but also to specify how the method is to be
applied. With methods such as SSADM, there is a considerable degree of choice about how
it is to be applied: not all parts of SSADM are compulsory. Many student projects have the
rather basic failing that at the planning stage they claim. SSADM is to be used: in the event,
all that is produced are a few SSADM fragments such as a top- level data flow diagram and
a preliminary logical data structure diagram. If this is all the particular project requires, it
should be stated at the outset.
The various Process Models are

Water Fall Model

Spiral Model Prototype
Model Incremental Delivery

2.2.1 Water fall model

The waterfall model is a sequential approach, where each fundamental activity of a process
represented as a separate phase, arranged in linear order.
In the waterfall model, you must plan and schedule all of the activities before starting working on
them (plan-driven process).
Plan-driven process is a process where all the activities are planned first, and the progress is
measured against the plan. While the agile process, planning is incremental and it’s easier to change
the process to reflect requirement changes.

The phases of the waterfall model are:

 Requirements

 Design

 Implementation

 Testing

 Maintenance
In principle, the result of each phase is one or more documents that should be approved and the next
phase shouldn’t be started until the previous phase has completely been finished.
In practice, however, these phases overlap and feed information to each other. For example, during
design, problems with requirements can be identified, and during coding, some of the design
problems can be found, etc.
The software process therefore is not a simple linear but involves feedback from one phase to
another. So, documents produced in each phase may then have to be modified to reflect the changes
made.

2.2.1 Spiral Model

The spiral model is similar to the incremental model, with more emphasis placed on risk
analysis. The spiral model has four phases: Planning, Risk Analysis, Engineering and Evaluation.
A software project repeatedly passes through these phases in iterations (called Spirals in this
model). The baseline spiral, starting in the planning phase, requirements is gathered and risk is
assessed. Each subsequent spiral builds on the baseline spiral. It is one of the software development
models like Waterfall, Agile, V-Model.
Planning Phase: Requirements are gathered during the planning phase. Requirements like ‘BRS’
that is ‘Bussiness Requirement Specifications’ and ‘SRS’ that is ‘System Requirement
specifications’.
Risk Analysis: In the risk analysis phase, a process is undertaken to identify risk and alternate
solutions. A prototype is produced at the end of the risk analysis phase. If any risk is found during
the risk analysis then alternate solutions are suggested and implemented.
Engineering Phase: In this phase software is developed, along with testing at the end of the
phase. Hence in this phase the development and testing is done.
Evaluation phase: This phase allows the customer to evaluate the output of the project to date
before the project continues to the next spiral.

Advantages of Spiral model:

 High amount of risk analysis hence, avoidance of Risk is enhanced.
 Good for large and mission-critical projects.
 Strong approval and documentation control.
 Additional Functionality can be added at a later date.
 Software is produced early in the software life cycle.
Disadvantages of Spiral model:
 Can be a costly model to use.
 Risk analysis requires highly specific expertise.
 Project’s success is highly dependent on the risk analysis phase.
 Doesn’t work well for smaller projects.

2.2.2 Software Prototyping

A prototype is a version of a system or part of the system that’s developed quickly to check
the customer’s requirements or feasibility of some design decisions.So, a prototype is useful when
a customer or developer is not sure of the requirements, or of algorithms, efficiency, business rules,
response time, etc.
In prototyping, the client is involved throughout the development process, which increases
the likelihood of client acceptance of the final implementation. While some prototypes are
developed with the expectation that they will be discarded, it is possible in some cases to evolve
from prototype to working system.
A software prototype can be used:
[1] In the requirements engineering, a prototype can help with the elicitation and validation of
system requirements. It allows the users to experiment with the system, and so, refine the
requirements. They may get new ideas for requirements, and find areas of strength and weakness
in the software. Furthermore, as the prototype is developed, it may reveal errors and in the
requirements. The specification maybe then modified to reflect the changes.
[2] In the system design, a prototype can help to carry out deign experiments to check the feasibility
of a proposed design. For example, a database design may be prototype-d and tested to check it
supports efficient data access for the most common user queries.
The phases of a prototype are:
1. Establish objectives: The objectives of the prototype should be made explicit from the start of
the process. Is it to validate system requirements, or demonstrate feasibility, etc.
2. Define prototype functionality: Decide what are the inputs and the expected output from a
prototype. To reduce the prototyping costs and accelerate the delivery schedule, you may ignore
some functionality, such as response time and memory utilization unless they are relevant to
the objective of the prototype.
3. Develop the prototype: The initial prototype is developed that includes only user interfaces.
4. Evaluate the prototype: Once the users are trained to use the prototype, they then discover
requirements errors. Using the feedback both the specifications and the prototype can be
improved. If changes are introduced, then a repeat of steps 3 and 4 may be needed.
Prototyping is not a standalone, complete development methodology, but rather an approach
to be used in the context of a full methodology (such as incremental, spiral, etc).

2.1 Incremental Delivery

Incremental development is based on the idea of developing an initial implementation,
exposing this to user feedback, and evolving it through several versions until an acceptable system
has been developed. The activities of a process are not separated but interleaved with feedback
involved across those activities.
 Each system increment reflects a piece of the functionality that is needed by the customer.
Generally, the early increments of the system should include the most important or most
urgentlyrequired functionality.
This means that the customer can evaluate the system at early stage in the development
tosee if it delivers what’s required. If not, then only the current increment has to be changed
and, possibly, new functionality defined for later increments.

Incremental Vs Waterfall Model

Incremental software development is better than a waterfall approach for most business, e-
commerce, and personal systems. By developing the software incrementally, it is cheaper and
easier to make changes in the softwareas it is being developed.

Compared to the waterfall model, incremental development has three important benefits:

1. The cost of accommodating changing customer requirements is reduced. The amount of

analysis and documentation that has to be redone is much less than that’s required with
waterfall model.
2. It’s easier to get customer feedback on the work done during development than when the
system is fully developed, tested, and delivered.
3. More rapid delivery of useful software is possible even if all the functionality hasn’t been
included. Customers are able to use and gain value from the software earlier than it’s
possiblewith the waterfall model.

Rapid Application Development

It is a type of incremental model. In RAD model the components or functions are developed in
parallel as if they were mini projects. The developments are time boxed, delivered and then
assembled into a working prototype. This can quickly give the customer something to see and
use and to provide feedback regarding the delivery and their requirements.
  RAD (Rapid Application Development) is a concept that products can be developed
faster and of higher quality through:
• Gathering requirements using workshops or focus groups
• Prototyping and early, re-iterative user testing of designs
• The re-use of software components
• A rigidly paced schedule that refers design improvements to the next product version
• Less formality in reviews and other team communication.

Features of RAD:-
 Quick prototyping
 Iterative development
 Incremental releases
 User involvement
 Time boxing
 Parallel development
The phases in the rapid application development (RAD) model are:
Business modeling: The information flow is identified between various business functions.
Data modeling: Information gathered from business modeling is used to define data objects
that are needed for the business.
Process modeling: Data objects defined in data modeling are converted to achieve the business
information flow to achieve some specific business objective. Description are identified and
created for CRUD of data objects.
Application generation: Automated tools are used to convert process models into code and
the actual system.
Testing and turnover: Test new components and all the interfaces.

Advantages of the RAD model:

• Reduced development time.
• Increases reusability of components
• Quick initial reviews occur
• Encourages customer feedback
• Integration from very beginning solves a lot of integration issues.

Disadvantages of RAD model:

• Depends on strong team and individual performances for identifying business
requirements.
• Only system that can be modularized can be built using RAD
• Requires highly skilled developers/designers.
• High dependency on modeling skills
• Inapplicable to cheaper projects as cost of modeling and automated code generation is very
high.

Agile Methods

AGILE methodology is a practice that promotes continuous iteration of development and

testing throughout the software development life cycle of the project. In the Agile model, both
development and testing activities are concurrent, unlike the Waterfall model.
The Agile software development methodology is one of the simplest and effective processes to
turn a vision for a business need into software solutions. Agile is a term used to describe software
development approaches that employ continual planning, learning, improvement, team
collaboration, evolutionary development, and early delivery. It encourages flexible responses to
change.
The Agile methodology is a way to manage a project by breaking it up into several phases. It
involves constant collaboration with stakeholders and continuous improvement at every stage.
Once the work begins, teams’ cycle through a process of planning, executing, and evaluating.
Continuous collaboration is vital, both with team members and project stakeholders.

Methods involved:

1. Test Management is a process of managing the testing activities in order to ensure

high quality and high-end testing of the software application.

2. Development in project management includes following steps:

1. Brainstorming and planning.
2. Requirements and feasibility analysis.
3. Design.
4. Development & coding.
5. Integration and testing.
6. Implementation and deployment.
7. Operations and maintenance.

3. Project design is an early phase of the project where a project's key features, structure,
criteria for success, and major deliverables are all planned out. The aim is to develop
one or more designs that can be used to achieve the desired project goals.

4. Deploy: Software deployment is one of the most important aspects of the

software development process. Deployment is the mechanism through which
applications are made available for use by end users or systems, typically by transferring
the developed and tested software from a development or staging environment to a
production environment. This process involves ensuring that the application is correctly
configured, tested, and operational in the live environment, enabling users to access new
features, improvements, or bug fixes. Deployment in Agile methodology is done
frequently and incrementally to ensure continuous delivery of value to the users.

5. Requirements: The software requirements specification document lists sufficient and

necessary requirements for the project development

Dynamic System Development Method

• DSDM is an iterative code method within which every iteration follows the 80% rule that
simply enough work is needed for every increment to facilitate movement to the
following increment.

• The remaining detail is often completed later once a lot of business necessities are noted
or changes are requested and accommodated.
 • DSDM is an agile method that focuses on the full project lifecycle, DSDM (formally
known as Dynamic System Development Method) was created in 1994, after project
managers using RAD (Rapid Application Development) sought more governance and
discipline to this new iterative way of working.

1. Feasibility Study:
It establishes the essential business necessities and constraints related to the application
to be designed then assesses whether or not the application could be a viable candidate
for the DSDM method.
2. Business Study:
It establishes the use and knowledge necessities that may permit the application to supply
business value; additionally, it is the essential application design and identifies the
maintainability necessities for the application.
3. Functional Model Iteration:
It produces a collection of progressive prototypes that demonstrate practicality for the
client.

Extreme Programming

Extreme programming (XP) is one of the most important software development frameworks
of agile models. It is used to improve software quality and responsive to customer
requirements. The extreme programming model recommends taking the best practices that
have worked well in the past in program development projects to extreme levels.
Extreme Programming (XP) is an agile project management framework used in software
development. It prescribes everything, from how to organize projects and develop software, to
how to increase developers' productivity and what's the best way to collaborate on code.

Three practices of Extreme Programming:

• Continuous Integration
• Test-First (including Test-Driven Development and Behavior-Driven Development)
• Refactoring, pair work, and collective ownership.

Some teams use other XP practices, such as a pair programming and system metaphors
Managing Interactive Processes

Managing People

• Act as project leader

• Liaison with stakeholders
• Managing human resources
• Setting up reporting hierarchy etc.

Managing Project

• Defining and setting up project scope

• Managing project management activities
• Monitoring progress and performance
• Risk analysis at every phase
• Take necessary step to avoid or come out of problems
• Act as project spokesperson

Basics of Software Estimation:

Estimation determines how much money, effort, resources, and time it will take to build a
specific system or product. Estimation is based on −

• Past Data/Past Experience

• Available Documents/Knowledge
• Assumptions
• Identified Risks

The four basic steps in Software Project Estimation are −

• Estimate the size of the development product.

• Estimate the effort in person-months or person-hours.
• Estimate the schedule in calendar months.
• Estimate the project cost in agreed currency.
 Activities involved in Software Estimation:

1. Projects planning (Estimation determines how much money, effort, resources, and
time it will take to build a specific system or product)
2. Scope and feasibility (The functions and features that are to be delivered to end users.
The data that are input to and output from the system. The "content" that is presented
to users as a consequence of using the software)
3. Project resources (Each resource is specified with: A description of the resource. A
statement of availability, time when the resource will be required. The duration of time
that the resource will be applied Time window)
4. Estimation of project cost and effort (The accuracy of a software project estimate is
predicated on: The degree to which the planner has properly estimated the size (e.g.,
KLOC) of the product to be built. The ability to translate the size estimate into human
effort, calendar time, and money)
5. Decomposition techniques (Before an estimate can be made and decomposition
techniques applied, the planner must Understand the scope of the software to be built
Generate an estimate of the software’s size)
6. Empirical estimation models (Estimation models for computer software use
empirically derived formulas to predict effort as a function of LOC (line of code) or FP
(function point). Resultant values computed for LOC or FP are entered into an
estimation model)

Effort and Cost Estimation Techniques

Cost and effort estimation are performed in a stepwise fashion by breaking down a
project into major functions and related software engineering activities.

 Algorithmic models, which use effort drivers representing characteristics of the target
system and the implementation environment to predict effort.
 Expert judgment, based on the advice of knowledgeable staff.
 Analogy, where a similar completed project is identified and its actual effort is used as
the basis of the estimate.
 Parkinson, where the staff effort available to do a project becomes the estimate.
 Price to win, where the estimate is a figure that seems sufficiently low to win a contract.
 Top-down, where an overall estimate for the whole project is broken down into the effort
required for component tasks.
 Bottom-up, where component tasks are identified and sized and these individual
estimates are aggregated.