UNIT 1
1. Introduction
2. software life-cycle models
3. software requirements specification
4. formal requirements specification
5. verification and validation.
SOFTWARE
Software is a set of items or objects that form a “configuration” that includes
• programs • documents • data ...
Characteristics
• software is engineered
• software doesn’t wear out
• software is complex
• software is like an ‘aging factory
Evolution of Software
1950s ~ mid 1960s (The early years)
Batch Orientation, Limited distribution,
1960s mid ~ 1970s mid (The second era)
Multiuser, Real-time, Database, Product SW
1970s mid 1980s late (The third era)
Distributed systems, Embedded ‘intelligence’
Low cost hardware, Consumer impact
1980s late ~2000s (The fourth era)
Powerful desk-top systems, object-oriented technique ,
Artificial neural networks Parallel computing, Network computers
Software Applications
system software
real-time software
business software
engineering/scientific software
embedded software
PC software
AI software
Web-based Software(web applications)
Process as problem solving
problem
definition
status technical
quo development
solution
integration
SOFTWARE ENGINEERING
A Layered Technology
tools
methods
process model
a “quality ” focus
Activities
• Software project management
• Formal technical reviews
• Software quality assurance
• Software configuration management
• Document preparation and production
• Reusability management
• Measurement
• Risk management
software life-cycle models
The Linear Sequential Model
The Prototyping Model
The RAD Model
Evolutionary Software Process Models
The Incremental Model
Spiral) Model
Concurrent Development Model
Component-Based Development
Scope and necessity of software engineering
A small program can be written without using software engineering principles. But if
one wants to develop a large software product, then software engineering principles
are indispensable to achieve a good quality software cost effectively
Eg. a small wall and a multi storied building
Without using software engineering principles it would be difficult to develop large
programs.
For example, a program of size 1,000 lines of code has some complexity. But a
program with 10,000 LOC is not just 10 times more difficult to develop, but may as
well turn out to be 100 times more difficult unless software engineering principles are
used. In such situations software engineering techniques come to rescue. Software
engineering helps to reduce the programming complexity. Software engineering
principles use two important techniques to reduce problem complexity:
abstraction and decomposition.
The principle of abstraction implies that a
problem can be simplified by omitting
irrelevant details.
Decomposition technique, is a complex
problem is divided into several smaller
problems and then the smaller problems are
solved one by one
Program vs. software product
Programs are developed by individuals for their personal use. They are therefore, small
in size and have limited functionality but software products are extremely large.
In case of a program, the programmer himself is the sole user but on the other hand, in
case of a software product, most users are not involved with the development. In case
of a program, a single developer is involved but in case of a software product, a large
number of developers are involved.
For a program, the user interface may not be very important, because the programmer
is the sole user. On the other hand, for a software product, user interface must be
carefully designed and implemented because developers of that product and users of
that product are totally different.
In case of a program, very little documentation is expected, but a software product
must be well documented. A program can be developed according to the programmer’s
individual style of development, but a software product must be developed using the
accepted software engineering principles.
Life cycle model
A software life cycle model (also called process model) is
a descriptive and diagrammatic representation of the
software life cycle.
A life cycle model represents all the activities required to
make a software product transit through its life cycle
phases. It also captures the order in which these activities
are to be undertaken. no matter which life cycle model is
followed, the basic activities are included in all life
cycle models though the activities may be carried out in
different orders in different life cycle models.
Need for a software life cycle model
The development team must identify a suitable life cycle model for the
particular project and then adhere to it. Without using of a particular life
cycle model the development of a software product would not be in a
systematic and disciplined manner.
When a software product is being developed by a team there must be a clear
understanding among team members about when and what to do.
Otherwise it would lead to chaos and project failure.
A software life cycle model defines entry and exit criteria for every
phase. A phase can start only if its phase-entry criteria have been satisfied.
So without software life cycle model the entry and exit criteria for a phase
cannot be recognized.
Different software life cycle models
Many life cycle models have been proposed so far. Each of them has
some advantages as well as some disadvantages
WA T E R F A L L L I F E C Y C L E MOD E L
Introduced by Royce 1970. The Waterfall life cycle model, also known
as the classic or linear-sequential life cycle model, is one of the simplest
to understand and use. The Waterfall model is characterized by a series
of steps that must be completed in a linear, sequential order. Each
phase is completed and verified before development progresses to the
next phase
Advantages of the Waterfall model
As a formalized approach to software development, the Waterfall model is simple
and easy to use. This model can be easy to implement and manage because each
phase has a specific purpose, and development occurs in only one phase at a time.
The Waterfall model is appropriate for small development projects in which the
requirements are well understood.
Disadvantages of the Waterfall model
Due to the rigidity of the model, all requirements must be stated explicitly
before development begins. It should not be used for developing object-
oriented software, for long-term or ongoing projects, or for projects in which
requirements are unknown or subject to change.
Prototype Model
A prototype is a toy implementation of the
system. A prototype usually exhibits limited
functional capabilities, low reliability, and
inefficient performance compared to the actual
software. A prototype is usually built using
several shortcuts. The shortcuts might involve
using inefficient, inaccurate, or dummy
functions.
◊ Repeated (iterated) processes
◊ For each iteration
• Add a (possibly small) subset of requirements
• Analyze the requirements, design, implement, test (by
developer)
• generally customer must approve before moving to
the next iteration
◊ Repeat until the product is done
Advantages of prototyping models
◊ Important functionalities can be considered separately.
◊ Requirements can be “discovered” at the prompting of an iteration.
◊ Customers & managers feel a sense of progress.
◊ Prototypes are often used to win customer contracts (especially in bidding).
Challenges of Prototyping
◊ Identifying the subset of requirements for the next iteration can be difficult.
◊ Establishing consistency is a repetitive work, particularly when a new subset of
requirements bears no relationships with the existing ones
• Moreover, it is a tedious and time consuming work
◊ The project deadline is difficult to predict.
• No visible end to the set of iterations
• Poses “maintenance” problems
Spiral life cycle model
Sequential(waterfall) n incremental) (radial n angular)
The Spiral life cycle model incorporates risk analysis.
It is divided into four phases: planning, risk analysis,
engineering, and evaluation. A project passes through
each of these phases in sequence, repeatedly, in a
series of iterations called spirals. At the beginning of
the development process, critical requirements are
identified for the first spiral. Subsequent spirals add
functionality to this baseline spiral.
First quadrant (Objective Setting)
• During the first quadrant, it is needed to identify the objectives
of the phase.
• Examine the risks associated with these objectives.
Requirements gathering is performed in the planning phase.
Second Quadrant (Risk Assessment and Reduction)
• A detailed analysis is carried out for each identified project risk.
• Steps are taken to reduce the risks. For example, if there is a
risk that the requirements are inappropriate, a prototype system
may be developed.
Third Quadrant (Development and Validation)
• Software is coded and tested during the engineering phase.
• Develop and validate the next level of the product after
resolving the identified risks.
Fourth Quadrant (Review and Planning)
• Review the results achieved so far with the customer and
plan the next iteration around the spiral. • Progressively more
complete version of the software gets built with each iteration
around the spiral.
Advantages of the Spiral model The focus on risk avoidance makes the
Spiral model ideal for large-scale and mission critical products. At its core,
the Spiral model is built on earlier software development models, and it
borrows from both the Waterfall and Incremental models. Working software
code is developed early; thus, the customer is given many opportunities to
evaluate the software and plenty of time to ease into adoption of the software.
Disadvantages of the Spiral model The Spiral model can cost considerably
more to implement than other life cycle models. The risk analysis phase
requires highly specific expertise, and the project's success depends on the
output of this phase. The Spiral model is inappropriate for use in small and
medium-scale projects that are not mission-critical.
Iterative Waterfall Model
Iterative Waterfall Model is the extension of the Waterfall model.
The iterative waterfall model provides customer’s feedback paths from each
phase to its previous phases.
There is no feedback path provided for feasibility study phase, so if any
change is required in that phase then iterative model doesn’t have scope for
modification or making corrections.
Iterative waterfall allows to go back on the previous phase and change the
requirements and some modification can done if necessary.
This model reduces the developer’s effort and time required to detect and
correct the errors.
In iterative waterfall model, next phase can only begins when the previous
phase is completed as waterfall model.
Advantages of Iterative Waterfall Model :-
Every phase contains feedback path to its previous phase.
This is an simple to make changes or any modifications at any phase.
By using this model, developer can completer project earlier.
Customer involvement is not required during the software
development.
This model is suitable for large and complex projects.
Disadvantages of Iterative Waterfall Model :-
There is no feedback path for feasibility study phase.
This model is not suitable if requirements are not clear.
It can be more costly.
There is no process for risk handling.
Customer can view the final project. there is no prototype for taking customer
reviews.
This model does not work well for short projects.
If modifications are required repeatedly then it can be more complex projects.
V-Model
V- model is also called Verification and Validation model .
This model is the extension of the Waterfall Model.
The V form of the V model shows the various phases of the verification and
validation phases.
This model mainly use for testing phase .
In the waterfall model testers involves in the last phase of the model but this
model overcomes the drawbacks of the waterfall model. In V model ,testers
involves in the early phases of the development process.
Verification:
Verification is the process to verify that the software
product development phase to determine that specified
requirements meet or not ? In this phase, there is no
need to execute the code for testing.
Validation:
Validation is the process to verify that the software
product fulfills the customer requirements and
expectations or not. In this phase, there is
need of execution of the code.
Phases of Verification Stage:
Requirement Analysis : In this phase, developers collects information from customers about the software.
System Design : When the requirements are defined clearly then implement and design the complete hardware and communication
setup for developing product and choose the programming language and databases.
System Architecture : Architectural specifications are designed in this phase. The system design is splits further into modules
taking up different working. This is also called High Level Design (HLD). In this stage, communication and transformation of data
between the internal modules and the outer world is clearly specified.
Module Design : In this phase the system breaks down into small modules. The detailed design of modules is specified, it is also
called the Low-Level Design (LLD).
Implementation/ Coding Phase : This is the last phase of the V-Shape model. Module design is transformed into the code. The
coding is done based on the coding principles and standards in a particular selected programming language.
phases of Validation Stage :
Unit Testing : Unit testing is a type of white box testing .These Unit Test Plans are executed to remove bugs at code level. Unit Test
Plans are created during the module design phase.
Integration Phase : In the integration testing, the integration test cases are executed which were developed in the High level design
phase. Integration testing is a testing process in which unit tested modules are integrated and evaluated. It verifies that the modules
work together as expected or not .
System Testing : System testing is done corresponds with the system design phase. It tests the functional and non-functional
requirements and evaluate the whole system functionality and the communication of the system with external systems.
Acceptance Testing : This testing is done to check that the delivered system meets user’s requirement or not? Nonfunctional testing
such as Load, Stress etc. are also done in this phase.
Advantages of V Model :-
1- It works very well for small project according to their requirement .
2- This model is very simple, easy and useful.
3- This is a high quality model and all the phases are completed at once.
4- This model is use to track the process of project management .
5- This model saves time and efforts.
6- Testing is starting at the initial phase so there is no issue of bugs.
Disadvantages of V Model :-
1- This model can not be use for large project.
2- This model is not good if customer’s requirements are not clear.
3- There are lots of risk.
4- This model is not easy for complex projects .
5- Client have no prototype and involvement during the software development.
6- This model contains less flexibility.
RAD Model
Rapid application development model firstly introduced by IBM in 1980’s.
RAD Model is generally based on the prototype model and iterative approach.
This model is used to completing the process of software product developing in a
very short time.
The entire project is divided into various small modules and each module is allocated
to different party to finish the working of the small modules. After that, all small
modules are combined together to obtain the final project.
If your project can be divided into many parts or modules then the Rapid application
development model is used.
Each module is developed like the waterfall model.
The process of RAD model is building the Rapid prototype and deliver it to the
clients and taking the reviews from them . If customer is satisfied then SRS document
is created and designing phase is start.
Advantages of RAD Model :-
RAD model completes the project in a short period of time.
The progress and development of project can be check on various stages .
This model uses the powerful techniques and tools.
Prototype is delivered to the customer so the customer is satisfied.
It has more flexibility and adaptability to acquire the new requirements.
Reusability of the components is increased.
Disadvantages of RAD Model :-
Team leader must to do work with developers to complete the work on time.
Customer involvement are needed .
This model works only when the requirements are clearly specified.
This model can be more complex if prototype is refined again and again.
RAD model is not suitable for the short projects.
Agile Model
To overcome the limitation of the waterfall model, in the 1990s , the agile model was
introduced.
Agile is the term referred as versatile.
Agile model is the combination of iterative and incremental software development model.
In the agile model, the requirements are break up into many parts, called iterations, and
then developed incrementally.
In this model, each iteration is planned, designed, implemented, tested and deployed to the
customers to take the feedback.
If any changes required then the modification is done at that iteration then carry on the
project.
Any error can be fixed at each iteration so there is no issue about presence of errors in the
project.
Advantages Of Agile Model :
Provides more flexibility.
Agile model provides customer’s satisfaction at each iteration.
No issue of bugs.
Can change or modify the requirement very easily.
It reduces development time of software product.
Disadvantages Of Agile Model :
It takes a long time to complete a project.
Agile model requires too much involvement of customers.
This model does not define end point clearly.
It can be more cost effective.
Developers and testers have to work actively.
This model is difficult to implement.
More risk of maintainability.
The concurrent development model
Concurrent models are those models within which the various activities of
software development happen at the same time, for faster development and a
better outcome.
The concurrent process model activities moving from one state to another state.
The communication activity has completed in the first iteration and exits in the
awaiting changes state.
The modeling activity completed its initial communication and then go to the
underdevelopment state.
If the customer specifies the change in the requirement, then the modeling activity
moves from the under development state into the awaiting change state.
Advantages of the concurrent development model
This model is applicable to all types of software development processes.
It is easy for understanding and use.
It gives immediate feedback from testing.
It provides an accurate picture of the current state of a project.
Disadvantages of the concurrent development model
•It needs better communication between the team members. This may not be
achieved all the time.
•It requires to remember the status of the different activities.
• What is the problem?
• Why is it important to solve the problem?
• What are the possible solutions to the problem?
• What exactly are the data input to the system and what
exactly are the data output by the system?
• What are the likely complexities that might arise while
solving the problem?
• If there are external software or hardware with which the
developed software has to interface, then what exactly
would the data interchange formats with the external
system be?
software requirements specification
A software requirements specification (SRS) is a document that captures complete
description about how the system is expected to perform. It is usually signed off at
the end of requirements engineering phase .
The important parts of SRS document are:
Functional requirements:-
1. A detailed description of all the data inputs and their sources, the
units of measure, and the range of valid inputs be specified:
2. All the operations to be performed on the input data obtain the
output should be specified, and
3. Care must be taken not to specify any algorithms that are not parts of
the system but that may be needed to implement the system.
4. It must clearly state what the system should do if system behaves
abnormally when any invalid input is given or due to some error
during computation.
Performance Requirements (Speed Requirements)
All the requirements related to the performance characteristics of the
system must be clearly specified. Performance requirements are typically
expressed as processed transactions per second or response time from
the system for a user event or screen refresh time or a combination of
these. It is a good idea to pin down performance requirements for the
most used or critical transactions, user events and screens.
Design Constraints
An SRS should identify and specify all such constraints.
Standard Compliance: It specifies the requirements for the standard the system must
follow. The standards may include the report format and according procedures.
Hardware Limitations: The software needs some existing or predetermined hardware to
operate, thus imposing restrictions on the design. Hardware limitations can includes the
types of machines to be used operating system availability memory space etc.
Fault Tolerance: Fault tolerance requirements can place a major constraint on how the
system is to be designed. Fault tolerance requirements often make the system more
complex and expensive, so they should be minimized.
Security: Currently security requirements have become essential and major for all types of
systems. Security requirements place restriction s on the use of certain commands control
access to database, provide different kinds of access, requirements for different people,
require the use of passwords and cryptography techniques, and maintain a log of activities
in the system.
External Interface Requirements
1. All the possible interactions of the software with people, hardware and
other software should be clearly specified,
2. The characteristics of each user interface of the software product
should be specified and
3. The SRS should specify the logical characteristics of each interface
between the software product and the hardware components for
hardware interfacing.
Types of Requirements:
Qualities of SRS:
Concise. The SRS document should be concise and at the same time
unambiguous, consistent, and complete. Verbose and irrelevant descriptions
reduce readability and also increase error possibilities.
Structured. It should be well-structured. A well-structured document is easy to
understand and modify. In practice, the SRS document undergoes several
revisions to cope up with the customer requirements. Often, the customer
requirements evolve over a period of time. Therefore, in order to make the
modifications to the SRS document easy, it is important to make the document
well-structured.
Black-box view. It should only specify what the system should do and refrain
from stating how to do these. This means that the SRS document should specify
the external behavior of the system and not discuss the implementation issues.
The SRS document should view the system to be developed as black box, and
should specify the externally visible behavior of the system. For this reason, the
SRS document is also called the black-box specification of a system.
Response to undesired events. It should characterize acceptable
responses to undesired events. These are called system response to
exceptional conditions.
Verifiable. All requirements of the system as documented in the SRS
document should be verifiable. This means that it should be possible to
determine whether or not requirements have been met in an
implementation.
Problems without a SRS document
Without developing the SRS document, the system would not be
implemented according to customer needs.
Software developers would not know whether what they are developing
is what exactly required by the customer.
Without SRS document, it will be very much difficult for the
maintenance engineers to understand the functionality of the system.
It will be very much difficult for user document writers to write the
users’ manuals properly without understanding the SRS document.
Problems with an unstructured specification
• It would be very much difficult to understand that document.
• It would be very much difficult to modify that document.
• Conceptual integrity in that document would not be shown.
• The SRS document might be unambiguous and inconsistent.
