Unit-1

Software engineering: it is the process of designing, developing, testing, and maintaining

software. It is a systematic and disciplined approach to software development that aims to create
high-quality, reliable, and maintainable software. Software engineering includes a variety of
techniques, tools, and methodologies, including requirements analysis, design, testing, and
maintenance.

Some key principles of software engineering include:

a) Modularity: Breaking the software into smaller, reusable components that can be
developed and tested independently.
b) Abstraction: Hiding the implementation details of a component and exposing only the
necessary functionality to other parts of the software.
c) Encapsulation: Wrapping up the data and functions of an object into a single unit, and
protecting the internal state of an object from external modifications.
d) Reusability: Creating components that can be used in multiple projects, which can save
time and resources.
e) Maintenance: Regularly updating and improving the software to fix bugs, add new
features, and address security vulnerabilities.
f) Testing: Verifying that the software meets its requirements and is free of bugs.
g) Design Patterns: Solving recurring problems in software design by providing templates
for solving them.
h) Continuous Integration & Deployment: Continuously integrating the code changes and
deploying them into the production environment.

Need of Software Engineering: The necessity of software engineering appears because of

a higher rate of progress in user requirements and the environment on which the program is
working.

a) Huge Programming: It is simpler to manufacture a wall than to a house or building,

similarly, as the measure of programming become extensive engineering has to step to
give it a scientific process.
b) Adaptability: If the software procedure were not based on scientific and engineering
ideas, it would be simpler to re-create new software than to scale an existing one.
c) Cost: As the hardware industry has demonstrated its skills and huge manufacturing has
let down the cost of computer and electronic hardware. But the cost of programming
remains high if the proper process is not adapted.
d) Dynamic Nature: The continually growing and adapting nature of programming hugely
depends upon the environment in which the client works. If the quality of the software is
continually changing, new upgrades need to be done in the existing one.
e) Quality Management: Better procedure of software development provides a better and
quality software product.
Importance of Software engineering:
a) Reduces complexity: Big software is always complicated and challenging to progress.
Software engineering has a great solution to reduce the complication of any project.
Software engineering divides big problems into various small issues. And then start
solving each small issue one by one. All these small problems are solved independently
to each other.
b) To minimize software cost: Software needs a lot of hardwork and software engineers
are highly paid experts. A lot of manpower is required to develop software with a large
number of codes. But in software engineering, programmers project everything and
decrease all those things that are not needed. In turn, the cost for software productions
becomes less as compared to any software that does not use software engineering
method.
c) To decrease time: Anything that is not made according to the project always wastes
time. And if you are making great software, then you may need to run many codes to get
the definitive running code. This is a very time-consuming procedure, and if it is not well
handled, then this can take a lot of time. So if you are making your software according to
the software engineering method, then it will decrease a lot of time.
d) Handling big projects: Big projects are not done in a couple of days, and they need lots
of patience, planning, and management. And to invest six and seven months of any
company, it requires heaps of planning, direction, testing, and maintenance. No one can
say that he has given four months of a company to the task, and the project is still in its
first stage. Because the company has provided many resources to the plan and it should
be completed. So to handle a big project without any problem, the company has to go for
a software engineering method.
e) Reliable software: Software should be secure, means if you have delivered the software,
then it should work for at least its given time or subscription. And if any bugs come in the
software, the company is responsible for solving all these bugs. Because in software
engineering, testing and maintenance are given, so there is no worry of its reliability.
f) Effectiveness: Effectiveness comes if anything has made according to the standards.
Software standards are the big target of companies to make it more effective. So Software
becomes more effective in the act with the help of software engineering.

Software : Software is the set of instructions in the form of programs to govern the computer
system and to process the hardware components. To produce a software product the set of
activities is used. This set is called a software process.

The Evolving Role of Software:

1. It is a product
2. Vehicle for delivering a product.

As a product, it delivers the computing potential embodied by computer hardware. Whether it

resides within a mobile phone or operates inside a mainframe computer, software is an
information transformer.
As the vehicle used to deliver the product, software acts as the basis for the control of the
computer (operating systems), the communication of information (networks), and the creation
and control other programs (software tools and environments).

Components of Software: There are three components of the software:

a) Program
b) Documentation
c) Operating Procedures

a) Program – A computer program is a list of instructions that tell a computer what to do.

b) Documentation – Source information about the product contained in design documents,

detailed code comments, etc.
 c) Operating Procedures –Set of step-by-step instructions compiled by an organization to
help workers carry out complex routine operations.

Characteristics of Software:
a) Software is not manufactured: Software is not manufactured but is developed. So, it
does not require any raw material for its development.
b) Software does not wear out: Different things like clothes, shoes, ornaments do wear out
after some time. But, software once created never wears out. It can be used for as long as
needed and in case of need for any updating, required changes can be made in the same
software and then it can be used further with updated features.
c) Usability of Software: The usability of the software is the simplicity of the software in
terms of the user. The easier the software is to use for the user, the more is the usability
of the software as more number of people will now be able to use it and also due to the
ease will use it more willingly.
d) Reusability of components: As the software never wears out, neither do its components,
i.e. code segments. So, if any particular segment of code is required in some other
software, we can reuse the existing code form the software in which it is already present.
This reduced our work and also saves time and money.
e) Flexibility of software: Software is flexible. What this means is that we can make
necessary changes in our software in the future according to the need of that time and
then can use the same software then also.
f) Maintainability of software: Every software is maintainable. This means that if any
errors or bugs appear in the software, then they can be fixed.
g) Portability of software: Portability of the software means that we can transfer our
software from one platform to another that too with ease. Due to this, the sharing of the
software among the developers and other members can be done flexibly.
 h) Reliability of Software: This is the ability of the software to provide the desired
functionalities under every condition. This means that our software should work properly
in each condition.

Changing Nature of Software:

There are seven broad categories of computer software having different forms, uses and
challenges to software engineers.

1) System Software: It is a collection of programs written to service other programs. Some

system software are compilers, editors, file management utilities. They process complex but
determinate information structure. Other system applications can be operating system
components, drivers, networking software. They process largely indeterminate data. In either
case the system software area is characterized by heavy interaction with computer hardware,
heavy usage by multiple users, concurrent operation that requires scheduling, resource
sharing, and sophisticated process management, complex data structure, and multiple
external interfaces.
2) Application software: These consist of standalone programs that solve a specific business
need. Applications in this area process business or technical data in a way that facilitates
business operations or management/technical decision making. These are used to control
business functions in real time.
3) Engineering/scientific software: This software range from astronomy to volcanology, from
automotive stress analysis to space shuttle orbital dynamics and from molecular biology to
automated manufacturing.
4) Embedded software: This software resides within a product or system and is used to
implement and control features and functions for the end user and for the system itself. It
can perform limited and esoteric functions or provide significant function and control
capability.
5) Product line software: These are designed to provide a specific capability for use by many
different customers. They focus on a limited and esoteric market place. This software
addresses mass consumer markets.
6) Web-applications: Web apps or web applications are evolving into sophisticated computing
environments that not only provide standalone features, computing functions and content to
the end user but also integrated with corporate databases and business applications.
7) Artificial intelligence software: It makes use of non numerical algorithms to solve complex
problems that are not amenable to computations or straightaway analysis. Applications
within this area include robotics, expert systems pattern recognition, artificial neural
networks, theorem proving and game playing.

Software Myths:
Software myths are the beliefs that people consider are true but are not, regarding software and
its development process. The software myths have been carried over several years and are now
identified by software engineering professionals.
Different Types of Software Myths

1. Management Myths:
Myth 1:
We have all the standards and procedures available for software development.
Fact:
Software experts do not know all the requirements for the software development. And all
existing processes are incomplete as new software development is based on new and different
problem.

Myth 2:
The addition of the latest hardware programs will improve the software development.
Fact:
The role of the latest hardware is not very high on standard software development; instead
(CASE) Engineering tools help the computer, they are more important than hardware to produce
quality and productivity. Hence, the hardware resources are misused.

Myth 3:
With the addition of more people and program planners to Software development can help meet
project deadlines (If lagging behind).
Fact:
If software is late, adding more people will merely make the problem worse. This is because the
people already working on the project now need to spend time educating the newcomers, and are
thus taken away from their work. The newcomers are also far less productive than the existing
software engineers, and so the work put into training them to work on the software does not
immediately meet with an appropriate reduction in work.

2. Customer Myths:
The customer can be the direct users of the software, the technical team, marketing / sales
department, or other company. Customer has myths leading to false expectations (customer) &
that’s why you create dissatisfaction with the developer.

Myth 1:

A general statement of intent is enough to start writing plans (software development) and details
of objectives can be done over time.

Fact:

Official and detailed description of the database function, ethical performance, communication,
structural issues and the verification process are important.

Unambiguous requirements (usually derived iteratively) are developed only through effective
and continuous communication between customer and developer.

Myth 2:
Software requirements continually change, but change can be easily accommodated because
software is flexible

Fact:

It is true that software requirements change, but the impact of change varies with the time at
which it is introduced. When requirements changes are requested early (before design or code
has been started), the cost impact is relatively small. However, as time passes, the cost impact
grows rapidly—resources have been committed, a design framework has been established, and
change can cause upheaval that requires additional resources and major design modification.

3. Practitioner’s Myths:

Myths 1:

They believe that their work has been completed with the writing of the plan.

Fact:

It is true that every 60-80% effort goes into the maintenance phase (as of the latter software
release). Efforts are required, where the product is available first delivered to customers.

Myths 2:

There is no other way to achieve system quality, until it is “running”.

Fact:

Systematic review of project technology is the quality of effective software verification method.
These updates are quality filters and more accessible than test.

Myth 3:

An operating system is the only product that can be successfully exported project.

Fact:

A working system is not enough, the right document brochures and booklets are also required to
provide guidance & software support.

Myth 4:

Engineering software will enable us to build powerful and unnecessary document & always
delay us.

Fact:

Software engineering is not about creating documents. It is about creating a quality product.
Better quality leads to reduced rework. And reduced rework results in faster delivery times
Software Processes: A software process is the set of activities and associated outcome that
produce a software product. Software engineers mostly carry out these activities. These are four
key process activities, which are common to all software processes. These activities are:

a) Software specifications: The functionality of the software and constraints on its

operation must be defined.
b) Software development: The software to meet the requirement must be produced.
c) Software validation: The software must be validated to ensure that it does what the
customer wants.
d) Software evolution: The software must evolve to meet changing client needs.

Process Pattern: As the software team moves through the software process they encounter
problems. It would be very useful if solutions to these problems were readily available so that
problems can be resolved quickly. Process-related problems which are encountered during
software engineering work, it identifies the encountered problem and in which environment it is
found, then it will suggest proven solutions to problem, they all are described by process pattern.
By solving problems a software team can construct a process that best meets needs of a project.

Uses of the process pattern:

At any level of abstraction, patterns can be defined. They can be used to describe a problem and
solution associated with framework activity in some situations. While in other situations patterns
can be used to describe a problem and solution associated with a complete process model.

Template:

Pattern Name – Meaningful name must be given to a pattern within context of software process
(e.g. Technical Reviews).

Forces – The issues that make problem visible and may affect its solution also environment in
which pattern is encountered.

Type of the process pattern: It is of three types :

1. Stage pattern – Problems associated with a framework activity for process are described by
stage pattern. Establishing Communication might be an example of a staged pattern. This
pattern would incorporate task pattern Requirements Gathering and others.
2. Task-pattern – Problems associated with a software engineering action or work task and
relevant to successful software engineering practice (e.g., Requirements Gathering is a task
pattern) are defined by task-pattern.
3. Phase pattern – Even when the overall flow of activities is iterative in nature, it defines
sequence of framework activities that occurs within process. Spiral Model or Prototyping
might be an example of a phase pattern.
Software Process Assessment: It is a disciplined and organized examination of the software
process which is being used by any organization bases the on the process model. The Software
Process Assessment includes many fields and parts like identification and characterization of
current practices, the ability of current practices to control or avoid significant causes of poor
(software) quality, cost, schedule and identifying areas of strengths and weaknesses of the
software.

Types of Software Assessment :

1. Self Assessment : This is conducted internally by the people of their own organization.
2. Second Party assessment: This is conducted by an external team or people of the own
organization are supervised by an external team.
3. Third Party assessment: In an ideal case Software Process Assessment should be
performed in a transparent, open and collaborative environment. This is very important for
the improvement of the software and the development of the product. The results of the
Software Process Assessment are confidential and are only accessible to the company. The
assessment team must contain at least one person from the organization that is being
assessed.

Personal and Team Process Model in Software Engineering:

The best software process is personal and team process model one that is close to the people who
will be doing the work. Watts Humphrey proposed two process models. Models “Personal
Software Process (PSP)” and “Team Software Process (TSP).” Both require hard work, training,
and coordination, but both are achievable.

Personal Software Process (PSP):

The Personal Software Process (PSP) emphasizes personal measurement of both the work
product that is produced and the resultant quality of the work product.

In addition PSP makes the practitioner responsible for project planning and empowers the
practitioner to control the quality of all software work products that are developed. The PSP
model defines five framework activities:

 Planning: This activity isolates requirements and develops both size and resource
estimates. In addition, defects estimate (the number of defects projected for the work) is
made. All metrics are recorded on worksheets or templates. Finally, development tasks
are identified and a project schedule is created.
 High level design: External specifications for each component to be constructed are
developed and a component design is created. Prototypes are built when uncertainty
exists. All issues are recorded and tracked.
 High level design review: Formal verification methods are applied to uncover errors in
the design. Metrics are maintained for all important tasks and work results.
 Development: The component level design is refined and reviewed. Code is generated,
reviewed, compiled, and tested. Metrics are maintained for all important tasks and work
results.
PSP stresses the need to identify errors early and, just as important, to understand the types of
errors that you are likely to make. PSP represents a disciplined, metrics based approach to
software engineering that may lead to culture shock for many practitioners.

Team Software Process (TSP):

Watts Humphrey extended the lessons learned from the introduction of PSP and proposed a
Team Software Process (TSP). The goal of TSP is to build a “self directed” project team that
organizes itself to produce high quality software.

Humphrey defines the following objectives for TSP:

 Build self directed teams that plan and track their work, establish goals, and own their
processes and plans. These can be pure software teams or integrated product teams (IPTs)
of 3 to about 20 engineers.
 Show managers how to coach and motivate their teams and how to help them sustain
peak performance
 Accelerate software process improvement by making CMM23 Level 5 behavior normal
and expected.
 Provide improvement guidance to high-maturity organizations.
 Facilitate university teaching of industrial-grade team skills.

A self directed team has a consistent understanding of its overall goals and objectives; defines
roles and responsibilities for each team member; tracks quantitative project data (about
productivity and quality); identifies a team process that is appropriate for the project and a
strategy for implementing the process; defines local standards that are applicable to the team’s
software engineering work; continually assesses risk and reacts to it; and tracks, manages, and
reports project status.

TSP defines the following framework activities: project launch, high level design,
implementation, personal and team process model, integration and test, and postmortem.

TSP makes use of a wide variety of scripts, forms, and standards that serve to guide team
members in their work. “Scripts” define specific process activities (project launch, design,
implementation, integration and system testing, postmortem) and other more detailed work
functions (development planning, requirements development, software configuration
management, unit test) that are part of the team process.

Software Process Models: These are convenient tools that developers use to map every
step of their projects. They help project managers plan their processes, estimate costs, identify
challenges and communicate with teams and customers. A software process model is a digital or
hand-written model that details the software development process. Process models help provide a
visual representation of the development process for both the team and the customer to review.
This helps them determine the right process to follow for specific software, identify early
challenges or cost constraints and acts as a record of the team's development process for the
future.

Types of software process models:

There are many types of software process models that development teams use across different
industries. Here are some examples of typical software process models you can use to outline
your development process:

1. The Waterfall Model: The waterfall model is a software development model used in the
context of large, complex projects, typically in the field of information technology. It is
characterized by a structured, sequential approach to project management and software
development. The waterfall model is useful in situations where the project requirements are well-
defined and the project goals are clear. It is often used for large-scale projects with long
timelines, where there is little room for error and the project stakeholders need to have a high
level of confidence in the outcome.

Features of the Waterfall Model:

 Sequential Approach: The waterfall model involves a sequential approach to software

development, where each phase of the project is completed before moving on to the next
one.
 Document-Driven: The waterfall model relies heavily on documentation to ensure that
the project is well-defined and the project team is working towards a clear set of goals.
 Quality Control: The waterfall model places a high emphasis on quality control and
testing at each phase of the project, to ensure that the final product meets the
requirements and expectations of the stakeholders.
 Rigorous Planning: The waterfall model involves a rigorous planning process, where the
project scope, timelines, and deliverables are carefully defined and monitored throughout
the project lifecycle.

Phases of Waterfall Model:

Waterfall Model is a classical software development methodology that was first introduced by
Winston W. Royce in 1970. It is a linear and sequential approach to software development that
consists of several phases that must be completed in a specific order. The phases include:
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 aim of the requirement analysis and specification phase is to understand the exact
requirements of the customer and document them properly. This phase consists of two different
activities.

a. 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).

b. 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 aim of the unit testing phase
is to check whether each module is working properly or not.

5. Integration and System testing:

Integration of different modules is undertaken soon after they have been coded and unit tested.
Integration of various modules is carried out incrementally over a number of steps. During each
integration step, previously planned modules are added to the partially integrated system and the
resultant system is tested. Finally, after all the modules have been successfully integrated and
tested, the full working system is obtained and system testing is carried out on this.

System testing consists 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 performed
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 full software. There are basically three
types of maintenance.

Advantages of the Classical Waterfall Model:

The classical waterfall model is an idealistic model for software development. It is very simple,
so it can be considered the basis for other software development life cycle models. Below are
some of the major advantages of this SDLC model.

 Easy to Understand: Classical Waterfall Model is very simple and easy to understand.
 Individual Processing: Phases in the Classical Waterfall model are processed one at a
time.
 Properly Defined: In the classical waterfall model, each stage in the model is clearly
defined.
 Clear Milestones: Classical Waterfall model has very clear and well-understood
milestones.
 Properly Documented: Processes, actions, and results are very well documented.
  Reinforces Good Habits: Classical Waterfall Model reinforces good habits like define-
before-design and design-before-code.
 Working: Classical Waterfall Model works well for smaller projects and projects where
requirements are well understood.

Disadvantages of the Classical Waterfall Model

The Classical Waterfall Model suffers from various shortcomings, basically, we can’t use it in
real projects, but we use other software development lifecycle models which are based on the
classical waterfall model. Below are some major drawbacks of this model.

 No Feedback Path: In the classical waterfall model evolution of software from one
phase to another phase is like a waterfall. It assumes that no error is ever committed by
developers during any phase. Therefore, it does not incorporate any mechanism for error
correction.
 Difficult to accommodate Change Requests: This model assumes that all the customer
requirements can be completely and correctly defined at the beginning of the project, but
actually customer’s requirements keep on changing with time. It is difficult to
accommodate any change requests after the requirements specification phase is complete.
 No Overlapping of Phases: This model recommends that a new phase can start only
after the completion of the previous phase. But in real projects, this can’t be maintained.
To increase efficiency and reduce cost, phases may overlap.
 Limited Flexibility: The Waterfall Model is a rigid and linear approach to software
development, which means that it is not well-suited for projects with changing or
uncertain requirements. Once a phase has been completed, it is difficult to make changes
or go back to a previous phase.
 Limited Stakeholder Involvement: The Waterfall Model is a structured and sequential
approach, which means that stakeholders are typically involved in the early phases of the
project (requirements gathering and analysis) but may not be involved in the later phases
(implementation, testing, and deployment).
 Late Defect Detection: In the Waterfall Model, testing is typically done toward the end
of the development process. This means that defects may not be discovered until late in
the development process, which can be expensive and time-consuming to fix.
 Lengthy Development Cycle: The Waterfall Model can result in a lengthy development
cycle, as each phase must be completed before moving on to the next. This can result in
delays and increased costs if requirements change or new issues arise.
 Not Suitable for Complex Projects: The Waterfall Model is not well-suited for complex
projects, as the linear and sequential nature of the model can make it difficult to manage
multiple dependencies and interrelated components.

The Incremental Process Model: It is also known as the Successive version model. First,
a simple working system implementing only a few basic features is built and then that is
delivered to the customer. Then thereafter many successive iterations/ versions are implemented
and delivered to the customer until the desired system is released.
 A, B, and C are modules of Software Products that are incrementally developed and delivered.

Types of Incremental model:

1. Staged Delivery Model: Construction of only one part of the project at a time.

2. Parallel Development Model – Different subsystems are developed at the same time. It
can decrease the calendar time needed for the development, i.e. TTM (Time to Market) if
enough resources are available.

When to use this:

 1. Funding Schedule, Risk, Program Complexity, or need for early realization of benefits.
2. When Requirements are known up-front.
3. When Projects have lengthy development schedules.
4. Projects with new Technology.
 Error Reduction (core modules are used by the customer from the beginning of
the phase and then these are tested thoroughly)
 Uses divide and conquer for a breakdown of tasks.
 Lowers initial delivery cost.
 Incremental Resource Deployment.
5. Requires good planning and design.
6. The total cost is not lower.
7. Well-defined module interfaces are required.

Advantages-
 Prepares the software fast.
 Clients have a clear idea of the project.
 Changes are easy to implement.
 Provides risk handling support, because of its iterations.

Disadvantages-
 A good team and proper planned execution are required.
 Because of its continuous iterations the cost increases.

Evolutionary Process Model:

The evolutionary model is based on the concept of making an initial product and then evolving
the software product over time with iterative and incremental approaches with proper feedback.
In this type of model, the product will go through several iterations and come up when the final
product is built through multiple iterations. The development is carried out simultaneously with
the feedback during the development. This model has a number of advantages such as customer
involvement, taking feedback from the customer during development, and building the exact
product that the user wants. Because of the multiple iterations, the chances of errors get reduced
and the reliability and efficiency will increase.

Types of Evolutionary Process Models:

  Iterative Model
 Incremental Model
 Spiral Model

Iterative Model:

In the iterative model first, we take the initial requirements then we enhance the product over
multiple iterations until the final product gets ready. In every iteration, some design
modifications were made and some changes in functional requirements is added. The main idea
behind this approach is to build the final product through multiple iterations that result in the
final product being almost the same as the user wants with fewer errors and the performance, and
quality would be high.

Incremental Model:
In the incremental model, we first build the project with basic features and then evolve the
project in every iteration, it is mainly used for large projects. The first step is to gather the
requirements and then perform analysis, design, code, and test and this process goes the same
over and over again until our final project is ready.
Spiral Model
The spiral model is a combination of waterfall and iterative models and in this, we focused on
risk handling along with developing the project with the incremental and iterative approach,
producing the output quickly as well as it is good for big projects. The software is created
through multiple iterations using a spiral approach. Later on, after successive development the
final product will develop, and the customer interaction is there so the chances of error get
reduced.
Advantages of the Evolutionary Process Model:
 During the development phase, the customer gives feedback regularly because the
customer’s requirement gets clearly specified.
 After every iteration risk gets analyzed.
 Suitable for big complex projects.
 The first build gets delivered quickly as it used an iterative and incremental approach.

Disadvantages of the Evolutionary Process Model:

 It is not suitable for small projects.
 The complexity of the spiral model can be more than the other sequential models.
 The cost of developing a product through a spiral model is high.

The Unified Process in Software Engineering:

Unified process (UP) is an architecture centric, use case driven, iterative and incremental
development process. UP is also referred to as the unified software development process.

The Unified Process recognizes the importance of customer communication and streamlined
methods for describing the customer’s view of a system. It emphasizes the important role of
software architecture and “helps the architect focus on the right goals, such as understandability,
reliance to future changes, and reuse”.

It suggests a process flow that is iterative and incremental, providing the evolutionary feel that is
essential in modern software development.

Phases of the Unified Process:

This process divides the development process into five phases:

 Inception: The inception phase of the UP encompasses both customer communication

and planning activities. By collaborating with stakeholders, business requirements for
the software are identified; a rough architecture for the system is proposed; and a plan
for the iterative, incremental nature of the ensuing project is developed.
 Elaboration: The elaboration phase encompasses the communication and modeling
activities of the generic process model. Elaboration refines and expands the
preliminary use cases that were developed as part of the inception phase and expands
the architectural representation to include five different views of the software the use
case model, the requirements model, the design model, the implementation model,
and the deployment model.
 Conception: The construction phase of the UP is identical to the construction activity
defined for the generic software process. Using the architectural model as input, the
construction phase develops or acquires the software components that will make each
use case operational for end users. To accomplish this, requirements and design
models that were started during the elaboration phase are completed to reflect the
final version of the software increment. All necessary and required features and
 functions for the software increment (the release) are then implemented in source
code.
 Transition: The transition phase of the UP encompasses the latter stages of the
generic construction activity and the first part of the generic deployment (delivery and
feedback) activity. Software is given to end users for beta testing and user feedback
reports both defects and necessary changes. At the conclusion of the transition phase,
the software increment becomes a usable software release.
 Production: The production phase of the UP coincides with the deployment activity
of the generic process. During this phase, the ongoing use of the software is
monitored, support for the operating environment (infrastructure) is provided, and
defect reports and requests for changes are submitted and evaluated.

Software Crisis: The difficulty of writing the code for a computer program which is correct
and understandable is referred to as software crisis.

a) Size: Software is becoming more expensive and more complex with the growing
complexity and expectation out of software. For example, the code in the consumer
product is doubling every couple of years.
b) Quality: Many software products have poor quality, i.e., the software products defects
after putting into use due to ineffective testing technique. For example, Software testing
typically finds 25 errors per 1000 lines of code.
c) Cost: Software development is costly i.e. in terms of time taken to develop and the
money involved. For example, Development of the FAA's Advanced Automation System
cost over $700 per lines of code.
d) Delayed Delivery: Serious schedule overruns are common. Very often the software takes
longer than the estimated time to develop, which in turn leads to cost shooting up. For
example, one in four large-scale development projects are never completed.

Software Development Life Cycle:

SDLC is a systematic process for building software that ensures the quality and correctness of
the software built. SDLC process aims to produce high-quality software that meets customer
expectations. The system development should be complete in the pre-defined time frame and
cost. SDLC consists of a detailed plan which explains how to plan, build, and maintain specific
software. Every phase of the SDLC life Cycle has its own process and deliverables that feed into
the next phase. SDLC stands for Software Development Life Cycle and is also referred to as the
Application Development life-cycle.

SDLC Phases:

The entire SDLC process divided into the following SDLC steps:
All these Software Development Life Cycle Phases are :

Phase 1: Requirement collection and analysis

The requirement is the first stage in the SDLC process. It is conducted by the senior team
members with inputs from all the stakeholders and domain experts in the industry. Planning for
the quality assurance requirements and reorganization of the risks involved is also done at this
stage. This stage gives a clearer picture of the scope of the entire project and the anticipated
issues, opportunities, and directives which triggered the project. Requirements Gathering stage
need teams to get detailed and precise requirements. This helps companies to finalize the
necessary timeline to finish the work of that system.

Phase 2: Feasibility study

Once the requirement analysis phase is completed the next sdlc step is to define and document
software needs. This process conducted with the help of ‘Software Requirement Specification’
document also known as ‘SRS’ document. It includes everything which should be designed and
developed during the project life cycle.

There are mainly five types of feasibilities checks:

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

b) Legal: Can we handle this project as cyber law and other regulatory
framework/compliances.
c) Operation feasibility: Can we create operations which are expected by the client?
d) Technical: Need to check whether the current computer system can support the software
e) Schedule: Decide that the project can be completed within the given schedule or not.

Phase 3: Design
In this third phase, the system and software design documents are prepared as per the
requirement specification document. This helps define overall system architecture. This design
phase serves as input for the next phase of the model. There are two kinds of design documents
developed in this phase:

High-Level Design (HLD)

 Brief description and name of each module

 An outline about the functionality of every module
 Interface relationship and dependencies between modules
 Database tables identified along with their key elements
 Complete architecture diagrams along with technology details
Low-Level Design (LLD)

 Functional logic of the modules

 Database tables, which include type and size
 Complete detail of the interface
 Addresses all types of dependency issues
 Listing of error messages
 Complete input and outputs for every module

Phase 4: Coding
Once the system design phase is over, the next phase is coding. In this phase, developers start
build the entire system by writing code using the chosen programming language. In the coding
phase, tasks are divided into units or modules and assigned to the various developers. It is the
longest phase of the Software Development Life Cycle process.

In this phase, Developer needs to follow certain predefined coding guidelines. They also need to
use programming tools like compiler, interpreters, debugger to generate and implement the code.

Phase 5: Testing
Once the software is complete, and it is deployed in the testing environment. The testing team
starts testing the functionality of the entire system. This is done to verify that the entire
application works according to the customer requirement.

During this phase, QA and testing team may find some bugs/defects which they communicate to
developers. The development team fixes the bug and send back to QA for a re-test. This process
continues until the software is bug-free, stable, and working according to the business needs of
that system.

Phase 6: Installation/Deployment
Once the software testing phase is over and no bugs or errors left in the system then the final
deployment process starts. Based on the feedback given by the project manager, the final
software is released and checked for deployment issues if any.

Phase 7: Maintenance
Once the system is deployed, and customers start using the developed system, following 3
activities occur

 Bug fixing – bugs are reported because of some scenarios which are not tested at all
 Upgrade – Upgrading the application to the newer versions of the Software
 Enhancement – Adding some new features into the existing software