SOFTWARE ENGINEERING NOTES MS J SUMEDHA ASST PROF

UNIT-1

Introduction to software engineering

Software is a program or set of programs containing instructions that

provide desired functionality. Engineering is the process of designing and
building something that serves a particular purpose and finds a cost-effective
solution to problems.
What is Software Engineering?
Software Engineering 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.
1. Software engineering includes a variety of techniques, tools, and
methodologies, including requirements analysis, design, testing, and
maintenance.
2. It is a rapidly evolving field, and new tools and technologies are constantly
being developed to improve the software development process.
3. By following the principles of software engineering and using the appropriate
tools and methodologies, software developers can create high-quality, reliable,
and maintainable software that meets the needs of its users.
4. Software Engineering is mainly used for large projects based on software
systems rather than single programs or applications.
5. The main goal of Software Engineering is to develop software applications for
improving quality, budget, and time efficiency.
6. Software Engineering ensures that the software that has to be built should be
consistent, correct, also on budget, on time, and within the required
requirements.
Software Development Life Cycle (SDLC):

Software development life cycle (SDLC) is a structured process that is used

to design, develop, and test good-quality software. SDLC, or software
development life cycle, is a methodology that defines the entire procedure of
software development step-by-step.
SOFTWARE ENGINEERING NOTES MS J SUMEDHA ASST PROF

SOFTWARE DEVELOPMENT LIFE CYCLE

The goal of the SDLC life cycle model is to deliver high-quality, maintainable
software that meets the user’s requirements. SDLC in software engineering
models outlines the plan for each stage so that each stage of the software
development model can perform its task efficiently to deliver the software at a
low cost within a given time frame that meets users’ requirements.

What is Software Development Life Cycle (SDLC)?

SDLC is a process followed for software building within a software
organization. SDLC consists of a precise plan that describes how to develop,
maintain, replace, and enhance specific software. The life cycle defines a method
for improving the quality of software and the all-around development process.
Stages of the Software Development Life Cycle
SDLC specifies the task(s) to be performed at various stages by a software
engineer or developer. It ensures that the end product is able to meet the
customer’s expectations and fits within the overall budget. Hence, it’s vital for a
software developer to have prior knowledge of this software development
process.
SOFTWARE ENGINEERING NOTES MS J SUMEDHA ASST PROF

The SDLC model involves six phases or stages while developing any software.
SDLC is a collection of these six stages, and the stages of SDLC are as follows:
Stage-1: Planning and Requirement Analysis
Planning is a crucial step in everything, just as in software development. In this
same stage, requirement analysis is also performed by the developers of the
organization. This is attained from customer inputs, and sales department/market
surveys.
The information from this analysis forms the building blocks of a basic project.
The quality of the project is a result of planning. Thus, in this stage, the basic
project is designed with all the available information.
SOFTWARE ENGINEERING NOTES MS J SUMEDHA ASST PROF

Stage-2: Defining Requirements

In this stage, all the requirements for the target software are specified. These
requirements get approval from customers, market analysts, and stakeholders.
This is fulfilled by utilizing SRS (Software Requirement Specification). This is a
sort of document that specifies all those things that need to be defined and created
during the entire project cycle.

Stage-3: Designing Architecture

SRS is a reference for software designers to come up with the best architecture
for the software. Hence, with the requirements defined in SRS, multiple designs
for the product architecture are present in the Design Document Specification
(DDS).
This DDS is assessed by market analysts and stakeholders. After evaluating all
the possible factors, the most practical and logical design is chosen for
development.
SOFTWARE ENGINEERING NOTES MS J SUMEDHA ASST PROF

Stage-4: Developing Product

At this stage, the fundamental development of the product starts. For this,
developers use a specific programming code as per the design in the DDS. Hence,
it is important for the coders to follow the protocols set by the association.
Conventional programming tools like compilers, interpreters, debuggers, etc. are
also put into use at this stage. Some popular languages like C/C++, Python, Java,
etc. are put into use as per the software regulations.

Stage-5: Product Testing and Integration

SOFTWARE ENGINEERING NOTES MS J SUMEDHA ASST PROF

After the development of the product, testing of the software is necessary to

ensure its smooth execution. Although, minimal testing is conducted at every
stage of SDLC. Therefore, at this stage, all the probable flaws are tracked, fixed,
and retested. This ensures that the product confronts the quality requirements of
SRS.
Documentation, Training, and Support: Software documentation is an
essential part of the software development life cycle. A well-written document
acts as a tool and means to information repository necessary to know about
software processes, functions, and maintenance. Documentation also provides
information about how to use the product. Training in an attempt to improve the
current or future employee performance by increasing an employee’s ability to
work through learning, usually by changing his attitude and developing his skills
and understanding.

Stage 6: Deployment and Maintenance of Products

After detailed testing, the conclusive product is released in phases as per the
organization’s strategy. Then it is tested in a real industrial environment. It is
important to ensure its smooth performance. If it performs well, the organization
sends out the product as a whole. After retrieving beneficial feedback, the
company releases it as it is or with auxiliary improvements to make it further
helpful for the customers. However, this alone is not enough. Therefore, along
with the deployment the product’s supervision.
SOFTWARE ENGINEERING NOTES MS J SUMEDHA ASST PROF

Software Development Life Cycle Models

To this day, we have more than 50 recognized SDLC models in use. But None of
them is perfect, and each brings its favorable aspects and disadvantages for a
specific software development project or a team.
1. Waterfall Model
It is the fundamental model of the software development life cycle. This is a very
simple model. The waterfall model is not in practice anymore, but it is the basis
for all other SDLC models. Because of its simple structure, the waterfall model is
easier to use and provides a tangible output. In the waterfall model, once a phase
seems to be completed, it cannot be changed, and due to this less flexible nature,
the waterfall model is not in practice anymore.
2. Agile Model
The agile model was mainly designed to adapt to changing requests quickly. The
main goal of the Agile model is to facilitate quick project completion. The agile
model refers to a group of development processes. These processes have some
similar characteristics but also possess certain subtle differences among
themselves.
Iterative Model
In the iterative model, each cycle results in a semi-developed but deployable
version; with each cycle, some requirements are added to the software, and the
final cycle results in the software with the complete requirement specification.
4. Spiral Model
The spiral model is one of the most crucial SDLC models that provides support
for risk handling. It has various spirals in its diagrammatic representation; the
SOFTWARE ENGINEERING NOTES MS J SUMEDHA ASST PROF

number of spirals depends upon the type of project. Each loop in the spiral
structure indicates the Phases of the Spiral model.
5. V-Shaped Model
The V-shaped model is executed in a sequential manner in V-shape. Each stage
or phase of this model is integrated with a testing phase. After every development
phase, a testing phase is associated with it, and the next phase will start once the
previous phase is completed, i.e., development & testing. It is also known as the
verification or validation model.
6. Big Bang Model
The Big Bang model in SDLC is a term used to describe an informal and
unstructured approach to software development, where there is no specific
planning, documentation, or well-defined phases.
What is the need for SDLC?
SDLC is a method, approach, or process that is followed by a software
development organization while developing any software. SDLC models were
introduced to follow a disciplined and systematic method while designing
software. With the software development life cycle, the process of software
design is divided into small parts, which makes the problem more understandable
and easier to solve. SDLC comprises a detailed description or step-by-step plan
for designing, developing, testing, and maintaining the software.
DEFINATION OF SOFTWARE ENGINEERING:
Software is: (1) instructions (computer programs) that when executed provide
desired features, function, and performance; (2) data structures that enable the
programs to adequately manipulate information, and (3) descriptive information in
both hard copy and virtual forms that describes the operation and use of the
programs.
SOFTWARE ENGINEERING:

In order to build software that is ready to meet the challenges of the twenty-first
century, you must recognize a few simple realities: • Software has become deeply
embedded in virtually every aspect of our lives, and as a consequence, the number
of people who have an interest in the features and functions provided by a specific
application8 has grown dramatically. When a new application or embedded system
is to be built, many voices must be heard. And it sometimes seems that each of
them has a slightly different idea of what software features and functions should be
delivered. It follows that a concerted effort should be made to understand the
problem before a software solution is developed. • The information technology
requirements demanded by individuals, businesses, and governments grow
increasing complex with each passing year. Large teams of people now create
SOFTWARE ENGINEERING NOTES MS J SUMEDHA ASST PROF

computer programs that were once built by a single individual. Sophisticated

software that was once implemented in a predictable, self-contained, computing
environment is now embedded inside everything from consumer electronics to
medical devices to weapons systems. The complexity of these new computer-based
systems and products demands careful attention to the interactions of all system
elements. It follows that design becomes a pivotal activity. • Individuals,
businesses, and governments increasingly rely on software for strategic and tactical
decision making as well as day-to-day operations and control. If the software fails,
people and major enterprises can experience anything from minor inconvenience to
catastrophic failures. It follows that software should exhibit high quality. • As the
perceived value of a specific application grows, the likelihood is that its user base
and longevity will also grow. As its user base and time-in-use.
Software engineering is a layered technology. Referring to Figure 1.3, any
engineering approach (including software engineering) must rest on an
organizational commitment to quality. Total quality management, Six Sigma, and
similar philosophies10 foster a continuous process improvement culture, and it is
this culture that ultimately leads to the development of increasingly more effective
approaches to software engineering. The bedrock that supports software
engineering is a quality focus. The foundation for software engineering is the
process layer. The software engineering process is the glue that holds the
technology layers together and enables rational and timely development of
computer software. Process defines a framework
that must be established for effective delivery of software engineering technology.
The software process forms the basis for management control of software projects
and establishes the context in which technical methods are applied, work products
(models, documents, data, reports, forms, etc.) are produced, milestones are
established, quality is ensured, and change is properly managed. Software
engineering methods provide the technical how-to’s for building software.
Methods encompass a broad array of tasks that include communication,
requirements analysis, design modeling, program construction, testing, and
support. Software engineering methods rely on a set of basic principles that govern
each area of the technology and include modeling activities and other descriptive
techniques. Software engineering tools provide automated or semi automated
support for the process and the methods. When tools are integrated so that
information created by one tool can be used by another, a system for the support of
software development, called computer-aided software engineering, is established.
A GENERIC VIEW OF PROCESS:

Software Process Framework is an abstraction of the software development

process.
SOFTWARE ENGINEERING NOTES MS J SUMEDHA ASST PROF

What is a Software Process Framework?

Software Process Framework details the steps and chronological order of a
process. Since it serves as a foundation for them, it is utilized in most
applications. Task sets, umbrella activities, and process framework activities all
define the characteristics of the software development process. Software Process
includes:
1. Tasks: They focus on a small, specific objective.
2. Action: It is a set of tasks that produce a major work product.
3. Activities: Activities are groups of related tasks and actions for a major
objective.

Process Framework Activities

The process framework is required for representing common process activities.
Five framework activities are described in a process framework for software
SOFTWARE ENGINEERING NOTES MS J SUMEDHA ASST PROF

engineering. Communication, planning, modeling, construction, and deployment

are all examples of framework activities. Each engineering action defined by a
framework activity comprises a list of needed work outputs, project milestones,
and software quality assurance (SQA) points.
1. Communication
By communication, customer requirement gathering is done. Communication
with consumers and stakeholders to determine the system’s objectives and the
software’s requirements.
3. Modeling
Architectural models and design to better understand the problem and to work
towards the best solution. The software model is prepared by:
 Analysis of requirements
 Design
4. Construction
Creating code, testing the system, fixing bugs, and confirming that all criteria are
met. The software design is mapped into a code by:
 Code generation
 Testing
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 the supply of better products.
Umbrella Activities
Umbrella Activities are that take place during a software development process for
improved project management and tracking.
1. Software project tracking and control: This is an activity in which the team
can assess progress and take corrective action to maintain the schedule. Take
action to keep the project on time by comparing the project’s progress against
the plan.
2. Risk management: The risks that may affect project outcomes or quality can
be analyzed. Analyze potential risks that may have an impact on the software
product’s quality and outcome.
3. Software quality assurance: These are activities required to maintain
software quality. Perform actions to ensure the product’s quality.
4. Formal technical reviews: It is required to assess engineering work products
to uncover and remove errors before they propagate to the next activity. At
each level of the process, errors are evaluated and fixed.
5. Software configuration management: Managing of configuration process
when any change in the software occurs.
SOFTWARE ENGINEERING NOTES MS J SUMEDHA ASST PROF

6. Work product preparation and production: The activities to create models,

documents, logs, forms, and lists are carried out.
7. Reusability management: It defines criteria for work product reuse. Reusable
work items should be backed up, and reusable software components should be
achieved.
8. Measurement: In this activity, the process can be defined and collected. Also,
project and product measures are used to assist the software team in delivering
the required software.

PROCESS PATTERNS:

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.
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.
SOFTWARE ENGINEERING NOTES MS J SUMEDHA ASST PROF

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

Let’s see an example of a process pattern to understand it more clearly.

Template:
Pattern Name: Prototyping Model Design
Intent: Requirements are not clear. So aim is to make an model iteratively to
solidify the exact requirements.
Type: Phase Pattern
Initial Context: Before going to the prototyping these basic conditions should be
made
1. Stakeholder has some idea about their requirements i.e. what they exactly
want
2. Communication medium should be established between stakeholder and
software development team to ensure proper understanding about the
requirements and future product
3. Initial understanding about other factors of project like scope of project,
duration of project, budget of project etc.
Problem: Identifying and Solidifying the hazy and nonexistent requirements.
Solution: A description of the prototyping should be presented.
Resulting Context: A prototype model which can give a clear idea about the
actual product and that needs to be agreed by stakeholder.
CAPABILITY MATURITY MODEL:

Capability Maturity Model (CMM) was developed by the Software

Engineering Institute (SEI) at Carnegie Mellon University in 1987. It is not a
software process model. It is a framework that is used to analyze the approach
and techniques followed by any organization to develop software products. It also
provides guidelines to further enhance the maturity of the process used to develop
those software products.
It is based on profound feedback and development practices adopted by the most
successful organizations worldwide. This model describes a strategy for software
SOFTWARE ENGINEERING NOTES MS J SUMEDHA ASST PROF

process improvement that should be followed by moving through 5 different

levels. Each level of maturity shows a process capability level. All the levels
except level 1 are further described by Key Process Areas (KPA).
Principles of Capability Maturity Model (CMM)
 People’s capability is a competitive issue. Competition arises when different
organizations are performing the same task (such as software development). In
such a case, the people of an organization are sources of strategy and skills,
which in turn results in better performance of the organization.
 The people’s capability should be defined in relation to the business objectives
of the organization.
 An organization should invest in improving the capabilities and skills of the
people as they are important for its success.
 The management should be responsible for enhancing the capability of the
people in the organization.
 The improvement in the capability of people should be done as a process. This
process should incorporate appropriate practices and procedures.
 The organization should be responsible for providing improvement
opportunities so that people in the organization can take advantage of them.
 Since new technologies and organizational practices emerge rapidly,
organizations should continually improve their practices and develop the
abilities of people.
Shortcomings of the Capability Maturity Model (CMM)
 It encourages the achievement of a higher maturity level in some cases by
displacing the true mission, which is improving the process and overall
software quality.
 It only helps if it is put into place early in the software development process.
 It has no formal theoretical basis and in fact, is based on the experience of
very knowledgeable people.
 It does not have good empirical support and this same empirical support could
also be constructed to support other models.
 Difficulty in measuring process improvement: The SEI/CMM model may not
provide an accurate measure of process improvement, as it relies on self-
assessment by the organization and may not capture all aspects of the
development process.
 Focus on documentation rather than outcomes: The SEI/CMM model may
focus too much on documentation and adherence to procedures, rather than on
actual outcomes such as software quality and customer satisfaction.
 May not be suitable for all types of organizations: The SEI/CMM model may
not be suitable for all kinds of organizations, particularly those with smaller
development teams or those with less structured development processes.
SOFTWARE ENGINEERING NOTES MS J SUMEDHA ASST PROF

 May not keep up with rapidly evolving technologies: The SEI/CMM model
may not be able to keep up with rapidly evolving technologies and
development methodologies, which could limit its usefulness in certain
contexts.
 Lack of agility: The SEI/CMM model may not be agile enough to respond
quickly to changing business needs or customer requirements, which could
limit its usefulness in dynamic and rapidly changing environments.
Key Process Areas (KPA)
Each of these KPA (Key Process Areas) defines the basic requirements that
should be met by a software process in order to satisfy the KPA and achieve that
level of maturity.
Conceptually, key process areas form the basis for management control of the
software project and establish a context in which technical methods are applied,
work products like models, documents, data, reports, etc. are produced,
milestones are established, quality is ensured and change is properly managed.

Level-1: Initial
 No KPIs defined.
SOFTWARE ENGINEERING NOTES MS J SUMEDHA ASST PROF

 Processes followed are Adhoc and immature and are not well defined.
 Unstable environment for software development.
 No basis for predicting product quality, time for completion, etc.
 Limited project management capabilities, such as no systematic tracking of
schedules, budgets, or progress.
 We have limited communication and coordination among team members and
stakeholders.
 No formal training or orientation for new team members.
 Little or no use of software development tools or automation.
 Highly dependent on individual skills and knowledge rather than standardized
processes.
 High risk of project failure or delays due to a lack of process control and
stability.
Level-2: Repeatable
 Focuses on establishing basic project management policies.
 Experience with earlier projects is used for managing new similar-natured
projects.
 Project Planning- It includes defining resources required, goals, constraints,
etc. for the project. It presents a detailed plan to be followed systematically for
the successful completion of good-quality software.
 Configuration Management- The focus is on maintaining the performance of
the software product, including all its components, for the entire lifecycle.
 Requirements Management- It includes the management of customer
reviews and feedback which result in some changes in the requirement set. It
also consists of accommodation of those modified requirements.
 Subcontract Management- It focuses on the effective management of
qualified software contractors i.e. it manages the parts of the software
developed by third parties.
 Software Quality Assurance- It guarantees a good quality software product
by following certain rules and quality standard guidelines while developing.
Level-3: Defined
 At this level, documentation of the standard guidelines and procedures takes
place.
 It is a well-defined integrated set of project-specific software engineering and
management processes.
 Peer Reviews: In this method, defects are removed by using a number of
review methods like walkthroughs, inspections, buddy checks, etc.
SOFTWARE ENGINEERING NOTES MS J SUMEDHA ASST PROF

 Intergroup Coordination: It consists of planned interactions between

different development teams to ensure efficient and proper fulfillment of
customer needs.
 Organization Process Definition: Its key focus is on the development and
maintenance of standard development processes.
 Organization Process Focus: It includes activities and practices that should
be followed to improve the process capabilities of an organization.
 Training Programs: It focuses on the enhancement of knowledge and skills
of the team members including the developers and ensuring an increase in
work efficiency.
Level-4: Managed
 At this stage, quantitative quality goals are set for the organization for
software products as well as software processes.
 The measurements made help the organization to predict the product and
process quality within some limits defined quantitatively.
 Software Quality Management: It includes the establishment of plans and
strategies to develop quantitative analysis and understanding of the product’s
quality.
 Quantitative Management: It focuses on controlling the project performance
in a quantitative manner.
Level-5: Optimizing
 This is the highest level of process maturity in CMM and focuses on
continuous process improvement in the organization using quantitative
feedback.
 The use of new tools, techniques, and evaluation of software processes is done
to prevent the recurrence of known defects.
 Process Change Management: Its focus is on the continuous improvement of
the organization’s software processes to improve productivity, quality, and
cycle time for the software product.
 Technology Change Management: It consists of the identification and use of
new technologies to improve product quality and decrease product
development time.
 Defect Prevention It focuses on the identification of causes of defects and
prevents them from recurring in future projects by improving project-defined
processes.
 CMM (Capability Maturity Model) vs CMMI (Capability Maturity
Model Integration)
SOFTWARE ENGINEERING NOTES MS J SUMEDHA ASST PROF

Capability Maturity
Capability Maturity Model Integration
Aspects Model (CMM) (CMMI)

Expands to various
Primarily focused on
disciplines like systems
Scope software engineering
engineering, hardware
processes.
development, etc.

Initially had a staged

Had a five-level
representation;
Maturity Levels maturity model (Level 1
introduced continuous
to Level 5).
representation later.

More rigid structure Offers flexibility to

Flexibility with predefined tailor process areas to
practices. organizational needs.

Gained popularity in Gained wider adoption

Adoption and
software development across industries due to
Popularity
industry. broader applicability.

Capability Maturity
Capability Maturity Model Integration
Aspects Model (CMM) (CMMI)

Expands to various
Primarily focused on
disciplines like systems
Scope software engineering
engineering, hardware
processes.
development, etc.

Initially had a staged

Had a five-level
representation;
Maturity Levels maturity model (Level 1
introduced continuous
to Level 5).
representation later.
SOFTWARE ENGINEERING NOTES MS J SUMEDHA ASST PROF

Capability Maturity
Capability Maturity Model Integration
Aspects Model (CMM) (CMMI)

More rigid structure Offers flexibility to

Flexibility with predefined tailor process areas to
practices. organizational needs.

Gained popularity in Gained wider adoption

Adoption and
software development across industries due to
Popularity
industry. broader applicability.

Capability Maturity
Capability Maturity Model Integration
Aspects Model (CMM) (CMMI)

Expands to various
Primarily focused on
disciplines like systems
Scope software engineering
engineering, hardware
processes.
development, etc.

Initially had a staged

Had a five-level
representation;
Maturity Levels maturity model (Level 1
introduced continuous
to Level 5).
representation later.

More rigid structure Offers flexibility to

Flexibility with predefined tailor process areas to
practices. organizational needs.

Gained popularity in Gained wider adoption

Adoption and
software development across industries due to
Popularity
industry. broader applicability.
 Levels of CMMI
 There are basically 5 performance levels of the CMMI Model.
 Level 1: Initial: Processes are often ad hoc and unpredictable. There is
little or no formal process in place.
SOFTWARE ENGINEERING NOTES MS J SUMEDHA ASST PROF

 Level 2: Managed: Basic project management processes are established.

Projects are planned, monitored, and controlled.
 Level 3: Defined: Organizational processes are well-defined and
documented. Standardized processes are used across the organization.
 Level 4: Quantitatively Managed: Processes are measured and controlled
using statistical and quantitative techniques. Process performance is
quantitatively understood and managed.
 Level 5: Optimizing: Continuous process improvement is a key focus.
Processes are continuously improved based on quantitative feedback.

PROCESS PATTERNS:

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:
SOFTWARE ENGINEERING NOTES MS J SUMEDHA ASST PROF

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

Example of Process Pattern:

Let’s see an example of a process pattern to understand it more clearly.

Template:
Pattern Name: Prototyping Model Design
Intent: Requirements are not clear. So aim is to make an model iteratively to
solidify the exact requirements.
Type: Phase Pattern
Initial Context: Before going to the prototyping these basic conditions should be
made
1. Stakeholder has some idea about their requirements i.e. what they exactly
want
SOFTWARE ENGINEERING NOTES MS J SUMEDHA ASST PROF

2. Communication medium should be established between stakeholder and

software development team to ensure proper understanding about the
requirements and future product
3. Initial understanding about other factors of project like scope of project,
duration of project, budget of project etc.
Problem: Identifying and Solidifying the hazy and nonexistent requirements.
Solution: A description of the prototyping should be presented.
Resulting Context: A prototype model which can give a clear idea about the
actual product and that needs to be agreed by stakeholder.
Related Patterns: Requirement extraction, Iterative design, customer
communication, Iterative development, Customer assessment etc.
Known Uses & Examples: When stakeholder requirements are unclear and
uncertain, prototyping is recommended.
Process Assessment:

The existence of a software process is no guarantee that software will be delivered

on time, that it will meet the customer’s needs, or that it will exhibit the technical
characteristics that will lead to long-term quality characteristics. Process patterns
must be coupled with solid software engineering practice . In addition, the process
itself can be assessed to ensure that it meets a set of basic process criteria that have
been shown to be essential for a successful software engineering. A number of
different approaches to software process assessment and improvement have been
proposed over the past few decades.

Standard CMMI Assessment Method for Process Improvement :(SCAMPI)—

provides a five-step process assessment model that incorporates five phases:
initiating, diagnosing, establishing, acting, and learning. The SCAMPI method
uses the SEI CMMI as the basis for assessment [SEI00].

CMM-Based Appraisal for Internal Process Improvement (CBA IPI):provides

a diagnostic technique for assessing the relative maturity of a software
organization; uses the SEI CMM as the basis for the assessment [Dun01].

SPICE (ISO/IEC15504): a standard that defines a set of requirements for software

process assessment. The intent of the standard is to assist organizations in
developing an objective evaluation of the efficacy of any defined software process
[ISO08].
 SOFTWARE ENGINEERING NOTES MS J SUMEDHA ASST PROF

ISO 9001:2000 for Software: a generic standard that applies to any organization
that wants to improve the overall quality of the products, systems, or services that
it provides. Therefore, the standard is directly applicable to software organizations
and companies.

PROCESS MODELS:

Prescriptive Models:

Prescriptive process models prescribe a set of framework and other activities,

quality assurance points, and software process-related elements. They define a
workflow among these elements that shows their inter-relationship.

The process models described here are,

 Waterfall Model.
 Incremental Process Model.
 Evolutionary Process Model.
The Waterfall Model:

The Waterfall model is also known as ‘Linear sequential model‘or ‘Classic life
cycle model‘. It is used in small projects where requirements are well defined and
known before starting the project. Activities are carried out in a linear and
systematic fashion.

The Waterfall Model

The process starts with communication, where requirements are gathered from the
customer and recorded.
Then goes to the planning stage where the cost and time constraints are estimated,
a schedule is outlined and project tracking variables are defined.
Modeling is where a design based on the requirements and keeping the project
constraints in mind is created. After this, code is generated and the actual building
of the product is started in the construction phase.
 SOFTWARE ENGINEERING NOTES MS J SUMEDHA ASST PROF

Testing (unit testing, integration testing) is done after code completion in this
phase.
Deployment is the last stage where the product is delivered, customer feedback is
received and, support and maintenance for the product are provided.

Advantages of the waterfall model:

 A simple model to use and implement.

 Easily understandable workflow.
 Easy to manage since requirements are known prior to the start of the project.
 Can be applied to projects where quality is preferred over cost.
Disadvantages of the waterfall model:

 It may be difficult for the customer to provide all the specific requirements
beforehand.
 Cannot be used for complex and object-oriented projects.
 Testing and customer evaluation are done at the last stages and hence the risk is
high.
 Iteration of activities is not promoted which is unavoidable for certain projects.
 May lead to “blocking states” in which some project team members must wait for
other members of the team to complete dependent tasks.
Incremental Process Model:

The Incremental process model is also known as ‘Successive version model‘.

In the Incremental process model, a series of releases, called increments, are built
and delivered to the customer. First, a simple working system(core product), that
addresses basic requirements, is delivered. Customer feedback is recorded after
each incremental delivery. Many increments are delivered, by adding more
functions, until the required system is released. This model is used when a user
demands a model of product with limited functionality quickly.
 SOFTWARE ENGINEERING NOTES MS J SUMEDHA ASST PROF

The Incremental Process Model

Advantages of incremental process model:

 Flexible to change requirements.

 Changes can be done throughout the development stages.
 Errors are reduced since the product is tested by the customer in each phase.
 Working software available at the early stage of the process.
 Easy to test because of small iterations.
 The initial cost is lower.
Disadvantages of incremental process model:

 Requires good planning and design.

 Modules and interfaces should be well defined.
 The total cost is high.
 Demands a complete planning strategy before commencement.
 Refining requirements in each iteration may affect system architecture.
 Breaking the problem into increments needs skilful management supervising.
Evolutionary Process Models:

Evolutionary process models are opted when the requirements may tend to
change and also when the complete sophisticated product delivery cannot be done
before a given deadline, but the delivery of a limited version of it is possible.

In the incremental model, complete requirements are specified beforehand and

these requirements are refined over time for each increment. The evolutionary
 SOFTWARE ENGINEERING NOTES MS J SUMEDHA ASST PROF

model permits requirements, plans and estimates to evolve over time. Here we
discuss prototyping and the spiral model.

Prototyping Model:

In cases when the requirements are unclear and are likely to change or when the
developer is doubtful about working of an algorithm, a solution is to build a
prototype and find out what is actually needed. Hence, in this model, one or more
prototypes are made with unrefined currently known requirements before the
actual product is made.

Prototyping model

A quick design is what occurs in a prototype model. The client evaluates the
prototype and gives feedback and other requirements which are incorporated in the
next prototype. This is repeated until the prototype becomes a complete product
that is acceptable to the client. Some prototypes are built as “throwaways”, others
are “evolutionary” in nature as they evolve into the actual system.

Advantages of prototyping:

 Active involvement of the user.

 Errors are detected earlier.
 SOFTWARE ENGINEERING NOTES MS J SUMEDHA ASST PROF

 Feedback after each prototype helps in understanding the system better.

 Does not need to know detailed processes, input and output from the beginning.
Disadvantages of prototyping:

 Multiple prototypes can slow down the process.

 Frequent changes can increase complexity.
 Unsatisfied client leads to multiple throwaways.
 The customer may not be interested or satisfied after evaluating the initial
prototype.

Spiral Model:

In spiral model, the software is developed through a series of increments. The

diagram looks like a spiral with loops where each loop is a phase. Each phase is
split into four sectors/quadrant.
SOFTWARE ENGINEERING NOTES MS J SUMEDHA ASST PROF

the Spiral Model

The first circuit around the spiral might result in the development of a product
specification. The subsequent passes around the spiral might be used to develop a
prototype and then progressively more mature versions of the software.

Planning is where the objectives, alternatives and other constraints are determined.
The alternatives are considered, risks in each alternative are analysed and
prototypes are refined in the risk analysis sector. At the development quadrant
level risks are known and it proceeds with developing and testing the product. In
the assessment sector, customer evaluation of product developed is reviewed and
 SOFTWARE ENGINEERING NOTES MS J SUMEDHA ASST PROF

the next phase is planned. This loop continues until acceptable software is built and
deployed.

Hence, the spiral model follows an incremental process methodology and unlike
other process models, it deals with the uncertainty by applying a series of risk
analysis strategies throughout the process.

Advantages of spiral model:

 Reduces risk.
 Recommended for complex projects.
 Changes can be incorporated at a later stage.
 Strong documentation helps in better management.
Disadvantages of spiral model:

 Costly and not recommended for small projects.

 Demands risk assessment expertise.
 Looping is a complex process.
 Heavy documentation.
SPECIALIZED PROCESS MODELES:
1) Component-Based Development (CBD)

The component Based Development Model has the characteristics of a spiral

model, hence is evolutionary and iterative in nature. In this model, applications are
built from pre-packaged software components that are available from different
vendors. Components are modular products with well-defined functions that can be
incorporated into the project of selection.

The modeling and construction stages are begun with identifying candidate
components suitable for the project.

Steps involved in this approach are implemented in an evolutionary fashion:

1. Components suitable for the application domain are selected.

2. Component integration issues are catered to.
3. Software architecture is designed based on the selected components.
4. Components are integrated into the architecture.
5. Testing of the functionality of components is done.
Software can be re-used in this manner, cost and time is reduced.
SOFTWARE ENGINEERING NOTES MS J SUMEDHA ASST PROF

2) Formal Methods Model(FMM)

In the Formal Methods Model, mathematical methods are applied in the process of
developing software. It Uses Formal Specification Language (FSL) to define each
system characteristics. FSL defines the syntax, notations for representing system
specifications, several objects and relations to define the system in detail.

The careful mathematical analysis that is done in FMM results in a defect-free

system. It also helps to identify and correct ambiguity and inconsistency easily.
This method is time-consuming and expensive in nature. Also, knowledge of
formal methods is necessary for developers and is a challenge.

Aspect-Oriented Software Development:

Regardless of the software process that is chosen, the builders of complex software
invariably implement a set of localized features, functions, and information
content. These localized software characteristics are modeled as components (e.g.,
object-oriented classes) and then constructed within the context of a system
architecture. As modern computer-based systems become more sophisticated (and
complex), certain concerns—customer required properties or areas of technical
interest—span the entire architecture. Some concerns are high-level properties of a
system (e.g., security, fault tolerance). Other concerns affect functions (e.g., the
application of business rules), while others are systemic (e.g., task synchronization
or memory management). When concerns cut across multiple system functions,
features, and information, they are often referred to as crosscutting concerns.
Aspectual requirements define those crosscutting concerns that have an impact
across the software architecture. Aspect-oriented software development (AOSD),
often referred to as aspect-oriented programming (AOP), is a relatively new
software engineering paradigm that provides a process and methodological
approach for defining, specifying, designing, and constructing aspects—
“mechanisms beyond subroutines and inheritance for localizing the expression of a
crosscutting concern” . Grundy provides further discussion of aspects in the
context of what he calls aspect-oriented component engineering (AOCE): AOCE
uses a concept of horizontal slices through vertically-decomposed software
components, called “aspects,” to characterize cross-cutting functional and non-
functional properties of components. Common, systemic aspects include user
interfaces, collaborative work, distribution, persistency, memory management,
transaction processing, security, integrity and so on. Components may provide or
require one or more “aspect details” relating to a particular aspect, such as a
SOFTWARE ENGINEERING NOTES MS J SUMEDHA ASST PROF

viewing mechanism, extensible affordance and interface kind (user interface

aspects); event generation, transport and receiving (distribution aspects); data
store/retrieve and indexing (persistency aspects); authentication, encoding and
access rights (security aspects); transaction atomicity, concurrency control and
logging strategy (transaction aspects); and so on. Each aspect detail has a number
of properties, relating to functional and/or non-functional characteristics of the
aspect detail. A distinct aspect-oriented process has not yet matured. However, it is
likely that such a process will adopt characteristics of both evolutionary and
concurrent process models. The evolutionary model is appropriate as aspects are
identified and then constructed. The parallel nature of concurrent development is
essential because aspects are engineered independently of localized software
components and yet, aspects have a direct impact on these components. Hence, it is
essential to 52 PART ONE THE SOFTWARE PROCESS WebRef A wide array of
resources and information on AOP can be found at: aosd.net. AOSD defines
“aspects” that express customer concerns that cut across multiple system functions,
features, and information. Instantiate asynchronous communication between the
software process activities applied to the engineering and construction of aspects
and components. A detailed discussion of aspect-oriented software development is
best left to books dedicated to the subject.
THE UNIFIED MODELS:
The unified software development process or unified process is an iterative and
incremental software development process framework. The best-known and
extensively documented refinement of the unified process is the rational unified
process (RUP). Other examples are Open UP and agile unified process.

The unified process is not simply a process, but rather an extensible framework
which should be customized for specific organizations or projects. The rational
unified process is, similarly, a customizable framework. As a result, it is often
impossible to say whether a refinement of the process was derived from UP or
from RUP, and so the names tend to be used interchangeably.

The unified process divides the project into four phases:

 Inception
 Elaboration (milestone)
 Construction (release)
 Transition (final production release)
Each phase will generally contain multiple iterations (named I1, E1, E2, C1, etc. in
the UP phase illustration). The exact number of iterations in each phase depends on
SOFTWARE ENGINEERING NOTES MS J SUMEDHA ASST PROF

the scale and nature of the project. The UP phase illustration here contains exactly
1, 2, 4 and 2 iterations in the four phases, but this is merely an example of how a
specific project could look.

Inception phase
Inception is the smallest phase in the project, and ideally, it should be quite short.
If the inception phase is long then it may be an indication of excessive up-front
specification, which is contrary to the spirit of the unified process.

Develop an approximate vision of the system, make the business case, define the
scope, and produce a rough cost estimate and project schedule.

Elaboration phase
During the elaboration phase, the project team is expected to capture a healthy
majority of the system requirements. However, the primary goals of Elaboration
are to address known risk factors and to establish and validate the system
architecture. Common processes undertaken in this phase include the creation
of use case diagrams, conceptual diagrams (class diagrams with only basic
notation) and package diagrams (architectural diagrams).

The architecture is validated primarily through the implementation of an

executable architecture baseline. This is a partial implementation of the system
which includes the core most architecturally significant components. It is built in a
series of small time-boxed iterations. By the end of the elaboration phase, the
system architecture must have stabilized and the executable architecture baseline
must demonstrate that the architecture will support the key system functionality
and exhibit the right behavior in terms of performance, scalability, and cost.

The final elaboration phase deliverable is a plan (including cost and schedule
estimates) for the construction phase. At this point the plan should be accurate and
credible since it should be based on the elaboration phase experience and since
significant risk factors should have been addressed during the elaboration phase.

Construction phase
Construction is the largest phase of the project. In this phase, the remainder of the
system is built on the foundation laid in elaboration. System features are
implemented in a series of short, time-boxed iterations. Each iteration results in an
executable release of the software. It is customary to write full-text use cases
during the construction phase and each one becomes the start of a new iteration.
Common Unified Modeling Language (UML) diagrams used during this phase
SOFTWARE ENGINEERING NOTES MS J SUMEDHA ASST PROF

include activity diagrams, sequence diagrams, collaboration diagrams, state

transition diagrams and interaction overview diagrams. Iterative implementation
for the lower risks and easier elements are done. The final construction phase
deliverable is software ready to be deployed in the transition phase.

Transition phase
The final project phase is transition. In this phase the system is deployed to the
target users. Feedback received from an initial release (or initial releases) may
result in further refinements to be incorporated over the course of several transition
phase iterations. The transition phase also includes system conversions and user
training.

PERSONAL and TEAM PROCESS MODELS:

The best software process is one that is close to the people who will be doing the
work. If a software process model has been developed at a corporate or
organizational level, it can be effective only if it is amenable to significant
adaptation to meet the needs of the project team that is actually doing software
engineering work. In an ideal setting, you would create a process that best fits your
needs, and at the same time, meets the broader needs of the team and the
organization. Alternatively, the team itself can create its own process, and at the
same time meet the narrower needs of individuals and the broader needs of the
organization. and argues that it is possible to create a “personal software process”
and/or a “team software process.” Both require hard work, training, and
coordination, but both are achievable.

Personal Software Process (PSP): Every developer uses some process to build
computer software. The process may be haphazard or ad hoc; may change on a
daily basis; may not be efficient, effective, or even successful; but a “process” does
exist. Suggests that in order to change an ineffective personal process, an
individual must move through four phases, each requiring training and careful
instrumentation. 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 (e.g., estimating and scheduling) 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, a defect estimates (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
SOFTWARE ENGINEERING NOTES MS J SUMEDHA ASST PROF

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 (this
is a substantial amount of data that should be analyzed statistically), 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. This is accomplished through a
rigorous assessment activity performed on all work products you produce. PSP
represents a disciplined, metrics-based approach to software engineering that may
lead to culture shock for many practitioners. However, when PSP is properly
introduced to software engineers [Hum96], the resulting improvement in software
engineering productivity and software quality are significant [Fer97]. However,
PSP has not been widely adopted throughout the industry. The reasons, sadly, have
more to do with human nature and organizational inertia than they do with the
strengths and weaknesses of the PSP approach. PSP is intellectually challenging
and demands a level of commitment (by practitioners and their managers) that is
not always possible to obtain. Training is relatively lengthy, and training costs are
high. The required level of measurement is culturally difficult for many software
people. Can PSP be used as an effective software process at a personal level? The
answer is an unequivocal “yes.” But even if PSP is not adopted in its entirely,
many of the personal process improvement concepts that it introduces are well
worth learning.

Team Software Process (TSP): Because many industry-grade software projects

are addressed by a team of practitioners, 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. 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.
SOFTWARE ENGINEERING NOTES MS J SUMEDHA ASST PROF

• 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, integration and test, and postmortem. Like their counterparts in
PSP (note that terminology is somewhat different), these activities enable the team
to plan, design, and construct software in a disciplined manner while at the same
time quantitatively measuring the process and the product. The postmortem sets
the stage for process improvements. 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 (i.e., project launch, design, implementation,
integration and system testing, postmortem) and other more detailed work
functions (e.g., development planning, requirements development, software
configuration management, and unit test) that are part of the team process. TSP
recognizes that the best software teams are self-directed.Team members set project
objectives, adapt the process to meet their needs, control the project schedule, and
through measurement and analysis of the metrics collected, work continually to
improve the team’s approach to software engineering. Like PSP, TSP is a rigorous
approach to software engineering that provides distinct and quantifiable benefits in
productivity and quality. The team must make a full commitment to the process
and must undergo thorough training to ensure that the approach is properly applied.

PROCESS TECHNOLOGY:

One or more of the process models discussed in the preceding sections must be
adapted for use by a software team. To accomplish this, process technology tools
have been developed to help software organizations analyze their current process,
organize work tasks, control and monitor progress, and manage technical quality.
Process technology tools allow a software organization to build an automated
model of the process framework, task sets, and umbrella activities discussed in the
SOFTWARE ENGINEERING NOTES MS J SUMEDHA ASST PROF

model, normally represented as a network, can then be analyzed to determine

typical workflow and examine alternative process structures that might lead to
reduced development time or cost. Once an acceptable process has been created,
other process technology tools can be used to allocate, monitor, and even control
all software engineering activities, actions, and tasks defined as part of the process
model. Each member of a software team can use such tools to develop a checklist
of work tasks to be performed, work products to be produced, and quality
assurance activities to be conducted. The process technology tool can also be used
to coordinate the use of other software engineering tools that are appropriate for a
particular work task.

PRODUCT and PROCESS:

Product:
In the context of software engineering, Product includes any software
manufactured based on the customer’s request. This can be a problem solving
software or computer based system. It can also be said that this is the result of a
project.
Process:
Process is a set of sequence steps that have to be followed to create a project. The
main purpose of a process is to improve the quality of the project. The process
serves as a template that can be used through the creation of its examples and is
used to direct the project.
The main difference between a process and a product is that the process is a set of
steps that guide the project to achieve a convenient product. while on the other
hand, the product is the result of a project that is manufactured by a wide variety
of people.
SOFTWARE ENGINEERING NOTES MS J SUMEDHA ASST PROF

Let’s see the difference between Product and Process:-

S.
No. Product Process

While the process is a set of

Product is the final production of the
1. sequence steps that have to be
project.
followed to create a project.

Whereas the process is focused

2. A product focuses on the final result. on completing each step being
developed.

In contrast, the process

In the case of products, the firm
3. consistently follows
guidelines are followed.
guidelines.

Whereas the process tends to

4. A product tends to be short-term.
be long-term.

While the purpose of the

The main goal of the product is to
5. process is to make the quality
complete the work successfully.
of the project better.

A process serves as a model

Product is created based on the needs and
6. for producing various goods in
expectations of the customers.
a similar way.

A product layout is a style of layout

When resources with similar
design in which the materials required to
processes or functions are
7. make the product are placed in a single
grouped together, it is referred
line depending on the order of
to as a process layout.
operations.

Product patents are thought to offer a

A process patent provides the
8. greater level of protection than process
inventor
patents.
SOFTWARE ENGINEERING NOTES MS J SUMEDHA ASST PROF

Introduction to Agility:
Agility has become today’s buzzword when describing a contemporary software
method. Everyone is agile. An associate agile team could be a nimble team able
to befittingly reply to changes. Modification is what software development is
extremely abundant.
 Changes within the software being engineered,
 Changes to the team members,
 Changes attributable to new technology,
 Changes of all types will have an effect on the merchandise they build or the
project that makes the merchandise.
All changes can be represented as shown in the below diagram which is
considered according to Ivar Jacobson Agility process of Software.

Support for changes ought to be inherent in everything we tend to kill software,

one thing we tend to embrace as a result of it’s the guts and soul of software.
Associate in agile teams acknowledges that software is developed by people
operating in groups the talents of those folks and their ability to collaborate are at
the core for the success of the project. In Jacobson’s read, the generality of
modification is that the primary driver for agility. Software engineers should be
fast on their feet if they’re to accommodate the speedy changes that Jacobson
describes. But agility is over an efficient response to alter.

 It encourages team structures and attitudes that create communication (among

team members, between technologists and business folks, between software
engineers and their managers) additional facile.
 It emphasizes speedy delivery of operational software Associate in emphasizes
the importance of intermediate work merchandise (not continuously a decent
thing);
 It adopts the client as a vicinity of the event team and works to eliminate the
“us and them” angle that continues to perforate several software projects;
 It acknowledges that coming up within an unsure world has its limits which a
project arrange should be versatile.
SOFTWARE ENGINEERING NOTES MS J SUMEDHA ASST PROF

Agility is applied to any software method. However, to accomplish this, it’s

essential that the method be designed during a manner that enables the project
team to adapt tasks and to contour them, conduct coming up within a good
manner that understands the fluidity of an agile development approach, eliminate
about the foremost essential work products and keeps them lean, Associate in
emphasize a progressive delivery strategy that gets operating package to the
client as apace as possible for the merchandise sort and operational atmosphere.
AGILE PROCESS:

The Agile Model is an incremental and iterative process of software development.

It defines each iteration’s number, duration, and scope in advance. Every iteration
is considered a short “frame” in the Agile process model, which mostly lasts from
two to four weeks.

Agile Model divides tasks into time boxes to provide specific functionality for the
release. Each build is incremental in terms of functionality, with the final build
containing all the attributes. The division of the entire project into small parts helps
minimize the project risk and the overall project delivery time.

What are the important Agile Model Manifestos?

Here is the essential manifesto of the Agile Model:

 Individuals and interactions are given priority over processes and tools.
 Adaptive, empowered, self-organizing team.
 Focuses on working software rather than comprehensive documentation.
 Agile Model in software engineering aims to deliver complete customer
satisfaction by rapidly delivering valuable software.
 Welcome changes in requirements, even late in the development phase.
 Daily co-operation between businesspeople and developers.
SOFTWARE ENGINEERING NOTES MS J SUMEDHA ASST PROF

 Priority is customer collaboration over contract negotiation.

 It enables you to satisfy customers through early and frequent delivery.
 A strong emphasis is placed on face-to-face communication.
 Developing working software is the primary indicator of progress.
 Promote sustainable development pace.
 A continuous focus is placed on technical excellence and sound design.
 An improvement review is conducted regularly by the team.

Phases of Agile Model

Here are the different phases of Agile:

Here are the important stages involved in the Agile Model process in the SDLC
life cycle:

 Requirements Gathering: In this Agile model phase, you must define the
requirements. The business opportunities and the time and effort required for
the project should also be discussed. By analyzing this information, you can
determine a system’s economic and technical feasibility.
 Design the Requirements: Following the feasibility study, you can work
with stakeholders to define requirements. Using the UFD diagram or high-
level UML diagram, you can determine how the new system will be
incorporated into your existing software system.
 Develop/Iteration: The real work begins at this stage after the software
development team defines and designs the requirements. Product, design,
SOFTWARE ENGINEERING NOTES MS J SUMEDHA ASST PROF

and development teams start working, and the product will undergo different
stages of improvement using simple and minimal functionality.
 Test: This phase of the Agile Model involves the testing team. For example,
the Quality Assurance team checks the system’s performance and reports
bugs during this phase.
 Deployment: In this phase, the initial product is released to the user.
 Feedback: After releasing the product, the last step of the Agile Model is
feedback. In this phase, the team receives feedback about the product and
works on correcting bugs based on the received feedback.

Compared to Waterfall, Agile cycles are short. There may be many such cycles in
a project. The phases are repeated until the product is delivered.

Types of Agile
Here are some important Agile Types:

Scrum: This agile method focuses primarily on managing tasks in team-based

development conditions. In the Scrum Agile model, the team should strictly follow
a work plan for each Sprint. Moreover, people involved in this type of project have
predefined roles.

Crystal: Using Crystal methodology is one of the most straightforward and most
flexible approaches to developing software, recognizing that each project has
unique characteristics. Therefore, policies and practices need to be tailored to suit
them.

Crystal methodologies are categorized as below:

 CLEAR: User for small and low critical efforts.

 ORANGE: User for moderately larger and critical projects.
 ORANGE WEB: Typically, electronic business

Dynamic Software Development Method (DSDM): This Rapid Application

Development (RAD) approach involves active user involvement, and the teams are
empowered to make decisions with the goal of frequent product delivery.

Feature Driven Development (FDD): This Agile method focuses on “designing

& building” features. It is divided into several short phases of work that must be
completed for each feature separately. It includes domain walkthrough, design
inspection, code inspection, etc.
SOFTWARE ENGINEERING NOTES MS J SUMEDHA ASST PROF

Lean Software Development: This methodology is based on the principle of

“Just-In-Time Production.” It helps to increase the speed of software development
and decrease costs.

As a result of a lean development model, waste is eliminated, learning is amplified,

early delivery is achieved, and integrity is built.

Extreme Programming (XP): Extreme Programming is a useful Agile model

when there are constantly changing requirements or demands from clients. It is
also used when there is no sure about the system’s functionality.

When to use the Agile Model?

Here are the common scenarios where the Agile method is used:

 It is used when there are frequent changes that need to be implemented.

 Low-regulatory-requirement projects
 Projects with not very strict existing process
 Projects where the product owner is highly accessible
 Projects with flexible timelines and budget

Advantages of the Agile Model

Here are some common pros/benefits of the Agile Model:

 Communication with clients is on a one-on-one basis.

 Provides a very realistic approach to software development
 Agile Model in software engineering enables you to draft efficient designs
and meet the company’s needs.
 Updated versions of functioning software are released every week.
 It delivers early partial working solutions.
 Changes are acceptable at any time.
 You can reduce the overall development time by utilizing this Agile Model.
 It allows concurrent development and delivery within an overall planned
context.
 The final product is developed and available for use within a few weeks.

Disadvantages of Agile Model

Here are some common cons/drawbacks of the Agile Model:
 SOFTWARE ENGINEERING NOTES MS J SUMEDHA ASST PROF

 There is a higher risk of sustainability, maintainability, and extensibility.

 In some corporations, self-organization and intensive collaboration may not
be compatible with their corporate culture.
 Documentation and design are not given much attention.
 Without clear information from the customer, the development team can be
misled.
 Not a suitable method for handling complex dependencies.

Agile Model Vs. Waterfall Model

Agile and Waterfall models are two different methods for the software
development process. Despite their differences in approach, both methodologies
can be used at times, depending upon the project and the requirements.

Agile Model Waterfall Model

Agile methodologies propose
incremental and iterative approaches to Software development flows sequentially from start point to e
software design
The Agile Model in software engineering
is broken into individual models that The design process is not broken into individual models
designers work on
The customer has early and frequent
opportunities to look at the product and The customer can only see the product at the end of the proje
make decisions and changes.
The Agile Model is considered
unstructured compared to the waterfall Waterfall models are more secure because they are plan orien
model
Small projects can be implemented very
quickly. For large projects, it isn’t easy All sorts of the project can be estimated and completed.
to estimate the development time.
Test plan is reviewed after each Sprint The test plan is hardly discussed during the test phase.