u02a1 Major Processes in the Development Life Cycle Warren Wilson

Part 1:
The following are Pfleegers nine processes of the software development life cycle (SDLC):
SDLC Processes
A process is a series of steps involving activities, constraints and resources that produce an
intended output of some kind. A process usually involves a set of tools and techniques. Processes
are important because they impose consistency and structure on a set of activities. The process
structure guides actions by allowing software engineers to examine, understand, control, and
improve the activities that comprise the software process. In software development, it is
important to follow a software development process in order to understand, control and improve
what happens as software products are built for customers.
Furthermore, each stage of software development is itself a process (or a collection of processes)
that can be described by a set of activities. A process can be described in a variety of ways, using
text, pictures or a combination. In the software engineering literature, descriptions of process
models are prescriptions (or the way software development should progress) or descriptions (the
way software development is done in actuality). In theory, the two should be the same, but in
practice, they are not. Building a process model and discussing its sub-processes helps the team
to understand the gap between the two.
System Planning
System planning is the first stage of system development life cycle. This gives a clear picture of
what actually the physical system is? In practice, the system planning is done in two phases. In
the first phase, the preliminary survey of the system is done which helps in identifying the scope
of the system. The second phase of the system planning is more detailed and in-depth study in
which the identification of users requirement and the limitations and problems of the present
system are studied. After completing the system planning, a system proposal is prepared by the
System Analyst (who studies the system) and placed before the user. The proposed system
contains the findings of the present system and recommendations to overcome the limitations
and problems of the present system in the light of the users requirements.
To describe the system planning phase more analytically, we would say that system planning
phase passes through the following steps:
1. problem identification and project initiation
2. background analysis
3. inference or findings
1. Requirements Analysis and Definition

Assuming that a new system is to be developed, the next phase is requirement analysis and
definition. The analysis involved a detailed study of the current system, leading to specifications
of a new system. The analysis is a detailed study of various operations performed by a system
and their relationships within and outside the system. During the analysis, data are collected on
the available files, decision points and transactions handled by the present system. Using the
following steps it becomes easy to draw the exact definition of the new system under
consideration:

Interviews (with users)

On-site observation (of where system to be implemented)
Questionnaire (about system to be developed)
Keeping in view the problems and new requirements
Workout the pros and cons including new areas of the system

All procedures, requirements must be analyzed and documented in the form of detailed data flow
diagrams, data dictionary, logical data structures and miniature specifications. The requirement
analysis also includes sub-dividing of complex process involving the entire system, identification
of data structure and manual processes.
The main points to be discussed in requirement analysis are:

Specification of what the new system is to accomplish based on the user requirements.
Functional hierarchy showing the functions to be performed by the new system and their
relationship with each other.
Function network which are similar to function hierarchy but they highlight those
functions which are common to more than one procedure.
List of attributes of the entities - these are the data items which need to be held about
each entity (record)

2. System Design
Based on the user requirements and the detailed analysis of the new system, the new system must
be designed. This is the phase of system designing. It is a most crucial phase in the development
of a system. In this stage the different design phases are:

Architecture design (Designing the structure of the system)

Interface design (Specifying the interfaces between the parts of the system)
Detailed design (Designing the algorithms for the individual parts)
Design concepts
Design strategies
Design-support tools and evaluation

In system design, the features of the new system are specified. The costs of implementing these
features and the benefits to be derived are estimated. If the project is still considered to be
feasible, we move to the program design stage.

Some of the other activities that may be used in the system design stage are:

Project planning (for determining how to develop the software)

Cost analysis (for determining cost estimations)
Scheduling (for building a schedule for the development process)
Software quality assurance (for determining activities that will help ensure quality of the
product)
Work-breakdown structure (for determining the subtasks necessary to develop the
product)

3. Program Design
The program design is a blue print of a computer system solution to a given problem having the
same components and inter-relationship among the same components as the original problem. At
this stage, the design of the system becomes more structured. Input, output and processing
specifications are drawn up in detail. In the program design stage, the programming language
and the platform in which the new system will run on are also decided.
There are several tools and techniques used for designing. These tools and techniques are:

Flowchart
Data flow diagram
Data dictionary
Structured English
Decision table
Decision tree

4. Writing the Program (Program Implementation)

a. Coding Program
After designing the new system, the whole system is required to be converted into computer
programming language. Writing the program for the new system is an important stage where the
defined procedures are transformed into control specifications by the help of a computer
programming language. This is also called the program implementation phase in which the
programmer converts the program specifications into computer instructions, which we refer as
programs. The programs coordinate the data movements and control the entire process in a
system.
b. Program Implementation
After having the user acceptance of the new system developed, the implementation phase begins.
Implementation is the stage of a project during which theory is turned into practice. During this
phase, all the programs of the system are loaded onto the user's computer. After loading the
system, training of the users starts. Main topics of such type of training are:

How to execute the package

How to enter the data
How to process the data (processing details)
How to take out the reports

After the users are trained about the computerized system, manual working has to shift from
manual to computerized working. The following two strategies are followed for running the
system:
i.

Parallel run: In such run for a certain period, both the systems -- computerized and
manual are executed in parallel. This strategy is helpful because of the following:
Manual results can be compared with the results of the computerized system.
Failure of the computerized system at the early stage, does not affect the working
of the organization, because the manual system continues to work, as it used to
do.
Pilot run: In this type of run, the new system is installed in parts. Some part of the new
system is installed first and executed successfully for considerable time period. When the
results are found satisfactory then only other parts are implemented. This strategy builds
confidence and the errors are traced easily.

ii.

5. Unit Testing
Before actually implementing the new system into operations, a test run of the system is done
removing all the bugs, if any. It is an important phase of a successful system. After codifying the
whole programs of the system, a test plan should be developed and run on a given set of test
data. The output of the test run should match the expected results.
When the programs have been coded and compiled and brought to working conditions, they must
be individually tested with the prepared test data. Any undesirable happening must be noted and
debugged (error corrections).
When it is ensured that the system is running error-free, the users are called with their own actual
data so that the system could be shown running as per their requirements.
6. Integration Testing
Integration testing is when software and/or hardware components are combined and tested to
confirm that they interact according to their requirements. Integration testing can continue
progressively until the entire system has been integrated.
Integration testing typically involves the following steps:
1. Create a Test Plan
2. Create Test Cases and Test Data
3. If applicable create scripts to run test cases

4. Once the components have been integrated execute the test cases
5. Fix the bugs if any and re test the code
6. Repeat the test cycle until the components have been successfully integrated
There are two major ways of carrying out an integration test, called the bottom-up method and
the top-down method. Bottom-up integration testing begins with unit testing, followed by tests of
progressively higher-level combinations of units called modules or builds. In top-down
integration testing, the highest-level modules are tested first and progressively lower-level
modules are tested after that. In a comprehensive software development environment, bottom-up
testing is usually done first, followed by top-down testing.
7. System Testing
Before actually implementing the new system into operations, a test run of the system is done
removing all the bugs, if any. It is an important phase of a successful system. After coding the
programs for the system, a test plan should be developed and run on a given set of test data. The
output of the test run should match the expected results.
After carrying out the unit test for each of the programs for the system and when errors are
removed, then system test is done. At this stage the test is done on actual data. The complete
system is executed on the actual data. At each stage of the execution, the results or output of the
system is analyzed. During the result analysis of testing, it may be found that the outputs are not
matching the expected outputs for the system. In such case, the errors in the particular programs
are identified and are fixed and further testing is done for expected output. When it is ensured
that the system is running error-free, the users are called with their own actual data so that the
system could be shown running as per their requirements.
8. System Delivery
The system delivery is a staged to roll out of the new application, this involves installation and
initial training and may involve hardware and network upgrades. Software will definitely
undergo change once it is delivered to the customer. There are many reasons for the change.
Change can happen because of some unexpected input values into the system. In addition, the
changes in the system could be directly affecting the software operations. The software should be
developed to accommodate changes that could happen during the post implementation period.
The development team puts the compiled software onto end-user unit or interface and runs
targeted business.
The deployment phase contains two stages, a three- to six-month pilot followed by a national
deployment. At the conclusion of the pilot, the finished application is placed on a production
server. Users are trained, user guides are delivered, and the system is distributed.
9. Maintenance
Maintenance is necessary to eliminate errors in the system during its working life and to tune the
system to any variations in its working environment. It has been seen that there are always some

errors found in the system that must be noted and corrected. It also means the review of the
system from time to time. The review of the system is done for:

Knowing the full capabilities of the system

Knowing the required changes or the additional requirements
Studying the performance

If a major change to a system is needed, a new project may have to be set up to carry out the
change. The new project will then proceed through all the above life cycle phases.

Part 2:
The processes of the software development life cycle using an Agile approach:
Agile software development refers to a group of methodologies that promotes software
development by iteration, open collaboration, and process adaptability throughout the life-cycle
of the project. It chooses to do things in small increments, with minimal planning, rather than
plan at length. This helps to minimize the overall risk, and allows the project to adapt to changes
more quickly. There is also an emphasis on stakeholder involvement. The stakeholder is
consulted about the product and comments are noted and acted upon at the end of each iteration.
1. Analysis (Conception)
Understand the application from the perspective of the stakeholder:
Time to accomplish: normally accomplished in days; sometimes 1 week
Inputs: customer collaboration, requirements documents, legacy code
Possible artifacts that demonstrate understanding:

High level problem statement

Generalized use cases that captures the intentions of a user
High level activity diagram
High level work flow

Agile practices employed:

Active stakeholder participation

Estimate the solution to the problem:

Time to accomplish: Hours
Inputs: High level use cases, project requirements
Artifacts: project estimate

Agile practices employed:

Active stakeholder participation

Small releases

2. Design (Elaboration)
Model the solution to the problem:
Time to accomplish: Several days to 1 week for large problem domains
Inputs: High level use cases, project requirements from Phase 1
Artifacts:

Agile class diagrams depicting data layer objects

Agile class diagrams depicting business layer objects
Agile sequence diagrams for complex logic
User interface mock-ups and flows
Others as painfully required

Agile practices employed:

Active stakeholder participation

Agile Modeling
Style and modeling standards
Simple design
Model refactoring

3. Implementation (Construction)
Implement the solution to the problem:
Time to accomplish: Weeks to months
Inputs: Design Model from Phase 2
Artifacts: Working code
Agile practices employed:

Active stakeholder participation

Test Driven development
Pair programming
Accomplished in iterations
Develop Incrementally
Code refactoring
Coding standards

4. Testing (Transition)
Verify the solution:
Time to accomplish: Hours to Days
Inputs: Implementation from Phase 3
Artifacts: Proven and tested code
Agile practices employed:

Active stakeholder participation

Continuous Integration Testing; run the test suite at least daily, email the results to team

In closing, in any software development process a system requires an input and a delivered
product as output. However, no matter what process model is used, many activities are common
to all. There are two major categories of model types: static and dynamic. A static model depicts
the process, showing that the inputs are transformed to outputs. A dynamic model can enact the
process, so that the user can see how intermediate and final products are transformed over time.
The systems dynamics approach has also been applied to dynamically model software
development processes.
The agile models attempt to minimize this process by dividing the project into short iterations
(called timeboxes) that normally last one week to one month. Each timebox represents a project
in miniature, with planning, requirements, design, coding, testing, and documentation. Agile
methods aim to satisfy customers with rapid, continuous deliveries of useful software, delivered
in weeks rather than months. The principal measure of progress is working software. Close, faceto-face communication is expected between developers and business people. The project should
adapt to changing circumstances, and even late changes in the requirements are welcome.

On the other hand, the waterfall model is considered one of the most direct approaches, with
short development times and minimal costs. However, it does presume an unvarying program
and that is the original specifications cannot change. When a phase is completed, the phase is
closed and cannot be revisited. This limitation has lead to widespread criticism of this approach.
The software development process involves discovery, and the different phases of development
often overlap. Critics maintain that the waterfall or the traditional model limits options to correct
mistakes. If a limitation or mistake of the requirements is discovered during the design phase, it
is too late to fix it.
Agile methodology means cutting down the big picture into puzzle size bits, fitting them
together when the time is right. So, while there are reasons to support both the waterfall and agile
methods, however, a closer look clarifies why many software and web design firms make the
more appropriate choice of employing the Agile methodology.
References:
Abrahamsson, P., Salo, O., Ronkainen, J., Warsta, J. (2002). Agile Software Development
Methods, Review and Analysis. (Copyright VTT 2002). [VTT Publications 478].
Retrieved from http://www.pss-europe.com/P478.pdf
ExecutiveBrief (2008). Which Life Cycle Is Best for Your Project? Retrieved from
http://www.projectsmart.co.uk/which-life-cycle-is-best-for-your-project.html
Patton, J. (2007). Agile Product Design, Management, and Ownership Instruction. Retrieved
from www.agileproductdesign.com/consulting/patton_training_workshops.doc
Pfleeger, S. L., & Atlee, J. M. (2010). Software engineering: Theory and practice (4th ed.).
Upper Saddle River, NJ: Prentice-Hall.
Saiful Islam, S.M. (2009). Software Engineering Process Design Quality Attributes.
Retrieved from http://www.docstoc.com/docs/8077699/Software-Engineering-Process--Design-Quality-Attributes/

SDLC Handbook (1998). Chapter 7 Traditional Waterfall Life Cycle. Retrieved from
http://som.csudh.edu/depts/cis/msheu/CIS%20502/week01/ch7-v9.pdf
SDLC Phases (2006). Systems Development Life Cycle (SDLC) Volume 2. Maryland
Department of Information Technology. Retrieved from
http://doit.maryland.gov/policies/Documents/sdlc/sdlcvol2.pdf
Steven, T. (2008). [Article]. Agile Lifecycle/Agile Heartbeat.(Copyright 2008). Retrieved from
http://www.itsadeliverything.com/articles/agile_lifecycle.htm
System Development Life Cycle Guide. (2008, May). Texas Department of Information
Resource, Texas Project Delivery Framework. Retrieved from
http://www2.dir.state.tx.us/SiteCollectionDocuments/IT
%20Leadership/Framework/Framework%20Extensions/sdlc-guide.pdf