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
Studying the existing or obsolete system and
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
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
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
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.
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.
An estimate says that 50% of whole software
development process should be tested. Errors
may ruin the software from critical level to its
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
Early discovery of errors and their remedy is the
key to reliable software.
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.
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
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
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.
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.
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
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
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
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
26. Formal System Development
An important variant of the waterfall model is
formal system development, where a
mathematical model of a system specification is
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
28. Formal Development
It is particularly suited to the development of
systems that have stringent safety, reliability, or
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 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.
32. Prototype Model
A software prototype can be used in a software
development process to help anticipate changes
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
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
The training time during prototype evaluation may be
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
37. Iterative or Evolutionary
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
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
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
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
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
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
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
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:
Risk assessment and reduction
Development and validation
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
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
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.
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.
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.
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
56. Reuse-Oriented Development
Reuse-oriented approaches rely on a large base
of reusable software components and an
integrating framework for the composition of
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
60. Component Analysis
Given the requirements specification, a search
is made for components to implement that
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
62. System Design with Reuse
During this phase, the framework of the
system is designed or an existing framework is
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 integration, in this model, may be part
of the development process rather than a
64. Software Reuse-Oriented
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
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
RUP is a modern generic process model that is
organized into phases
-inception, elaboration, construction, and
but separates activities
-requirements, analysis, and design, etc.
from these phases.
67. Rational Unified Process
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
3. Use component-based architectures Structure the system
architecture into components, as discussed earlier in this
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
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
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