Manual SDLC Models I

G.C.Reddy (09247837478) gcrindia@gmail.
com
Software Testing
Chapter I Software Development Life Cycle Models
Software: The instructions executed by a computer, as opposed to the physical device on

which they run (the "hardware").
Software: Software is a set of programs; they take Inputs and provide Outputs.
 Set of Instructions are called as Program.
 A set of Programs are called Software unit/Component.
 Integrated Units/components Called as a Software/System.
Software Testing:
Testing: The process consisting of all life cycle activities, both static and dynamic, concerned
with planning, preparation and evaluation of software products and related work products
to determine that they satisfy specified requirements, to demonstrate that they are fit for
purpose and to detect defects.
G.c.Reddy- Knowledge Doc: GC 001 1

G.C.Reddy (09247837478) gcrindia@gmail.com
Information Technology
Information Technology
Computer
Computer Computer
Hardware Software
Hardware Hardware
Hardware Software Software
Manufacturing Testing
Testing Development Testing
Software
System Programming Application

System Software
Software Software Software
Operating Systems, Text Editors Banking Application

Device Drivers, C, C++, Java, Spread Sheets
Utilities COBOL, .Net Accounting S/w
Etc... Etc... Etc…
Software
Software Application Software Product
Banking software MS Windows, MS Office,

Insurance software Focus, Tally Etc…
Software Development:
I. Software Bidding: A Proposal to develop new software is called Software Bidding.

In Software Application Development, the proposal comes from the specific customers.

In Product development, Organization takes their own proposal.
II. Kick off meeting: The CEO category People Conduct meeting with high level management
and select a project manager to handle the new software development process.
III. Pin Document: The selected project manager prepares this document to estimate required
people, required technologies, time and resources.
Then he submits a report to CEO. The CEO conducts a review meeting to give green signal to
project manager.
Software engineering: (SE) A systematic approach to the analysis, design, implementation

and maintenance of software. It often involves the use of CASE tools. There are various
models of the software life-cycle and many methodologies for the different phases.
Software Development Phases
Requirement Gathering
Analysis and Planning
Designing the software
Coding
Testing
Release & Maintenance

In above SDLC model, single stage of Testing is available and conducts by developers. If any
mistakes happen resolving is expensive, due to this reason organizations are concentrating on
multiple stages of testing and separate testing Team to conduct System Testing.
Quality:
The meaning for the term quality has developed over time. Various interpretations are given
below:
1. ISO 9000 - "Degree to which a set of inherent characteristic fulfills requirements"

2. "Fitness for use". Fitness is defined by the customer.
3. A two-dimensional model of quality. The quality has two dimensions: "must-be quality"
and "attractive quality". The former is near to the "fitness for use" and the latter is
what the customer would love, but has not yet thought about. Supporters characterize
this model more succinctly as: "Products and services that meet or exceed customers'
expectations".
4. "Value to some person".

Software quality: The totality of functionality and features of a software product that bear
on its ability to satisfy stated or implied needs.
Software Quality:
 Meet customer Requirements (Functionality).
 Meet customer expectations (Usability, Performance, Reliable etc...).
 Cost to purchase (Reasonable).
 Time to Market.
Software Quality Assurance:

The monitoring and Measuring the Strength of development process is called SQA or
Verification.
Software Quality Control:

The validation of Product with respect to customer requirements is called SQC or Validation or
Testing.
Verification: Confirmation by examination and through the provision of objective evidence
that specified requirements have been fulfilled.
Validation: Confirmation by examination and through provision of objective evidence that
the requirements for a specific intended use or application have been fulfilled.
Software Development Life Cycle Models
The waterfall model
The waterfall model derives its name due to the cascading effect from one phase to the other
as is illustrated in Figure1.1. In this model each phase well defined starting and ending point,
with identifiable deliveries to the next phase.
Note that this model is sometimes referred to as the linear sequential model or the
software life cycle.

The model consists of six distinct stages, namely:
1. In the requirements analysis phase
(a) The problem is specified along with the desired service objectives (goals)
(b) The constraints are identified

2. In the specification phase the system specification is produced from the detailed
definitions of (a) and (b) above. This document should clearly define the product
function.
Note that in some text, the requirements analysis and specifications phases are
combined and represented as a single phase.
3. In the system and software design phase, the system specifications are translated
into a software representation. The software engineer at this stage is concerned with:
 Data structure
 Software architecture
 Algorithmic detail and
 Interface representations
The hardware requirements are also determined at this stage along with a picture of
the overall system architecture. By the end of this stage the software engineer should
be able to identify the relationship between the hardware, software and the associated
interfaces. Any faults in the specification should ideally not be passed ‘down stream’
4. In the implementation and testing phase stage the designs are translated into the
software domain
 Detailed documentation from the design phase can significantly reduce the
coding effort.
 Testing at this stage focuses on making sure that any errors are identified
and that the software meets its required specification.
5. In the integration and system testing phase all the program units are integrated and
tested to ensure that the complete system meets the software requirements. After this
stage the software is delivered to the customer [Deliverable – The software
product is delivered to the client for acceptance testing.]

6. The maintenance phase the usually the longest stage of the software. In this phase
the software is updated to:
 Meet the changing customer needs
 Adapted to accommodate changes in the external environment
 Correct errors and oversights previously undetected in the testing phases
 Enhancing the efficiency of the software
Observe that feed back loops allow for corrections to be incorporated into the model. For
example a problem/update in the design phase requires a ‘revisit’ to the specifications phase.
When changes are made at any phase, the relevant documentation should be updated to
reflect that change.
Advantages
 Testing is inherent to every phase of the waterfall model
 It is an enforced disciplined approach
 It is documentation driven, that is, documentation is produced at every stage
Disadvantages
The waterfall model is the oldest and the most widely used paradigm.
However, many projects rarely follow its sequential flow. This is due to the inherent problems
associated with its rigid format. Namely:
 It only incorporates iteration indirectly, thus changes may cause considerable

confusion as the project progresses.
 As The client usually only has a vague idea of exactly what is required from the
software product, this WM has difficulty accommodating the natural uncertainty
that exists at the beginning of the project.
 The customer only sees a working version of the product after it has been
coded. This may result in disaster if any undetected problems are precipitated to
this stage.
The Spiral Model
The spiral model, illustrated in Fig. 1.7, combines the iterative nature of prototyping with the
controlled and systematic aspects of the waterfall model, therein providing the potential for
rapid development of incremental versions of the software. In this model the software is
developed in a series of incremental releases with the early stages being either paper models
or prototypes. Later iterations become increasingly more complete versions of the product.

As illustrate in Fig 1.7, the model is divided into a number of task regions.
Depending on the model it may have 3-6 task regions (/framework activities) our
case will consider a ‘6-task region’ model.
These regions are:
1. The customer communication task – to establish effective communication between

developer and customer.
2. The planning task – to define resources, time lines and other project related
information..
3. The risk analysis task – to assess both technical and management risks.
4. The engineering task – to build one or more representations of the application.

5. The construction and release task – to construct, test, install and provide user
support (e.g., documentation and training).
6. The customer evaluation task – to obtain customer feedback based on the
evaluation of the software representation created during the engineering stage and
implemented during the install stage.
The evolutionary process begins at the centre position and moves in a clockwise direction.
Each traversal of the spiral typically results in a deliverable. For example, the first and second
spiral traversals may result in the production of a product specification and a prototype,
respectively. Subsequent traversals may then produce more sophisticated versions of the
software.
An important distinction between the spiral model and other software models is the explicit
consideration of risk. There are no fixed phases such as specification or design phases in the
model and it encompasses other process models. For example, prototyping may be used in
one spiral to resolve requirement uncertainties and hence reduce risks. This may then be
followed by a conventional waterfall development.
 Note that each passage through the planning stage results in an adjustment to the
project plan (e.g. cost and schedule are adjusted based on the feedback from the
customer, project manager may adjust the number of iterations required to complete
the software….)
 Each of the regions is populated by a set of work tasks called a task set that are
adapted to characteristics of the project to be undertaken. For small projects the
number of tasks and their formality is low. Conversely, for large projects the reverse is
true.
Advantages of the Spiral Model
• The spiral model is a realistic approach to the development of large-scale software

products because the software evolves as the process progresses. In addition, the
developer and the client better understand and react to risks at each evolutionary
level.
• The model uses prototyping as a risk reduction mechanism and allows for the
development of prototypes at any stage of the evolutionary development.
• It maintains a systematic stepwise approach, like the classic life cycle model, but
incorporates it into an iterative framework that more reflect the real world.
• If employed correctly, this model should reduce risks before they become problematic,
as consideration of technical risks are considered at all stages.
Disadvantages of the Spiral Model

 Demands considerable risk-assessment expertise
 It has not been employed as much proven models (e.g. the WF model) and hence
may prove difficult to ‘sell’ to the client (esp. where a contract is involved) that this
model is controllable and efficient. [More study needs to be done in this regard]
The ‘V’ Model:
V-model: A framework to describe the software development life cycle activities from
requirements specification to maintenance. The V-model illustrates how testing activities
can be integrated into each phase of the software development life cycle.
V stands for Verification and validation.

This model defining Development process with testing stages, this model extension of SDLC
model.

Software Development Life Cycle Models
I was asked to put together this high-level and traditional software life cycle information as a
favor for a friend of a friend, so I thought I might as well share it with everybody.
The General Model
Software life cycle models describe phases of the software cycle and the order in which those
phases are executed. There are tons of models, and many companies adopt their own, but all
have very similar patterns. The general, basic model is shown below:
General Life Cycle Model

Each phase produces deliverables required by the next phase in the life cycle. Requirements
are translated into design. Code is produced during implementation that is driven by the
design. Testing verifies the deliverable of the implementation phase against requirements.
Requirements
Business requirements are gathered in this phase. This phase is the main focus of the project
managers and stake holders. Meetings with managers, stake holders and users are held in
order to determine the requirements. Who is going to use the system? How will they use the
system? What data should be input into the system? What data should be output by the
system? These are general questions that get answered during a requirements gathering
phase. This produces a nice big list of functionality that the system should provide, which
describes functions the system should perform, business logic that processes data, what data
is stored and used by the system, and how the user interface should work. The overall result
is the system as a whole and how it performs, not how it is actually going to do it.
Design
The software system design is produced from the results of the requirements phase.
Architects have the ball in their court during this phase and this is the phase in which their
focus lies. This is where the details on how the system will work is produced. Architecture,
including hardware and software, communication, software design (UML is produced here) are
all part of the deliverables of a design phase.
Implementation
Code is produced from the deliverables of the design phase during implementation, and this is
the longest phase of the software development life cycle. For a developer, this is the main
focus of the life cycle because this is where the code is produced. Implementation my overlap
with both the design and testing phases. Many tools exists (CASE tools) to actually automate
the production of code using information gathered and produced during the design phase.
Testing
During testing, the implementation is tested against the requirements to make sure that the
product is actually solving the needs addressed and gathered during the requirements phase.
Unit tests and system/acceptance tests are done during this phase. Unit tests act on a
specific component of the system, while system tests act on the system as a whole.
So in a nutshell, that is a very basic overview of the general software development life cycle
model. Now lets delve into some of the traditional and widely used variations.
Waterfall Model
This is the most common and classic of life cycle models, also referred to as a linear-
sequential life cycle model. It is very simple to understand and use. In a waterfall model,
each phase must be completed in its entirety before the next phase can begin. At the end of
each phase, a review takes place to determine if the project is on the right path and whether

or not to continue or discard the project. Unlike what I mentioned in the general model,
phases do not overlap in a waterfall model.
Waterfall Life Cycle Model
Advantages
• Simple and easy to use.

• Easy to manage due to the rigidity of the model – each phase has specific deliverables
and a review process.
• Phases are processed and completed one at a time.
• Works well for smaller projects where requirements are very well understood.
Disadvantages
• Adjusting scope during the life cycle can kill a project

• No working software is produced until late during the life cycle.
• High amounts of risk and uncertainty.
• Poor model for complex and object-oriented projects.
• Poor model for long and ongoing projects.
• Poor model where requirements are at a moderate to high risk of changing.
V-Shaped Model
Just like the waterfall model, the V-Shaped life cycle is a sequential path of execution of
processes. Each phase must be completed before the next phase begins. Testing is
emphasized in this model more so than the waterfall model though. The testing procedures
are developed early in the life cycle before any coding is done, during each of the phases
preceding implementation.
Requirements begin the life cycle model just like the waterfall model. Before development is
started, a system test plan is created. The test plan focuses on meeting the functionality
specified in the requirements gathering.

The high-level design phase focuses on system architecture and design. An integration test
plan is created in this phase as well in order to test the pieces of the software systems ability
to work together.
The low-level design phase is where the actual software components are designed, and unit
tests are created in this phase as well.
The implementation phase is, again, where all coding takes place. Once coding is complete,
the path of execution continues up the right side of the V where the test plans developed
earlier are now put to use.
V-Shaped Life Cycle Model
Advantages
• Simple and easy to use.

• Each phase has specific deliverables.
• Higher chance of success over the waterfall model due to the development of test
plans early on during the life cycle.
• Works well for small projects where requirements are easily understood.
Disadvantages
• Very rigid, like the waterfall model.

• Little flexibility and adjusting scope is difficult and expensive.
• Software is developed during the implementation phase, so no early prototypes of the
software are produced.
• Model doesn’t provide a clear path for problems found during testing phases.
Incremental Model
The incremental model is an intuitive approach to the waterfall model. Multiple development
cycles take place here, making the life cycle a “multi-waterfall” cycle. Cycles are divided up
into smaller, more easily managed iterations. Each iteration passes through the
requirements, design, implementation and testing phases.

A working version of software is produced during the first iteration, so you have working
software early on during the software life cycle. Subsequent iterations build on the initial
software produced during the first iteration.
Incremental Life Cycle Model
Advantages
• Generates working software quickly and early during the software life cycle.
• More flexible – less costly to change scope and requirements.
• Easier to test and debug during a smaller iteration.
• Easier to manage risk because risky pieces are identified and handled during its
iteration.
• Each iteration is an easily managed milestone.
Disadvantages
• Each phase of an iteration is rigid and do not overlap each other.

• Problems may arise pertaining to system architecture because not all requirements are
gathered up front for the entire software life cycle.
Spiral Model
The spiral model is similar to the incremental model, with more emphases 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 are
gathered and risk is assessed. Each subsequent spirals builds on the baseline spiral.
Requirements are gathered during the planning phase. 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.
Software is produced in the engineering phase, along with testing at the end of the phase.
The evaluation phase allows the customer to evaluate the output of the project to date before
the project continues to the next spiral.
In the spiral model, the angular component represents progress, and the radius of the spiral
represents cost.

Spiral Life Cycle Model
Advantages
• High amount of risk analysis

• Good for large and mission-critical projects.
• Software is produced early in the software life cycle.
Disadvantages
• 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.
And that’s it. If you have any input, especially your views on advantages and disadvantages
of any particular model, feel free to leave them in the comments and I can add them to my
copy.

Introduction
This purpose of this paper is to give the CISSP student an understanding of the Software
Development Lifecycle (SDLC) models available to software developers. The student will also
see examples of where each model is most appropriate for various types of software
development projects. The models covered are the ones most likely to be included in CISSP
exam questions.
Note that the SDLC acronym is also used to represent System Development Life Cycle. In
many cases, a decision is made to purchase or outsource the software and associated
hardware and network systems needed to implement a new application. This is often referred
to as the "buy or build" decision. This paper focuses on the Software Development Life Cycle
models, but most of the phases, terms, and issues discussed apply to both the "buy" and
"build" process.
SDLC Models
To help understand and implement the SDLC phases (Project Initiation, Design Analysis,
System Design Specification, Programming and Testing, Installation and Maintenance, and
Destruction), various SDLC models have been created by software development experts,
universities, and standards organizations. New SDLC models are introduced on a regular basis
as new technology and new research (and sometimes new fads) requires new SDLC
techniques. Recent new SDLC models include Extreme Programming and Agile Development.
This paper looks at the most commonly known and used models and describes situations
where the model is an appropriate choice.
Waterfall Model
The Waterfall Model is the oldest and most well-known SDLC model. The distinctive feature of
the Waterfall model is its sequential step-by-step process from requirements analysis to
maintenance.
The major weakness of the Waterfall Model is that after project requirements are gathered in
the first phase, there is no formal way to make changes to the project as requirements
change or more information becomes available to the project team. Because requirements
almost always change during long development cycles, often the product that is implemented
at the end of the process is obsolete as it goes into production. The Waterfall Model is a poor
choice for software development projects where requirements are not well-known or
understood by the development team. It might not a good model for complex projects or
projects that take more than a few months to complete. Think about doing a home
improvement project (such as new hardwood floors) for the first time and only being allowed
to go the hardware store one time. The risk the project will fail is high.
What are good candidate software development projects for the Waterfall Model? Systems
that have well-defined and understood requirements are a good fit for the Waterfall Model.
For instance, a military system aiming an artillery shell is a system with a single, simple
requirement; put the shell on the target. This also assumes that the developers have worked
on similar systems in the past and are experts in the application domain (artillery fire control
systems). To follow the home improvement example, after a visit to a home to get
specifications, an experience flooring contractor could install new hardwood floors with only
one trip to the hardware store. In this case, the risk of project failure is low.

Spiral Model
In response to the weaknesses and failures of the Waterfall SDLC Model, many new models
were developed that add some form of iteration to the software development process. In the
Spiral SDLC Model, the development team starts with a small set of requirements and goes
through each development phase (except Installation and Maintenance) for those set of
requirements. Based on lesson learned from the initial iteration (via a risk analysis process),
the development team adds functionality for additional requirements in ever-increasing
"spirals" until the application is ready for the Installation and Maintenance phase (production).
Each of the iterations prior to the production version is a prototype of the application.
The advantage of the Spiral Model over the Waterfall Model is that the iterative approach
allows development to begin even when all the system requirements are not known or
understood by the development team. As each prototype is tested, user feedback is used to
make sure the project is on track. The risk analysis step provides a formal method to ensure
the project stays on track even if requirements do change. If new techniques or business
requirements make the project unnecessary, it can be canceled before too many resources
are wasted. In today's business environment, the Spiral Model (or its other iterative model
cousins) is the most used SDLC model. An example application development project that
would a good candidate for the Spiral Model is an online customer support system where it is
not well-understood what services customers want or can accomplish online. Each iterative
prototype helps answer the question, "Can and will customers use this system?" The Spiral
Model also lets the development team build application domain experience with every
iteration. In the home improvement project example, it would be like starting the hardwood
flooring project in the upstairs hall to get experience with the flooring process in a low-risk
area before moving to living areas where a mistake would be costly.
The Spiral Model combines elements of the Top-down and Bottom-up SDLC models that are
discussed in the next sections.
Top-Down Model
The Top-down SDLC model was popularized by IBM in the 1970s, and its concepts are used in
other SDLC models such as the Waterfall and Spiral Models previously discussed. In a pure
Top-down model, high-level requirements are documented, and programs are built to meet
these requirements. Then, the next level is designed and built. A good way to picture the Top-
down model is to think of a menu-driven application. The top level menu items would be
designed and coded, and then each sublevel would be added after the top level was finished.
Each menu item represents a subsystem of the total application.
The Top-down model is a good fit when the application is a new one and there is no existing
functionality that can be incorporated into the new system. A major problem with the Top-
down model is that real system functionality is not added and cannot be tested until late in
the development process. If problems are not detected early in the project, they can be costly
to remedy later.
Bottom-Up Model
In the Bottom-up SDLC model, the lowest level of functionality is designed and programmed
first, and finally all the pieces are integrated together into the finished application. This means
that, generally, the most complex components are developed and tested first. The idea is that
any project show-stoppers will surface early in the project. The Bottom-up model also

encourages the development and use of reusable software components that can be used
multiple times across many software development projects. Again, think of a menu driven
system where the development starts with the lowest level menu items.
The disadvantage of the Bottom-up model is that an extreme amount of coordination is

required to be sure that the individual software components work together correctly in the
finished system. Few systems are developed purely from the Bottom-up model.
Hybrid Model
The Hybrid SDLC model combines the top-down and bottom-up models. Using the menu
driven application example, the design team primarily works top down, but the development
team identifies two types of lower level components to work on at the same time as the high-
level components. The first type of low-level component would be existing software modules
from other projects that can be reused in the new project. The other type of low-level
component that would be developed early in the project would be software components with a
high risk of failure. This approach allows the development team to make changes to the
system early in the project if problems occur with the high-risk components. A new data
access technique the team has not used before or a component that might require high
amounts of CPU processing time is an example of a high-risk low-level component.
In reality, many of the SDLC models are a variation of the Hybrid Model. The Spiral Model is
an example discussed previously.
Rapid Prototyping
With the demand for faster software development, and because of many well-documented
failures of traditional SDLC models, Rapid Application Development (RAD) was introduced as a
better way to add functionality to an application. The main new tenant of RAD compared to
older SDLC models is the use of prototypes. After a quick requirements gathering phase, a
prototype application is built and presented to the application users. Feedback from the user
provides a loop to improve or add functionality to the application. Early RAD models did not
involve the use of real data in the prototype, but new RAD implementations do use real data.
The advantage of Rapid Prototyping Models is that time-to-market is greatly reduced. Rapid
Prototyping skips many of the steps in traditional SDLC models in favor of fast and low-cost
software development. The idea is that application software is a "throw-away." If a new
version of the software is needed, it is developed from scratch using the newest RAD
techniques and tools.
The big disadvantage of the Rapid Prototyping Model is that the process can be to fast, and,
therefore, proper testing (especially security testing) may not be done.
The Rapid Prototyping Model is used for graphical user interface (GUI) applications such as
web-based applications. Extreme Programming (XP) is a modern incarnation of the Rapid
Prototyping Model.
Object-Oriented Model
Object-oriented programming became popular 1990s with the increased use of Smalltalk, C+
+, and other new object-oriented programming languages. To take full advantage of object-

oriented features (i.e. classes, inheritance, methods), the Object-oriented SDLC model was
developed.
An important feature of Object-oriented (OO) systems is that software objects represent real-
world objects. Objects are derived from Classes, and a class hierarchy allows objects to
inherit characteristics from parent classes. This allows software object reuse, less coding,
encapsulation of functionality, and many other advantages. A major problem that arose with
OO programming is that if the Class hierarchy is not properly designed, all the OO advantages
disappear. The object-oriented model attempts to properly define and document the Class
hierarchy from which all the system objects are created and object interactions are defined.
For example, in an accounts payable system for GIAC Bikes, GIAC Bikes is an Object. Spacely
Space Sprockets is another Object (of class Supplier). Supplier is a Relationship between
GIAC Bikes and Spacely Space Sprockets. A Supplier Class has Attributes such as Name,
Address, and so on. The Relationship itself may be considered as an Object, having Attributes
like Prime Supplier, and so forth. A Supplier Method may be Pay, Drop, Request Refund, and
such.
Defining all the application Classes, Methods, Relationships, and Properties is very difficult.
The object-oriented SDLC model provides the development team the tools to accomplish this
task.
The object-oriented SDLC model has these phases that roughly correspond to the traditional
SDLC phases noted in brackets:
1. Object-Oriented Requirements Analysis (OORA) [Design Analysis]: This is where

classes of objects and the interaction between them are defined.
2. Object-Oriented Analysis (OOA) [Design Analysis]: In terms of object-oriented
concepts, understanding, and modeling a particular problem within a problem domain.
3. Object-Oriented Design (OOD) [System Design Specification]: The object is the basic
unit of modularity; objects are instantiations of a class.
4. Object-Oriented Programming (OOP) [Programming and Testing]: Emphasizes the
employment of objects and methods rather than types or transformations, as in other
programming approaches.
The Object-oriented SDLC model is characterized by its attempt to model real-world entities
(such as company, account, employee) into abstract computer software objects and all the
interactions that can take place between those objects.
Other Models
Other SDLC models include Model Driven Development, Chaos Model, Agile Programming
Model, and many others. One significant trend in the development of new SDLC models is the
integration of software design tools into the programming environment (such as Microsoft
Visual Studio, IBM Rational Rose). The design team develops a graphical model of the system,
and the tool automatically creates a running application.
Summary
SDLC models are tools that allow the development team to correctly follow the SDLC steps to
create software that meets a business need. The SDLC models have evolved as new

technology and new research have addressed weaknesses of older models. Ideas have been
borrowed and adapted between the various models. The CISSP student should recognize the
main SDLC model families of sequential (Waterfall), iterative (Spiral), rapid prototyping
(RAD), and object-oriented. The student should recognize the characteristics of top-down and
bottom-up development.
It is the responsibility of the CISSP to make sure development teams follows an SDLC model
so that proper confidentiality, integrity, and availability controls are designed and built into
the software application throughout the software life cycle.
The Distributed Agile Model

Since proponents of Agile processes prefer face-to-face conversation as the means for
communication within a development team, in the “distributed Agile model” – in which
members of an Agile team are situated in more than one workplace -- this may seem unlikely.
But Agile processes are not rule-bound; rather, they optimize for methods and dynamics by
which organizations are able to build, maintain, and apply systems of knowledge within
changeful, context-dependent, collaborative work situations.
So when we evaluate the viability of distributed Agile (DA), our concern is not whether it
complies with a particular definition of Agile, but whether it can support iterative, incremental,
and sustainable development; promote teamwork; promote self-management; adapt readily
to emergent changed requirements; and increase customer participation in the development
process. Based on my experience I would say DA is, in this sense, viable. But special
measures must be taken, especially in the area of communication. I will briefly describe those
measures in this paper.
First, though, it may be helpful to state some background. We worked with organizations
who, following their companies’ recommendation or mandate, had adopted Agile project
management, but also wanted to outsource their testing. We worked with start-ups who were
committed to Agile models for development and wanted to outsource within that model
because they had seen such extraordinary improvements in productivity and code stability.
We also worked with companies who were trying out whatever they thought might work
better than the cause of their current headache. I wish I could say that, for developing a
website using AJAX, for example, you do or you do not want to attempt DA. Or that if you are
working on the first release of a new product, you should stick to single-sited Agile. In fact
there is very little correlation between the type of project and the success or failure of DA.
Failure is almost certain, however, if team members do not understand that Agile is not about
freedom from documentation, or freedom from process (although it very well may be free
from these), but is about producing working software at short intervals using iterative
processes that adapt to emergent conditions without losing their purpose.
Some varieties of testing are a very good fit for DA, such as running full regression suites on
the most recent known-good build, performance testing, automation development, and end-
to-end testing. The home group (that is, the group that owns contact with company

management) works side-by-side with the developers, perhaps reviewing acceptance tests
and designing test cases that expand upon tests developed in test-driven development, and
the remote group covers non-functional testing.
One of the best fits for DA has been a sort of cluster of remote Scrums, where the home
group drives development of the core engine, while a remote group is spawned whenever an
adapter or significant new feature is required -- each remote group communicating closely
with one member of the home group who attends daily standups etc. I don’t recommend
trying this without doing due diligence; but it is useful to know that DA does work in a variety
of situations.
Here are a number of practices; I would not want to call them “best practices” because I am
certain they can be improved upon. Their strongest recommendation is that they have
consistently worked in a variety of projects deployed in a DA model.
Making Distributed Agile Work for you
 Keep an inclusive test plan Even in straightforward Scrum, a backlog or schedule or

even a set of cards on the wall reminds everyone what tasks the team owns, i.e. must
accomplish in the current sprint (or series of sprints). This is of even greater
importance for DA; if there are multiple remote groups, while the “Scrum of Scrums”
structure is useful, it is not sufficient – the remote group will need something to refer
to in case the home group is unavailable.
 Keep the customer engaged with both remote and home groups throughout
the project The temptation is to maintain contact with the remote group only, but
that would damage the remote group’s sense of belonging to a team, which is the
basis for communication. The customer should at least participate in conference calls.
 Coordinate by “Scrum of Scrums” Represent each remote group in home group
through participation by one home group member who is in daily telephone contact (if
personal contact is impossible) with the remote group. Participation of remote groups
by conference call alone provides much weaker linkage.
 Exchange remote and home group members within the team Ideally, remote
group members visit the home group for several days, and home group members visit
remote groups. Even if only one person from the home group visits a remote group for
a week or two, all members of both groups will tend to bond. This is especially useful if
the two groups are from markedly disparate cultures.
 Communication protocol Since decisions regarding adoption of communication and
reporting protocols have a much greater impact in DA than in single-site Agile, they
should be discussed as part of pre-sprint planning, and any required hardware or
software resources obtained well in advance of sprint kick-off.
 Defect management For large-scale projects using multiple Agile teams, while each
team tracks defects and their resolution during the sprint using a backlog or
programmatic equivalent (e.g. Rally), at the end of the sprint all fixed, resolved and

unresolved bugs should be moved into a defect database (e.g. Bugzilla) that tracks all
bugs across the project/product so that there are no loose ends. For example, from
the remote group handling regressions; and so that trending can be identified across
multiple groups and teams. While it is tempting for the remote group to enter all bugs
into the master defect database during the sprint, that defeats the task-based focus of
Agile.
 Staff assessment Since every project has different resource needs, ensure that team
members have the needed skill-sets and experience. The team that put together
version 1.0 may not have what is needed for the features planned for 1.1. Somehow
remote groups are especially prone to issues of “inheritance”, where resource
qualifications are not re-assessed on a sprint-by-sprint basis.
 Trust and feedback Because DA reduces communication bandwidth,
misunderstandings are rampant. Trust is critical to success. Trust enables the
exchange of constructive feedback and criticism. Establishing common non-work
interests helps a lot. The best social glue I have seen was when members of both the
home and remote groups followed World Soccer championships.
 Access to resources Give everyone equal access to the same resources. Wikis are
helpful because their topic hierarchy can be changed on the fly,links can be shared
instantly, etc.
 Avoiding process inheritance Because more process is required by DA to keep
home and remote groups in synch, processes are likely to be carried over from one
project to another. They will lose their “appropriate process for the project” attributes,
adding unnecessary baggage. While keeping everyone on the same page, it doesn’t
hurt to maintain a healthy skepticism for all process, verifying its need before adopting
it.
 Documenting test results Although working code is an indicator of some degree of
accomplishment, it is never a replacement for documentation necessary to record what
tests have been completed, such as non-functional testing by the remote group in
areas like security and compliance.
 Looping business analysts in to specify documentation Agile has a tendency to
reduce documentation to zero. Do not assume that the Agile team manager or the
team itself are capable of deciding how much documentation is required -- bring
business stakeholders into the pre-sprint discussion.
If a team realizes benefits in cost and quality while using Agile, it should not assume that
every aspect of Agile is responsible for its success. The key may be iterations alone, as
seemed to be the case in NASA’s Project Mercury. Success may have been due merely to
keeping management out of the picture while coding.
DA requires a little more coordination, regulation, and scheduling -- in other words a little
more discipline. Unless an Agile team is composed entirely of bright, experienced, self-

managing, team-supporting multiple-domain experts, you’ll need some degree of discipline

even if everyone sits around the same table for the entire sprint. DA is the same; but more
so.
ii. Agile software development is a conceptual framework for software engineering that
promotes development iterations throughout the life-cycle of the project.
There are many agile development methods; most minimize risk by developing software in
short amounts of time. Software developed during one unit of time is referred to as an
iteration, which may last from one to four weeks. Each iteration is an entire software project:
including planning, requirements analysis, design, coding, testing, and documentation. An
iteration may not add enough functionality to warrant releasing the product to market but the
goal is to have an available release (without bugs) at the end of each iteration. At the end of
each iteration, the team re-evaluates project priorities.
Agile methods emphasize face-to-face communication over written documents. Most agile
teams are located in a single open office sometimes referred to as a bullpen. At a minimum,
this includes programmers and their "customers" (customers define the product; they may be
product managers, business analysts, or the clients). The office may include testers,
interaction designers, technical writers, and managers.
Agile methods also emphasize working software as the primary measure of progress.
Combined with the preference for face-to-face communication, agile methods produce very
little written documentation relative to other methods. This has resulted in criticism of agile
methods as being undisciplined.

Manual SDLC Models I

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Manual SDLC Models I

Uploaded by

Copyright:

Available Formats

G.C.Reddy (09247837478) gcrindia@gmail.

Chapter I Software Development Life Cycle Models

Software: The instructions executed by a computer, as opposed to the physical device on

G.c.Reddy- Knowledge Doc: GC 001 1

System Programming Application

Operating Systems, Text Editors Banking Application

Software Application Software Product

Banking software MS Windows, MS Office,

I. Software Bidding: A Proposal to develop new software is called Software Bidding.

G.c.Reddy- Knowledge Doc: GC 001 2

In Product development, Organization takes their own proposal.

Software engineering: (SE) A systematic approach to the analysis, design, implementation

Software Development Phases

Analysis and Planning

Designing the software

Release & Maintenance

1. ISO 9000 - "Degree to which a set of inherent characteristic fulfills requirements"

G.c.Reddy- Knowledge Doc: GC 001 3

Software Quality Assurance:

Software Quality Control:

Software Development Life Cycle Models

The waterfall model

G.c.Reddy- Knowledge Doc: GC 001 4

The model consists of six distinct stages, namely:

1. In the requirements analysis phase

(b) The constraints are identified

G.c.Reddy- Knowledge Doc: GC 001 5

 Algorithmic detail and

G.c.Reddy- Knowledge Doc: GC 001 6

 Meet the changing customer needs

 Adapted to accommodate changes in the external environment

 Correct errors and oversights previously undetected in the testing phases

 Enhancing the efficiency of the software

 Testing is inherent to every phase of the waterfall model

 It is an enforced disciplined approach

 It is documentation driven, that is, documentation is produced at every stage

 It only incorporates iteration indirectly, thus changes may cause considerable

The Spiral Model

G.c.Reddy- Knowledge Doc: GC 001 7

These regions are:

1. The customer communication task – to establish effective communication between

4. The engineering task – to build one or more representations of the application.

G.c.Reddy- Knowledge Doc: GC 001 8

Advantages of the Spiral Model

• The spiral model is a realistic approach to the development of large-scale software

Disadvantages of the Spiral Model

G.c.Reddy- Knowledge Doc: GC 001 9

 Demands considerable risk-assessment expertise

The ‘V’ Model:

V stands for Verification and validation.

G.c.Reddy- Knowledge Doc: GC 001 10

Software Development Life Cycle Models

The General Model

General Life Cycle Model

G.c.Reddy- Knowledge Doc: GC 001 11

G.c.Reddy- Knowledge Doc: GC 001 12

Waterfall Life Cycle Model

• Simple and easy to use.

• Adjusting scope during the life cycle can kill a project

G.c.Reddy- Knowledge Doc: GC 001 13

V-Shaped Life Cycle Model

• Simple and easy to use.

• Very rigid, like the waterfall model.