chapter 1: the software process -...

Chapter 1: The

Software Process

Slides by: Ms. Shree Jaswal

CHAPTER 1 Slides by:Ms. Shree Jaswal

Topics to be covered

Nature of Software, Software Definition, Software Characteristics, Software Application Domains

Generic view of Process,

Prescriptive Models: Waterfall Model, Incremental-RAD Model,

Evolutionary Process Model: Prototyping, Spiral and Concurrent Development Model,

Specialized Models: Component based, Aspect Oriented Development,

Agile Methodology: Scrum and Extreme Programming 2

Which Chapter? Which Book?

Chapter 1: Software and Software Engineering, Roger

Pressman, “ Software Engineering: A practitioner’s

Approach”, 7th Edition, Mc Graw Hill Publication

Chapter 2: Process Models, Roger Pressman, “ Software

Engineering: A practitioner’s Approach”, 7th Edition, Mc

Graw Hill Publication

Chapter 3: Agile Development, Roger Pressman, “

Software Engineering: A practitioner’s Approach”, 7th

Edition, Mc Graw Hill Publication

CHAPTER 1 Slides by:Ms. Shree Jaswal 3


Computer Software

It is the product that S/W engineers design

and build.

S/W engineers build it and virtually

everyone uses it either directly or indirectly.

Software might take following form:

1. Instructions (Computer programs)

2. Data structures

3. documents

4


Software Characteristics

It is developed or engineered, it is not

manufactured

It doesn’t wear out

Although industry is moving toward

component based assembly, most software

continues to be custom built

5

Wear vs. Deterioration



Software Applications

System

Application software

Real-time

Business

Engineering and scientific

Embedded

Web-based(WebApps)

Artificial intelligence7

Software—New Categories

Open world computing—pervasive, distributed computing

Ubiquitous computing—wireless networks

Netsourcing—the Web as a computing engine

Open source—”free” source code open to the computing

community (a blessing, but also a potential curse!)

Also …Data mining

Grid computing

Cognitive machines

Software for nanotechnologies


Legacy Software

Why must it change? software must be adapted to meet the needs

of new computing environments or technology.

software must be enhanced to implement new business requirements.

software must be extended to make it interoperable with other more modern systems or databases.

software must be re-architected to make it viable within a network environment.


Characteristics of WebApps - I

Network intensiveness. A WebApp resides on a network and must serve the needs of a diverse community of clients.

Concurrency. A large number of users may access the WebApp at one time.

Unpredictable load. The number of users of the WebAppmay vary by orders of magnitude from day to day.

Performance. If a WebApp user must wait too long (for access, for server-side processing, for client-side formatting and display), he or she may decide to go elsewhere.

Availability. Although expectation of 100 percent availability is unreasonable, users of popular WebApps often demand access on a “24/7/365” basis.


Characteristics of WebApps - II

Data driven. The primary function of many WebApps is to use hypermedia to present text, graphics, audio, and video content to the end-user.

Content sensitive. The quality and aesthetic nature of content remains an important determinant of the quality of a WebApp.

Continuous evolution. Unlike conventional application software that evolves over a series of planned, chronologically-spaced releases, Web applications evolve continuously.

Immediacy. Although immediacy—the compelling need to get software to market quickly—is a characteristic of many application domains, WebApps often exhibit a time to market that can be a matter of a few days or weeks.

Security. Because WebApps are available via network access, it is difficult, if not impossible, to limit the population of end-users who may access the application.

Aesthetics. An undeniable part of the appeal of a WebApp is its look and feel.



Software engineering

The economies of ALL developed nations are dependent on software

More and more systems are software controlled

Thus, the need for software engineering

Software engineering is the systematic approach to the development, operation, maintenance & retirement of software.

Software engineering is concerned with theories, methods and tools for professional software development

12


Software costs

Software costs often dominate system costs.

The costs of software on a PC are often

greater than the hardware cost

Software costs more to maintain than it does

to develop. For systems with a long life,

maintenance costs may be several times

development costs

Software engineering is concerned with

cost-effective software development13

Software engineering

The seminal definition:

[Software engineering is] the establishment and use

of sound engineering principles in order to obtain

economical software that is reliable and works

efficiently on real machines.

The IEEE definition:

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



Problems faced by SE

1. Problem of scale

2. Cost, schedule and Quality

3. Problem of consistency

15


Problem of Scale

Development of a very large system requires

a very different set of methods compared in

development of a small system, i.e. methods

that are used for developing small system

generally do not scale up to large systems

16


Cost, schedule and Quality

A persistent & consistent goal of SE is to

produce S/W cheaply. Cost is calculated in

terms of persons-month.

Schedule can be considered as an

independent variable whose value is more or

less fixed for a given cost. To meet market

needs the rapid development of S/W is

needed

Quality is the main “mantra” for successful

S/W product. Reliability is generally main

quality criteria.17


Problem of consistency

An organization involved in S/W development

doesn’t just want low cost and high quality for

a project but it wants these consistently.

In other words it wants consistent quality with

consistent productivity.

Consistency can be achieved by following

standardized procedures for developing

software.

18


Software Engg. Approach

It is : Develop methods & procedures for

software development that can scale up for

large systems and that can be used to

consistently produce high-quality software at

low cost and with a small cycle time, and

scalability

The S/W process must contain components

of project management in addition to

procedures for development

19



A] Phased development process:

To better manage the development process

& to achieve consistency it is essential that

S/W development be done in phases.

It generally consists of following activities:

1. Requirement specification for understanding

& clearly stating the problem

2. Design for deciding a plan for a solution

3. Coding for implementing planned solution

4. Testing for verifying the programs

20



B] Project management and Metrics

Project mgmt is done to ensure that each phase is being done properly, what the risks for the project are & how to mitigate them etc. so that the cost & quality objectives can be met.

S/W metrics are quantifiable measures that could be used to measure different characteristics of S/W system or S/W development process.

21



2 types of metrics used for software development are:

1. Product metrics: Are used to quantify characteristics of the product being developed i.e. software

2. Process metrics: Are used to quantify characteristics of the process used to develop the software. It measures productivity, cost & resource requirements, etc…

22


Software Process

SE is a layered technology.

Software Engineering

a “quality” focus

process model

methods

tools

23


Software Process

Quality focus: The bedrock that supports SE

Process Layer: It’s the foundation of SE. It defines a framework for a set of Key Process Areas (KPA’s) that must be established for effective delivery of SE technology.

Methods: Provide the technical how-to’s for building software.

Tools: Provide automated or semi-automated support for process & methods.

24


Software Process

Software process is a coherent set of activities for specifying, designing, implementing and testing software systems.

A S/W process is a set of activities together with ordering constraints among them, such that if the activities are performed properly and in accordance with ordering constraints, the desired result (high quality S/W at low cost) is produced.

25


Software Process

It is a structured set of activities required to develop a software system.

Fundamental generic activities:

1. Specification:what the system should do and its development constraints

2. Design: production of the software system

3. Validation: checking that the software is what the customer wants

4. Evolution: changing the software in response to changing demands

26


A Process Framework

Process framework

Framework activities

work tasks

work products

milestones & deliverables

QA checkpoints

Umbrella Activities

27


Framework Activities

Communication

Planning

Modeling

Analysis of requirements

Design

Construction

Code generation

Testing

Deployment

28


Umbrella Activities

Software project management

Formal technical reviews

Software quality assurance

Software configuration management

Work product preparation and production

Reusability management

Measurement

Risk management29


CMM

To determine an organization’s current state

of process maturity, the SEI (Software

Engineering Institute) uses an assessment

that results in 5-point grading scheme.

This scheme determines compliance with a

capability maturity model (CMM).

The 5 process maturity levels are defined as

follows:

30


CMM

Level 1:Initial – S/W processes are ad-hoc & chaotic. Few of them are defined & success depends on individual effort.

Level 2:Repeatable – Basic proj. mgmt. processes are established to track cost, schedule & functionality. Earlier successes can be repeated on projects with similar appl.

Level 3:Defined – S/W processes for both mgmt. & engg. activities is documented, standardized &integrated into an organizationwide S/W process. This level includes all characteristics defined for level 2.

31


CMM

Level 4:Managed – Detailed measures for

the S/W process & product quality are

collected. This level includes all

characteristics defined for level 3.

Level 5:Optimizing – Continuous process

improvement is enabled by quantitative

feedback from the process & from testing

innovative ideas & technologies.

32


Software Process Models

A simplified representation of a software process, presented from a specific perspective

Examples of process perspectives are

Workflow perspective - sequence of activities

Data-flow perspective - information flow

Role/action perspective - who does what

Generic process models

Waterfall

Evolutionary development

Formal transformation

Integration from reusable components33


Prescriptive model: The

Waterfall Model

Communicat ion

Planning

Modeling

Const ruct ionDeployment

analysis

designcode

t est

project init iat ion

requirement gat hering estimating

scheduling

tracking

delivery

support

f eedback

Also called classic life cycle or linear

sequential model.

34


The Waterfall Model

1. Analysis:

Requirement gathering is intensified.

Software analyst must understand the info domain for S/W as well as required fn., behavior, performance & interface.

2. Design:

This process translates requirements into a representation of S/W that can be assessed for quality before coding begins.

35


The Waterfall Model

3. Code generation: Design is translated into a machine readable from.

4. Testing: After coding testing begins. It focuses on – logical internals i.e ensuring that all statements have been tested and functional externals i.e to uncover errors & ensure that defined input will produce actual results that agree with required results.

5. Support: S/W support/maintenance is provided to client to accommodate some change or provide functional or performance enhancements.

36


Drawbacks of waterfall model

1. Real projects rarely follow sequential flow that model proposes

2. It requires that customer state all requirements explicitly which is often difficult for customer.

3. The customer must have patience as a working version of the program will not be available until late in project time span.

4. This model leads to “blocking states” in which some project team members must wait for other team members to complete dependent tasks. Thus time spent waiting is more than time spent doing productive work.

37


The Incremental Model

C o m m u n i c a t i o n

P l a n n i n g

M o d e l i n g

C o n s t r u c t i o n

D e p l o y m e n t

d e l i v e r y

f e e d b a c k

ana ly s is

des ign c ode

t es t

increment # 1

increment # 2

delivery of

1st increment

delivery of

2nd increment

delivery of

nt h increment

increment # n

project calendar t ime


P l a n n i n g

M o d e l i n g


D e p l o y m e n t

d e l i v e r y

f e e d b a c k

ana ly s is

des ign c ode

t es t


P l a n n i n g

M o d e l i n g


D e p l o y m e n t

d e l i v e r y

f e e d b a c k

ana ly s is

des ignc ode

t es t

38



It combines elements of linear sequential

model with iterative philosophy of prototyping.

It delivers S/W in small but usable pieces

called “increments”.

Each increment builds on those that have

already been delivered.

1st increment is often called a core product.

Core product is reviewed by customer based

on which modifications are made to it by

adding additional features & functionality.39



It is useful when staffing is unavailable for a

complete implementation by the business

deadline.

If the core product is well received than

additional staff can be added to implement

next increments.

Eg. Word processing S/W

40


The RAD Model

Communicat ion

Planning

Mode lingbusiness modeling

dat a modeling

process modeling

Const ruct ioncomponent reuse

aut omat ic code

generat ion

t est ing

De ployme nt

6 0 - 9 0 days

Team # 1

Mo d elingbusiness m odel ing

da t a m ode l ing

process m ode l ing

Co nst ruct io ncom ponent reuse

aut om at ic code

genera t ion

t est ing

M o d e lin g

business m odeling

data m odeling

process m odeling

Co n st ru ct io ncom ponent reuse

autom at ic code

generat ion

test ing

Team # 2

Team # n

int egrat ion

delivery

feedback

41


The RAD Model

Rapid application development (RAD) is an incremental model that emphasizes an extremely short development cycle (eg.60-90 days).

It is a high speed adaptation of linear sequential model in which rapid development is achieved by using component based construction.

RAD approach encompasses following phases

42


The RAD Model

Business modeling: info flow among

business fns. is modeled to find what info is

generated, who generates it, where does it

go, who processes it, etc…

Data modeling: the info flow obtained from

earlier phase is refined into data objects,

characteristics (called attributes) of each

object are identified & relationships between

the objects are defined.

43


The RAD Model

Process modeling: data objects are used to implement business function. Processing description are created for adding, modifying, deleting or retrieving a data object.

Application generation: RAD process works to reuse existing program components or create usable components. Automated tools are used to facilitate construction of S/W.

Testing & turnover: since many of the program components are reused ones they are already tested, thus reducing overall testing time.

44


The RAD Model- Drawbacks

Requires sufficient human resources to

create right number of RAD teams.

Requires high commitment from developers

& customers for rapid-fire activities involved

Not all types of applications are suitable for

RAD. It requires that a system can be

properly modularized to use RAD.

It is not appropriate when technical risks are

high. This occurs when a new application

makes heavy use of new technology.

45


Evolutionary Models:

Prototyping

Communicat ion

Qu ick p lan

Const ruct ion

of

prot ot ype

Mo d e lin g

Qu ick d e sig n

De live ry

& Fe e dback

Deployment

46


Prototyping Model This model is used when customer isn’t able

to identify detailed input/output requirements

or the developer is unsure of the efficiency of

the algo, adaptability of O.S., etc…

After requirement gathering a quick design is

made which leads to construction of a

“prototype”.

The prototype serves as a mechanism for

identifying S/W requirements.

Customer evaluation is used to refine the

requirements for the S/W to be developed.47


Prototyping Model Prototype gives the actual feel of the system to

be built.

Customer may want the prototype immediately

with a few fixes but the developer has to resist

the pressure to extend a rough prototype into a

production product because quality suffers.

Quality maybe low as developer may have made

the prototype in a haste using inappropriate

algorithms or O.S. or programming language.

Prototype is discarded (at least in parts) & actual

S/W is engineered which is good in quality &

maintainability.48


Evolutionary Models: The

Spiral

communication

planning

modeling

constructiondeployment

delivery

feedback

start

analysis

design

code

test

estimation

scheduling

risk analysis

49


The Spiral Model

It combines elements of linear sequential model with iterative philosophy of prototyping.

It provides potential for rapid development of incremental versions of S/W

During early iterations paper model or prototype is released and in later ones, complete versions are produced.

It is divided into no. of framework activities also called task regions. Typically there are between 3 & 6 task regions.

50


The Spiral Model- Task regions

1. Customer communication: establish effective commn. between customer & developer.

2. Planning: tasks required to define resources, timelines & other info

3. Risk analysis: tasks required to assess both technical & mgmt. risks.

4. Engineering: tasks required to build 1 or more representations of the application.

5. Construction & release: tasks required to construct, test, install & provide user support

51


The Spiral Model

6. Customer evaluation: tasks required to

obtain customer feedback.

Each of the task regions in turn contain set

of work tasks called a task set.

The project entry points placed along the

axis is used to represent the starting point

for different types of projects.

52


The Spiral Model

It is best suited for object oriented systems.

It is a realistic approach to development of

large scale systems & S/W.

It demands considerable risk assessment

expertise & relies on this expertise for

success.

It is not a widely used model

53



Concurrent

Under review

Baselined

Done

Under

revision

Await ing

changes

Under

development

none

Modeling act ivit y

represents the state

of a sof tware engineering

act ivity or task

54


Concurrent

The concurrent development model,

sometimes called concurrent engineering,

allows a software team to represent iterative

and concurrent elements of any of the

process models

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.CHAPTER 1 Slides by:Ms. Shree Jaswal 55

Specialized models:

Component based development

Component based development—the process to apply

when reuse is a development objective

The component-based development model incorporates

many of the characteristics of the spiral model.

It is evolutionary in nature, demanding an iterative

approach to the creation of software.

However, the component-based development model

constructs applications from prepackaged software

components



Advantages of OO model

1. Model leads to s/w reuse. Reusability provides s/w engineer with a number of measurable benefits.

2. Based on study of reusability, QSM Associates, Inc reported component assembly leads to

70% (↓) reduction in development cycle time

84 %(↑) reduction in project class

Production index of 26.2 %(↑) compared to industry norm of 16.9%

58


OO Model

E.g.

Unified s/w development process is

representation of a number of component

based development models, using UML.

Demerit of OO model

Risk involved with reusability may produce

defects.

59

Specialized models: Aspect

Oriented software development

When concerns cut across multiple system functions,

features, and information, they are often referred to as

crosscutting concerns.

Aspect-oriented software development (AOSD), often

referred to as aspect-oriented programming (AOP), is a

relatively new software engineering paradigm that

provides a process and methodological approach for

defining, specifying, designing, and constructing aspects

AOSD defines “aspects” that express customer concerns

that cut across multiple system functions, features, and

information.


For example, consider a banking application

with a conceptually very simple method for

transferring an amount from one account to

another:


void transfer(Account fromAcc, Account toAcc,

int amount) throws Exception

{ if (fromAcc.getBalance() < amount)

throw new InsufficientFundsException();

fromAcc.withdraw(amount);

toAcc.deposit(amount); }

However, this transfer method overlooks certain

considerations that a deployed application would

require:

It lacks security checks to verify that the current

user has the authorization to perform this operation;

a database transaction should encapsulate the

operation in order to prevent accidental data loss;

for diagnostics, the operation should be logged to

the system log, etc.

A version with all those new concerns, for the sake

of example, could look somewhat like this:CHAPTER 1 Slides by:Ms. Shree Jaswal 62


void transfer(Account fromAcc, Account toAcc, int amount, User user,

Logger logger, Database database) throws Exception {

logger.info("Transferring money...");

if (!isUserAuthorised(user, fromAcc)) {

logger.info("User has no permission.");

throw new UnauthorisedUserException();

}

if (fromAcc.getBalance() < amount) {

logger.info("Insufficient funds.");

throw new InsufficientFundsException();

}

fromAcc.withdraw(amount);

toAcc.deposit(amount);

database.commitChanges(); // Atomic operation.

logger.info("Transaction successful.");

}

In this example other interests have become tangled with

the basic functionality (sometimes called the business

logic concern).

Transactions, security, and logging all exemplify cross-

cutting concerns. That means to change logging can

require modifying all affected modules.

Aspects become tangled not only with the mainline

function of the systems in which they are expressed but

also with each other. That means changing one concern

entails understanding all the tangled concerns or having

some means by which the effect of changes can be

inferred.CHAPTER 1 Slides by:Ms. Shree Jaswal 64


Summary – waterfall

Strength Weakness Types of Projects

Simple

Easy to execute

Intuitive and logical

Easy contractually

All or nothing – too

risky

Req frozen early

May chose outdated

hardware/tech

Disallows changes

No feedback from

users

Encourages req

bloating

Well understood

problems, short

duration projects,

automation of

existing manual

systems

65


Summary – Prototyping


Helps req. elicitation

Reduces risk

Better and more

stable final system

Front heavy

Possibly higher cost

and schedule

Encourages

requirement bloating

Disallows later change

Systems with novice

users; or areas with

requirement

uncertainity.

Heavy reporting based

systems can benefit

from UI prototype

66


Summary – Iterative


Regular deliveries,

leading to biz benefit

Can accommodate

changes naturally

Allows user feedback

Avoids req bloating

Naturally prioritizes

req

Allows reasonable

exit points

Reduces risks

Overhead of

planning each

iteration

Total cost may

increase

System arch and

design may suffer

Rework may

increase

For businesses

where time is imp;

risk of long projects

cannot be taken; req

not known and

evolve with time

67

What is “Agility”?

Effective (rapid and adaptive) response to change

Effective communication among all stakeholders

Drawing the customer onto the team

Organizing a team so that it is in control of the work performed

Yielding …

Rapid, incremental delivery of software


Agility and the Cost of Change


An Agile Process

Is driven by customer descriptions of what is

required (scenarios)

Recognizes that plans are short-lived

Develops software iteratively with a heavy

emphasis on construction activities

Delivers multiple ‘software increments’

Adapts as changes occur


Agility Principles - I

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.


Agility Principles - II

8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

9. Continuous attention to technical excellence and good design enhances agility.

10. Simplicity – the art of maximizing the amount of work not done – is essential.

11. The best architectures, requirements, and designs emerge from self–organizing teams.

12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.


Human Factors

the process molds to the needs of the people and team,

not the other way around

key traits must exist among the people on an agile team

and the team itself:

Competence.

Common focus.

Collaboration.

Decision-making ability.

Fuzzy problem-solving ability.

Mutual trust and respect.

Self-organization.


Advantages of Agile Process

Is a very realistic approach to software development.

Promotes teamwork and cross training.

Functionality can be developed rapidly and

demonstrated.

Resource requirements are minimum.

Suitable for fixed or changing requirement .

Delivers early partial working solutions .

Good model for environments that change steadily.

Minimal rules, documentation easily employed.

Enables concurrent development and delivery within an

overall planned context.CHAPTER 1 Slides by:Ms. Shree Jaswal 75

Is agile process suitable for

large scale projects?

Agile Process Methods break the product into small

incremental builds. These builds are provided in

iterations. Each iteration typically lasts from about one to

three weeks.

Every iteration involves cross functional teams working

simultaneously on various areas like planning,

requirements analysis, design, coding, unit testing, and

acceptance testing.

Any agile process is characterized in a manner that

addresses three key major assumptions before

considering it for large scale project development:


1. It is difficult to predict in advance which software

requirements will persist and which will change.

2. It is equally difficult to predict how customer priorities will

change as a project proceeds.

3. For many types of software, design and construction are

interleaved. That is both activities should be performed in

tandem so that the design models are proven as they are

created.

4. It is difficult to predict how much design is necessary before

construction is used to prove the design.

5. Analysis, design, construction and testing are not as

predictable as we might like.CHAPTER 1 Slides by:Ms. Shree Jaswal 77

Extreme Programming (XP)

The most widely used agile process, originally proposed

by Kent Beck

XP Planning

Begins with the creation of “user stories” by listening

Customer assigns a value to the story.

Agile team assesses each story and assigns a cost

Stories are grouped to for a deliverable increment

A commitment is made on delivery date

After the first increment “project velocity” is used to help define

subsequent delivery dates for other increments



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.


Project Velocity

project velocity is the number of customer

stories implemented during the first release.

Project velocity can then be used to

(1) help estimate delivery dates and schedule for

subsequent releases and

(2) determine whether an over commitment has

been made for all stories across the entire

development project.




unit t est

cont inuous int egrat ion

accept ance t est ing

pair

programming

Release

user st ories

values

accept ance t est crit eria

it erat ion plan

simple design

CRC cards

spike solut ions

prot ot ypes

refact oring

sof tware increment

project velocit y computed

Extreme Programming (XP) XP Design

Follows the KIS(Keep it Simple) principle

Encourage the use of CRC (class-responsibility collaborator)cards

For difficult design problems, suggests the creation of “spike solutions”—a design prototype

Encourages “refactoring”—an iterative refinement of the internal program design

XP Coding

Recommends the construction of a unit test for a story beforecoding commences

Encourages “pair programming”

XP Testing

All unit tests are executed daily (whenever code is modified)

“Acceptance tests” are defined by the customer and executed to assess customer visible functionality


CRC cards

CRC (class-responsibility collaborator) cards

identify and organize the object-oriented

classes that are relevant to the current

software increment

The CRC cards are the only design work

product produced as part of the XP process

software increment.


Scrum

Originally proposed by Schwaber and Beedle

Scrum—distinguishing features Development work is partitioned into “packets”

Testing and documentation are on-going as the product is constructed

Work occurs in “sprints” and is derived from a “backlog” of existing requirements

Meetings are very short and sometimes conducted without chairs

“Demos” are delivered to the customer with the time-box allocated


Scrum


Scrum

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 (this is

how changes are introduced). The product manager

assesses the backlog and updates priorities as required.

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. CHAPTER 1 Slides by:Ms. Shree Jaswal 86

Scrum

Scrum meetings—are short (typically 15 minutes)

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.


Scrum

Demos—deliver the software increment to

the customer so that functionality that has

been implemented can be demonstrated and

evaluated by the customer


Thank You!

chapter 1: the software process -...

Documents