0% found this document useful (0 votes)
4 views

Lecture 3 Software Development Process

Uploaded by

abdullah009amjad
Copyright
© © All Rights Reserved
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
4 views

Lecture 3 Software Development Process

Uploaded by

abdullah009amjad
Copyright
© © All Rights Reserved
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
You are on page 1/ 24

Lecture 3

Software Development Process

BSCS (Software Engineering-II) SZABIST-Islamabad 1


Software Engineering Overview
IEEE defines software engineering as:
 The application of a systematic, disciplined,
quantifiable approach to the development,
operation and maintenance of software; that is,
the application of engineering to software.
 The study of approaches as in the above
statement.

BSCS (Software Engineering-II) SZABIST-Islamabad 2


Software Development
 Construction
• Requirement Gathering
• Design Development
• Coding
• Testing
 Management
• Project Planning and Management
• Configuration Management
• Software Quality Assurance
• Installation and Training

BSCS (Software Engineering-II) SZABIST-Islamabad 3


Software Development

BSCS (Software Engineering-II) SZABIST-Islamabad 4


Software Process
 A software process is a road map that helps
you create.It is the way we produce software
and it provides stability and control. Each
process defines certain deliverables known as
the work products. These include programs,
documents and data produced as a
consequence of the software engineering
activities. a timely, high quality result.

BSCS (Software Engineering-II) SZABIST-Islamabad 5


The Waterfall Model
The waterfall model is a sequential approach, where each fundamental
activity of a process represented as a separate phase, arranged in linear
order.
When To Use?
In principle, the waterfall model should only be applied when requirements
are well understood and unlikely to change radically during development
as this model has a relatively rigid structure which makes it relatively
hard to accommodate change when the process in underway.

BSCS (Software Engineering-II) SZABIST-Islamabad 6


BSCS (Software Engineering-II) SZABIST-Islamabad 7
Iterative Model
Iterative development model aims to develop a system
through building small portions of all the features, across all
components.

BSCS (Software Engineering-II) SZABIST-Islamabad 8


Incremental Model
Incremental development is based on the idea of
developing an initial implementation, exposing this to user
feedback, and evolving it through several versions until an
acceptable system has been developed.

increment #n
Communic at ion
Planning

Modeling
analys is C o n s t ru c t i o n
des ign
c ode De p l o y m e n t
t es t d e l i v e ry
fe e dba c k

delivery of
increment # 2 nth increment

Communic at ion
Planning

Modeling
analys is C o n s t ru c t i o n
des ign c ode De p l o y m e n t
t es t d e l i v e ry
fe e dba c k
delivery of
increment # 1 2nd increment

Communic at ion
Planning
Modeling
analys is C o n s t ru c t i o n
des ign c ode
delivery of
De p l o y m e n t
t es t d e l i v e ry
fe e dba c k

1st increment

project calendar time

BSCS (Software Engineering-II) SZABIST-Islamabad 9


Agile
 Agile SDLC 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 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.

BSCS (Software Engineering-II) SZABIST-Islamabad 10


Agile

BSCS (Software Engineering-II) SZABIST-Islamabad 11


Manifesto for Agile Software Development

4 values of Agile Manifesto is comprised of:


 Individuals and interactions over processes and tools
 Working software over comprehensive documentation
 Customer collaboration over contract negotiation
 Responding to change over following a plan

BSCS (Software Engineering-II) SZABIST-Islamabad 12


Manifesto for Agile Software Development
The twelve principles of agile Manifesto include:
 Customer satisfaction through early and continuous software delivery – Customers are happier when they
receive working software at regular intervals, rather than waiting extended periods of time between releases.
 Accommodate changing requirements throughout the development process – The ability to avoid delays
when a requirement or feature request changes.
 Frequent delivery of working software – Scrum accommodates this principle since the team operates in
software sprints or iterations that ensure regular delivery of working software.
 Collaboration between the business stakeholders and developers throughout the project – Better decisions
are made when the business and technical team are aligned.
 Support, trust, and motivate the people involved – Motivated teams are more likely to deliver their best work
than unhappy teams.
 Enable face-to-face interactions – Communication is more successful when development teams are co-located.
 Working software is the primary measure of progress – Delivering functional software to the customer is the
ultimate factor that measures progress.
 Agile processes to support a consistent development pace – Teams establish a repeatable and maintainable
speed at which they can deliver working software, and they repeat it with each release.
 Attention to technical detail and design enhances agility – The right skills and good design ensures the team
can maintain the pace, constantly improve the product, and sustain change.
 Simplicity – Develop just enough to get the job done for right now.
 Self-organizing teams encourage great architectures, requirements, and designs – Skilled and motivated
team members who have decision-making power, take ownership, communicate regularly with other team
members, and share ideas that deliver quality products.
 Regular reflections on how to become more effective – Self-improvement, process improvement, advancing
skills, and techniques help team members work more efficiently.

BSCS (Software Engineering-II) SZABIST-Islamabad 13


The Agile Landscape

BSCS (Software Engineering-II) SZABIST-Islamabad 14


Five Values of Scrum
 Focus. Because we focus on only few things at a time, we
produce excellent work and deliver sooner.
 Courage. Because we aren't alone, we feel supported. This
gives courage to undertake challenges.
 Openness. We discuss how we’re doing and what’s in our way
so that concerns can be rapidly addressed.
 Commitment. Because we have control over our own destiny,
we become more committed to success.
 Respect. As we work together, sharing success and failures,
we come to respect each other, and to help each other
become worthy of respect.

BSCS (Software Engineering-II) SZABIST-Islamabad 15


Important Terminologies
 Scrum Board: A physical board to visualize information for and by the Scrum
Team, often used to manage Sprint Backlog. Tool Jira is used for soft boards.
 Product Backlog: ”An ordered list of the work to be done in order to create,
maintain and sustain a product. Managed by the Product Owner.”
 Sprint: Time-boxed event of 30 days, or less, that serves as a container for the
other Scrum events and activities. Sprints are done consecutively, without
intermediate gaps.
 Sprint Goal: A short expression of the purpose of a Sprint, often a business
problem that is addressed. Functionality might be adjusted during the Sprint in
order to achieve the Sprint Goal.
 Sprint Backlog: An overview of the development work to realize a Sprint’s goal,
typically a forecast of functionality and the work needed to deliver that
functionality. Managed by the Development Team.
 Velocity: ”It is used for indication of the average amount of Product Backlog
turned into an Increment of product during a Sprint by a Scrum Team”.

BSCS (Software Engineering-II) SZABIST-Islamabad 16


Important Terminologies
 Daily Scrum: Daily time-boxed event of 15 minutes, or less, for the
Analysis, Development and Test Team and to re-plan the next day of
development work during a Sprint. Updates are reflected in the Sprint
Backlog.
 Sprint Planning: Time-boxed event of 8 hours, or less, to start a Sprint.
It serves for the Scrum Team to inspect the work from the Product
Backlog that’s most valuable to be done next and design that work into
Sprint backlog.
 Sprint Retrospective: ”Time-boxed event of 3 hours, or less, to end a
Sprint. It serves for the Scrum Team to inspect the past Sprint and plan
for improvements to be enacted during the next Sprint”.
 Sprint Review: Time-boxed event of 4 hours, or less, to conclude the
development work of a Sprint. It serves for the Scrum Team and the
stakeholders to inspect the Increment of product resulting from the
Sprint, assess the impact of the work performed on overall progress and
update the Product backlog in order to maximize the value of the next
period.

BSCS (Software Engineering-II) SZABIST-Islamabad 17


Important Terminologies
 Burn-down Chart: ”A chart which shows the amount of work which is thought to
remain in a backlog. Time is shown on the horizontal axis and work remaining on
the vertical axis”.
As time progresses and items are drawn from the backlog and completed, a plot
line showing work remaining may be expected to fall. The amount of work may
be assessed in any of several ways such as user story points or task hours.
Work remaining in Sprint Backlogs and Product Backlogs may be communicated
by means of a burn-down chart.

 Burn-up Chart: ”A chart which shows the amount of work which has been
completed. Time is shown on the horizontal axis and work completed on the
vertical axis”.
As time progresses and items are drawn from the backlog and completed, a plot
line showing the work done may be expected to rise. The amount of work may
be assessed in any of several ways such as user story points or task hours. The
amount of work considered to be in-scope may also be plotted as a line; the
burn-up can be expected to approach this line as work is completed.

BSCS (Software Engineering-II) SZABIST-Islamabad 18


Important Terminologies

BSCS (Software Engineering-II) SZABIST-Islamabad 19


The Three Roles of Scrum

BSCS (Software Engineering-II) SZABIST-Islamabad 20


Scrum Board (Manual)

BSCS (Software Engineering-II) SZABIST-Islamabad 21


Scrum Board (in JIRA)

BSCS (Software Engineering-II) SZABIST-Islamabad 22


How Scrum Works

BSCS (Software Engineering-II) SZABIST-Islamabad 23


Scrum Ceremonies

BSCS (Software Engineering-II) SZABIST-Islamabad 24

You might also like