P A NAIDU 1

Module-1:Software Overview
 Software is considered to be collection of executable
programming code, associated libraries and
documentations. Software, when made for a specific
requirement is called software product.
 Engineering on the other hand, is all about developing
products, using well-defined, scientific principles and
methods.

P A NAIDU 2
Software Overview

P A NAIDU 3
Software Engineering Definitions
 IEEE defines software engineering as: The application of
a systematic, disciplined, quantifiable approach to the
development, operation, and maintenance of software;
that is, the application of engineering to software.
 Fritz Bauer, a German computer scientist, defines
software engineering as: “Software engineering is the
establishment and use of sound engineering principles in
order to obtain economically software that is reliable and
work efficiently on real machines.”

P A NAIDU 4
Software Evolution
 The process of developing a software product using
software engineering principles and methods is referred
to as Software Evolution.
 This includes the initial development of software and its
maintenance and updates, till desired software product is
developed, which satisfies the expected requirements.
 Evolution starts from the requirement gathering process.


P A NAIDU 5
Software Evolution Laws
 Lehman has given laws for software evolution. He divided
the software into three different categories:
 Static-type (S-type) - This is a software, which works
strictly according to defined specifications and solutions.
The solution and the method to achieve it, both are
immediately understood before coding. The s-type
software is least subjected to changes hence this is the
simplest of all. For example, calculator program for
mathematical computation.

P A NAIDU 6
Software Evolution Laws
 Practical-type (P-type) - This is a software with a
collection of procedures.This is defined by exactly what
procedures can do. In this software, the specifications can
be described but the solution is not obviously instant. For
example, gaming software.
 Embedded-type (E-type) - This software works closely as
the requirement of real-world environment. This software
has a high degree of evolution as there are various
changes in laws, taxes etc. in the real world situations. For
example, Online trading software.

P A NAIDU 7
Software Paradigms
 Software paradigms refer to the methods and steps,
which are taken while designing the software.

P A NAIDU 8
Software Paradigms
 Software Development Paradigm :It includes various
researches and requirement gathering which helps the
software product to build.
 It consists of –
Requirement gathering
Software design
Programming

P A NAIDU 9
Software Paradigms
 Software Design Paradigm: This paradigm is a part of Software
Development and includes –
Design
Maintenance
Programming
 Programming Paradigm :This paradigm is related closely to
programming aspect of software development.
 This includes –
Coding
Testing
Integration

P A NAIDU 10
Need of Software Engineering

 The need of software engineering arises because of higher rate of

change in user requirements and environment on which the
software is working. Following are some of the needs stated:

 Large software - It is easier to build a wall than a house or building,

likewise, as the size of the software becomes large, engineering has
to step to give it a scientific process.
 Scalability- If the software process were not based on scientific and
engineering concepts, it would be easier to re-create new software
than to scale an existing one.
 Cost- As hardware industry has shown its skills and huge
manufacturing has lower down the price of computer and electronic
hardware. But, cost of the software remains high if proper process is
not adapted.

P A NAIDU 11
Need of Software Engineering
 Dynamic Nature- Always growing and adapting nature of
the software hugely depends upon the environment in
which the user works. If the nature of software is always
changing, new enhancements need to be done in the
existing one. This is where the software engineering plays
a good role.
 Quality Management- Better process of software
development provides better and quality software
product.

P A NAIDU 12
Characteristics of good software
 software must satisfy on the following grounds:
 Operational
 Transitional
 Maintenance

P A NAIDU 13
Characteristics of good software
 Operational :
This tells us how well the software works in operations. It can be
measured on:
 Budget
 Usability
 Efficiency
 Correctness
 Functionality
 Dependability
 Security
 Safety
P A NAIDU 14
Characteristics of good software
 Transitional:
This aspect is important when the software is moved from
one platform to another:
 Portability
 Interoperability
 Reusability
 Adaptability

P A NAIDU 15
Characteristics of good software
 Maintenance :
This aspect briefs about how well the software has the
capabilities to maintain itself in the ever-changing
environment:
 Modularity
 Maintainability
 Flexibility
 Scalability

P A NAIDU 16
Changing Nature of Software
 System software
 Application software
 Engineering/scientific software
 Embedded software
 Product-line software (e.g., inventory control, word
processing, multimedia)
 Web applications
 Artificial intelligence software
 Ubiquitous computing (small, wireless devices)
 Net sourcing (net-wide computing)
 Open source (operating systems, databases, development
environments)

P A NAIDU 17
SYSTEM SOFTWARE
 COLLECTION OF PROFRAMS WRITTEN TO SERVICE OTHER PROGAMS

 HEAVY INTERACTION WITH COMPUTER HARDWARE

 CONTAINS COMPLEX DATA STRUCTURES AND MULTIPLE EXTERNAL

INTERFACES

 CONCURRENT OPERATION THAT REQUIRES SHEDULING

 EXAMPLE:
 COMPILERS , EDITORS
 FILE MANAGEMENT UTILITIES
 OTHER SYSTEM APPLICATIONS
 DRIVERS AND NETWORKING SOFTWARE

P A NAIDU 18
APPLICATION SOFTWARE

 CONSISTS OF STANDALONE PROGRAMS

 USED TO SOLVE SPECIFIC BUSINESS NEEDS
 PROCESS TECHNICAL DATA/TECHNICAL DECISIONS
 CONTROL BUSINESS FUNCTIONS IN REAL TIME

 EXAMPLE:CONVENTIONAL DATA PROCESSING

APPLICATIONS
 REALTIME MANUFACTURING PROCESS CONTROL

P A NAIDU 19
ENGINEERING & SCIENTIFIC S/W

 CHARACTERISED BY CONVENTIONAL NUMERICAL

ALGORITHMS
 INTERACTIVE APPLICATIONS TO TAKE ON REALTIME
 EXAMPLE:COMPUTER AIDED DESIGN(CAD/CAM)
 SYSTEM SIMULATION
 SPACE SHUTTLE ORBITAL DYNAMICS
 MOLECULAR BIOLIOGY TO AUTOMATED MANUFACTURING
 USED IN EDUCATIONAL FIELD FOR CREATING INTERACTIVE
APPLICATIONS

P A NAIDU 20
NET SOURCING

 WWW –A COMPUTING ENGINE & CONTENT PROVIDER

 CHALLENGE OF S/W ENGINEERS IS TO ARCHITECT SIMPLE
 SOPHISTICATED APPLICATIONS THAT PROVIDE BENEFIT TO
TARGET AND END-USER MARKETS WORLDWIDE
 EXAMPLE:PERSONAL FINANCIAL PLANNING

P A NAIDU 21
WEB APPLICATIONS

 SPAN A WIDE ARRAY OF APPLICATIONS

 SET OF LINKED HYPERTEXT FILES
 E-COMMERCE& B2B APPICATIONSGROW IN
IMPORTANCE
 PROVIDE STAND ALONE FEATURES,COMPUTING
FUNCTIONS & CONTENT TO END-USER
 INTEGRATED WITH CORPORATED DATABASES & BUSINESS
APPLICATIONS

P A NAIDU 22
PRODUCT LINE SOFTWARE

 PROVIDE SPECIFIC CAPABIITY FOR USE BY MANY

DIFFERENT CUSTOMERS
 FOCUS ON LIMITED & ESOTERIC MARKETPLACE
 EXAMPLE:WORD PROCESSING
 SPREADSHEETS
 COMPUTER GRAPHICS
 DATABASE MANAGEMENT
 MULTIMEDIA & ENTERTAINMENT
 BUSINESS FINANCIAL APPLICATIONS

P A NAIDU 23
EMBEDDED SOFTWARE

 RESIDES WITHIN A PRODUCT OR SYSTEM

 USED TO IMPLEMENT & CONTROL FEATURES
 PERFORM LIMITED & ESOTERIC FUNCTIONS
 PROVIDE SIGNIFICANT FUNCTION & CONTROL CAPABILITY
 EXAMPLE:KEYPAD CONTROL FOR A MICROWAVE OVEN

P A NAIDU 24
UBIQUITUOUS COMPUTING

 RAPID GROWTH OF WIRELESS NETWORKING LEADS TO

DISTRIBUTED COMPUTING
 TO DEVELOP SYSTEMS & APPLICATION S/W THAT WILL
ALLOW SMALL DEVICES , PERSONAL COMPUTERS &
ENTERPRISE SYSTEM TO COMMUNICATE ACROSS VAST
NETWORKS

P A NAIDU 25
ARTIFICIAL INTELLIGENCE

 USE OF NON-NUMERICAL ALGORITHMS TO SOLVE COMPLEX

PROBLEMS
 NOT AMENABLE TO COMPUTATION / STRAIGHT FORWARD
ANALYSIS
 EXAMPLE:ROBOTICS
 EXPERT SYSTEMS
 PATTERN RECOGNITION(IMAGE AND VOICE)
 ARTIFICIAL NEURAL NETWORKS
 THOREM PROVING
 GAME PLAYING

P A NAIDU 26
A generic view of process
 Process :
 What is it? – A series of predictable steps – A road map that helps
you create for timely, high‐quality result. » A software process is a
framework for the tasks that are required to build high‐quality
software.
• Who does it? – Software Engineers, Project Managers and
Customers
• Why is it important? – It provides stability, control, and organization
to an activity that can, if left uncontrolled, become quite chaotic.
• What are the steps? – The process that you adopt depends on the
software you’re building.
• What is the work product? – The work products are the programs,
documents, and data produced as a consequence of the software
engineering activities defined by the process.

P A NAIDU 27
Process
 Process :
• How do I ensure that I’ve done it right? – The quality, timeliness, and
long‐term viability of the product you build are the best indicators of the
efficacy of the process that you use. – A number of software process
assessment mechanisms enable organizations to determine the “maturity”
of a software process.
• Is process synonymous with software engineering? – A software process
defines the approach that is taken as software is engineered. But software
engineering also encompasses technologies that populate the process—
technical methods and automated tools. – Software engineering is
performed by creative, knowledgeable people who should work within a
defined and mature software process that is appropriate for the products
they build and the demands of their marketplace. – Software Engineering
is the application of a systematic, disciplined, quantifiable approach to the
development, operation, and maintenance of software

P A NAIDU 28
Software Engineering – Layered Technology

P A NAIDU 29
Software Engineering – Layered Technology

• The bedrock that supports software engineering is a quality focus.

• The foundation for software engineering is the process layer. – Process defines a
framework for a set of key process areas (KPAs) that must be established for
effective delivery of software engineering technology.
• Software engineering methods provide the technical how‐to's for building software.
– Methods encompass a broad array of tasks that include requirements analysis,
design, program construction, testing, and support. – Software engineering
methods rely on a set of basic principles that govern each area of the technology
and include modeling activities and other descriptive techniques.
• Software engineering tools provide automated or semi‐automated support for the
process and the methods. – Computer‐aided software engineering (CASE) is the
scientific application of a set of tools and methods to a software system which is
meant to result in high‐quality, defect‐free, and maintainable software products. –
CASE tools are a class of software that automate many of the activities involved in
various life cycle phases. – Automated tools can be used collectively or individually.

P A NAIDU 30
A generic View of Software
Engineering
 The work associated with software engineering can be
categorized into three generic phases, regardless of
application area, project size, or complexity.
 Definition phase
 Development Phase
 Support Phase

P A NAIDU 31
A generic View of Software Engineering

Definition Phase
 Definition Phase – The definition phase focuses on “what” ‐The key
requirements of the system and the software are identified.
» what information is to be processed
» what function and performance are desired
» what system behavior can be expected
» what interfaces are to be established
» what design constraints exist
» what validation criteria are required to define a successful system.
– Three major tasks will occur : system or information engineering,
software project planning and requirements analysis

P A NAIDU 32
A generic View of Software Engineering

Development Phase
Development Phase:
• The development phase focuses on “how”.
– How data are to be structured
– How function is to be implemented within a software
architecture
– How procedural details are to be implemented
– How interfaces are to be characterized
– How the design will be translated into a programming language
and how testing will be performed.
• Three specific technical tasks will always occur in this phase:
software design, code generation and software testing

P A NAIDU 33
A generic View of Software Engineering

Support phase:

Support phase:
• Focuses on change
• Reapplies the steps of the definition and development phases but does so
in the context of existing software.
• Four types of change are encountered during the support phase: –
Correction :
• Even with the best quality assurance activities, it is likely that the customer
will uncover defects in the software.
• Corrective maintenance changes the software to correct defects. –
Adaptation :
• Over time, the original environment (e.g., CPU, operating system, business
rules, external product characteristics) for which the software was
developed is likely to change.
• Adaptive maintenance results in modification to the software to
accommodate changes to its external environment.

P A NAIDU 34
A generic View of Software Engineering

Support phase:

Enhancement :
• As software is used, the customer/user will recognize
additional functions that will provide benefit.
• Perfective maintenance extends the software beyond its
original functional requirements
Prevention:
• Computer software deteriorates due to change, and because
of this, preventive maintenance, often called software
reengineering, must be conducted to enable the software to
serve the needs of its end users.
• Preventive maintenance makes changes to computer programs
so that they can be more easily corrected, adapted, and
enhanced.
P A NAIDU 35
Product Vs Process
 Product
 The software developer and customer must meet to define
product objectives and scope Objectives identify the overall
goals for the product (from the customer’s point of view)
without considering how these goals will be achieved.
 Scope identifies the primary data, functions and behaviors
that characterize the product, and more important,
attempts to bound these characteristics in a quantitative
manner

P A NAIDU 36
Product Vs Process
 Process:
 A software process provides the framework from which a
comprehensive plan for software development can be
established.
 A small number of framework activities are applicable to
all software projects, regardless of their size or
complexity.
 Finally, umbrella activities such as software quality
assurance, software configuration management and
measurement overlay the process model.
P A NAIDU 37
Product Vs Process

 Process is essential to the creation of the product.

 Process is a fundamental tool for carrying out community
consensus, and for allowing a very large number of
people to work together on a collaborative project.
 A creative software professional should also derive as
much satisfaction from the process as the end‐product.

P A NAIDU 38
Capability Maturity Model ‐SEI

 Capability Maturity Model ‐SEI:

 •To determine an organization’s current state of process maturity, the SEI uses an assessment that results
in a five point grading scheme.
 •The grading scheme determines compliance with a capability maturity model (CMM)that defines key
activities required at different levels of process maturity.
 •Level 1: Initial. The software process is characterized as ad hoc and occasionally even chaotic. Few
processes are defined, and success depends on individual effort.
 •Level 2: Repeatable. Basic project management processes are established to track cost, schedule, and
functionality. The necessary process discipline is in place to repeat earlier successes on projects with similar
applications.
 •Level 3: Defined. The software process for both management and engineering activities is documented,
standardized, and integrated into an organization wide software process. All projects use a documented
and approved version of the organization's process for developing and supporting software. This level
includes all characteristics defined for level 2.
 •Level 4: Managed. Detailed measures of the software process and product quality are collected. Both the
software process and products are quantitatively understood and controlled using detailed measures. This
level includes all characteristics defined for level 3.
 •Level 5: Optimizing. Continuous process improvement is enabled by quantitative feedback from the
process and from testing innovative ideas and technologies. This level includes all characteristics defined
for level 4.

P A NAIDU 39
Personal & team Process models
 Personal Software Process (PSP):
 The Personal Software Process (PSP) shows engineers
how to
- manage the quality of their projects
- make commitments they can meet
- improve estimating and planning
- reduce defects in their products
 PSP emphasizes the need to record and analyze the types
of errors you make, so you can develop strategies
eliminate them.

P A NAIDU 40
PSP model Framework Activities
 Planning – isolates requirements and based on these develops both
size & resource estimates. A defect estimate is made.

 High level Design – external specification of all components. All

issues are recorded and tracked.

 High level Design Review- formal verification to uncover errors

 Development- metrics are maintained for all important tasks & work
results.

 Postmortem- using measures & metrics collected effectiveness of

process is determined an improved.

P A NAIDU 41
Personal Software Process
Personal Software Process:
 Because personnel costs constitute 70 percent of the cost
of software development, the skills and work habits of
engineers largely determine the results of the software
development process.
 Based on practices found in the CMMI, the PSP can be
used by engineers as a guide to a disciplined and
structured approach to developing software. The PSP is a
prerequisite for an organization planning to introduce the
TSP.

P A NAIDU 42
PSP…
 The PSP can be applied to many parts of the software
development process, including
 small-program development
 requirement definition
 document writing
 systems tests
 systems maintenance
 enhancement of large software systems

P A NAIDU 43
Team Software Process (TSP)
 Team Software Process (TSP):The Team Software Process
(TSP), along with the Personal Software Process, helps the
high-performance engineer to
 ensure quality software products
 create secure software products
 improve process management in an organization

P A NAIDU 44
TSP Framework Activities
 Launch high level design
 Implementation
 Integration
 Test
 postmortem
 Engineering groups use the TSP to apply integrated team
concepts to the development of software-intensive systems. A
launch process walks teams and their managers through
 establishing goals
 defining team roles
 assessing risks
 producing a team plan

P A NAIDU 45
Benefits of TSP
 The TSP provides a defined process framework for
managing, tracking and reporting the team's progress.
 Using TSP, an organization can build self-directed teams
that plan and track their work, establish goals, and own
their processes and plans. These can be pure software
teams or integrated product teams of 3 to 20 engineers.
 TSP will help your organization establish a mature and
disciplined engineering practice that produces secure,
reliable software.

P A NAIDU 46
Software Development Life Cycle
 SDLC( Software Development Life Cycle) is a process used
by software industry to design, develop and test high
quality softwares.
 The SDLC aims to produce a high quality software that
meets or exceeds customer expectations, reaches
completion within times and cost estimates.
 SDLC is a process followed for a software project, within a
software organization. It consists of a detailed plan
describing how to develop, maintain, replace and alter or
enhance specific software.

P A NAIDU 47
SDLC

P A NAIDU 48
SDLC
 The life cycle defines a methodology for improving the
quality of software and the overall development process.
 A typical Software Development life cycle consists of the
following stages:
 Stage 1: Planning and Requirement Analysis
 Stage 2: Defining Requirements
 Stage 3: Designing the product architecture
 Stage 4: Building or Developing the Product
 Stage 5: Testing the Product
 Stage 6: Deployment in the Market and Maintenance

P A NAIDU 49
SDLC Activities

P A NAIDU 50
SDLC Models
 There are various software development life cycle models
defined and designed which are followed during software
development process. These models are also referred as
"Software Development Process Models".
 Each process model follows a Series of steps unique to its type,
in order to ensure success in process of software
development. Following are the most important and popular
SDLC models followed in the industry:
1) Waterfall Model
2) Iterative Model
3) Spiral Model
4) V-Model
5) Big Bang Model
P A NAIDU 51
Waterfall Model
 Waterfall approach was first SDLC Model to be used
widely in Software Engineering to ensure success of the
project. In "The Waterfall" approach, the whole process
of software development is divided into separate phases.
In Waterfall model, typically, the outcome of one phase
acts as the input for the next phase sequentially.
 Following is a diagrammatic representation of different
phases of waterfall model.

P A NAIDU 52
Waterfall Model

P A NAIDU 53
Waterfall Model
 The sequential phases in Waterfall model are:
 Requirement Gathering and analysis: All possible requirements of the system to be developed are
captured in this phase and documented in a requirement specification doc.

 System Design: The requirement specifications from first phase are studied in this phase and system
design is prepared. System Design helps in specifying hardware and system requirements and also helps in
defining overall system architecture.

 Implementation: With inputs from system design, the system is first developed in small programs called
units, which are integrated in the next phase. Each unit is developed and tested for its functionality which is
referred to as Unit Testing.

 Integration and Testing: All the units developed in the implementation phase are integrated into a system
after testing of each unit. Post integration the entire system is tested for any faults and failures.

 Deployment of system: Once the functional and non functional testing is done, the product is deployed in
the customer environment or released into the market.

 Maintenance: There are some issues which come up in the client environment. To fix those issues patches
are released. Also to enhance the product some better versions are released. Maintenance is done to
deliver these changes in the customer

P A NAIDU 54
Waterfall Model Applications: Some situations where the use of
Waterfall model is most appropriate are
 Every software developed is different and requires a
suitable SDLC approach to be followed based on the
internal and external factors. :
 Requirements are very well documented, clear and fixed
 Product definition is stable
 Technology is understood and is not dynamic
 There are no ambiguous requirements
 sufficient resources with required expertise are available
to support the product
 The project is short

P A NAIDU 55
Waterfall Model
 The advantage of waterfall development is that it allows for
departmentalization and control. A schedule can be set with
deadlines for each stage of development and a product can
proceed through the development process model phases one
by one. Each phase of development proceeds in strict order.
 [Therefore, in any practical software development work, it is
not possible to strictly follow the classical waterfall model.]
 The disadvantage of waterfall development is that it does not
allow for much reflection or revision. Once an application is in
the testing stage, it is very difficult to go back and change
something that was not well-documented or thought upon in
the concept stage.

P A NAIDU 56
Iterative Model
 Iterative process starts with a simple implementation of a
subset of the software requirements and iteratively enhances
the evolving versions until the full system is implemented.
 At each iteration, design modifications are made and new
functional capabilities are added. The basic idea behind this
method is to develop a system through repeated cycles
(iterative) and in smaller portions at a time (incremental).
 "During software development, more than one iteration of the
software development cycle may be in progress at the same
time." and "This process may be described as an "evolutionary
acquisition" or "incremental build" approach.

P A NAIDU 57
Following is the pictorial representation of Iterative and
Incremental model

P A NAIDU 58
Iterative Model
 In incremental model the whole requirement is divided into
various builds. During each iteration, the development module
goes through the requirements, design, implementation and
testing phases. Each subsequent release of the module adds
function to the previous release. The process continues till the
complete system is ready as per the requirement.
 The key to successful use of an iterative software development
lifecycle is rigorous validation of requirements, and verification
& testing of each version of the software against those
requirements within each cycle of the model. As the software
evolves through successive cycles, tests have to be repeated
and extended to verify each version of the software.

P A NAIDU 59
Iterative Model Applications: : This model is most often
used in the following scenarios:
 Requirements of the complete system are clearly defined and understood.

 Major requirements must be defined; however, some functionalities or requested

enhancements may evolve with time.

 There is a time to the market constraint.

 A new technology is being used and is being learnt by the development team while
working on the project.

 Resources with needed skill set are not available and are planned to be used on
contract basis for specific iterations.

 There are some high risk features and goals which may change in the future.

P A NAIDU 60
Iterative Model
 The advantage of this model is that there is a working
model of the system at a very early stage of development
which makes it easier to find functional or design flaws.
Finding issues at an early stage of development enables
to take corrective measures in a limited budget.
 The disadvantage with this SDLC model is that it is
applicable only to large and bulky software development
projects. This is because it is hard to break a small
software system into further small serviceable
increments/modules.

P A NAIDU 61
PRTOTYPING MODEL

 Prototype: 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.
 There are several uses of a prototype. An important purpose is 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.
P A NAIDU 62
PRTOTYPING MODEL
 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.
 A prototype of the actual product is preferred in
situations such as:
 User requirements are not complete
 Technical issues are not clear

P A NAIDU 63
Fig: Prototype Model

P A NAIDU 64
EVOLUTIONARY MODEL

 It is also called successive versions model or incremental model. At first, a simple working
model is built. Subsequently it undergoes functional improvements & we keep on adding new
functions till the desired system is built.
 Applications: This model is most often used in the following scenarios:
 Large projects where you can easily find modules for incremental implementation. Often
used when the customer wants to start using the core features rather than waiting for the full
software.
 Also used in object oriented software development because the system can be easily
portioned into units in terms of objects.

 Advantages:
 User gets a chance to experiment partially developed system
 Reduce the error because the core modules get tested thoroughly.

 Disadvantages:
 It is difficult to divide the problem into several versions that would be acceptable to the
customer which can be incrementally implemented & delivered.


P A NAIDU 65
Spiral Model
 Spiral model is a combination of iterative development process
model and sequential linear development model i.e. waterfall
model with very high emphasis on risk analysis.
 Spiral Model is very widely used in the software industry as it
is in synch with the natural development process of any
product i.e. learning with maturity and also involves minimum
risk for the customer as well as the development firms.
 The diagrammatic representation of this model appears like a
spiral with many loops. The exact number of loops in the spiral
is not fixed. Each loop of the spiral represents a phase of the
software process .
 Each phase in this model is split into four sectors (or
quadrants) as shown in fig.

P A NAIDU 66
The diagrammatic representation
of Spiral model

P A NAIDU 67
Each phase in this model is split into four sectors (or
quadrants) as shown in fig.
First quadrant (Objective Identification) :
 During the first quadrant, it is needed to identify the objectives of the phase.
 Examine the risks associated with these objectives.
Second Quadrant (Risk Analysis) :
 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 (Execution and Testing)
 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.

P A NAIDU 68
Spiral Model Application: Following are the typical uses of Spiral
model:

 When costs there is a budget constraint and risk evaluation is

important
 For medium to high-risk projects
 Long-term project commitment because of potential changes
to economic priorities as the requirements change with time
 Customer is not sure of their requirements which is usually
the case
 Requirements are complex and need evaluation to get clarity
 New product line which should be released in phases to get
enough customer feedback
 Significant changes are expected in the product during the
development cycle

P A NAIDU 69
Spiral Model Pros & Cons
Pros(Advantages):
 Changing requirements can be accommodated.
 Allows for extensive use of prototypes
 Requirements can be captured more accurately.
 Users see the system early.
 Development can be divided into smaller parts and more
risky parts can be developed earlier which helps better
risk management.

P A NAIDU 70
Spiral Model Pros & Cons
Cons(Disadvantages):
 Management is more complex.
 End of project may not be known early.
 Not suitable for small or low risk projects and could be
expensive for small projects.
 Process is complex
 Spiral may go indefinitely.
 Large number of intermediate stages requires excessive
documentation.


P A NAIDU 71
RAD Model
 The RAD (Rapid Application Development)model is based on
prototyping and iterative development with no specific
planning involved. The process of writing the software itself
involves the planning required for developing the product.
 Rapid application development (RAD) is a software
development methodology that uses minimal planning in favor
of rapid prototyping. A prototype is a working model that is
functionally equivalent to a component of the product.
 In RAD model the functional modules are developed in parallel
as prototypes and are integrated to make the complete
product for faster product delivery.

P A NAIDU 72
RAD Model
 Since there is no detailed preplanning, it makes it easier
to incorporate the changes within the development
process.
 RAD projects follow iterative and incremental model and
have small teams comprising of developers, domain
experts, customer representatives and other IT resources
working progressively on their component or prototype.
 The most important aspect for this model to be successful
is to make sure that the prototypes developed are
reusable.

P A NAIDU 73
RAD Model Design
 RAD model distributes the analysis, design, build, and test
phases into a series of short, iterative development
cycles. Following are the phases of RAD Model:
 Business Modeling
 Data Modeling
 Process Modeling
 Application Generation
 Testing and Turnover

P A NAIDU 74
RAD Model Design
 Business Modeling: The information gathered in the
Business Modeling phase is reviewed and analyzed to
form sets of data objects vital for the business. The
attributes of all data sets is identified and defined. The
relation between these data objects are established and
defined in detail in relevance to the business model.
 Process Modeling: The process model for any changes or
enhancements to the data object sets is defined in this
phase. Process descriptions for adding , deleting,
retrieving or modifying a data object are given.

P A NAIDU 75
RAD Model Design
 Application Generation: The actual system is built and
coding is done by using automation tools to convert
process and data models into actual prototypes.
 Testing and Turnover: The overall testing time is reduced
in RAD model as the prototypes are independently tested
during every iteration. However the data flow and the
interfaces between all the components need to be
thoroughly tested with complete test coverage. Since
most of the programming components have already been
tested, it reduces the risk of any major issues.

P A NAIDU 76
Following image illustrates the RAD Model:

P A NAIDU 77
RAD Model Application: Following are the typical
scenarios where RAD can be used:
RAD model can be applied successfully to the projects in which clear
modularization is possible. If the project cannot be broken into modules,
RAD may fail.

 RAD should be used only when a system can be modularized to be

delivered in incremental manner.
 It should be used if there’s high availability of designers for modeling
 It should be used only if the budget permits use of automated code
generating tools.
 RAD SDLC model should be chosen only if domain experts are available
with relevant business knowledge
 Should be used where the requirements change during the course of the
project and working prototypes are to be presented to customer in small
iterations of 2-3 months.

P A NAIDU 78
pros and cons of RAD Model
Pros(Advantages):
 Changing requirements can be accommodated.
 Progress can be measured.
 Iteration time can be short with use of powerful RAD tools.
 Productivity with fewer people in short time.
 Reduced development time.
 Increases reusability of components

Cons(Disadvantages):
 Dependency on technically strong team members for identifying business
requirements.
 Only system that can be modularized can be built using RAD
 Requires highly skilled developers/designers.
 High dependency on modeling skills
 Inapplicable to cheaper projects as cost

P A NAIDU 79
A PROCESS FRAMEWORK
 Software process models can be prescriptive or agile,
complex or simple, all-encompassing or targeted, but in
every case, five key activities must occur. The framework
activities are applicable to all projects and all application
domains, and they are a template for every process
model.
 Each framework activity is populated by a set of S/W eng
actions – a collection of related tasks that produces a
major S/W eng work product (design is a S/W eng action).
Each action is populated with individual work tasks that
accomplish some part of the work implied by the action.

P A NAIDU 80
A PROCESS FRAMEWORK…
 The following generic process framework is applicable to the vast majority of S/W
projects.
 Communication: involves heavy communication with the customer (and other
 stakeholders) and encompasses requirements gathering.
 Planning: Describes the technical tasks to be conducted, the risks that are likely,
 resources that will be required, the work products to be produced and a work
schedule.
 Modeling: encompasses the creation of models that allow the developer and
customer to better understand S/W req. and the design that will achieve those req.
 Construction: combines code generation and the testing required uncovering
errors in the code.
 Deployment: deliver the product to the customer who evaluates the delivered
product and provides feedback.

P A NAIDU 81
A PROCESS FRAMEWORK…
 The framework described in the generic view of S/W eng is complemented by a number of
umbrella activities. Typical activities include:
 S/W project tracking and control: allows the team to assess progress against the project plan
and take necessary action to maintain schedule.
 Risk Management: Assesses the risks that may affect the outcome of the project or the
quality.
 Software quality assurance: defines and conducts the activities required to ensure software
quality.
 Formal Technical Review: uncover and remove errors before they propagate to the next
action.
 Measurement: defines and collects process, project, and product measures that assist the
team in delivering S/W that meets customers’ needs.
 Software configuration management: Manages the effect of change throughout the
 S/W process
 Reusability management: defines criteria for work product reuse.
 Work product preparation and production: encompasses the activities required to create
work products such as models, documents, etc.

P A NAIDU 82
PROCESS ASSESSMENT

 The process should be assessed to ensure that it meets a set

of basic process criteria that have been shown to be essential
for a successful software engineering. This is used by industry
professionals.
 The PSP model is good from the perspective that an individual
software engineer can use it to improve his or her personal
productivity and work product quality. Both models are largely
iterative or evolutionary in their approach to software
development.
 PSP and TSP are interesting, but are not pivotal to an
understanding of process issues. A key point of this section is
that individuals and teams should measure their work and the
errors they make and act to improve their approach so that
the causes of errors are eliminated.
P A NAIDU 83
THE CONCURRENT DEVELOPMENT
MODEL
 The concurrent development model, sometimes called
concurrent engineering, can be represented schematically
as a series of framework activities, Software engineering
actions of tasks, and their associated states.
 The concurrent model is often more appropriate for
system engineering projects where different engineering
teams are involved.

P A NAIDU 84
CONCURRENT DEVELOPMENT
MODEL

P A NAIDU 85
SPECIALIZED PROCESS MODELS
 Component Based Development
 Commercial off-the-shelf (COTS) Software components, developed
by
 vendors who offer them as products, can be used when Software is
tobe
 built.
 These components provide targeted functionality with well-defined
 interfaces that enable the component to be integrated into the
Software.
 The Formal Methods Model
 • defect-free Software.
 • Clean room Software.

P A NAIDU 86
The Unified Process

 A “use-case driven, architecture-centric, iterative and

incremental”
 software process closely aligned with the Unified Modeling
Language (UML).
 Recognize:
 importance of customer communication methods for
describing the customer’s view of a system
 Easy to identify goals, such as understandability, add future
changes, andreuse
 The UML developers developed the Unified Process, a
framework Object Oriented Software Engineering using UML.

P A NAIDU 87
Phases of Unified Process

P A NAIDU 88
Software Requirement Specification

 A software requirements specification (SRS) is a document that captures

complete description about how the system is expected to perform.
 The SRS fully describes what the software will do and how it will be
expected to perform.
 SRS is a Contract between Development and Customer.
 Qualities of SRS:
 Correct
 Unambiguous
 Complete
 Consistent
 Well Structured
 Verifiable
 Modifiable
 Traceable

P A NAIDU 89