UNIT II

Software Process
 Project Phases and the Project Life
Cycle
• A project life cycle is a collection of project phases
that defines
– what work will be performed in each phase
– what deliverables will be produced and when
– who is involved in each phase, and
– how management will control and approve work produced
in each phase
• A deliverable is a product or service produced or
provided as part of a project
 More on Project Phases
• In early phases of a project life cycle
– resource needs are usually lowest
– the level of uncertainty (risk) is highest
– project stakeholders have the greatest opportunity to
influence the project
• In middle phases of a project life cycle
– the certainty of completing a project improves
– more resources are needed
• The final phase of a project life cycle focuses on
– ensuring that project requirements were met
– the sponsor approves completion of the project
Phases of the Traditional Project Life
Cycle
 Product Life Cycles

• Products also have life cycles

• The Systems Development Life Cycle (SDLC) is a
framework for describing the phases involved in
developing and maintaining information systems
• Systems development projects can follow
– Predictive life cycle: the scope of the project can be clearly
articulated and the schedule and cost can be predicted
– Adaptive Software Development (ASD) life cycle:
requirements cannot be clearly expressed, projects are
mission driven and component based, using time-based
cycles to meet target dates
 Predictive Life Cycle Models
• Waterfall model: has well-defined, linear stages of
systems development and support
• Spiral model: shows that software is developed using
an iterative or spiral approach rather than a linear
approach
• Incremental build model: provides for progressive
development of operational software
• Prototyping model: used for developing prototypes to
clarify user requirements
• Rapid Application Development (RAD) model: used
to produce systems quickly without sacrificing
quality
 Software Life Cycle Models
The goal of Software Engineering is to provide
models and processes that lead to the
production of well-documented maintainable
software in a manner that is predictable.
 Software Life Cycle Models
“The period of time that starts when a software
product is conceived and ends when the
product is no longer available for use. The
software life cycle typically includes a
requirement phase, design phase,
implementation phase, test phase, installation
and check out phase, operation and
maintenance phase, and sometimes retirement
phase”.
 Waterfall Model

• This model is easy to understand and

reinforces the notion of “define before design”
and “design before code”.

• The model expects complete & accurate

requirements early in the process, which is
unrealistic
Waterfall Model
 Phases of Waterfall Model
• Requirement Definition
– All possible requirements of the system to be developed are
captured in this phase and documented in a required
specification document.
• System &Software Design
– Requirement specifications from first phase are studied in this
phase and system design is prepared. System design helps in
specifying hardware and system requirement and also help in
defining overall system architecture.
• Implementation & Unit Testing
– With inputs from system design, the system is first developed in
small programs called units, which are integrated in in the next
phase. Each unit is developed and tested for functionality
known as unit testing.
 Phases of Waterfall Model
• Integration & System Testing
– All the units developed in implementation phase are integrated
into a system after testing of each unit. Post integration the entire
system is tested for any faults and failures.
• Operation Maintenance
– Once the functional and non-functional testing is done, the
product is deployed in the customer environment or released into
the market.
– There are some issues which come up in the client environment.
To fix those issues patches are released. Also to enhance the
product some better versions are released. Maintenance is done
to deliver these changes in the customer environment.
 Advantages of Waterfall Model
• Simple and easy to understand and use
• Easy to manage due to the rigidity of the model, each
phase has specific deliverables and review process
• Phases are processed and complete one at a time
• Works well for small projects where requirements are
very well understood
• Clearly defined stages
• Well understood milestones
• Easy to arrange tasks
• Process and results are well documented
 Limitations of Waterfall Model
The waterfall model, although widely used, has some strong
limitations. Some of the key limitations are :
1. It assumes that the requirements of a system can be frozen
(i.e., baseline) before the design starts. This is possible for
systems designed to automate an existing manual system.
But for new systems, determining the requirements is
difficult as the user does not even know the requirements.
Hence, having unchanging requirements is unrealistic for
such projects.
2. Freezing the requirements usually requires choosing the
hardware (because it forms a part of the requirements
specification). A large project might take a few years to
complete. If the hardware is selected early then due to the
speed at which hardware technology is changing, it is likely
that the final software will use a hardware technology on the
verge of becoming obsolete. This is clearly not desirable for
such expensive software systems.
 Limitations of Waterfall Model
3. It follows the “big bang” approach the entire software is
delivered in one shot at the end. This entails heavy risks,
as the users do not known until the very end what they
are getting. Furthermore, if the project runs out of money
in the middle, then there will be no software. That is it
has the “all or nothing” value proposition.
4. It encourages “requirements bloating”. Since all
requirements must be specified at the start and only what
is specified will be delivered, it encourages the users and
other stakeholders to add even those features which they
think might be needed (which finally may not get used).
5. It is a document-driven process that requires formal
documents at the end of each phase.
 Waterfall Model
Among the problems that are sometimes encountered when
the waterfall model is applied are :
1. Real projects rarely follow the sequential flow that the
model proposes. Although the linear model can
accommodate iteration, it does so indirectly. As a result,
changes can cause confusing as the project team proceeds.
2. It is often difficult for the customer to state all requirements
explicitly. The water fall model requires this and has
difficulty accommodating the natural uncertainty that exists
at the beginning of many projects.
3. The customer must have patience. A working version of the
program's) will not be available until late in the project time
span. A major blunder, if undetected until the working
program is reviewed, can be disastrous.
Evolutionary Process Model
 Evolutionary Process Model

• Evolutionary process model resembles iterative

enhancement model.
• The same phases as defined for the waterfall model
occur here in a cyclical fashion.
• This model differs from iterative enhancement model
in the sense that this does not require a useable
product at the end of each cycle.
• In evolutionary development, requirements are
implemented by category rather than by priority.
 Evolutionary Process Model

• This model is useful for projects using new

technology that is not well understood.
• This is also used for complex projects where all
functionality must be delivered at one time, but the
requirements are unstable or not well understood at
the beginning.
 Prototyping
• A customer defines a set of general objectives for software, but
does not identify detailed input, processing, or output
requirements.
• The developer may be unsure of the efficiency of an algorithm
the adaptability of an operating system or the form that
human-machine interaction should take.
• In these and many other situations, a prototyping paradigm
may offer the best approach.
• Prototyping can be used as a standalone process model.
• Commonly used as a technique that can be implemented
within the context of any one of the process models.
• The prototyping paradigm assists the software engineer and
the customer to better understand what is to be built when
requirements are fuzzy.
 Prototyping
• The prototype may be a usable program but is not
suitable as the final software product.
• The code for the prototype is thrown away. However
experience gathered helps in developing the actual
system.
• The development of a prototype might involve extra
cost, but overall cost might turnout to be lower than
that of an equivalent system developed using the
waterfall model.
The Prototyping Model
 The Prototyping Model
Initial
Requirement Develop Prototype
Identify Problem

Convert to Operational
System

Problem
Implement and Use Revise and Enhance
Prototype Prototype
Next Version
 Prototyping
Prototyping can be problematic for the following reasons :

1. The customer sees what appears to be a working

version of the software unaware that the prototype is
held together “with chewing gum and baling wire”,
unaware that in the rush to get it working we haven’t
considered overall software quality or long-term
maintainability. When informed that the product must
be rebuilt so that high levels of quality can be
maintained, the customer cries foul and demands that “a
few fixes” be applied to make the prototype a working
product. Too often, software development management
relents.
 The Prototyping Model
2. The developer often makes implementation compromises in order
to get a prototype working quickly. An inappropriate operating
system or programming language may be used simply because it
is available and known; an inefficient algorithm may be
implemented simply to demonstrate capability. After a time, the
developer may become comfortable with these choices and forget
all the reasons why were inappropriate. The less-than-ideal choice
has now become an integral part of the system.

Although problems can occur, prototyping can be an effective

paradigm for software engineering. The key is to define the rules
of the fame at the beginning; that is the customer and developer
must both agree that the prototype is built to serve as a
mechanism for defining requirements. It is then discarded (as least
in part), and the actual software is engineered with an eye toward
quality
 Advantages of Prototyping Model
• Increased user involvement in the product even
before implementation
• Users get a better understanding of the system being
developed
• Reduces time and cost as the defects can be detected
much earlier
• Quicker user feedback is available leading to better
solutions
• Missing functionality can be identified easily
• Confusing or difficult functions can be identified
 Limitations of Prototype Model
• Developers often makes implementation
compromises in order to get prototype working
quickly.
• Quality is not properly checked for long time.
• User may get confused in the prototype and actual
system.
• May increase the complexity of the system as scope
of the system may expand beyond original plans.
• The efforts invested in building prototype may be too
much if not monitored properly.
 Spiral Model
• The spiral model originally proposed by Boehm.
• It couples the iterative nature of prototyping with the
controlled and systematic aspects of the linear
sequential model.
• It allows for incremental releases of the product or
incremental refinement through each iteration around
the spiral.
 The Spiral Model
• Customer communication
– tasks required to establish effective communication
between developer and customers
• Planning
– tasks required to define resources, timelines and other
project related information
• Risk analysis
– tasks required to assess both technical and management
risks
• Engineering
– tasks required to build one or more representations of the
application
 The Spiral Model
• Construction and release
– tasks required to construct, test install, and provide user
support (e.g., documentation and training).
• Customer Evaluation
– tasks required to obtain customer feedback based on
evaluation of the software representations created during
the engineering stage and implemented during the
installation stage.
 Planning

Customer Risk analysis

communication
Project entry
Point axis

Engineering

Customer
evaluation
Construction & release

Product maintenance projects

Product enhancement projects

New Product development projects

Concept development projects

 Advantages of Spiral Model
• The spiral model is a realistic approach to the
development of large-scale systems and software.
Because software evolves as the process progresses,
the developer and customer better understand and
react to risks at each evolutionary level.

• The spiral model uses prototyping as a risk reduction

mechanism but, more importantly enables the
developer to apply the prototyping approach at any
stage in the evolution of the product.
 Advantages of Spiral Model
• It maintains the systematic stepwise approach
suggested by the classic life cycle but incorporates it
into an iterative framework that more realistically
reflects the real world.

• The spiral model demands a direct consideration of

technical risks at all stages of the project and if
properly applied should reduce risks before they
come problematic.
 Limitations of Spiral Model
• But like other paradigms 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 un-covered and managed,

problems will undoubtedly occur.
 Incremental Process Model
• They are effective in the situations where
requirements are defined precisely and there is no
confusion about the functionality of the final product.

• After every cycle a useable product is given to the

customer.

• Popular particularly when we have to quickly deliver

a limited functionality system.
 Incremental Process Model
• Combines the benefits of both waterfall and
prototyping.
• Each increment add some functional capability to the
system until the full system is implemented.
• Result in better testing as testing each increment is
likely to be easier than testing entire system.
• The first increment is often a core product i.e. basic
requirements are addressed but many supplementary
features remain underlived.
 Incremental Process Model
• Core product is used by costumer.
• As a result, a plan is developed for the next
increment.
• Plan addressed the modifications of the core product
and delivery of additional functionality features and
functionality.
• This process is repeated until the complete product is
produced.
Incremental Process Model
 Iterative Enhancement Model
• This model has the same phases as the waterfall
model, but with fewer restrictions.
• Generally the phases occur in the same order as in the
waterfall model, but they may be conducted in several
cycles.
• Useable product is released at the end of the each
cycle, with each release providing additional
functionality.
 Iterative Enhancement Model
• Customers and developers specify as many
requirements as possible and prepare a SRS
document.
• Developers and customers then prioritize these
requirements.
• Developers implement the specified requirements in
one or more cycles of design, implementation and test
based on the defined priorities.
Iterative Enhancement Model
 Rapid Application Development
(RAD)
• Rapid application development (RAD) is an
incremental software process model that emphasizes
on extremely short development cycle.
• The RAD model is a high-speed’ adaptation of the
waterfall model, in which rapid development is
achieved by using a component based construction
approach.
• If requirements are well understood and project scope
is constrained the RAD process enables a
development team to create a ‘fully functional
system’ within a very short time period.
The RAD Model Team #2 Team #3
Team #1
Business
Business modeling
modeling
Business Data
modeling modeling
Data
modeling Process
modeling

Data Process Application

modeling modeling generation
Testing
&
Application Turnover
generation
Process
modeling Testing
&
Turnover

Application
generation

Testing
&
Turnover
60-90 days
 Phases of RAD
• Business Modeling
– The business model for the product is designed in terms of
flow of information between various business channels.
– A complete business analysis is performed to find the vital
information for business, how it can be obtained, how and
when is the information processed and what are the factors
driving successful flow of information.
• Data Modeling
– Information gathered in the business modelling phase is
refined and analyzed to form a set of data objects that are
needed to support the business.
– The characteristics of each object is defined and the
relationship between these objects defined
 Phases of RAD
• Process Modeling
– Data objects defined in the previous phase are transformed to
achieve the information flow necessary to implement a business
functions.
– Process model for any changes or enhancements to the data
objects sets is defined in this phase.
– Process descriptions for adding, deleting, retrieving or
modifying a data object are given.
• Application Generation
– RAD uses fourth generation technology.
– RAD process works to reuse existing program component or
create reusable components.
– Actual system is build and coding is done by using automation
tools to convert process and data models into actual prototypes.
 Phases of RAD
• Testing & Turnover
– RAD process emphasizes on reuse, many of the program
components have already been tested.
– This reduces overall testing time.
– Also, it reduces the risk of any major issues
– However the data flow and interfaces between all the
components need to be thoroughly tested with complete
test coverage.
 Advantages of RAD
• Changing requirements can be accommodated
• Progress can be measured
• Iteration time can be short with use of powerful RAD
tools
• Productivity with fewer people in short time
• Reduced development time
• Increases reusability of components
• Quick initial reviews occur
• Encourage customer feedback
• Integration from very beginning solves a lot of integration
issues
 Limitations of RAD
1. For large but scalable projects RAD requires sufficient
human resources to create the right number of RAD teams.
2. If developers and customers are not committed to the rapid
fire activities necessary to complete the system in a much
abbreviated time frame, RAD projects will fail.
3. If a system cannot be properly modularized, building the
components necessary for RAD will be problematic.
4. If high performance is an issue and performance is to be
achieved through tuning the interfaces to system
components the RAD approach may not work.
5. RAD may not be appropriate when technical risks are high
(e.g., when a new application makes heavy use of new
technology).
 Agile Methodologies
• Aims for customer satisfaction through early and
continuous delivery of components developed by an
iterative process.
• Small teams work together with stakeholders to
define quick prototypes, proof of concepts, or other
visual means to describe the problem to be solved.
• The team defines the requirements for the iteration,
develops the code, and defines and runs integrated
test scripts, and the users verify the results.
 Agile Methodologies
• Verification occurs much earlier in the development
process than it would with waterfall, allowing
stakeholders to fine-tune requirements while they’re
still relatively easy to change.
• The most widely used methodologies based on the
agile philosophy are
– XP and
– Scrum
• These differ in particulars but share the iterative
approach.
 Agile Process
• Any Agile software process is characterized in a
manner that addresses number of key assumptions
– It is difficult to predict in advance which software
requirements will persists and which will change. Similarly,
it is difficult to predict how customer priorities will change
as project proceeds.
– For many types of software, design and construction are
interleaved. That is both activities should be performed in
tandem so that design models are proven as they are
created. It is difficult to predict how much design is
necessary before construction is used to prove the design.
 Agile Process
– Analysis, design, construction and testing are not as
predictable as we might like.
• How do we create a process that can mange
unpredictability?
• Therefore, agile process must be adaptable.
• But continual adaptation without forward progress
accomplish little.
• Therefore, agile process must adapt incrementally.
• For this, an agile team requires customer feedback.
 Agile Process
• An effective catalyst for customer feedback is an
operational prototype.
• Hence, incremental development strategy should be
institute.
• Software increments must be delivered in short
period of time so that adaptation keeps pace with
change.
• This iterative approach enables the customer to
evaluate the software increment regularly, provide
necessary feedback to the team and influence the
process adaptations that are made to accommodate
the feedback.
 Agility Principles
• Highest priority is to satisfy the customer through early and
continuous delivery of valuable software.
• Welcome changing requirements, even late in development.
• Deliver working software frequently, from a couple of weeks
to a couple of months, with a preference to the shorter
timescale.
• Business people and developers must work together daily
throughout the project.
• Build project around motivated individuals. Give them
environment and support they need and trust them to get the
job done.
 Agility Principles
• Most efficient and effective method of conveying information
to and within a development team is face-to-face conversation.
• Working software is the primary measure of progress.
• Agile processes promote sustainable development. The
sponsors, developers, and users should be able to maintain a
constant pace indefinitely.
• Continuous attention to technical excellence and good design
enhances agility.
• Simplicity-the art of maximizing the amount of work not done
–is essential.
• Best architectures, requirements, and designs emerge from self
organizing teams.
• At regular intervals, the team reflects on how to become more
effective, then tunes and adjust its behavior accordingly.
Agile Methodologies
 XP
• XP stands for Extreme Programming.

• XP projects start with a release planning phase,

followed by several iterations, each of which
concludes with user acceptance testing.

• When the product has enough features to

satisfy users, the team terminates iteration and
releases the software.
 XP
• Users write “user stories” to describe the need the software
should fulfill.
• User stories help the team to estimate the time and resources
necessary to build the release and to define user acceptance
tests.
• To create a release plan, the team breaks up the development
tasks into iterations.
• The release plan defines each iteration plan, which drives the
development for that iteration.
• At the end of an iteration, users perform acceptance tests
against the user stories.
• If they find bugs, fixing the bugs becomes a step in the next
iteration.
 XP
• Iterative user acceptance testing, in theory, can
result in release of the software.

• If users decide that enough user stories have

been delivered, the team can choose to
terminate the project before all of the
originally planned user stories have been
implemented.
XP
 XP Values
• Beck defines a set of five values that establish
a foundation for all work performed as part of
XP
– Communication
– Simplicity
– Feedback
– Courage
– Respect
 XP Values
• To achieve effective communication between
software engineers and other stakeholders, XP
emphasizes
– Close, yet informal (verbal) collaboration between
customers and developers.
– The establishment of effective metaphors (stories) for
communicating important concepts.
– Continuous feedback.
– Avoidance of voluminous documentation as a
communication medium.
 XP Values
• For simplicity, XP restricts developers to design only
for immediate needs, rather than consider future
needs.
• The intent is to create a simple design that can be
easily implemented in code.
• If the design must be improved it can be refactored
(allows to improve internal structure of a design
without changing its external functionality or
behavior) at a later time.
 XP Values
• Feedback is derived from three sources
– The implemented software itself
– Customer
– Other software team members
• Certain XP practices demands courage
• There is often significant pressure to design for future
requirements, arguing that it will save time and effort
in the long run.
• Agile XP team must have discipline to design for
today, recognizing that future requirements may
change dramatically and may demand substantial
rework of the design and implemented code.
 XP Values
• By following abovementioned values, the agile team
inculcates respect between other stakeholders and
team members and indirectly for the software itself.
• As they achieve successful delivery of software
increments, the team develops growing respect for the
XP process.
 XP Concepts

• Integrate often:
– Development teams must integrate changes into the
development baseline at least once a day.
– This concept is also called continuous integration.

• Project velocity:
– Velocity is a measure of how much work is getting done on
the project.
– This important metric drives release planning and schedule
updates.
 XP Concepts
• Pair programming:
– All code for a production release is created by two people
working together at a single computer.
– XP proposes that two coders working together will satisfy
user stories at the same rate as two coders working alone,
but with much higher quality.
• User story:
– A user story describes problems to be solved by the system
being built.
– These stories must be written by the user and should be
about three sentences long.
– User stories do not describe a solution, use technical
language, or contain traditional requirements.
 XP Process
• XP uses an object-oriented approach as its preferred
development paradigm and encompasses a set of rules
and practices that occur within the context of four
framework activities:
– Planning
– Design
– Coding
– Testing
XP Process
 XP Process
• Planning
– Begins with listening
• A requirement gathering activity that enables the technical member
to understand the business context for the software and to get a feel
for required output and major features and functionality.
– Listening leads to the creation of stories
• Describe required output, features and functionality for software to
be built.
– Each story written by the customer and placed on the index
card with assigned value based on the overall business
value of the feature or function.
– XP team members assess each story and assign a cost
measured in development weeks.
 XP Process
– If the estimated time for a story is more than three weeks
then the customer is asked to split story into smaller stories
• Again assign the value and cost
– Customers and developers work together to decide how to
group stories into the next release
– Once the basic commitment is made for release, XP team
orders the stories that will be developed in one of three
ways:
• All stories will be implemented immediately
• Stories with highest value will be moved up in the schedule and
implemented first
• Riskiest story will be moved up in schedule and implemented first
 XP Process
– After the first project release has been delivered, XP team
computes project velocity.
– Project velocity is the number of customer stories
implemented during the first release.
– Project velocity can then be used to
• Help estimating delivery dates and schedule for subsequent release
• Determine whether an overcommitment has been made for all
stories across the entire development project.
– If yes, the content of release is modified or end delivery dates are changed

– As work proceeds, customer can add stories, change the

value of existing story, split stories and eliminate them.
– XP team must reconsider all remaining releases and
modifies its plans accordingly.
 XP Process
• Design
– Follows KIS (Keep it Simple) principle
– Always prefer simple design over complex
– Design provides implementation guidance for a story as it
is written
– Design of extra functionality is discouraged.
– XP encourages the use of CRC (Class-Responsibility-
Collaboration) cards.
– CRC 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
the part of XP process
 XP Process
– If a difficult design problem is encountered, XP
recommends the immediate creation of an operational
prototype of that portion of the design.
– Called a Spike Solution, design prototype is implemented
and evaluated.
– Intent is to lower the risk and to validate the original
estimates for the story containing the design problem.
 XP Process
• Coding
– After development of stories and preliminary design work,
team does not move to code.
• Rather develops a series of unit test
– Once the unit test has been created, the developer is better
able to focus on what must be implemented to pass the test.
– Once the code is completed, it can be unit tested
immediately, providing instantaneous feedback to the
developers.
– Pair programming is the key concept during coding.
– XP recommends that two people work together at one
workstation to create code for story.
 XP Process
– Provides the mechanism for real time problem solving and
real time quality assurance.
– Keeps the developers focused on the problem in hand.
– Each person takes on different role
• One person might think about the coding details
• While other ensures that coding standards are being followed.
– Code of pair programmers is integrated with the work of
others
• May be performed on daily basis by an integration team.
• Pair programmers have integration responsibility
– This continuous integration strategy helps to avoid
compatibility and interfacing problems and help to uncover
errors early.
 XP Process
• Testing
– Unit test should be implemented using a framework that
enables them to be automated.
– This encourages a regression testing strategy whenever
code is modified.
– As individual unit tests are organized into a universal
testing suite, integration and validation testing can occur on
daily basis.
– XP acceptance test or customer test are specified by the
customer and focus on overall system features and
functionality that are visible and reviewable by the
customer.
 Issues in XP
• Requirements volatility
• Conflicting customer needs
• Requirements are expressed informally
• Lack of formal design
 Scrum
• At the center of each Scrum project is a backlog of
work to be done. This backlog is populated during the
planning phase of a release and defines the scope of
the release.
• After the team completes the project scope and high-
level designs, it divides the development process into
a series of short iterations called sprints.
• Each sprint aims to implement a fixed number of
backlog items.
• Before each sprint, the team members identify the
backlog items for the sprint.
 Scrum
• At the end of a sprint, the team reviews the sprint to
articulate lessons learned and check progress.
• During a sprint, the team has a daily meeting called a
scrum.
• Each team member describes the work to be done that
day, progress from the day before, and any blocks
that must be cleared.
• To keep the meetings short, the scrum is supposed to
be conducted with everyone in the same room—
standing up for the whole meeting.
 Scrum
• When enough of the backlog has been
implemented so that the end users believe the
release is worth putting into production,
management closes development.

• The team then performs integration testing,

training, and documentation as necessary for
product release.
Scrum
 Scrum Development
• The Scrum development process concentrates on
managing sprints.
• Before each sprint begins, the team plans the sprint,
identifying the backlog items and assigning teams to
these items.
• Teams develop, wrap, review, and adjust each of the
backlog items.
• During development, the team determines the
changes necessary to implement a backlog item.
• The team then writes the code, tests it, and documents
the changes.
 Scrum Development
• During wrap, the team creates the executable
necessary to demonstrate the changes.
• In review, the team demonstrates the new
features, adds new backlog items, and assesses
risk.
• Finally, the team consolidates data from the
review to update the changes as necessary.
 Scrum Development
• Following each sprint, the entire team-
including management, users, and other
interested parties—demonstrates progress from
the sprint and reviews the backlog progress.

• The team then reviews the remaining backlog

and adds, removes, or reprioritizes items as
necessary to account for new information and
understanding gathered during the sprint.
 Scrum Concepts
• Burndown Chart:
– This chart, updated every day, shows the work remaining
within the sprint.
– The burndown chart is used both to track sprint progress
and to decide when items must be removed from the sprint
backlog and deferred to the next sprint.
• Product Backlog:
– Product backlog is the complete list of requirements—
including bugs, enhancement requests, and usability and
performance improvements—that are not currently in the
product release.
 Scrum Concepts
• ScrumMaster:
– The ScrumMaster is the person responsible for managing
the Scrum project.
– Sometimes it refers to a person who has become certified
as a ScrumMaster by taking ScrumMaster training.
• Sprint Backlog:
– Sprint backlog is the list of backlog items assigned to a
sprint, but not yet completed.
– In common practice, no sprint backlog item should take
more than two days to complete.
– The sprint backlog helps the team predict the level of effort
required to complete a sprint.