UNIT 1

1.1​Software Development Life Cycle

Software Development Life Cycle is the application of standard business practices to building
software applications. It’s typically divided into six to eight steps: Planning, Requirements,
Design, Build, Document, Test, Deploy, Maintain. Some project managers will combine, split,
or omit steps, depending on the project’s scope. These are the core components recommended
for all software development projects.

SDLC is a way to measure and improve the development process. It allows a fine-grain
analysis of each step of the process. This, in turn, helps companies maximize efficiency at
each stage. As computing power increases, it places a higher demand on software and
developers. Companies must reduce costs, deliver software faster, and meet or exceed their
customers’ needs. SDLC helps achieve these goals by identifying inefficiencies and higher
costs and fixing them to run smoothly.

1.​Planning

In the Planning phase, project leaders evaluate the terms of the project. This includes
calculating labor and material costs, creating a timetable with target goals, and creating the
project’s teams and leadership structure.

Planning can also include feedback from stakeholders. Stakeholders are anyone who stands to
benefit from the application. Try to get feedback from potential customers, developers, subject
matter experts, and sales reps.

Planning should clearly define the scope and purpose of the application. It plots the course
and provisions the team to effectively create the software. It also sets boundaries to help keep
the project from expanding or shifting from its original purpose.

2.​Define Requirements

Defining requirements is considered part of planning to determine what the application is

supposed to do and its requirements. For example, a social media application would require
the ability to connect with a friend. An inventory program might require a search feature.

Requirements also include defining the resources needed to build the project. For example, a
team might develop software to control a custom manufacturing machine. The machine is a
requirement in the process.

3.​Design and Prototyping

The Design phase models the way a software application will work. Some aspects of the
design include:

Architecture – Specifies programming language, industry practices, overall design,

and use of any templates or boilerplate
User Interface – Defines the ways customers interact with the software, and how the
software responds to input
Platforms – Defines the platforms on which the software will run, such as Apple,
Android, Windows version, Linux, or even gaming consoles
Programming – Not just the programming language, but including methods of
solving problems and performing tasks in the application
 Communications – Defines the methods that the application can communicate with
other assets, such as a central server or other instances of the application
Security – Defines the measures taken to secure the application, and may include SSL
traffic encryption, password protection, and secure storage of user credentials

Prototyping can be a part of the Design phase. A prototype is like one of the early versions of
software in the Iterative software development model. It demonstrates a basic idea of how the
application looks and works. This “hands-on” design can be shown to stakeholders. Use
feedback o improve the application. It’s less expensive to change the Prototype phase than to
rewrite code to make a change in the Development phase.

4.​Software Development

This is the actual writing of the program. A small project might be written by a single
developer, while a large project might be broken up and worked by several teams. Use an
Access Control or Source Code Management application in this phase. These systems help
developers track changes to the code. They also help ensure compatibility between different
team projects and to make sure target goals are being met.

The coding process includes many other tasks. Many developers need to brush up on skills or
work as a team. Finding and fixing errors and glitches is critical. Tasks often hold up the
development process, such as waiting for test results or compiling code so an application can
run. SDLC can anticipate these delays so that developers can be tasked with other duties.

Software developers appreciate instructions and explanations. Documentation can be a formal

process, including wiring a user guide for the application. It can also be informal, like
comments in the source code that explain why a developer used a certain procedure. Even
companies that strive to create software that’s easy and intuitive benefit from the
documentation.

Documentation can be a quick guided tour of the application’s basic features that display on
the first launch. It can be video tutorials for complex tasks. Written documentation like user
guides, troubleshooting guides, and FAQ’s help users solve problems or technical questions.

5.​Testing

It’s critical to test an application before making it available to users. Much of the testing can
be automated, like security testing. Other testing can only be done in a specific environment –
consider creating a simulated production environment for complex deployments. Testing
should ensure that each function works correctly. Different parts of the application should also
be tested to work seamlessly together—performance test, to reduce any hangs or lags in
processing. The testing phase helps reduce the number of bugs and glitches that users
encounter. This leads to a higher user satisfaction and a better usage rate.

6.​Deployment

In the deployment phase, the application is made available to users. Many companies prefer to
automate the deployment phase. This can be as simple as a payment portal and download link
on the company website. It could also be downloading an application on a smartphone.

Deployment can also be complex. Upgrading a company-wide database to a newly-developed

application is one example. Because there are several other systems used by the database,
integrating the upgrade can take more time and effort.
7.​Operations and Maintenance

At this point, the development cycle is almost finished. The application is done and being
used in the field. The Operation and Maintenance phase is still important, though. In this
phase, users discover bugs that weren’t found during testing. These errors need to be resolved,
which can spawn new development cycles.

In addition to bug fixes, models like Iterative development plan additional features in future
releases. For each new release, a new Development Cycle can be launched.

Fig.1 Phase in Software lifecycle model

2.​ Process
Project management process is an administration process for the planning and control of
the services or the implementation of a project
The results of one of these processes are:
1.​ delivery of the project product
2.​ achievement of the project objectives
3.​ documentation of the learning processes
2.2​Project Management Process consists of the following 4 stages:

⚫​Feasibility study
•​ Project Planning
•​ Project Execution
•​ Project Termination

Fig.1.1 Process
1.1.1​Feasibility Study
 ⚫​Feasibility study explores system requirements to determine project feasibility.
1.1.2​Project Planning
A detailed plan stating a stepwise strategy to achieve the listed objectives is an integral part of
any project. Planning consists of the following activities:
•​ Set objectives or goals
•​ Develop strategies
•​ Develop project policies
•​ Determine courses of action
•​ Making planning decisions
•​ Set procedures and rules for the project
•​ Develop a software project plan
•​ Prepare budget
•​ Conduct risk management

•​ Document software project plans

⚫​This step also involves the construction of a work breakdown structure(WBS). It also
includes size, effort, schedule, and cost estimation using various techniques.
1.1.3​Project Execution
⚫​Amodel(SDLC)
project is executed by choosing an appropriate software development lifecycle

⚫​Itandincludes a number of steps including requirements analysis, design, coding, testing

implementation, testing, delivery, and maintenance.
⚫​There are a number of factors that need to be considered while doing so including the
size of the system, the nature of the project, time and budget constraints, domain
requirements, etc.
⚫​ An inappropriate SDLC can lead to the failure of the project.
1.1.4​Project Termination:
⚫​There can be several reasons for the termination of a project.
⚫​Though expecting a project to terminate after successful completion is
conventional, but at times, a project may also terminate without completion.
⚫​Projects have to be closed down when the requirements are not fulfilled according to
given time and cost constraints.
⚫​Some of the reasons for failure include:
•​ Fast-changing technology
•​ Project running out of time
•​ Organizational politics
•​ Too much change in customer requirements
 •​ Project exceeding budget or funds
•​ Once the project is terminated, a post-performance analysis is done. Also, a final
report is published describing the experiences, lessons learned, recommendations for
handling future projects.
1.2​Tailoring the Process
⚫​Tailoring is the process of referencing framework documents, standards and other
relevant sources and utilizing those elements that provide processes, tools and
techniques that are suitable for that particular organization.
⚫​It also includes modifying existing processes currently in use by the organization.
⚫​The result of tailoring is that the project management methodology will be suitable
for use in specific types of projects, and a tailored methodology will reflect the size,
complexity, and duration of the project as appropriate for the organizational context
along with adaptation to the industry within which the project is undertaken.
⚫​tailoring at two levels:
⚫​Summary
⚫​Detailed.
1.2.1​Summary-Level Tailoring
In summary-level tailoring, depending on the project characteristics, the project manager
applies overall guidelines for tailoring the standard process. That is, it provides some general
rules regarding certain types of detailed activities. To perform this step, the project manager
first identifies certain characteristics of the project. For development projects, the following
characteristics are used for tailoring:
⚫​ Experience and skill level of the team and the project manager
⚫​ Clarity of the requirements
⚫​ Project duration
⚫​ Application criticality
1.2.2​Detailed Tailoring
Detailed tailoring covers execution of activities, their review, and documentation needs.
Tailoring guidelines may specify an activity as optional, in which case the project manager
can decide whether or not to execute the activity. Similarly, preparation of some documents
may be optional, in which case the project manager decides whether or not the project needs
the document. For review, the general alternatives are Do group review, do one-person review,
or Do not review. In addition, a project manager may add some new activities or may repeat
some activities.
⚫​When detailed tailoring is finished, the sequence of activities to be performed in the
process for the project is defined. These definitions are then used to plan and schedule
activities and form the basis of project execution. The tailoring performed is
highlighted in the project plan, so the process definition and tailoring also are
reviewed when the plan is reviewed.

⚫​Process discipline is the adherence to well-thought-out and well-defined processes that

are executed daily. The rules are often related to the work of process engineers and
 local leaders, e.g. line leaders, and production supervisors. Or rather, the lack of a
particular type of work in this case.
1.3​Process Improvement Discipline
⚫​Asreducebusinesses try to accelerate growth while running lean, there’s always a desire to
costs through process improvement. Like the examples above, this could
include:
•​ Improving product quality
•​ Upgrade service quality
•​ Improve delivery times
•​ Reduce billing cycles
•​ Make production more efficient

1.3.1​LEAN Technology
⚫​LEAN Tech, also known as LEAN manufacturing, was a process that originated with
Toyota. It was implemented to streamline the company’s production chain and
dramatically reduce operating and overhead costs.
⚫​The key idea is to base process improvement on the customer perspective; taking the
time to understand what they value from the product and then using LEAN process
improvement to eliminate unnecessary waste, errors and other things that drive up
costs. By focusing on value, the entire process is organized to drive more of what the

customer is willing to pay for.

1
1.3.2 Six Sigma
Six Sigma is a process improvement example that focuses on achieving the maximum level
of obtainable quality within an organization. At the Six Sigma level, that is a rating of near
100% perfection (or 99.9966%).
The Six Sigma approach looks closely at the root cause of problems, defects, and variations
that reduce the effectiveness of processes. At its heart, there’s a philosophy of constant
improvement that is in place to improve results consistently and progressively until that max
level of perfection is achieved.
1.3.3 Total Quality Management (TQM)
Total quality management (TQM) is a project management technique or strategy that is
implemented to assure that an awareness of quality is embedded in all phases of the project
from conception to completion. Used in industries from manufacturing to aerospace, total
quality management requires the careful and consistent review of all phases of a project, and
the coordinated effort of all involved. Communication is key to the process. Standards must be
developed, procedures well defined, and all involved must follow strict adherence to the plan
to assure its success.
1.3.3.1​The first paradigm Total Quality Management
The first paradigm of the strategy, “total,” calls for an integrated system of dependent
variables. Here, planning is of the utmost importance. In the planning stage obstacles to
success can be identified, confronted, and conquered. Procedures for inspection, evaluating,
reporting, and rectifying anomalies are established that will assure consistency and quality
will be developed and implemented. All parties involved, from workers to management must
become familiar with the process and committed to its success.
1.3.3.2​The second paradigm Total Quality Management
The second paradigm of the total quality management (TQM) strategy, “quality,” requires that
once a standard has been established it must never be violated. This necessitates a certain
amount of cross training, so that one party along the chain of project management can spot the
errors that might have occurred at a prior stage in the process. This not only assures quality,
but also tends to inspire greater commitment and conscientiousness among the individuals
involved.
1.3.3.3 The Third paradigm Total Quality Management
The third paradigm of total quality management (TQM) is management itself. In order to
ensure success, the strategy must function as a cohesive element that unites the individual
efforts of all involved.
The system must be managed properly in order to ensure the quality of the strategy itself.
Therefore, it is the role of project management role to oversee the training of all involved in
the process, to ascertain whether the process is being strictly adhered to, and to develop and
implement corrective measures designed to rectify any problems that might divert the strategy
from its goal.
1.4​The Importance of a Disciplined Process
•​ A disciplined software process serves two main purposes: Helps
developers better understand what they are doing
 •​ Helps managers make more accurate predictions about how long a project will take
•​ Predictability is crucial for setting reasonable goals and planning
resource allocation.

1.4.1​Understanding
•​ As software developers work through a disciplined process, they
are developing a complex mental roadmap of: The values of the
client
•​ The concepts that are important to the client
•​ Software patterns for achieving the desired behavior
•​ Implementation methods
⚫​Common sense and experience both support the importance of this understanding.
1.4.2​Common Sense
•​ Suppose that a software development process has been in progress for
several months or years. Then: One of the development team members
has changed jobs so that a replacement is needed, or
•​ The project is behind schedule so management has allocated more
people to work on the project.
⚫​Sobeena added
new member, who knows neither the process nor the client, has
to the team.
⚫​Will he/she be as effective as the other team members?
⚫​Not likely.
1.4.3​Experience
•​ Brooks has discussed management problems arising from adding people
to a project that is behind schedule in order to catch up: Often, the result
is that the project slips
•​ further behind schedule.
•​ The reason: The new people do not have a mental roadmap.
•​ In order to acquire it, experienced team members will have to dedicate
some time to bringing them up to speed.
⚫​This may seem obvious, but managers have to go through a similar
process to learn how to manage effectively.
•​ A lot of facts are obvious, but that does not mean that you will see them
when they are important: You do not see things that are obvious until
you have had experiences that stress their importance.
•​ You also need to recognize that they are important.
 1.​ Classical Waterfall Model

1. Feasibility Study:
The main goal of this phase is to determine whether it would be financially and technically feasible to
develop the software.
The feasibility study involves understanding the problem and then determining the various possible
strategies to solve the problem. These different identified solutions are analyzed based on their benefits and
drawbacks, The best solution is chosen and all the other phases are carried out as per this solution strategy.
2. Requirements Analysis and Specification:
The requirement analysis and specification phase aims to understand the exact requirements of the customer
and document them properly. This phase consists of two different activities.
●​ Requirement gathering and analysis: Firstly all the requirements regarding the software are gathered
from the customer and then the gathered requirements are analyzed. The goal of the analysis part is
to remove incompleteness (an incomplete requirement is one in which some parts of the actual
requirements have been omitted) and inconsistencies (an inconsistent requirement is one in which
some part of the requirement contradicts some other part).
●​ Requirement specification: These analyzed requirements are documented in a software requirement
specification (SRS) document. SRS document serves as a contract between the development team
and customers. Any future dispute between the customers and the developers can be settled by
examining the SRS document.
3. Design:
The goal of this phase is to convert the requirements acquired in the SRS into a format that can be coded in a
programming language. It includes high-level and detailed design as well as the overall software
architecture. A Software Design Document is used to document all of this effort (SDD).
4. Coding and Unit Testing:
In the coding phase software design is translated into source code using any suitable programming language.
Thus each designed module is coded. The unit testing phase aims to check whether each module is working
properly or not.
5. Integration and System testing:
Integration of different modules is undertaken soon after they have been coded and unit tested. Integration of
various modules is carried out incrementally over several steps. During each integration step, previously
planned modules are added to the partially integrated system and the resultant system is tested. Finally, after
all the modules have been successfully integrated and tested, the full working system is obtained and system
testing is carried out on this. ​
System testing consists of three different kinds of testing activities as described below.
●​ Alpha testing: Alpha testing is the system testing performed by the development team.
●​ Beta testing: Beta testing is the system testing performed by a friendly set of customers.
●​ Acceptance testing: After the software has been delivered, the customer performs acceptance testing
to determine whether to accept the delivered software or reject it.
6. Maintenance:
Maintenance is the most important phase of a software life cycle. The effort spent on maintenance is 60% of
the total effort spent to develop a full software. There are three types of maintenance.
●​ Corrective Maintenance: This type of maintenance is carried out to correct errors that were not
discovered during the product development phase.
●​ Perfective Maintenance: This type of maintenance is carried out to enhance the functionalities of the
system based on the customer’s request.
●​ Adaptive Maintenance: Adaptive maintenance is usually required for porting the software to work in
a new environment such as working on a new computer platform or with a new operating system.
Advantages of Waterfall Model
●​ Classical waterfall model is easy to understand and simple to use.
●​ In the waterfall model, only one phase is executed at a time or phases cannot overlap.
●​ In this model, each phase is clearly defined.
●​ Waterfall model works best for a small project, where requirements are clearly defined.
●​ It has clearly understood milestones.
●​ Each Process, actions and results are well documented.
Disadvantages of Waterfall Model
Below are the list of Shortcomings of Waterfall Model:
1.​ Idealistic Model: The classical waterfall model is an idealistic one since it assumes that no
development error is ever committed by the engineers during any of the life cycle phases. However,
in practical development environments, the engineers do commit a large number of errors in almost
every phase of the life cycle.​

2.​ Waterfall model assumes that all requirements are defined correctly at the beginning of the
 project, and on the basis of that, the development work starts. However, that is rarely the case in real
life projects. The customer keeps changing the requirements as their development proceeds. Thus, it
becomes difficult to accommodate later requirements change request made by the customer.​

3.​ Phases are sequential: Classical waterfall model assumes, that all the phases are sequential.
However, that is rarely the case.

For example, for efficient utilization of manpower in a company, the members assigned the testing
work may start their work immediately after the requirements specification to design the system test
cases. Consequently, it is safe to say that in a practical software development scenario, the different
phases might overlap, rather than having a precise point in time at which one phase stops and the
other starts.

2.​ Iterative Waterfall Model

It is not possible to strictly follow the classical waterfall model for software development work. In
this context, we can view the iterative waterfall model as making necessary changes to the classical
waterfall model so that it becomes applicable to practical software development projects.

In Iterative waterfall model, the feedback paths are provided from every phase to its preceding
phase as shown in Figure
The feedback paths allow for correction of the errors committed during a phase, as and when
these are detected in a later phase.

For example, if during a testing a design error is identified, then the feedback path allows the
design to be reworked and the changes to be reflected in the design documents. However,
observe that there is no feedback path to the feasibility stage. This means that the feasibility
study errors cannot be corrected.
When to use Iterative Waterfall Model
 ●​ The requirement of the defined and clearly understood.
●​ New technology is being learned by the development team.
●​ There are some high risk features and goals which might in the future.
Advantages of Iterative Waterfall Model
●​ Feedback Path: iterative waterfall allows the mechanism of error connection because
there is a feedback path from one phase to its preceding phase which it lacks in the
Waterfall Model.
●​ Simple: iterative waterfall model is simple to understand and use. It is the most widely
used software development model evolved so far.
●​ Parallel development: can be done.

Disadvantage of Iterative Waterfall Model

●​ More resource: may be required to implement the iterative waterfall model.
●​ Difficult to include change requests: In the iterative waterfall model, all the
requirements must be clearly defined before starting of the development phase but
sometimes customer requirement changes which is difficult to incorporate change
requests that are made after development phase starts.
●​ Not support Intermediate delivery: Project has to be fully completed before it
delivered to the customer.
●​ Risk handling: Project is prone to many types of risk but there is no risk handling
mechanism.
●​ Not suitable for a small project.
3.​ Prototyping Model

Step 1: Requirement Gathering and Analysis: This is the initial step in designing a
prototype model. In this phase, users are asked about what they expect or what they want from
the system.
Step 2: Quick Design: This is the second step in the Prototyping Model. This model covers
the basic design of the requirement through which a quick overview can be easily described.
Step 3: Build a Prototype: This step helps in building an actual prototype from the
knowledge gained from prototype design.
Step 4: Initial User Evaluation: This step describes the preliminary testing where the
investigation of the performance model occurs, as the customer will tell the strengths and
weaknesses of the design, which was sent to the developer.
Step 5: Refining Prototype: If any feedback is given by the user, then improving the client’s
response to feedback and suggestions, the final system is approved.
Step 6: Implement Product and Maintain: This is the final step in the phase of the
Prototyping Model where the final system is tested and distributed to production, here the
program is run regularly to prevent failures.
When Prototyping model is used?
This model is used when the customers do not know the exact project requirements
beforehand. In this model, a prototype of the end product is first developed, tested, and refined
as per customer feedback repeatedly till a final acceptable prototype is achieved which forms
the basis for developing the final product.
Advantages of Prototyping Model
●​ The customers get to see the partial product early in the life cycle. This ensures a
greater level of customer satisfaction and comfort.
●​ New requirements can be easily accommodated as there is scope for refinement.
●​ Missing functionalities can be easily figured out.
●​ Errors can be detected much earlier thereby saving a lot of effort and cost, besides
enhancing the quality of the software.
●​ The developed prototype can be reused by the developer for more complicated projects
in the future.
●​ Flexibility in design.
●​ Early feedback from customers and stakeholders can help guide the development
process and ensure that the final product meets their needs and expectations.
●​ Prototyping can be used to test and validate design decisions, allowing for adjustments
to be made before significant resources are invested in development.
●​ Prototyping can help reduce the risk of project failure by identifying potential issues
and addressing them early in the process.
Disadvantages of the Prototyping Model
●​ Costly concerning time as well as money.
●​ There may be too much variation in requirements each time the prototype is evaluated
 by the customer.
●​ Poor Documentation due to continuously changing customer requirements.
●​ It is very difficult for developers to accommodate all the changes demanded by the
customer.
●​ There is uncertainty in determining the number of iterations that would be required
before the prototype is finally accepted by the customer.
●​ After seeing an early prototype, the customers sometimes demand the actual product to
be delivered soon.
●​ Developers in a hurry to build prototypes may end up with sub-optimal solutions.

4.​ 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 (Figure 2.2). Specification, development, and
validation activities are interleaved rather than separate, with rapid feedback across
activities.
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. We rarely work out
a complete problem solution in advance but move toward a solution in a series of
steps, backtracking when we realize that we have made a mistake. By developing the
software incrementally, it is cheaper and easier to make changes in the software as it is
being developed.
Each increment or version of the system incorporates some of the functionality that is
needed by the customer. Generally, the early increments of the system include the most
important or most urgently required functionality. This means that the customer can
evaluate the system at a relatively early stage in the development to see if it delivers
what is required. If not, then only the current increment has to be changed and,
possibly, new functionality defined for later increments.
 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 gain
value from the software earlier than is possible with a waterfall process.

5.​ RAD Model

The RAD model is a type of incremental process model in which there is an extremely short
development cycle. When the requirements are fully understood and the component-based
construction approach is adopted then the RAD model is used.
The critical feature of this model is the use of powerful development tools and techniques. A
software project can be implemented using this model if the project can be broken down into
small modules wherein each module can be assigned independently to separate teams. These
modules can finally be combined to form the final product. Development of each module
involves the various basic steps as in the waterfall model i.e. analyzing, designing, coding, and
then testing, etc.
This model consists of 4 basic phases:
1.​ Requirements Planning – This involves the use of various techniques used in
requirements elicitation like brainstorming, task analysis, form analysis, user
scenarios, FAST (Facilitated Application Development Technique), etc. It also consists
of the entire structured plan describing the critical data, methods to obtain it, and then
processing it to form a final refined model.
2.​ User Description – This phase consists of taking user feedback and building the
prototype using developer tools. In other words, it includes re-examination and
validation of the data collected in the first phase. The dataset attributes are also
identified and elucidated in this phase.
3.​ Construction – In this phase, refinement of the prototype and delivery takes place. It
includes the actual use of powerful automated tools to transform processes and data
models into the final working product. All the required modifications and
enhancements are to be done in this phase.
4.​ Cutover – All the interfaces between the independent modules developed by separate
teams have to be tested properly. The use of powerfully automated tools and subparts
makes testing easier. This is followed by acceptance testing by the user.

The process involves building a rapid prototype, delivering it to the customer, and taking
feedback. After validation by the customer, the SRS document is developed and the design is
finalized.
Advantages of Rapid Application Development Model (RAD)
●​ The use of reusable components helps to reduce the cycle time of the project.
●​ Feedback from the customer is available at the initial stages.
●​ Reduced costs as fewer developers are required.
●​ The use of powerful development tools results in better quality products in
comparatively shorter periods.
●​ The progress and development of the project can be measured through the various
stages.
Disadvantages of Rapid application development model (RAD)
●​ The use of powerful and efficient tools requires highly skilled professionals.
●​ The absence of reusable components can lead to the failure of the project.
●​ The team leader must work closely with the developers and customers to close the
project on time.

6. Spiral Model
 The Spiral Model is a risk-driven model, meaning that the focus is on managing risk
through multiple iterations of the software development process. It consists of the
following phases:
1.​ Objectives Defined: In first phase of the spiral model we clarify what the project aims
to achieve, including functional and non-functional requirements.
2.​ Risk Analysis: In the risk analysis phase, the risks associated with the project are
identified and evaluated.
3.​ Engineering: In the engineering phase, the software is developed based on the
requirements gathered in the previous iteration.
4.​ Evaluation: In the evaluation phase, the software is evaluated to determine if it meets
the customer’s requirements and if it is of high quality.
5.​ Planning: The next iteration of the spiral begins with a new planning phase, based on
the results of the evaluation.
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.
Each loop in the spiral is split into four sectors:

1. 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.

2. 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.
 3. 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.

4. 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.
Advantages of the Spiral Model
1.Risk Handling
2.Good for large projects
3.Flexibility in Requirements
4.Customer Satisfaction
5.Iterative and Incremental Approach
6.Emphasis on Risk Management
7.Improved Communication
8.Improved Quality

Disadvantages of the Spiral Model

Below are some main disadvantages of the spiral model.
1.​ Complex: The Spiral Model is much more complex than other SDLC models.
2.​ Expensive: Spiral Model is not suitable for small projects as it is expensive.
3.​ Too much dependability on Risk Analysis: The successful completion of the project
is very much dependent on Risk Analysis. Without very highly experienced experts, it
is going to be a failure to develop a project using this model.
4.​ Difficulty in time management: As the number of phases is unknown at the start of
the project, time estimation is very difficult.
5.​ Complexity: The Spiral Model can be complex, as it involves multiple iterations of
the software development process.
6.​ Time-Consuming: The Spiral Model can be time-consuming, as it requires multiple
evaluations and reviews.
7.​ Resource Intensive: The Spiral Model can be resource-intensive, as it requires a
significant investment in planning, risk analysis, and evaluations.
7. Component assembly model
 The component-based assembly model uses object-oriented technologies. In
object-oriented technologies, the emphasis is on the creation of classes. Classes are the
entities that encapsulate data and algorithms. In component-based architecture, classes
(i.e., components required to build application) can be uses as reusable components.
This model uses various characteristics of spiral model. This model is evolutionary by
nature. Hence, software development can be done using iterative approach. In CBD
model, multiple classes can be used. These classes are basically the prepackaged
components. The model works in following manner:
●​ Step-1: First identify all the required candidate components, i.e., classes with the help
of application data and algorithms.
●​ Step-2: If these candidate components are used in previous software projects then they
must be present in the library.
●​ Step-3: Such preexisting components can be excited from the library and used for
further development.
●​ Step-4: But if the required component is not present in the library then build or create
the component as per requirement.
●​ Step-5: Place this newly created component in the library. This makes one iteration of
the system.
●​ Step-6: Repeat steps 1 to 5 for creating n iterations, where n denotes the number of
iterations required to develop the complete application.
Characteristics of Component Assembly Model:
●​ Uses object-oriented technology.
●​ Components and classes encapsulate both data and algorithms.
●​ Components are developed to be reusable.
●​ Paradigm similar to spiral model, but engineering activity involves components.
●​ The system produced by assembling the correct components.

8.​ Agile process model

Agile development model is also a type of Incremental model. Software is developed
in incremental, rapid cycles. This results in small incremental releases with each
release building on previous functionality. Each release is thoroughly tested to ensure
software quality is maintained. It is used for time critical applications. Extreme
Programming (XP) and Scrum are currently the most well known agile development
life cycle models.
8.1 Extreme Programming:
XP is a lightweight, efficient, low-risk, flexible, predictable, scientific, and fun way to
develop software. eXtreme Programming (XP) was conceived and developed to
address the specific needs of software development by small teams in the face of vague
and changing requirements. Extreme Programming is one of the Agile software
development methodologies. It provides values and principles to guide the team
behavior. The team is expected to self-organize. Extreme Programming provides
specific core practices where- Each practice is simple and self-complete. Combination
of practices produces more complex and emergent behavior.
Extreme Programming in a Nutshell Extreme Programming involves-
• Writing unit tests before programming and keeping all of the tests running at all times.
The unit tests are automated and eliminate defects early, thus reducing the costs.
• Starting with a simple design just enough to code the features at hand and redesigning
when required.
• Programming in pairs (called pair programming), with two programmers at one screen,
taking turns to use the keyboard. While one of them is at the keyboard, the other
constantly reviews and provides inputs.
• Integrating and testing the whole system several times a day.
• Putting a minimal working system into the production quickly and upgrading it whenever
required.
• Keeping the customer involved all the time and obtaining constant feedback. Iterating
facilitates the accommodating changes as the software evolves with the changing
requirements.
 Advantages:
• Slipped schedules: Short and achievable development cycles ensure timely deliveries.
• Cancelled projects: Focus on continuous customer involvement ensures transparency
with the customer and immediate resolution of any issues.
• Costs incurred in changes: Extensive and ongoing testing makes sure the changes do
not break the existing functionality. A running working system always ensures
sufficient time for accommodating changes such that the current operations are not
affected.
• Production and post-delivery defects: Emphasis is on the unit tests to detect and fix the
defects early.
• Misunderstanding the business and/or domain: Making the customer a part of the
team ensures constant communication and clarifications.
• Business changes: Changes are considered to be inevitable and are accommodated at
any point of time.
• Staff turnover: Intensive team collaboration ensures enthusiasm and good will.
Cohesion of multi-disciplines fosters the team spirit.
The fundamental principles of Extreme Programming are-
• Rapid feedback
• Assume simplicity
• Incremental change
• Embracing change
• Quality work
8.2 Scrum Model
Scrum is an agile way to manage a project, usually software development. Agile software
development with Scrum is often perceived as a methodology; but rather than viewing Scrum
as methodology, think of it as a framework for managing a process.

Scrum team: A typical scrum team has between five and nine people, but Scrum projects
can easily scale into the hundreds. However, Scrum can easily be used by one-person
teams and often is. This team does not include any of the traditional software
engineering roles such as programmer, designer, tester or architect. Everyone on the
project works together to complete the set of work they have collectively committed to
complete within a sprint. Scrum teams develop a deep form of camaraderie and a
feeling that “we’re all in this together.”
Product owner: The product owner is the project’s key stakeholder and represents users,
customers and others in the process. The product owner is often someone from product
management or marketing, a key stakeholder or a key user.
Scrum Master: The Scrum Master is responsible for making sure the team is as
productive as possible. The Scrum Master does this by helping the team use the Scrum
process, by removing impediments to progress, by protecting the team from outside,
and so on.
Product backlog: The product backlog is a prioritized features list containing every
desired feature or change to the product. Note: The term “backlog” can get confusing
because it’s used for two different things. To clarify, the product backlog is a list of
desired features for the product. The sprint backlog is a list of tasks to be completed in
a sprint.
Sprint planning meeting: At the start of each sprint, a sprint planning meeting is held,
during which the product owner presents the top items on the product backlog to the
team. The Scrum team selects the work they can complete during the coming sprint.
That work is then moved from the product backlog to a sprint backlog, which is the list
 of tasks needed to complete the product backlog items the team has committed to
complete in the sprint.
Daily Scrum: Each day during the sprint, a brief meeting called the daily scrum is
conducted. This meeting helps set the context for each day’s work and helps the team
stay on track. All team members are required to attend the daily scrum.
Sprint review meeting: At the end of each sprint, the team demonstrates the completed
functionality at a sprint review meeting, during which, the team shows what they
accomplished during the sprint. Typically, this takes the form of a demonstration of the
new features, but in an informal way; for example, PowerPoint slides are not allowed.
The meeting must not become a task in itself nor a distraction from the process.
Sprint retrospective: Also at the end of each sprint, the team conducts a sprint
retrospective, which is a meeting during which the team (including its Scrum Master
and product owner) reflect on how well Scrum is working for them and what changes
they may wish to make for it to work even better.
Scrum is an iterative framework to help teams manage and progress through a complex
project. It is most commonly used in Software Development by teams that implement
the Agile Software Development methodology. However it is not limited to those
groups. Even if your team does not implement Agile Software Development, you can
still benefit from holding regular scrums with your teams.
Advantages of Agile model:
• Customer satisfaction by rapid, continuous delivery of useful software.
• People and interactions are emphasized rather than process and tools. Customers, developers
and testers constantly interact with each other.
• Working software is delivered frequently (weeks rather than months). Face-to-face
conversation is the best form of communication.
• Close, daily cooperation between business people and developers. Continuous attention to
technical excellence and good design.
• Regular adaptation to changing circumstances.
• Even late changes in requirements are welcomed
Disadvantages of Agile model:
• In case of some software deliverables, especially the large ones, it is difficult to assess the
effort required at the beginning of the software development life cycle.
• There is lack of emphasis on necessary designing and documentation.
• The project can easily get taken off track if the customer representative is not clear what
final outcome that they want.
• Only senior programmers are capable of taking the kind of decisions required during the
development process. Hence it has no place for newbie programmers, unless combined with
experienced resources.
When to use Agile model:
• When new changes are needed to be implemented. The freedom agile gives to change is very
important. New changes can be implemented at very little cost because of the frequency of
new increments that are produced.
• To implement a new feature the developers need to lose only the work of a few days, or even
only hours, to roll back and implement it.
• Unlike the waterfall model in agile model very limited planning is required to get started
with the project. Agile assumes that the end users’ needs are ever changing in a dynamic
business and IT world. Changes can be discussed and features can be newly effected or
removed based on feedback. This effectively gives the customer the finished system they want
or need.
• Both system developers and stakeholders alike, find they also get more freedom of time and
options than if the software was developed in a more rigid sequential way. Having options
gives them the ability to leave important decisions until more or better data or even entire
hosting programs are available; meaning the project can continue to move forward without
fear of reaching a sudden standstill.
Scaling of agile methods
There are two perspectives on the scaling of agile methods:
1. A ‘scaling up’ perspective, which is concerned with using these methods for​
developing large software systems that cannot be developed by a small team.
2. A ‘scaling out’ perspective, which is concerned with how agile methods can be​
introduced across a large organization with many years of software development​
experience.

Process activities
1. Software specification
In this process, detailed description of a software system to be developed with its functional
and non-functional requirements.

2. Software design and implementation (Software Development)

Software development is defined as the process of designing, creating, testing, and
maintaining computer programs and applications. This diverse field combines creativity,
engineering expertise, and problem-solving abilities to produce software that satisfies
particular requirements and goals. Software developers, also known as programmers or
coders, use a variety of programming languages and tools to create solutions for end-users or
businesses.
Software developers develop the software, which itself is a set of instructions in order to
perform a specific task. software have three types.
Types of Softwares
There are three basic types of Software
1. System Software
System software is software that directly operates computer hardware and provides basic
functionality to users as well as other software for it to run smoothly.
2. Application Software
Application software is a software that is designed for end-user to complete a specific task. It
is a product or programm that is only intended to meet the needs of end users. It includes word
processors, spreadsheets, database management, inventory, and payroll software, among other
things.
3. Programming Software
Programming software is a software that is designed for programmers to develop program. It
consists of code editor, compiler, interpreter, debugger etc.
3. Software validation
Verification and Validation is the process of investigating whether a software system satisfies
specifications and standards and fulfills the required purpose.
Verification is the process of checking that software achieves its goal without any bugs. It is
the process to ensure whether the product that is developed is right or not. It verifies whether
the developed product fulfills the requirements that we have.
Validation is the process of checking whether the software product is up to the mark or in
other words product has high-level requirements. It is the process of checking the validation of
the product i.e. it checks what we are developing is the right product. it is a validation of
actual and expected products.

4. Software evolution
The software evolution process includes fundamental activities of change analysis, release
planning, system implementation, and releasing a system to customers.
1.​ The cost and impact of these changes are accessed to see how much the system is
affected by the change and how much it might cost to implement the change.
2.​ If the proposed changes are accepted, a new release of the software system is planned.
3.​ During release planning, all the proposed changes (fault repair, adaptation, and new
functionality) are considered.
4.​ A design is then made on which changes to implement in the next version of the
system.
5.​ The process of change implementation is an iteration of the development process
where the revisions to the system are designed, implemented, and tested.

Waterfall Model Spiral Model Prototyping Model Incremental Model

 Requirements analysis
The requirements can be made in the
Requirements must be Requirements analysis
analysis and gathering later stages of the
clearly understood and can be made in the
can be done in iteration development cycle.
defines at the beginning later stages of the
because requirements Because requirements
only. development cycle.
get changed quite often. get changed quite
often.

The development team

The development team The development team The development team
having the adequate
having the adequate having the adequate having the adequate
experience of working
experience of working experience of working experience of working
on the similar project
on the similar project is on the similar project is on the similar project
is chose to work on
chose to work on this allowed in this process is allowed in this
this type of process
type of process model model. process model.
model

There is no user There is no user There is user There is user

involvement in all the involvement in all the involvement in all the involvement in all the
phases of development phases of development phases of development phases of development
process. process. process. process.

When the
requirements are
reasonably well
Due to iterative nature defined and the
When developer is development effort
When the requirements of this model, the risk
unsure about the suggests a purely
are reasonably well identification and
efficiency of an linear effort and when
defined and the rectification is done
algorithm or the limited set of software
development effort before they get
adaptability of an functionality is needed
suggests a purely linear problematic. Hence for
operating system then quickly then the
effort then the waterfall handling real time
the prototyping model incremental model is
model is chosen. problems the spiral
is chosen. chosen.
model is chosen.