Software Processes and Models

Software Processes Overview

• Software processes consist of structured activities to develop a software system.
• Multiple software processes exist, commonly involving specification, design, implementation, validation, and evolution.
• A software process model offers an abstract representation of a process from a specific viewpoint.
• Software process descriptions detail activities like specifying data models or designing user interfaces.
• Process descriptions can include products, roles, and pre- and post-conditions.

Plan-Driven vs. Agile Processes

• Plan-driven processes involve advance planning of all activities with progress measured against the plan.
• Agile processes use incremental planning, adapting to evolving customer needs.
• Practical processes often blend plan-driven and agile elements, and no software process is inherently superior to another.

Software Process Models

• The waterfall model is plan-driven, segmenting activities into distinct phases like requirement specification, design, implementation, and testing.
• Incremental development interleaves specification, development, and validation, possibly being plan-driven or agile.
• Reuse-oriented software engineering uses existing components to assemble the system and can be plan-driven or agile.
• Most large systems utilize a development approach that combines aspects of all the models.

Waterfall Model

• Involves distinct phases: requirements analysis/definition, system/software design, implementation/unit testing, integration/system testing, operation/maintenance.
• It can be difficult to accommodate changes mid-process, requiring phase completion before moving forward.
• Partitioning projects into inflexible stages hinders adapting to changing customer needs.
• It is appropriate when a project's requirements are well-understood with limited changes during design.
• It is often used for large systems developed across multiple locations as its plan-driven nature aids work coordination.

Incremental Development

• Reduces costs for accommodating changing customer needs.
• Generates less analysis and documentation than the waterfall model.
• Facilitates customer feedback on development with software demonstrations.
• Makes rapid software deployment possible for customers.
• Allows earlier customer use and value gain compared to the waterfall process.
• Can suffer from a lack of visibility and can be costly to produce documents that reflect every version of the system.
• The system's structure can be compromised as increments are added.

Reuse-Oriented Software Engineering

• A systematic approach that integrates pre-existing components or COTS (Commercial-off-the-shelf) systems.
• Process steps include component analysis, requirements modification, system design with reuse, development, and integration.
• Component types include web services with standard-based remote invocation, object collections for integration (.NET, J2EE), and configurable standalone systems (COTS).

Process Activities

• Real software processes interleave technical, collaborative, and managerial activities.
• They are aimed at specifying, designing, implementing, and testing software systems.
• Specification, development, validation, and evolution activities are organized differently based on the development process.

Software Specification

• Establishes needed services and system constraints.
• The requirements engineering process involves feasibility studies, requirements elicitation/analysis, specification, and validation.

Software Design and Implementation

• Converts system specifications into executable systems.
• Software design involves designing a structure that realizes the specification.
• Implementation involves translating this structure into a program.
• Design and implementation are closely related and may be interleaved.

Design Activities

• Architectural design identifies the system's overall structure and components, defining their overall relationships .
• Interface design defines interfaces between system components.
• Component design details the operation of each system component.
• Database design focuses on the system data structures and representation in a database.

Software Validation

• Verification and validation (V & V) shows that a system adheres to its specification and customer needs.
• V & V includes checking, reviewing, and system testing.
• Testing executes the system using test cases derived from real data specifications.
• Testing is the most common V & V activity.

Testing Stages

• Development/component testing focuses on individual components. These components are tested independently.
• System testing tests the whole system and emergent properties.
• Acceptance testing checks if the system meets customer needs with real data.

Software Evolution

• Software is flexible and adaptable.
• Software must evolve and be useful as business circumstances and requirements change.

Coping with Software Changes

• Change is unavoidable in big software projects.
• Business changes result in new system demands.
• New technology provides opportunities for implementation improvements.
• Changing platforms will require application modifications.
• Addressing change involves reworking, raising costs and requiring new functionality considerations.
• System prototyping and incremental delivery are two ways to deal with changes and evolving requirements.

Reducing Rework Costs

• Change avoidance incorporates activities to anticipate changes, reducing rework. Developing prototype systems and refining requirements with customer feedback aids in that anticipation.
• Change tolerance designs the process to accommodate changes at a lower cost, often through incremental development.
• Proposed changes can be made to undeveloped increments, or a smaller system may be changed to incorporate modifications.

Software Prototyping

• An initial system version used to show ideas and test design choices.
• Prototyping can assist with requirements engineering, validation, exploring design options, and testing.
• Prototyping provides key benefits like improved system usability, closer user need alignment, improved design quality, enhanced maintainability, and reduced development efforts.

Prototype Development

• It may rely on rapid prototyping languages or tools.
• May leave out functionality.
• Prototype highlights areas not fully understood, it may overlook error checking or prioritize functional over non-functional reliability/security issues.

Throwaway Prototypes

• Prototypes may be discarded post-development because they might lack suitability for production.
• Tuning systems to fulfill functional needs could be difficult.
• Prototypes may lack documentation, exhibit degraded structure, and fail to satisfy quality standards.

Incremental Delivery

• Development breaks down into increments, each providing functionality, instead of delivering as one package.
• Prioritizes user needs, addressing peak requirements into earlier deployments.
• Continues assessment with the aim being requirements for subsequent phases.

Incremental Development and Delivery

• Incremental development develops and evaluates each increment before moving on to the next. It is commonly used in agile methods and uses user/customer evaluations.
• Incremental delivery deploys increments for end-user application, giving practical use evaluation, but may be arduous to incorporate as replacements due to minimal capacity.

Incremental Delivery Advantages

• Customer value emerges throughout with functionality available immediately.
• Early increments are prototypes to formulate additional phase requests.
• Lower chance of total cancellation as well as most tested system programs.

Incremental Delivery Problems

• Rework can be difficult with replacement systems due to user resistance.
• Complete user needs with the original framework makes reception difficult.
• System model conflicts with acquisition model.
• Contract requires complete system setup.

Boehm's Spiral Model

• A risk-driven framework created by Boehm replaces the common activity-based sequence with a spiral shape.
• Each spiral cycle embodies phase-specific models, which combines change avoidance with tolerance centered on project risks and management.
• Risks must be defined, measured and adapted, which is part of reduction activities.

Spiral Model Sectors

• Establish concrete targets for progress toward development while decreasing main concerns throughout activity establishment.
• Choose system development that conforms to model through generic forms to meet validation.
• Analyze planned processes by assessing project stage relative to the cycle.

Spiral Model Usage

• The spiral is influential among people.
• Thinks of stages during iterative model creation through implementing hazard driving, yet it has never been directly applied for use in common cases.

The Rational Unified Process

• Is a modern process taken from UML practices and is supported by aspects of past procedures.
• Is analyzed from three angles, or time driven displays, process activity and exercise supported practice.

RUP Phases

• System cases are developed to highlight the process, understanding sphere and development creation through programs/testing.
• A transition deploys into an operating context.

RUP Iteration

• Every point is developed during gradual iteration. The model enacts full sets of increments in succession.