Devops Unit 1

DevOps Dr S V N SREENIVASU, Professor, Dept.
of CSE, NEC
UNIT- 1
Phases of Software Development life cycle. Values and principles of agile software development.
What is SDLC?
SDLC, Software Development Life Cycle is a process used by software industry to design, develop and test high
quality software’s. The SDLC aims to produce a high quality software that meets or exceeds customer expectations,
reaches completion within times and cost estimates.
SDLC is a process followed for a software project, within a software organization. It consists of a
detailed plan describing how to develop, maintain, replace and alter or enhance specific software.
The life cycle defines a methodology for improving the quality of software and the overall
development process.
The following figure is a graphical representation of the various stages of a typical SDLC.
A typical Software Development life cycle consists of the following stages:
• Stage 1: Planning and Requirement Analysis : Requirement analysis is the most

important and fundamental stage in SDLC. It is performed by the senior members of the
team with inputs from the customer, the sales department, market surveys and domain
experts in the industry. This information is then used to plan the basic project approach and
to conduct product feasibility study in the economical, operational, and technical areas.
Planning for the quality assurance requirements and identification of the risks associated
with the project is also done in the planning stage. The outcome of the technical feasibility
study is to define the various technical approaches that can be followed to implement the
project successfully with minimum risks.
• Stage 2: Defining Requirements : Once the requirement analysis is done the next step is
DevOps Dr S V N SREENIVASU, Professor, Dept. of CSE, NEC
to clearly define and document the product requirements and get them approved from the
customer or the market analysts. This is done through ‘BRD’ – Business Requirement
Document which consists of all the product requirements to be designed and developed
during the project life cycle.
• Stage 3: Designing the product architecture : BRD is the reference for product architects
to come out with the best architecture for the product to be developed. A design approach
clearly defines all the architectural modules of the product along with its communication
and data flow representation with the external and third party modules (if any). The internal
design of all the modules of the proposed architecture should be clearly defined with the
minutest of the details in BRD.
• Stage 4: Building or Developing the Product : In this stage of SDLC the actual
development starts and the product is built. If the design is performed in a detailed and
organized manner, code generation can be accomplished without much hassle. Developers
have to follow the coding guidelines defined by their organization and programming tools
like framework, compilers, interpreters, debuggers etc are used to generate the code.
Different high level programming languages such as C, C++, Pascal, Java, and PHP are
used for coding. The programming language is chosen with respect to the type of software
being developed.
• Stage 5: Testing the Product : This stage is usually a subset of all the stages as in the
modern SDLC models, the testing activities are mostly involved in all the stages of SDLC.
However this stage refers to the testing only stage of the product where products defects
are reported, tracked, fixed and retested, until the product reaches the quality standards
defined in the BRD.
• Stage 6: Deployment and Maintenance : Once the product is tested and ready to be
deployed it is released. Sometime product deployment happens in stages as per the
organizations’ business strategy. The product may first be released in a limited segment
and tested in the real business environment (UAT- User acceptance testing).Then based on
the feedback, the product may be released as it is or with suggested. After the product is
released, its maintenance is done for the existing customer base.
Advantages and Disadvantages of SDLCs
Advantages Disadvantages
Unsuitable when there are many iterations and/or

Ample documentation
regular reviews
Comprehensive steps Difficult to estimate costs and project overruns
Easy maintenance Inflexible when it comes to changes in requirements
Effective development and design standards Increased development cost and development time
Sets reliable evaluation costs and completion

Limited automation of documents and standards
targets
Can monitor full-scale projects Little parallelism
The software is required to be thoroughly defined

Strong control
before the start
Precise user input User input might be limited in certain scenarios
Tolerates changes to MIS in staffing
What is the best SDLC methodology?

There is no straight answer to this question, as the software life cycle model you choose will depend
on the size and scope of the software you are building, on top of other factors. The best SDLC
methodology will always come down to the requirements and project context.
There are also alternatives to the types of SDLC methodologies detailed further below. The most
popular one is the RAD or Rapid Application Development. RAD offers implementation of CASE
tools, joint application development, and prototyping. The advantages of RAD are active user
involvement, a faster approach, and reduced development cost.
SDLC Models
There are various software development life cycle models defined and designed which are
followed during software development process. Each process model follows a Series of steps
unique to its type, in order to ensure success in process of software development. Following are the
most important and popular SDLC models followed in the industry:
• Waterfall Model
• Iterative Model
• Spiral Model
• V-Model
• Big Bang Model
• The other related methodologies are Agile Model, RAD (Rapid Application
Development and Prototyping Models)
Waterfall Model
The Waterfall Model was 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. In a waterfall model, each phase must be completed before
the next phase can begin and there is no overlapping in the phases.
Waterfall model is the earliest SDLC approach that was used for software development .The
waterfall Model illustrates the software development process in a linear sequential flow; hence it
is also referred to as a linear-sequential life cycle model. This means that any phase in the
development process begins only if the previous phase is complete. In waterfall model phases do
not overlap.
Waterfall Model design
Waterfall approach was first SDLC Model to be used widely in Software Engineering to ensure
success of the project. In "The Waterfall" approach, the whole process of software development is
divided into separate phases. In Waterfall model, typically, the outcome of one phase acts as the
input for the next phase sequentially.
Following is a diagrammatic representation of different phases of waterfall model.
The sequential phases in Waterfall model are:
• Requirement Gathering and analysis All possible requirements of the system to be

developed are captured in this phase and documented in a requirement specification doc.
• System Design: The requirement specifications from first phase are studied in this phase
and system design is prepared. System Design helps in specifying hardware and system
requirements and also helps in defining overall system architecture.

• Implementation: With inputs from system design, the system is first developed in small
programs called units, which are integrated in the next phase. Each unit is developed and
tested for its functionality which is referred to as Unit Testing.
• Integration and Testing: All the units developed in the implementation phase are
integrated into a system after testing of each unit. Post integration the entire system is tested
for any faults and failures.
• Deployment of system: Once the functional and non functional testing is done, the product
is deployed in the customer environment or released into the market.
• Maintenance: There are some issues which come up in the client environment. To fix
those issues patches are released. Also to enhance the product some better versions are
released. Maintenance is done to deliver these changes in the customer environment.
All these phases are cascaded to each other in which progress is seen as flowing steadily
downwards (like a waterfall) through the phases. The next phase is started only after the defined
set of goals are achieved for previous phase and it is signed off, so the name "Waterfall Model".
In this model phases do not overlap.
Waterfall Model Application
Every software developed is different and requires a suitable SDLC approach to be fol lowed based
on the internal and external factors. Some situations where the use of Waterfall model is most
appropriate are:
• Requirements are very well documented, clear and fixed

• Product definition is stable
• Technology is understood and is not dynamic
• There are no ambiguous requirements
• Ample resources with required expertise are available to support the product
• The project is short
Waterfall Model Pros & Cons
The advantage of waterfall development is that it allows for departmentalization and control. A
schedule can be set with deadlines for each stage of development and a product can proceed
through the development process model phases one by one. Development moves from concept,
through design, implementation, testing, installation, troubleshooting, and ends up at operation and
maintenance. Each phase of development proceeds in strict order.
The disadvantage of waterfall development is that it does not allow for much reflection or
revision. Once an application is in the testing stage, it is very difficult to go back and change
something that was not well-documented or thought upon in the concept stage.
The following table lists out the pros and cons of Waterfall model:
Pros Cons
• Simple and easy to understand and use. • No working software is produced until late
• Easy to manage due to the rigidity of the during the life cycle.
model – each phase has specific deliverables • High amounts of risk and uncertainty.
and a review process. • Not a good model for complex and object
• Phases are processed and completed one at a oriented projects.
time. • Poor model for long and ongoingprojects.
• Works well for smaller projects where
• Not suitable for the projects where
requirements are very well understood.
requirements are at a moderate to high risk
• Clearly defined stages.
of changing. So risk and uncertainty is high
• Well understood milestones.
with this process model.
• Easy to arrange tasks.
• It is difficult to measure progress within
• Process and results are well documented
stages.
• Cannot accommodate changing
requirements.
• No working software is produced until late
in the life cycle
Iterative Model
In Iterative model, iterative process starts with a simple implementation of a small set of the
software requirements and iteratively enhances the evolving versions until the complete system is
implemented and ready to be deployed.
An iterative life cycle model does not attempt to start with a full specification of requirements.
Instead, development begins by specifying and implementing just part of the software, which is
then reviewed in order to identify further requirements. This process is then repeated, producing a
new version of the software at the end of each iteration of the model.
Iterative Model design
Iterative process starts with a simple implementation of a subset of the software requirements and
iteratively enhances the evolving versions until the full system is implemented. At each iteration,
design modifications are made and new functional capabilities are added. The basic idea behind
this method is to develop a system through repeated cycles (iterative) and in smaller portions at a
time (incremental).
Following is the pictorial representation of Iterative and Incremental model:

Iterative and Incremental development is a combination of both iterative design or iterative

method and incremental build model for development. "During software development, more
than one iteration of the software development cycle may be in progress at the same ti me." and
"This process may be described as an "evolutionary acquisition" or "incremental build" approach."
In incremental model the whole requirement is divided into various builds. During each iteration,
the development module goes through the requirements, design, implementation and testing
phases. Each subsequent release of the module adds function to the previous release. The process
continues till the complete system is ready as per the requirement.
The key to successful use of an iterative software development lifecycle is rigorous validation of
requirements, and verification & testing of each version of the software against those requirements
within each cycle of the model. As the software evolves through successive cycles, tests have to
be repeated and extended to verify each version of the software.
Iterative Model Application
Like other SDLC models, Iterative and incremental development has some specific applications
in the software industry. This model is most often used in the following scenarios:
• Requirements of the complete system are clearly defined and understood.

• Major requirements must be defined; however, some functionalities or requested
enhancements may evolve with time.
• There is a time to the market constraint.
• A new technology is being used and is being learnt by the development team while
working on the project.
• Resources with needed skill set are not available and are planned to be used on contract
basis for specific iterations.
• There are some high risk features and goals which may change in the future.
Iterative Model Pros and Cons
The advantage of this model is that there is a working model of the system at a very early stage of
development which makes it easier to find functional or design flaws. Finding issues at an early
stage of development enables to take corrective measures in a limited budget.
The disadvantage with this SDLC model is that it is applicable only to large and bulky software
development projects. This is because it is hard to break a small software system into further small
serviceable increments/modules.
The following table lists out the pros and cons of Iterative and Incremental SDLC Model:
Pros Cons
• Some working functionality can be developed • More resources may be required.

quickly and early in the life cycle. • Although cost of change is lesser but it is not
• Results are obtained early and periodically. very suitable for changing requirements.
• Parallel development can be planned. • More management attention is required.
• Progress can be measured. • System architecture or design issues may arise
• Less costly to change the because not all requirements are
scope/requirements. gathered in the beginning of the entire life
• Testing and debugging during smaller cycle.
iteration is easy. • Defining increments may require definition of
• Risks are identified and resolved during the complete system.
iteration; and each iteration is an easily • Not suitable for smaller projects.
managed milestone. • Management complexity is more.
• Easier to manage risk - High risk part is done • End of project may not be known which is a
first. risk.
• With every increment operational product is • Highly skilled resources are required for risk
delivered. analysis.
Issues, challenges & risks identified from Project’s progress is highly dependent
each increment can be utilized/applied to the upon the risk analysis phase
next increment.
Spiral Model
The spiral model combines the idea of iterative development with the systematic, controlled
aspects of the waterfall model.
Spiral model is a combination of iterative development process model and sequential linear
development model i.e. waterfall model with very high emphasis on risk analysis. It allows for
incremental releases of the product, or incremental refinement through each iteration around the
spiral.
Spiral Model design
The spiral model has four phases. A software project repeatedly passes through these phases in
iterations called Spirals.
• Identification : This phase starts with gathering the business requirements in the baseline
spiral. In the subsequent spirals as the product matures, identification of system
requirements, subsystem requirements and unit requirements are all done in this phase.
This also includes understanding the system requirements by continuous communication

between the customer and the system analyst. At the end of the spiral the product is
deployed in the identified market.
Following is a diagrammatic representation of spiral model listing the activities in each phase
• Design : Design phase starts with the conceptual design in the baseline spiral and involves
architectural design, logical design of modules, physical product design and final design
in the subsequent spirals.
• Construct or Build : Construct phase refers to production of the actual software product
at every spiral. In the baseline spiral when the product is just thought of and the design is
being developed a POC (Proof of Concept) is developed in this phase to get customer
feedback. Then in the subsequent spirals with higher clarity on requirements and design
details a working model of the software called build is produced with a version number.
These builds are sent to customer for feedback.
• Evaluation and Risk Analysis: Risk Analysis includes identifying, estimating, and
monitoring technical feasibility and management risks, such as schedule slippage and cost
overrun. After testing the build, at the end of first iteration, the customer evaluates the
software and provides feedback.
Based on the customer evaluation, software development process enters into the next
iteration and subsequently follows the linear approach to implement the feedback
suggested by the customer. The process of iterations along the spiral continues throughout
the life of the software.
Spiral Model Application
Spiral Model is very widely used in the software industry as it is in synch with the natural
development process of any product i.e. learning with maturity and also involves minimum
risk for the customer as well as the development firms. Following are the typical uses of Spiral
model:
• When costs there is a budget constraint and risk evaluation is important

• For medium to high-risk projects
• Long-term project commitment because of potential changes to economic priorities as the
requirements change with time
• Customer is not sure of their requirements which is usually the case
• Requirements are complex and need evaluation to get clarity
• New product line which should be released in phases to get enough customer feedback
• Significant changes are expected in the product during the development cycle
Spiral Model Pros and Cons
The advantage of spiral lifecycle model is that it allows for elements of the product to be added in
when they become available or known. This assures that there is no conflict with previous
requirements and design. This method is consistent with approaches that have multiple software
builds and releases and allows for making an orderly transition to a maintenance activity. Another
positive aspect is that the spiral model forces early user involvement in the system development
effort.
On the other side, it takes very strict management to complete such products and there is a risk of
running the spiral in indefinite loop. So the discipline of change and the extent of taking change
requests is very important to develop and deploy the product successfully.
The following table lists out the pros and cons of Spiral SDLC Model:
Pros Con
s
• Changing requirements can be • Management is more complex.
accommodated. • End of project may not be known early.
• Allows for extensive use of prototypes • Not suitable for small or low risk projects
• Requirements can be captured more and could be expensive for small projects.
accurately. • Process is complex
• Users see the system early. • Spiral may go indefinitely.
• Development can be divided into smaller • Large number of intermediate stages
parts and more risky parts can be developed requires excessive documentation.
earlier which helps better risk
management.
V-Model
The V- model is SDLC model where execution of processes happens in a sequential manner in V
-shape. It is also known as Verification and Validation model.
V-Model is an extension of the waterfall model and is based on association of a testing phase for
each corresponding development stage. This means that for every single phase in the development
cycle there is a directly associated testing phase. This is a highly disciplined model and next phase
starts only after completion of the previous phase.
V- Model design
Under V-Model, the corresponding testing phase of the development phase is planned in parallel.
So there are Verification phases on one side of the ‘V’ and Validation phases on the other side.
Coding phase joins the two sides of the V-Model.
The below figure illustrates the different phases in V-Model of SDLC.
Verification Phase
Following are the Verification phases in V-Model:
• Business Requirement Analysis :This is the first phase in the development cycle where
the product requirements are understood from the customer perspective. This phase
involves detailed communication with the customer to understand his expectations and
exact requirement. This is a very important activity and need to be managed well, as
most of the customers are not sure about what exactly they need. The acceptance test
design planning is done at this stage as business requirements can be used as an input for
acceptance testing.
• System Design: Once you have the clear and detailed product requirements, it’s time to
design the complete system. System design would comprise of understanding and detailing
the complete hardware and communication setup for the product under development.
System test plan is developed based on the system design. Doing this at an earlier stage
leaves more time for actual test execution later.
• Architectural Design: Architectural specifications are understood and designed in this

phase. Usually more than one technical approach is proposed and based on the technical
and financial feasibility the final decision is taken. System design is broken down further
into modules taking up different functionality. This is also referred to as High Level Design
(HLD). The data transfer and communication between the internal modules and with the
outside world (other systems) is clearly understood and defined in this stage. With this
information, integration tests can be designed and documented during this stage.
• Module Design: In this phase the detailed internal design for all the system modules is
specified, referred to as Low Level Design (LLD). It is important that the design is
compatible with the other modules in the system architecture and the other external
systems. Unit tests are an essential part of any development process and helps eliminate
the maximum faults and errors at a very early stage. Unit tests can be designed at this stage
based on the internal module designs.
Coding Phase
The actual coding of the system modules designed in the design phase is taken up in the Coding
phase. The best suitable programming language is decided based on the system and architectural
requirements. The coding is performed based on the coding guidelines and standards. The code
goes through numerous code reviews and is optimized for best performance before the final build
is checked into the repository.
Validation Phases
Following are the Validation phases in V-Model:
• Unit Testing : Unit tests designed in the module design phase are executed on the code
during this validation phase. Unit testing is the testing at code level and helps eliminate
bugs at an early stage, though all defects cannot be uncovered by unit testing.
• Integration Testing : Integration testing is associated with the architectural design phase.
Integration tests are performed to test the coexistence and communication of the internal
modules within the system.
System Testing : System testing is directly associated with the System design phase. System tests
check the entire system functionality and the communication of the system under development
with external systems. Most of the software and hardware compatibility issues can be uncovered
during system test execution.
• Acceptance Testing : Acceptance testing is associated with the business requirement

analysis phase and involves testing the product in user environment. Acceptance tests
uncover the compatibility issues with the other systems available in the user environment.
It also discovers the non functional issues such as load and performance defects in the
actual user environment.
V- Model Application
V- Model application is almost same as waterfall model, as both the models are of sequential type.
Requirements have to be very clear before the project starts, because it is usually expensive to go
back and make changes. This model is used in the medical development field, as it is strictly
disciplined domain. Following are the suitable scenarios to use V-Model:
• Requirements are well defined, clearly documented and fixed.

• Product definition is stable.
• Technology is not dynamic and is well understood by the project team.
• There are no ambiguous or undefined requirements
• The project is short.
V- Model Pros and Cons
The advantage of V-Model is that it’s very easy to understand and apply. The simplicity of this
model also makes it easier to manage. The disadvantage is that the model is not flexible to changes
and just in case there is a requirement change, which is very common in today’s dynamic world,
it becomes ve ry expensive to make the change.
The following table lists out the pros and cons of V-Model:
Pros Con
s
• This is a highly disciplined model and • High risk and uncertainty.
Phases are completed one at a time. • Not a good model for complex and object-
• Works well for smaller projects where oriented projects.
requirements are very well understood. • Poor model for long and ongoing projects.
• Simple and easy to understand and use. • Not suitable for the projects where
• Easy to manage due to the rigidity of the requirements are at a moderate to high risk
model – each phase has specific of changing.
deliverables and a review process. • Once an application is in the testing stage, it
is difficult to go back and change a
functionality
Big Bang Model
The Big Bang model is SDLC model where there is no specific process followed. The development
just starts with the required money and efforts as the input, and the output is the software developed
which may or may not be as per customer requirement.
Big Bang Model is SDLC model where there is no formal development followed and very little
planning is required. Even the customer is not sure about what exactly he wants and the
requirements are implemented on the fly without much analysis. Usually this model is followed
for small projects where the development teams are very small.
Big Bang Model design and Application
Big bang model comprises of focusing all the possible resources in software development and
coding, with very little or no planning. The requirements are understood and implemented as they
come. Any changes required may or may not need to revamp the complete software.
This model is ideal for small projects with one or two developers working together and is also
useful for academic or practice projects. It’s an ideal model for the product where requirements
are not well understood and the final release date is not given.
Big Bang Model Pros and Cons
The advantage of Big Bang is that its very simple and requires very little or no planning. Easy to
mange and no formal procedure are required.
However the Big Bang model is a very high risk model and changes in the requirements or
misunderstood requirements may even lead to complete reversal or scraping of the project. It is
ideal for repetitive or small projects with minimum risks.
Following table lists out the pros and cons of Big Bang Model
Pros Con
s
• This is a very simple model • Very High risk and uncertainty.
• Little or no planning required • Not a good model for complex and object-
• Easy to manage oriented projects.
• Very few resources required • Poor model for long and ongoing projects.
• Gives flexibility to developers • Can turn out to be very expensive if
• Is a good learning aid for new comers or requirements are misunderstood
Students
RAD MODEL
The RAD (Rapid Application Development) model is based on prototyping and iterative
development with no specific planning involved. The process of writing the software itself
involves the planning required for developing the product.
Rapid Application development 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.
What is RAD?
Rapid application development (RAD) is a software development methodology that uses minimal
planning in favor of rapid prototyping. A prototype is a working model that is functionally
equivalent to a component of the product. In RAD model the functional modules are developed in
parallel as prototypes and are integrated to make the complete product for faster product delivery.
Since there is no detailed preplanning, it makes it easier to incorporate the changes within the
development process. RAD projects follow iterative and incremental model and have small teams
comprising of developers, domain experts, customer representatives and other IT resources
working progressively on their component or prototype. The most important aspect for this model
to be successful is to make sure that the prototypes developed are reusable.
RAD Model Design
RAD model distributes the analysis, design, build, and test phases into a series of short, iterative
development cycles. Following are the phases of RAD Model:
• Business Modeling: The business model for the product under development is designed
in terms of flow of information and the distribution of information between various
business channels. A complete business analysis is performed to find the vital information
for business, how it can be obtained, how and when is the information processed and what
are the factors driving successful flow of information.
• Data Modeling: The information gathered in the Business Modeling phase is reviewed
and analyzed to form sets of data objects vital for the business. The attributes of all data
sets is identified and defined. The relation between these data objects are established and
defined in detail in relevance to the business model.
• Process Modeling: The data object sets defined in the Data Modeling phase are converted
to establish the business information flow needed to achieve specific business objectives as
per the business model. The process model for any changes or enhancements to the data
object sets is defined in this phase. Process descriptions for adding , deleting, retrieving or
modifying a data object are given.
• Application Generation: The actual system is built and coding is done by using
automation tools to convert process and data models into actual prototypes.
• Testing and Turnover: The overall testing time is reduced in RAD model as the
prototypes are independently tested during every iteration. However the data flow and the
interfaces between all the components need to be thoroughly tested with complete test
coverage. Since most of the programming components have already been tested, it reduces
the risk of any major issues.
Following image illustrates the RAD Model:
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 a 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 actually 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 traditional SDLC.
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.
RAD Model Application
RAD model can be applied successfully to the projects in which clear modularization is possible.
If the project cannot be broken into modules, RAD may fail. Following are the typical scenarios
where RAD can be used:
•
RAD should be used only when a system can be modularized to be delivered in
incremental manner.
• It should be used if there’s high availability of designers for modeling
• It should be used only if the budget permits use of automated code generating tools.
• RAD SDLC model should be chosen only if domain experts are available with relevant
business knowledge
• Should be used where the requirements change during the course of the project and
working prototypes are to be presented to customer in small iterations of 2-3 months.
RAD Model Pros and Cons
RAD model enables rapid delivery as it reduces the overall development time due to reusability of
the components and parallel development.
RAD works well only if high skilled engineers are available and the customer is also committed
to achieve the targeted prototype in the given time frame. If there is commitment l acking on either
side the model may fail.
Following table lists out the pros and cons of RAD Model
Pros Con
s
• Changing requirements can be • Dependency on technically strong team
accommodated. members for identifying business
• Progress can be measured. requirements.
• Iteration time can be short with use of • Only system that can be modularized can be
powerful RAD tools. built using RAD
• Productivity with fewer people in short • Requires highly skilled developers.
time. • High dependency on modeling skills
• Reduced development time. • Inapplicable to cheaper projects as cost of
• Increases reusability of components modeling and automated code generation is
• Quick initial reviews occur very high.
• Encourages customer feedback Integration • Management complexity is more.
from very beginning solves a lot of • Suitable for systems that are component
integration issues. based and scalable.
• Requires user involvement throughout the
life cycle.
• Suitable for project requiring shorter
development times
Software Prototyping Overview
The Software Prototyping refers to building software application prototypes which display the
functionality of the product under development but may not actually hold the exact logic of the
original software.
Software prototyping is becoming very popular as a software development model, as it enables to

understand customer requirements at an early stage of development. It helps get valuable feedback
from the customer and helps software designers and developers understand about what
exactly is expected from the product under development.
What is Software Prototyping?
Prototype is a working model of software with some limited functionality. The prototype does not
always hold the exact logic used in the actual software application and is an extra effort to be
considered under effort estimation. Prototyping is used to allow the users evaluate developer
proposals and try them out before implementation. It also helps understand the requirements which
are user specific and may not have been considered by the developer during product design.
Following is the stepwise approach to design a software prototype:
• Basic Requirement Identification : This step involves understanding the very basics
product requirements especially in terms of user interface. The more intricate details of the
internal design and external aspects like performance and security can be ignored at this
stage.
• Developing the initial Prototype : The initial Prototype is developed in this stage, where
the very basic requirements are showcased and user interfaces are provided. These features
may not exactly work in the same manner internally in the actual software developed and
the workarounds are used to give the same look and feel to the customer in the prototype
developed.
• Review of the Prototype : The prototype developed is then presented to the customer and
the other important stakeholders in the project. The feedback is collected in an organized
manner and used for further enhancements in the product under development.
• Revise and enhance the Prototype : The feedback and the review comments are discussed
during this stage and some negotiations happen with the customer based on factors like ,
time and budget constraints and technical feasibility of actual implementation. The changes
accepted are again incorporated in the new Prototype developed and the cycle repeats until
customer expectations are met.
Prototypes can have horizontal or vertical dimensions. Horizontal prototype displays the user
interface for the product and gives a broader view of the entire system, without concentrating on
internal functions. A vertical prototype on the other side is a detailed elaboration of a specific
function or a sub system in the product.
The purpose of both horizontal and vertical prototype is different. Horizontal prototypes are used
to get more information on the user interface level and the business requirements. It can even be
presented in the sales demos to get business in the market. Vertical prototypes are technical in
nature and are used to get details of the exact functioning of the sub systems. For example,
database requirements, interaction and data processing loads in a given sub system.
Software Prototyping Types
There are different types of software prototypes used in the industry. Following are the major
software prototyping types used widely:
• Throwaway/Rapid Prototyping
Throwaway prototyping is also called as rapid or close ended prototyping. This type of prototyping
uses very little efforts with minimum requirement analysis to build a prototype. Once the actual
requirements are understood, the prototype is discarded and the actual system is developed with a
much clear understanding of user requirements.
• Evolutionary Prototyping
Evolutionary prototyping also called as breadboard prototyping is based on building actual

functional prototypes with minimal functionality in the beginning. The prototype developed forms
the heart of the future prototypes on top of which the entire system is built. Using evolutionary
prototyping only well understood requirements are included in the prototype and the requirements
are added as and when they are understood.
• Incremental Prototyping
Incremental prototyping refers to building multiple functional prototypes of the various sub
systems and then integrating all the available prototypes to form a complete system.
• Extreme Prototyping
Extreme prototyping is used in the web development domain. It consists of three sequential phases.
First, a basic prototype with all the existing pages is presented in the html format. Then the data
processing is simulated using a prototype services layer. Finally the services are implemented and
integrated to the final prototype. This process is called Extreme Prototyping used to draw attention
to the second phase of the process, where a fully functional UI is developed with very little regard
to the actual services.
Software Prototyping Application
Software Prototyping is most useful in development of systems having high level of user
interactions such as online systems. Systems which need users to fill out forms or go through
various screens before data is processed can use prototyping very effectively to give the exact look
and feel even before the actual software is developed.
Software that involves too much of data processing and most of the functionality is internal with
very little user interface does not usually benefit from prototyping. Prototype development could
be an extra overhead in such projects and may need lot of extra efforts.
Software Prototyping Pros and Cons
Software prototyping is used in typical cases and the decision should be taken very carefully so
that the efforts spent in building the prototype add considerable value to the final software
developed. The model has its own pros and cons discussed as below.
Following table lists out the pros and cons of Big Bang Model
Pros Con
s
• Increased user involvement in the product • Risk of insufficient requirement analysis
even before implementation owing to too much dependency on prototype
• Since a working model of the system is • Users may get confused in the
displayed, the users get a better prototypes and actual systems.
understanding of the system being • Practically, this methodology may
developed. increase the complexity of the system as
• Reduces time and cost as the defects can be scope of the system may expand beyond
detected much earlier. original plans.
• Quicker user feedback is available • Developers may try to reuse the existing
leading to better solutions. prototypes to build the actual system, even
• Missing functionality can be identified when its not technically feasible
easily • The effort invested in building
• Confusing or difficult functions can be prototypes may be too much if not
identified monitored properly
Agile Model
Agile SDLC model is a combination of iterative and incremental process models with focus on
process adaptability and customer satisfaction by rapid delivery of working software product.
Agile Methods break the product into small incremental builds. These builds are provided in
iterations. Each iteration typically lasts from about one to three weeks. Every iteration involves
cross functional teams working simultaneously on various areas like planning, requirements
analysis, design, coding, unit testing, and acceptance testing. At the end of the iteration a working
product is displayed to the customer and important stakeholders.
Agile thought process had started early in the software development and started becoming
popular with time due to its flexibility and adaptability. The most popular agile methods include
Rational Unified Process (1994), Scrum (1995), Crystal Clear, Extreme Programming (1996),
Adaptive Software Development, Feature Driven Development, and Dynamic Systems
Development Method (DSDM) (1995). These are now collectively referred to as agile
methodologies, after the Agile Manifesto was published in 2001
What is Agile?
Agile model believes that every project needs to be handled differently and the existing methods
need to be tailored to best suit the project requirements. In agile the tasks are divided to time boxes
(small time frames) to deliver specific features for a release. Iterative approach is taken and
working software build is delivered after each iteration. Each build is incremental in terms of
features; the final build holds all the features required by the customer.
The Four Values of The Agile Manifesto
The Agile Manifesto is comprised of four foundational values and 12 supporting principles which lead
the Agile approach to software development. Each Agile methodology applies the four values in
different ways, but all of them rely on them to guide the development and delivery of high-quality,
working software.
1. Individuals and Interactions Over Processes and Tools
The first value in the Agile Manifesto is “Individuals and interactions over processes and tools.”
Valuing people more highly than processes or tools is easy to understand because it is the people
who respond to business needs and drive the development process. If the process or the tools drive
development, the team is less responsive to change and less likely to meet customer needs.
Communication is an example of the difference between valuing individuals versus process. In the
case of individuals, communication is fluid and happens when a need arises. In the case of process,
communication is scheduled and requires specific content.
2. Working Software Over Comprehensive Documentation
Historically, enormous amounts of time were spent on documenting the product for development
and ultimate delivery. Technical specifications, technical requirements, technical prospectus,
interface design documents, test plans, documentation plans, and approvals required for each. The
list was extensive and was a cause for the long delays in development. Agile does not eliminate
documentation, but it streamlines it in a form that gives the developer what is needed to do the work
without getting bogged down in minutiae. Agile documents requirements as user stories, which are
sufficient for a software developer to begin the task of building a new function.The Agile Manifesto
values documentation, but it values working software more.
3. Customer Collaboration Over Contract Negotiation
Negotiation is the period when the customer and the product manager work out the details of a
delivery, with points along the way where the details may be renegotiated. Collaboration is a
different creature entirely. With development models such as Waterfall, customers negotiate the
requirements for the product, often in great detail, prior to any work starting. This meant the
customer was involved in the process of development before development began and after it was
completed, but not during the process. The Agile Manifesto describes a customer who is engaged
and collaborates throughout the development process, making. This makes it far easier for
development to meet their needs of the customer. Agile methods may include the customer at
intervals for periodic demos, but a project could just as easily have an end-user as a daily part of
the team and attending all meetings, ensuring the product meets the business needs of the customer.
4. Responding to Change Over Following a Plan
Traditional software development regarded change as an expense, so it was to be avoided. The

intention was to develop detailed, elaborate plans, with a defined set of features and with everything,
generally, having as high a priority as everything else, and with a large number of many
dependencies on delivering in a certain order so that the team can work on the next piece of the
puzzle.
With Agile, the shortness of an iteration means priorities can be shifted from iteration to iteration and
new features can be added into the next iteration. Agile’s view is that changes always improve a project;
changes provide additional value.
An Agile Information Systems Development Method in use as: “A process or capability in which
human agents determine a system development approach for a specific project situation through
responsive changes in, and dynamic interplays between contexts, intentions, and method fragments.”
Agile methodologies allow the Agile team to modify the process and make it fit the team rather
than the other way around.
The Twelve Agile Manifesto Principles
The Twelve Principles are the guiding principles for the methodologies that are included under the title
“The Agile Movement.” They describe a culture in which change is welcome, and the customer is the
focus of the work. They also demonstrate the movement’s intent as described by Alistair Cockburn,
one of the signatories to the Agile Manifesto, which is to bring development into alignment with
business needs.
The twelve principles of agile development include:

1. Customer satisfaction through early and continuous software delivery – Customers are
happier when they receive working software at regular intervals, rather than waiting extended
periods of time between releases.
2. Accommodate changing requirements throughout the development process – The ability
to avoid delays when a requirement or feature request changes.
3. Frequent delivery of working software – Scrum accommodates this principle since the team
operates in software sprints or iterations that ensure regular delivery of working software.
4. Collaboration between the business stakeholders and developers throughout the project –
Better decisions are made when the business and technical team are aligned.
5. Support, trust, and motivate the people involved – Motivated teams are more likely to deliver
their best work than unhappy teams.
6. Enable face-to-face interactions – Communication is more successful when development
teams are co-located.
7. Working software is the primary measure of progress – Delivering functional software to
the customer is the ultimate factor that measures progress.
8. Agile processes to support a consistent development pace – Teams establish a repeatable and
maintainable speed at which they can deliver working software, and they repeat it with each
release.
9. Attention to technical detail and design enhances agility – The right skills and good design
ensures the team can maintain the pace, constantly improve the product, and sustain change.
10. Simplicity – Develop just enough to get the job done for right now.
11. Self-organizing teams encourage great architectures, requirements, and designs – Skilled
and motivated team members who have decision-making power, take ownership, communicate
regularly with other team members, and share ideas that deliver quality products.
12. Regular reflections on how to become more effective – Self-improvement, process
improvement, advancing skills, and techniques help team members work more efficiently.
The intention of Agile is to align development with business needs, and the success of Agile is apparent.
Agile projects are customer focused and encourage customer guidance and participation. As a result,
Agile has grown to be an overarching view of software development throughout the software industry
and an industry all by itself
The Phase of Agile Software Development Life Cycle & Workflow and Project Management
What is Agile model in the software development life cycle? Agile software development
life cycle is a method or process that focuses on building and maintaining software. It's a
scope detailing every stage from beginning to completion and further modification/ upgrading
& maintenance of software.
SDLC is the short form of this significant useful term which applied for building high-quality
software on budget & on time.
Moreover, the software development life cycle in Agile is a bit similar term of project
management functionally. Therefore, if you want to get a clear concept of Agile SDLC
models, you first need to know about their phases.
Now it's the time to reveal the phases, Agile SDLC workflow, benefits of Agile methods &
the effective Agile process for your software development.
Phases of Agile Software Development Life Cycle
Phase 1: Concept & Requirement
Requirement gathering is the first phase of the Agile development cycle. In this stage, stakeholders
determine their basis of requirement & overall project assessment. After that, the developing team
draws the solution by requirement analysis.
The following questions are a reflection of the performance of this stage as the basic activities
of the agile team.
• Who will use the software?

• How will they use the software?
• What would the required software need as input?
• What would the required software give out as final output?
Gathering every requirement and analysis on that the product owner calculates the risk of
software development, set some achievable goals, time frame, product functionality etc.
As the outcome of the requirement phase, documentation development of the functional

requirement & budget release is also performed in this stage of development.
Phase 2: Design
The stakeholder introduces the requirement outline to the software development team in the
design phase.
After entirely knowing the expectation of the stakeholders, the developer team make plans
and basic frameworks for the project. The team discusses the product functionality,
programming language, essential tools, etc.
In the design stage, the team remains engaged in things like:
• The layout of the mobile, desktop, and various devices for the website
• Color scheme fix according to the project
• What programming languages should use
• Backend frameworks designs
• System server designs
This phase aims to create the agile framework as the main base of the software architecture
to work on.
Phase 3: Development
Next is the development phase, also known as the iteration phase of Agile lifecycle. The
development phase takes the maximum amount of work and time on the Agile development
lifecycle. But this phase is the part where the actual fun begins!
In this phase, the developer team works with the UX designer and user stories to combine all
the requirements and turn these into code.
Let's get the story of this phase here:
• The development team initiates the building code.

• Sets up the hardware.
• Configures the servers.
• The designers are working on improving the user interface & user experience.
• The testers analyze the requirements.
• Start designing test plans.
After all, the software development team gets the flashlight here where they do the max of
the work of an Agile project!
Phase 4: Integration & Testing
Testing is the most vital phase of the Agile application development lifecycle. In this phase,
the software gets ready to release. But before release, the development team conducts a couple
of tests to ensure the software functionalities.
So that they test the chunk of code is clean or not, software process adaptability, product backlog,
features competitive advantages etc. If there is any error or bugs, the developer team will fix it with
immediate action & ensure secure software.
Get the following points to better understand for this testing phase:
• Brainstorm on every possible test case

• Use the test cases according to the built feature
• Incorporate them to create a 360-degree test plan that can detect all of the bad features & existing
bugs.
• Compiled every planned test
User or external training, backlog refinement, or backlog items also take place in this phase.
Overall, the tech companies work to create a beta version of the existing software. Then analyses the
user acceptance, fix bugs then goes for the production for the final product version.
Phase 5: Implementation & Deployment
After testing & fixing all defined bugs, now it’s time to complete the development & ready to be
deployed. In this phase, the operation team makes themselves busy getting the software live and running
smoothly. To deploy it, the team would need to keep all of the things in mind:
• Getting all the software, servers, and hardware running for the final release.
• Setting up the databases and links to ensure all is ready.
After all, in the deployment phase, the vital round of quality assurance is mainly done. After that, the
development team provides additional training to the users, define & resole new bugs to run the
software smoothly.
Overall, a continuous flow of transparent iterations happens by upgrading & adding new features or
functionalities in order to refresh the product.
Phase 6: Review & Retirement
This is the last phase of the Agile model of software development life cycle. Leave the maintaining
responsibilities after deploying the software out of a perfect Agile project management rule.
So, the development team runs the back-channel communication, takes the user feedback & shows the
outcomes of the project to the clients.
It enhances usability is the leading role of this agile software development phase. When your built
system is cloud-based (website, software, or app), the operation team will ensure the regular update of
the software and hardware eligibility for taking the load.
But sometimes a software enters into the retirement stage due to replace with new applications or if the
software has its own incompatibility over time.
Otherwise, take the client or stakeholder feedback to improve further & enhance customer satisfaction
takes place, and Agile remains.
The Agile SDLC Workflow
The average release cycle of software consists of 1 to 4 weeks. According to the Agile software
development phases, the developer team conducts an Agile workflow diagram. From start to the final
completion of software development, the Agile iteration workflow consists of five steps-
Planning
Approach to software development and planning is the Agile workflow's first step. In the planning
stage, the developer team imagined the whole project & made the sprint backlog, calculated the average
time of release product, & determined about the required agile technologies.
Building
The building is the second step of a traditional Agile process model. In the building or design process,
the Agile development team creates input functions & prepares the system for start testing.
Testing
Agile model in software development life cycle, this is the most vital step. In this step, the whole system
is tested before the final production approach.
The quality assurance team works to find bugs and analyze the user flow diagram to fix and enhance
the user acceptance of the application.
Delivery
The Agile delivery is the fourth step of the software development workflow. After performing a series
of testing, user training, enhancing system functionalities developers team release the software.
Feedback
Review is the final step of the Agile development process. Client & user feedback is taken in this step
to see the outcomes & if the software works and is functional or not.
All in all, this is the step of application retirement, either a continuous flow of review & up-gradation
of the software.
Effective Agile Process For You Software Development
First thing first, how Agile software development life cycle works? Choosing perfect Agile
methodologies does half of the work done in software development.
There have different Agile development life cycle models, including the traditional waterfall model, V-
shape, Spiral Agile software development methods etc. Therefore, the Agile SDLC benefits depend on
the methods and the project.
But, some standard processes require an effective Agile implementation, whichever method you
choose.
Define Goals
Defining goals helps to get a clear view of the project objectives. In that case, the development team
can determine what to do, how to do & what to avoid.
It also helps identify the requirements, work structure, and necessary tools and technologies for the
projects.
Daily Meetings
Daily meetings improve communication between the clients and team. It’s a hybrid approach to open
discussion, brainstorming, each development moving forward, and having an efficient Agile
environment.
Interaction
Smooth interaction between design, development team & customer utilizes most Agile benefits. In
other words, user interaction is the backbone of the Agile environment.
In order to best perform and achieve the internal goals supports between the team, open discussions are
crucial to progress.
Collaboration
A collaborative environment between the development team and stakeholder ensures better workflow,
empower between teams and finally bring out a high-quality product that can increase the business
value.
Share Feedback
Clients and customer feedback are other core elements for successful software development. So, the
development company or Agile team should receive feedback from time to time to upgrade features
and present the existing product as a new one.
Remain Agile
You may remain run the same phases, which is the Agile software development benefits. If the software
has compatibility & usability, you can run the same workflow to enhance the system's keep going &
up-gradation.
Keep taking feedback and make changes as a continuous process of your software development life
cycle.
Benefits of Agile Methodology in Software Development
1. Increase the Software Quality
What is the biggest benefit of Agile development methodology? In the Agile method, every project can
break down into multiple units that serve an easily manageable process. Enables the team on proper
development and testing that reaches a high-quality assurance level.
2. Opportunity for Changes
Every software company runs its system through agile SDLC methodology. Because Agile method
gives teams a chance to time-to-time flexible change process and refines the complete product life
cycle.
AGILE WATERFALL
The plan evolves over time The plan is developed at the beginning
Iterative and incremental processes Phased and sequential processes
Produces working outcomes on a regular basis Delivers a final product at the end
Cross-Functional Teams Functional Teams
Here is a graphical illustration of the Agile Model:
Following are the Agile Manifesto principles:
• Individuals and interactions : in agile development, self-organization and motivation are

important, as are interactions like co-location and pair programming.
• Working software : Demo working software is considered the best means of

communication with the customer to understand their requirement, instead of just
depending on documentation.
• Customer collaboration : As the requirements cannot be gathered completely in the

beginning of the project due to various factors, continuous customer interaction is very
important to get proper product requirements.
• Responding to change : agile development is focused on quick responses to change and

continuous development.
Agile Vs Traditional SDLC Models
Agile is based on the adaptive software development methods where as the traditional SDLC
models like waterfall model is based on predictive approach.
Predictive teams in the traditional SDLC models usually work with detailed planning and have a
complete forecast of the exact tasks and features to be delivered in the next few months or during
the product life cycle. Predictive methods entirely depend on the requirement analysis and planning
done in the beginning of cycle. Any changes to be incorporated go through a strict change control
management and prioritization.
Agile uses adaptive approach where there is no detailed planning and there is clarity on future tasks
only in respect of what features need to be developed. There is feature driven development and the
team adapts to the changing product requirements dynamically. The product is tested very
frequently, through the release iterations, minimizing the risk of any major failures in future.
Customer interaction is the backbone of Agile methodology, and open communication with
minimum documentation are the typical features of Agile development environment. The agile
teams work in close collaboration with each other and are most often located in the same
geographical location.
Agile Model Pros and Cons
Agile methods are being widely accepted in the software world recently, however, this method
may not always be suitable for all products. Here are some pros and cons of the agile model.
Following table lists out the pros and cons of Agile Model
Pros Cons
• Is a very realistic approach to software • Not suitable for handling complex
development dependencies.
• Promotes teamwork and cross training. • More risk of sustainability, maintainability
• Functionality can be developed rapidly and and extensibility.
demonstrated. • An overall plan, an agile leader and agile PM
• Resource requirements are minimum. practice is a must without which it will not
• Suitable for fixed or changing work.
requirements • Strict delivery management dictates the
• Delivers early partial working solutions. scope, functionality to be delivered, and
• Good model for environments that change adjustments to meet the deadlines.
steadily. • Depends heavily on customer interaction, so
• Minimal rules, documentation easily if customer is not clear, team can be driven
employed. in the wrong direction.
• Enables concurrent development and • There is very high individual dependency,
delivery within an overall planned context. since there is minimum documentation
• Little or no planning required generated.
• Easy to manage • Transfer of technology to new team
members may be quite challenging due to
• Gives flexibility to developers
lack of documentation.
Assignment-1 Questions:
1. Describe the different phases of SDLC with example?
2. Analyze the waterfall and spiral SDLC model
3. Analyze the Agile and Waterfall model
4. Analyze the values and principles of Agile model
5. Analyze the Agile SDLC phases with suitable business example
6. Analyze the Spiral and V-Model of SDLC with suitable example.

Devops Unit 1

Uploaded by

Copyright:

Available Formats

Devops Unit 1

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Devops Unit 1

Uploaded by

Copyright:

Available Formats

DevOps Dr S V N SREENIVASU, Professor, Dept.

A typical Software Development life cycle consists of the following stages:

• Stage 1: Planning and Requirement Analysis : Requirement analysis is the most

Advantages and Disadvantages of SDLCs

Unsuitable when there are many iterations and/or

Comprehensive steps Difficult to estimate costs and project overruns

Easy maintenance Inflexible when it comes to changes in requirements

Sets reliable evaluation costs and completion

Can monitor full-scale projects Little parallelism

The software is required to be thoroughly defined

Precise user input User input might be limited in certain scenarios

Tolerates changes to MIS in staffing

What is the best SDLC methodology?

Waterfall Model design

Following is a diagrammatic representation of different phases of waterfall model.

The sequential phases in Waterfall model are:

• Requirement Gathering and analysis All possible requirements of the system to be

requirements and also helps in defining overall system architecture.

Waterfall Model Application

• Requirements are very well documented, clear and fixed

Waterfall Model Pros & Cons

Iterative Model design

Following is the pictorial representation of Iterative and Incremental model:

Iterative and Incremental development is a combination of both iterative design or iterative

Iterative Model Application

• Requirements of the complete system are clearly defined and understood.

Iterative Model Pros and Cons

• Some working functionality can be developed • More resources may be required.

Spiral Model design

This also includes understanding the system requirements by continuous communication

Spiral Model Application

• When costs there is a budget constraint and risk evaluation is important

Spiral Model Pros and Cons

The below figure illustrates the different phases in V-Model of SDLC.

Following are the Verification phases in V-Model:

• Architectural Design: Architectural specifications are understood and designed in this

Following are the Validation phases in V-Model:

• Acceptance Testing : Acceptance testing is associated with the business requirement

disciplined domain. Following are the suitable scenarios to use V-Model:

• Requirements are well defined, clearly documented and fixed.

V- Model Pros and Cons

Big Bang Model

Big Bang Model design and Application

Big Bang Model Pros and Cons

Rapid Application development focuses on gathering customer requirements through workshops

RAD Model Design

Following image illustrates the RAD Model:

RAD Model Vs Traditional SDLC

RAD Model Application

Software prototyping is becoming very popular as a software development model, as it enables to

What is Software Prototyping?

Following is the stepwise approach to design a software prototype:

Software Prototyping Types

Evolutionary prototyping also called as breadboard prototyping is based on building actual

Software Prototyping Application

Software Prototyping Pros and Cons

The Four Values of The Agile Manifesto

1. Individuals and Interactions Over Processes and Tools