SE - Unit - 2
SE - Unit - 2
UNIT – II
SOFTWARE DEVELOPMENT LIFE CYCLE
MODEL
In this chapter:
✓ Phases Of Software Project
✓ Quality, Quality Assurance And Quality Control
✓ Testing, Verification And Validation
✓ Process Model To Represent Different Phases
✓ Life Cycle Models
✓ System Engineering
✓ Computer Based Systems
✓ The System Engineering Hierarchy
Quality Assurance (QA) is the set of actions Quality Control (QC) is described as
including facilitation, training, measurement, the processes and methods used to
and analysis needed to provide adequate compare product quality to
confidence that processes are established and requirements and applicable standards,
continuously improved to produce products and the actions are taken when a
or services that conform to specifications and nonconformance is detected.
are fit for use.
QA is an activity that establishes and QC is an activity that demonstrates
calculates the processes that produce the whether or not the product produced
product. If there is no process, there is no role met standards.
for QA.
A software life cycle model (also termed process model) is a pictorial and
diagrammatic representation of the software life cycle.
A life cycle model represents all the methods required to make a software
product transit through its life cycle stages. It also captures the structure in which these
methods are to be undertaken.
In other words, a life cycle model maps the various activities performed on a
software product from its inception to retirement. Different life cycle models may plan
the necessary development activities to phases in different ways.
Thus, no element which life cycle model is followed, the essential activities are
contained in all life cycle models though the action may be carried out in distinct orders
in different life cycle models.
During any life cycle stage, more than one activity may also be carried out.
We will now look at some of the common life cycle models that are used in
software projects.
For each model, we will look at:
1. a brief description of the model;
2. the relationship of the model to verification and validation activities; and
3. typical scenarios where that life cycle model is useful.
WATERFALL MODEL
The waterfall is a universally accepted SDLC model. In this method, the whole
process of software development is divided into various phases.
The waterfall model is a continuous software development model in which
development is seen as flowing steadily downwards (like a waterfall) through the steps
of requirements analysis, design, implementation, testing (validation), integration, and
maintenance.
Linear ordering of activities has some significant consequences.
First, to identify the end of a phase and the beginning of the next, some
certification techniques have to be employed at the end of each step.
Some verification and validation usually do this mean that will ensure that the
output of the stage is consistent with its input (which is the output of the previous step),
and that the output of the stage is consistent with the overall requirements of the system.
ITERATIVE MODEL
In this Model, you can start with some of the software specifications and develop
the first version of the software.
After the first version if there is a need to change the software, then a new version
of the software is created with a new iteration.
Every release of the Iterative Model finishes in an exact and fixed period that is
called iteration.
The Iterative Model allows the accessing earlier phases, in which the variations
made respectively.
The final output of the project renewed at the end of the Software Development
Life Cycle (SDLC) process.
The various phases of Iterative model are as follows:
1. Requirement gathering & analysis: In this phase, requirements are gathered
from customers and check by an analyst whether requirements will fulfil or not. Analyst
checks that need will achieve within budget or not. After all of this, the software team
skips to the next phase.
2. Design: In the design phase, team design the software by the different
diagrams like Data Flow diagram, activity diagram, class diagram, state transition
diagram, etc.
3. Implementation: In the implementation, requirements are written in the
coding language and transformed into computer programmes which are called
Software.
4. Testing: After completing the coding phase, software testing starts using
different test methods. There are many test methods, but the most common are white
box, black box, and grey box test methods.
5. Deployment: After completing all the phases, software is deployed to its work
environment.
6. Review: In this phase, after the product deployment, review phase is
performed to check the behaviour and validity of the developed product. And if there
are any error found then the process starts again from the requirement gathering.
7. Maintenance: In the maintenance phase, after deployment of the software in
the working environment there may be some bugs, some errors or new updates are
required. Maintenance involves debugging and new addition options.
V-MODEL
V-Model also referred to as the Verification and Validation Model. In this, each phase
of SDLC must complete before the next phase starts. It follows a sequential design
process same as the waterfall model. Testing of the device is planned in parallel with a
corresponding stage of development.
Verification: It involves a static analysis method (review) done without executing
code. It is the process of evaluation of the product development process to find whether
specified requirements meet.
Stated in a slightly more formal manner, the world view (WV) is composed of a set of
domains (Di), which can each be a system or system of systems in its own right.
Each domain is composed of specific elements (Ej) each of which serves some role in
accomplishing the objective and goals of the domain or component:
Finally, each element is implemented by specifying the technical components (Ck) that
achieve the necessary function for an element:
1. Assumptions that reduce the number of possible permutations and variations, thus
enabling a model to reflect the problem in a reasonable manner.
As an example, consider a three-dimensional rendering product used by the
entertainment industry to create realistic animation.
One domain of the product enables the representation of 3D human forms. Input
to this domain encompasses the ability to specify movement from a live human actor,
from video, or by the creation of graphical models.
The system engineer makes certain assumptions about the range of allowable
human movement (e.g., legs cannot be wrapped around the torso) so that the range of
inputs and processing can be limited.
3. Limitations that help to bound the system. For example, an aircraft avionics system
is being modeled for a next generation aircraft.
Since the aircraft will be a two-engine design, the monitoring domain for
propulsion will be modeled to accommodate a maximum of two engines and associated
redundant systems.
4. Constraints that will guide the manner in which the model is created and the approach
taken when the model is implemented.
For example, the technology infrastructure for the three-dimensional rendering system
described previously is a single G4-based processor. The computational complexity of
problems must be constrained to fit within the processing bounds imposed by the
processor.
5. Preferences that indicate the preferred architecture for all data, functions, and
technology.
The preferred solution sometimes comes into conflict with other restraining
factors. Yet, customer satisfaction is often predicated on the degree to which the
preferred approach is realized.
The resultant system model (at any view) may call for a completely automated
solution, a semi-automated solution, or a non automated approach.
In fact, it is often possible to characterize models of each type that serve as
alternative solutions to the problem at hand.
In essence, the system engineer simply modifies the relative influence of
different system elements (people, hardware, software) to derive models of each type.
System Simulation