What is a Software?

Software is defined as the set of instructions or programs that are used

by a computer for performing specific tasks. With these sets of
instructions, we can create different software applications like –
calculators, web browsers, operating systems, etc.
Engineering is a scientific field that involves taking the scientific
understanding of the natural world and using it to invent, design, and
build things to solve problems and achieve practical goals.
What is Software Engineering?
According to IEEE, Software engineering is the systematic design and
development of software products and the management of the software
process. It has as one of its primary objectives the production of
programs that meet specifications, and are demonstrably accurate,
produced on time, and within budget.
THE EVOLVING ROLE OF A SOFTWARE

What is Software Engineering?

The term software engineering is the product of two words, software, and
engineering. The software is a collection of integrated programs. Software
subsists of carefully-organized instructions and code written by developers on any
of various particular computer languages. Computer programs and related
documentation such as requirements, design models and user manuals.

Engineering is the application of scientific and practical knowledge to invent,

design, build, maintain, and improve frameworks, processes, etc. Software
Engineering is an engineering branch related to the evolution of software product
using well-defined scientific principles, techniques, and procedures. The result of
software engineering is an effective and reliable software product

. THE EVOLVING ROLE OF SOFTWARE

Today, software takes on a dual role. It is a product and, at the same time, the
vehicle for delivering a product. As a product, it delivers the computing potential
embodied by computer hardware or, more broadly, a network of computers that
are accessible by local hardware. Whether it resides within a cellular phone or
operates inside a mainframe computer, software is an information transformer—
producing, managing, acquiring, modifying, displaying, or transmitting
information that can be as simple as a single bit or as complex as a multimedia
presentation.

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 of other programs (software tools and
environments). Software delivers the most important product of our time—
information.

Software transforms personal data (e.g., an individual’s financial transactions) so

that the data can be more useful in a local context; it manages business
information to enhance competitiveness; it provides a gateway to worldwide
information networks (e.g., Internet) and provides the means for acquiring
information in all of its forms

. The role of computer software has undergone significant change over a time
span of little more than 50 years. Dramatic improvements in hardware
performance, profound changes in computing architectures, vast increases in
memory and storage capacity, and a wide variety of exotic input and output
options have all precipitated more sophisticated and complex computer-based
systems. The lone programmer of an earlier era has been replaced by a team of
software specialists, each focusing on one part of the technology required to
deliver a complex application.

Why is Software Engineering required?

1. Changes in requirement – With frequent changes in the business
requirements and the environment, a properly documented and well-
defined system of software development is required which makes it
eminent to use Software Engineering.
2. Large and complex software – With large and complex software, it
becomes difficult to handle the software product but with the concept
of software engineering, it is comparatively easier to build and manage
them.
3. Scalability – Scalability is used to describe the ability of the software to
grow and manage according to the increasing demand of the market.
4. Adaptability -It also helps in creating software that is adaptable to the
changing needs of software usage efficiently.
5. To reduce the time – More often than not software product
development exceeds the time this can be because of various reasons,
some of which can be avoidable. When software engineering concepts
are employed, proper development process and tools are used that
makes it possible to develop the software within the time-lines.

Software Myths
Software myths are misleading attitudes that have caused serious problems
for managers and technical people alike. Software myths propagate
misinformation and confusion. There are three kinds of software myths:

1) Management myths:
Managers with software responsibility are often under pressure to maintain
budgets, keep schedules from slipping, and improve quality. Following are
the management myths:

 Myth:
We already have a book that’s full of standards and procedures for
building software, won’t that provide my people with everything they need
to know?

Reality:
The book of standards may very well exist, but isn’t used. Most software
practitioners aren’t aware of its existence. Also, it doesn’t reflect modern
software engineering practices and is also complete.

 Myth:
My people have state-of-the-art software development tools, after all, we
buy them the newest computers.

Reality:
It takes much more than the latest model mainframe, workstation, or PC to
do high-quality software development. Computer-aided software
engineering (CASE) tools
are more important than hardware for achieving good quality and
productivity, yet the majority of software developers still do not use them
effectively.

 Myth:
If we get behind schedule, we can add more programmers and catch up
(sometimes called the Mongolian horde concept).
Reality:
Software development is not a mechanistic process like manufacturing. As
new people are added, people who were working must spend time
educating the newcomers, thereby reducing the amount of time spent on
productive development effort. People can be added but only in a planned
and well-coordinated manner.
 Myth:
 If I decide to outsource the software project to a third party, I can just relax
and let that firm build it.
Reality:
If an organization does not understand how to manage and control
software projects internally, it will invariably struggle when it outsources
software projects.
2) Customer myths:
Customer myths lead to false expectations (by the customer) and
ultimately, dissatisfaction with the developer. Following are the
customer myths:
 Myth:
A general statement of objectives is sufficient to begin writing programs-
we can fill in the details later.

Reality:
A poor up-front definition is the major cause of failed software efforts. A
formal and detailed description of the functions, behavior, performance,
interfaces, design constraints, and validation criteria is essential.

 Myth:
Project requirements continually change, but change can be easily
accommodated because software is flexible.

Reality
: It is true that software requirements change, but the impact of change
varies with the time at which it is introduced. When changes are
requested during software design, the cost impact grows rapidly.
Resources have been committed and a design framework has been
established. Change can cause heavy additional costs. Change, when
requested after software is in production, can be much more expensive
than the same change requested earlier.
3) Practitioner’s myths:
Practitioners have following myths:
Myth
: Once we write the program and get it to work, our job is done.

Reality:
Industry data indicate that between 60 and 80 percent of all effort
expended on software will be expended after it is delivered to the
customer for the first time.
  Myth:
Until I get the program “running” I have no way of assessing its quality.

Reality:
One of the most effective software quality assurance mechanisms can
be applied from the inception of a project—the formal technical review.

Software Engineering – A Layered

Technology
Software engineering, basically, comprises a process, a set of methods, and a
collection of tools for managing and developing a software system.

1. Quality – Quality focus is an organization’s goal that aims at improving

software engineering processes.
2. Process – A framework that must be established for the effective
delivery of software that includes the timely development of the
software, management, and control of software projects.
3. Methods – Methods provide technical aspects i.e. “how-to” for building
software e.g. requirement analysis, testing support, maintainability, etc.
 4. Tools – Tools provide automated/semi-automated support for the
implementation of ‘process’ and ‘methods’. Simply put, tools help in
developing software applications e.g. Adobe Creative Cloud helps in
Graphics designing or animation

1. Quality – Quality focus is an organization’s goal that aims at improving

software engineering processes.
2. Process – A framework that must be established for the effective
delivery of software that includes the timely development of the
software, management, and control of software projects.
3. Methods – Methods provide technical aspects i.e. “how-to” for building
software e.g. requirement analysis, testing support, maintainability, etc.
4. Tools – Tools provide automated/semi-automated support for the
implementation of ‘process’ and ‘methods’. Simply put, tools help in
developing software applications e.g. Adobe Creative Cloud helps in
Graphics designing or animation

Software Engineering | Software Process Framework

Framework is a Standard way to build and deploy applications. Software

Process Framework is the foundation of complete software engineering
process. Software process framework includes set of all umbrella activities. It
also includes number of framework activities that are applicable to all software
projects.
1. Communication:
In this activity, heavy communication with customers and other stakeholders,
as well as requirement gathering is done.
2. Planning:
In this activity, we discuss the technical related tasks, work schedule, risks,
required resources, etc.
3. Modeling:
Modeling is about building representations of things in the ‘real world’. In
modeling activity, a product’s model is created in order to better understand
the requirements.
4. Construction:
In software engineering, construction is the application of set of procedures
 that are needed to assemble the product. In this activity, we generate the
code and test the product in order to make better product.
5. Deployment:
In this activity, a complete or non-complete product or software is
represented to the customers to evaluate and give feedback. On the basis of
their feedback, we modify the product for supply of better product.

Capability Maturity Model Integration

(CMMI)
Capability Maturity Model Integration (CMMI) is a successor of CMM and is a
more evolved model that incorporates best components of individual disciplines
of CMM like Software CMM, Systems Engineering CMM, People CMM, etc.
Since CMM is a reference model of matured practices in a specific discipline, so
it becomes difficult to integrate these disciplines as per the requirements. This
is why CMMI is used as it allows the integration of multiple disciplines as and
when needed.

Objectives of CMMI :
1. Fulfilling customer needs and expectations.
2. Value creation for investors/stockholders.
3. Market growth is increased.
4. Improved quality of products and services.
5. Enhanced reputation in Industry.
CMMI Representation – Staged and Continuous :
A representation allows an organization to pursue a different set of
improvement objectives. There are two representations for CMMI :
 Staged Representation :
 uses a pre-defined set of process areas to define improvement
path.
 provides a sequence of improvements, where each part in the
sequence serves as a foundation for the next.
 an improved path is defined by maturity level.
 maturity level describes the maturity of processes in organization.
 Staged CMMI representation allows comparison between different
organizations for multiple maturity levels.
 Continuous Representation :
 allows selection of specific process areas.
 uses capability levels that measures improvement of an individual
process area.
  Continuous CMMI representation allows comparison between
different organizations on a process-area-by-process-area basis.
 allows organizations to select processes which require more
improvement.
 In this representation, order of improvement of various processes
can be selected which allows the organizations to meet their
objectives and eliminate risks.
CMMI Model – Maturity Levels :
In CMMI with staged representation, there are five maturity levels described as
follows :
1. Maturity level 1 : Initial
 processes are poorly managed or controlled.
 unpredictable outcomes of processes involved.
 ad hoc and chaotic approach used.
 No KPAs (Key Process Areas) defined.
 Lowest quality and highest risk.
2. Maturity level 2 : Managed
 requirements are managed.
 processes are planned and controlled.
 projects are managed and implemented according to their
documented plans.
 This risk involved is lower than Initial level, but still exists.
 Quality is better than Initial level.
3. Maturity level 3 : Defined
 processes are well characterized and described using standards,
proper procedures, and methods, tools, etc.
 Medium quality and medium risk involved.
 Focus is process standardization.
4. Maturity level 4 : Quantitatively managed
 quantitative objectives for process performance and quality are set.
 quantitative objectives are based on customer requirements,
organization needs, etc.
 process performance measures are analyzed quantitatively.
 higher quality of processes is achieved.
 lower risk
5. Maturity level 5 : Optimizing
 continuous improvement in processes and their performance.
 improvement has to be both incremental and innovative.
 highest quality of processes.
 lowest risk in processes and their performance.
CMMI Model – Capability Levels
A capability level includes relevant specific and generic practices for a specific
process area that can improve the organization’s processes associated with
that process area. For CMMI models with continuous representation, there are
six capability levels as described below :
1. Capability level 0 : Incomplete
 incomplete process – partially or not performed.
 one or more specific goals of process area are not met.
 No generic goals are specified for this level.
 this capability level is same as maturity level 1.
2. Capability level 1 : Performed
 process performance may not be stable.
 objectives of quality, cost and schedule may not be met.
 a capability level 1 process is expected to perform all specific and
generic practices for this level.
 only a start-step for process improvement.
3. Capability level 2 : Managed
 process is planned, monitored and controlled.
 managing the process by ensuring that objectives are achieved.
 objectives are both model and other including cost, quality,
schedule.
 actively managing processing with the help of metrics.
4. Capability level 3 : Defined
 a defined process is managed and meets the organization’s set of
guidelines and standards.
 focus is process standardization.
5. Capability level 4 : Quantitatively Managed
 process is controlled using statistical and quantitative techniques.
 process performance and quality is understood in statistical terms
and metrics.
 quantitative objectives for process quality and performance are
established.
6. Capability level 5 : Optimizing
 focuses on continually improving process performance.
 performance is improved in both ways – incremental and
innovation.
 emphasizes on studying the performance results across the
organization to ensure that common causes or issues are identified and
fixed.

Process Patterns in Software Engineering

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.

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.

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 :
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.
Initial Context :
Conditions under which the pattern applies are described by initial context. Prior
to the initiation of the pattern :
1. What organizational or term-related activities have already occurred?
2. Entry state for the process?
3. Software engineering information or project information already exists?
For example, the Planning pattern requires that :
 Collaborative communication has been established between customers
and software engineers.
 Successful completion of a number of task patterns for the
communication pattern has occurred.
 The project constraints, basic requirements, and the project scope are
known.
Problem :
Any specific problem is to be solved by pattern.
Solution –
Describes how to implement pattern successfully. This section describes how
initial state of process is modified as a consequence of initiation of pattern.
Resulting Context :
Once the pattern has been successfully implemented, it describes conditions.
Upon completion of pattern :
1. Organizational or term-related activities must have occurred?
2. What should be the exit state for the process?
3. What software engineering information has been developed?
Related pattern :
Provide a list of all process patterns that are directly related to this one. It can
be represented n a hierarchy or in some other diagrammatic form.
Known uses and Examples –
In which the pattern is applicable, it indicates the specific instances. For
example, communication is mandatory at the beginning of every software
project, is recommended throughout the software project, and is mandatory
once the deployment activity is underway.

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.

Models “Personal Software Process (PSP)” and “Team Software Process

(TSP).” Both require hard work, training, and coordination, but bot

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.
 Postmortem. Using the measures and metrics collected, the effectiveness of
the process is determined. Measures and metrics should provide guidance for
modifying the process to improve its effectiveness.

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)

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.

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

TSP defines the following framework activities:

project launch,

high level design,

implementation,

personal and team process model,

integration and test, and

postmortem.

Waterfall model
Winston Royce introduced the Waterfall Model in 1970.This model has five phases:
Requirements analysis and specification, design, implementation, and unit testing,
integration and system testing, and operation and maintenance. The steps always follow
in this order and do not overlap. The developer must complete every phase before the
next phase begins. This model is named "Waterfall Model", because its diagrammatic
representation resembles a cascade of waterfalls.

. Requirements analysis and specification phase: The aim of this phase is to understand the
exact requirements of the customer and to document them properly. Both the customer and the
software developer work together so as to document all the functions, performance, and
interfacing requirement of the software. It describes the "what" of the system to be produced
and not "how."In this phase, a large document called Software Requirement Specification
(SRS) document is created which contained a detailed description of what the system will do in
the common language.

Design Phase: This phase aims to transform the requirements gathered in the SRS into
a suitable form which permits further coding in a programming language. It defines the
overall software architecture together with high level and detailed design. All this work
is documented as a Software Design Document (SDD).

3. Implementation and unit testing: During this phase, design is implemented. If the
SDD is complete, the implementation or coding phase proceeds smoothly, because all
the information needed by software developers is contained in the SDD.

4. Integration and System Testing: This phase is highly crucial as the quality of the
end product is determined by the effectiveness of the testing carried out. The better
output will lead to satisfied customers, lower maintenance costs, and accurate results.
Unit testing determines the efficiency of individual modules. However, in this phase, the
modules are tested for their interactions with each other and with the system.

5. Operation and maintenance phase: Maintenance is the task performed by every

user once the software has been delivered to the customer, installed, and operational.

Evolutionary Process Models

 Evolutionary models are iterative type models.
 They allow to develop more complete versions of the software .

Following are the evolutionary process models.

1. The prototyping model

2. The spiral model
3. Concurrent development model

1. The Prototyping model

 Prototype is defined as first or preliminary form using which other forms

are copied or derived.
 Prototype model is a set of general objectives for software.
 It does not identify the requirements like detailed input, output.
 It is software working model of limited functionality.
 In this model, working programs are quickly produced.

The different phases of Prototyping model are:

1. Communication
In this phase, developer and customer meet and discuss the overall objectives
of the software.
 2. Quick design
 Quick design is implemented when requirements are known.
 It includes only the important aspects like input and output format of the
software.
 It focuses on those aspects which are visible to the user rather than the
detailed plan.
 It helps to construct a prototype.
3. Modeling quick design
 This phase gives the clear idea about the development of software
because the software is now built.
 It allows the developer to better understand the exact requirements.
4. Construction of prototype
The prototype is evaluated by the customer itself.

5. Deployment, delivery, feedback

 If the user is not satisfied with current prototype then it refines according
to the requirements of the user.
 The process of refining the prototype is repeated until all
the requirements of users are met.
 When the users are satisfied with the developed prototype then the
system is developed on the basis of final prototype.
Advantages of Prototyping Model
 Prototype model need not know the detailed input, output, processes,
adaptability of operating system and full machine interaction.
 In the development process of this model users are actively involved.
 The development process is the best platform to understand the system
by the user.
 Errors are detected much earlier.
 Gives quick user feedback for better solutions.
 It identifies the missing functionality easily. It also identifies the
confusing or difficult functions.
Disadvantages of Prototyping Model:
 The client involvement is more and it is not always considered by the
developer.
 It is a slow process because it takes more time for development.
 Many changes can disturb the rhythm of the development team.
 It is a thrown away prototype when the users are confused with it.

2. The Spiral model

 Spiral model is a risk driven process model.

 It is used for generating the software projects.
 In spiral model, an alternate solution is provided if the risk is found in the
risk analysis, then alternate solutions are suggested and implemented.
 It is a combination of prototype and sequential model or waterfall model.
 In one iteration all activities are done, for large project's the output is
small.

The framework activities of the spiral model are as shown in the

following figure.

NOTE: The description of the phases of the spiral model is same as that of the
process model.

Advantages of Spiral Model

 It reduces high amount of risk.
 It is good for large and critical projects.
 It gives strong approval and documentation control.
 In spiral model, the software is produced early in the life cycle process.

Disadvantages of Spiral Model

 It can be costly to develop a software model.
 It is not used for small projects.

3. The concurrent development model

 The concurrent development model is called as concurrent model.

 The communication activity has completed in the first iteration and exits
in the awaiting changes state.
 The modeling activity completed its initial communication and then go to
the underdevelopment state.
 If the customer specifies the change in the requirement, then the
modeling activity moves from the under development state into the awaiting
change state.
 The concurrent process model activities moving from one state to
another state.
 Advantages of the concurrent development model
 This model is applicable to all types of software development processes.
 It is easy for understanding and use.
 It gives immediate feedback from testing.
 It provides an accurate picture of the current state of a project.

Disadvantages of the concurrent development model

 It needs better communication between the team members. This may not
be achieved all the time.
 It requires to remember the status of the different activities.

The Unified Process in Software Engineering

May 6, 2021
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
 Elaboration
  Conception
 Transition
 Production

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.

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.

Elaboration creates an “executable architectural baseline” that represents a “first cut”

executable system.

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.

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