SOFTWARE ENGINEERING

SOFTWARE-LIFE CYCLE AND PROCESS MODELS

Saulius Ragaišis

saulius.ragaisis@mif.vu.lt

CSC2008 SE “Software Processes”

Learning Objectives:

• Explain the concept of a software life cycle and provide an example, illustrating its phases including the deliverables that are produced.

• Select, with justification the software development models and process elements most appropriate for the development and maintenance of a diverse range of software products.

• Explain the role of process maturity models.

• Compare the traditional waterfall model to the incremental model, the agile model, and other appropriate models.

• For each of various software project scenarios, describe the project’s place in the software life cycle, identify the particular tasks that should be performed next, and identify measurements appropriate to those tasks.

SOFTWARE LIFE CYCLE

Definitions from Google

• The phases a software product goes through between when it is conceived and when it is no longer available for use.

The Free On-line Dictionary of Computing, Denis Howe 2010

• A series of stages in the development of an application and is often used in Software Engineering. David Bolton, About.com

Standards of Life cycle processes

• ISO/IEC 12207:2008. Systems and software engineering — Software life cycle processes

• ISO/IEC 15288:2008. Systems and software engineering — System life cycle processes

Definitions in standards

• Life cycle - evolution of a system, product, service, project or other human-made entity from conception through retirement.

• Life cycle model - framework of processes and activities concerned with the life cycle that may be organized into stages, which also acts as a common reference for communication and understanding.

[ISO/IEC 12207:2008]

Software life cycle processes (ISO/IEC 12207-2008)

LIFE CYCLE MODELS

Life cycle models and stages

The life of a system/software can be modeled by a life cycle model consisting of stages. Models may be used to represent the entire life from concept to disposal or to represent the portion of the life corresponding to the current project. The life cycle model is comprised of a sequence of stages that may overlap and/or iterate, as appropriate for the project's scope, magnitude, complexity, changing needs and opportunities. [ISO/IEC 12207:2008]

1970

Development according W. W. Royce

1968... “Iterative development”

“Rocket science!”

Generic process framework activities

• Communication

• Planning

• Modeling

• Construction

• Deployment

Waterfall model

Incremental model

Spiral model

RAD model

Prototyping

Unified Process

• An extensible framework which should be customized for specific organizations or projects.

• Proposed by Ivar Jacobson, Grady Booch and James Rumbaugh. The first book “The Unified Software Development Process” (ISBN 0-201-57169-2) published in 1999.

UP refinements and variations

• Rational Unified Process (RUP), the IBM / Rational Software development process

• Oracle Unified Method (OUM), the Oracle development and implementation process

• Agile Unified Process (AUP), a lightweight variation developed by Scott W. Ambler

• Essential Unified Process (EssUP), a lightweight variation developed by Ivar Jacobson

• Enterprise Unified Process (EUP), an extension of the Rational Unified Process

…

UP characteristics

• Iterative and Incremental

• Use Case Driven

• Architecture Centric

• Risk Focused

UP project life-cycle

UP major work products: Inception

• Vision document

• Initial use-case model

• Initial project glossary

• Initial business case

• Initial risk assessment

• Project plan (phases and iterations)

• Business model (if necessary)

• One or more prototypes

UP major work products: Elaboration

• Use-case model

• Supplementary requirements including non-functional

• Analysis model

• Software architecture description

• Executable architectural prototype

• Preliminary design model

• Revised risk list

• Project plan including iteration plan, adapted workflows, milestones, technical work products

• Preliminary user manual

UP major work products: Construction

• Design model

• Software components

• Integrated software increment

• Test plan and procedure

• Test cases

• Support documentation (user manuals, installation

manuals, description of current increment)

UP major work products: Transition

• Delivered software increment

• Beta test reports

• General user feedback

AN AGILE VIEW OF PROCESS

Principles behind the Agile Manifesto • Our highest priority is to satisfy the customer

through early and continuous delivery of valuable software.

• Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

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

Principles behind the Agile Manifesto (2) • Build projects around motivated individuals. Give

them the environment and support they need, and trust them to get the job done.

• The 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.

Principles behind the Agile Manifesto (3) • Continuous attention to technical excellence and

good design enhances agility.

• Simplicity--the art of maximizing the amount of work not done--is essential.

• The 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 adjusts its behavior accordingly.

Most popular Agile methodologies

• XP (eXtreme Programming)

• SCRUM

• DSDM (Dynamic System Development Method)

Key issues stressed by Agile

• The importance of self-organizing teams that control over the work they perform.

• Communication and collaboration between team members and between practitioners and their customers.

• A recognition that change represents an opportunity.

• An emphasis on rapid delivery of software that satisfies the customer.

What we have learned?

• Concept of software life cycle

• Understanding of software life cycle processes

• Software life cycle models

QUESTIONS?

APPENDIX

Life cycle process groups (ISO/IEC 12207-2008)

System Life Cycle Processes

• Agreement Processes (2 processes)

• Organizational Project-Enabling Processes (5 p.)

• Project Processes (7 p.)

• Technical Processes (11 p.)

Software Life Cycle Processes

• Software Implementation Processes (7 p.)

• Software Support Processes (8 p.)

• Software Reuse Processes (3 p.)

Agreement Processes

• Acquisition Process

• Supply Process

Organizational Project-Enabling Processes

• Life Cycle Model Management Process

• Infrastructure Management Process

• Project Portfolio Management Process

• Human Resource Management Process

• Quality Management Process

Project Processes

• Project Planning Process

• Project Assessment and Control Process

• Decision Management Process

• Risk Management Process

• Configuration Management Process

• Information Management Process

• Measurement Process

Technical Processes

• Stakeholder Requirements Definition Process

• System Requirements Analysis

• System Architectural Design

• Implementation Process

• System Integration Process

• System Qualification Testing Process

• Software Installation

• Software Acceptance Support

• Software Operation Process

• Software Maintenance Process

• Software Disposal Process

Software Implementation Processes

• Software Implementation Process

• Software Requirements Analysis Process

• Software Architectural Design Process

• Software Detailed Design Process

• Software Construction Process

• Software Integration Process

• Software Qualification Testing Process

Software Support Processes

• Software Documentation Management Process

• Software Configuration Management Process

• Software Quality Assurance Process

• Software Verification Process

• Software Validation Process

• Software Review Process

• Software Audit Process

• Software Problem Resolution Process

Software Reuse Processes

• Domain Engineering Process

• Reuse Asset Management Process

• Reuse Program Management Process

XP project

XP planning/feedback loops

XP main values

• Communication

• Simplicity

• Feedback

• Courage

• Respect

XP practices • Planning game

• Small releases

• System metaphor

• Simple design

• Refactoring

• Test driven development

• Pair programming

• Collective code ownership

• Continuous integration

• 40 hour week (sustainable pace)

• On-site customer (whole team)

• Coding standard

XP practices

DSDM project phases

Prerequisites for using DSDM

• Acceptance of the DSDM Atern philosophy before starting work.

• Appropriate empowerment of the Solution Development Team.

• Commitment of senior business management to provide the necessary Business Ambassador (and Business Advisor) involvement.

• Incremental delivery • Access by the Solution Development Team to business

roles • Solution Development Team stability. • Solution Development Team skills. • Solution Development Team size. • A supportive commercial relationship.

DSDM principles

• Focus on the business need

• Deliver on time

• Collaborate

• Never compromise quality

• Build incrementally from firm foundations

• Develop iteratively

• Communicate continuously and clearly

• Demonstrate control

Core techniques of DSDM

• Timeboxing

• MoSCoW method for requirements prioritizing

• Prototyping

• Testing

• Workshop

• Modeling

• Configuration Management

MoSCoW method

• MUST have this requirement to meet the business needs.

• SHOULD have this requirement if at all possible, but the project success does not rely on this.

• COULD have this requirement if it does not affect the fitness of business needs of the project.

• WOULD have this requirement at later date if there is some time left (or in the future development of the system).

SCRUM project

Scrum Framework in 30 Seconds

• A product owner creates a prioritized wish list called a product backlog.

• During sprint planning, the team pulls a small chunk from the top of that wish list, a sprint backlog, and decides how to implement those pieces.

• The team has a certain amount of time, a sprint, to complete its work - usually two to four weeks - but meets each day to assess its progress (daily scrum).

• Along the way, the Scrum Master keeps the team focused on its goal.

• At the end of the sprint, the work should be potentially shippable, as in ready to hand to a customer, put on a store shelf, or show to a stakeholder.

• The sprint ends with a sprint review and retrospective. • As the next sprint begins, the team chooses another chunk of the

product backlog and begins working again.

Scrum terminology

• Scrum Team: Product Owner, Scrum Master and Development Team

• Product Owner: The person responsible for maintaining the Product Backlog by representing the interests of the stakeholders, and ensuring the value of the work the Development Team does.

• Scrum Master: The person responsible for the Scrum process, making sure it is used correctly and maximizing its benefits.

• Development Team: A cross-functional group of people responsible for delivering potentially shippable increments of Product at the end of every Sprint.

Scrum terminology (2)

• Sprint burn down chart: Daily progress for a Sprint over the sprint’s length.

• Product backlog: A prioritized list of high-level requirements.

• Sprint backlog: A prioritized list of tasks to be completed during the sprint.

• Sprint: A time period (typically 1–4 weeks) in which development occurs on a set of backlog items that the team has committed to. Also commonly referred to as a Time-box or iteration.

Scrum terminology (3)

• (User) Story: A feature that is added to the backlog. A story is an independent, negotiable, valuable, estimable, small, testable requirement ("INVEST Acronym").

• Theme: A theme is a top-level objective that may span projects and products. Themes may be broken down into sub-themes, which are more likely to be product-specific.

Epic: An epic is a group of related stories, mainly used in product roadmaps and the backlog for features that have not yet been analyzed enough to break it down into it's component stories, which should be done before bringing it into a sprint so to reduce uncertainty.

Scrum terminology (4)

• Spike: A time boxed period used to research a concept and/or create a simple prototype. Spikes can either be planned to take place in between sprints or, for larger teams, a spike might be accepted as one of many sprint delivery objectives. For example, the objective of a spike might be to successfully reach a decision on a course of action. The spike is over when the time is up, not necessarily when the objective has been delivered.

• Tracer Bullet: The tracer bullet is a spike with the current architecture, current technology set, current set of best practices which results in production quality code. It might just be a very narrow implementation of the functionality but is not throw away code.

Scrum terminology (5)

• Point Scale/Effort/Story points: Relates to an abstract point system, used to discuss the difficulty of the story, without assigning actual hours. The most common scale used is a rounded Fibonacci sequence (1,2,3,5,8,13,20,40,100), although some teams use linear scale (1,2,3,4...), powers of two (1,2,4,8...), and clothes size (XS, S, M, L, XL).

• Tasks: Added to the story at the beginning of a sprint and broken down into hours. Each task should not exceed 12 hours, but it's common for teams to insist that a task take no more than a day to finish.

Scrum terminology (6)

• Definition of Done (DoD): The exit-criteria to determine whether a product backlog item is complete. In many cases the DoD requires that all regression tests should be successful.

• Velocity: The total effort a team is capable of in a sprint. The number is derived by adding all the story points from the last sprint's stories/features. This is a guideline for the team and assists them in understanding how many stories they can do in a sprint.

• Impediment: Anything that prevents a team member from performing work as efficiently as possible.

Scrum terminology (7)

• Sashimi: A report that something is "done". The definition of "done" may vary from one Scrum team to another, but must be consistent within one team.

• Abnormal Termination: The Product Owner can cancel a Sprint if necessary. If a sprint is abnormally terminated, the next step is to conduct a new Sprint planning meeting, where the reason for the termination is reviewed.

• Planning Poker: In the Sprint Planning Meeting, the team sits down to estimate its effort for the stories in the backlog. The Product Owner needs these estimates, so that he or she is empowered to effectively prioritize items in the backlog and, as a result, forecast releases based on the team's velocity.