SOFTWARE ENGINEERING

(KDS 063)

Lecture Notes

(Unit-1)(Notes-1)(Introduction)
By
Ms.Pallavi Shukla
U.C.E.R
 Syllabus for 1 Unit

Introduction: Introduction to Software Engineering, Software Components, Software

Characteristics, Software Crisis, Software Engineering Processes, Similarity and Differences from
Conventional Engineering Processes, Software Quality Attributes. Software Development Life Cycle
(SDLC) Models: Water Fall Model, Prototype Model, Spiral Model, Evolutionary Development
Models, Iterative Enhancement Models.

PROGRAM:
It is complete in itself and is generally used only by the author of the program, there is
usually little documentation or other aids to help other people use the program. These
programs are not designed with issues of portability, reliability and usability in mind .

PROGRAMMING SYSTEM PRODUCT:

 It is used largely by people, other than developers of the system.
 Proper interface is provided.
 There is sufficient documentation for help.
 Here portability is a key issue.
 The programming systems product is also called “Industrial Quality Software”

SOFTWARE:
Software is :
 Instructions that when executed provide desired function and performance.
 Data structures that enable the programs to adequately manipulate information.
 Documents that describe the operation and use of the programs.
Or
 IEEE defines software as collection of computer programs , procedures ,rules and
associated documentation and data.
SOFTWARE CHARACTERISTICS:
 1) “Software is developed or engineered , it is not manufactured in the classical
sense”
- Difference after manufacturing Product cannot be modified but after developing
software , it can be easily modified.
 2) “Software does not wear out”.
In this errors are corrected in the early stage after that it maintains that position.
  3) “Most Software is custom built rather than being assembled from existing
components”.
Hardware are assembled from components available in market but software is build
according to the needs of the customer.
TYPES OF SOFTWARE:
 System software
 Business software
 Embedded Software
 Real time Software
 Personal Computer Software
 Artificial Intelligence Software
 Web Based Software
System Software:
They directly interacts with the hardware and does the necessary work relating to
hardware like CPU scheduling , resource sharing and complex data structure handling.
Business Software:
These are application level software developed for specific operations like according
package, payroll package & MIS.
Embedded Software:
Software which is specially dedicated to the particular operation is known as
Embedded software. It uses high level language which is fed in to the ROM and is used
to control products & systems.
Real Time Software :
Software which are dealing with changing environment of the real world event is
called as Real Time software.
Artificial Intelligence Software:
Software packages used for analysis are known as Expert systems or knowledge based
systems. They make use of non numerical algorithms to solve complex problems that
are not amenable to computation.
Personal Computer Software
Word processing, spreadsheets , Computer graphics , Multimedia, entertainment,
Database access , personal & Business financial applications.
Web Based Software

Web pages retrieved by a browser are software that incorporates executable

instructions and data(Hypertext and a variety of visual and Audio formats.)

SOFTWARE COMPONENTS-
 CORRECTNESS –
A Program is said to be functionally correct if it meets the desired specifications.
It can be defines in terms of mathematical expression correlating the two qualities
software and specifications.
 RELIABILTY –
It can be defined as probability that the software will meet the expected level.
 ROBUSTNESS –
If a program performs well even during extraneous conditions i.e they perform well for
which they are not designed.
 PERFORMANCE –
It depends on the efficiency as well as reusability part of the system.
 VERIFIABILTY:
If its properties can be verified easily.
 MAINTAINABILITY –
Maintenance generally accounts for 60% of the total cost of the system.
 REUSUABILTY–
Software components can be reused to form a new software by making certain changes in
the software components.
 PORTABILITY –
It can be defines as a software which can support various environments or platforms ex –
JAVA, UNIX.
 UNDERSTANDABILITY –
It helps the programmer and users in many ways it helps in achieving many of qualities
such as verifiability.
 TIMELINESS:
It is a process related to the quality to deliver a product on time.
 INTERPERABILITY:
It is defined as the ability of a system to co exists and cooperate with other systems.

SOFTWARE ENGINEERING
 It is application of science and mathematics by which the capabilities of computer
equipment are made useful to man via computer programs , procedures and
associated documentation.
 Basic objective of software Engineering is to :
“ develop methods and procedures for software development that can scale
up for large systems and that can be used to consistently produce high quality
Software at low cost and with a small cycle time”
 Three Factors driving the Software Engineering are :
i) Cost ii) Schedule iii) Quality
Cost - Cost of a developing system is the cost of resources used for the system
, in case of software are Manpower , Hardware , software and other support
resources.
Schedule – Relates to cycle time from concept to delivery which should be
small.
Quality – Quality of a software product is known through 3 dimensions
i) Product Operation- deals with Quality factors such as correctness , reliability &
efficiency.
ii) Product transition- deals with factors like portability , Interoperability, Reusability
iii) Product Revision – It is concerned with those aspects related to modification,
maintainability & testability.
SOFTWARE CRISIS-
 Scheduling and costing of a project does not match with the actuals.
 Software is not meeting the current demand for which it should accommodate.
 Quality of software should be good and more user friendly.
 Timely collection of data and analysis is not done correctly
 Due to lack of linking and co ordination between the developer and consumer.
 Quality of software detoriates if the software has not being developed in systematic
& proper manner.
SOFTWARE PROCESS-
  It is set of activities , together with ordering constraints among them such that if the
activities are performed properly and in accordance with the ordering constraints, the
desired result is produced. Desired result is High quality software at low cost.
 The process that deals with the technical and management issues of software
development is called a “software process” it specifies a method of developing
software
 A software project is development project in which a software process is used.
 Software products are the outcomes of a software project.

Software Process

Product Process
engineering Management
Process Process

Software
Project
Development Configuration
Management
Process Management
process
Process

 Development Process: specifies the development and Quality assurance activities

that need to be performed.
 Management Process: specifies how to plan and control these activities are met
 Objective of Software Configuration Management process is to primarily deal with
managing change, so that the cost and Quality objectives are met & the integrity of
the products is not violated despite these changes requests.
CHARACTRISTICS OF SOFTWARE PROCESS
 PREDICTABILTY –
It determines how accurately the outcome of following process in a project can be
predicted before the project is completed. Predictable process is also said to be
under statistical control.
  SUPPORT TESTABILITY AND MAINTAINBILITY:
If we want to reduce the overall cost of software or achieve “ global “ optimality in
terms of cost rather than “ local” optimality in terms of development cost only. The
goal of development should be to reduce the maintenance effort. i.e one of the main
objectives of the development project should be to produce software that is easy to
maintain.
The observation from the data about effort distribution with phases is that testing
consumes the most resources during development.
Underestimating the testing & less knowledge of testing tools effort often causes the
planners to allocate insufficient resources for testing which in turn results in
unreliable software or schedule slippage.
 EARLY DEFECT REMOVAL & DEFECT PREVENTION
Errors occurs throughout the department Process. However, the cost of correcting
errors of different phases is not the same and depends on when the error is detected
and corrected.
The greater the delay in detecting an error after it occurs the more expensive it is to
correct it.
Detecting errors soon after they have introduced is clearly an objective that should be
supported by the process.
However, even better is to provide support for Defect Prevention.
 PROCESS IMPROVEMENT –
Having process improvement as a basic goal of the software process implies that the
software process used is such that it supports its improvement. This requires that
there be means for evaluating the existing process and underestimating the weakness
in the process. And it is always preferable to have a quantifiable evaluation rather than
a subjective evaluation. Hence it is important that the process provides data that can
be used to evaluate the current processes and its weakness. Process improvement is
a fundamental objectives which requires that the software process be a closed loop
process. “The Process must learn from previous experiences & each project done
using the existing process must feed information back into the process itself , which
can then use this information for self improvement”.

SOFTWARE DEVELOPMENT LIFE CYCELE(SDLC) -

 PHASED DEVELOPMENT PROCESS –
Development process consist of various phases , each phase ending with a
defined output.
 The main reason for having a phased process is that it breaks the problem of
developing software into successfully performing set of phases each handling a
different concern of software development.
Any problem solving in software must consists of these activities.

FEASIBILITY STUDY:
 Feasibility Study in Software Engineering is a study to evaluate feasibility of
proposed project or system.
 It is the feasibility analysis or it is a measure of the software product in terms of how
much beneficial product development will be for the organization in a practical point
of view.
 Feasibility study is carried out based on many purposes to analyze whether software
product will be right in terms of development, implantation, contribution of project
to the organization etc.
TYPES OF FEASIBILITY STUDY:

Economical
Technical Operational
Feasibility Legal Feasibility
Feasibility Feasibility

Schedule
FeasibilIty
Technical Feasibility:
 In Technical Feasibility current resources both hardware software along with
required technology are analyzed/assessed to develop project.
 This technical feasibility study gives report whether there exists correct required
resources and technologies which will be used for project development.
 Along with this, feasibility study also analyzes technical skills and capabilities of
technical team, existing technology can be used or not, maintenance and up-
gradation is easy or not for chosen technology etc.
Operational Feasibility:
 In Operational Feasibility degree of providing service to requirements is analyzed
along with how much easy product will be to operate and maintenance after
deployment.
 Along with this other operational scopes are determining usability of product,
Determining suggested solution by software development team is acceptable or not
etc.
Economic Feasibility:
 In Economic Feasibility study cost and benefit of the project is analyzed.
 Means under this feasibility study a detail analysis is carried out what will be cost of
the project for development which includes all required cost for final development
like hardware and software resource required, design and development cost and
operational cost and so on.
 After that it is analyzed whether project will be beneficial in terms of finance for
organization or not.
Legal Feasibility:
 In Legal Feasibility study project is analyzed in legality point of view.
 This includes analyzing barriers of legal implementation of project, data protection
acts or social media laws, project certificate, license, copyright etc.
 Overall it can be said that Legal Feasibility Study is study to know if proposed project
conform legal and ethical requirements.
Schedule Feasibility:
 In Schedule Feasibility Study mainly timelines/deadlines is analyzed for proposed
project which includes how many times teams will take to complete final project
which has a great impact on the organization as purpose of project may fail if it can’t
be completed on time.
REQUIREMENTS ANALYSIS:
 It is done in order to understand the problems that the software system is to solve.

 Emphasis on identifying what is needed from the system.

 Two parties involved in software development

A CLIENT, A DEVELOPER

The developer usually does not understand the client’s problem and client does not understand the
issues involved in software systems.

This causes a communication Gap.

This is to be bridged between Requirement Analysis.

 There are 2 major activities in this phase:

 Problem Understanding

 Requirement Specification

Once the problem is analyzed & the essentials understood the requirements must be specified in the
requirement specification document.

Requirement document (SRS) must satisfy all functional & performance requirements , the formats
of inputs and outputs and all design constraints that exist due to political , economic, environmental
& security reasons.

SOFTWARE DESIGN:
 Purpose is to plan a solution of the problem specified by the requirements documents.

 It is the most critical factor affecting the quality of software. It has major impact on the later
phases such as Testing and Maintenance.

 Output is design document which is similar to a blue print or plan for the solution and is
used later during implementation, testing and maintenance.

 Design Activity is divided into two separate phases

 System Design

 Detailed Design

In system design the focus is on identifying the modules, whereas during design the focus is on
designing the logic for each of the modules.

CODING:
 Goal of coding phase is to translate the design of the system into code in a given
programming language.

 During coding the focus should be on developing programs that are easy to read &
understand.
  Goal of structured programming is to linearize the control flow in the program i.e. program
text should be as a sequence of statements & during execution the statements are executed
in the sequence given in the programming.

TESTING:
 Its basic function is to detect errors in the software

 Goal of testing is to uncover requirement , design & coding errors in the programs.

 UNIT TESTING – In this , a module is tested separately and is often performed by the coder
himself simultaneously along with the coding of the module.

 INTEGRATION TESTING – After Unit Testing the modules are gradually integrated into
subsystems, which are then integrated to eventually form the entire system.

 SYSTEM TESTING – Here the system tested against the system requirements to see if all the
requirements are met and if the system performs as specified by the requirements.

 ACCEPTANCE TESTING – It is performed to demonstrate to the client on the real life data of
the client, the operation of the system.

 Final output of testing phase is the test report & the error report.

LIFE CYCLE MODEL:

 Process model is a descriptive and diagrammatic representation of the software life cycle.

 It 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.

 Life cycle model maps the different activities performed on a software product from its
inception to retirement.

 Different life cycle models may map the basic development activities to phases in different
ways.

 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.

During any life cycle phase, more than one activity may also be carried out

THE 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.

 This problem can be illustrated by using an example.

 Suppose a software development problem is divided into several parts and the parts are
assigned to the team members.

 From then on, suppose the team members are allowed the freedom to develop the parts
assigned to them in whatever way they like.

 It is possible that one member might start writing the code for his part, another might
decide to prepare the test documents first, and some other engineer might begin with the
design phase of the parts assigned to him.

 This would be one of the perfect recipes for 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.

 Without software life cycle models it becomes difficult for software project managers to
monitor the progress of the project.

 Many life cycle models have been proposed so far.

 Each of them has some advantages as well as some disadvantages. A few important and
commonly used life cycle models are as follows:

 Classical Waterfall Mode

 Iterative Waterfall Model

 Prototyping Model

 Evolutionary Model

 Spiral Model
CLASSICAL WATERFALL MODEL:
System
Feasibility

Requirement
Analysis

System
Design

Detailed
Design

Coding

Testing and Installation Operation &

Integration Maintenance

System Feasibility:
 In this, we establish requirements for all system elements and the allocating some
subsets of these needs to software.
 Result of this phase tabulated in feasibility report.
Requirements Analysis – Project Planning:
 In this, we define the needs, requirements , scope etc.
 This is called critical Phase.
 After requirement analysis with rigorous integration with the proposed software end
users the whole project for software development is panned and scheduled.
 End products of this phase are requirements document & Project schedule
System Design:
 In this, the overall design or architecture of system is proposed using the previous
results of phase carried out.
 Product of this stage is System Design Document
Detailed Design:
 In this stage , the programmers code for different modules of the software in the
chosen programming Language.
 Programmers or every module is individually developed overall the backend is same
for every module programmed.
Testing & Integration:
 All the wides for various modules are tested for their aimed working & efficiency.
 After achieving the rate factor results , all the modules are integrated & their again
the integrated system is chosen for testing in wholesome manner.
 End Product is test & integration report
Installation:
 Whole system is installed if any upgradation of software or hardware is needed at
the site, then the required resources are made available.
 Users are given training how to use software & they may also be provided with a
user’s manual.
Operation and Maintenance:
 The stage spans to the whole life of software product developed.
 Routine check is also needed to ensure the proper & efficient monitoring of software
installed at the site.
 If end users face any problem afterwards , it is also looked into the software is
always expected to be maintained upgraded in the further for various changes
occurring in the users environment & also in his needs.
 Maintenance of a typical software product requires much more than the effort
necessary to develop the product itself.
 Many studies carried out in the past confirm this and indicate that the relative effort
of development of a typical software product to its maintenance effort is roughly in
the 40:60 ratios.
 Maintenance involves performing any one or more of the following three kinds of
activities:
· Correcting errors that were not discovered during the product development phase.
This is called corrective maintenance.
· Improving the implementation of the system, and enhancing the functionalities of
the system according to the customer’s requirements. This is called perfective maintenance.
· Porting the software to work in a new environment. For example, porting may be
required to get the software to work on a new computer platform or with a new operating
system. This is called adaptive maintenance.
Shortcomings of the classical waterfall model:
 The classical waterfall model is an idealistic one since it assumes that no
development error is ever committed by the engineers during any of the life cycle
phases.
 However, in practical development environments, the engineers do commit a large
number of errors in almost every phase of the life cycle.
 The source of the defects can be many: oversight, wrong assumptions, use of
inappropriate technology, communication gap among the project engineers, etc.
 These defects usually get detected much later in the life cycle. For example, a design
defect might go unnoticed till we reach the coding or testing phase. Once a defect is
detected, the engineers need to go back to the phase where the defect had occurred
and redo some of the work done during that phase and the subsequent phases to
correct the defect and its effect on the later phases.
 Therefore, in any practical software development work, it is not possible to strictly
follow the classical waterfall model
ADVANTAGES OF WATERFALL MODEL:
 Systematic & Sequential
 It is linear Model
 There is a clear identification of the beginning and end of any stage.
 It involves problem documentation
 It enforces the responsibility of carrying out all the phases in listed order.
LIMITATIONS OF WATERFALL MODEL:
 No changes in the requirement can be after the start of design process.
 For long projects , may be the hardware can become obsolete.
 Providing different versions with limited capabilities is not possible
 There is heavy documentation involved.
 We cannot go back to any previously executed phase
 There is no risk analysis.
 It is very difficult to predict the requirement explicitly for the customer.
WHERE TO USE WATERFALL MODEL-
1. Requirements are clear and fixed that may not change.
2. There are no ambiguous requirements (no confusion).
 3. It is good to use this model when the technology is well understood.
4. The project is short and cast is low.
5. Risk is zero or minimum.

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.

 The shortcut implementation of a function, for example, may produce the desired results by
using a table look-up instead of performing the actual computations.

 A prototype usually turns out to be a very crude version of the actual system

NEED OF PROTOTYPE:
 To illustrate the input data formats, messages, reports, and the interactive dialogues to the
customer.

 This is a valuable mechanism for gaining better understanding of the customer’s needs:

· how the screens might look like

· how the user interface would behave

· how the system would produce outputs

 Another reason for developing a prototype is that it is impossible to get the perfect product
in the first attempt.

 The experience gained in developing the prototype can be used to develop the final product.

 A prototyping model can be used when technical solutions are unclear to the development
team.

 A developed prototype can help engineers to critically examine the technical issues associated
with the product development.

 In such circumstances, a prototype may be the best or the only way to resolve the technical
issues. A prototype of the actual product is preferred in situations such as:

• User requirements are not complete

• Technical issues are not clear

COST CAN BE REDUCED USING PROTOTYPE:

➢ Experience of developing the prototype might reduce the cost if the later phases when the
actual software development is done.

➢ In many projects the requirements are constantly changing particularly when development
takes a long time.

➢ Client and users get experience with the system it is more likely that the requirements
specified after the prototype will be closer to the actual requirements. This will lead to fewer
changes in the requirements at a later time.

➢ TYPES OF PROTOTYPING:

➢ Evolutionary Prototyping

➢ Throwaway Prototyping

EVOLUTIONARY PROTOTYPING:
 It helps in delivering the complete system to user.

 The system design starts with prototype & subsequent modules are developed & integrated
with the prototype which would ultimately result in the complete system even high costs does
not matter because our prototype will form a part of the system.

 It is also an effective method of demonstrated the feasibility of a certain approach.

 The development of the prototype type starts when the preliminarily version of the
requirements specification document has been developed.

 After the prototype has been developed the end users and clients are given an opportunity to
use the prototype.

 Based on the feedback , the initial requirements are modified to produce the final
requirements specification which is then used to develop the production Quality System.
HOW COST CAN BE REDUCED:
 As protype is to be discarded there is no point in implementing those parts of requirements
which are well understood.

 Minimal documentation needs to be produced during prototyping ex design documents , a

test plan, test case specification are not need during prototyping,

 Because testing consumes a major part of developer expenditure during regular software
development we reduce testing.

THROWAWAY PROTOTYPING:
➢ Idea is to discard after the analysis is complete.

➢ This prototyping helps us in validation of the system and in deriving the complete system
requirements.

➢ Cost of prototype is kept to a minimum as when the overall system is developed this prototype
is of no use.

➢ Only minimal documents need to be produced during prototyping.

ADVANTAGES:
 Partial product is built in the initial stages.therefore customers get a chance to see the product
early in life cycle & thus give necessary feedback.

 New requirements can be easily accommodated as there is scope of refinement.

 Requirements become more clear resulting into an accurate products.

 As user is involved from the starting of the project, he tend to be more secure , comfortable
and satisfied.

 Flexibility in design & development is also supported by the model.

DISADVANTAGES:
 After seeing an early prototype end users demand the actual system to be delivered soon.

 End users may not like to know the difference between a prototype and aw well engineered
fully developed system.

 Developers in a hurry to build protypes may end up with sub optimal solutions.

 If not managed properly , the iterative process of prototype demonstration and refinement
can continue for long duration.

 If end users is not satisfied with initial protype , he may loose interest in the project.

 Poor documentation.
ITERATIVE ENHANCEMENT MODEL:
 Known as Momental Enhanced Model.
 Aims at bonding the merits of prototyping and the waterfall model
 Software should be developed in increments, each increment adding some functional
capability to the system until the full system is implemented .

 Project Control List is created that contains all the tasks that must be performed to
obtain the final implementation
 First step is to create a simple initial implementation is done for a subset if overall
problem.
 Each step consists of removing the next task from the list, designing the
implementation for the selected task, coding and testing the implementation.
 The process is iterated until the project control list is empty, at which time the final
implementation of the system, will be available.
 Project control list guides the iteration steps and keeps track of all tasks that must be
done.
 Based on analysis one of the tasks in the list can include redesign of defective
components or redesign of the entire system.
 However, redesign of the system will generally occur only in initial steps.

ADVANTAGES:
 One effective use of this type of model is for product development , in which the developers
themselves provide the specifications & therefore have a lot of control on what specifications
go in the system & what stay out.

 As product is to be delivered in parts total cost of project is distributed,

 Limited number of persons can be put on project because work is to be delivered in parts.
  As development activities for next release & use of early version of product is done
simultaneously , errors if found can be corrected.

 Customers or end users feedback requirements for successive releases become more clear.

 As functionality is incremented in steps, testing also becomes easy.

 Risk of failure of a product is decreased as users start using the product early.

DISADVANTAGES:
 As product is delivered in parts total development cost is higher.

 Well defined interfaces are required to connect modules developed with each phase.

 Model requires well defined project planning schedule to distribute the work properly.

 Testing of modules also results into overhead and increased cost.

 In a customized software development, where the client has to essentially provide and
approve the specification it is not always clear how this process can be applied.

 Another problem is in generating the business control how will the cost of additional features
be determined , negotiated , particularly because the client organization is likely to be tied to
the original vendor who developed the first version.

SPIRAL MODEL:
 Proposed by Bohem.
 The activities in this model can be organized like a spiral that has many cycles.
 Spiral Model is a risk-driven software development process model.
 It is a combination of the waterfall model and the iterative model.
 Radial Dimensions represents the cumulative cost incurred in accomplishing the steps
done so far.
 Angular dimensions represent the progress made in completing each cycle of the
spiral.
MAIN PHASES OF SPIRAL MODEL:
 It has four stages or phases: The planning of objectives, risk analysis, engineering or
development, and finally reviews. A project passes through all these stages
repeatedly and the phases are known as a Spiral in the model.
• Determine Objectives
• Alternatives
• Constraints
• Planning Phase
Region 1 – Determine Objectives –
This phase includes requirement gathering and analysis. Based on the requirements,
objectives are defined and different alternate solutions are proposed. There’s a wide
range of them, from trivial to fatal. The primary task for the development team is to
enumerate all the possible risks and prioritize them according to importance.
Region 2 – Risk Analysis-
In this quadrant, all the proposed solutions are analyzed and any potential risk is
identified, analyzed, and resolved. During the first spiral, when the overall requirements
are not so clear, the so-called Proof of Concept (POF) is created to get the customer’s
feedback.
Region 3 – Develop and verify next level of Product
This phase includes the actual implementation of the different features. All the
implemented features are then verified with thorough testing.
Region 4 Plan Next Phase:
 In this phase, the software is evaluated by the customer. It also includes risk
identification and monitoring like cost overrun or schedule slippage and after that
planning of the next phase is started.
ADVANTAGES:
 This model is a very flexible model and it is highly suited to project development of
our times.
 In this model, very little documentation is generated in compare to waterfall model.
 This particular model lays a lot of stress on Risk Analysis.
 This model efficiently uses prototyping.
LIMITATIONS:
 There are no concrete beginning or end of particular phases.
 We do not get very strict standards for software development
RAD MODEL:
When to use RAD Model?
• When a system needs to be produced in a short span of time (2-3 months)
• When the requirements are known
• When the user will be involved all through the life cycle
• When technical risk is less
• When there is a necessity to create a system that can be modularized in 2-3 months
of time
• When a budget is high enough to afford designers for modeling along with the cost of
automated tools for code generation

RAD MODEL(RAPID APPLICATION DEVELOPMENT):

 It is incremental software development process model.

 It has short development cycle.

 It is high speed adaption of linear sequential model in which rapid development is done with the help
of component based construction.

 In RAD model, there is less attention paid to the planning and more priority is given to the development
tasks. It targets at developing software in a short span of time.

 SDLC RAD modeling has following phases

• Business Modeling

• Data Modeling

• Process Modeling

• Application Generation

• Testing and Turnover

Business Modeling
 Function of this modeling covers following:

 What Information driven the business process?

 What information is generated & who generate it?

 Where does information go?

 Who process it?

Data Modeling
Information flow defined in the above phase is refined into a set of data objects that are needed to
support the business.
Process Modeling:
 Data objects defined in previous phase are transformed to achieve the
information flow necessary to implemented a business function.

Application Generation:
 RAD process works to reuse the existing program components or create reusable
components .
 In this all automated tools are used to facilitate construction of the software.

Testing & Turnover:

 Because of reusability's , many of program components have already been tested.
 This reduces overall testing time.
 But new components must be tested and all interfaces must be fully exercised.

Advantages of RAD Model:

 As customer is involved at all stages of development , it leads to a product achieving customer
satisfaction.

 Usage of powerful development tools results into reduced SDLC.

 Feedback from customer is available at the initial stages.

 Makes use of reusable components to decrease the cycle time.

 Results into reduced costs as less developers are required.

 Flexible and adaptable to changes.

 It is useful when you have to reduce the overall project risk.

 It is adaptable and flexible to changes.

 It is easier to transfer deliverables as scripts, high-level abstractions and intermediate codes are
used.

 Due to code generators and code reuse, there is a reduction of manual coding.

 Due to prototyping in nature, there is a possibility of lesser defects.

 With less people, productivity can be increased in short time.

Disadvantages of RAD Model:
 The model makes use of efficient tools, to develop the prototype quickly , which calls for hiring
skilled properties.

 Team leader must work closely with developers & customers /users to close the perfect in
time.

 Absence of reusable components can lead to feature of project.

 It can’t be used for smaller projects.

 Not all application is compatible with RAD.

 When technical risk is high, it is not suitable.

 If developers are not committed to delivering software on time, RAD projects can fail.

 Reduced features due to time boxing, where features are pushed to a later version to finish a
release in short period.

 Reduced scalability occurs because a RAD developed application begins as a prototype and
evolves into a finished application.

 Requires highly skilled designers or developers.

V MODEL
❑ The V-model is an SDLC model where execution of processes happens in a sequential manner
in a V-shape. It is also known as Verification and Validation model.

❑ The V-Model is an extension of the waterfall model and is based on the association of a testing
phase for each corresponding development stage. This means that for every single phase in
the development cycle, there is a directly associated testing phase. This is a highly-disciplined
model and the next phase starts only after completion of the previous phase.

❑ Under the V-Model, the corresponding testing phase of the development phase is planned in
parallel. So, there are Verification phases on one side of the ‘V’ and Validation phases on the
other side. The Coding Phase joins the two sides of the V-Model.

❑ Verification: It involves static analysis technique (review) done without executing code. It is
the process of evaluation of the product development phase to find whether specified
requirements meet.

❑ Validation: It involves dynamic analysis technique (functional, non-functional), testing done

by executing code. Validation is the process to evaluate the software after the completion of
the development phase to determine whether software meets the customer expectations and
requirements.

 So V-Model contains Verification phases on one side of the Validation phases on the other
side. Verification and Validation phases are joined by coding phase in V-shape. Thus it is called
V-Model.

 Why preferred?
❑ It is easy to manage due to the rigidity of the model.
 ❑ Each phase of V-Model has specific deliverables and a review process.

❑ Proactive defect tracking that is defects are found at early stage.

 When to use?

❑ Where requirements are clearly defined and fixed.

❑ The V-Model is used when ample technical resources are available with technical expertise.

V-Model- Advantages:

❑ This is a highly disciplined model and Phases are completed one at a time.

❑ V-Model is used for small projects where project requirements are clear.

❑ Simple and easy to understand and use.

❑ This model focuses on verification and validation activities early in the life cycle thereby
enhancing the probability of building an error-free and good quality product.

❑ It enables project management to track progress accurately.

V-Model -Disadvantages:
❑ High risk and uncertainty.

❑ It is not a good for complex and object-oriented projects.

❑ It is not suitable for projects where requirements are not clear and contains high risk of
changing.

❑ This model does not support iteration of phases.

❑ It does not easily handle concurrent events.