Software Development Process

Fundamental Concepts of Software Process Models

• Definition of Software Process Model: As introduced in Lecture $1$, a software process model is defined as "A simplified representation of a software process, presented from a specific perspective."

• Generic Software Process Activities:

  • Specification: Involved in determining what the system should do and identifying its development constraints.

  • Development: The actual production of the software system.

  • Validation: The process of checking that the software meets the customer's requirements and desires.

  • Evolution: The ongoing process of changing the software to respond to changing demands.

• General Types of Models:

  • Traditional

  • Evolutionary

  • Component Based

  • Iterative and Incremental

  • Agile

Traditional Development: The Waterfall Model

• Sequential Phases: Transitioning from one phase to another requires the previous phase to be finished completely.

  • $1$. Requirement Analysis

  • $2$. Specification

  • $3$. Design

  • $4$. Implementation

  • $5$. Testing and Integration

  • $6$. Operation and Maintenance

• Characteristics and Observations:

  • Structured and theoretically easy to manage.

  • Rigidity: It is a rigid process where one phase must conclude before the next begins.

  • Requirement Stability: Theoretically assumes stable requirements; however, the nature of software development involves ever-changing customer requirements and very few stable ones.

  • Failure Rate: Statistics indicate that $40\%$ of software fails because of issues related to requirements.

  • Applicability: Suitable for large projects coordinated across many sites.

  • Improvement: A variation known as the "Cyclic Waterfall" exists to address some inherent limitations.

Evolutionary Development Models

• General Core Outline: Specification, Development, and Validation are conducted as concurrent activities rather than sequential ones, producing an Initial Version, then Intermediate Versions, and finally the Final Version.

• Exploratory Development:

  • Objective: To work closely with customers to evolve a final system based on an initial outline specification.

  • Workflow: Begins with well-understood requirements. New features are added as proposed by the customer throughout the process.

  • Final Deliverable: The refined system.

• Throw-away Prototyping:

  • Objective: To "REALLY" understand system requirements, especially when clients do not know exactly what they want.

  • Workflow: Starts with poorly understood requirements to clarify needs. A prototype is built and then discarded once the client confirms the requirements. A completely new system is then built based on those clarified requirements.

• Applicability of Evolutionary Models:

  • Small or medium-sized interactive systems.

  • Specific parts of larger systems (such as the User Interface).

  • Short-lifetime systems.

• Problems with Evolutionary Models:

  • Lack of process visibility.

  • Systems are often poorly structured.

  • May require special skills, such as proficiency in languages specifically for rapid prototyping.

Component-Based Software Engineering (CBSE)

• Core Concept: Reusing existing components or COTS (Commercial-off-the-shelf) systems.

• Characteristics: A popular approach involving standard components that can be "plugged" in and used with minimal effort.

• Process Steps:

  • $1$. Requirements specification.

  • $2$. Component analysis.

  • $3$. Requirements modification (to fit available components).

  • $4$. System design with reuse.

  • $5$. Development and integration.

  • $6$. System validation.

Modern Approaches: Iterative and Incremental Development

• Incremental Development: A scheduling and staging strategy where various parts of the system are developed at different times or rates and integrated upon completion.

• Iterative Development: A rework scheduling strategy where time is set aside to revise and improve parts of the system. It does not presuppose incremental development but works effectively in tandem with it.

The Spiral Model

• Overview: The process is represented as a spiral rather than a linear sequence. Each loop represents a phase. There are no fixed phases; loops are chosen based on requirements.

• Focus: Risks are explicitly assessed and resolved throughout the entire process.

• Four Spiral Sectors:

  • Objective Setting: Identify specific objectives for the phase.

  • Risk Assessment and Reduction: Assess risks and implement activities to reduce key risks.

  • Development and Validation: Choose a development model (which can be any generic model).

  • Planning: Review the project and plan the next phase of the spiral.

• Procedural Steps:

  • $1$. Define new system requirements.

  • $2$. Analyze risk.

  • $3$. Create preliminary design.

  • $4$. Construct prototype from preliminary design.

  • $5$. Test the prototype.

  • $6$. Develop a second prototype following the evaluation of the first, defining requirements for the second, and designing it.

Agile Software Development

• Agile Process Flow:

  • Iteration $0$ (Initial Modeling): Identify high-level scope, initial "requirements stack," and architectural vision (takes days).

  • Development Iterations (Iteration $1$ to $n$): Develop working software in an evolutionary manner.

  • Model Storming: Work through specific issues in a Just-In-Time (JIT) manner (takes minutes).

  • Implementation: Ideally Test-Driven (takes hours).

• Well-Known Agile Methods:

  • Agile Modelling

  • Agile Unified Process (AUP)

  • Extreme Programming (XP)

  • Feature Driven Development (FDD)

Extreme Programming (XP)

• Objectives: To improve software quality and responsiveness to changing user requirements.

• Key Features:

  • Time-boxing and short development releases.

  • Pair Programming: Two developers work together at one workstation.

  • Unit Testing: Continuous testing during development.

  • Daily Stand-up Meetings: Brief meetings to coordinate tasks.

  • Feedback Loops: Cycles range from minutes (Pair Negotiation/Unit Test) to weeks (Iteration Plan) to months (Release Plan).

V-Model and Rational Unified Process (RUP)

• V-Model: Maps development phases to corresponding testing phases:

  • Business Case corresponds to Release Testing.

  • Requirements correspond to Acceptance Testing.

  • System Specification corresponds to System Testing.

  • System Design corresponds to Interface Testing.

  • Component Design corresponds to Component Testing.

• Rational Unified Process (RUP):

  • Origin: Created by IBM in $2003$.

  • Nature: An adaptable, iterative framework intended to be tailored to specific project needs.

  • Building Blocks:

    • Roles (Who): Defines a set of related skills, competences, and responsibilities.

    • Work Products (What): Represents deliverables, including documents and models (e.g., SRS, design models).

    • Tasks (How): Describes a unit of work assigned to a role that provides a meaningful result.

  • Phases:

    • Inception

    • Elaboration

    • Construction

    • Transition

  • Disciplines: Includes $6$ engineering disciplines (Business Modeling, Requirements, Analysis & Design, Implementation, Test, Deployment) and $3$ supporting disciplines (Configuration & Change Mgmt, Project Management, Environment).

Detailed Process Activities and Outputs

• Requirement:

  • Capture user problems and desires via various techniques.

  • Outputs: Software Development Plan (SDP), Software Requirement Analysis (SRA), and documentation of requirement capturing sessions.

• Specification:

  • Models the requirements and involves sketching user interfaces.

  • Outputs: Software Requirement Specification (SRS).

• Architecture:

  • Defines high-level design (e.g., Stand-alone, Web-based, Client-Server).

  • Identifies modules and components.

  • Outputs: High Level Design (HLD), Integration Test Plan (ITP).

• Design:

  • Writes functions and algorithms; determines system behavior.

  • Outputs: Software Detail Design (SDD), Unit Test Plan (UTP).

• Implementation:

  • Coding, debugging, code review, and module integration.

  • Outputs: Result of Unit Test Plan.

• Testing:

  • Includes Integration Testing, Debugging, and User Acceptance Test (UAT).

  • verifies requirements in SRA and SRS.

  • Outputs: Software Test Result (STR).

• Deployment:

  • Handover, installation at the client site, and training.

• Maintenance:

  • System operation, managing data, and handling change requests or additional features.

  • Maintenance is considered its own system life cycle.

Strategic Selection of Models

• Selection should be based on Time, Man-Power, and Resources.

• Models should be customized for the specific project.

• It is essential to adhere to established milestones.