Software Engineering NOTES

Software Engineering
Prepared by: Neha Tripathi

Assistant Professor
Department of CSE
Graphic Era deemed to be University
What is Software Engineering
• Software engineering is an engineering discipline that is concerned

with all aspects of software production.
• Engineering approach to develop software.
-A disciplined and systematic approach whose aim is the develop
a quality software, software that is delivered on time, within
budget, and that satisfies its requirements.
• Systematic collection of past experience:
– techniques,
– methodologies,
– guidelines.
Software Engineering Definition
• The seminal definition:

– [Software engineering is] the establishment and use of sound
engineering principles in order to obtain economically software
that is reliable and works efficiently on real machines.
• The IEEE definition:
– Software Engineering: (1) The application of a systematic,
disciplined, quantifiable approach to the development,
operation, and maintenance of software; that is, the application
of engineering to software. (2) The study of approaches as in
(1).
Technology Development Pattern
What is the difference between software
engineering and computer science?
• Computer science focuses on theory and fundamentals;
• Software Engineering is concerned with the practicalities of

developing and delivering useful software.
Why Study Software Engineering?
• To acquire skills to develop large programs.

-Exponential growth in complexity and difficulty level with
size.
-The ad hoc approach breaks down when
size of software increases.
• Ability to solve complex programming problems:
-How to break large projects into smaller and manageable
parts?
What is Software?
• The product that software professionals build and then support over the
long term.
• Software encompasses:
(1) instructions (computer programs) that when executed provide desired
features, function, and performance;
(2) data structures that enable the programs to adequately store and
manipulate information and
(3) documentation that describes the operation and use of the programs.
• Thus, Software is a collection of computer programs, data
structures and associated documentation.
• Software products may be developed for a particular customer or
may be developed for a general market.
Programs versus Software Products
?
Thank You!

Program Vs Software
What Is A Computer Program
• Program is a set of instructions written in a programming language used to execute

for a specific task or particular function.
• A program does not have further categorization.
• A program cannot be software.
• A program consists of a set of instructions which are coded in a programming language
like c, C++, PHP, Java etc.
• Programs do not have a user interface.
• A program is developed and used by either a single programmer or a group of
programmers.
• A program is compiled every time when we need to generate some output from it.
• Program has limited functionality and less features.
• Program functionality is dependent on compiler.
• A program takes less time to build/make.
• Program development approach is un-procedural, un-organized and unplanned.
• The size of a program ranges from kilobytes (Kb) to megabytes (Mb).
• Examples of computer programs include: Operating system, office suite, video games,
malware, a web browser like Mozilla Firefox and Apple Safari.
What Is A Computer Software
• Software is a collection of several programs and other procedures and

documentation.
• Software can be categorized into two categories: application software and system
software.
• Software can be a program.
• Software consists of bundles of programs and data files. Programs in specific software
use these data files to perform a dedicated type of tasks.
• Every software has a dedicated user interface. The user interface of software may be in
the form of a command prompt or in a graphical format.
• Software is developed by either a single programmer or a group of programmers.
• Whole software is compiled, tested and debugged during the development process.
• Software has lots of functionality and features such as GUI, input/output data, process
etc.
• Software functionality is dependent on the operating system.
• Software takes relatively more time to build/make when compared to program.
• Software development approach is systematic, organized and very well planned.
• The size of a software ranges from megabytes (Mb) to Gigabytes (Gb).
• Examples of software include: Microsoft Word, Microsoft Excel, VLC media player,
Firefox, Adobe Reader, Windows, Linux, Unix, Mac etc.
Program Vs Software
Program Vs Software(continue…)
Program Vs Software(continue…)
• Usually small in size • Large

• Author himself is sole • Large number of users
user • Team of developers
• Single developer • Well-designed interface
• Lacks proper user
interface • Well documented &
user-manual prepared
• Lacks proper
documentation • Systematic
development
• Ad hoc development.
Thank You!

Software Crisis
• Software crisis is the situation resulted due to the increment in

failure rate of software development which leads to incomplete
and degrading performance of software products.
• Term was coined in the year 1968.
• In general it refers to poorly written, hard to read, error-prone
software that often lacks good documentation.
• The term software crisis revolves around three concepts:
complexity, change and the expectations.
Software Crisis
Software Crisis in terms of statistics
• success 16%
• failure 31%
• over budget 53%
Problems of software crisis:
• Projects running over-budget

• Projects running over-time
• Software was very inefficient
• Projects were unmanageable and code difficult to maintain
• Software was of low quality
• The software often did not meet requirements
Factors contributing to the software crisis
• Large and complex problems,

• Lack of adequate training in software engineering,
• Increasing skill shortage,
• Low productivity improvements,
• Requirement change is inevitable,
• Requirement gets frozen,
• Customer themselves are not clear with their requirements,
• Market demand/conditions changes,
• Manpower turnover,
• Technology/Process change,
• etc.
Example
• Y2K problem
-related to date format
-problem arise in year 2000
- all the softwares stopped working
-format changed from ddmmyy to ddmmyyyy.
-example:
-In 19th century date format used was ddmmyy(say 1st jan 1999 was written as
010199 and it year is assumed to be 1999 by default )
- but, when 20 th century came, (say 1 st jan 2000 was written as 010100 and
according to old format year was assumed to be 1900)
- so all the software failed.
-currently, we use yyyy instead of yy.
Thank You!

What is software?
What is software?
Documentation consists of different types of
manuals are
Documentation consists of different types of
manuals are
What is software engineering?
• Software engineering is an engineering discipline which is

concerned with all aspects of software production
• Software engineers should
– adopt a systematic and organized approach to their work
– use appropriate tools and techniques depending on
• the problem to be solved,
• the development constraints and
– use the resources available
What is software engineering?
• The establishment and use of sound engineering principles in

order to obtain economically developed software that is reliable
and works efficiently on real machines.
• “A discipline whose aim is the production of quality software,
software that is delivered on time, within budget, and that
satisfies its requirements”.
• Both the definitions are popular and acceptable to majority.
• However, due to increase in cost of maintaining software, objective
is now shifting to produce quality software that is maintainable,
delivered on time, within budget, and also satisfies its
requirements.
Characteristics/Attributes/Features of Software
Its characteristics that make it different from other things human

being build. Features of such logical system:
• Software is developed or engineered, it is not manufactured in the
classical sense which has quality problem.
• Software doesn't "wear out.” but it deteriorates (due to change).
Hardware has bathtub curve of failure rate ( high failure rate in the
beginning, then drop to steady state, then cumulative effects of
dust, vibration, abuse occurs).
• Although the industry is moving toward component-based
construction (e.g. standard screws and off-the-shelf integrated
circuits), most software continues to be custom-built. Modern
reusable components encapsulate data and processing into
software parts to be reused by different programs. E.g. graphical
user interface, window, pull-down menus in library etc.
Software Characteristics:
Software Characteristics:
Essential Attributes for Software Products
Characteristics of Good Software
• Any software should be judged by what it offers and what are the
methods which help you to use it.
• Every software must satisfy the following attributes:
-Operational
-Transitional
-Maintenance
Operational
• This characteristic let us know about how well software works in

the operations which can be measured on:
• Budget
• Efficiency
• Usability
• Dependability
• Correctness
• Functionality
• Safety
• Security
Transitional
• This is an essential aspect when the software is moved from one

platform to another:
• Interoperability
• Reusability
• Portability
• Adaptability
Maintenance
• This aspect talks about how well software has the capabilities to
adapt itself in the quickly changing environment:
• Flexibility
• Maintainability
• Modularity
• Scalability
Thank you!
Need of Software Engineering
The necessity of software engineering appears because of a higher rate of progress

in user requirements and the environment on which the program is working.
• Huge Programming: It is simpler to manufacture a wall than to a house or
building, similarly, as the measure of programming become extensive
engineering has to step to give it a scientific process.
• Adaptability: If the software procedure were not based on scientific and
engineering ideas, it would be simpler to re-create new software than to scale
an existing one.
• Cost: As the hardware industry has demonstrated its skills and huge
manufacturing has let down the cost of computer and electronic hardware. But
the cost of programming remains high if the proper process is not adapted.
• Dynamic Nature: The continually growing and adapting nature of programming
hugely depends upon the environment in which the client works. If the quality
of the software is continually changing, new upgrades need to be done in the
existing one.
• Quality Management: Better procedure of software development provides a
better and quality software product.
Importance of Software Engineering
Importance of Software Engineering
• Reduces complexity:
Big software is always complicated and challenging to progress. Software engineering has a
great solution to reduce the complication of any project. Software engineering divides big
problems into various small issues. And then start solving each small issue one by one. All
these small problems are solved independently to each other.
• To minimize software cost:
Software needs a lot of hardwork and software engineers are highly paid experts. A lot of
manpower is required to develop software with a large number of codes. But in software
engineering, programmers project everything and decrease all those things that are not
needed. In turn, the cost for software productions becomes less as compared to any software
that does not use software engineering method.
• To decrease time:
Anything that is not made according to the project always wastes time. And if you are
making great software, then you may need to run many codes to get the definitive running
code. This is a very time-consuming procedure, and if it is not well handled, then this can take
a lot of time. So if you are making your software according to the software engineering
method, then it will decrease a lot of time.
• Handling big projects:
Big projects are not done in a couple of days, and they need lots of patience, planning, and
management. And to invest six and seven months of any company, it requires heaps of planning, direction,
testing, and maintenance. No one can say that he has given four months of a company to the task, and the
project is still in its first stage. Because the company has provided many resources to the plan and it
should be completed. So to handle a big project without any problem, the company has to go for a
software engineering method.
• Reliable software:
Software should be secure, means if you have delivered the software, then it should work for at least
its given time or subscription. And if any bugs come in the software, the company is responsible for solving
all these bugs. Because in software engineering, testing and maintenance are given, so there is no worry
of its reliability.
• Effectiveness:
Effectiveness comes if anything has made according to the standards. Software standards are the big
target of companies to make it more effective. So Software becomes more effective in the act with the
help of software engineering.
Applications of Software
The most significant factor in determining which software engineering methods and
techniques are most important is the type of application that is being developed.
• System Software: A collection of programs written to service other programs. Compiler,
device driver, editors, file management.
• Application software or stand alone program: It solves a specific Business needs. It is
needed to convert the business function in real time. Example -point of sale,
Transaction processing, real time manufacturing control.
• Scientific / Engineering Software: Applications like based on astronomy, automative
stress analysis , molecular Biology, volcanology, space Shuttle orbital dynamic,
automated manufacturing.
• Embedded Software: There are software control systems that control and manage
hardware devices. Example- software in mobile phone, software in Anti Lock Braking in
car, software in microwave oven to control the cooking process.
• Product Line Software: It is designed to provide a specific capability for use by many
different customers. It can focus on unlimited or esoteric Marketplace like inventory
control products. Or address mass market place like : Spreadsheets, computer graphics,
multimedia, entertainment, database management, personal, business financial
applications.
• Web application: It is also called " web apps ", are evolving into sophisticated
computing environment that not only provide stand alone features, computing
functions, and content to the end user but also are integrated with corporate database
and business applications.
• Artificial intelligence software: This include- robotic, expert system, pattern
recognition, image and voice, artificial neural network, game playing, theorem proving
... It solves Complex problems.
• Networking and Web Applications Software –Networking
Software provides the required support necessary for computers
to interact with each other and with data storage facilities. The
networking software is also used when software is running on a
network of computers (such as World Wide Web). It includes all
network management software, server software, security and
encryption software and software to develop web-based
applications like HTML, PHP, XML, etc.
• Business Software –This category of software is used to support
the business applications and is the most widely used category of
software. Examples are software for inventory management,
accounts, banking, hospitals, schools, stock markets, etc.
• Entertainment Software –Education and entertainment software
provides a powerful tool for educational agencies, especially
those that deal with educating young children. There is a wide
range of entertainment software such as computer games,
educational games, translation software, mapping software, etc.
• Utilities Software –The programs coming under this category perform specific tasks and
are different from other software in terms of size, cost and complexity. Examples are
anti-virus software, voice recognition software, compression programs, etc.
• Document Management Software –A Document Management Software is used to
track, manage and store documents in order to reduce the paperwork. Such systems
are capable of keeping a record of the various versions created and modified by
different users (history tracking). They commonly provide storage, versioning,
metadata, security, as well as indexing and retrieval capabilities.
• Reservation Software –A Reservation system is primarily used to store and retrieve
information and perform transactions related to air travel, car rental, hotels, or other
activities. They also provide access to bus and railway reservations, although these are
not always integrated with the main system. These are also used to relay computerized
information for users in the hotel industry, making a reservation and ensuring that the
hotel is not overbooked.
Thank you!
Design
Design Data
Dataflow
floworiented
oriented
Design
Design Object
Object ––oriented
Emergence oriented
of The
The Design
Design
improvement
improvement of of the
the software
software
Software engineering discipline is the result of advancement in the field of technology. In
this section, we will discuss various innovations and technologies that led to the
design
design methodology
methodology overover the
the
emergence of software engineering discipline.
last
last 50
50 yrs
yrs have
have indeed
indeed been
been
remarkable.
remarkable.
Emergence of Software Engineering
Early Computer Programming (1950s):
(Exploratory programming style)
• Programs were being written in assembly language.

• Programs were limited to about a few hundreds of lines of assembly code.
• Every programmer developed his own style of writing programs:
-according to his intuition (exploratory programming).
High-Level Language Programming (Early 60s)
• High-level languages such as FORTRAN, ALGOL, and COBOL were introduced:

− This reduced software development efforts greatly.
• Software development style was still exploratory.
− Typical program sizes were limited to a few thousands of lines of source code.
Control Flow-Based Design (late 60s)
• Size and complexity of programs increased further:

• exploratory programming style proved to be insufficient.
• Programmers found:
-very difficult to write cost-effective and correct programs.
• Programmers found:
-programs written by others very difficult to understand and maintain.
• To cope up with this problem, experienced programmers advised: ``Pay particular
attention to the design of the program's control structure.'’
• A program's control structure indicates:
• the sequence in which the program's instructions are executed.
• To help design programs having good control structure:
• flow charting technique was developed.
• Using flow charting technique:
• one can represent and design a program's control structure.
• Usually one understands a program:
• by mentally simulating the program's execution sequence.
• A program having a messy flow chart representation:
• difficult to understand and debug.
• It was found:
• GO TO statements makes control structure of a program messy
• GO TO statements alter the flow of control arbitrarily.
• The need to restrict use of GO TO statements was recognized.
• But, soon it was conclusively proved:
• only three programming constructs are sufficient to express any programming
logic:
• sequence (e.g. a=0;b=5;)
• selection (e.g. if(c=true) k=5 else m=5;)
• iteration (e.g. while(k>0) k=j-k;)
• Everyone accepted:
• it is possible to solve any programming problem without using GO TO statements.
• This formed the basis of Structured Programming methodology.
Structured Programming
• A program is called structured

• when it uses only the following types of constructs:
• sequence,
• selection,
• iteration
• Unstructured control flows are avoided.
• Consist of a neat set of modules.
• Use single-entry, single-exit program constructs.
• However, violations to this feature are permitted:
− due to practical considerations such as:
-premature loop exit to support exception handling.
Structured programs are:
• Easier to read and understand,
• easier to maintain,
• require less effort and time for development.
Data Structure-Oriented Design (Early 70s)
• Soon it was discovered:

• it is important to pay more attention to the design of data structures of a program
• than to the design of its control structure.
• Techniques which emphasize designing the data structure:
− derive program structure from it:
-are called data structure-oriented design techniques.
• Example of data structure-oriented design technique:

• Jackson's Structured Programming(JSP) methodology
-developed by Michael Jackson in 1970s.
• JSP technique:
− program code structure should correspond to the data structure.
• In JSP methodology:
− a program's data structures are first designed using notations for
 sequence, selection, and iteration.
− Then data structure design is used :
 to derive the program structure.
• Several other data structure-oriented Methodologies also exist:
− e.g., Warnier-Orr Methodology.
Data Flow-Oriented Design (Late 70s)
• Data flow-oriented techniques advocate:

• the data items input to a system must first be identified,
• processing required on the data items to produce the required outputs should be
determined.
• Data flow technique identifies:
• different processing stations (functions) in a system
• the items (data) that flow between processing stations.
• Data flow technique is a generic technique:
• can be used to model the working of any system
• not just software systems.
• A major advantage of the data flow technique is its simplicity.
Data Flow Model of a Car Assembly Unit
Object-Oriented Design (80s)
• Object-oriented technique:
• an intuitively appealing design approach:
• natural objects (such as employees, pay-roll-register, etc.)
occurring in a problem are first identified.
• Relationships among objects:
• such as composition, reference, and inheritance are
determined.
• Each object essentially acts as
• a data hiding (or data abstraction) entity.
• Object-Oriented Techniques have gained wide acceptance:
• Simplicity
• Reuse possibilities
• Lower development time and cost
• More robust code
• Easy maintenance
Differences between the exploratory style and modern software
development practices
• Use of Life Cycle Models

• Software is developed through several well-defined stages:
• requirements analysis and specification,
• design,
• coding,
• testing, etc.
• Emphasis has shifted
• from error correction to error prevention.
• Modern practices emphasize:
• detection of errors as close to their point of introduction as possible.
• In exploratory style,
• errors are detected only during testing,
• Now,
• focus is on detecting as many errors as possible in each phase of development.
• In exploratory style,
• coding is synonymous with program development.
• Now,
• coding is considered only a small part of program development effort.
• A lot of effort and attention is now being paid to:
• requirements specification.
• Also, now there is a distinct design phase:
• standard design techniques are being used.
• During all stages of development process:
• Periodic reviews are being carried out
• Software testing has become systematic:
• standard testing techniques are available.
• There is better visibility of design and code:
• visibility means production of good quality, consistent and standard documents.
• In the past, very little attention was being given to producing good quality and
consistent documents.
• We will see later that increased visibility makes software project management
easier.
• Because of good documentation:
• fault diagnosis and maintenance are smoother now.
• Several metrics are being used:
• help in software project management, quality assurance, etc.
• Projects are being thoroughly planned:
• estimation,
• scheduling,
• monitoring mechanisms.
• Use of CASE tools.
Thank you!
Software life cycle model
or
Software development life cycle (SDLC) model
or
Software development process model
Software Life Cycle
• Software life cycle (or software process):

• series of identifiable stages that a software product undergoes during its life
time:
• Feasibility study
• Requirements analysis and specification,
• Design,
• Coding,
• Testing
• Installation
• Maintenance.
Software Life Cycle Model
• A software life cycle model (or process model):

• a descriptive and diagrammatic model of software life cycle:
• identifies all the activities required for product development,
• establishes a precedence ordering among the different activities,
• Divides life cycle into phases.
• Several different activities may be carried out in each life cycle phase.
• For example, the design stage might consist of:
• structured analysis activity followed by
• structured design activity.
Why Model Life Cycle ?
• A written description:
• forms a common understanding of activities among the software developers.
• helps in identifying inconsistencies, redundancies, and omissions in the
development process.
• Helps in tailoring a process model for specific projects.
• The development team must identify a suitable life cycle model:
• and then adhere to it.
• Primary advantage of adhering to a life cycle model:
• helps development of software in a systematic and disciplined manner.
• When a program is developed by a single programmer ---
• he has the freedom to decide his exact steps.
• When a software product is being developed by a team:
• there must be a precise understanding among team members as to when to do
what,
• otherwise it would lead to chaos and project failure.
• A software project will never succeed if:
• one engineer starts writing code,
• another concentrates on writing the test document first,
• yet another engineer first defines the file structure
• another defines the I/O for his portion first.
• A life cycle model:
• defines entry and exit criteria for every phase.
• A phase is considered to be complete:
• only when all its exit criteria are satisfied.
• The phase exit criteria for the software requirements specification phase:
• Software Requirements Specification (SRS) document is complete, reviewed, and
approved by the customer.
• A phase can start:
• only if its phase-entry criteria have been satisfied.
• It becomes easier for software project managers:
• to monitor the progress of the project.
• When a life cycle model is adhered to,
• the project manager can at any time fairly accurately tell,
• at which stage (e.g., design, code, test, etc. ) of the project is.
• Otherwise, it becomes very difficult to track the progress of the project
• the project manager would have to depend on the guesses of the team
members.
• This usually leads to a problem:
• known as the 99% complete syndrome.
• Many life cycle models have been proposed.
• We will confine our attention to a few important and commonly used models.
• classical waterfall model
• iterative waterfall,
• evolutionary,
• prototyping, and
• spiral model
Summary
• Software engineering is:

• systematic collection of decades of programming experience
• together with the innovations made by researchers.
• A fundamental necessity while developing any large software product:
• adoption of a life cycle model.
• Adherence to a software life cycle model:
• helps to do various development activities in a systematic and disciplined
manner.
• also makes it easier to manage a software development effort.
Thank you!
Software Development Life Cycle
(SDLC)
Software Development Life Cycle (SDLC)
• Software Development Life Cycle (SDLC) is a process used by the software industry to
design, develop and test high quality software.
• The SDLC aims to produce a high-quality software that meets or exceeds customer
expectations, reaches completion within times and cost estimates.
• SDLC consists of a detailed plan which explains how to plan, build, and maintain specific
software.
• Every phase of the SDLC life cycle has its own process and deliverables that feed into
the next phase.
• SDLC is the acronym of Software Development Life Cycle.
• It is also called as Software Development Process.
• SDLC is a framework defining tasks performed at each step in the software
development process.
Why SDLC?
• It offers a basis for project planning, scheduling, and estimating

• Provides a framework for a standard set of activities and deliverables
• It is a mechanism for project tracking and control
• Increases visibility of project planning to all involved stakeholders of the development
process
• Increased and enhance development speed
• Improved client relations
• Helps you to decrease project risk and project management plan overhead
SDLC Phases
• Phase 1: Feasibility study

• Phase 2: Requirement Analysis and Specification
• Phase 3: Design
• Phase 4: Coding
• Phase 5: Testing
• Phase 6: Installation/Deployment
• Phase 7: Maintenance
Feasibility study:
• Main aim of feasibility study:

-determine whether developing the product
• financially worthwhile
• technically feasible.
• i.e., implementable or not.
• Work out an overall understanding of the problem.
• Formulate different solution strategies.
• Identify and Examine alternate solution
• Determine which solution is the best.
• Prepare feasibility report
Types of Feasibility
• Economic: Can we complete the project within the budget or not?

• Legal: Can we handle this project as cyber law and other regulatory
framework/compliances.
• Operation feasibility: Can we create operations which is expected by the client?
• Technical: Need to check whether the current computer system can support the
software
• Schedule: Decide that the project can be completed within the given schedule or not.
Requirement Analysis and Specification
• Aim of this phase:

• understand the exact requirements of the customer,
• document them properly.
• “What to do”
• Consists of two distinct activities:
• requirements gathering and analysis
• requirements specification.
• Collect all related data from the customer:

• analyze the collected data to clearly understand what the customer wants,
• find out any inconsistencies and incompleteness in the requirements,
• resolve all inconsistencies and incompleteness.
Steps of Requirement Analysis and Specification
• Requirements Gathering/Elicitation-Functional/Non-functional requirements/Constraints

• Requirements Analysis-
• Requirement Specification-Software Requirement Specification (SRS) document
• Requirement Validation
• Requirement Management
Design
• Design phase transforms requirements specification:

• into a form suitable for implementation in some programming language.
• Plan a Solution
• Diagrammatic representation
• “How to do it”
• the system and software design documents are
prepared as per the requirement specification
document.
• There are two kinds of design,
-high-level design and
-low-level design.
• According to their definitions, a high-level design (HLD) is the overall plan of the system,
while a low-level design (LLD) is a design of its components.
Coding
• In this phase, developers start build the entire system by writing code using the chosen
programming language.
• In the coding phase, tasks are divided into units or modules and assigned to the various
developers.
• It is the longest phase of the Software Development Life Cycle process.
• In this phase, Developer needs to follow certain predefined coding standards and
guidelines.
• They also need to use programming tools like compiler, interpreters, debugger to
generate and implement the code.
Testing
• Once the software is complete, and it is deployed in the testing environment.

• The testing team starts testing the functionality of the entire system. This is done to
verify that the entire application works according to the customer requirement.
• They also test all the non functional requirement to check the performance of the
system.
• They also check whether system adhere to the quality standards or not. It is
impossible to deliver quality software without testing.
• During this phase, QA and testing team may find some bugs/defects which they
communicate to developers. The development team fixes the bug and send back to
QA for a re-test. This process continues until the software is bug-free, stable, and
working according to the business needs of that system.
• Unit testing ,Integration testing, System testing etc.
Installation/Deployment
• Once the software testing phase is over and no bugs or errors left in the system then
the final deployment process starts.
• At this stage, the goal is to deploy the software to the production environment so
users can start using the product.
• Based on the feedback given by the project manager, the final software is released and
checked for deployment issues if any.
Maintenance
• Once the system is deployed, and customers start using the developed system,
following 3 activities occurs due to which system requires a change:
-Bug fixing - bugs are reported because of some scenarios which are not tested at all
-Upgrade - Upgrading the application to the newer versions of the Software
-Enhancement - Adding some new features into the existing software
• The main focus of this SDLC phase is to ensure that needs continue to be met and that
the system continues to perform as per the specification mentioned in the first phase.
• Maintenance of any software product:
• requires much more effort than the effort to develop the product itself.
• development effort to maintenance effort is typically 40:60.
Types of Maintenance
• Corrective maintenance:
• Correct errors which were not discovered during the product development
phases.
• Perfective maintenance:
• Improve implementation of the system
• enhance functionalities of the system.
• Adaptive maintenance:
• Port software to a new environment,
• e.g. to a new computer or to a new operating system.
• Preventive maintenance:
-to prevent system getting obsolete.
Thank You!
Prepared by : Neha Tripathi
SDLC-Waterfall Model
• Classical Waterfall Model

• Iterative Waterfall Model
Classical Waterfall Model
• The Waterfall Model was the first Process Model to be introduced.

• It is also referred to as a linear-sequential life cycle model.
• It is very simple to understand and use.
• Classical waterfall model divides the life cycle into a set of phases and each phase consists of a series
of tasks and has different objectives.
• In a waterfall model, each phase must be completed before the next phase can begin and there is no
overlapping in the phases.
• Since the phases fall from a higher level to lower level, like a cascade of waterfall, It’s named as the
waterfall model.
• Phases between feasibility study and testing is known as development phases.
• Among all life cycle phases maintenance phase consumes maximum effort.
• Among development phases, testing phase consumes the maximum effort.
Classical Waterfall Model – representation1
Deliverables of Waterfall Model
Classical Waterfall Model – representation2
Phases of Classical waterfall Model
1. Feasibility Study: The main goal of this phase is to determine whether it would be financially and
technically feasible to develop the software. The feasibility study involves understanding the problem
and then determine the various possible strategies to solve the problem. These different identified
solutions are analyzed based on their benefits and drawbacks, The best solution is chosen and all the
other phases are carried out as per this solution strategy.
2. Requirements analysis and specification: The aim of the requirement analysis and specification phase
is to understand the exact requirements of the customer and document them properly. This phase
consists of two different activities.
• Requirement gathering and analysis: Firstly all the requirements regarding the software are
gathered from the customer and then the gathered requirements are analyzed. The goal of the
analysis part is to remove incompleteness and inconsistencies.
• Requirement specification: These analyzed requirements are documented in a software
requirement specification (SRS) document. SRS document serves as a contract between
development team and customers. Any future dispute between the customers and the
developers can be settled by examining the SRS document.
3. Design: The aim of the design phase is to transform the requirements specified in the SRS document
into a structure that is suitable for implementation in some programming language.
4. Coding and Unit testing: In coding phase software design is translated into source code using any
suitable programming language. Thus each designed module is coded. The aim of the unit testing phase
is to check whether each module is working properly or not.
5. Integration and System testing: Integration of different modules are undertaken soon after they have
been coded and unit tested. Integration of various modules is carried out incrementally over a number
of steps. During each integration step, previously planned modules are added to the partially integrated
system and the resultant system is tested. Finally, after all the modules have been successfully integrated
and tested, the full working system is obtained and system testing is carried out on this.
System testing consists three different kinds of testing activities as described below :
• Alpha testing: Alpha testing is the system testing performed by the development team.
• Beta testing: Beta testing is the system testing performed by a friendly set of customers.
• Acceptance testing: After the software has been delivered, the customer performed the acceptance
testing to determine whether to accept the delivered software or to reject it.
6. 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.
7. Maintenance: Maintenance is the most important phase of a software life cycle. The effort spent on
maintenance is the 60% of the total effort spent to develop a full software. There are basically three
types of maintenance:
• Corrective Maintenance: This type of maintenance is carried out to correct errors that were not
discovered during the product development phase.
• Perfective Maintenance: This type of maintenance is carried out to enhance the functionalities of the
system based on the customer’s request.
• Adaptive Maintenance: Adaptive maintenance is usually required for porting the software to work in
a new environment such as work on a new computer platform or with a new operating system.
When To Use Waterfall Model-Application
SDLC Waterfall model is used when

• Requirements are initially well known
• Requirements are stable and not changed frequently.
• An application is small.
• There is no requirement which is not understood or not very clear.
• The environment is stable
• The tools and techniques used is stable and is not dynamic
• Resources are well trained and are available.
Waterfall Model - Advantages
• Simple and easy to understand and use

• Easy to manage due to the rigidity of the model. Each phase has specific deliverables
and a review process.
• Phases are processed and completed one at a time.
• Works well for smaller projects where requirements are very well understood.
• Clearly defined stages.
• Well understood milestones.
• Easy to arrange tasks.
• Process and results are well documented.
Waterfall Model - Disadvantages
Classical waterfall model suffers from various shortcomings, basically we

can’t use it in real projects, but we use other software development
lifecycle models which are based on the classical waterfall model. Below
are some major drawbacks of this model:
• No feedback path: In classical waterfall model evolution of a software
from one phase to another phase is like a waterfall. It assumes that no
error is ever committed by developers during any phases. Therefore, it
does not incorporate any mechanism for error correction.
• Difficult to accommodate change requests: This model assumes that all
the customer requirements can be completely and correctly defined at
the beginning of the project, but actually customers’ requirements keep
on changing with time. It is difficult to accommodate any change
requests after the requirements specification phase is complete.
• No overlapping of phases: This model recommends that new phase can
start only after the completion of the previous phase. But in real
projects, this can’t be maintained. To increase the efficiency and reduce
the cost, phases may overlap.
Other drawbacks includes:
• No working software is produced until late during the life cycle.

• High amounts of risk and uncertainty.
• Not a good model for complex and object-oriented projects.
• Poor model for long and ongoing projects.
• Not suitable for the projects where requirements are at a moderate to high risk of
changing. So, risk and uncertainty is high with this process model.
• It is difficult to measure progress within stages.
• Cannot accommodate changing requirements.
• Adjusting scope during the life cycle can end a project.
• Integration is done as a "big-bang. at the very end, which doesn't allow identifying any
technological or business bottleneck or challenges early.
Iterative Waterfall Model
• Classical waterfall model is idealistic:

• assumes that no defect is introduced during any development activity.
• in practice:
• defects do get introduced in almost every phase of the life cycle.
• Defects usually get detected much later in the life cycle:
• For example, a design defect might go unnoticed till the coding or testing phase.
• Once a defect is detected:
• we need to go back to the phase where it was introduced
• redo some of the work done during that and all subsequent phases.
• Therefore we need feedback paths in the classical waterfall model.
Iterative Waterfall Model-representation
• Errors should be detected in the same phase in which they are introduced.
• For example:
• if a design problem is detected in the design phase itself,
• the problem can be taken care of much more easily
• than say if it is identified at the end of the integration and system testing
phase.
• Reason: rework must be carried out not only to the design but also to code and test
phases.
• The principle. of detecting errors as close to its point of introduction as possible is
known as phase containment of errors
• Iterative waterfall model is by far the most widely used model.
• Almost every other model is derived from the waterfall model.
Advantages of Iterative Waterfall Model
• Feedback Path: In the classical waterfall model, there are no feedback paths, so there is
no mechanism for error correction. But in iterative waterfall model feedback path from
one phase to its preceding phase allows correcting the errors that are committed and
these changes are reflected in the later phases.
• Simple: Iterative waterfall model is very simple to understand and use. That’s why it is
one of the most widely used software development models.
Drawbacks of Iterative Waterfall Model
• Difficult to incorporate change requests: The major drawback of the iterative waterfall model is that
all the requirements must be clearly stated before starting of the development phase. Customer may
change requirements after some time but the iterative waterfall model does not leave any scope to
incorporate change requests that are made after development phase starts.
• Incremental delivery not supported: In the iterative waterfall model, the full software is completely
developed and tested before delivery to the customer. There is no scope for any intermediate
delivery. So, customers have to wait long for getting the software.
• Overlapping of phases not supported: Iterative waterfall model assumes that one phase can start
after completion of the previous phase, But in real projects, phases may overlap to reduce the effort
and time needed to complete the project.
• Risk handling not supported: Projects may suffer from various types of risks. But, Iterative waterfall
model has no mechanism for risk handling.
• Limited customer interactions: Customer interaction occurs at the start of the project at the time of
requirement gathering and at project completion at the time of software delivery. These fewer
interactions with the customers may lead to many problems as the finally developed software may
differ from the customers’ actual requirements.
Thank You!
Prototyping Model
• Throw Away Prototyping

• Evolutionary Prototyping
Prototyping Model
• Prototyping is defined as the process of developing a working replication of a product

or system that has to be engineered. It offers a small scale facsimile of the end product
and is used for obtaining customers feedback.
• The Prototyping Model is one of the most popularly used Software Development Life
Cycle Models (SDLC models).
• This model is used when the customers do not know the exact project requirements
beforehand.
• In this model, a prototype of the end product is first developed, tested and refined as
per customer feedback repeatedly till a final acceptable prototype is achieved which
forms the basis for developing the final product.
• Final Product is developed using Iterative Waterfall approach.
Prototyping Model-Representation
• A prototype is a toy implementation of a system:
• limited functional capabilities,
• low reliability,
• inefficient performance.
• Small scale
• Developed using shortcuts
• Start with approximate requirements.
• Carry out a quick design.
• Prototype model is built using several short-cuts:
• Short-cuts might involve using inefficient, inaccurate, or dummy functions.
• A function may use a table look-up rather than performing the actual computations.
• The developed prototype is submitted to the customer for his evaluation:
• Based on the user feedback, requirements are refined.
• This cycle continues until the user approves the prototype.
• The actual system is developed using the iterative waterfall approach.
When to use prototyping Model-Application?
• The Prototyping Model should be used when the requirements of the product are not
clearly understood or are unstable.
• It is also a very good choice to demonstrate the technical feasibility of the product.
• Prototype model should be used when the desired system needs to have a lot of
interaction with the end users.
• Typically, online systems, web interfaces have a very high amount of interaction with
end users, are best suited for Prototype model. It might take a while for a system to be
built that allows ease of use and needs minimal training for the end user.
• Prototyping ensures that the end users constantly work with the system and provide a
feedback which is incorporated in the prototype to result in a useable system. They are
excellent for designing good human computer interface systems.
Advantages –
• The customers get to see the partial product early in the life cycle. This ensures a
greater level of customer satisfaction and comfort.
• New requirements can be easily accommodated as there is scope for refinement.
• Missing functionalities can be easily figured out.
• Errors can be detected much earlier thereby saving a lot of effort and cost, besides
enhancing the quality of the software.
• The developed prototype can be reused by the developer for more complicated
projects in the future.
• Flexibility in design.
Disadvantages –
• Costly w.r.t time as well as money.

• There may be too much variation in requirements each time the prototype is evaluated
by the customer.
• Poor Documentation due to continuously changing customer requirements.
• It is very difficult for the developers to accommodate all the changes demanded by the
customer.
• There is uncertainty in determining the number of iterations that would be required
before the prototype is finally accepted by the customer.
• After seeing an early prototype, the customers sometimes demand the actual product
to be delivered soon.
• Developers in a hurry to build prototypes may end up with sub-optimal solutions.
• The customer might lose interest in the product if he/she is not satisfied with the initial
prototype.
Types of Prototyping Model
• Rapid Throwaway Prototyping –

This technique offers a useful method of exploring ideas and getting customer feedback
for each of them. In this method, a developed prototype need not necessarily be a part of
the ultimately accepted prototype. Customer feedback helps in preventing unnecessary
design faults and hence, the final prototype developed is of a better quality.
• Evolutionary Prototyping –
In this method, the prototype developed initially is incrementally refined on the basis of
customer feedback till it finally gets accepted. In comparison to Rapid Throwaway
Prototyping, it offers a better approach which saves time as well as effort. This is because
developing a prototype from scratch for every iteration of the process can sometimes be
very frustrating for the developers.
Summary
• In Software Engineering, Prototype methodology is a software development model in

which a prototype is built, test and then reworked when needed until an acceptable
prototype is achieved.
• 1) Requirements gathering and analysis, 2) Quick design, 3) Build a Prototype, 4) Initial
user evaluation, 5) Refining prototype, 6)Implement Product and Maintain; are the
basic steps of the prototyping process
• Type of prototyping models are 1) Rapid Throwaway prototypes 2) Evolutionary
prototype
• Regular meetings are essential to keep the project on time and avoid costly delays in
prototyping approach.
• Missing functionality can be identified, which helps to reduce the risk of failure as
Prototyping is also considered as a risk reduction activity in SDLC.
• Prototyping may encourage excessive change requests.
Thank You!
SDLC - Iterative Model
Iterative Model
• In an Iterative model, initially, a partial implementation of a total system is constructed

so that it will be in a deliverable state.
• Increased functionality is added.
• Defects, if any, from the prior delivery are fixed and the working product is delivered.
• The process is repeated until the entire product development is completed.
• The repetitions of these processes are called iterations.
• At the end of every iteration, a product increment is delivered.
Iterative Model-representation
Phases of Iterative model
1. Requirement gathering & analysis: In this phase, requirements are gathered from customers and check
by an analyst whether requirements will fulfil or not. Analyst checks that need will achieve within budget
or not. After all of this, the software team skips to the next phase.
2. Design: In the design phase, team design the software by the different diagrams like Data Flow diagram,
activity diagram, class diagram, state transition diagram, etc.
3. Implementation: In the implementation, requirements are written in the coding language and
transformed into computer programs which are called Software.
4. Testing: After completing the coding phase, software testing starts using different test methods. There
are many test methods, but the most common are white box, black box, and grey box test methods.
5. Deployment: After completing all the phases, software is deployed to its work environment.
6. Review: In this phase, after the product deployment, review phase is performed to check the behaviour
and validity of the developed product. And if there are any error found then the process starts again from
the requirement gathering.
7. Maintenance: In the maintenance phase, after deployment of the software in the working environment
there may be some bugs, some errors or new updates are required. Maintenance involves debugging and
new addition options.
When to use the Iterative Model-Application?
• When requirements are defined clearly and easy to understand.

• When the software application is large.
• When there is a requirement of changes in future( unstable requirements).
• Most of the requirements are known up-front but are expected to evolve over time.
• The requirements are prioritized.
• There is a need to get the basic functionality delivered fast.
• A project has lengthy development schedules.
• A project has new technology.
• The domain is new to the team.
• Such methodology is more in use for web application and product based companies
Advantage(Pros) of Iterative Model:
• You can develop prioritized requirements first.

• Initial product delivery is faster.
• Customers gets important functionality early.
• Lowers initial delivery cost.
• Each release is a product increment, so that the customer will have a working product at hand all
the time.
• Customer can provide feedback to each product increment, thus avoiding surprises at the end of
development.
• Requirements changes can be easily accommodated.
• Testing and debugging during smaller iteration is easy.
• It is easily acceptable to ever-changing needs of the project.
• Risks are identified and resolved during iteration.
• Limited time spent on documentation and extra time on designing.
Disadvantage(Cons) of Iterative Model:
• It is not suitable for smaller projects.

• More Resources may be required.
• Design can be changed again and again because of imperfect requirements.
• Requirement changes can cause over budget.
• Project completion date not confirmed because of changing requirements.
• Requires effective planning of iterations.
• Requires efficient design to ensure inclusion of the required functionality and
provision for changes later.
• Requires early definition of a complete and fully functional system to allow the
definition of increments.
• Well-defined module interfaces are required, as some are developed long
before others are developed.
• Total cost of the complete system is not lower.
Thank You!
Evolutionary Model
Evolutionary model
• Evolutionary model is also referred to as the successive versions model and sometimes
as the incremental model.
• In Evolutionary model, the software requirement is first broken down into several
modules (or functional units) that can be incrementally constructed and delivered.
• The development first develops the core modules of the system. The core modules are
those that do not need services from the other modules.
• The initial product skeleton is refined into increasing levels of capability by adding new
functionalities in successive versions.
• Each evolutionary model may be developed using an iterative waterfall model of
development.
• The evolutionary model is shown in the figure. Each successive version/model of the
product is a fully functioning software capable of performing more work than the
previous versions/model.
Evolutionary Development of a Software Product
Evolutionary Model of Software Development
When to use the Evolutionary Model-Application?
• The evolutionary model is normally useful for very large products, where it is easier to
find modules for incremental implementation.
• Often, evolutionary model is used when the customer prefers to receive the product in
increments so that he can start using the different features as and when they are
developed rather than waiting all the time for the full product to be developed and
delivered.
• The evolutionary model is also very useful in object-oriented software development
because all the development is divided into different units.
Advantages of Evolutionary Model
• Large project: Evolutionary model is normally useful for very large products.
• User gets a chance to experiment with a partially developed software much before the
complete version of the system is released.
• Evolutionary model helps to accurately elicit user requirements during the delivery of
different versions of the software.
• The core modules get tested thoroughly, thereby reducing the chances of errors in the
core modules of the final products.
• Evolutionary model avoids the need to commit large resources in one go for
development of the system.
Other benefits include:
• Error reduction: As the version is tested with customer which reduces the error
thoroughly.
• User satisfaction: User gets satisfied and he gets the full chance of experimenting
partially developed system.
• Business benefit: Successful use of this model can benefit not only business result but
marketing and the internal operations as well.
• High quality: As you should get satisfied with every version, it produces the high quality
product.
• Low risk: There is significant reduction of risk as a versions is implemented. This risk
may be associated with : missing schedule deadline ,wrong feature sets , poor quality
etc.
• Reduction Cost: Some design issues are cheaper to resolve through experimentation
than through analysis. It reduces cost by providing structured and disciplined avenue for
experimentation.
Disadvantages of Evolutionary Model
• Difficult to divide the problem into several versions that would be acceptable to the
customer and which can be incrementally implemented and delivered.
• Several version release: Developer has to make table version which increases their
Efforts.
• Dividing software: It is difficult to "divide the software and the problems in several
versions that would be acceptable to the customer which can be implemented and
delivered incrementally.
• Uncertain nature of customer needs: A confused user has uncertainty over his
requirements, so giving him several version may change his requirement Rapidly.
• Time And Cost: As this model reduces "Time And Cost" but requirement is not gathered
correctly. It will subsequently time, cost and efforts.
• Confusion by several version: An user might get "confused by several versions of the
software. It will affect on the final product.
Thank You!
Spiral Model
Spiral Model
• Spiral model is one of the most important Software Development Life Cycle models,
which provides support for Risk Handling.
• Spiral model was given by Barry Boehm in 1986 .
• In its diagrammatic representation, it looks like a spiral with many loops. The exact
number of loops of the spiral is unknown and can vary from project to project. Each
loop of the spiral is called a Phase of the software development process. The exact
number of phases needed to develop the product can be varied by the project manager
depending upon the project risks. As the project manager dynamically determines the
number of phases, so the project manager has an important role to develop a product
using spiral model.
• The Radius of the spiral at any point represents the expenses(cost) of the project so far,
and the angular dimension represents the progress made so far in the current phase.
Spiral Model-Representation
Quadrants in Spiral Model
Each phase of Spiral Model is divided into four quadrants as shown in the above figure. The
functions of these four quadrants are discussed below-
• Objectives determination and identify alternative solutions: Requirements are gathered from
the customers and the objectives are identified, elaborated and analyzed at the start of every
phase. Then alternative solutions possible for the phase are proposed in this quadrant.
• Identify and resolve Risks: During the second quadrant all the possible solutions are evaluated
to select the best possible solution. Then the risks associated with that solution is identified and
the risks are resolved using the best possible strategy. At the end of this quadrant, Prototype is
built for the best possible solution.
• Develop next version of the Product: During the third quadrant, the identified features are
developed and verified through testing. At the end of the third quadrant, the next version of the
software is available.
• Review and plan for the next Phase: In the fourth quadrant, the Customers evaluate the so far
developed version of the software. In the end, planning for the next phase is started.
Risk Handling in Spiral Model
• A risk is any adverse situation that might affect the successful completion of a software
project. The most important feature of the spiral model is handling these unknown risks
after the project has started. Such risk resolutions are easier done by developing a
prototype. The spiral model supports coping up with risks by providing the scope to
build a prototype at every phase of the software development.
• Prototyping Model also support risk handling, but the risks must be identified
completely before the start of the development work of the project. But in real life
project risk may occur after the development work starts, in that case, we cannot use
Prototyping Model. In each phase of the Spiral Model, the features of the product dated
and analyzed and the risks at that point of time are identified and are resolved through
prototyping. Thus, this model is much more flexible compared to other SDLC models.
Why Spiral Model is called Meta Model ?
• The Spiral model is called as a Meta Model because it subsumes all the other SDLC
models. For example, a single loop spiral actually represents the Iterative Waterfall
Model. The spiral model incorporates the stepwise approach of the Classical Waterfall
Model. The spiral model uses the approach of Prototyping Model by building a
prototype at the start of each phase as a risk handling technique. Also, the spiral model
can be considered as supporting the evolutionary model – the iterations along the spiral
can be considered as evolutionary levels through which the complete system is built.
When to use Spiral Model-Applications?
• When project is large

• When releases are required to be frequent
• When creation of a prototype is applicable
• When risk and costs evaluation is important
• For medium to high-risk projects
• When requirements are unclear and complex
• When changes may require at any time
• When long term project commitment is not feasible due to changes in economic
priorities
Advantages of using Spiral Model:
• Risk Handling: The projects with many unknown risks that occur as the development
proceeds, in that case, Spiral Model is the best development model to follow due to the
risk analysis and risk handling at every phase.
• Good for large projects: It is recommended to use the Spiral Model in large and
complex projects.
• Flexibility in Requirements: Change requests in the Requirements at later phase can be
incorporated accurately by using this model.
• Customer Satisfaction: Customer can see the development of the product at the early
phase of the software development and thus, they habituated with the system by using
it before completion of the total product.
Disadvantages of using Spiral model:
• Complex: The Spiral Model is much more complex than other SDLC models.
• Expensive: Spiral Model is not suitable for small projects as it is expensive.
• Too much dependable on Risk Analysis: The successful completion of the project is
very much dependent on Risk Analysis. Without very highly experienced expertise, it is
going to be a failure to develop a project using this model.
• Difficulty in time management: As the number of phases is unknown at the start of the
project, so time estimation is very difficult.
Thank You!
SDLC- V Model
• also called as Verification and Validation Model

V-Model
• The V-model is a type of SDLC model where process executes in a sequential manner in
V-shape.
• It is also known as Verification and Validation model.
• It is based on the association of a testing phase for each corresponding development
stage.
• Development of each step directly associated with the testing phase.
• The next phase starts only after completion of the previous phase i.e. for each
development activity, there is a testing activity corresponding to it.
V-model representation
V-Model representing the document released after each phase
that assist in corresponding testing
Continue…
• 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.
Verification Phase of V-model:
• Requirement Analysis: This phase contains detailed communication with the customer
to understand their requirements and expectations. This stage is known as Requirement
Gathering.
• System Design: This phase contains the system design and the complete hardware and
communication setup for developing product.
• Architectural Design: System design is broken down further into modules taking up
different functionalities. The data transfer and communication between the internal
modules and with the outside world (other systems) is clearly understood.
• Module Design: In this phase the system breaks down into small modules. The detailed
design of modules is specified, also known as Low-Level Design (LLD).
Validation Phase of V-model:
• Unit Testing: Unit Test Plans are developed during module design phase. These Unit
Test Plans are executed to eliminate bugs at code or unit level.
• Integration testing: After completion of unit testing Integration testing is performed. In
integration testing, the modules are integrated and the system is tested. Integration
testing is performed on the Architecture design phase. This test verifies the
communication of modules among themselves.
• System Testing: System testing test the complete application with its functionality, inter
dependency, and communication . It tests the functional and non-functional
requirements of the developed application.
• User Acceptance Testing (UAT): UAT is performed in a user environment that resembles
the production environment. UAT verifies that the delivered system meets user’s
requirement and system is ready for use in real world.
Principles of V-Model:
• Large to Small: In V-Model, testing is done in a hierarchical perspective, For

example, requirements identified by the project team, create High-Level Design,
and Detailed Design phases of the project. As each of these phases is completed
the requirements, they are defining become more and more refined and
detailed.
• Data/Process Integrity: This principle states that the successful design of any
project requires the incorporation and cohesion of both data and processes.
Process elements must be identified at each and every requirements.
• Scalability: This principle states that the V-Model concept has the flexibility to
accommodate any IT project irrespective of its size, complexity or duration.
• Cross Referencing: Direct correlation between requirements and corresponding
testing activity is known as cross-referencing.
• Tangible Documentation: This principle states that every project needs to create
a document. This documentation is required and applied by both the project
development team and the support team. Documentation is used to
maintaining the application once it is available in a production environment.
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 V-Model?
• When the requirement is well defined and not ambiguous.

• The V-shaped model should be used for small to medium-sized projects where
requirements are clearly defined and fixed.
• The V-shaped model should be chosen when sample technical resources are available
with essential technical expertise.
Advantages:
• Easy to Understand.
• Testing Methods like planning, test designing happens well before coding.
• This saves a lot of time. Hence a higher chance of success over the waterfall model.
• Avoids the downward flow of the defects.
• Works well for small plans where requirements are easily understood.
Disadvantages:
• Very rigid and least flexible.

• Not a good for a complex project.
• Software is developed during the implementation stage, so no early prototypes of the
software are produced.
• If any changes happen in the midway, then the test documents along with the required
documents, has to be updated.
Thank You!
Rapid Application Development (RAD) Model
RAD Model
• The Rapid Application Development Model was first proposed by IBM in 1980’s.
• It is based on prototyping and iterative development with no specific planning involved.
• Using the RAD model, software product is developed in a short period of time(60-90 days).
• The critical feature of this model is the use of powerful development tools and techniques.
• In RAD model the components or functions are developed in parallel as if they were mini projects.
The developments are time boxed, delivered and then assembled into a working prototype.
• This can quickly give the customer something to see and use and to provide feedback regarding the
delivery and their requirements.
• Rapid Application Development focuses on gathering customer requirements through workshops
or focus groups, early testing of the prototypes by the customer using iterative concept, reuse of
the existing prototypes (components), continuous integration and rapid delivery.
RAD Model representation
Phases of RAD Model
1.Business Modelling: The information flow among business functions is defined

by answering questions like what data drives the business process, what data is
generated, who generates it, where does the information go, who process it and
so on.
2. Data Modelling: The data collected from business modeling is refined into a set
of data objects (entities) that are needed to support the business. The attributes
(character of each entity) are identified, and the relation between these data
objects (entities) is defined.
3. Process Modelling: The information object defined in the data modeling phase
are transformed to achieve the data flow necessary to implement a business
function. Processing descriptions are created for adding, modifying, deleting, or
retrieving a data object.
4. Application Generation: Automated tools are used to facilitate construction of
the software; even they use the 4th GL techniques.
5. Testing & Turnover: Many of the programming components have already been
tested since RAD emphasis reuse. This reduces the overall testing time. But the
new part must be tested, and all interfaces must be fully exercised.
When to use RAD Model?
• RAD should be used only when a system can be modularized to be delivered in an

incremental manner.
• It should be used if there is a high availability of designers for Modelling.
• 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 project and working
prototypes are to be presented to customer in small iterations of 2-3 months.
Advantages of RAD Model
• Reduced development time.

• Increases reusability of components
• Quick initial reviews occur
• Encourages customer feedback
• Integration from very beginning solves a lot of integration issues.
Disadvantages of RAD Model
• Depends on strong team and individual performances 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.
• For smaller projects, we cannot use the RAD model.
• Inapplicable to cheaper projects as cost of modeling and automated code generation is
very high.
RAD Model Vs Traditional SDLC
• The traditional SDLC follows a rigid process models with high emphasis on requirement
analysis and gathering before the coding starts. It puts pressure on the customer to sign
off the requirements before the project starts and the customer doesn’t get the feel of
the product as there is no working build available for a long time.
• The customer may need some changes after he gets to see the software. However, the
change process is quite rigid and it may not be feasible to incorporate major changes in
the product in the traditional SDLC.
• The RAD model focuses on iterative and incremental delivery of working models to the
customer. This results in rapid delivery to the customer and customer involvement
during the complete development cycle of product reducing the risk of non-
conformance with the actual user requirements.
Thank You!
The Rational Unified Process (RUP) Model
RUP Model
• The Rational Unified Process (RUP) is an iterative software development framework.

• It was created by the Rational Software Corporation, a division of IBM since 2003.
• The Rational Unified Process is a modern generic process model that is organized into
phases(inception, elaboration, construction, and transition) but separates activities
(requirements, analysis, and design, etc.) from these phases.
• RUP incrementally grows an effective solution over multiple iterations
• A modern generic process derived from the work on the UML and associated process.
• 3 perspectives of RUP Model
• A dynamic perspective that shows phases over time;
• A static perspective that shows process activities;
• A practice perspective that suggests good practice.
• Unified modeling language :The RUP is a guide for how to effectively use the Unified
Modeling Language(UML). The UML is a industry-standard language that allows us to
clearly communicate requirements, architectures and designs.
• Tools: They are used to create and maintain visual modeling, programming, testing.
• Configurable process: The Unified Process fits small development teams as well as large
development organizations.
RUP Model representation
Phases in the Rational Unified Process
• Inception
- Establish the business case for the system.
• Elaboration
- Develop an understanding of the problem domain and the system
architecture.
• Construction
- System design, programming and testing.
• Transition
- Deploy the system in its operating environment.
RUP Iterations
• In-phase iteration
- Each phase is iterative with results developed incrementally.
• Cross-phase iteration
- As shown by the loop in the RUP model, the whole set of phases may be
enacted incrementally.
Static workflows in the Rational Unified Process
( 9 workflows= 6 core + 3 supporting)
Effort Distribution of Activities
RUP good practice
• Develop software iteratively

• Plan increments based on customer priorities and deliver highest priority
increments first.
• Manage requirements
• Explicitly document customer requirements and keep track of changes to these
requirements.
• Use component-based architectures
• Organize the system architecture as a set of reusable components.
• Visually model software
• Use graphical UML models to present static and dynamic views of the software.
• Verify software quality
• Ensure that the software meet’s organizational quality standards.
• Control changes to software
• Manage software changes using a change management system and
configuration management tools.
Thank You!
Agile Software Development
• eXtreme Programming(XP)
• Scrum
Rapid software development
• Rapid development and delivery is now often the most important requirement for
software systems
• Businesses operate in a fast –changing requirement and it is practically impossible
to produce a set of stable software requirements
• Software has to evolve quickly to reflect changing business needs.
• Rapid software development
• Specification, design and implementation are inter-leaved
• System is developed as a series of versions with stakeholders involved in version
evaluation
• User interfaces are often developed using an IDE and graphical toolset.
Agile methods
• Dissatisfaction with the overheads involved in software design methods of the 1980s
and 1990s led to the creation of agile methods. These methods:
• Focus on the code rather than the design
• Are based on an iterative approach to software development
• Are intended to deliver working software quickly and evolve this quickly to meet
changing requirements.
• The aim of agile methods is to reduce overheads in the software process (e.g. by
limiting documentation) and to be able to respond quickly to changing requirements
without excessive rework.
Agile manifesto
• We are uncovering better ways of developing software by doing it and helping others
do it. Through this work we have come to value:
-Individuals and interactions over processes and tools
-Working software over comprehensive documentation
-Customer collaboration over contract negotiation
-Responding to change over following a plan
• That is, while there is value in the items on the right, we value the items on the left
more.
The principles of agile methods
Agile method applicability
• Product development where a software company is developing a small or medium-

sized product for sale.
• Custom system development within an organization, where there is a clear
commitment from the customer to become involved in the development process and
where there are not a lot of external rules and regulations that affect the software.
• Because of their focus on small, tightly-integrated teams, there are problems in scaling
agile methods to large systems.
Problems with agile methods
• It can be difficult to keep the interest of customers who are involved in the process.
• Team members may be unsuited to the intense involvement that characterizes agile
methods.
• Prioritizing changes can be difficult where there are multiple stakeholders.
• Maintaining simplicity requires extra work.
• Contracts may be a problem as with other approaches to iterative development.
Plan-driven and agile development
• Plan-driven development
• A plan-driven approach to software engineering is based around separate
development stages with the outputs to be produced at each of these stages
planned in advance.
• Not necessarily waterfall model – plan-driven, incremental development is
possible
• Iteration occurs within activities.
• Agile development
• Specification, design, implementation and testing are inter-leaved and the outputs
from the development process are decided through a process of negotiation
during the software development process.
Plan-driven and agile specification
Agile Methods
• eXtreme Programming(XP)?
• Scrum ?
Thank You!
Prepared by : Neha Tripathi
Agile Software Development- eXtreme Programming(XP)
• Agile methods are incremental development methods that focus on rapid development,
frequent releases of the software, reducing process overheads and producing high-
quality code. They involve the customer directly in the development process.
• The decision on whether to use an agile or a plan-driven approach to development
should depend on the type of software being developed, the capabilities of the
development team and the culture of the company developing the system.
• Extreme programming is a well-known agile method that integrates a range of good
programming practices such as frequent releases of the software, continuous
software improvement and customer participation in the development team.
eXtreme Programming(XP)
• Perhaps the best-known and most widely used agile method.

• Extreme Programming (XP) takes an ‘extreme’ approach to iterative development.
• New versions may be built several times per day;
• Increments are delivered to customers every 2 weeks;
• All tests must be run for every build and the build is only accepted if tests run
successfully.
XP and agile principles
• Incremental development is supported through small, frequent system releases.

• Customer involvement means full-time customer engagement with the team.
• People not process through pair programming, collective ownership and a process that
avoids long working hours.
• Change supported through regular system releases.
• Maintaining simplicity through constant refactoring of code.
The Extreme Programming release cycle
Extreme programming practices (a)
Extreme programming practices (b)
Requirements scenarios
• In XP, a customer or user is part of the XP team and is responsible for making decisions
on requirements.
• User requirements are expressed as scenarios or user stories.
• These are written on cards and the development team break them down into
implementation tasks. These tasks are the basis of schedule and cost estimates.
• The customer chooses the stories for inclusion in the next release based on their
priorities and the schedule estimates.
Refactoring
• Programming team look for possible software improvements and make these
improvements even where there is no immediate need for them.
• This improves the understandability of the software and so reduces the need for
documentation.
• Changes are easier to make because the code is well-structured and clear.
• However, some changes requires architecture refactoring and this is much more
expensive.
• Example: Tidying up and renaming attributes and methods to make them easier to
understand.
Test-first development
• Writing tests before code clarifies the requirements to be implemented.

• Tests are written as programs rather than data so that they can be executed
automatically. The test includes a check that it has executed correctly.
• Usually relies on a testing framework such as Junit.
• All previous and new tests are run automatically when new functionality is added, thus
checking that the new functionality has not introduced errors.
Pair programming
• In XP, programmers work in pairs, sitting together to develop code.

• This helps develop common ownership of code and spreads knowledge across
the team.
• It serves as an informal review process as each line of code is looked at by more
than 1 person.
• It encourages refactoring as the whole team can benefit from this.
• Measurements suggest that development productivity with pair programming is
similar to that of two people working independently.
• In pair programming, programmers sit together at the same workstation to
develop the software.
• Pairs are created dynamically so that all team members work with each other
during the development process.
• The sharing of knowledge that happens during pair programming is very
important as it reduces the overall risks to a project when team members leave.
• Pair programming is not necessarily inefficient and there is evidence that a pair
working together is more efficient than 2 programmers working separately.
Advantages of pair programming
• It supports the idea of collective ownership and responsibility for the system.
• Individuals are not held responsible for problems with the code. Instead, the team
has collective responsibility for resolving these problems.
• It acts as an informal review process because each line of code is looked at by at least
two people.
• It helps support refactoring, which is a process of software improvement.
• Where pair programming and collective ownership are used, others benefit
immediately from the refactoring so they are likely to support the process.
Thank You!
Agile project management-Scrum
• A particular strength of extreme programming is the development of automated tests

before a program feature is created. All tests must successfully execute when an
increment is integrated into a system.
• The principal responsibility of software project managers is to manage the project so
that the software is delivered on time and within the planned budget for the project.
• The standard approach to project management is plan-driven. Managers draw up a plan
for the project showing what should be delivered, when it should be delivered and who
will work on the development of the project deliverables.
• Agile project management requires a different approach, which is adapted to
incremental development and the particular strengths of agile methods.
• The Scrum method is an agile method that provides a project management framework.
It is centred round a set of sprints, which are fixed time periods when a system
increment is developed.
Scrum: Phases
• The Scrum approach is a general agile method but its focus is on managing iterative
development rather than specific agile practices.
• There are three phases in Scrum.
• The initial phase is an outline planning phase where you establish the general
objectives for the project and design the software architecture.
• This is followed by a series of sprint cycles, where each cycle develops an
increment of the system.
• The project closure phase wraps up the project, completes required
documentation such as system help frames and user manuals and assesses the
lessons learned from the project.
The Scrum process
The Sprint cycle
• Sprints are fixed length, normally 2–4 weeks. They correspond to the development of a
release of the system in XP.
• The starting point for planning is the product backlog, which is the list of work to be
done on the project.
• The selection phase involves all of the project team who work with the customer to
select the features and functionality to be developed during the sprint.
• Once these are agreed, the team organize themselves to develop the software. During
this stage the team is isolated from the customer and the organization, with all
communications channelled through the so-called ‘Scrum master’.
• The role of the Scrum master is to protect the development team from external
distractions.
• At the end of the sprint, the work done is reviewed and presented to stakeholders. The
next sprint cycle then begins.
Teamwork in Scrum
• The ‘Scrum master’ is a facilitator who arranges daily meetings, tracks the backlog of
work to be done, records decisions, measures progress against the backlog and
communicates with customers and management outside of the team.
• The whole team attends short daily meetings(“Stand-up meeting”) where all team
members share information, describe their progress since the last meeting, problems
that have arisen and what is planned for the following day.
• This means that everyone on the team knows what is going on and, if problems
arise, can re-plan short-term work to cope with them.
Scrum benefits
• The product is broken down into a set of manageable and understandable chunks.
• Unstable requirements do not hold up progress.
• The whole team have visibility of everything and consequently team communication is
improved.
• Customers see on-time delivery of increments and gain feedback on how the product
works.
• Trust between customers and developers is established and a positive culture is created
in which everyone expects the project to succeed.
Thank You!
Case studies
 A personal insulin pump

▪ An embedded system in an insulin pump used by diabetics to
maintain blood glucose control.
 A mental health care patient management system(MHC-
PMS)
▪ A system used to maintain records of people receiving care for
mental health problems.
230
Insulin pump control system
 Collects data from a blood sugar sensor and calculates

the amount of insulin required to be injected.
 Calculation based on the rate of change of blood sugar
levels.
 Sends signals to a micro-pump to deliver the correct
dose of insulin.
 Safety-critical system as low blood sugars can lead to
brain malfunctioning, coma and death; high-blood sugar
levels have long-term consequences such as eye and
kidney damage.
231
Insulin pump hardware architecture
232
Activity model of the insulin pump
233
Essential high-level requirements
 The system shall be available to deliver insulin when

required.
 The system shall perform reliably and deliver the correct
amount of insulin to counteract the current level of blood
sugar.
 The system must therefore be designed and
implemented to ensure that the system always meets
these requirements.
234
A patient information system for mental health
care
 A patient information system to support mental health

care is a medical information system that maintains
information about patients suffering from mental health
problems and the treatments that they have received.
 Most mental health patients do not require dedicated
hospital treatment but need to attend specialist clinics
regularly where they can meet a doctor who has detailed
knowledge of their problems.
 To make it easier for patients to attend, these clinics are
not just run in hospitals. They may also be held in local
medical practices or community centres.
235
MHC-PMS
 The MHC-PMS (Mental Health Care-Patient

Management System) is an information system that is
intended for use in clinics.
 It makes use of a centralized database of patient
information but has also been designed to run on a PC,
so that it may be accessed and used from sites that do
not have secure network connectivity.
 When the local systems have secure network access,
they use patient information in the database but they can
download and use local copies of patient records when
they are disconnected.
236
MHC-PMS goals
 To generate management information that allows health

service managers to assess performance against local
and government targets.
 To provide medical staff with timely information to
support the treatment of patients.
237
The organization of the MHC-PMS
238
MHC-PMS key features
 Individual care management

▪ Clinicians can create records for patients, edit the information in
the system, view patient history, etc. The system supports data
summaries so that doctors can quickly learn about the key
problems and treatments that have been prescribed.
 Patient monitoring
▪ The system monitors the records of patients that are involved in
treatment and issues warnings if possible problems are detected.
 Administrative reporting
▪ The system generates monthly management reports showing the
number of patients treated at each clinic, the number of patients
who have entered and left the care system, number of patients
sectioned, the drugs prescribed and their costs, etc.
239
MHC-PMS concerns
 Privacy
▪ It is essential that patient information is confidential and is never
disclosed to anyone apart from authorised medical staff and the
patient themselves.
 Safety
▪ Some mental illnesses cause patients to become suicidal or a
danger to other people. Wherever possible, the system should
warn medical staff about potentially suicidal or dangerous
patients.
▪ The system must be available when needed otherwise safety
may be compromised and it may be impossible to prescribe the
correct medication to patients.
240
Unit II
Requirement Analysis and Specification
Requirement Analysis and Specification phase- An overview
• The requirements analysis and specification phase starts after the feasibility study stage
is complete and the project has been found to be financially viable and technically
feasible.
• The requirements analysis and specification phase ends when the requirements
specification document has been developed and reviewed.
• The requirements specification document is usually called as the Software
Requirements Specification (SRS) document.
• The goal of the requirements analysis and specification phase is to clearly understand
the customer requirements and to systematically organize the requirements into a
document called the Software Requirements Specification (SRS) document.
• The engineers who gather and analyze customer requirements and then write the
requirements specification document are known as System Analyst.
What is Software Requirement?
• Requirements are descriptions of the services that a software system must provide and
the constraints under which it must operate
• Requirements can range from high-level abstract statements of services or system
constraints to detailed mathematical functional specifications
• IEEE defines requirement as
(1) A condition or capability needed by a user to solve a problem or achieve an objective.
(2) A condition or capability that must be met or possessed by a system or system component to satisfy a
contract, standard, specification, or other formally imposed documents.
(3) A documented representation of a condition or capability as in (1) or (2).
• Requirements Engineering is the process of establishing the services that the customer
requires from the system and the constraints under which it is to be developed and
operated. It includes: Requirement Elicitation, Requirement Analysis, Requirement
Specification, Requirement Validation and requirement Management.
Types of Requirements
• User requirements
• Statements in natural language plus diagrams of the services the system provides
and its operational constraints.
• Written for customers.
• System requirements
• A structured document setting out detailed descriptions of the system’s functions,
services and operational constraints.
• Written as a contract between client and contractor
Note: User and system requirements are further divided into Functional and Non-
Functional requirements.
User and system requirements
Functional and Non-Functional Requirements
• Functional requirements
• Statements of services the system should provide, how the system should react to
particular inputs and how the system should behave in particular situations.
• May state what the system should not do.
• Non-functional requirements
• Constraints on the services or functions offered by the system such as timing
constraints, constraints on the development process, standards, etc.
• Often apply to the system as a whole rather than individual features or services.
• Domain requirements
• Constraints on the system from the domain of operation
• Requirements that come from the application domain of the system that reflect
the characteristics of that domain
• May be functional or non-functional
Functional requirements
• Describe functionality or system services.

• Depend on the type of software, expected users and the type of system where the
software is used.
• Functional user requirements may be high-level statements of what the system should
do.
• Functional system requirements should describe the system services in detail.
Functional requirements for the MHC-PMS
• A user shall be able to search the appointments lists for all clinics.
• The system shall generate each day, for each clinic, a list of patients who are expected
to attend appointments that day.
• Each staff member using the system shall be uniquely identified by his or her 8-digit
employee number.
Non-functional requirements
• The non-functional requirements (also known as quality requirements) are related to

system attributes such as reliability and response time.
• Non-functional requirements arise due to user requirements, budget constraints,
organizational policies, and so on.
• These requirements are not related directly to any particular function provided by the
system.
• Non-functional requirements should be accomplished in software to make it perform
efficiently.
• Non-functional requirements may be more critical than functional requirements. If
these are not met, the system may be useless.
Types of non-functional requirement
Non-functional requirements implementation
• Non-functional requirements may affect the overall architecture of a system rather than
the individual components.
• For example, to ensure that performance requirements are met, you may have to organize the
system to minimize communications between components.
• A single non-functional requirement, such as a security requirement, may generate a
number of related functional requirements that define system services that are
required.
• It may also generate requirements that restrict existing requirements.
Non-functional classifications
• Product requirements
• Requirements which specify that the delivered product must behave in a
particular way e.g. execution speed, reliability, etc.
• Organisational requirements
• Requirements which are a consequence of organisational policies and procedures
e.g. process standards used, implementation requirements, etc.
• External requirements
• Requirements which arise from factors which are external to the system and its
development process e.g. interoperability requirements, legislative requirements,
etc.
Metrics for specifying non-functional requirements
(Non-functional requirements are difficult to verify. Hence, it is essential to write non-
functional requirements quantitatively, so that they can be tested. For this, non-functional
requirements metrics are used. These metrics are listed in Table.)
Thank you!
Unit-II
Requirement Engineering(RE) Process
Requirement Engineering
• Requirements engineering (RE) refers to the process of

defining, documenting, and maintaining requirements in the
engineering design process.
• Requirement engineering provides the appropriate
mechanism to understand what the customer desires,
analyzing the need, and assessing feasibility, negotiating a
reasonable solution, specifying the solution clearly,
validating the specifications and managing the requirements
as they are transformed into a working system.
• Thus, requirement engineering is the disciplined application
of proven principles, methods, tools, and notation to
describe a proposed system's intended behavior and its
associated constraints.
Requirement Engineering Process
• The requirements engineering process is an iterative process.

• It is a four-step process, which includes -
- Feasibility Study
- Requirement Elicitation and Analysis
- Software Requirement Specification
- Software Requirement Validation
- Software Requirement Management
Feasibility Study:
• The objective behind the feasibility study is to create the reasons for developing the
software that is acceptable to users, flexible to change and conformable to established
standards.
Types of Feasibility:
• Technical Feasibility - Technical feasibility evaluates the current technologies, which are
needed to accomplish customer requirements within the time and budget.
• Operational Feasibility - Operational feasibility assesses the range in which the required
software performs a series of levels to solve business problems and customer
requirements.
• Economic Feasibility - Economic feasibility decides whether the necessary software can
generate financial profits for an organization.
1.Requirements Elicitation and Analysis:
• After an initial feasibility study, the next stage of the requirements engineering process
is requirements elicitation and analysis.
• This is also known as the gathering of requirements. Here, requirements are identified
with the help of customers and existing systems processes, if available.
• In this activity, software engineers work with customers and system end-users to find
out about the application domain, what services the system should provide, the
required performance of the system, hardware constraints, and so on.
• Analysis of requirements starts with requirement elicitation. The requirements are
analyzed to identify inconsistencies, ambiguities, redundancies, defects, omission, etc.
We describe requirements in terms of relationships and also resolve conflicts if any.
2.Requirement Specification
• The process of writing the user and system requirements in a requirements document
known as Software requirement Specification(SRS) document.
• This activity is used to produce formal software requirement models.
• All the requirements including the functional as well as the non-functional
requirements and the constraints are specified by these models in totality.
• During specification, more knowledge about the problem may be required which can
again trigger the elicitation process.
• The models used at this stage include ER diagrams, data flow diagrams(DFDs), function
decomposition diagrams(FDDs), data dictionaries, etc.
3. Requirement Validation
• Validation: It refers to a different set of tasks that ensures that the software that has
been built is traceable to customer requirements.
If requirements are not validated, errors in the requirement definitions would
propagate to the successive stages resulting in a lot of modification and rework.
The main steps for this process include:
• The requirements should be consistent with all the other requirements i.e no two
requirements should conflict with each other.
• The requirements should be complete in every sense.
• The requirements should be practically achievable.
• Reviews, buddy checks, making test cases, etc. are some of the methods used for this.
4. Requirement Management
• Requirement management is the process of analyzing, documenting, tracking,

prioritizing and agreeing on the requirement and controlling the communication to
relevant stakeholders.
• This stage takes care of the changing nature of requirements.
• It should be ensured that the SRS is as modifiable as possible so as to incorporate
changes in requirements specified by the end users at later stages too.
• Being able to modify the software as per requirements in a systematic and controlled
manner is an extremely important part of the requirements engineering process.
Thank You!
Unit-II
Requirement Elicitation and Analysis
• It is a four-step process, which includes -

- Feasibility Study
2.Requirements Elicitation and Analysis:
• After an initial feasibility study, the next stage of the requirements engineering process
is requirements elicitation and analysis.
• This is also known as the gathering of requirements. Here, requirements are identified
with the help of customers and existing systems processes, if available.
• In this activity, software engineers work with customers and system end-users to find
out about the application domain, what services the system should provide, the
required performance of the system, hardware constraints, and so on.
• Analysis of requirements starts with requirement elicitation. The requirements are
analyzed to identify inconsistencies, ambiguities, redundancies, defects, omission, etc.
We describe requirements in terms of relationships and also resolve conflicts if any.
Requirements Elicitation and Analysis-Stages
• Software engineers work with a range of system stakeholders to find out about the
application domain, the services that the system should provide, the required system
performance, hardware constraints, other systems, etc.
• Stages include:
• Requirements discovery,
• Requirements classification and organization,
• Requirements prioritization and negotiation,
• Requirements specification.
The requirements elicitation and analysis process
Process activities
• Requirements discovery
• Interacting with stakeholders to discover their requirements. Domain
requirements are also discovered at this stage.
• Requirements classification and organisation
• Groups related requirements and organises them into coherent clusters.
• Prioritisation and negotiation
• Prioritising requirements and resolving requirements conflicts.
• Requirements specification
• Requirements are documented and input into the next round of the spiral.
Requirements discovery
• The process of gathering information about the required and existing systems and
distilling the user and system requirements from this information.
• Interaction is with system stakeholders from managers to external regulators.
• Systems normally have a range of stakeholders.
Stakeholders in the MHC-PMS
• Patients whose information is recorded in the system.

• Doctors who are responsible for assessing and treating patients.
• Nurses who coordinate the consultations with doctors and administer some
treatments.
• Medical receptionists who manage patients’ appointments.
• IT staff who are responsible for installing and maintaining the system.
• A medical ethics manager who must ensure that the system meets current ethical
guidelines for patient care.
• Health care managers who obtain management information from the system.
• Medical records staff who are responsible for ensuring that system information can be
maintained and preserved, and that record keeping procedures have been properly
implemented.
Requirement Elicitation techniques
• Requirements Elicitation is the process to find out the requirements for an intended software system by communicating with client, end users,
system users and others who have a stake in the software system development.
• There are various ways to discover requirements
- Interviews
- Questionnaires
- Onsite observation
- Survey
- Existing manuals and documentation
- www
- Group discussion
- Scenarios
- Use cases
- Prototyping
- Ethnography
- Brainstorming etc.
Problems of requirements elicitation
• Stakeholders don’t know what they really want.

• Stakeholders express requirements in their own terms.
• Different stakeholders may have conflicting requirements.
• Organisational and political factors may influence the system requirements.
• The requirements change during the analysis process. New stakeholders may emerge
and the business environment change.
Thank You!
Unit-II
Software Requirement Specification
SOFTWARE REQUIREMENTS SPECIFICATION (SRS)
• After the analyst has gathered all the required information regarding the software to be
developed, and has removed all incompleteness, inconsistencies, and anomalies from the
specification, he starts to systematically organize the requirements in the form of an SRS
document.
• The SRS is the official statement of what is required of the system developers.
• It include definition of user requirements and a specification of the system requirements.
• SRS should set of WHAT the system should do rather than HOW it should do it.
• Among all the documents produced during a software development life cycle, SRS
document is probably the most important document and is the toughest to write. One
reason for this difficulty is that the SRS document is expected to cater to the needs of a wide
variety of audience.
• Users of SRS Document- Users, customers, and marketing personnel, Software developers,
Test engineers, User documentation writers, Project managers, Maintenance engineers etc.
SRS
• SRS document is considered to be a basic reference document.
• SRS document serves as the documentation of a contract between the development
team and the customer.
• SRS serves as an agreement as it is signed by Customer and developers both .
• The SRS document can be used to resolve any disagreements between the developers
and the customers that may arise in the future.
• The SRS document can even be used as a legal document to settle disputes between
the customers and the developers in a court of law.
• Once the customer agrees to the SRS document, the development team proceeds to
develop the software and ensure that it conforms to all the requirements mentioned in
the SRS document.
• The SRS document should describe the system to be developed as a black box, and
should specify only the externally visible behavior of the system. For this reason, the
SRS document is also called the black-box specification of the software being
developed.
Parts of a SRS document
The important parts of SRS document are:

• Functional requirements of the system-functional system
requirements describe the system functions, its inputs and outputs, exceptions, etc., in detail.
• Non-functional requirements of the system -

Nonfunctional requirements deal with the characteristics of the system which can not be expressed
as functions - such as the maintainability of the system, portability of the system, usability of the
system, etc.
• Goals of implementation-The goals of implementation part documents some

general suggestions regarding development. These suggestions guide trade-off among design goals. The
goals of implementation section might document issues such as revisions to the system functionalities that
may be required in the future, new devices to be supported in the future, reusability issues, etc.
Characteristics of a Good SRS Document
• Concise
• Structured
• Black-box view
• Conceptual integrity
• Response to undesired events
• Verifiable
• Modifiable/Maintainable
• Traceable
• Scalable
• Testable
Attributes of Bad SRS Documents
• Over-specification
• Forward references
• Wishful thinking
• Noise
Ways of writing a system requirements specification
The structure of a requirements document
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.
Thank You!
Unit-II
Software Requirement Validation

Requirements Validation
• Requirements validation is the process of checking the requirements for validity,

consistency, completeness, realism and verifiability.
• Concerned with demonstrating that the requirements define the system that the
customer really wants.
• Requirements error costs are high so validation is very important
• Fixing a requirements error after delivery may cost up to 100 times the cost of
fixing an implementation error.
Requirements checking
• Validity. Does the system provide the functions which best support the customer’s
needs?
• Consistency. Are there any requirements conflicts?
• Completeness. Are all functions required by the customer included?
• Realism. Can the requirements be implemented given available budget and technology
• Verifiability. Can the requirements be checked?
Requirements validation techniques
• Requirements reviews
• Systematic manual analysis of the requirements.
• Prototyping
• Using an executable model of the system to check requirements.
• Test-case generation
• Developing tests for requirements to check testability.
Requirements Reviews
• Regular reviews should be held while the requirements definition is being formulated.
• Both client and contractor staff should be involved in reviews.
• Reviews may be formal (with completed documents) or informal. Good
communications between developers, customers and users can resolve problems at an
early stage.
Review checks
• Verifiability
• Is the requirement realistically testable?
• Comprehensibility
• Is the requirement properly understood?
• Traceability
• Is the origin of the requirement clearly stated?
• Adaptability
• Can the requirement be changed without a large impact on other requirements?
Software Requirement Management

Requirements Management
• Requirements management is the process of managing changing requirements during

the requirements engineering process and system development.
• Business, organizational and technical changes inevitably lead to changes to the
requirements for a software system. Requirements management is the process of
managing and controlling these changes.
• New requirements emerge as a system is being developed and after it has gone into
use.
• You need to keep track of individual requirements and maintain links between
dependent requirements so that you can assess the impact of requirements changes.
You need to establish a formal process for making change proposals and linking these to
system requirements.
Changing requirements
• The business and technical environment of the system always changes after installation.
• The people who pay for a system and the users of that system are rarely the same
people.
• Large systems usually have a diverse user community, with many users having different
requirements and priorities that may be conflicting or contradictory.
Requirements evolution
Requirements management planning
• Establishes the level of requirements management detail that is required.
• Requirements management decisions:
• Requirements identification Each requirement must be uniquely identified so that
it can be cross-referenced with other requirements.
• A change management process This is the set of activities that assess the impact
and cost of changes. I discuss this process in more detail in the following section.
• Traceability policies These policies define the relationships between each
requirement and between the requirements and the system design that should be
recorded.
• Tool support Tools that may be used range from specialist requirements
management systems to spreadsheets and simple database systems.
• Deciding if a requirements change should be accepted
• Problem analysis and change specification
• During this stage, the problem or the change proposal is analyzed to check
that it is valid. This analysis is fed back to the change requestor who may
respond with a more specific requirements change proposal, or decide to
withdraw the request.
• Change analysis and costing
• The effect of the proposed change is assessed using traceability information
and general knowledge of the system requirements. Once this analysis is
completed, a decision is made whether or not to proceed with the
requirements change.
• Change implementation
• The requirements document and, where necessary, the system design and
implementation, are modified. Ideally, the document should be organized so
that changes can be easily implemented.
Requirements Change Management
Thank You!
Unit-II
Analysis Tools
• Data Flow Diagrams(DFDs)

• Data Dictionary
• Decision Tree
• Decision Table
• Structured Chart
etc.
Design Approaches and Types
• Function Oriented approach

• Object Oriented approach
• Types of Design: System Design Structured Analysis(SA)

Detailed design Structured Design(SD)
• Structured Analysis Tools: DFDs, Data dictionary, Decision Tree, Decision Table, ERDs
etc.
• Structured Design Tools: Structured chart/Module dependency Graph
Structured Analysis/ Structured design (SA/SD)
• SA/SD methodology involves carrying out two distinct activities:

-Structured analysis (SA)
-Structured design (SD)
• During structured analysis, the SRS document is transformed into a data flow diagram
(DFD) model.
• During structured design, the DFD model is transformed into a structure chart.
Structured Analysis
• Structured analysis is used to carry out the top-down decomposition of a set of high-
level functions depicted in the problem description and to represent them graphically.
During structured analysis, functional decomposition of the system is achieved. That is,
each function that the system performs is analyzed and hierarchically decomposed into
more detailed functions.
• Structured analysis technique is based on the following essential underlying principles:
• Top-down decomposition approach.

• Divide and conquer principle. Each function is decomposed independently.
• Graphical representation of the analysis results using Data Flow Diagrams(DFDs).
Data Flow Diagram (DFD)
• The DFD (also known as a bubble chart) is a hierarchical graphical model of a system
that shows the different processing activities or functions that the system performs and
the data interchange among these functions.
• Each function is considered as a processing station (or process) that consumes some
input data and produces some output data.
• The system is represented in terms of the input data to the system, various processing
carried out on these data, and the output data generated by the system.
• A DFD model uses a very limited number of primitive symbols to represent the
functions performed by a system and the data flow among these functions.
Primitive symbols used for constructing DFDs
Important concepts associated with constructing DFD models
• Synchronous and Asynchronous DFD

Balancing DFDs:
The data that flow into or out of a bubble must match the data flow at the next level of
DFD. This is known as balancing a DFD.
Numbering of bubbles
• It is necessary to number the different bubbles occurring in the DFD.

• These numbers help in uniquely identifying any bubble in the DFD from its bubble
number.
• The bubble at the context level is usually assigned the number 0 to indicate that it is the
0 level DFD.
• Bubbles at level 1 are numbered, 0.1, 0.2, 0.3, etc. When a bubble numbered x is
decomposed, its children bubble are numbered x.1, x.2, x.3, etc.
• In this numbering scheme, by looking at the number of a bubble we can unambiguously
determine its level, its ancestors, and its successors.
DEVELOPING THE DFD MODEL OF A SYSTEM
• A DFD model of a system graphically represents how each input data is transformed to
its corresponding output data through a hierarchy of DFDs.
• The DFD model of a problem consists of many DFDs and a single data dictionary.
• The DFD model of a system i s constructed by using a hierarchy of DFDs called as Levels.
Levels of DFD
• 0-Level/Context DFD:
The context diagram is the most abstract (highest level) data flow representation of a system. It represents the
entire system as a single bubble. It establishes the context in which the system operates; that is, who are the
users, what data do they input to the system, and what data they received by the system.
• 1-Level DFD:
The level 1 DFD usually contains three to seven bubbles. That is, the system is represented as performing three
to seven important functions. To develop the level 1 DFD, examine the high-level functional requirements in
the SRS document.
• 2-Level/Detailed DFD:
The level 2 DFD is made for those bubbles in level 1 DFD whose details /decomposition is possible.
Rules for constructing DFD systematically in Levels:
1. Construction of context diagram: Examine the SRS document to determine:

• Different high-level functions that the system needs to perform.
• Data input to every high-level function.
• Data output from every high-level function.
• Interactions (data flow) among the identified high-level functions.
Represent these aspects of the high-level functions in a diagrammatic form. This would form the top-level data
flow diagram (DFD), usually called the DFD 0.
2.Construction of level 1 diagram:
Examine the high-level functions described in the SRS document.
• If there are three to seven high-level requirements in the SRS document, then represent each of the high-
level function in the form of a bubble.
• If there are more than seven bubbles, then some of them have to be combined.
• If there are less than three bubbles, then some of these have to be split.
3. Construction of lower-level diagrams: Decompose each high-level function into its constituent sub-
functions through the following set of activities:
• Identify the different sub-functions of the high-level function.
• Identify the data input to each of these sub-functions.
• Identify the data output from each of these sub-functions.
• Identify the interactions (data flow) among these sub-functions.
Represent these aspects in a diagrammatic form using a DFD. Recursively repeat Step 3 for each sub-function
until a sub-function can be represented by using a simple algorithm.
Example : (RMS Calculating Software)
• A software system called RMS calculating software would read three integral numbers
from the user in the range of –1000 and +1000 and would determine the root mean
square (RMS)of the three input numbers and display it.
• 0-Level/Context DFD:
• 1-Level DFD:
• 2-Level/Detailed DFD
Shortcomings of the DFD model
• Imprecise DFDs leave ample scope to be imprecise.

• Not-well defined control aspects are not defined by a DFD.
• Decomposition: The method of carrying out decomposition to arrive at the successive
levels and the ultimate level to which decomposition is carried out are highly subjective
and depend on the choice and judgment of the analyst.
• Improper data flow diagram: T he da ta flow diagramming technique does not provide
any specific guidance as to how exactly to decompose a given function into its sub-
functions and we have to use subjective judgment to carry out decomposition.
STRUCTURED DESIGN
• The aim of structured design is to transform the results of the structured analysis (that
is, the DFD model) into a structure chart.
• A structure chart represents the software architecture.
• The various modules making up the system, the module dependency (i.e. which module
calls which other modules), and the parameters that are passed among the different
modules.
• The structure chart representation can be easily implemented using some programming
language.
Notations Used:
• Rectangular boxes: A rectangular box represents a module.

• Module invocation arrows: An arrow connecting two modules implies that during
program execution control is passed from one module to the other in the direction of
the connecting arrow.
• Data flow arrows: These are small arrows appearing alongside the module invocation
arrows. The data flow arrows are annotated with the corresponding data name.
• Library modules: A library module is usually represented by a rectangle with double
edges. Libraries comprise the frequently called modules.
• Selection: The diamond symbol represents the fact that one module of several modules
connected with the diamond symbol i s invoked depending on the outcome of the
condition attached with the diamond symbol.
• Repetition: A loop around the control flow arrows denotes that the respective modules
are invoked repeatedly.
Example of Properly and poorly Layered design
Transformation of a DFD Model into Structured Chart
• Structured design provides two strategies to guide transformation of a DFD into a

structure chart:
-Transform analysis
-Transaction analysis
• If all the data flow into the diagram are processed in similar ways (i.e. if all the input
data flow arrows are incident on the same bubble in the DFD) the transform analysis is
applicable.
• Otherwise, transaction analysis is applicable.
• Normally, transform analysis is applicable only to very simple processing.
• Note: one would start with the level 1 DFD, transform it into module representation
using either the transform or transaction analysis and then proceed toward the lower
level DFDs.
Transform analysis
• Transform analysis identifies the primary functional components (modules) and

the input and output data for these components. The first step in transform
analysis is to divide the DFD into three types of parts:
- Input.
- Processing.
- Output.
• The input portion in the DFD includes processes that transform input data from
physical (e.g, character from terminal) to logical form (e.g. internal tables, lists,
etc.). Each input portion is called an afferent branch.
• The output portion of a DFD transforms output data from logical form to
physical form. Each output portion is called an efferent branch.
• The remaining portion of a DFD is called central transform.
• In the next step of transform analysis, the structure chart is derived by drawing
one functional component each for the central transform, the afferent and
efferent branches. These are drawn below a root module, which would invoke
these modules.
• The first level o f structure chart is produced by representing each input and output unit
as a box and each central transform as a single box.
• In the third step of transform analysis, the structure chart is refined by adding sub-
functions required by each of the high-level functional components.
• Many levels of functional components may be added. This process of breaking
functional components into subcomponents is called factoring.
• The factoring process is continued until all bubbles in the DFD are represented in the
structure chart.
Example : Draw the structure chart for the RMS software
• By observing the level 1 DFD, we can identify validate-input as the afferent branch and
write-output as the efferent branch. The remaining (i.e., compute-rms) as the central
transform.
• By applying the step 2 and step 3 of transform analysis, we get the structure chart
Transaction analysis
• As in transform analysis, first all data entering into the DFD need to be identified.
• In a transaction-driven system, different data items may pass through different computation
paths through the DFD. This is in contrast to a transform centered system where each data item
entering the DFD goes through the same processing steps.
• Each different way in which input data is processed is a transaction.
• A simple way to identify a transaction is the following. Check the input data. The number of
bubbles on which the input data to the DFD are incident defines the number of transactions.
However, some transactions may not require any input data. These transactions can be
identified based on the experience gained from solving a large number of examples.
• For each identified transaction, trace the input data to the output. All the traversed bubbles
belong to the transaction. These bubbles should be mapped to the same module on the
structure chart.
• In the structure chart, draw a root module and below this module draw each identified
transaction as a module.
• Every transaction carries a tag identifying its type. Transaction analysis uses this tag to divide the
system into transaction modules and a transaction-center module.
Thank You!
Unit-II
Prepared by:Neha Tripathi
Analysis Tools
• Data Flow Diagrams(DFDs)

• Data dictionary
• Decision Tree
• Decision Table
Data dictionary
• Every DFD model of a system must be accompanied by a data dictionary.
• A data dictionary lists all data items that appear in a DFD model.
• The data items listed include all data flows and the contents of all data stores appearing
on all the DFDs in a DFD model.
• A data dictionary lists the purpose of all data items and the definition of all composite data
items in terms of their component data items.
• For example, a data dictionary entry may represent that the data grossPay consists of the
components regularPay and overtimePay.
grossP ay = regularP ay + overtimePay
• For the smallest units of data items, the data dictionary simply lists their name and their
type. Composite data items are expressed in terms of the component data items using
certain operators.
Importance/Benefits of Data Dictionary
• A data dictionary provides a standard terminology for all relevant data for use by the
developers working in a project. A consistent vocabulary for data items is very important,
since in large projects different developers of the project have a tendency to use
different terms to refer to the same data, which unnecessarily causes confusion.
• The data dictionary helps the developers to determine the definition of different data
structures in terms of their component elements while implementing the design.
• The data dictionary helps to perform impact analysis. That is, it is possible to determine
the effect of some data on various processing activities and vice versa. Such impact
analysis is especially useful when one wants to check the impact of changing an input
value type, or a bug in some functionality, etc.
Tool support
• For large systems, the data dictionary can become extremely complex and
voluminous. Even moderate-sized projects can have thousands of entries in the
data dictionary. It becomes extremely difficult to maintain a voluminous
dictionary manually.
• Computer-aided software engineering (CASE) tools come handy to overcome
this problem. Most CASE tools usually capture the data items appearing in a DFD
as the DFD is drawn, and automatically generate the data dictionary.
• As a result, the designers do not have to spend almost any effort in creating the
data dictionary.
• These CASE tools also support some query language facility to query about the
definition and usage of data items.
• For example, queries may be formulated to determine which data item affects
which processes, or a process affects which data items, or the definition and
usage of specific data items, etc.
• Query handling is facilitated by storing the data dictionary in a relational database
management system (RDBMS).
Data definition
Composite data items can be defined in terms of primitive data items using the following
data definition operators.
• +: denotes composition of two data items, e.g. a+b represents data a and b.
• [,,]: represents selection, i.e. any one of the data items listed inside the square bracket
can occur For example, [a,b] represents either a occurs o r b occurs.
• (): the contents inside the bracket represent optional data which may or may not
appear. a+(b) represents either a or a+b occurs.
• {}: represents iterative data definition, e.g. {name}5 represents five name data. {name}*
represents zero or more instances of name data.
• =: represents equivalence, e.g. a=b+c means that a is a composite data item comprising
of both b and c.
• /* */: Anything appearing within /* and */ is considered as comment.
Decision Tree
• A decision tree gives a graphic view of the processing logic involved in decision making
and the corresponding actions taken.
• It is a graphical technique representing decisions using a series of nodes and branches
• Each node is a decision point - a choice has to be made
• Each branch has a corresponding value to the decision choice
• Subsequent action is the result
Example of Decision Tree
Decision Tables
• A matrix representation of the logic of a decision

• Specifies the possible conditions and the resulting actions
• Based on a set of conditions, different actions will be performed
• Best used for complicated decision logic
• Consists of three parts:
• Condition stubs
• Lists condition relevant to decision
• Action stubs
• Actions that result from a given set of conditions
• Rules
• Specify which actions are to be followed for a given set of conditions
Structure of Decision Table
Decision table for payroll system example
Constructing Decision Table
• Name the conditions and the values each condition can assume
• Name all possible actions that can occur
• List all possible rules
• Define the actions for each rule
• Simplify the decision table
Simplified Decision Table
Decision table versus decision tree
Even though both decision tables and decision trees can be used to represent
complex program logic, they can be distinguishable on the following three
considerations:
• Readability: Decision trees are easier to read and understand when the number
of conditions are small. On the other hand, a decision table causes the analyst to
look at every possible combination of conditions which he might otherwise omit.
• Explicit representation of the order of decision making: In contrast to the decision
trees, the order of decision making is abstracted out in decision tables. A
situation where decision tree is more useful is when multilevel decision making is
required. Decision trees can more intuitively represent multilevel decision
making hierarchically, whereas decision tables can only represent a single
decision to select the appropriate action for execution.
• Representing complex decision logic: Decision trees become very complex to
understand when the number of conditions and actions increase. It may even be
difficult to draw the tree on a single page. When very large number of decisions
are involved, the decision table representation may be preferred.
Thank You!

Software Engineering NOTES

Uploaded by

Software Engineering NOTES

Uploaded by

Software Engineering

Prepared by: Neha Tripathi

• Software engineering is an engineering discipline that is concerned

• The seminal definition:

• Computer science focuses on theory and fundamentals;

• Software Engineering is concerned with the practicalities of

• To acquire skills to develop large programs.

Prepared by: Neha Tripathi

• Program is a set of instructions written in a programming language used to execute

• Software is a collection of several programs and other procedures and

• Usually small in size • Large

Prepared by: Neha Tripathi

• Software crisis is the situation resulted due to the increment in

• Projects running over-budget

• Large and complex problems,

Prepared by: Neha Tripathi

• Software engineering is an engineering discipline which is

• The establishment and use of sound engineering principles in

Its characteristics that make it different from other things human

• This characteristic let us know about how well software works in

• This is an essential aspect when the software is moved from one

The necessity of software engineering appears because of a higher rate of progress

• Programs were being written in assembly language.

• High-level languages such as FORTRAN, ALGOL, and COBOL were introduced:

• Size and complexity of programs increased further:

• A program is called structured

• Soon it was discovered:

• Example of data structure-oriented design technique:

• Data flow-oriented techniques advocate:

• Use of Life Cycle Models

• Software life cycle (or software process):

• A software life cycle model (or process model):

• Software engineering is:

• It offers a basis for project planning, scheduling, and estimating

• Phase 1: Feasibility study

• Main aim of feasibility study:

• Economic: Can we complete the project within the budget or not?

• Aim of this phase:

• Collect all related data from the customer:

• Requirements Gathering/Elicitation-Functional/Non-functional requirements/Constraints

• Design phase transforms requirements specification:

• Once the software is complete, and it is deployed in the testing environment.

• Classical Waterfall Model

• The Waterfall Model was the first Process Model to be introduced.

SDLC Waterfall model is used when

• Simple and easy to understand and use

Classical waterfall model suffers from various shortcomings, basically we

• No working software is produced until late during the life cycle.

• Classical waterfall model is idealistic:

• Throw Away Prototyping

• Prototyping is defined as the process of developing a working replication of a product

• Costly w.r.t time as well as money.

• Rapid Throwaway Prototyping –

• In Software Engineering, Prototype methodology is a software development model in

• In an Iterative model, initially, a partial implementation of a total system is constructed

• When requirements are defined clearly and easy to understand.

• You can develop prioritized requirements first.

• It is not suitable for smaller projects.

• When project is large

• also called as Verification and Validation Model

• Large to Small: In V-Model, testing is done in a hierarchical perspective, For

• When the requirement is well defined and not ambiguous.

• Very rigid and least flexible.

1.Business Modelling: The information flow among business functions is defined

• RAD should be used only when a system can be modularized to be delivered in an

• Reduced development time.

• Depends on strong team and individual performances for identifying business

• The Rational Unified Process (RUP) is an iterative software development framework.

• Develop software iteratively

• Product development where a software company is developing a small or medium-

• Perhaps the best-known and most widely used agile method.

• Incremental development is supported through small, frequent system releases.

• Writing tests before code clarifies the requirements to be implemented.

• In XP, programmers work in pairs, sitting together to develop code.

• A particular strength of extreme programming is the development of automated tests

 A personal insulin pump