Chapter 1

INTRODUCTION TO SOFTWARE ENGINEERING

Structure
1.1 Learning Objectives
1.2 Introduction
1.3 The Software Process
1.3.1 The Process Framework
1.3.2 Umbrella Activities
1.4 A Generic Process Model
1.5 Defining a Framework Activity
1.6 Prescriptive Process Models
1.6.1 The Waterfall Model
1.6.2 Incremental Process Models
1.6.3 Evolutionary Process Models
1.7 What is agility?
1.8 What is an Agile Process?
1.8.1 Agility Principles
1.9 Scrum
1.10 Summary
1.11 Glossary
1.12 In-text Questions Answers
1.13 Self-assessment Questions
1.14 References
1.15 Suggested Readings

1.1 Learning Objectives

You will learn the following in this chapter -
● What is Software engineering?
● About Software processes and activities
● Various process models
 ● Agile principle
● Scrum

1.2 Introduction
The IEEE [IEE93a] has created the below definition for software engineering:
Software Engineering : (1) The application of a systematic, disciplined, quantifiable approach to the
development, operation, and maintenance of software; that is, the application of engineering to software.
(2) The study of approaches as in (1).

Software engineering is built on a layered framework (see Figure 1.1), and any effective engineering
approach, including software engineering, requires a strong organizational commitment to quality.
Philosophies like Total Quality Management and Six Sigma promote a culture of continuous improvement,
which is essential for evolving better software engineering practices. At the core of software engineering
lies a focus on quality.

Figure 1.1 - Software engineering layers

The process layer is the fundamental layer of software engineering, acting as the binding element that
combines the various technology layers and facilitates the efficient and timely development of software.
It provides the foundation for managing software projects, outlining the context for applying technical
methods, producing work products (such as models, forms, and reports, ), setting milestones, ensuring
quality, and managing changes effectively.

Software engineering methods offer the technical guidance needed for software development. These
cover a range of tasks, including communication, requirements research, design modeling, program
construction, testing, and maintenance. They are based on fundamental principles that govern technology
and incorporate modeling activities and various descriptive techniques.

Software engineering tools offer automated or semi-automated assistance for processes and methods.
When these tools are integrated, allowing information generated by one tool to be utilized by another,
they create a system known as computer-aided software engineering, which supports software
development.

1.3 The Software Process

A process consists of a series of activities, actions, and tasks performed to create a work product.

● The activity aims to achieve a broad goal (such as stakeholder communication) and is relevant
across all application domains, project sizes, complexities, and levels of rigor in software
engineering.
● An action (like architectural design) includes a set of tasks that create a significant work product
(such as an architectural model).
● A task concentrates on a specific, well-defined objective (like conducting a unit test) that leads to
a tangible result.

In software engineering, a process is not a strict guideline for building software. Instead, it is a flexible
framework that allows the software team to select the most suitable actions and tasks for their work. The
goal is to deliver software on time and ensure it meets the quality standards required by both stakeholders
and end users.

1.3.1 The Process Framework

A process framework identifies framework activities that apply to all software projects, regardless of their
size or complexity, thus, specifying the foundation for the entire software engineering process.
Additionally, it includes a set of umbrella activities that apply throughout the entire software process.

Let's see the five key framework activities:

 ● Communication - Effective communication and collaboration with the customer and other
stakeholders are crucial before beginning any technical work. The goal is to understand their
objectives for the project and gather requirements that outline the desired software features and
functions.
● Planning - Just as a journey is easier with a map, a software project benefits from careful planning.
This planning activity produces a "map," known as a software project plan, which guides the team
throughout the project. The plan outlines the technical tasks to be performed, identifies potential
risks and required resources, specifies the work products to be created, and establishes a work
schedule.
● Modeling - Just as professionals like landscapers, bridge builders, and architects use models to
visualize their projects, software engineers create models to gain a clearer understanding of
software requirements and design. They begin with a broad "sketch" to capture the overall
concept, then refine it with increasing detail to better understand the problem and formulate
effective solutions.
● Construction - The designed software must be built, which involves combining code generation
with testing to identify and fix errors in the code.
● Deployment - The software, whether as partially completed or as a complete product, must be
delivered to the customer. The customer then evaluates the delivered product and provides
feedback based on their assessment.

These five generic framework activities can be applied to various software projects, from small programs
and web applications to large, complex systems. While the specifics of the software process may vary in
each scenario, the framework activities remain consistent.

In many projects, these activities are applied iteratively, meaning communication, planning, modeling,
construction, and deployment occur repeatedly throughout the project. Each iteration results in a
software increment, delivering a subset of overall features and functionality to stakeholders, gradually
bringing the software closer to completion.

1.3.2 Umbrella Activities

The software engineering process framework activities are supported by umbrella activities that are
consistently applied throughout a software project. These umbrella activities assist the software team in
overseeing and ensuring progress, maintaining quality, managing changes, and mitigating risks. Common
umbrella activities are:

● Software project tracking and control - It enables the software team to monitor progress in
comparison to the project plan and implement adjustments as needed to adhere to the schedule.
● Risk management - It evaluates potential risks that could impact the project's outcome or product
quality.
● Software quality assurance - It encompasses defining and executing the necessary activities to
guarantee the quality of the software.
● Technical reviews - This involves evaluating software engineering work products to identify and
rectify errors before they progress to the next stages.
● Measurement - It involves defining and collecting metrics related to process, project, and product
performance, aiding the team in delivering software that fulfils stakeholders’ requirements, and
supporting other framework and umbrella activities.
● Software configuration management - It oversees the impact of changes throughout the
software development process.
● Reusability management - It establishes criteria for reusing work products, including software
components, and implements mechanisms to facilitate their reuse.
● Work product preparation and production - It encompasses the activities necessary to create
various work products such as models, logs, documents, lists and forms.

Figure 1.2 represents the software process framework.

Figure 1.2 - A software Process Framework

1.4 A Generic Process Model

Now, we know that a software process is represented by a framework including work activities, actions,
and tasks performed when a work product is to be created. Let us discuss its another aspect in depth.

This aspect is called process flow and outlines the organization of framework activities, actions, and tasks
in terms of their sequence and timing. This is depicted in Figure 1.3.
Figure 1.3 - Process Flow
● Linear process flow: This type executes each of the five framework activities sequentially, starting
with communication and ending with deployment. Refer to Figure 1.3(a).
● Iterative process flow: This approach involves repeating one or more activities before moving to
the next. Refer to Figure 1.3(b).
 ● Evolutionary process flow: In this method, the activities are executed in a circular manner. Each
cycle through the five activities results in a more complete version of the software. Refer to Figure
1.3(c).
● Parallel process flow: This type executes one or more activities concurrently with others. For
example, planning for one aspect of the software might proceed simultaneously with the
modeling of another aspect. Refer to Figure 1.3(d).

1.5 Defining a Framework Activity

While we have outlined five framework activities and their basic definitions above, executing any of these
activities within the software process requires more detailed information. This leads to a crucial question:

What specific actions should be undertaken for each framework activity, considering the nature of the
problem, the skills and characteristics of the team members, and the interests of the stakeholders funding
the project?

For a small software project requested by a single stakeholder with clear requirements, the
communication activity may only involve a brief phone call or email exchange. Therefore, the essential
action required is a phone conversation. The specific work tasks involved in this action include:

1. Connect with the stakeholder via a phone call.

2. Discuss requirements and create detailed notes.
3. Arrange notes into a concise written statement of requirements.
4. Email the statement to the stakeholder for his review and approval.

In contrast, for a more complicated project involving multiple stakeholders with diverse and potentially
conflicting requirements, the communication process expands significantly. It would encompass six
distinct actions: inception, elicitation, elaboration, negotiation, specification, and validation. Each of
these actions involves numerous tasks and results in various work products.

1.6 Prescriptive Process Models

A prescriptive (or traditional) process model aims to set structure and order during software
development by defining sequential activities and tasks with clear guidelines for progress.

But are prescriptive models suitable for a software world that is based on change? If we ignore
traditional process models and their implied order and use less structured approaches, would this
approach hinder our ability to achieve coordination and coherence in software work?

Addressing these questions doesn't provide simple answers, but there are indeed alternatives for
software engineers to consider. In the upcoming sections, we delve into the prescriptive process
approach, where maintaining order and ensuring project consistency are primary concerns. These
models are termed "prescriptive" because they establish a defined set of process elements—such as
framework activities, software engineering actions, tasks, work products, quality assurance measures,
and change control mechanisms—for every project. Additionally, each process model outlines a specific
process flow (also known as a workflow), which presents how these process elements interact with one
another.

Every software process model can incorporate the generic framework activities. However, each model
places varying emphasis on these activities and defines a unique process flow that dictates how each
framework activity, along with software engineering actions and tasks, is implemented.
1.6.1 The Waterfall Model

There are instances when the requirements for a problem are well understood and work progresses from
communication through deployment in a linear manner. This scenario often arises when well-defined
adaptations or enhancements are needed for an existing system. This linear progression may also occur
in a limited number of new development projects, but only when the requirements are clearly defined
and remain stable over time.

Figure 1.4 - The Waterfall Model

The waterfall model, also known as the classic life cycle, proposes an ordered and step-by-step approach
to software development. It starts with the customer defining their requirements and moves through
stages like planning, modeling, construction, and deployment, ultimately concluding with continuous
support for the finalized software.
The waterfall model, the oldest paradigm in software engineering, has faced significant criticism over the
past decades, leading even its supporters to question its effectiveness (Han, 1995). Some challenges
commonly encountered with the waterfall model include:

1. Actual projects rarely adhere strictly to the sequential flow proposed by the model. While the
linear approach can incorporate iteration, it does so indirectly, making changes potentially
confusing for project teams as they progress.
2. Customers often find it hard to communicate all requirements upfront. The waterfall model
requires this, which can be difficult as it struggles to accommodate the uncertainty.
3. The customer should be patient because a functional version of the program(s) will not be
available until late in the project timeline. If a significant mistake remains undetected until the
program is operational, it can lead to disastrous consequences.
In a compelling study of real-world projects, Bradac [Bra94] discovered that the sequential nature of the
traditional life cycle results in "blocking states," where certain team members must wait for others to
finish dependent tasks. Surprisingly, the time spent waiting can sometimes exceed the time spent on
productive work. These blocking states are particularly common at the start and end of a linear sequential
process.

In today's fast-paced software environment, projects often experience a continuous flow of changes,
including adjustments to features, functions, and content. The waterfall model is frequently deemed
unsuitable for such dynamic work scenarios. However, it can still be valuable as a process model in
situations where requirements are well-defined and the project can progress linearly to completion.

1.6.2 Incremental Process Models

There are numerous scenarios where initial software requirements are sufficiently well-defined, yet the
overall scope of the development effort prevents a strictly linear process. Moreover, there might be a
strong requirement to deliver a basic set of software functionalities to users rapidly, with subsequent
iterations to refine and expand upon these functionalities in later releases. In such cases, opting for a
process model designed to produce software incrementally would be beneficial.

The incremental model integrates both linear and parallel process flows. As illustrated in Figure 1.6, this
model applies linear sequences in a staggered manner as time progresses on the calendar. Each of these
linear sequences generates deliverable "increments" of the software [McD93].
Figure 1.6 - The Incremental Model

As an example, if word-processing software is developed using the incremental model, it could initially
provide fundamental features like file management, basic editing, and document creation in the first
increment. Subsequent increments would introduce more advanced editing tools and document
production capabilities in the second stage, followed by spelling and grammar checking in the third, and
advanced page layout functionalities in the fourth. It's important to emphasize that each increment's
process flow can integrate elements of the prototyping approach described below.

In an incremental model, the first increment typically serves as the core product where fundamental
requirements are implemented, but many additional features—some identified and others yet to be
discovered—remain unfinished. The core product is then utilized by the customer or undergoes thorough
evaluation. Based on this usage and evaluation, a plan is formulated for the subsequent increment. This
plan focuses on refining the core product to better align with customer needs and delivering additional
features and functionalities. This iterative process continues with each increment until the complete
product is delivered.

1.6.3 Evolutionary Process Models

Software undergoes evolution over time. As development progresses, business and product needs often
shift, making it impractical to follow a straightforward path to a final product but a limited version is
required to stay competitive. In such scenarios, a process model explicitly designed to accommodate
evolving and expanding products is essential.

Evolutionary models are iterative. They are represented in a manner that allows you to develop
increasingly more complete versions of the software. Let us see the two common evolutionary process
models below.

Prototyping
Sometimes, a client outlines broad goals for software without specifying detailed functional requirements.
Similarly, developers might be uncertain about algorithm efficiency, operating system compatibility, or
optimal human-machine interaction. In such scenarios and others, using a prototyping approach could be
the most suitable method.

While prototyping can function independently as a process model, it can be integrated into various
process models. Regardless of its application, the prototyping paradigm helps the stakeholders gain clarity
on what needs to be developed, especially when requirements are ambiguous.

Figure 1.7 - The Prototyping Paradigm

The prototyping paradigm (Figure 1.7) starts with communication. Stakeholders collaborate to define the
overall objectives of the software, identify requirements, and mark the areas needing further clarification.
A prototyping iteration is swiftly planned, and modeling takes place through a "quick design." This design
focuses on visual aspects of the software that will be seen by end users, such as interface layouts or output
formats. Following the quick design, a prototype is constructed. This prototype is then deployed and
evaluated by stakeholders, who provide feedback for refining requirements further. Iteration continues
as the prototype is adjusted to meet the needs of various stakeholders.

The prototype acts as a tool for identifying software requirements. When constructing a working
prototype, developers can utilize existing program components or use tools that facilitate the quick
generation of functional programs. Brooks [Bro95] answers the question of "what to do with the
prototype after it has served the objective described earlier" -

''In most projects, the first system built is barely usable. It may be too slow, too big, awkward in use or all
three. There is no alternative but to start again, smarting but smarter, and build a redesigned version in
which these problems are solved.''

The prototype can act as "the first system". While some prototypes are indeed created as throwaway
models—used solely to explore ideas and clarify requirements—others take on an evolutionary role. In
these cases, the prototype gradually transforms into the actual system through iterative refinement and
development.

Both stakeholders and software engineers favor the prototyping approach. Users experience the actual
system, while developers get to create something. Prototyping can indeed present challenges for several
reasons:

1. Stakeholders may perceive a prototype as a fully functional software product, unaware that it
has been hurriedly assembled and lacks consideration for overall software quality and long-term
maintainability. When informed that rebuilding is necessary to ensure high quality, stakeholders
may resist and demand quick fixes to transform the prototype into a functional product.
Unfortunately, in many cases, management may concede to these demands due to time
pressures or stakeholder expectations.
 2. As a software engineer, when creating prototypes, there's a tendency to make implementation
compromises to achieve quick results. This can include using an inappropriate operating system
or programming language simply because it's readily available and familiar. Over time, you
become accustomed to these choices and focus on iterating and improving the prototype and
forget the initial reasons why these decisions were unsuitable. Eventually, these less-than-ideal
choices become vital parts of the system.

Despite potential challenges, prototyping remains a valuable paradigm in software engineering when
managed effectively. The crucial step is to establish clear guidelines from the start. All stakeholders
should collectively agree that the prototype's primary purpose is to define and refine requirements.
Once the prototype has served its purpose, it is either discarded entirely or used selectively as a
reference. The actual software development phase then begins.

The Spiral Model

Barry Boehm [Boe88] initially introduced the spiral model as an evolutionary approach to software
development. This model combines iterative prototyping with the structured approach of the waterfall
model. It aims to facilitate the swift creation of progressively refined versions of software. Boehm
[Boe01a] further describes the model as follows:

‘’The spiral development model is a risk-driven process model generator that is used to guide multi-
stakeholder concurrent engineering of software intensive systems. It has two main distinguishing
features. One is a cyclic approach for incrementally growing a system’s degree of definition and
implementation while decreasing its degree of risk. The other is a set of anchor point milestones for
ensuring stakeholder commitment to feasible and mutually satisfactory system solutions.’’

In the spiral model, software development progresses through a sequence of evolutionary releases.
Initially, these releases might be in the form of models or prototypes. As the development continues,
refined versions of the engineered system are produced.

The spiral model is based on a group of framework activities defined by the software engineering team.
These activities correspond to segments of the spiral path, as depicted in Figure 1.8.

Figure 1.8 - The Spiral Model

As the development progresses through each iteration of the spiral, the team performs these framework
activities in a clockwise direction starting from the center. Each revolution around the spiral path
considers risks. Anchor point milestones—a combination of specific work products and conditions that are
achieved along the path of the spiral— are recorded for each evolutionary pass.

Initially, the first round through the spiral involves creating a detailed product specification. Following
iterations then focus on prototyping and advancing the software through successive stages of complexity.
Each cycle through the planning area involves refining the project plan. Adjustments to costs and
schedules are made based on customer feedback received after each deliverable. Additionally, the project
manager may revise the planned number of iterations needed to complete the software.

In contrast to other process models that finish upon software delivery, the spiral model can be used
throughout the entire lifespan of computer software. In this model, the first circuit around the spiral could
represent a "concept development project," starting at the core and continuing through multiple
iterations until the concept is fully developed. If the concept advances to become an actual product, the
process extends outward on the spiral, marking the commencement of a "new product development
project." The new product undergoes iterative development around the spiral model. Subsequently,
further iterations around the spiral can signify a "product enhancement project." This framework of the
spiral model remains active throughout the entire lifecycle of the software. Periodically, there may be
dormant periods in the process, but whenever a change is initiated, the process resumes from the
appropriate entry point.

Advantages
● The spiral model offers a practical approach to developing large-scale systems and software.
● It allows for the continuous evolution of software, enabling both developers and customers to
better understand and address risks as the project progresses.
● Prototyping is used within the spiral model to mitigate risks, with the flexibility to apply this
approach at any phase of product development
● By emphasizing the assessment of technical risks throughout every stage of the project, the spiral
model aims to proactively manage and minimize risks before they escalate.

Similar to other methodologies, the spiral model is not a universal solution. Convincing customers about
the evolutionary approach can be challenging, especially in contractual contexts. Successful application of
the spiral model requires substantial expertise in risk assessment. Failure to identify and manage
significant risks can lead to inevitable issues during the project.

1.7 What is agility?

Ivar Jacobson [Jac02a] offers a useful discussion to understand the concept of agility concerning software
engineering:
“Agility has become today’s buzzword when describing a modern software process. Everyone is agile. An
agile team is a nimble team able to appropriately respond to changes. Change is what software
development is very much about. Changes in the software being built, changes to the team members,
changes because of new technology, changes of all kinds that may have an impact on the product they
build or the project that creates the product. Support for changes should be built-in everything we do in
software, something we embrace because it is the heart and soul of software. An agile team recognizes
that software is developed by individuals working in teams and that the skills of these people, their ability
to collaborate is at the core for the success of the project.”

According to Jacobson, the primary catalyst for agility is the constant presence of change. Software
engineers need to be responsive to manage the rapid changes that Jacobson highlights effectively.

However, agility extends beyond responding effectively to change. Agility promotes team structures and
attitudes that facilitate seamless communication among team members, between technologists and
business stakeholders, and between software engineers and their managers. It highlights the rapid
delivery of functional software while reducing the emphasis on intermediate deliverables, though this can
sometimes have drawbacks. Agility embraces the customer as an integral part of the development team
and aims to break down traditional barriers between stakeholders, fostering collaboration. It
acknowledges the challenges of planning in uncertain environments and emphasizes the importance of
flexibility in project plans.

Agility can be integrated into any software process, but to achieve this, the process must be designed to
enable the project team to adapt and streamline tasks. Planning should recognize the dynamic nature of
agile development, focusing on flexibility. It's crucial to minimize unnecessary work products, keeping
them lean and concentrating on essential outputs. Emphasizing an incremental delivery strategy is key,
ensuring that functional software reaches the customer as quickly as feasible, tailored to the specific
product type and operational environment.
1.8 What is an Agile Process?

An agile software process is designed to accommodate several fundamental assumptions [Fow02] about
software projects:

1. Predicting which software requirements will remain constant and how customer priorities may
shift during the project is challenging.
2. Many software projects involve simultaneous design and construction phases, ensuring that
design models are validated as they are developed. Determining the exact amount of design
needed before construction begins is also uncertain.
3. The activities of analysis, design, construction, and testing cannot be reliably predicted in
advance from a planning perspective.

Based on these three assumptions, a crucial question arises: How does a process can be developed to
manage unpredictability? The answer is process adaptability of continuously changing project and
technical conditions. An agile process, thus, should be adaptable.

However, continuous adjustment without moving forward accomplishes little. Therefore, an agile
software process must evolve incrementally. For this, an agile team needs feedback from customers to
make appropriate adjustments. An effective way to gather customer feedback is through an operational
prototype of a system. Therefore, an incremental development strategy should be implemented.
Software increments, such as executable prototypes or functional system components, should be
delivered within short timeframes to keep up with changes and unpredictability. This iterative approach
allows the customer to regularly assess the software increments, provide feedback to the software team,
and influence the adjustments made to the process to accommodate this feedback.

1.8.1 Agility Principles

The Agile Alliance ( [Agi03], [Fow01]) defines 12 agility principles mentioned below:

1. Our highest priority is to satisfy the customer by delivering the software early and consistently.
 2. Welcome changing requirements, even late in development. Agile processes harness change for
the customer's competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a
preference for a shorter timescale.
4. Business people and developers must work together daily throughout the project.
5. Build projects around motivated individuals. Give them the environment and support they need,
and trust them to complete the job.
6. Face-to-face conversation is the most efficient and effective method of conveying information
to and within a development team.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors, developers, and users should
be able to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity—the art of maximizing the amount of work not done—is essential.
11. The best architectures, requirements, and designs emerge from self-organizing teams.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts
its behavior accordingly.

Not all agile process models emphasize all 12 principles equally, and some may choose to downplay or
even ignore the significance of one or more principles. Nevertheless, these principles define a
fundamental agile ethos that is preserved in each of the process models.

1.9 Scrum

Scrum, an agile software development methodology, originated in the early 1990s by Jeff Sutherland and
his development team. Over the years, Schwaber and Beedle [Sch01b] offered advancements in Scrum
methods.

The principles of Scrum align with the agile manifesto and serve as guidelines for development activities
within a process that includes the following phases: requirements, analysis, design, evolution, and
delivery. Each of these phases operates within a process framework known as a sprint. The work
conducted within a sprint is tailored to the specific project needs and is defined and adjusted in real time
by the Scrum team. The overall flow of the Scrum process is depicted in Figure 1.9.

Scrum emphasizes employing a collection of software process patterns [Noy02] that have demonstrated
effectiveness in projects characterized by stringent deadlines, evolving requirements, and critical business
needs. Each of these process patterns outlines a series of development activities:

Backlog - This refers to a prioritized list of project requirements or features that deliver business value to
the customer. Items can be added to the backlog at any point, allowing changes. The product manager
evaluates the backlog regularly and adjusts priorities as necessary.

Sprints - They are composed of work units aimed at fulfilling a requirement defined in the backlog, all of
which must fit within a predetermined time-box (typically 30 days). No changes, such as adding or altering
backlog items, are permitted during the sprint. This restriction ensures that team members can operate
in a short-term, stable environment.
Figure 1.9 - Scrum Process Flow

Scrum meetings - Also known as daily stand-ups or daily scrums, these meetings are brief gatherings
conducted every day by the Scrum team. Each meeting typically lasts around 15 minutes. During these
meetings, all team members address three key questions [Noy02]:

- What have you accomplished since the last team meeting?

- What obstacles or challenges are you currently facing?
- What do you plan to achieve by the next team meeting?

A Scrum master (the team leader) facilitates the meeting and evaluates the responses from each team
member. The Scrum meeting serves to identify potential issues at an early stage. Additionally, these
daily interactions foster "knowledge socialization" [Bee99] promoting a self-organizing team structure.

Demos - They involve presenting the software increment to the customer and showcasing the
implemented functionality for evaluation. It's important to understand that the demo might not
encompass all planned features but rather focuses on the functions that can be completed within the
established time-box.

1.10 Summary

● Software engineering is built on a layered framework - Quality Focus, Process, Methods and Tools.
● A process consists of a series of activities, actions, and tasks performed to create a work product.
 ● A process framework identifies framework activities and umbrella activities that apply to all
software projects, regardless of their size or complexity.
● Key framework activities are - Communication, Planning, Modeling, Construction and
Deployment.
● A process flow outlines the organization of framework activities, actions, and tasks in terms of
their sequence and timing.
● A process flow is of four types - linear, iterative, evolutionary and parallel.
● A prescriptive process model sets structure and order during software development by defining
sequential activities and tasks.
● It is of three types - Waterfall model, Incremental model and Evolutionary model.
● The waterfall model (or classic life cycle) proposes an ordered and step-by-step approach to
software development. It comes with many disadvantages but it is also considered valuable where
requirements are well-defined and the project can progress linearly to completion.
● The incremental model integrates both linear and parallel process flows. It delivers basic software
functionalities to users rapidly, with subsequent iterations (or increments) to refine these
functionalities in later releases.
● Evolutionary models are iterative. They are of two types - The prototype model and The Spiral
model.
● The prototype acts as a tool for identifying software requirements. The prototyping paradigm
helps the stakeholders gain clarity on what needs to be developed, especially when requirements
are ambiguous.
● The Spiral model combines iterative prototyping with the structured approach of the waterfall
model.
● The primary catalyst for agility is the constant presence of change. It has 12 principles.
● Scrum is another software development methodology that includes the phases: requirements,
analysis, design, evolution, and delivery.

1.11 Glossary

● Prototype - It is an early, often simplified version of a software application.

● Agility - It refers to the ability to quickly and effectively respond to change and adapt to new
circumstances.
 ● Anchor point milestones - They are a combination of specific work products and conditions that
are achieved along the path of the spiral model.
● Sprint - Phases of scrum operate within a process framework.

1.12 In-text Questions Answers

1. Four
2. Framework, Umbrella
3. Process Flow
4. Communication
5. Traditional
6. Waterfall, Classic life
7. Iterative
8. First
9. Risk-driven
10. Change
11. 12
12. Sprint

1.13 Self-assessment Questions

Q1 - Define software engineering and describe how it is organized into layers.

Q2 - What is a process framework? What activities does it include?
Q3 - Explain a process flow and its types.
Q4 -What is a Waterfall model? How does a V-model overcome the disadvantages of the Waterfall model?
Q5 - What advantages does the Spiral model offer over the prototyping model?
Q6 - What is Agility? Explain an agile process. Why is agility required?
Q7 - Define Scrum and explain the Scrum activities.

1.14 References
Pressman, R.S., & Maxim, B.R. (2015). Software Engineering: A Practitioner’s Approach. 8th Edition.
McGraw-Hill.
1.15 Suggested Readings
1. Aggarwal, K.K., & Singh, Y. (2007). Software Engineering. 3rd Edition. New Age International
Publishers.
2. Jalote, P. An Integrated Approach to Software Engineering, 3rd Edition, Narosa Publishing
House, 2005.
3. Sommerville, I. Software Engineering, 9th Edition. Addison Wesley, 2011.
4. The Definitive Guide to Scrum: The Rules of the Game, Ken Schwaber, Jeff Sutherland, July 2016.