Software Engineering

Agile Software Engineering: Agile Methods, Scrum, and Extreme Programming

Course Learning Outcome

CLO1: Recognize Software Engineering principles, life cycle phases, processes, and activities.

Chapter 2: Software Processes

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

There are many different software processes, but all involve four fundamental activities:

1. Specification – Defining what the system should do
2. Design and Implementation – Defining the organization of the system and implementing the system
3. Validation – Checking that it does what the customer wants
4. Evolution – Changing the system in response to changing customer needs

Note: A software process model is an abstract representation of a process. It presents a description of a process from some particular perspective.

Software Process Descriptions

When we describe and discuss processes, we usually talk about the activities or actions in these processes such as specifying a data model, designing a user interface, etc. and the ordering of these activities.

Process descriptions may also include:

Plan-Driven and Agile Processes

Plan-Driven (Prescriptive) Processes

Processes where all of the process activities are planned in advance and progress is measured against this plan.

  • Detailed upfront planning
  • Structured phases
  • Comprehensive documentation
  • Progress measured against plan

Agile Processes

Planning is incremental and it is easier to change the process to reflect changing customer requirements.

  • Incremental planning
  • Flexible adaptation
  • Quick response to change
  • Customer collaboration

Important: In practice, most practical processes include elements of both plan-driven and agile approaches. There are no right or wrong software processes.

Traditional/Planned Software Process Models

The Waterfall Process Model

Plan-driven model with separate and distinct phases of specification and development.

Requirements Definition
System and Software Design
Implementation and Unit Testing
Integration and System Testing
Operation and Maintenance

Waterfall Model Phases

Requirements Analysis and Definition
System and Software Design
Implementation and Unit Testing
Integration and System Testing
Operation and Maintenance

Note: Each major phase is marked by milestones and deliverables (artifacts).

When to Use Waterfall Model

  1. It works for well-understood problems with minimal or no changes in the requirements, such as governmental projects
  2. Simple and easy to explain to customers

Advantages

  • Clear structure and milestones
  • Easy to understand and manage
  • Works well for stable requirements
  • Comprehensive documentation

Drawbacks

  • Difficulty accommodating change after process is underway
  • Often difficult for customers to state all requirements explicitly
  • Inflexible partitioning makes it difficult to respond to changing requirements
  • Only appropriate when requirements are well-understood

Modified Waterfall: The model has been modified to allow going back to previous phases, which opened the door for other iterative models.

Incremental Model

Incremental Model: Rather than deliver the system as a single delivery, the system is broken down into increments with each increment adding a part of the required functionality.

The Incremental model combines the elements of linear and parallel process flow. The incremental process model focuses on the delivery of an operational product with each increment.

Incremental Development Process

Product Feature List
Choose Features
Refine Descriptions
Implement & Test
Integrate Feature
Deliver Increment

Incremental Model Activities

1. Choose features to be included in an increment

Using the list of features in the planned product, select those features that can be implemented in the next product increment.

2. Refine feature descriptions

Add detail to the feature descriptions so that the team has a common understanding of each feature and there is sufficient detail to begin implementation.

3. Implement and test

Implement the feature and develop automated tests for that feature, tests that will validate that the system's behavior is consistent with its description.

4. Integrate feature and test

Integrate the developed feature with the existing system and test it to check that it works in conjunction with other features.

5. Deliver system increment

Deliver the system increment to product manager for checking and comments. If enough features have been implemented, release a version of the system for customer use.

Benefits

  • Reduced cost of accommodating changing customer requirements
  • Easier to get customer feedback on development work
  • More rapid delivery and deployment of useful software to customers
  • Highest priority system services receive most system testing
  • Reduced risk of overall project failure (compared to waterfall)

Problems

  • System structure tends to degrade as new increments are added
  • Unless time and money is spent on refactoring to improve the software, regular change tends to corrupt its structure

Key Difference: User requirements are prioritized, then the highest priority requirements are included in early increments. Once the development of an increment is started, requirements are frozen, though requirements for later increments can continue to evolve.

Difference with Evolutionary Models: The list of features is defined from the beginning in the classical incremental model.

Evolutionary Models

The Evolutionary models are iterative. They are characterized in a manner that enables you to develop increasingly more complete versions of the software in increments.

It is used when core or system requirements are well understood but additional system requirements have yet to be defined.

Prototyping Model

Often a customer defines a set of general objectives for software, but doesn't identify details for the functions and features. In other cases, developers may be unsure of the efficiency of an algorithm. In these cases, Prototyping may be the best approach.

Communication
Quick Plan
Quick Design
Prototype Construction
Delivery & Feedback

Prototyping Process

  1. The prototyping paradigm begins with communication. Meet with stakeholders to define overall objectives, identify known requirements, and outline areas needing further definition.
  2. A prototyping iteration is planned quickly, and modeling ("quick design") occurs (e.g., human interface layout or output display formats).
  3. The quick design leads to construction of a prototype.
  4. The prototype is deployed and evaluated by stakeholders, who provide feedback used to further refine requirements.
  5. Iteration occurs as the prototype is tuned to satisfy stakeholder needs while enabling better understanding of requirements.

Benefits

  • Both stakeholders and software engineers like the prototyping paradigm
  • Users get a feel for the actual system
  • Developers get to build something immediately
  • Improve the system before deploying

Drawbacks

  • Stakeholders may see what appears to be a working version, unaware of quality compromises
  • Developers may not consider overall software quality or long-term maintainability
  • May use inappropriate operating system, programming language, or inefficient algorithms

Note: The Prototype can serve as "the first system." Although some prototypes are built as "throw away," others are evolutionary in the sense that the prototype slowly evolves into the actual system.

Spiral Model

Spiral Model couples the iterative nature of prototyping with controlled and systematic aspects of waterfall. It provides the potential for rapid development of increasingly more complete versions of the software.

The Spiral Model is a risk-driven process model generator. It has two main distinguishing features:

  1. It is a cyclic nature for incrementally growing a system's degree of definition and implementation while decreasing its degree of risk
  2. It has a set of milestones for ensuring stakeholders' commitment to feasible and mutually satisfactory system solutions

Spiral Activities

Communication – Gather requirements and feedback
Planning – Define resources, timelines, and other project information
Modeling (Analysis & Design) – Create models to better understand requirements
Construction (Code & Test) – Build and test the software
Deployment (Delivery & Feedback) – Deliver to stakeholders and gather feedback
Risk Analysis – Evaluate risks at each iteration

Key Points:

  • The first circuit around the spiral might result in the development of a product specification
  • Subsequent passes might develop a prototype and then progressively more sophisticated versions
  • Each pass through the planning region results in adjustments to the project plan
  • Cost and schedule are adjusted based on feedback derived from the customer after delivery
  • The spiral model uses prototyping as a risk reduction mechanism

Specialized Process Models

1. Component-Based Development

Based on software reuse where systems are integrated from existing components or application systems (sometimes called COTS - Commercial-off-the-shelf systems).

The process to apply when reuse is a development objective. You want to use components that are already made or you want to make components that may be reused.

Types of Reusable Software

  1. Stand-alone application systems that are configured for use in a particular environment
  2. Collections of objects that are developed as a package to be integrated with a component framework such as .NET or J2EE
  3. Web services that are developed according to service standards and which are available for remote invocation

Advantages

  • Reduced costs and risks as less software is developed from scratch
  • Faster delivery and deployment of system
  • Reduction in development time
  • Reduction in project cost if component reuse becomes part of organizational culture

Disadvantages

  • Requirements compromises are inevitable
  • System may not meet real needs of users
  • Loss of control over evolution of reused system elements

Note: Reused elements may be configured to adapt their behavior and functionality to a user's requirements. Reuse is now the standard approach for building many types of business systems.

2. Unified Process (UP)

The Unified Process is an iterative and incremental development process. The Elaboration, Construction, and Transition phases are divided into a series of timeboxed iterations. Each iteration results in an increment, which is a release of the system that contains added or improved functionality compared with the previous release.

Phases of Unified Process

Inception

Identify business requirements, described as use-cases
Propose a rough system architecture

Elaboration

Refine and expand the preliminary use-cases
Expand the architecture to include five different views:
  • Use-case model
  • Analysis model
  • Design model
  • Implementation model
  • Deployment model

Construction

Develop or acquire the software components to accomplish an initial release

Transition

Software is given to users for beta-testing to collect defects and necessary changes
Create support information, e.g., user manuals, installation procedures, trouble-shooting guides

Production

Monitor the on-going use of the software, and evaluate defect reports and change requests

Key Characteristic: The Unified Process integrates planning, modeling, construction, and deployment activities throughout all phases, with varying emphasis at different stages of development.

Agile Software Engineering

Software products must be brought to market quickly, so rapid software development and delivery is essential. Virtually all software products are now developed using an agile approach (except safety-critical systems, which are in direct opposition with agile manifesto and development principles).

Agile software engineering focuses on:

  • Delivering functionality quickly
  • Responding to changing product specifications
  • Minimizing development overheads

Agile Mindset: Values, Principles, and Practices

Agile is a mindset defined by 4 values, guided by 12 principles, and manifested through many different practices. Agile practitioners select practices based on their needs.

The Four Values of the Agile Manifesto

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Value 1

Individuals and interactions

over

processes and tools

Value 2

Working software

over

comprehensive documentation

Value 3

Customer collaboration

over

contract negotiation

Value 4

Responding to change

over

following a plan

That is, while there is value in the items on the right, we value the items on the left more.

The Twelve Principles Behind the Agile Manifesto

1. Satisfy the customer

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

2. Welcome changing requirements

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

3. Deliver working software frequently

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

4. Work together daily

Business people and developers must work together daily throughout the project.

5. Build projects around motivated individuals

Build projects around motivated individuals. Give them the environment and support their needs and trust them to get the job done.

6. Face-to-face conversation

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

Working software is the primary measure of progress.

8. Sustainable development

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

9. Technical excellence

Continuous attention to technical excellence and good design enhances agility.

10. Simplicity

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

11. Self-organizing teams

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

12. Reflect and adjust

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

Agile Methods

Agile is a blanket term for many approaches, including:

Scrum

Extreme Programming (XP)

Kanban

Lean

Crystal

FDD (Feature-Driven Development)

DSDM

AUP (Agile Unified Process)

Process Feature Matrix

Process Distinct Phases Incremental Delivery Iterative Evolving Specification Timeboxed Iterations Risk Management
Waterfall
Incremental
Evolutionary
Spiral
Unified Process
Generic Agile
Scrum

Key Points Summary

  • Software processes are the activities involved in producing a software system. Software process models are abstract representations of these processes.
  • Traditional process models describe the organization of software processes. Examples include the waterfall model and incremental development.
  • Requirements engineering is the process of developing a software specification.
  • Design and implementation processes are concerned with transforming a requirements specification into an executable software system.
  • Software validation is the process of checking that the system conforms to its specification and that it meets the real needs of the users of the system.
  • Software evolution takes place when you change existing software systems to meet new requirements. The software must evolve to remain useful.
  • Processes should include activities such as prototyping and incremental delivery to cope with change.
  • Processes may be structured for iterative development and delivery so that changes may be made without disrupting the system as a whole.
  • Component-based development is based on software reuse where systems are integrated from existing components.
  • Agile approaches focus on rapid delivery, customer collaboration, and responding to change, with various methodologies like Scrum and XP providing specific practices.