Software Engineering

TE SEMESTER V COMPUTER ENGINEERING

By Radha Nabar
Module: 01] Introduction to Software Engineering and Process Models

1.1 Software Engineering-process framework, the Capability Maturity Model (CMM),

Advanced Trends in Software Engineering
1.2 Prescriptive Process Models: The Waterfall, Incremental Process Models, Evolutionary
Process Models: RAD & Spiral
1.3 Agile process model: Extreme Programming (XP), Scrum, Kanban

Introduction:
Defining software: 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 Application Domains: Today, seven broad categories of computer software present
continuing challenges for software engineers:
1. System software: a collection of programs written to service other programs. Some
system software (e.g., compilers, editors, and file management utilities) processes
complex, but determinate, information structures. Other systems applications (e.g.,
operating system components, drivers, networking software, telecommunications
processors) process largely indeterminate data.
2. Application software: stand-alone programs that solve a specific business need.
Applications in this area process business or technical data in a way that facilitates
business operations or management/technical decision making.
3. Engineering/scientific software: a broad array of “number-crunching programs that
range from astronomy to volcanology, from automotive stress analysis to orbital
dynamics, and from computer-aided design to molecular biology, from genetic analysis
to meteorology.
4. Embedded software: resides within a product or system and is used to implement and
control features and functions for the end user and for the system itself. Embedded
software can perform limited and esoteric functions (e.g., keypad control for a
microwave oven) or provide significant function and control capability (e.g., digital
functions in an automobile such as fuel control, dashboard displays, and braking
systems).
5. Product-line software: designed to provide a specific capability for use by many
different customers. Product-line software can focus on a limited and esoteric
marketplace (e.g., inventory control products) or address mass consumer.
6. Web/Mobile applications: this network-centric software category spans a wide array
of applications and encompasses both browser-based apps and software that resides on
mobile devices.
7. Artificial intelligence software: makes use of non-numerical algorithms to solve
complex problems that are not amenable to computation or straightforward analysis.
Applications within this area include robotics, expert systems, pattern recognition
(image and voice), artificial neural networks, theorem proving, and game playing.

Software Engineering (TE SEM V Computer Engineering)

By Radha Nabar Page 1
Categories of Software: Four broad categories of software are evolving to dominate the
industry.
1. WebApps: In the early days of the World Wide Web (1990 to 1995), websites consisted
of little more than a set of linked hypertext files that presented information using text
and limited graphics. As time passed, the augmentation of HTML by development tools
(e.g., XML, Java) enabled Web engineers to provide computing capability along with
informational content. Today, WebApps have evolved into sophisticated computing
tools that not only provide stand-alone function to the end user, but also have been
integrated with corporate databases and business applications.
2. Mobile Applications: The term app has evolved to connote software that has been
specifically designed to reside on a mobile platform (e.g., iOS, Android, or Windows
Mobile). In most instances, mobile applications encompass a user interface that takes
advantage of the unique interaction mechanisms provided by the mobile platform,
interoperability with Web-based resources that provide access to a wide array of
information that is relevant to the app, and local processing capabilities that collect,
analyse, and format information in a manner that is best suited to the mobile platform.
In addition, a mobile app provides persistent storage capabilities within the platform.
A mobile web application (WebApp) allows a mobile device to gain access to web-
based content via a browser that has been specifically designed to accommodate the
strengths and weaknesses of the mobile platform.
3. Cloud Computing: Cloud computing encompasses an infrastructure or “ecosystem”
that enables any user, anywhere, to use a computing device to share computing
resources on a broad scale. The overall logical architecture of cloud computing is
represented following figure 1.

Figure 1: Cloud Computing

Referring to the figure, computing devices reside outside the cloud and have access to
a variety of resources within the cloud. These resources encompass applications,
Software Engineering (TE SEM V Computer Engineering)
By Radha Nabar Page 2
 platforms, and infrastructure. In its simplest form, an external computing device
accesses the cloud via a Web browser or analogous software. The cloud provides access
to data that resides with databases and other data structures. In addition, devices can
access executable applications that can be used in lieu of apps that reside on the
computing device. The implementation of cloud computing requires the development
of an architecture that encompasses front-end and back-end services. The front-end
includes the client (user) device and the application software (e.g., a browser) that
allows the back-end to be accessed. The back-end includes servers and related
computing resources, data storage systems (e.g., databases), server-resident
applications, and administrative servers that use middleware to coordinate and monitor
traffic by establishing a set of protocols for access to the cloud and its resident
resources.
4. Product line software: The Software Engineering Institute defines a software product
line as “a set of software-intensive systems that share a common, managed set of
features satisfying the specific needs of a particular market segment or mission and that
are developed from a common set of core assets in a prescribed way.” The concept of
a line of software products that are related in some way is not new. But the idea that a
line of software products, all developed using the same underlying application and data
architectures, and all implemented using a set of reusable software components that can
be reused across the product line provides significant engineering leverage.

Software Development Life Cycle (SDLC): Software Development Life Cycle, SDLC for
short, is a well-defined, structured sequence of stages in software engineering to develop the
intended software product. SDLC provides a series of steps to be followed to design and
develop a software product efficiently shown in figure 2. SDLC framework includes the
following steps:
1. Planning: It is performed by the senior members of the team with inputs from the customer,
the sales department, market surveys and domain experts in the industry. This information is
then used to plan the basic project approach and to conduct product feasibility study in the
economical, operational and technical areas.
2. Analysis: At this step the developers decide a roadmap of their plan and try to bring up the
best software model suitable for the project. System analysis includes Understanding of
software product limitations, learning system related problems or changes to be done in
existing systems. The project team analyses the scope of the project and plans the schedule and
resources accordingly.
3. Design: Next step is to bring down whole knowledge of requirements and analysis on the
desk and design the software product. The inputs from users and information gathered in
requirement gathering phase are the inputs of this step. The output of this step comes in the
form of two designs; logical design and physical design. Engineers produce meta-data and data
dictionaries, logical diagrams, data-flow diagrams and in some cases pseudo codes.
4. Coding/Implementation: This step is also known as programming phase. The
implementation of software design starts in terms of writing program code in the suitable
programming language and developing error-free executable programs efficiently.
5. Testing: Errors may ruin the software from critical level to its own removal. Software testing
is done while coding by the developers and thorough testing is conducted by testing experts at
various levels of code such as module testing, program testing, product testing, in-house testing
and testing the product at user’s end. Early discovery of errors and their remedy is the key to
reliable software.

Software Engineering (TE SEM V Computer Engineering)

By Radha Nabar Page 3
6. Integration and Deployment: Software may need to be integrated with the libraries,
databases and other programs. Deployment means installing the software on user machines. At
times, software needs post-installation configurations at user end. Software is tested for
portability and adaptability and integration related issues are solved during implementation.
7. Maintenance: This phase confirms the software operation in terms of more efficiency and
less errors. If required, the users are trained on, or aided with the documentation on how to
operate the software and how to keep the software operational. The software is maintained
timely by updating the code according to the changes taking place in user end environment or
technology.

Figure 2: Stages of Software Development Life Cycle

Software Engineering: Software engineering is defined as the application of a systematic,

disciplined, quantifiable approach to the development, operation, and maintenance of software;
that is, the application of engineering to software. Software engineering is an engineering
discipline that is concerned with all aspects of software production. Software engineering is a
layered technology as shown in following figure 3.

Figure 3: Software Engineering Layers

1. Process: The foundation for software engineering is the process layer. The software
engineering process is the glue that holds the technology layers together and enables

Software Engineering (TE SEM V Computer Engineering)

By Radha Nabar Page 4
 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.
2. Methods: 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 modelling, program construction, testing, and support.
Software engineering methods rely on a set of basic principles that govern each area of
the technology and include modelling activities and other descriptive techniques.
3. Tools: 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.

The Software Process: A process is a collection of activities, actions, and tasks that are
performed when some work product is to be created. An activity strives to achieve a broad
objective (e.g., communication with stakeholders) and is applied regardless of the application
domain, size of the project, complexity of the effort, or degree of rigor with which software
engineering is to be applied. An action (e.g., architectural design) encompasses a set of tasks
that produce a major work product (e.g., an architectural model). A task focuses on a small, but
well-defined objective (e.g., conducting a unit test) that produces a tangible outcome.
In the context of software engineering, a process is not a rigid prescription for how to build
computer software. Rather, it is an adaptable approach that enables the people doing the work
(the software team) to pick and choose the appropriate set of work actions and tasks. The intent
is always to deliver software in a timely manner and with sufficient quality to satisfy those who
have sponsored its creation and those who will use it.

1.1.1 Software Engineering Process Framework: A process framework establishes the

foundation for a complete software engineering process by identifying a small number of
framework activities that are applicable to all software projects, regardless of their size or
complexity. In addition, the process framework encompasses a set of umbrella activities that
are applicable across the entire software process. A generic process framework for software
engineering encompasses five activities:
1. Communication: Before any technical work can commence, it is critically important
to communicate and collaborate with the customer (and other stakeholders). The intent
is to understand stakeholders’ objectives for the project and to gather requirements that
help define software features and functions.
2. Planning: Any complicated journey can be simplified if a map exists. A software
project is a complicated journey, and the planning activity creates a “map” that helps
guide the team as it makes the journey. The map called a software project plan defines
the software engineering work by describing the technical tasks to be conducted, the
risks that are likely, the resources that will be required, the work products to be
produced, and a work schedule.
3. Modelling: Whether you’re a landscaper, a bridge builder, an aeronautical engineer, a
carpenter, or an architect, you work with models every day. You create a “sketch” of
the thing so that you’ll understand many characteristics. A software engineer does the

Software Engineering (TE SEM V Computer Engineering)

By Radha Nabar Page 5
 same thing by creating models to better understand software requirements and the
design that will achieve those requirements.
4. Construction: What you design must be built. This activity combines code generation
(either manual or automated) and the testing that is required to uncover errors in the
code.
5. Deployment: The software is delivered to the customer who evaluates the delivered
product and provides feedback based on the evaluation.
These five generic framework activities can be used during the development of small, simple
programs, the creation of Web applications, and for the engineering of large, complex
computer-based systems.

Figure 4: A Software Process Framework

Umbrella Activities: Software engineering process framework activities are complemented

by a number of umbrella activities. In general, umbrella activities are applied throughout a
software project and help a software team manage and control progress, quality, change, and
risk. Typical umbrella activities include:
1. Software project tracking and control: allows the software team to assess progress
against the project plan and take any necessary action to maintain the schedule.

Software Engineering (TE SEM V Computer Engineering)

By Radha Nabar Page 6
 2. Risk management: assesses risks that may affect the outcome of the project or the
quality of the product.
3. Software quality assurance: defines and conducts the activities required to ensure
software quality.
4. Technical reviews: assess software engineering work products in an effort to uncover
and remove errors before they are propagated to the next activity.
5. Measurement: defines and collects process, project, and product measures that assist
the team in delivering software that meets stakeholders’ needs; can be used in
conjunction with all other framework and umbrella activities.
6. Software configuration management: manages the effects of change throughout the
software process.
7. Reusability management: defines criteria for work product reuse (including software
components) and establishes mechanisms to achieve reusable components.
8. Work product preparation and production: encompass the activities required to
create work products such as models, documents, logs, forms, and lists.

1.1.2 The Capability Maturity Model (CMM): The Software Engineering Institute (SEI)
Capability Maturity Model (CMM) specifies an increasing series of levels of a software
development organization. The higher the level, the better the software development process,
hence reaching each level is an expensive and time-consuming process.

Figure 5: Levels of CMM

1. Initial Level: Work is performed informally. The software process is characterized as

ad hoc and occasionally even chaotic. Few processes are defined, and success depends
on individual effort. This is unstable environment for software development. There is
no basis for predicting product quality, time for completion, etc.

Software Engineering (TE SEM V Computer Engineering)

By Radha Nabar Page 7
 2. Repeatable Level: Work is planned and tracked. Basic project management processes
are established to track cost, schedule, and functionality. The necessary process
discipline is in place to repeat earlier successes on projects with similar applications.
3. Defined Level: Work is well defined. The software process for both management and
engineering activities is documented, standardized, and integrated into an organization
wide software process. All projects use a documented and approved version of the
organization's process for developing and supporting software. This level includes all
characteristics defined for level 2.
4. Managed Level: Work is quantitatively controlled. Detailed measures of the software
process and product quality are collected. Both the software process and products are
quantitatively understood and controlled using detailed measures. This level includes
all characteristics defined for level 3.
5. Optimizing Level: Work is based upon continuous improvement. Continuous process
improvement is enabled by quantitative feedback from the process and from testing
innovative ideas and technologies. This level includes all characteristics defined for
level 4.

1.1.3 Advanced Trends in Software Engineering: Software engineers will face the
challenges of dealing with rapid change, uncertainty and emergence, dependability, diversity,
and interdependence. Each nation with IT industry has a set of unique characteristics that define
the manner in which business is conducted, the organizational dynamics that arise within a
company, the distinct marketing issues that apply to local customers, and the overriding culture
that dictates all human interaction. However, some trends in each of these areas are universal.

Soft Trends: The trends that have an effect on software engineering technology often come
from the business, organizational, market, and cultural arenas. These “soft trends” can guide
the direction of research and the technology that is derived as a consequence of research.
The broad characteristics of the new systems we build (and test), e.g.
• Emergent requirements
• Autonomy of action
The anthropological and sociological characteristics of the new generation of people who do
software engineering work.
1. Connectivity and collaboration has already led to software teams that do not occupy
the same physical space (telecommuting and part-time employment in a local context).
One team collaborates with other teams that are separated by time zones, primary
language, and culture. Software engineering must respond with an overarching process
model for “distributed teams” that is agile enough to meet the demands of immediacy
but disciplined enough to coordinate disparate groups.
2. Globalization leads to a diverse workforce (in terms of language, culture, problem
resolution, management philosophy, communication priorities, and person-to-person
interaction). This, in turn, demands a flexible organizational structure.
3. Aging population: This undeniable demographic (and cultural trend) implies that
many experienced software engineers and managers will be leaving the field over the
coming decade. The software engineering community must respond with viable
mechanisms that capture the knowledge of these aging managers and technologists.
4. Human culture: Human culture itself will impact the direction of software engineering.
Every generation establishes its own imprint on local culture.

Software Engineering (TE SEM V Computer Engineering)

By Radha Nabar Page 8
Hard Trends: The technical aspects of next generation software intensive systems. The
technical directions that software engineering process, methods, and tools will take.

Process Trends: Following are the six ideas proposed by Conradi and Fuggetta are adopted to
suggest possible process trends.
1. As SPI frameworks evolve, they will emphasize “strategies that focus on goal orientation
and product innovation. This means that a stable, step-by-step road map for SPI may have to
be replaced with a framework that emphasizes short-term goals that have a product orientation.
2. SPI activities should “use a simple and focused scorecard to start with, not a large
assessment.”
3. Automated software process technology (SPT) will move away from global process
management to focus on those aspects of the software process that can best benefit from
automation. To be most effective, it should focus on umbrella activities.
4. Greater emphasis will be placed on the return on investment of SPI activities.
5. Much can be learned by examining the sociology of groups to better understand effective
ways to introduce change.
6. New modes of learning may facilitate the transition to a more effective software process. In
this context, “learning” implies learning from successes and mistakes.

1.2 Prescriptive Process Models: A prescriptive process model strives for structure and order
in software development. Activities and tasks occur sequentially with defined guidelines for
progress. We call them “prescriptive” because they prescribe a set of process elements—
framework activities, software engineering actions, tasks, work products, quality assurance,
and change control mechanisms for each project. Each process model also prescribes a process
flow (also called a work flow) that is, the manner in which the process elements are interrelated
to one another.

1.2.1 The Waterfall Model: The waterfall model, sometimes called the classic life cycle,
suggests a systematic, sequential approach to software development that begins with customer
specification of requirements and progresses through planning, modelling, construction, and
deployment, culminating in on-going support of the completed software as shown in figure 6.

Figure 6: The waterfall model

A variation in the representation of the waterfall model is called the V-model. Represented in
Figure 7, the V-model depicts the relationship of quality assurance actions to the actions
associated with communication, modelling, and early construction activities. As software team
moves down the left side of the V, basic problem requirements are refined into progressively
more detailed and technical representations of the problem and its solution. Once code has been

Software Engineering (TE SEM V Computer Engineering)

By Radha Nabar Page 9
generated, the team moves up the right side of the V, essentially performing a series of tests
(quality assurance actions) that validate each of the models created as the team moves down
the left side.
In reality, there is no fundamental difference between the classic life cycle and the V-model.
The V-model provides a way of visualizing how verification and validation actions are applied
to earlier engineering work. Following are the steps included in V- model:

Figure 7: The V-Model

1. Requirement Modelling: It is a process used in software development projects

where requirements and solutions constantly evolve through collaborative efforts
and teamwork.
2. Architectural Design: This design models the overall software structure by
representing components interface, dependencies, relationships and interaction.
3. Component Design: A component is a modular building block for computer
software. Component design occurs after the first iteration of the architectural
design has been completed. At this stage overall data and program structure of the
software which can help to translate design model into operational software.
4. Code Generation: It includes coding for the required software.
5. Unit Testing: Unit testing focuses verification effort on the smallest unit of
software design—the software component or module using the component-level
design description.
6. Integration Testing: Integration testing is a systematic technique for constructing
the software architecture while at the same time conducting tests to uncover errors
associated with interfacing. The objective is to take unit-tested components and
build a program structure that has been dictated by design.

Software Engineering (TE SEM V Computer Engineering)

By Radha Nabar Page 10
 7. System Testing: System testing is actually a series of different tests whose primary
purpose is to fully exercise the computer-based system. Although each test has a
different purpose all work to verify that system elements have been properly
integrated and perform allocated functions.
8. Acceptance Testing: It is a test conducted to determine if the requirements of
specification/ contract are met.

Among the problems that are sometimes encountered when the waterfall model is applied are:
1. Real projects rarely follow the sequential flow that the model proposes. Although the linear
model can accommodate iteration, it does so indirectly. As a result, changes can cause
confusion as the project team proceeds.
2. It is often difficult for the customer to state all requirements explicitly. The waterfall model
requires this and has difficulty accommodating the natural uncertainty that exists at the
beginning of many projects.
3. The customer must have patience. A working version of the program(s) will not be available
until late in the project time span.
Today, software work is fast paced and subject to a never-ending stream of changes. The
waterfall model is often inappropriate for such work. However, it can serve as a useful process
model in situations where requirements are fixed and work is to proceed to completion in a
linear manner.

1.2.2 The Incremental Process Models: The incremental model combines the elements linear
and parallel process flows referring to Figure 8, the incremental model applies linear sequences
in a staggered fashion as calendar time progresses. Each linear sequence produces deliverable
“increments” of the software.

Figure 8: Incremental Process Models

For example, word-processing software developed using the incremental paradigm might
deliver basic file management, editing, and document production functions in the first
increment; more sophisticated editing and document production capabilities in the second
increment; spelling and grammar checking in the third increment; and advanced page layout
capability in the fourth increment.

Software Engineering (TE SEM V Computer Engineering)

By Radha Nabar Page 11
When an incremental model is used, the first increment is often a core product. That is, basic
requirements are addressed but many supplementary features remain undelivered. As a result
of evaluation, a plan is developed for the next increment. The plan addresses the modification
of the core product to better meet the needs of the customer and the delivery of additional
features and functionality. This process is repeated following the delivery of each increment,
until the complete product is produced.

1.2.2.1 The RAD Model: Rapid application development (RAD) is an incremental software
development process model that emphasizes an extremely short development cycle. The RAD
model is a “high-speed” adaptation of the linear sequential model in which rapid development
is achieved by using component-based construction. The RAD approach encompasses the
following phases:

Figure 9: The RAD model

1. Business modelling: The information flow among business functions is modeled in a

way that answers the following questions: What information drives the business
process? What information is generated? Who generates it? Where does the information
go? Who processes it?
2. Data modelling: The information flow defined as part of the business modeling phase
is refined into a set of data objects that are needed to support the business. The
characteristics (called attributes) of each object are identified and the relationships
between these objects defined.
Software Engineering (TE SEM V Computer Engineering)
By Radha Nabar Page 12
 3. Process modelling: The data objects defined in the data modelling phase are
transformed to achieve the information flow necessary to implement a business
function. Processing descriptions are created for adding, modifying, deleting, or
retrieving a data object.
4. Application generation: RAD assumes the use of fourth generation techniques.
Rather than creating software using conventional third generation programming
languages the RAD process works to reuse existing program components (when
possible) or create reusable components (when necessary). In all cases, automated tools
are used to facilitate construction of the software.
5. Testing and turnover: Since the RAD process emphasizes reuse, many of the program
components have already been tested. This reduces overall testing time. However, new
components must be tested and all interfaces must be fully exercised.

Like all process models, the RAD approach has drawbacks:

• For large but scalable projects, RAD requires sufficient human resources to create the right
number of RAD teams.
• RAD requires developers and customers who are committed to the rapid-fire activities
necessary to get a system complete in a much abbreviated time frame. If commitment is lacking
from either constituency, RAD projects will fail.
• Not all types of applications are appropriate for RAD.
• RAD is not appropriate when technical risks are high. This occurs when a new application
makes heavy use of new technology or when the new software requires a high degree of
interoperability with existing computer programs.

1.2.3 Evolutionary Process Models: Evolutionary models are iterative. They are
characterized in a manner that enables you to develop increasingly more complete versions of
the software.

1.2.3.1 The Prototyping Model: The prototyping paradigm (shown in figure 10) begins with
communication. You meet with other stakeholders to define the overall objectives for the
software, identify whatever requirements are known, and outline areas where further definition
is mandatory.
Prototyping iteration is planned quickly, and modelling in the form of a “quick design” occurs.
A quick design focuses on a representation of those aspects of the software that will be visible
to end users. The quick design leads to the construction of a prototype. The prototype is
deployed and evaluated by stakeholders, who provide feedback that is used to further refine
requirements.
Iteration occurs as the prototype is tuned to satisfy the needs of various stakeholders, while at
the same time enabling you to better understand what needs to be done.

Prototyping can be problematic for the following reasons:

1. Stakeholders see what appears to be a working version of the software, unaware that the
prototype is held together haphazardly, unaware that in the rush to get it working you haven't
considered overall software quality or long-term maintainability. When informed that the
product must be rebuilt so that high levels of quality can be maintained.
2. As a software engineer, you often make implementation compromises in order to get a
prototype working quickly. An inappropriate operating system or programming language may

Software Engineering (TE SEM V Computer Engineering)

By Radha Nabar Page 13
be used simply because it is available and known; an inefficient algorithm may be implemented
simply to demonstrate capability.
Although problems can occur, prototyping can be an effective paradigm for software
engineering. The key is to define the rules of the game at the beginning; that is, all stakeholders
should agree that the prototype is built to serve as a mechanism for defining requirements.

Figure 10: The prototyping model

1.2.3.2 The Spiral Model: Originally proposed by Barry Boehm, the spiral model is an
evolutionary software process model that couples the iterative nature of prototyping with the
controlled and systematic aspects of the waterfall model. It provides the potential for rapid
development of increasingly more complete versions of the software.
Boehm describes the model in the following manner:
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.
Using the spiral model, software is developed in a series of evolutionary releases. During early
iterations, the release might be a model or prototype. During later iterations, increasingly more
complete versions of the engineered system are produced.
A spiral model is divided into a set of framework activities defined by the software engineering
team. Each of the framework activities represent one segment of the spiral path illustrated in
Figure 10. As this evolutionary process begins, the software team performs activities that are
implied by a circuit around the spiral in a clockwise direction, beginning at the centre.
The first circuit around the spiral might result in the development of a product specification;
subsequent passes around the spiral might be used to develop a prototype and then
progressively more sophisticated versions of the software.

Software Engineering (TE SEM V Computer Engineering)

By Radha Nabar Page 14
 Figure 11: A typical spiral model

The spiral model is a realistic approach to the development of large-scale systems and software.
Because software evolves as the process progresses, the developer and customer better
understand and react to risks at each evolutionary level. The spiral model uses prototyping as
a risk reduction mechanism but, more important, enables you to apply the prototyping approach
at any stage in the evolution of the product. It maintains the systematic stepwise approach
suggested by the classic life cycle but incorporates it into an iterative framework that more
realistically reflects the real world. The spiral model demands a direct consideration of
technical risks at all stages of the project and, if properly applied, should reduce risks before
they become problematic.
But it may be difficult to convince customers that the evolutionary approach is controllable. It
demands considerable risk assessment expertise and relies on this expertise for success. If a
major risk is not uncovered and managed, problems will undoubtedly occur.

1.2.4 Concurrent Model: The concurrent development model, sometimes called concurrent
engineering, allows a software team to represent iterative and concurrent elements of any of
the process models described in this chapter. For example, the modeling activity defined for
the spiral model is accomplished by invoking one or more of the following software
engineering actions: prototyping, analysis, and design.

Figure 12 provides a schematic representation of one software engineering activity within the
modeling activity using a concurrent modeling approach. The activity—modeling—may be in
any one of the states12 noted at any given time. All software engineering activities exist
concurrently but reside in different states.

For example, early in a project the communication activity has completed its first iteration and
exists in the awaiting changes state. The modelling activity (which existed in the inactive state
while initial communication was completed, now makes a transition into the under
development state. If, however, the customer indicates that changes in requirements must be
made, the modeling activity moves from the under development state into the awaiting changes

Software Engineering (TE SEM V Computer Engineering)

By Radha Nabar Page 15
state. Concurrent modeling defines a series of events that will trigger transitions from state to
state for each of the software engineering activities, actions, or tasks.
Concurrent modeling is applicable to all types of software development and provides an
accurate picture of the current state of a project. Rather than confining software engineering
activities, actions, and tasks to a sequence of events, it defines a process network. Each activity,
action, or task on the network exists simultaneously with other activities, actions, or tasks.
Events generated at one point in the process network trigger transitions among the states.

Figure 12: One element of Concurrent process Model

1.3 Agile process model: Any agile software process is characterized in a manner that
addresses a number of key assumptions about the majority of software projects:
1. It is difficult to predict in advance which software requirements will persist and which will
change. It is equally difficult to predict how customer priorities will change as the project
proceeds.
2. For many types of software, design and construction are interleaved. That is, both activities
should be performed in tandem so that design models are proven as they are created. It is
difficult to predict how much design is necessary before construction is used to prove the
design.
3. Analysis, design, construction, and testing are not as predictable as we might like.

Software Engineering (TE SEM V Computer Engineering)

By Radha Nabar Page 16
 Figure 13: Agile Model

Agility Principles: The Agile Alliance defines 12 agility principles for those who want to
achieve agility:
1. Our highest priority is to satisfy the customer through early and continuous delivery of
valuable software.
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 to the 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 get the job done.
6. The most efficient and effective method of conveying information to and within a
development team is face-to-face conversation.
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 behaviour accordingly.

1.3.1 Extreme Programming (The XP Process): Extreme Programming uses an object-

oriented approach as its preferred development paradigm and encompasses a set of rules and
practices that occur within the context of four framework activities: planning, design, coding,
and testing. Figure illustrates the XP process and notes some of the key ideas and tasks that are
associated with each framework activity. Key XP activities are summarized in the paragraphs
that follow:
1. Planning: The planning activity begins with listening a requirements gathering activity
that enables the technical members of the XP team to understand the business context
for the software and to get a broad feel for required output and major features and

Software Engineering (TE SEM V Computer Engineering)

By Radha Nabar Page 17
 functionality. Listening leads to the creation of a set of “stories” (also called user
stories) that describe required output, features, and functionality for software to be built.
2. Design: XP design rigorously follows the KIS (keep it simple) principle. A simple
design is always preferred over a more complex representation. In addition, the design
provides implementation guidance for a story as it is written nothing less, nothing more.
The design of extra functionality (because the developer assume is discouraged.
3. Coding: After stories are developed and preliminary design work is done, the team
does not move to code, but rather develops a series of unit tests that will exercise each
of the stories that is to be included in the current release. Once the unit test has been
created, the developer is better able to focus on what must be implemented to pass the
test. A key concept during the coding activity is pair programming. XP recommends
that two people work together at one computer workstation to create code for a story.
This provides a mechanism for real-time problem solving and real-time quality
assurance.
4. Testing: The unit tests that are created should be implemented using a framework that
enables them to be automated. XP acceptance tests, also called customer tests, are
specified by the customer and focus on overall system features and functionality that
are visible and reviewable by the customer. Acceptance tests are derived from user
stories that have been implemented as part of a software release.

Figure 14: The Extreme Programming Process

1.3.2 Scrum: Scrum (the name is derived from an activity that occurs during a rugby match)
is an agile software development method that was conceived by Jeff Sutherland and his
development team in the early 1990s. In recent years, further development on the Scrum
methods has been performed by Schwaber and Beedle.
Scrum principles are consistent with the agile manifesto that incorporates the following
framework activities: requirements, analysis, design, evolution, and delivery. The overall flow
of the Scrum process is illustrated in following figure.
Scrum emphasizes the use of a set of software process patterns that have proven effective for
projects with tight timelines, changing requirements, and business criticality. Each of these
process patterns defines a set of development activities:

Software Engineering (TE SEM V Computer Engineering)

By Radha Nabar Page 18
 1. Backlog: a prioritized list of project requirements or features that provide business
value for the customer. Items can be added to the backlog at any time. The product
manager assesses the backlog and updates priorities as required.
2. Sprints: consist of work units that are required to achieve a requirement defined in the
backlog that must be fit into a predefined time-box (typically 30 days). Changes (e.g.,
backlog work items) are not introduced during the sprint. Hence, the sprint allows team
members to work in a short-term, but stable environment.
3. Scrum meetings: are short (typically 15-minute) meetings held daily by the Scrum
team. Three key questions are asked and answered by all team members:
• What did you do since the last team meeting?
• What obstacles are you encountering?
• What do you plan to accomplish by the next team meeting?
A team leader, called a Scrum master, leads the meeting and assesses the responses
from each person. The Scrum meeting helps the team to uncover potential problems as
early as possible.
4. Demos: deliver the software increment to the customer so that functionality that has
been implemented can be demonstrated and evaluated by the customer. It is important
to note that the demo may not contain all planned functionality, but rather those
functions that can be delivered within the time-box that was established.

Figure 15: Scrum Process Flow

Software Engineering (TE SEM V Computer Engineering)

By Radha Nabar Page 19
 Figure 16: Scrum Process flow

1.3.3 Kanban: Kanban is a Japanese word that literally means “visual card”. Kanban cards
were originally used in Toyota to limit the amount of inventory tied up in “work in progress”
on a manufacturing floor. Kanban not only reduces excess inventory waste, but also the time
spent in producing it.

Figure 17: Kanban Board

Kanban term came into existence using the flavors of “visual card,” “signboard,” or
“billboard”, “signaling system” to indicate a workflow that limits Work In Progress (WIP).
Kanban has been used in Lean Production for over half-century.
The core concept of Kanban includes:
1. Visualize Workflow: Split the entire work into defined segments or states, visualized
as named columns on a wall. Write each item on a card and put in a column to indicate
where the item is in the workflow.
2. Limit WIP: Assign explicit limits to how many items can be in progress at each
workflow segment / state. i.e., Work in Progress (WIP) is limited in each workflow
state.

Software Engineering (TE SEM V Computer Engineering)

By Radha Nabar Page 20
 3. Measure the Lead Time: Lead Time, also known as cycle time is the average time to
complete one item. Measure the Lead Time and optimize the process to make the Lead
Time as small and predictable as possible.

Benefits of Kanban:
1. Bottlenecks become clearly visible in real-time. This leads people to collaborate to
optimize the whole value chain rather than just their part.
2. Useful for situations where operations and support teams have a high rate of uncertainty
and variability.
3. Tends to spread throughout the organization naturally, including sales and
management. This increases visibility of everything that is going on at the company.
4. Reduces inventory in the range of 25%-75%, thereby reducing company costs.
5. Since all segments/states in the workflow are visually organized, the required items,
reducing the wait times and ensuring speed, continually support all the tasks in the
workflow.
6. Overproduction of inventory is avoided, thereby saving resources and time as well. This
is termed as eliminating waste.

Characteristics of Kanban:
1. Flexibility in Planning: Kanban provides improvements in the workflow. With visual
representation of the workflow, speed of moving from one task to another is reduced.
This is accomplished through the creation of clearly marked flow lanes, Kanban cards
and clearly marked columns to indicate where each item is in the workflow. This allows
a. Sufficient duration for longer tasks that cannot be broken down logically.
b. Preservation of value of such longer tasks.
c. Effort required by each role to be expended.
d. Continuous flow of the tasks that are completed without wait time.

2. Limits Work-In-Progress (WIP): Explicit limits are assigned to number of items that
can be in progress at each workflow state, indicated by a column. This allows
a. Reducing wait time.
b. Avoiding stress on resources at a workflow state.
c. Identifying bottlenecks causing an item to be in a workflow state than the
anticipated time (usually average cycle time) immediately.
d. Resolving bottlenecks with collaboration of the entire team.
e. Decreasing dependencies in completing a task by splitting it into sub-tasks, so
that the sub-task is tracked independently.

3. Pull Approach: When you have two teams and the first one is performing better than
the second one, it is likely that it pushes more work than the other can actually handle.
This often creates friction between the teams. A solution to this is the Pull approach. In
Pull Approach, the next team pulls work only when it is ready for it. Pull Approach is
implemented by adding a buffer with limited capacity between the two teams. The
benefits of Pull Approach are
a. Avoids piling-up of work.
b. Reduces wait time.
c. Facilitates a team to maintain constant pace and focus on quality.
d. Provides resource balancing.

Software Engineering (TE SEM V Computer Engineering)

By Radha Nabar Page 21
 4. Minimize Cycle Time: The cycle time for each task is measured and the process is
optimized to reduce the cycle times.
a. The bottlenecks are identified immediately and resolved collaboratively by the
entire team.
b. The correction loops are considered to reduce rework.

5. Continuous Delivery: Benefits of continuous delivery are

a. Short release cycles result in continuous delivery of growing product at regular
intervals.
b. Continuous interactions with the customer.
i. To understand what customer wants.
ii. Not to produce anything that the customer does not need. o Feedback on
delivered modules.
c. Limited requirements in each release cycle.
i. Developers are not overloaded with requests. This enables them to focus
on the delivery.
ii. There is no partially completed work.
d. Focus is on finishing work than on starting work.
i. This enables focus on sustaining pace and quality of the product.
ii. Deliver before the customer changes mind.
e. Optimize flow of Work from beginning to end.
i. Helps in incremental process improvements.

6. Visual Metrics: Visually organized workflows (on Kanban Boards) facilitate

a. Scheduling as per WIP limits on a workflow state.
b. Tracking status and progress continually.
c. Assigning resources dynamically based on the role requirements.
Advantages of Visual Metrics: Each day, for each column, mark how many tasks are in
it, you will see a mountain-like chart. This chart shows the past performance and allows
predicting future results.

Figure 18: Visual metrics

Software Engineering (TE SEM V Computer Engineering)
By Radha Nabar Page 22
 You can gather the following information from the chart –
1. Measure cycle time for each feature (or story) by marking a start date when the feature
is scheduled and an end date when the feature finishes.
2. Evaluate the quality of the growing product from technical, functional and user
perspectives at regular time-boxes.
3. Evaluate the pace of development by looking at the number of development items
completed and looking at the average cycle time per development item.
4. Adjust the pace of development by calculating the ratio of developer days per
completed development item. You can use this ratio to estimate the completion time for
the yet-to-develop items and adjust the development plan as necessary.
5. Evaluate and adjust the process by using a collaborative session to identify changes that
can be made to improve the quality of the product, or to improve the pace of
development.
6. Identify and resolve un-validated decisions by looking at the cycle time of validated
decisions and focusing on the correction loops that are usually the invisible backed-up
queues.

7. Efficiency through Focus: By focusing on what a customer wants, the scope becomes
clear. The focus is on delivering value to the customer. Efficiency can be achieved in
the following ways
a. A customer’s expectations can be made realistic and focused with continuous
interactions with the customer.
b. Focus on the tasks is ensured with a limit on work-in-progress (WIP).
c. The Pull approach enables resources to complete the tasks at hand before a new
task is taken up.
d. Optimizing lead-time (cycle time) results in faster delivery.
e. Visualization of the workflow with Kanban board draws immediate attention to
any bottlenecks that can be resolved immediately.
f. Empowerment of the team makes the team accountable for the success

Kanban and Scrum - Similarities

Similarities between Kanban and Scrum are
1. Both are Agile.
2. Both use pull scheduling.
3. Both limit WIP, Kanban at task level and Scrum at sprint level.
4. Both use transparency across the development.
5. Both focus on delivering releasable software early.
6. Both are based on self-organizing teams.
7. Both require breaking the work into pieces.
8. In both the methods, the release plan is continuously optimized based on empirical data
(Scrum – Velocity, Kanban - Lead Time/Cycle Time).

Software Engineering (TE SEM V Computer Engineering)

By Radha Nabar Page 23
Kanban and Scrum – Differences
SrNo Scrum Kanban
1 Scrum prescribes roles. In kanban roles are optional.
2 Product backlog is to be prioritized. Prioritization is optional
3 Sprints are to be time-boxed. You can Time-boxed iterations are optional.
choose the length of the sprint, but once
chosen, the same length is to be
maintained for all the sprints.
4 Scrum team needs to commit to a particular Commitment is optional.
amount of work for the sprint.
5 Cross-functional teams are prescribed. Cross-functional teams are optional.
Specialist teams are allowed.
6 Uses velocity as default metric for Uses lead time (cycle time) as default
planning and process improvement. metric for planning and process
improvement.
7 Items such as stories, tests must be No particular item size is prescribed.
broken down so that they can be
completed within one sprint.
8 Sprint backlog shows what tasks are to be Tasks are defined at workflow level.
executed during the current sprint. These WIP is limited per workflow state.
tasks are displayed on Scrum board.
Scope of the sprint is fixed. WIP is
limited per unit of time (WIP limit is the
velocity).
9 Additions/Changes cannot be done Additions/ Changes can be done if WIP
within a sprint. limit is not crossed.
10 New Scrum board is set at the beginning Kanban board is persistent.
of every sprint.
11 Daily meetings need to be conducted. Daily meetings are optional.
12 Burn-down charts are prescribed. No particular chart is prescribed.

Software Engineering (TE SEM V Computer Engineering)

By Radha Nabar Page 24