[3] Software Development Process Model

People (in software development)

One of the three cornerstones needed to produce a successful software product, referring to the individuals involved in the process.

Projects (in software development)

One of the three cornerstones needed to produce a successful software product, representing the specific undertakings to develop software.

Processes (in software development)

One of the three cornerstones needed to produce a successful software product; part of a software life cycle model or methodology.

Software Life Cycle Model/Methodology

A framework of processes used for developing and maintaining software.

Project Tasks and Processes

Defined in a project schedule and developed based on the adopted process paradigm/model or methodology.

Importance of Processes

They guarantee that the developed software product possesses good qualities.

Impact of Poor Process Model Selection

Affects the quality of the delivered software project.

Need for Industry-Proven Models

To manage software activities and increase the quality of software developed and maintained.

Benefits of Software Engineering Life Cycle Models

Provide systematic and well-structured approaches, often supported by tools for effective use.

Tailoring Life Cycle Models

Can be adapted based on organizational size, maturity level, and software complexity.

Software Engineering Process Model (Life-cycle Model/Strategy/Paradigm/Method)

Chosen based on project nature, application, methods, tools, controls, and required deliverables.

Generic Stages in Software Development (Regardless of Model)

Definition, Implementation, and Maintenance.

Major Categories of Software Engineering Process Models

Linear Models and Variants, Iterative or Prototyping, and Evolutionary Model.

Linear Models

Software development models characterized by a sequential flow of phases.

Classic System Development Life Cycle (SDLC) / Waterfall Approach / Software Life Cycle / Linear Sequential Model

A linear model that demands a systematic, sequential approach from system level through analysis, design, coding, testing, and maintenance.

Analysis Phase (Waterfall Model)

Establishes system services, constraints, and goals through user consultations; includes requirements definition, interface definition, and prioritization.

Requirements Specification Document (Waterfall Analysis)

The main output of the analysis phase, detailing the defined and prioritized software requirements.

Other Deliverables of Analysis Phase (Waterfall)

Acceptance test plan document, scope and vision document, and revised project plan.

System/Software Design Phase (Waterfall Model)

Establishes an overall system architecture and plans a solution based on the requirements document.

Activities in Design Phase (Waterfall)

High-level architectural design, database design, interface design, and detailed designs.

Design Specifications Document (Waterfall Design)

The main deliverable of the design phase, encompassing high-level and detailed design documents.

High-Level Design (Waterfall)

Focuses on identifying software modules and their interfaces.

Detailed Design (Waterfall)

Provides details on each module, including data structures and algorithms.

Database Design (Waterfall)

Presents a detailed description of the database schema based on the Requirements Specifications Document.

Interface Design (Waterfall)

Designs graphical user interface components and all interfaces with other systems/devices.

Verification of Designs (Waterfall)

Can be done by building executable design models or prototypes.

Implementation Phase (Waterfall Model)

Translates the system and software design into programs or program units (executable code) using a suitable programming language.

Database Implementation (Waterfall)

The database design is implemented, integrated with the code, and potentially populated with initial data.

Testing and Integration Phase (Waterfall Model)

Executes test plans, tests individual units (Unit Test), then tests the complete system (Integration and System Test) to ensure requirements are met.

Validation (in Testing)

Testing performed against the original requirements.

Verification (in Testing)

Testing performed against design specifications.

Deliverable of Testing and Integration (Waterfall)

The integrated software.

Operation and Maintenance Phase (Waterfall Model)

The system is installed and put into practical use based on the installation and deployment plan.

Client/User Testing (Waterfall)

Users test the system's usability and applicability based on the acceptance test plan.

Deliverables of Operation and Maintenance (Waterfall)

The official acceptance document signed by the client and the properly installed software system.

Characteristics of the Waterfall Model

Sequential and generally one-way phases, early deadline determination, completely and unambiguously determined results, milestone document suite concluding each phase, applicability to large and small projects, ideal with available resources, applicable with fully documented standard procedures.

Advantages of the Waterfall Model

Divides complex tasks, allows careful planning, clear delineation of responsibilities, clear phases with specified inputs/deliverables/milestones for progress assessment, easy to apply and understand, detailed documents reduce future maintenance costs.

Disadvantages of the Waterfall Model

Rarely follows sequential flow in real projects, difficulty for customers to state all requirements explicitly, working version available late, discourages late changes, depends on stable requirements, excessive documentation, may lead to "blocking state".

Main Drawback of the Waterfall Model

Difficulty of accommodating change after the process begins; one phase must complete before the next.

Consequences of Ignoring Requirements Ambiguity (Waterfall)

Potential severe consequences, including higher repair costs later.

Fountain Model / Iterative Waterfall

A variant of the waterfall model where iteration to previous phases ("water can flow upwards") is recognized as necessary.

Advantage of Fountain Model

More realistic as it allows revisiting preceding phases if needed.

Disadvantage of Fountain Model

More difficult to control, hence the need for change control procedures.

Rapid Application Development (RAD) Model

A linear sequential model emphasizing an extremely short development cycle through component-based construction.

RAD Teams

Separate teams address each major function in a project and then integrate their work.

Business Modeling Phase (RAD)

Models information flow among business functions, answering questions about what drives, generates, goes, and processes information.

Data Modeling Phase (RAD)

Refines the information flow into data objects needed to support the business, identifying attributes and relationships.

Process Modeling Phase (RAD)

Transforms data objects to achieve the necessary information flow for business functions, creating processing descriptions for data manipulation.

Application Generation Phase (RAD)

Assumes the use of fourth-generation techniques, reusing or creating reusable components and using automated tools.

Testing and Turnover Phase (RAD)

Emphasizes reuse, reducing overall testing time, but requires testing of new components and interfaces.

Problems With RAD

Requires sufficient human resources for large projects, committed customers and developers for rapid-fire activities, not suitable for poorly modularized systems, high-performance requirements, or high technical risks.

Other Linear Life-Cycle Strategies

Model Systems Ltd (NCC-UK), Foundation (Andersen Consulting), Structured Project Life-cycle (Yourdon group).

Iterative or Prototyping Model

A process where developers create a model (prototype) to understand customer requirements before delivering the final system, proceeding in iterations.

Prototype

An executable program implementing mainly the functional aspects related to the graphical user interface.

Customer Feedback (Prototyping)

Provided on the prototype in each iteration, continuing until the customer is satisfied.

Types of Prototypes

PC-model (human-machine interactions), working software (subset of functions), existing program (performs desired functions but will be improved).

Characteristics of Prototyping Model

Starts with incomplete requirements, full requirements derived from user interaction, three types based on code retention.

Prototyping with Disposable System

Tests solution adequacy; requirements formalized after prototype feedback; prototypes discarded, and development follows a linear sequential model.

Prototyping with Working System

A prototype of critical functions is built and, after acceptance, extended to a working system.

Evolutionary Prototyping

Prototype adapts to changing requirements; subsequent prototypes evolve into the operational system; the final prototype is used for deployment.

Ideal Applications for Prototyping

Systems with defined requirements but unknown human-computer interface suitability, or systems the developer has not seen before.

Advantages of Prototyping Model

No need for uniquely determined requirements initially, requirements can change, delivers clear system definition to users, enhances communication about interfaces, increases user involvement and satisfaction, development environment can be tested quickly, can demonstrate feasibility.

Disadvantages of Prototyping Model

Rising user expectations (seeing a seemingly working version), danger of never-ending development due to user interaction, risk of neglecting planning/verification/validation/documentation, danger of modeling before sufficient analysis, risk of design/implementation compromises for quick prototypes, building on prototypes can lead to failure.

Prototyping as a Tool

Clarifies requirements, explores design alternatives, tests solution adequacy.

Addressing Waterfall Model Weaknesses with Prototyping

Reliance on written documentation for requirements can be inappropriate for user-centered systems; approved written requirements can be volatile.

Benefits of Prototyping Requirements

Building a visual and executable model allows effective review and approval, reducing risks of later changes and fewer revisions/iterations.

Evolutionary Model

An iterative approach where software engineers develop increasingly complete versions of the software.

Starting Point of Evolutionary Model

The problem domain needing a software or automated solution.

Steps in Evolutionary Model

(1) Delineate functional boundaries, (2) Split into Microsystems, (3) Develop and deploy microsystem (<= 6 months), (4) Reassess long-term goals and adjust subsequent microsystems; repeat steps 3 and 4.

Characteristics of Evolutionary Model

Product-oriented, iterative (all phases in each iteration), continuous testing and re-planning based on long-term goals.

Advantages of Evolutionary Model

Faster results for developers, fast response and visible product evolution for users/management, fast reaction to changed goals, better manageability through incremental construction and continuous control.

Disadvantages of Evolutionary Model

No scheduled recursion to previous microsystems, changing environments may obliterate long-term goals, can be costly.

Examples of Evolutionary Development

Incremental Model and Spiral Model.

Incremental Model

Combines linear sequential elements with prototyping's iterative philosophy; each linear sequence produces a deliverable "increment".

First Increment (Incremental Model)

Often the core product addressing basic or high-priority requirements.

Subsequent Increments (Incremental Model)

Address medium and low priority requirements, modifying the core product and adding features.

Advantages of Incremental Model

Operational product with each increment, reduced risk of failure and changing requirements, user can adjust to new technology incrementally.

Disadvantages of Incremental Model

Lack of process visibility (hard to determine progress to final version), often poorly structured systems, may require special skills (e.g., rapid prototyping languages).

Recommendations for Incremental Model

Applicable for small growing companies, useful with limited/critical budget, requirements should be clear, releases carefully scheduled, produce specifications before coding.

Usefulness of Incremental Approach

When technical requirements or staffing is unavailable for complete implementation by the deadline.

Spiral Model

Couples prototyping's iterative nature with the linear sequential model's controlled aspects; software developed in incremental releases.

Task Regions/Framework Activities (Spiral Model)

Customer communication, planning, risk analysis, engineering, construction and release, customer evaluation.

Planning Region (Spiral Model)

Results in adjustments to the project plan; cost and schedules adjusted based on customer feedback.

Risk Analysis (Spiral Model)

A key aspect involving assessment of both technical and managerial risks.

Prototyping in Spiral Model

Can be applied at any stage of evolution as a risk reduction mechanism.

Throw-Away Prototypes (Spiral Model)

May or may not be required in each phase as part of risk reduction.

Advantages of Spiral Model

Splits large efforts into small chunks (high-risk functions first), takes advantage of incremental release, cumulative costs can be assessed, rapid application development can be used.

Disadvantages of Spiral Model

Complex model, potentially too complicated and costly, no clear distinct phases (difficult to manage), additional documentation needed for intermediate stages.

Recommendations for Spiral Model

Ideal for large-scale systems (not small projects due to cost), applicable with high risks, dynamic procedures/technology, lack of expertise, and when the system can be broken down.

Addressing Waterfall Weakness (Spiral Model)

Includes formal and continuous consideration of risk management, enhancing software quality and project success.

Relative Use of Spiral Model

Relatively new and not yet widely used.

Concurrent Development Model / Concurrent Engineering

Allows tracking the status of extremely complex sets of activities, especially those occurring simultaneously within a phase.

Representation of Concurrent Model

Schematically as a series of major technical activities, tasks, and their associated states.

Focus of Concurrent Model

Defines a network of activities existing simultaneously, rather than a sequence.

Common Application of Concurrent Model

Development of client/server applications, but applicable to all types.

Advantage of Concurrent Model

Provides an accurate picture of the current project state.

Fourth Generation Techniques (4GT)

A broad array of software tools enabling high-level specification of software characteristics.

Examples of 4GT Tools

Non-procedural languages (database query, reports, data manipulation, screen interaction, code generation), high-level graphics, spreadsheet capability.

Focus of 4GT

Specifying software using specialized languages or graphic notation understandable by the customer.

Application of 4GT for Small Applications

Possible to move directly from requirements to implementation using a non-procedural language.