Software Processes and Models

• Software processes are the activities involved in producing a software system.

Software Process Models

• Software process models are abstract representations of software processes.
• Process activity models show activities and their sequence, but may not show the people involved.
• Common process activities include specifying a data model and user interface design.

Plan-driven and Agile Processes

• Plan-driven processes plan all activities in advance, tracking progress against the plan.
• Agile processes incrementally plan and easily change the process.
• In practice, most processes include elements of both approaches.
• There are no right or wrong software processes.

Waterfall Model

• The waterfall model includes requirements definition, system and software design, implementation and unit testing, integration and system testing, and operation and maintenance.

Incremental Development

• This approach interleaves specification, development, and validation activities
• The system is developed as a series of versions (increments), with each version adding functionality to the previous version.
• Incremental software development is better than a waterfall approach for most business, e-commerce, and personal systems.
• Concurrent activities include specification, development, and validation creating initial, intermediate, and final versions.
• Managers need deliverables to measure progress, quick system development may not be cost-effective if documentation is required.
• The system structure degrades as new increments are added.

Reuse-Oriented Software Engineering

• Stages include: requirements specification, component analysis, requirements modification, system design with reuse, development, and integration, and system validation
• There are three types of software components:
• Web services developed according to service standards and available for remote invocation,
• Collections of objects developed as a package to be integrated with a component framework such as .NET or J2EE
• Stand-alone software systems configured for use in a particular environment, like word processing or a spreadsheet
• Advantages include reducing the amount of software to develop, and reducing costs and risks.
• It usually leads to faster software delivery.
• Requirements compromises are inevitable and may lead to systems not meeting users' needs.
• There is some control lost in the system evolution as new versions of reusable components are not under the control of the organization using them.

Process Activities

• Real software processes are inter-leaved sequences of technical, collaborative, and managerial activities.
• The overall goal is to specify, design, implement, and test a software system.
• Four basic process activities of specification, development, validation, and evolution are organized differently in different development processes.
• In the waterfall model, activities are organized in sequence, whereas in incremental development they are interleaved.

Software Specification - 1

• This includes establishing services required and the constraints on the system's operation and development.
• The requirements engineering process includes feasibility study, requirements elicitation and analysis, requirements specification, and requirements validation.
• Feasibility Study: Is it technically and financially feasible to build the system?
• Requirements Elicitation and Analysis: What do the system stakeholders require or expect?
• Requirements Specification: Define the requirements in detail.
• Requirements Validation: Check the validity of the requirements.
• Final output of the specification activity of the software process is Requirements Document.

Software Design and Implementation

• Software design includes designing a software structure that realises the specification
• Implementation includes translating this structure into an executable program;
• Design and implementation activities are closely related and may be inter-leaved.
• Activities include architectural design, interface design, component design and database design.

Design Activities

• Architectural design identifies the overall structure of the system
• Principal components are sometimes called sub-systems or modules, their relationships, and how they are distributed.
• Interface design: defining the interfaces between system components
• Component design: how each system component will operate
• Database design: design system data structures and how these are to be represented in a database

Testing and Validation

• Alpha testing (acceptance testing) is for custom systems, being developed for a single client.
• The alpha testing process continues until the system developer and the client agree that the delivered system is an acceptable implementation of the requirements.
• Beta testing is used when a system is to be marketed as a software product.
• Beta testing delivers a system to a number of potential customers who agree to use that system.

Software Evolution - 4

• Software evolution takes place when existing software systems are changed to meet new requirements. The software must evolve to remain useful.

Coping with Change

• Change is inevitable in all large software projects.
• Business changes lead to new and changed system requirements.
• New technologies open up new possibilities for improving implementations.
• Changing platforms require application changes
• Costs of change include both rework and implementing new functionality.

Software Prototyping

• Benefits include:
• Improved system usability;
• Closer match to user needs;
• Improved design quality;
• Improved maintainability;
• Reduced development effort.
• Process of prototype development:
• Establish Prototype Objectives, Prototyping Plan
• Define prototype functionality, Outline definition
• Develop prototype, Executable prototype
• Evaluate prototype, Evaluation report

Incremental Development and Delivery

• Develop the system in increments and evaluate each increment before proceeding to the development of the next increment.
• This is normal approach used in agile methods.
• Evaluation is done by user/customer proxy.
• Incremental Delivery Process:
• Deploy an increment for use by end-users;
• A realistic evaluation is provided about practical software use.
• A difficult process to implement of replacement systems as increments have less functionality than the system being replaced.

Boehm's Spiral Model of the Software Process

• The model helps determine objectives, alternatives, identify and resolve risks, and evaluate results.

Spiral Model Usage

• The Spiral model is influential in helping people think about iteration in software processes.
• The model is influential in introducing the risk-driven approach to development.
• The model is not often used as published for practical software development

Rational Unified Process

• A modern generic process is derived from the work on the UML and associated process, bringing together aspects of the 3 generic process models.
• The process is described from 3 perspectives:
• a dynamic perspective that shows phases over time
• a static perspective that shows process activities
• a proactive perspective that suggests good practice
• RUP Phases:
• Inception, Elaboration, Construction and Transition
• Inception Phase establishes the business case and defines external entities.
• Elaboration phase: develops an understanding of the problem domain and system architecture using UML use-cases

Use Case Diagram

• Used to graphically represent different scenarios and interactions within the system.
• Stages are:
• Construction: System design, programming, and testing so that you have a working software system and associated documentation that is ready for delivery to users.
• Transition: Deploy the system in its operating environment, moving from the development community to the user community.

RUP Iteration

• Both an in-phase and cross-phase iteration
• In-phase: Each phase is iterative with results developed incrementally.
• Cross Phase: As shown by the loop in the RUP model, the whole set of phases may be enacted incrementally.
• Static workflows in the Rational Unified Process;
• Business modelling, Requirements, Analysis and design, Implementation, testing, Deployment, Configuration and change management, project management, Environment

RUP Good Practice

• Visually model software through use of UML models to present static and dynamic views of the software.
• Verify software quality ensures the software meet's organizational quality standards.
• Control changes to software by managing software changes using a change management system and configuration management tools.
• Activities should be included to cope with change, which may involve a prototyping phase.
• Processes may be structured for iterative development and delivery.
• Rational Unified Process is organized into phases, but separates activities.