1. SHARBANI
BHATTACHARYA
Software Engineering-
Software Development Life Cycle
Govt. Polytechnic(W)
Faridabad
26th August 2016

2. Software Development Life
Cycle Models
 Waterfall Model
 Prototype Model
 Iterative or Evolutionary Model
 Spiral Model
 V – Model
 Big Bang Model

4. Software Development Life
Cycle

5. Communication
Communication with customer or requirement
analysis. Communication in team and
management of Software Company.
The user contacts the service provider and tries
to negotiate the terms, submits the request to
the service providing organization in writing.

6. Requirement Gathering
Gathering of information and put don into papers
or system specification and requirement
specification.
 Studying the existing or obsolete system and
software
 Conducting interviews of users and developers
 Referring to the database
 Collecting answers from the questionnaires

7. Feasibility Study
 After requirement gathering, the team comes up
with a rough plan of software process.
 At this step the team analyzes if a software can be
designed to fulfill all requirements of the user, and
if there is any possibility of software being no
more useful.
 It is also analyzed if the project is financially,
practically, and technologically feasible for the
organization to take up.
 There are many algorithms available, which help
the developers to conclude the feasibility of a
software project.

8. System Analysis
Analysis of the system and its working methods.
Workflow and dataflow is conceptualized.
 At this step the developers decide a roadmap of
their plan and try to bring up the best software
model suitable for the project.
 System analysis includes understanding of
software product limitations, learning system
related problems or changes to be done in
existing systems beforehand, identifying and
addressing the impact of project on organization
and personnel etc.
 The project team analyzes the scope of the
project and plans the schedule and resources
accordingly.

9. Software Design
Designing of the system. Defining , selecting and
planning architectural model.
To bring down whole knowledge of requirements
and analysis on the desk and design the software
product. The inputs from users and information
gathered in requirement gathering phase are the
inputs of this step.
The output of this step comes in the form of two
designs; logical design, and physical design.
Engineers produce meta-data and data dictionaries,
logical diagrams, data-flow diagrams, and in some
cases pseudo codes.

10. Coding
This step is also known as programming phase.
The implementation of software design starts in
terms of writing program code in the suitable
programming language and developing error-
free executable programs efficiently.

11. Testing
An estimate says that 50% of whole software
development process should be tested. Errors
may ruin the software from critical level to its
own removal.
Software testing is done while coding by the
developers and thorough testing is conducted by
testing experts at various levels of code such as
module testing, program testing, product testing,
in-house testing, and testing the product at
user’s end.
Early discovery of errors and their remedy is the
key to reliable software.

12. Integration
Software may need to be integrated with the
libraries, databases, and other program(s). This
stage of SDLC is involved in the integration of
software with outer world entities.

13. Implementation
This means installing the software on user
machines. At times, software needs post-
installation configurations at user end. Software
is tested for portability and adaptability and
integration related issues are solved during
implementation.

14. Operation & Maintenance
This phase confirms the software operation in
terms of more efficiency and less errors.
If required, the users are trained on, or aided
with the documentation on how to operate the
software and how to keep the software
operational.
The software is maintained timely by updating
the code according to the changes taking place
in user end environment or technology.
This phase may face challenges from hidden
bugs and real-world unidentified problems.

15. Disposition
Softwares which cannot be used further and
cannot changed either have to be disposed off.
 Example- Foxpro systems are dispose off or
new system on ERP on Oracle is developed
in a company.
 Oracle systems are dispose off or new system
on ERP on SAP is developed in a company.

16. Waterfall Model

17. Waterfall Model
 Requirements analysis and definition
 System and software design
 Implementation and unit testing
 Integration and system testing
 Operation and maintenance

18. Waterfall Model
The first published model of the software
development process was derived from
more general system engineering processes
(Royce, 1970).

19. Waterfall Model
Because of the cascade from one phase to
another, this model is known as the ‘waterfall
model’ or software life cycle. The waterfall model
is an example of a plan-driven process—in
principle, you must plan and schedule all of the
process activities before starting work on them.

20. Requirements Analysis and
Definition
The system’s services, constraints, and goals
are established by consultation with system
users. They are then defined in detail and serve
as a system specification.

21. System and Software Design
The systems design process allocates the
requirements to either hardware or software
systems by establishing an overall system
architecture. Software design involves identifying
and describing the fundamental software system
abstractions and their relationships.

22. Implementation and Unit Testing
During this stage, the software design is realized
as a set of programs or program units. Unit
testing involves verifying that each unit meets its
specification.

23. Integration and System Testing
The individual program units or programs are
integrated and tested as a complete system to
ensure that the software requirements have
been met. After testing, the software system is
delivered to the customer.

24. Operation and Maintenance
Normally (although not necessarily), this is the
longest life cycle phase. The system is installed
and put into practical use.
Maintenance involves correcting errors which
were not discovered in earlier stages of the life
cycle, improving the implementation of system
units and enhancing the system’s services as
new requirements are discovered.

25. Drawbacks of Waterfall Model
Its major problem is the inflexible partitioning
of the project into distinct stages. Commitments
must be made at an early stage in the process,
which makes it difficult to respond to changing
customer requirements.

26. Formal System Development
An important variant of the waterfall model is
formal system development, where a
mathematical model of a system specification is
created.
This model is then refined, using mathematical
transformations that preserve its consistency,
into executable code.
Based on the assumption that your
mathematical transformations are correct, you
can therefore make a strong argument that a
program generated in this way is consistent with
its specification.

27. Formal System Development
Formal development processes, such as that
based on the B method by Schneider,2001 and
Wordsworth, 1996.

28. Formal Development
Processes
It is particularly suited to the development of
systems that have stringent safety, reliability, or
security requirements.
The formal approach simplifies the production of
a safety or security case. This demonstrates to
customers or regulators that the system actually
meets its safety or security requirements.

29. Formal Development
Processes
Processes based on formal transformations are
generally only used in the development of
safety-critical or security-critical systems.
They require specialized expertise. For the
majority of systems this process does not offer
significant cost benefits over other approaches
to system development.

30. Prototype Model
A prototype is an initial version of a software
system that is used to demonstrate concepts, try
out design options, and find out more about the
problem and its possible solutions.
Rapid, iterative development of the prototype is
essential so that costs are controlled and system
stakeholders can experiment with the prototype
early in the software process.

31. Prototype Model

32. Prototype Model
A software prototype can be used in a software
development process to help anticipate changes
that
1. In the requirements engineering process, a
prototype can help with the elicitation and
validation of system requirements.
2. In the system design process, a prototype can
be used to explore particular software solutions
and to support user interface design.

33. Drawbacks of Prototype
Model
 A general problem with prototyping is that the prototype may
not necessarily be used in the same way as the final system.
 The tester of the prototype may not be typical of system
users.
 The training time during prototype evaluation may be
insufficient.
 If the prototype is slow, the evaluators may adjust their way of
working and avoid those system features that have slow
response times. When provided with better response in the
final system, they may use it in a different way.
 Developers are sometimes pressured by managers to deliver
throwaway prototypes, particularly when there are delays in
delivering the final version of the software.

34. Prototypes Benefits
 Prototypes do not have to be executable to be
useful. Paper-based mock-ups of the system user
interface (Rettig, 1994) can be effective in helping
users refine an interface design and work through
usage scenarios. These are very cheap to
develop and can be constructed in a few days.
 An extension of this technique is a Wizard of Oz
prototype where only the user interface is
developed. Users interact with this interface but
their requests are passed to a person who
interprets them and outputs the appropriate
response.

35. Iterative or Evolutionary Model

36. Incremental Development
Incremental development is based on the idea of
developing an initial implementation, exposing
this to user comment and evolving it through
several versions until an adequate system has
been developed

37. Iterative or Evolutionary
Model
 Incremental software development, which is a
fundamental part of agile approaches, is better
than a waterfall approach for most business, e-
commerce, and personal systems. Incremental
development reflects the way that we solve
problems.

38. Iterative or Evolutionary Model

39. Incremental & Waterfall
Incremental development has three important benefits,
compared to the waterfall model:
1.The cost of accommodating changing customer
requirements is reduced. The amount of analysis and
documentation that has to be redone is much less than is
required with the waterfall model.
2. It is easier to get customer feedback on the
development work that has been done. Customers can
comment on demonstrations of the software and see how
much has been implemented. Customers find it difficult to
judge progress from software design documents.
3. More rapid delivery and deployment of useful software
to the customer is possible, even if all of the functionality
has not been included. Customers are able to use and

40. Incremental Delivery
Advantages: Customers can use the early increments as
prototypes and gain experience that informs their
requirements for later system increments. Unlike
prototypes, these are part of the real system so
there is no re-learning when the complete system
is available.
 Customers do not have to wait until the entire
system is delivered before they can gain value
from it. The first increment satisfies their most
critical requirements so they can use the software
immediately.
 The process maintains the benefits of incremental
development in that it should be relatively easy to
incorporate changes into the system.
 As the highest-priority services are delivered first
and increments then integrated, the most

41. Drawbacks of Incremental
Model
 Most systems require a set of basic facilities that are used by
different parts of the system. As requirements are not defined
in detail until an increment is to be implemented, it can be
hard to identify common facilities that are needed by all
increments.
 Iterative development can also be difficult when a replacement
system is being developed. Users want all of the functionality
of the old system and are often unwilling to experiment with
an incomplete new system. Therefore, getting useful customer
feedback is difficult.
 The essence of iterative processes is that the specification is
developed in conjunction with the software. However, this
conflicts with the procurement model of many organizations,
where the complete system specification is part of the system
development contract. In the incremental approach, there is
no complete system specification until the final increment is
specified. This requires a new form of contract, which large
customers such as government agencies may find difficult to
accommodate.

42. Spiral Model

43. Boehm’s Spiral Model
A risk-driven software process framework
(the spiral model) was proposed by
Boehm (1988).

44. Spiral Model
The software process is represented as a spiral,
rather than a sequence of activities with some
backtracking from one activity to another.
Each loop in the spiral represents a phase of the
software process.
Thus, the innermost loop might be concerned
with system feasibility, the next loop with
requirements definition, the next loop with
system design, and so on.

45. Spiral Model
Each loop in the spiral is split into four sectors:
 Objective setting
 Risk assessment and reduction
 Development and validation
 Planning

46. Objective Setting
Specific objectives for that phase of the project
are defined. Constraints on the process and the
product are identified and a detailed
management plan is drawn up.
Project risks are identified. Alternative strategies,
depending on these risks, may be planned.

47. Risk Assessment and Reduction
For each of the identified project risks, a detailed
analysis is carried out. Steps are taken to reduce
the risk.
For example, if there is a risk that the
requirements are inappropriate, a prototype
system may be developed.

48. Development and Validation
After risk evaluation, a development model for
the
system is chosen. For example, throwaway
prototyping may be the best development
approach if user interface risks are dominant.
If safety risks are the main consideration,
development based on formal transformations
may be the most appropriate process, and so
on. If the main identified risk is sub-system
integration, the waterfall model may be the best
development model to use.

49. Planning
 The project is reviewed and a decision made
whether to continue with a further loop of the
spiral. If it is decided to continue, plans are
drawn up for the next phase of the project.

50. V – Model

51. V- Model
 At every stage, test plans and test cases are
created to verify and validate the product
according to the requirement of that stage.
 For example, in requirement gathering stage
the test team prepares all the test cases in
correspondence to the requirements.

52. V -Model
Later, when the product is developed and is
ready for testing, test cases of this stage verify
the software against its validity towards
requirements at this stage.
This makes both verification and validation go in
parallel. This model is also known as verification
and validation model.

53. Big Bang Model

54. Big Bang Model
This model is the simplest model in its form. It
requires little planning, lots of programming and
lots of funds. This model is conceptualized
around the big bang of universe.
As scientists say that after big bang lots of
galaxies, planets, and stars evolved just as an
event. Likewise, if we put together lots of
programming and funds, you may achieve the
best software product.

55. Big Bang Model
For this model, very small amount of planning is
required. It does not follow any process, or at
times the customer is not sure about the
requirements and future needs. So the input
requirements are arbitrary.
This model is not suitable for large software
projects but good one for learning and
experimenting.

56. Reuse-Oriented Development
Model
Reuse-oriented approaches rely on a large base
of reusable software components and an
integrating framework for the composition of
these components.
Sometimes, these components are systems in
their own right (COTS or commercial off-the-
shelf systems) that may provide specific
functionality such as word processing or a
spreadsheet.

57. Reuse-Oriented Development
Model
Although the initial requirements specification
stage and the validation stage are comparable
with other software processes, the intermediate
stages in a reuse oriented process are different.

58. Reuse-Oriented Development
Model

59. Reuse-Oriented Development
Model
The intermediate stages apart initial
requirements specification stage and the
validation stage from are
 Component analysis
 Requirements modification
 System design with reuse
 Development and integration

60. Component Analysis
 Given the requirements specification, a search
is made for components to implement that
specification.
 Usually, there is no exact match and the
components that may be used only provide
some of the functionality required.

61. Requirements Modification
 During this stage, the requirements are
analyzed using information about the
components that have been discovered.
 They are then modified to reflect the available
components. Where modifications are
impossible, the component analysis activity
may be re-entered to search for alternative
solutions.

62. System Design with Reuse
 During this phase, the framework of the
system is designed or an existing framework is
reused.
 The designers take into account the
components that are reused and organize the
framework to cater for this.
 Some new software may have to be designed
if reusable components are not available.

63. Development and Integration
 Software that cannot be externally procured is
developed, and the components and COTS
systems are integrated to create the new
system.
 System integration, in this model, may be part
of the development process rather than a
separate activity.

64. Software Reuse-Oriented
Process
There are three types of software component
that may be used in a reuse-oriented process:
1. Web services that are developed according to
service standards and which are available for
remote invocation.
2. Collections of objects that are developed as a
package to be integrated with a component
framework such as .NET or J2EE.
3. Stand-alone software systems that are
configured for use in a particular environment.

65. Rational Unified Process
Model
RUP 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.

66. Rational Unified Process
Model
Philippe Krutchen,2003

67. Rational Unified Process
Model
1.Develop software iteratively Plan increments of the system
based on customer priorities and develop the highest-priority
system features early in the development process.
2. Manage requirements Explicitly document the customer’s
requirements and keep track of changes to these requirements.
Analyze the impact of changes on the system before accepting
them.
3. Use component-based architectures Structure the system
architecture into components, as discussed earlier in this
chapter.
4. Visually model software Use graphical UML models to present
static and dynamic views of the software.
5. Verify software quality Ensure that the software meets the
organizational quality standards.
6. Control changes to software Manage changes to the software
using a change management system and configuration
management procedures and tools.

68. Rational Unified Process
Model
1. A dynamic perspective, which shows the
phases of the model over time.
2. A static perspective, which shows the process
activities that are enacted.
3. A practice perspective, which suggests good
practices to be used during the process.

69. Drawbacks of RUP Model
The RUP is not a suitable process for all types of
development, e.g., embedded software
development.

70. Advantages RUP Model
 The most important innovations in the RUP are
the separation of phases and workflows, and
the recognition that deploying software in a
user’s environment is part of the process.
 Phases are dynamic and have goals.
 Workflows are static and are technical
activities that are not associated with a single
phase but may be used throughout the
development to achieve the goals of each
phase.

71. REFERENCES
 Software Engineering by Somerville
 Software Engineering-Pressman
 Software Engineering Tutorial Point
 Software Engineering Wikipedia

72. THANK YOU