Software Processes

Chapter 2
Software Engineering Fundamentals
Learning Objectives

Understand software processes and process models

Learn three general software process models and their applications

Explore fundamental process activities: requirements, development, testing, evolution

Understand why processes must adapt to changing requirements

Grasp software process improvement concepts and quality factors

What is a Software Process?

A set of related activities that leads to the

Key Points: No universal process exists • Depends on software type,
production of a software system customer requirements, and developer skills
Four Fundamental Activities

1. Software Specification 2. Software Development

3. Software Validation 4. Software Evolution

Software Process Models

Waterfall Model
Sequential phases of development

Incremental Development
Process models are simplified representations of software processes from a
Interleaved activities, multiple
particular perspective
versions

Integration and
Configuration
Reuse-oriented with existing
components
Agile vs. Plan-Driven Approaches

Plan-Driven Agile

All activities planned in advance Incremental planning

Progress measured against plan Continuous customer involvement

Heavy documentation Minimal documentation

Best for stable requirements Best for changing requirements

Plan-driven processes are processes where all of the process Agile processes, planning is incremental and it is easier to
activities are planned in advance and progress is measured change the process to reflect changing customer
against this plan. requirements.
Waterfall Model: Plan-Driven Approach

The first published model of software development, representing software as a linear sequence of phases

Core Principle Documentation Focus

Each phase must be complete before moving to the next phase Produces comprehensive documentation at each stage

Plan-driven: All activities are planned in advance, progress measured Sequential: Development flows downward through phases like a
against plan waterfall
Waterfall Model: Five Major Phases

1. Requirements Analysis and Definition

2. System and Software Design

3. Implementation and Unit Testing

4. Integration & System Testing 5. Operation and Maintenance

The waterfall model
When Waterfall Model Works Best

Appropriate only when requirements are well understood and unlikely to change during development

Embedded Systems
Software closely interacts with hardware systems. Hardware may be specially designed, so important design decisions must be made early—they
cannot be delayed until system is implemented.

Critical Systems
Systems where extensive safety and security analysis is essential. Complete analysis of specifications and design required before implementation
begins.

Large Software Systems (Multi-Company)

Part of broader engineering project. Complete specifications needed for different companies to develop independent subsystems.
Waterfall Model: Challenges

Major Issue: Difficulty accommodating change after process starts. One phase must complete before moving to next.

Inflexible Partitioning Late System Delivery

Hard division into distinct stages makes it difficult to respond to changing Working version only available late in project lifecycle, making early
customer requirements problem discovery difficult

Requirements Commitment Rarely Matches Reality

Customers must commit to all requirements early, but full understanding Few business or personal systems have stable requirements, so plan-
often emerges only after seeing software driven approach creates problems
Incremental Development Overview

Based on idea of developing initial implementation, exposing to user feedback, and evolving through several
versions until adequate system developed

Interleaved Iterative Feedback-Driven

Activities not separate Continuous refinement Users guide evolution

Most Common Approach: Used for most types of application systems and software products today
Incremental Development: How It Works

Specification, development, and validation activities are interleaved with rapid feedback across activities

Outline Description Concurrent Activities

Start with outline requirements. Do not develop detailed specification. Development, specification, and testing proceed in parallel with continuous
interleaving.

System Versions
Early increments serve as prototypes to explore requirements. System functionality evolves as new increments developed and delivered. Final increment delivers
all required functionality.
Incremental development
Incremental Development: Three Benefits

Cost of Accommodating Change Reduced

Amount of analysis and documentation that has to be redone is much less than required with waterfall model

Easier Customer Feedback

Customers can comment on demonstrations of software and see how much has been implemented. Easier than document-based discussions.

More Rapid Delivery of Useful Software

Customers able to use and gain value from software earlier than possible with waterfall process. Even if not all functionality included.
Incremental Development: Problems

Process Not Visible System Structure Degrades

Managers need regular deliverables to measure progress. With rapid As new increments added, regular changes corrupt software structure.
development, not cost-effective to produce documents reflecting every Software becomes increasingly complex and costly to change. Unless
version. Difficult to measure progress. time and money spent on refactoring.

Agile Solution: Methods suggest regular refactoring to reduce structural degradation and maintain clean code
Integration and Configuration Model

Relies on availability of reusable software components or COTS systems (Commercial Off-The-Shelf)

Stand-alone Applications Component Collections Web Services

Complete systems configured for specific Objects/packages integrated with frameworks Developed according to service standards,
environments invoked remotely

Key Principle: Integrate and configure existing systems rather than building from scratch
Reuse-Oriented Process Stages

1. Component Analysis

2. Requirements Modification

3. System Design with Reuse

4. Development and Integration

Reuse-oriented software engineering
Software Specification: Requirements

Requirements Engineering: Process of establishing what services customers require and what constraints exist on
system operation and development

Critical Stage: Errors at this stage inevitably lead to later problems in system design and implementation

User Requirements System Requirements

High-level abstract statements understandable by users Detailed description of exactly what should be implemented
Requirements Engineering Process

Three main activities with iterative and interleaved execution

1. Requirements Elicitation and Analysis

2. Requirements Specification

3. Requirements Validation
Software Design and Implementation

Process of converting system specification into an executable system

Software Design Implementation

Description of structure of software to be implemented, data models and Process of realizing the design as a program - translating design into
structures, interfaces, and sometimes algorithms executable code

Plan-Driven Processes: Design and implementation separate stages with formal design document

Agile Approaches: Design and implementation interleaved, no separate design document

Design Process Activities

Four key design activities that may be organized differently depending on system type

1. Architectural Design 2. Database Design

Identify overall structure of system, principal components Design system data structures and how represented in database.
(subsystems/modules), their relationships, and how distributed. Output is Influenced by whether existing database reused or new database created.
architectural model.

3. Interface Design 4. Component Selection/Design

Define interfaces between system components. Specification must be Search for reusable components. If unavailable, design how component will
unambiguous. Components can be developed without others interfering. operate. May be simple statement or detailed design model.
Software Validation: Overview

Verification and Validation (V&V): Show that system both conforms to its specification and meets expectations of
system customer

Program Testing Inspections and Reviews

Principal validation technique where system executed with test data. Analysis and checking of system representations at each stage. May be
Defects discovered where behavior incorrect or conforms to spec. applied to requirements, design, configuration data, test data.

Critical: System should be tested incrementally, component by component, not as single monolithic unit
Testing Stages: Three Levels

Component Testing System Testing Customer Testing

Software Evolution

Software is inherently flexible and can change. Changes to software cost less than changes to hardware.

Paradigm Shift in Thinking

Distinction between development and maintenance increasingly irrelevant. Better to think of software engineering as evolutionary process where
software continually changed over lifetime in response to changing requirements and customer needs.

Old View Modern View

Development then maintenance as separate Continuous evolution throughout lifetime
Coping with Change: Overview

Change is inevitable in all large software projects. Business changes, new technologies emerge, platforms change. Processes must
accommodate changes without excessive costs.

Change Anticipation Change Tolerance

Process includes activities that can anticipate possible changes Process designed so changes can be accommodated at low
before significant rework required. Example: prototype system cost. Normally involves iterative development and limiting
shown to customers so they can refine requirements. specification documentation. Example: incremental development.
Prototyping for Change

A prototype is an early version of system used to demonstrate concepts, try Benefits of Prototyping
design options, and find problems
Improves System Usability

Key Uses:
Closer Match to Needs
Requirements elicitation and validation

Improved Design Quality

Explore particular software solutions

Maintainability Enhanced
Develop user interfaces

Reduced development effort

Incremental Delivery

Rather than single delivery, system development and deployment broken down into increments, each delivering part of
required functionality

Advantages Problems
Early increments act as prototypes, customers gain value earlier, highest- Most systems require basic set of facilities, difficult to identify common
priority services receive most testing, lower risk of overall project facilities, conflicts with procurement model

Important: Incremental development and incremental delivery are NOT the same

Incremental development: Develop the system in Incremental delivery: Deploy an increment for use by end-
increments and evaluate each increment before proceeding users. More realistic evaluation. Difficult to implement for
to the development of the next increment replacement systems as increments have less functionality
than the system being replaced.
Process Improvement: Introduction

Process of understanding existing processes and changing them to increase product quality, reduce costs, or accelerate schedules

Process Maturity Approach

Agile Approach
Process Improvement Cycle

Continuous cyclical process of improvement activities

Process Measurement
Measure attributes of current process. Derive set of metrics that provide insights into process effectiveness.
Examples: Time taken for process activities to be completed, resources required for processes or activities, number of occurrences of a particular
event

Process Analysis
Analyze current process to identify weaknesses and bottlenecks. Process models help understand activities involved.

Process Change
Make proposed process changes. Changes may be organizational, structural, or require new tool introduction.
 Capability Maturity Model (CMM)
Framework for assessing maturity of software processes. Defines five capability levels representing increasingly organized and
effective processes.

Process Maturity Levels: Details

Initial
Project goals achieved, work scope defined. Ad hoc process.

Managed
Policies define process use, documented project plans, resource management, quality assurance, configuration management.

Defined
Organizational set of standard processes, measurements and targets established, continuous improvement.

Quantitatively Managed
Statistical and quantitative techniques control performance, predictable processes.

Optimizing
Quantitative feedback drives continuous process improvement, innovative technology deployed.
Key Takeaways from Chapter 2

Software processes are complex sets of activities for specification, Three general models: Waterfall (plan-driven), Incremental (most
design, implementation, and testing common), Integration and Configuration (reuse)

Four fundamental activities: Requirements engineering, Design, Coping with change through prototyping (anticipation) or incremental
Implementation, Validation delivery (tolerance)

Software evolution is continuous—no clear distinction between Process improvement cycle: measure, analyze, change processes to
development and maintenance increase quality

No universal process works for all systems—choose based on type, organizational culture, and team experience
Questions?

Questions?
Chapter 2: Software Processes