0% found this document useful (0 votes)
3 views10 pages

02 SW Process

The document outlines software processes, which consist of core activities such as specification, design, validation, and evolution. It discusses various process models, including the Waterfall Model and Incremental Development, highlighting their advantages and limitations. Additionally, it covers software prototyping, process activities, specification, validation, and the need for software evolution in response to changing requirements.

Uploaded by

Timur Turk
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
3 views10 pages

02 SW Process

The document outlines software processes, which consist of core activities such as specification, design, validation, and evolution. It discusses various process models, including the Waterfall Model and Incremental Development, highlighting their advantages and limitations. Additionally, it covers software prototyping, process activities, specification, validation, and the need for software evolution in response to changing requirements.

Uploaded by

Timur Turk
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd

02-sw-process.

md 2025-03-11

Software Processes
A structured set of activities required to develop a software system.

Core Activities
All software processes involve:

Specification – Defining what the system should do


Design and Implementation – Defining the organization of the system and implementing the system
Validation – Checking that it does what the customer wants
Evolution – Changing the system in response to changing customer needs

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

Process Description Components

Process descriptions may include:

Products – The outcomes of a process activity


Roles – The responsibilities of the people involved in the process
Pre- and Post-conditions – Statements that are true before and after a process activity has been
enacted or a product produced

Plan-driven and Agile Processes


Plan-driven Processes

Processes where all activities are planned in advance


Progress is measured against this plan

Agile Processes

Planning is incremental
Easier to change the process to reflect changing customer requirements

Note: In practice, most practical processes include elements of both plan-driven and agile approaches.

Software Process Models


1. The Waterfall Model

Plan-driven model
Separate and distinct phases of specification and development

2. Incremental Development

1 / 10
[Link] 2025-03-11

Specification, development and validation are interleaved


May be plan-driven or agile

3. Integration and Configuration

System is assembled from existing configurable components


May be plan-driven or agile

Note: Most large systems are developed using a process that incorporates elements from all of these models.

Waterfall Model

Key Phases

Requirements analysis and definition


System and software design
Implementation and unit testing
Integration and system testing
Operation and maintenance

Characteristics

Sequential, plan-driven approach


Each phase must be completed before the next begins
Best suited for projects with stable requirements

2 / 10
[Link] 2025-03-11

Limitations

Difficult to accommodate changes once started


Inflexible phase partitioning
Limited customer feedback until late stages

Best Use Cases

Large systems engineering projects


Multi-site development
Projects requiring strict coordination

Incremental Development

Advantages

Reduced Change Costs: Easier to accommodate requirement changes


Minimal Rework: Less analysis and documentation updates needed
Better Customer Feedback: Regular demonstrations of working software
Faster Delivery: Earlier access to useful software
Value Generation: Customers gain value from early releases

Disadvantages

Limited Process Visibility: The process is not easily visible to managers who need regular deliverables
to measure progress
3 / 10
[Link] 2025-03-11

Documentation Challenges: For rapidly developed systems, creating documentation for every version
becomes cost-prohibitive
Structural Degradation: System structure tends to degrade as new increments are added without
proper refactoring
Increasing Complexity: Over time, incorporating further changes becomes increasingly difficult and
costly
Maintenance Overhead: Regular refactoring is required to maintain code quality and structural
integrity

4 / 10
[Link] 2025-03-11

Incremental Delivery

Rather than deliver the system as a single delivery, the development and delivery is broken down into
increments with each increment delivering part of the required functionality.

User requirements are prioritised and the highest priority requirements are included in early increments.

5 / 10
[Link] 2025-03-11

Once the development of an increment is started, the requirements are frozen though requirements for later
increments can continue to evolve.

Advantages of Incremental Delivery

Early Value Delivery: Customer value can be delivered with each increment so system functionality is
available earlier
Requirements Elicitation: Early increments act as a prototype to help elicit requirements for later
increments
Reduced Project Risk: Lower risk of overall project failure
Prioritized Testing: The highest priority system services tend to receive the most testing

Disadvantages of Incremental Delivery

Common Facilities Challenge: Most systems require a set of basic facilities that are used by different
parts of the system
Architecture Planning Issues: As requirements are not defined in detail until an increment is to be
implemented, it can be hard to identify common facilities needed by all increments
Specification Evolution: The essence of iterative processes is that the specification is developed in
conjunction with the software
Procurement Conflicts: This conflicts with the procurement model of many organizations, where the
complete system specification is part of the system development contract

Software Prototyping

A prototype is an initial version of a system used to demonstrate concepts and try out design options.

Uses of Prototyping

6 / 10
[Link] 2025-03-11

In the requirements engineering process to help with requirements elicitation and validation
In design processes to explore options and develop a UI design
In the testing process to run back-to-back tests

Benefits of Prototyping

Improved System Usability: Better interfaces that meet user needs


Closer Match to User Needs: Better alignment with actual requirements
Improved Design Quality: Ability to refine design before full implementation
Improved Maintainability: Clearer understanding of system structure
Reduced Development Effort: Early identification and resolution of issues

Prototype Development

Rapid Tools: May be based on rapid prototyping languages or tools


Simplified Functionality: May involve leaving out functionality
Focused Scope: Prototype should focus on areas of the product that are not well-understood
Error Handling: Error checking and recovery may not be included in the prototype
Functional Priority: Focus on functional rather than non-functional requirements such as reliability and
security

Throw-away Prototypes

Prototypes should be discarded after development as they are not a good basis for a production system:

Performance Limitations: It may be impossible to tune the system to meet non-functional


requirements
Documentation Gaps: Prototypes are normally undocumented
Structural Issues: The prototype structure is usually degraded through rapid change
Quality Concerns: The prototype probably will not meet normal organisational quality standards

7 / 10
[Link] 2025-03-11

Process Activities
Real software processes are inter-leaved sequences of technical, collaborative and managerial activities with
the overall goal of specifying, designing, implementing and testing a software system.

The four basic process activities of specification, development, validation and evolution are organized
differently in different development processes.

For example, in the waterfall model, they are organized in sequence, whereas in incremental development
they are interleaved.

8 / 10
[Link] 2025-03-11

Software Specification

The process of establishing required services and constraints for system operation and development.

Requirements Engineering Process

Requirements Elicitation and Analysis: Determining stakeholder requirements and expectations


Requirements Specification: Defining requirements in detail
Requirements Validation: Checking requirement validity

Design Activities

Architectural Design: Identifying overall system structure, principal components, relationships, and
distribution
Database Design: Creating system data structures and database representations
Interface Design: Defining interfaces between system components
Component Selection/Design: Searching for reusable components or designing new ones

Software Validation

Verification and validation (V & V) demonstrates that a system meets specifications and customer
requirements.

Review Processes: Systematic examination of system artifacts


System Testing: Executing the system with test cases derived from specifications

9 / 10
[Link] 2025-03-11

Test Data: Using real or realistic data for validation

Testing is the most commonly used V & V activity.

Testing Stages

Component Testing: Individual components are tested independently; may include functions, objects,
or cohesive groups of these entities
System Testing: Testing the system as a whole, with particular focus on emergent properties
Customer Testing: Testing with customer data to verify the system meets user needs

Software Evolution

Software is inherently flexible and must adapt to changing business requirements.

Continuous Change: Software must evolve as business circumstances change


Blurred Boundaries: Traditional separation between development and maintenance (evolution) is
increasingly irrelevant
Iterative Nature: Most modern systems evolve through continuous enhancement rather than complete
replacement

10 / 10

You might also like