PSNA COLLEGE OF ENGINEERING AND TECHNOLOGY, DINDIGUL – 624622.

(An Autonomous Institution Affiliated to Anna University, Chennai)

IT8075 – SOFTWARE PROJECT MANAGEMENT
UNIT 2 – PROJECT LIFE CYCLE AND EFFORT ESTIMATION
SOFTWAREPROCESSANDPROCESSMODELS:
 Asoftwareproductdevelopmentprocessusuallystartswhenarequestfortheproductisrece
ivedfromthecustomer.
 Startingfromtheinceptionstage:
 Aproductundergoesaseriesoftransformationsthroughafew
identifiablestages.
 Untilitisfullydevelopedandreleasedtothecustomer.
 After release:
 The product is used by the customer and during this time the product
needs to be maintained for fixing bugs and enhancing functionalities.
This stage is called maintenance stage.
 This set of identifiable stages through which a product transits from inception
to retirement form the life cycle of the product.
 Life cycle model (also called a process model) is a graphical or textual
representation of its life cycle.
CHOICE OF PROCESS MODELS:
 The number of interrelated activities to create a final product can be organized in
different ways and we can call these Process Models.
 A software process model is a simplified representation of a software process. Each
model represents a process from a specific perspective. These generic models are
abstractions of the process that can be used to explain different approaches to the
software development.
 Any software process must include the following four activities:
 Software specification
 Software design and implementation
 Software verification and validation
 Software maintenance
 The various Process Models are
 Waterfall Model
 Spiral Model
 Software Prototyping
 Incremental Delivery
(a) Waterfall Model:
 The ‘classical’ model of system development.
 ‘Waterfall’ also known as ‘one-shot’, ‘once-through’ model.
 It imposes structure on the project.
 Limited scope for iteration.
 Every stage needs to be checked and signed off – stage-gate model.
 It allows project completion times to be forecast with some confidence,
allowing the effective control of the project.

1
 Fig: The waterfall model
(b) Spiral Model:

Fig: The spiral model

 It could be argued that this is another way of looking at the waterfall model.

2
  In the waterfall model, it is possible to escape at the end of any activity in the
sequence.
 A feasibility study might decide that the implementation of a proposed
system would be beneficial.
 The management therefore authorizes work on the detailed analysis of user
requirements.
 Some analysis, might already have taken place at the feasibility stage, but a
more thorough investigation is now launched.
 This could reveal that the costs of implementing the system would be higher
than projected benefits and lead to a decision to abandon the project.
 A greater level of detail is considered at each stage of the project and a
greater degree of confidence about the probability of success for the project
should be justified.
 This can be portrayed as a loop or a spiral where the system to be
implemented is considered in more detail in each sweep.
 Each sweep terminates with an evaluation before the next iteration is
embarked upon.
 The figure below illustrates how SSADM can be interpreted in such a way.
 A key point here is that uncertainty about a project is usually because of a
lack of knowledge about some aspect.
 We can spend money on activities at the start of the project that buy
knowledge and reduce that uncertainty.
(c) Software Prototyping:
 This is one way, we can buy knowledge and reduce uncertainty.
 A prototype is a working model of one or more aspects of the projected
system.
 It is constructed and tested quickly and inexpensively in order to test out
assumptions.
 Prototypes can be classified as throw-away or evolutionary.
 Throw-Away Prototypes:
 Tests out some ideas.
 Developed using a different software or hardware environment.
 Procedural programming language is used.
 Evolutionary Prototypes:
 Developed and modified until it becomes the operational system.
 Standards that are used to develop the software.
 Some of the reasons that have been put forward for prototyping follow:
 Learning by doing
 Improved communication
 Improved user involvement
 Clarification of partially known requirements
 Demonstration of the consistency and completeness of a specification
 Reduced need for documentation
 Reduced maintenance costs
 Feature constraint
 Production of expected results
 Users can misunderstand the role of the prototype
 Lack of project standards possible

3
  Lack of control
 Additional expense
 Machine efficiency
 Close proximity of developers
(d) Incremental Delivery:
 This approach breaks the application down into small components which are
then implemented and delivered in sequence.
 Each component delivered must give some benefit to the user.
 Time-boxing is often associated with an incremental approach.
 Here the scope of deliverables for an increment is rigidly constrained by an
agreed deadline.
 This deadline has to be met, even at the expense of dropping some of the
planned functionality.
 Omitted features can be transferred to later increments.

Fig: Intentional incremental delivery

Advantages:
 The feedback from early increments improves the later stages.
 The possibility of changes in requirements is reduced.
 Users get benefits earlier than with a conventional approach.
 Early delivery of some useful components improves cash flow.
 Smaller sub-projects are easier to control and manage.
 The project can be temporarily abandoned if more urgent work emerges.
 Job satisfaction is increased for developers.
Disadvantages:
 Later increments might require modifications to earlier increments. This is
known as software breakage.
4
  Software developers may be more productive working on one large system
than on a series of smaller ones.
RAPID APPLICATION DEVELOPMENT:
 RAD model is also referred to as the rapid prototyping model.
 It has the features of both the prototyping and the incremental delivery models.
 The major aims of the RAD model are as follows:
 To decrease the time taken and the cost incurred to develop software systems.
 To limit the costs of accommodating change requests as early as possible
before large investments have been made.
 One of the major problems with the waterfall model is the following:
 Clients do not know what they exactly want until they see a working system.
 They do not see the working system until it delivered to them.
 As a result, the exact requirements only known after the application is
installed.
 The required changes are incorporated after the installation.
 This makes the cost of accommodating any change extremely high.
 As a result, it takes more time and huge cost to obtain the solution.
 This model would displease even the best customer.
 RAD model tries to overcome this problem by inviting and incorporating customer
feedback on successively developed prototypes.
 In RAD model, absence of long-term and detailed planning gives the flexibility of
accommodate requirements change requests from customer during project
execution.
 In RAD model, development takes place in a series of cycles called iterations.
 Plans are made for one iteration at a time only.
 The time planned for each iteration is called a time box.
 Each iteration enhances the implemented functionality of the application little.
 During each iteration, a quick and dirty prototype for some functionality is
developed.
 The customer evaluates the prototype and gives feedback, based on which the
prototype is refined.
 Thus, over successive iterations, the full set of functionalities of the software takes
shape.
 In RAD model, the prototype is used for gathering customer feedback only and is
not released to the customer for regular use.
AGILE METHODS:
 Agile methods are designed to overcome the disadvantages we have noted with
heavyweight implementation methodologies.
 There are various agile approaches, including:
 Crystal technologies
 Atern (formerly DSDM)
 Feature-driven development
 Scrum
 Extreme Programming (XP)
 In agile model, feature requirements are decomposed into several small parts that
can be incrementally developed.
 The agile model adopts an iterative approach.

5
  Each incremental part is developed over an iteration.
 Each iteration is intended to be small and easily manageable, and lasts for a couple
of weeks only.
 Agile model adopts an iterative approach.
 At a time, only one increment is planned, developed, and deployed.
 No long-term plans are made.
 Time taken to complete an iteration is called a time box.
 The implication of the term ‘time box’ is that the end date for an iteration does not
change.
 The development team can decide to reduce the delivered functionality during time
box, but the delivery date is considered sacrosanct.
 Besides that, a few other principles discussed below:
 Agile model emphasizes face-to-face communication over written documents.
 Team size is kept small (5-9 people) to help the team members effectively
communicate with each other and collaborate.
 Agile model well-suited for small projects as well as for large projects also.
 In large project, the collaborating teams might work at different locations.
 In this case, the different teams maintain daily contact through video
conferencing, telephone, e-mail, etc.
 An agile project usually includes a customer representative in the teams.
 At the end of each iteration, the customer representative along with the
stakeholders review the progress made, re-evaluate the requirements, and give
suitable feedback to the development team.
 Agile development projects usually deploy pair programming.
 Two programmers work together at one work station.
 One types the code while the other reviews the code as it is typed.
 The two programmers switch their roles every hour or so.
 Programmers working in pairs produce compact well-written programs and
commit fewer errors as compared to programmers working alone.
DYNAMIC SYSTEMS DEVELOPMENT METHOD:
 In United Kingdom, SSADM (Structured Systems Analysis and Design Method) has
until recently been a predominant methodology.
 In no small part, this has been because of sponsorship by the UK government.
 More recently, it has lost some favour, partly because it has been perceived as
overly bureaucratic and prescriptive.
 In contrast, there has been an increased interest in the iterative and incremental
approaches.
 A consortium has developed guidelines for the use of such techniques and
packaged the overall approach as the Dynamic Systems Development Method
(DSDM).
 This has been re-badged as Atern.
 It is possible to attend courses on the method and to become an accredited Atern
practitioner.
 Eight core Atern principles have been enunciated:
1. Focus on business need
2. Deliver on time
3. Collaborate
4. Never compromise quality
6
 5. Develop iteratively
6. Build incrementally from firm foundations
7. Communicate continuously
8. Demonstrate control
 The main life-cycle phases are:
 Feasibility/foundation
 Exploration cycle
 Engineering cycle
 Deployment

Fig: Atern process model

 Atern encourages the use of time-boxes.
 It is suggested that these should typically be between two and six weeks.
 It will be recalled in order to meet the deadline imposed by a time-box.
 The implementation of less important features may be held over to later increments
(or even dropped altogether).
 The relative importance of requirements can be categorized using the ‘MoSCoW’
classification:
 Must have: that is essential features.
 Should have: these would probably be mandatory.
 Could have: these requirements can be delayed with some inconvenience.
 Won’t have: these features are wanted, but their delay to a later increment is
readily accepted.
 The possibility of requirements being, reallocated to different increments means
that project plans will need to be constantly updated if the project is to be
successfully controlled.
EXTREME PROGRAMMING:
 The primary source of information on XP is Kent Beck’s “Extreme programming
explained: embrace change”, first published in 1999 and updated in 2004.
 The description here is based on the first edition, with some comments where the
ideas have been developed further in the second.
 The ideas were largely developed on the C3 payroll development project at Chrysler.
 The approach is called ‘extreme programming’ because, according to Beck, ‘XP
takes commonsense principles to extreme levels’.

7
  Four core values are presented as the foundations of XP.
1. Communication and Feedback:
 It is argued that the best method of communication is face-to-face
communication.
 Also, the best way of communicating to the users the nature of the
software under production is to provide them with frequent working
increments. Formal documentation is avoided.
2. Simplicity:
 The simplest design that implements the users’ requirements should
always be adopted.
 Effort should not be spent trying to cater for future possible needs –
which in any case might never actually materialize.
3. Responsibility:
 The developers are the ones who are ultimately responsible for the quality
of the software - not/ for example, some system testing or quality control
group.
4. Courage:
 This is the courage to throw away work in which you have already
invested a lot of effort, and to start with a fresh design if that is what is
called for.
 It is also the courage to try out new ideas - after all, if they do not work
out, they can always be scrapped.
 Beck argues that this attitude is more likely to lead to better solutions.
 Among the core practices of XP are the following:
 The planning exercise
 Metaphor
 Simple design
 Testing
 Refactoring
 Pair programming
 Collective ownership
 Continuous integration
 Forty-hour weeks
 On-site customers
 Coding standards
Advantages:
 Robustness
 Resilience
 Cost savings
 Lesser risks
Disadvantages:
 It assumes constant involvement of customers.
 Centered approach rather than design-centered approach.
 Lack of proper documentation.
MANAGING ITERATIVE PROCESSES:
 Booch suggests that there are two levels of development: the macro process and the
micro process.

8
 Fig: A macro process containing three micro processes
 Macro process is closely related to the waterfall process model.
 At this level, a range of activities carried out by a variety of specialist groups has to
be coordinated.
 We need to have some dates when we know that major activities will be finished so
that we bring in staff to work on subsequent activities.
 Within this macro process there will be micro process activities which might involve
iterative working.
 A system testing has always been one.
 The figure below illustrates how a sequential macro process can be imposed on a
number of iterative sub-processes.
 With iterative micro processes, the use of time-boxes is needed to control at the
macro level.