22CS602 OBJECT ORIENTED SOFTWARE ENGINEERING

UNIT I PRODUCT AND PROCESS

The Nature of Software – Defining the Discipline – The Software Process – Process models –
Prescriptive Process Models – Product and Process – Agility and Process – What is an Agile
Process?– Scrum– Other Agile Framework – Kanban – DevOps

INTRODUCTION TO SOFTWARE ENGINEERING

Engineering – Application of science, tools and methods to find a cost- effective solution
to the given [Link] uses scientific principles to design and build machines, structures,
and other things, including bridges, roads, vehicles, buildings or a software :
civil/electrical/mechanical/software engineering.
Analogy-Think of delegating a 30 storey complex building construction to a petty
contractor who lacks basic systematic principles. The failure might come in several forms—
the building might collapse during the construction stage itself due to his ignorance of the
basic theories concerning the strengths of materials; the construction might get unduly
delayed, since he may not prepare proper estimates and detailed plans regarding the
types and quantities of raw materials required, the times at which these are required, etc.
In short, to be successful in constructing a building of large magnitude, one needs a good
understanding of various civil and architectural engineering techniques such as analysis,
estimation, prototyping, planning,designing, and testing. Similar is the case with the
software development projects.
Software engineering discusses the systematic and cost-effective techniques for
software development.

Why study Software Engineering?

• To acquire skills to develop large programs
o Exponential growth in complexity and difficulty level with size
• Ability to solve complex programming problems
o How to break large projects into smaller and manageable parts?
o Learn techniques of:
o Specification, design, interface development, testing, project management etc.,
• To acquire skills to be a better programmer:
o Higher productivity
o Better Quality Program
Goals of Software Engineering:

The primary goal of software engineering is to improve the quality of

software products and to increase the productivity and job satisfaction of
13
software engineers.
1.11 THE NATURE OF SOFTWARE:

DEFINING THE SOFTWARE SOFTWARE APPLICATION DOMAINS

▪ SYSTEM SOFTWARE
▪ APPLICATION SOFTWARE
▪ ENGINEERING/SCIENTIFIC SOFTWARE
▪ EMBEDDED SOFTWARE
▪ PRODUCT-LINE SOFTWARE
▪ WEB-APPLICATIONS
▪ ARTIFICIAL INTELLIGENCE SOFTWARE
THE CHANGING NATURE OF SOFTWARE:
▪ WEB APPS
▪ MOBILE APPLICATION
▪ CLOUD COMPUTING
▪ PRODUCT LINE SOFTWARE

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

❑ Steps involved-

❑ Software- plays dual role

1. As a Product Eg-Ms office,Games
2. As a vehicle or a means to extract the potential of a product
Eg-OS,drivers,networking software,video editing software,Anti virus

14
❑ Delivers information-

• It transforms personal data (e.g., an individual’s financial transactions)

that the data can be more useful in a local context
I•t manages business information to enhance [Link]-Busines
Analytic tools-Tableau
I•t provides a gateway to worldwide information networks Eg-Internet
I•t also provides a vehicle that can threaten personal privacy and a gateway that
enables those with malicious intent to commit criminal [Link]-
virus,malware

❑ Software can be determinate or indeterminate

• Determinate -if the order and timing of inputs, processing, and outputs
is predictable. Eg. Microsoft Excel, many filter functions in image-editing
software like Photoshop, and media players such as VLC
• Indeterminate if the order and timing of inputs, processing, and outputs
cannot be predicted in advance. Eg Multiuser application-Ticket booking app

❑ Software is a logical rather than a physical system element

H/w wears out but —software doesn’t wear out. But it does deteriorate!
Figure 1.1 depicts failure rate as a function of time for hardware. The
relationship, often called the “bathtub curve,” indicates that hardware exhibits
relatively high failure rates early in its life (these failures are often
attributable to design or manufacturing defects).
Defects are then corrected, and failure rate drops to a steady-state level
(hopefully, quitelow) for some period of time. As time passes, however, the
failure rate rises again as hardware components suffer from the cumulative
affects of dust, vibration, abuse, temperature extremes , and many other
environmental maladies. Stated simply, the hardware begins to wear out.

Figure 1.1:
15
Failure curve for
hardware
Software is not susceptible to the environmental maladies that cause hardware to wear
out. In theory, therefore, the failure rate curve for software should take the form of the
“idealized curve” shown in Figure 1.2.
Undiscovered defects will cause high failure rates early in the life of a program.
However, these are corrected (hopefully, without introducing other errors), and the curve
flattens as shown. The idealized curve is a gross oversimplification of actual failure
models for software. However, the implication is clear—software doesn’t wear out. But it
does deteriorate!

This seeming contradiction can best be explained by considering the “actual curve” in
Figure 1.2. During its life, software will undergo change. As changes are made, it is likely
that errors will be introduced, causing the failure rate curve to spike as shown in Figure
1.2. Before the curve can return to the original steady-state failure rate, another change
is requested, causing the curve to spike again. Slowly, the minimum failure rate level
begins to rise— the software is deteriorating due to change.

Figure 1.2: Failure curve for software

Another aspect of wear illustrates the difference between hardware and software. When
a hardware component wears out, it is replaced by a spare part. There are no software
spare parts. Every software failure indicates an error in design or in the process through
which design was translated into machine-executable code. Therefore, software
maintenance involves considerably more complexity than hardware maintenance. 16
1.1.1SOFTWARE APPLICATION DOMAINS:
Seven broad categories of computer software present continuing challenges for
software engineers:
[Link] 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,)
process largely indeterminate data.
[Link] 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” or data
science programs that range from astronomy to volcanology, from automotive stress
analysis to orbital dynamics, from computer-aided design to consumer spending habits,
and 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., key pad control for a micro
wave oven)
5. Product-line software. Composed of reusable components and designed to
provide specific capabilities for use by many different customers. It may focus
on a limited and esoteric marketplace (e.g., inventory control products) or attempt
to address the mass consumer market.
[Link]/mobile applications. This network-centric software category spans a
wide array of applications and encompasses browser-based apps, cloud computing,
service-based computing, and software that resides on mobile devices.
[Link] intelligence software. Makes use of heuristics to solve complex
problems that are not amenable to regular computation or straightforward
analysis.
Applications within this area include robotics, decision-making systems, pattern
recognition (image and voice), machine learning, theorem proving, and game
playing.
 1.1.2 Legacy Software

Legacy software systems . . . were developed decades ago and have been continually modified to
meet changes in business requirements and computing platforms. The proliferation of such systems is
causing headaches for large organizations who find them costly to maintain and risky to evolve.

legacy systems often evolve for one or more of the following reasons:
∙ The software must be adapted to meet the needs of new computing environments or technology.
∙ The software must be enhanced to implement new business requirements.
∙ The software must be extended to make it work with other more modern
systems or databases.
∙ The software must be re-architected to make it viable within an evolving
computing environment
1.2 Defining the Discipline
The IEEE [IEE17] has developed the following definition for software engineering:
Software Engineering: The application of a systematic, disciplined, quantifiable approach to the
development, operation, and maintenance of software; that is, the application of engineering to
software

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 tools provide automated or semi-automated support for the process and the
methods
 1.3 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
1.3.1 The 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
Communication. Before any technical work can commence, it is critically
important to communicate and collaborate with the customer (and other
stakeholders).
The aim is to understand stakeholders’ objectives for the project and to
gather requirements that help define software features and functions.
Planning.: . 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
Modeling. a “sketch” of the thing .If required, you refine the sketch into greater and
greater detail in an effort to better understand the problem and how you’re going to
solve it.
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.
Deployment. The software (as a complete entity or as a partially completed increment)
is delivered to the customer who evaluates the delivered product and provides feedback
based on the evaluation
1.3.2. Umbrella Activities
Software engineering process framework activities are complemented by a number of
umbrella activities. 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:
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.
Risk management. Assesses risks that may affect the outcome of the project or
the quality of the product.
Software quality assurance. Defines and conducts the activities required to
ensure software quality.
Technical reviews. Assess software engineering work products in an effort to
uncover and remove errors before they are propagated to the next activity.
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.
Software configuration management. Manages the effects of change throughout the
software process.
Reusability management. Defines criteria for work product reuse (including
software components) and establishes mechanisms to achieve reusable
components.
Work product preparation and production. Encompasses the activities
required to create work products such as models, documents, logs, forms, and
lists

1.3.3 Process Adaptation

Therefore, a process adopted for one project might be significantly different than
a process adopted for another project. Among the differences are:
∙ Overall flow of activities, actions, and tasks and the interdependencies among
them
∙ Degree to which actions and tasks are defined within each framework activity
∙ Degree to which work products are identified and required
∙ Manner in which quality assurance activities are applied
∙ Manner in which project tracking and control activities are applied
∙ Overall degree of detail and rigor with which the process is described
∙ Degree to which the customer and other stakeholders are involved with the
project
∙ Level of autonomy given to the software team
∙ Degree to which team organization and roles are prescribed

1.4. SOFTWARE PROCESS

[Link] SOFTWARE PROCESS MODEL
The software process is represented schematically in Figure 2.1. Referring to the
figure, each framework activity is populated by a set of software engineering
actions. Each software engineering action is defined by a task set that identifies
the work tasks that are to be completed, the work products that will be produced,
the quality assurance points that will be required, and the milestones that will be
used to indicate progress
A
process flow—describes how the framework activities and the actions and
tasks that occur within each framework activity are organized with respect to
sequence and time. It is illustrated in Figure
A linear process flow executes each of the five framework activities in
sequence, beginning with communication and culminating with deployment (F
An iterative process flow repeats one or more of the activities before
proceeding to the next
An evolutionary process flow executes the activities in a “circular”
manner. Each circuit through the five activities leads to a more complete
version of the software .
A parallel process flow executes one or more activities in parallel with other
activities (e.g., modeling for one aspect of the software might be executed in
parallel with construction of another aspect of the software).

Defining a Framework Activity

software team would need significantly more information

before it could properly execute any one of these activities as part of the
software process.
Therefore, you are faced with a key question: What actions are appropriate
for a framework activity, given the nature of the problem to be solved, the
characteristics of the people doing the work, and the stakeholders who are
sponsoring the project?
communication activity might encompass little more than a phone call or e-
mail with the appropriate stakeholder.
Therefore, the only necessary action is phone conversation, and the work
tasks (the task set) that this action encompasses are:
1. Make contact with stakeholder via telephone.
2. Discuss requirements and develop notes.
3. Organize notes into a brief written statement of requirements.
4. E-mail to stakeholder for review and approval.
If the project was considerably more complex with lots of stakeholders, each
with a different set of (sometimes conflicting) requirements, the
communication activity might have six distinct actions: inception, elicitation,
elaboration, negotiation, specification, and validation.
1.4PRESCRIPTIVE PROCESS MODELS

A prescriptive model prescribes how a new software system should be developed. It

strives for structure and order of the software development activities.

1.4.1WATERFALL LIFE CYCLE MODEL:

Sometimes called as The Classic Life Cycle model

Suggests a systematic, sequential approach to software development
Begins with customer specification of requirements and progresses through
planning, modeling, construction, and deployment, culminating in ongoing support of the
completed software.

Figure : The software life cycle

The waterfall model, sometimes called the linear sequential model, suggests a
systematic, sequential approach to software development that begins with customer.
specification of requirements and progresses through planning, modeling, construction,
and deployment, culminating in ongoing support of the completed software

27
The waterfall model is the oldest paradigm for software engineering. However, over
the past five decades, criticism of this process model has caused even ardent supporters to
question its efficacy. Among the problems that are sometimes encountered when
the waterfall model is applied are:
1. Real projects rarely follow the sequential work flow that the model proposes.
2. It is often difficult for the customer to state all requirements explicitly at the
beginning of most projects.
3. The customer must have patience because a working version of the
program(s) will not be available until late in the project time span.
4. Major blunders may not be detected until the working program is reviewed.
Today, software work is fast paced and subject to a never-ending stream of changes
(to features, functions, and information content). The waterfall model is often inappropriate for
such work

1.4.2. Prototyping Process Model

Often, a customer defines a set of general objectives for software but does not identify detailed
requirements for functions and features. In these, and many other situations, a prototyping
paradigm may offer the best approach.
Although prototyping can be used as a stand-alone process model, it is more commonly used as a
technique that can be implemented within the context of any one of the process models.
For example, a fitness app developed using incremental prototypes might deliver the basic user
interface screens needed to sync a mobile phone with the fitness device and display the current
data; the ability to set goals and store the fitness device data on the cloud might be included in
the second prototype, creating and modifying the user interface screens based on customers
feedback; and a third prototype might include social media integration to allow users to set fitness
goals and share progress toward them with a set of friends.
The prototyping paradigm begins with communication. 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.
A prototyping iteration is planned quickly, and modeling (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 (e.g., human interface layout or output display formats).
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
The prototyping paradigm

prototyping can be problematic for the following reasons

1. Stakeholders see what appears to be a working version of the software. They

may be unaware that the prototype architecture (program structure) is also
evolving. This means that the developers may not have considered the overall
software quality or long-term maintainability.
2. As a software engineer, you may be tempted to make implementation compromises
to get a prototype working quickly. If you are not careful, these less than-ideal choices
have now become an integral part of the evolving system
1.4.3 Evolutionary Process Model
Software, like all complex systems, evolves over time. Business and product
requirements often change as development proceeds, making a straight-line path to
an end product unrealistic.
Tight market deadlines may make completion of a comprehensive software product
impossible .Barry Boehm [Boe88], 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. 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 . 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
center. Risk is considered as each revolution is made.
Anchor point milestones—a combination of work products and conditions that are
attained along the path of the spiral—are noted for each evolutionary pass

A TYPICAL SPIRAL MODEL

The first circuit around the spiral (beginning at the inside streamline nearest the
center, as shown in Figure ) 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.
Each pass through the planning region results in adjustments to the project plan.
Cost and schedule are adjusted based on feedback derived from the customer
after delivery. In addition, the project manager adjusts the planned number of
iterations required to complete the software the spiral model can be adapted to
apply throughout the life of the computer software.
The spiral model a realistic approach to the development of large-scale systems
and software. It uses prototyping as a risk reduction mechanism. 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.

The spiral model is not a panacea. It may be difficult to convince customers

(particularly in contract situations) 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.

The intent of evolutionary models is to develop high-quality software in an

iterative or incremental manner. However, it is possible to use an evolutionary
process to emphasize flexibility, extensibility, and speed of development. The
challenge for software teams and their managers is to establish a proper balance
between these critical project and product parameters and customer satisfaction
(the ultimate arbiter of software quality).

1.4.4 Unified Process Model

The Unified Process recognizes the importance of customer communication and

streamlined methods for describing the customer’s view of a system (the use
case)
It emphasizes the important role of software architecture and “helps the
architect focus on the right goals, such as understandability, reliance to
future changes, and reuse” [Jac99].
It suggests a process flow that is iterative and incremental, providing the
evolutionary feel that is essential in modern software development.
UML, the unified modeling language, was developed to support their work. UML
contains a robust notation for the modeling and development of object-oriented
systems and has became a de facto industry standard for modeling software of all
types
Figure depicts the “phases” of the Unified Process and relates them to the
generic activities.
The inception phase of the UP is where customer communication and planning
takes place. Fundamental business requirements are described through a set of preliminary use
cases that describe which features and functions each major class of users desires that will become
realized in the software architecture.
Planning identifies resources, assesses major risks, and defines a preliminary schedule for the
software increment
The Unified Process

The elaboration phase encompasses the planning and modeling activities of the generic process
model . Elaboration refines and expands the preliminary use cases and creates an architectural
baseline that includes five different views of the software—the use case model, the analysis model,
the design model, the implementation model, and the deployment model.8 Modifications to the plan
are often made at this time
The construction phase of the UP is identical to the construction activity
defined for the generic software process. All necessary and required features and
functions for the software increment (i.e., the release) are then implemented in
source code. As components are being implemented, unit tests are designed and
executed for each.
In addition, integration activities (component assembly and integration testing)
are conducted. Use cases are used to derive a suite of acceptance tests that are
executed prior to the initiation of the next UP phase.
The transition phase of the UP encompasses the latter stages of the generic
construction activity and the first part of the generic deployment (delivery and
feedback) activity. Software and supporting documentation is given to end users
for beta testing, and user feedback reports both defects and necessary changes.
At the conclusion of the transition phase, the software increment becomes a
usable software release.
The production phase of the UP coincides with the deployment activity of the
generic process. During this phase, the ongoing use of the software is monitored,
support for the operating environment (infrastructure) is provided, and defect
reports and requests for changes are submitted and evaluated

1.5 PRODUCT AND PROCESS

Some of the strengths and weaknesses of the process models we have discussed
are summarized

Comparing process models

1.6AGILITY AND PROCESS

Agility Introduction
Agility And The Cost Of Change
What Is An Agile Process?
Agility Principles
Advantages & Disadvantages Of Agile Development

AGILITY INTRODUCTION
The main point of this section is to introduce agility in the context of software
development. Agility is more than change management. Agility means that customers
and developers need to work together as collaborators on the development team and try
to build products that can be adapted to a rapidly changing market place. Part of this
adaptation is learning when and how to streamline the production of work products and
focus on the development of incremental operational prototypes.
A manifesto is normally associated with an emerging political movement-one that
attacks the old guard and suggests revolutionary change.
“We are uncovering better ways of developing software by doing it and helping
others do it. Through this work we have come to value:

Individuals and interactions over processes and tools Working

software over comprehensive documentation Customer collaboration
over contract negotiation

Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on
the
left more –Kent Beck et al.

AGILITY AND THE COST OF CHANGE

An agile process reduces the cost of change because software is released in increments
and change can be better controlled within an increment

39
AGILE PROCESS
An agile process is one that addresses following 3 assumptions
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. 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 (from a planning
point of view)

❖ Tomanage all these unpredictability, agile process permits Incremental

Adaptation

❖ Incremental adaptation is accomplished by Agile Team using Customer Feedback by

delivering a quick operational prototype.

Given these three assumptions, an important question arises:

How do we create a process that can manage unpredictability?

The answer, as we have already noted, lies in process adaptability (to rapidly changing
project and technical conditions).
An agile process, therefore, must be adaptable. But continual adaptation without
forward progress accomplishes little. Therefore, an agile software process must adapt
incrementally. To accomplish incremental adaptation, an agile team requires customer
feedback (so that the appropriate adaptations can be made). An effective catalyst for
customer feedback is an operational prototype or a portion of an operational system.
Hence, an incremental development strategy should be instituted. Software increments
(executable prototypes or portions of an operational system) must be delivered in short
time periods so that adaptation keeps pace with change (unpredictability). This iterative
approach enables the customer to evaluate the software increment regularly, provide
necessary feedback to the software team, and influence the process adaptations that
are made to accommodate the feedback.

40
 1.6.1Agility Principles

The Agile Alliance [Agi17]2 defines 12 principles for those software organizations that
want to achieve agility. These principles are summarized in the paragraphs that follow.
Customer satisfaction is achieved by providing value through software that is
delivered to the customer as rapidly as possible.
To achieve this, agile developers recognize that requirements will change. They deliver
software increments frequently and work together with all stakeholders so that
feedback on their deliveries is rapid and meaningful.
An agile team is populated by motivated individuals, who communicate face-to face
and work in an environment that is conducive to high quality software development.
The team follows a process that encourages technical excellence and good design,
emphasizing simplicity—“the art of maximized the amount of work not done” [Agi17].
Working software that meets customer needs is their primary goal, and the pace and
direction of the team’s work must be “sustainable,” enabling them to work effectively
for long periods of time.
An agile team is a “self-organizing team”—one that can develop well-structured
architectures that lead to solid designs and customer satisfaction. Part of the team
culture is to consider its work introspectively, always with the intent of improving the
manner in which it addresses its primary goal

1.7 scrum
Scrum (the name is derived from an activity that occurs during a rugby match)3 is a
very popular agile software development method that was conceived by Jeff Sutherland
and his development team in the early 1990s
Scrum principles are consistent with the agile manifesto and are used to guide
development activities within a process that incorporates the following framework
activities: requirements, analysis, design, evolution, and delivery. Within each
framework activity, work tasks take place in a relatively short time-boxed4 period called
a sprint
Scrum process flow

The work conducted within a sprint (the number of sprints required for each
framework activity will vary depending on size of the product and its complexity) is
adapted to the problem at hand and is defined and often modified in real time by
the Scrum team
1 Scrum Teams and Artifacts The Scrum team is a self-organizing
interdisciplinary team consisting of a product owner, a Scrum master, and a small
(three to six people) development team. The principle Scrum artifacts are the
product backlog, the sprint backlog, and the code increment. Development
proceeds by breaking the project into a series of incremental prototype
development periods 2 to 4 weeks in length called sprints.
The product backlog is a prioritized list of product requirements or features that
provide business value for the customer. Items can be added to the backlog at any
time with the approval of the product owner and the consent of the development
team. The product owner orders the items in the product backlog to meet the most
important goals of all stakeholders. The product backlog is never complete while the
product is evolving to meet stakeholder needs. The product owner is the only
person who decides whether to end a sprint prematurely or extend the sprint if the
increment is not accepted
The sprint backlog is the subset of product backlog items selected by the product
team to be completed as the code increment during the current active sprint. The
increment is the union of all product backlog items completed in previous sprints and
all backlog items to be completed in the current sprints. The development team creates
a plan for delivering a software increment containing the selected features intended
to meet an important goal as negotiated with the product owner in the current sprint.
Most sprints are time-boxed to be completed in 3 to 4 weeks. How the development
team completes the increment is left up to the team to decide. The development team
also decides when the increment is done and ready to demonstrate to the product
owner. No new features can be added to the sprint backlog unless the sprint is cancelled
and restarted.
The Scrum master serves as facilitator to all members of the Scrum team. She runs
the daily Scrum meeting and is responsible for removing obstacles identified by team
members during the meeting. She coaches the development team members to help
each other complete sprint tasks when they have time available. She helps the product
owner find techniques for managing the product backlog items and helps ensure that
backlog items are stated in clear and concise terms.
[Link] Planning Meeting Prior to beginning, any development team works with the
product owner and all other stakeholders to develop the items in the product backlog. .
The product owner and the development team rank the items in the product backlog by
the importance of the owner’s business needs and the complexity of the software
engineering tasks (programming and testing) required to complete each of them.
Sometimes this results in the identification of missing features needed to deliver the
required functionality to the end users. Prior to starting each sprint, the product owner
states her development goal for the increment to be completed in the upcoming sprint.
The Scrum master and the development team select the items to move from to the
sprint backlog. The development team determines what can be delivered in the
increment within the constraints of the time-box allocated for the sprint and, with the
Scrum master, what work will be needed to deliver the increment. The development
team decides which roles are needed and how they will need to be filled
3. Daily Scrum Meeting
The daily Scrum meeting is a 15-minute event scheduled at the start of each
workday to allow team members to synchronize their activities and make plans for
the next24 hours. The Scrum master and the development team always attend the
daily Scrum. Some teams allow the product owner to attend occasionally.
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?
The 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. It is the Scrum master’s task to clear obstacles presented before the next
Scrum meeting if possible. These are not problem-solving meetings, those occur off-
line and only involve the affected parties. Also, these daily meetings lead to
“knowledge socialization” and thereby promote a self-organizing team structure.
Some teams use these meetings to declare sprint backlog items complete or done.
When the team considers all sprint backlog items complete, the team may decide to
schedule a demo and review of the completed increment with the product owner.
4 Sprint Review Meeting The sprint review occurs at the end of the sprint when
the development team has judged the increment complete. The sprint review is often
time-boxed as a 4-hour meeting for a 4-week sprint. The Scrum master, the
development team, the product owner, and selected stakeholders attend this review.
The primary activity is a demo of the software increment completed during the
sprint. It is important to note that the demo may not contain all planned
functionality, but rather those functions that were to be delivered within the time-box
defined for the sprint. The product owner may accept the increment as complete or
not. If it is not accepted, the product owner and the stakeholders provide feedback
to allow a new round of sprint planning to take place. This is the time when new
features may be added or removed from the product backlog. The new features may
affect the nature of the increment developed in the next sprint.
5 Sprint Retrospective Ideally, before beginning another sprint planning
meeting, the Scrum master will schedule a 3-hour meeting (for a 4-week sprint)
with the development team called a sprint retrospective. During this meeting the
team discusses: ∙ What went well in the sprint ∙ What could be improved ∙ What
the team will commit to improving in the next sprint The Scrum master leads the
meeting and encourages the team to improve its development practices to
become more effective for the next sprint. The team plans ways to improve
product quality by adapting its definition of “done.” At the end of this meeting,
the team should have a good idea about the improvements needed in the next
sprint and be ready to plan the increment at the next sprint planning meeting
1.8 OTHER AGILE FRAME WORKS

1.8.1 The XP Framework In this section we provide a brief overview of Extreme

Programming (XP), one of the most widely used approaches to agile software
development. Kent Beck [Bec04a] wrote the seminal work on XP. Extreme
Programming encompasses a set of rules and practices that occur within the
context of four framework activities: planning, design, coding, and testing.. The
key XP activities are summarized in the paragraphs that follow
Planning. The planning activity (also called the planning game) begins with a
requirements activity called listening. 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.
Each user story is written by the customer and is placed on an index card.
The customer assigns a value (i.e., a priority) to the story based on the overall
business value of the feature or function.
Members of the XP team then assess each story and assign a cost—measured in
development weeks—to it. It is important to note that new stories can be written
at any time
Customers and developers work together to decide how to group stories into the next
release (the next software increment) to be developed by the XP team. Once a basic
commitment (agreement on stories to be included, delivery date, and other project
matters) is made for a release, the XP team orders the stories that will be developed in
one of three ways:
(1) all stories will be implemented immediately (within a few weeks),
(2) the stories with highest value will be moved up in the schedule and implemented
first, or
(3) the riskiest stories will be moved up in the schedule and implemented first.

After the first project release (also called a software increment) has been delivered,
the XP team computes project velocity. Stated simply, project velocity is the number of
customer stories implemented during the first release. Project velocity can then be
used to help estimate delivery dates and schedule for subsequent releases. The XP
team modifies its plans accordingly
Design. XP design rigorously follows the KIS (keep it simple) principle. The
design of extra functionality (because the developer assumes it will be required
later) is discouraged.
XP encourages the use of CRC cards as an effective mechanism for
thinking about the software in an object-oriented context. CRC (class-
responsibility collaborator) cards identify and organize the object-oriented
classes that are relevant to the current software increment. CRC cards are the
only design work product produced as part of the XP process.
If a difficult design problem is encountered as part of the design of a story, XP
recommends the immediate creation of an operational prototype of that portion
of the design. A central notion in XP is that design occurs both before and after
coding commences. Refactoring—modifying/optimizing the code in a way that
does not change the external behavior of the software means that design
occurs continuously as the system is constructed. In fact, the construction
activity itself will provide the XP team with guidance on how to improve the
design.
Coding.. A key concept during the coding activity (and one of the most talked-
about aspects of XP) is pair programming. XP recommends that two people
work together at one computer to create code for a story. This provides a
mechanism for real-time problem solving (two heads are often better than one)
and real-time quality assurance (the code is reviewed as it is created). As pair
programmers complete their work, the code they develop is integrated with the
work of others. This “continuous integration” strategy helps uncover
compatibility and interfacing errors early.
Testing. The unit tests that are created should be implemented using a
framework that enables them to be automated (hence, they can be executed
easily and repeatedly). This encourages implementing a regression testing
strategy whenever code is modified (which is often, given the XP refactoring
philosophy). XP acceptance tests, also called customer tests, are specified by
the customer and focus on overall system features and functionality that are
PRINCIPLES BEHIND THE AGILE MANIFESTO
The Agile Alliance defines 12 agility principles for those who want to achieve agility:

[Link] satisfaction: Customers need to be satisfied with the quick delivery of the
product at the earliest.
[Link] change: Even if the change is late in the development process, it needs to be
addressed and handled as soon as possible.
[Link] frequently: The focus must be on the continuous delivery of software in a shorter
timescale.
[Link] together: Business units and developers need to work in tandem
throughout the project lifespan.
[Link] team: The projects need to have motivated team members. They must also be
trusted to get the work done.
[Link]-to-face: Conversations that take place face-to-face have maximum efficiency and
effectiveness.
[Link] software: The primary measure of progress is evaluated based on
the working software created.
[Link] pace: The agile process is greatly beneficial when it comes to sustainable
development.
[Link] design: Focusing on technological excellence and good design can significantly affect
agility.
[Link]: The amount of work not being done needs to be reduced via
simpler processes.
11. Self-organized: Self-organized teams end up providing the best architectures,
designs, and requirements.
[Link] and adjustment: At regular intervals, the team reflects on how
to become more effective, then tunes and adjusts its behavior accordingly.

Figure 1.17 Agiity

model
41
 1.9 KANBAN

The Kanban method is a lean methodology that describes methods for improving any
process or workflow. Kanban is focused on change management and service delivery.
Change management defines the process through which a requested change is
integrated into a software-based system. Service delivery is encouraged by focusing on
understanding customer needs and expectations. The team members manage the
work and are given the freedom to organize themselves to complete it. Policies evolve

as needed to improve outcomes.

Kanban originated at Toyota as a set of industrial engineering practices and was

adapted to software development by David Anderson [And16]. Kanban itself depends
on six core practices:
1. Visualizing workflow using a Kanban board (an example is shown in
Figure 3.4). The Kanban board is organized into columns representing the
development stage for each element of software functionality. The cards on
the board might contain single user stories or recently discovered defects on
sticky notes and the team would advance them from “to do,” to “doing,” and
“done” as the project progresses
2. Limiting the amount of work in progress (WIP) at any given time.
Developers are encouraged to complete their current task before starting
another. This reduces lead time, improves work quality, and increases the
team’s ability to deliver software functionality frequently to their
stakeholders.
3. Managing workflow to reduce waste by understanding the current value
flow, analyzing places where it is stalled, defining changes, and then
implementing the changes.
4. Making process policies explicit (e.g., write down your reasons for
selecting items to work on and the criteria used to define “done”).
5. Focusing on continuous improvement by creating feedback loops where
changes are introduced based on process data and the effects of the
change on the process are measured after the changes are made.
6. Make process changes collaboratively and involve all team members and
other stakeholders as needed

The team meetings for Kanban are like those in the Scrum framework. If
Kanban is being introduced to an existing project, not all items will start in
the backlog column.
Developers need to place their cards in the team process column by asking
themselves:
Where are they now? Where did they come from? Where are they going?
The basis of the daily Kanban standup meeting is a task called “walking the
board.” Leadership of this meeting rotates daily. The team members
identify any items missing from the board that are being worked on and
add them to the board. The team tries to advance any items they can to
“done.” The goal is to advance the high business value items first. The team
looks at the flow and tries to identify any impediments to
completion by looking at workload and risks
1.10 DevOps
DevOps was created by Patrick DeBois [Kim16a] to combine Development and
Operations. DevOps attempts to apply agile and lean development principles across the
entire software supply chain. Figure presents an overview of the DevOps workflow. The
DevOps approach involves several stages that loop continuously until the
desired product exists:
∙ Continuous development. Software deliverables are broken down and
developed in multiple sprints with the increments delivered to the quality
assurance members of the development team for testing
∙ Continuous testing. Automated testing tools15 are used to help team members
test multiple code increments at the same time to ensure they are free of
defects prior to integration.
∙ Continuous integration. The code pieces with new functionality are added
to the existing code and to the run-time environment and then checked to
ensure there are no errors after deployment.
∙ Continuous deployment. At this stage the integrated code is deployed
(installed) to the production environment, which might include multiple sites
globally that need to be prepared to receive the new functionality.
∙ Continuous monitoring. Operations staff who are members of the development team
help to improve software quality by monitoring its performance
in the production environment and proactively looking for possible problems
before users find them.
DevOps enhances customers’ experiences by reacting quickly to changes in their
needs or desires. This can increase brand loyalty and increase market share. Lean
approaches like DevOps can provide organizations with increased capacity to innovate
Dynamic System Development Method (DSDM)

Promoted by the DSDM Consortium

Dynamic System Development Method is an agile S/W development approach that

provides a framework for building and maintaining systems which meet tight time
constraints through the use of incremental prototyping in a controlled project
environment.

Borrows Pareto principle 80-20 rule—80 % of an application can be delivered in 20% of

the time it would take to deliver the complete (100 percent) application.
only enough work is required for each increment to facilitate movement to the next
increment. Remaining- on request.

DSDM life cycle starts with - Feasibility study and Business

study. DSDM defines 3 iterative cycles-

❖ Functional Model Iteration: Produce iterative prototypes.

❖ design and build iteration: Revisit prototyping to ensure operational business

value for end users.

❖ Implementation: Places the latest prototype into the operational environment

NOTE: (1) The increment may not be 100 percent complete

(2) changes may be requested as the increment is put into place

Agile Modeling (AM)

It is a collection of values, principles and practice for effective modeling and
documentation of software-based systems.
AM follows Agile Manifesto
The Agile modeling philosophy recognizes that an agile team must have the courage
to make decisions that may cause it to reject a design and refactor.
The team must also have the humility to recognize that technologists do not have
all the answers and that business experts and other stakeholders should be
respected and embraced.
AM suggests a wide array of “core” and “supplementary” modeling principles
that make AM unique !
Model with a purpose Use multiple models Travel light
Content is more important than representation
Know the models and the tools you use to create them Adapt locally.
A major segment of the software engineering community has adopted the Unified
Modeling Language (UML) as the preferred method for representing analysis and
design models.

48
 ASSIGNMENT
Category 1:
[Link] the main difference between a traditional (plan-driven)
process and an Agile process in one or two sentences. (K2 ,CO1)
2. "Software is not just a product but also a vehicle for delivering a
service." Explain this statement with a concrete example. . (K2 ,CO1)
3. List the three core roles in a Scrum team and the three primary
artifacts they create/manage. (K2 ,CO1)
Category 2:
[Link] why software is often said to be logical rather than
physical. Provide one example to support your explanation. (K2,CO1)
2. The Waterfall mod el is often described as a "linear-sequential"
model. What does this mean, and why is it difficult to go back to a
previous phase? (k2.CO1)
3. For a "Student Grade Calculator" software, differentiate between a
Product characteristic and a Process activity. (K2,CO1)
Category 3:
1.A client approaches you to build a simple, well-understood
system. Which prescriptive process model would be most suitable and
why? (K2,CO1)
2. For a university developing a new student portal, give one
example of a Product attribute and one example of a Process
activity. (K2,CO1)
3. From the Agile Manifesto, state two of the four value statements.
For one, explain what it means in practical terms. (K2,CO1)
Category 4:
1. What is the purpose of a Sprint Retrospective? What kind of
outcomes might come from this meeting? (K2,CO1)
[Link] does a Kanban board visually help a development team
manage its work? (K2,CO1)
3. Explain how the DevOps philosophy aims to break down the
Traditional”wall” between development and operations teams.
Provide an example of a practice that supports this.? (K2,CO1)

Category 5:
1. Design a simple Kanban board workflow for a bug-fixing
team, including at least four columns and suggest a WIP limit
for one of them, justifying your choice.? (K2,CO1)
2. A client’s requirements are vague and likely to change
frequently. Compare and contrast how a Waterfall team and a
Scrum team would handle this situation? (K2,CO1)
3. Design a simple Kanban board workflow for a bug-fixing
team, including at least four columns and suggest a WIP limit
for one of them, justifying your choice? (K2,CO1)
 PART-A

1. Define software engineering? (K1,CO1)

Ans: 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 discusses systematic and cost-effective techniques for
software development.
2. What is Software? (K1,CO1)
Ans: Software encompasses: (1) Set of computer programs to provide desired features,
function, and performance; (2) data structures that enable the programs to adequately
store and manipulate information and
(3) documentation that describes the operation and use of the programs

Program is a set of instructions and data to performs a specific task

3. What are the characteristics of a software? (K2,CO1)
Ans: Software plays a dual role- as a product and as a mean to extract the underlying
potential of a hardware

Delivers information-
Software can be determinate or indeterminate
Software doesn’t wear out but may deteriorate if not adapted to change.
Software is a logical rather than a physical system element- It is not manufactured
but engineered.
Other characterestics include,
Usability of Software Reusability of components Flexibility of software
Maintainability of software

Portability and Reliability of Software

4. What are the software layers? (K1,CO1)
Ans: Software engineering is a layered technology. The layers include Layer 1-
QualityLayer 2-Process Layer 3-Methods `Layer 4-Tools

53
QUALITY – bedrock supporting SE-organizational primary commitment

PROCESS-The foundation for software engineering is the process [Link] holds the
technology layers together

METHODS- It compasses technical details for building software-

Software engineering tools provide automated or semi-automated support for the
process and the methods.

5. Define Software Process Framework. (K1,CO1)

Ans: A software process framework 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.

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

6. What is a Generic process framework (K1,CO1)

Ans: A generic process framework for software engineering encompasses five activities:
[Link]
[Link]
[Link]
[Link]
[Link]
Communication –understanding stakeholders’ need

Planning –Route map-Software project plan - Describes technical tasks,risks,resources

required,work products to produce, schedule

Modeling-sketch -Models are used to understand something before building it .S/W Engr
creates models to understand the requirements and the design to achieve it

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.

Deployment - The software (as a complete entity or as a partially completed increment) is

delivered to the customer who evaluates the delivered product and provides feedback
based on the evaluation.

54
7. List 5 umbrella activities in the process framework. (K1,CO1)

Ans:Typical umbrella activities include:

• Software project tracking and control
• Risk management
• Software quality assurance
• Technical Reviews
• Measurement
• Software Configuration Management
• Reusability management
• Work product preparation and production
[Link] Process flow. (K1,CO1)
Ans:Describes how the framework activities, actions, and tasks are organized
w.r.t sequence and time.
Each of a variety of process models differs in the process
flow. Types:

a) Linear process flow

b) Iterative Process flow
c) Evolutionary Process flow
d) Parallel Process flow
[Link] Process Pattern (K1,CO1)
Ans:It describes the problems that is encountered during software
engineering process

Identifies the environment in which the problem has been encountered

It Suggests one or more proven solutions to the problem.

Types:
Stage pattern-defines problems in the Framework
Activity Eg: Establishing Communication
Task pattern- defines problems in the Action or Task
set Eg: Requirements Gathering

Phase pattern-defines the sequence of framework activities that occurs

within the process Eg: spiral or prototyping 55
[Link] are the pitfalls of the Classic life cycle model? (K2,CO1)
Ans:Real projects rarely follow the sequential flow that the model proposes.
It is often difficult for the customer to state all requirements explicitly that too in
the beginning of the project itself
A working version of the program(s) will not be available until late in the project time
span

Not good for long, complex and object oriented projects

High risk as problems are uncovered only at the testing phase-disastrous
effects. [Link] is the principle behind the Spiral Model? (K2,CO1)
Ans:Principles of spiral model are:
Risk driven process model - Risk is analyzed on each revolution using
prototyping Anchor point milestones [work products+ conditions attained] are noted for

each
evolutionary pass-Proper Documentation
12. What is an Anchor point milestone? (K1,CO1)
Anchor point milestones—a combination of work products and conditions that are attained
along the path of the spiral in the spiral model.

It ensures stakeholder commitment to feasible and mutually satisfactory

system solutions.

are noted for each evolutionary pass.

13. What is an Agile model? (K1,CO1)
Ans: Agile model model is a combination of iterative and incremental process models with
focus on process adaptability and customer satisfaction by rapid delivery of working
software product.

Agile Methods break the product into small incremental [Link] principle-To remove
unnecessary activities that waste time and effort.
14. When is an Agile Process used?. State 2 principles of agility. (K2,CO1)
Ans: Agile process is used when there is an
• Unpredictability on sustainable requirements
• Unpredictability on needed design before construction
• Unpredictability on Analysis, design, construction, and testing from a
planning point of view
Two Principles of Agility-
Customer satisfaction: Customers need to be satisfied with the quick delivery of the
product at the earliest.
Welcome change: Even if the change is late in the development process, it needs to 56
be addressed and handled as soon as possible.
15. What are the disadvantages of Agile methodologies (K2,CO1)

Effort required is unpredictable for large software deliverables.

Lack of formal documents leaves scope for confusion as it is not possible to
review the important design decisions
The project may turn up as an failure if customer representative is unclear. Only
senior programmers are capable of taking the kind of decisions required
during the development process disregarding the new comers..

16. what is a spike solution? What is the need for Refactoring? (K2,CO1)
Spike Solutions are the immediate recommendation of an operational prototype
by XP for difficult design problems encountered.
The intent is to lower risk when true implementation starts and to validate the
original estimates for the story containing the design problem.
Refactoring is the process of changing a software system in such a way that it
does not alter the external behavior of the code yet improves the internal
structure. It is a disciplined way to clean up code [and modify/simplify the
internal design] that minimizes the chances of introducing bugs

17. What are CRC cards? What is the use of it? (K2,CO1)
Ans: A Class Responsibility Collaborator (CRC) model is a collection of standard
index cards that have been divided into three sections-A class represents a
collection of similar objects, a responsibility is something that a class knows
or does, and a collaborator is another class that a class interacts with to fulfill
its responsibilities.

[Link] is an DSDM Agile [Link] its principle. (K1,CO1)

Ans:Dynamic System Development Method is an agile S/W development approach
that provides a framework for building and maintaining systems which meet tight
time constraints through the use of incremental prototyping in a controlled project
environment.

DSDM borrows modified Pareto principle of 80-20 rule.

80 % of an application can be delivered in 20% of the time it would take to deliver
the complete (100 percent) [Link] enough work is required for each
increment to facilitate movement to the next increment. Remaining- on request.

57
19. Define Sprints and Demos. (K2,CO1)
Ans: A sprint is part of the core components of the agile methodology. The term refers
to a predefined span of time (any period of length, usually shorter 1- weeks) in which
a team will work to accomplish a work product.

It consist of work units that are required to achieve a requirement defined in the
backlog that must be fi t into a predefined time-box.
Scrum meetings of 15 minute duration take place every 24 hours during the course of
sprint.
The work conducted within a sprint (the number of sprints required for each framework
activity will vary depending on product complexity and size) is adapted to the
problem at hand and is defined and often modified in real time by the Scrum team.
Demos:It 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.

20. Differentiate Product and Process. (K2,CO1)

The product is the final result of a development cycle.

The process is a sequence or set of steps that should be followed to create a
product.
Product development focus is on final outcome.
The process focuses on each step to be followed during software product development.
A product life cycle tends to be in the short term.
A process life cycle is generally long term.
The main goal of product development is to finish the work and get the product
delivered successfully.
The main goal of a process is to make a good quality products.

21. Scrum Vs Kanban (k2,CO1)

58