Software Engineering Process and Models

A Layered Technology Software Engineering tools methods process model a “quality” focus

A Process Framework Process framework Framework activities work tasks work products milestones & deliverables QA checkpoints Umbrella Activities

Framework Activities Communication Planning Modeling Construction Analysis of requirements Design Construction Code generation Testing Deployment

Umbrella Activities Software project management Formal technical reviews Software quality assurance Software configuration management Work product preparation and production Reusability management Measurement Risk management

The Process Model: Adaptability the framework activities will always be applied on every project ... BUT the tasks (and degree of rigor) for each activity will vary based on: the type of project characteristics of the project common sense judgment; concurrence of the project team

Assessment and Improvement

The Primary Goal of Any Software Process: High Quality Remember: High quality = project timeliness Why? Less rework!

What are the attributes of good software? The software should deliver the required functionality and performance to the user and should be maintainable, dependable and usable Maintainability Software must evolve to meet changing needs Dependability Software must be trustworthy Efficiency Software should not make wasteful use of system resources Usability Software must be usable by the users for which it was designed

What are the key challenges facing software engineering? Software engineering in the 21st century faces three key challenges: Legacy systems Old, valuable systems must be maintained and updated Heterogeneity Systems are distributed and include a mix of hardware and software Delivery There is increasing pressure for faster delivery of software

What is a software process? SP is a set of activities whose goal is the development or evolution of software Fundamental activities in all software processes are: Specification - what the system should do and its development constraints Development - production of the software system (design and implementation) Validation - checking that the software is what the customer wants Evolution - changing the software in response to changing demands

What is a software process model? SPM is a simplified representation of a software process, presented from a specific perspective Examples of process perspectives: Workflow perspective represents inputs, outputs and dependencies Data-flow perspective represents data transformation activities Role/action perspective represents the roles/activities of the people involved in software process Generic process models Waterfall Evolutionary development Formal transformation Integration from reusable components

What is a Process … ? When we provide a service or create a product we always follow a sequence of steps to accomplish a set of tasks You do not usually put up the drywall before the wiring for a house is installed or bake a cake before all the ingredients are mixed together We can think of a series of activities as a process Any process has the following characteristics It prescribes all of the major activities It uses resources and produces intermediate and final products It may include sub-processes and has entry and exit criteria The activities are organized in a sequence Constrains or control may apply to activities (budget control, availability of resources )

Software Processes Coherent sets of activities for Specifying, When the process involves the building of some product we refer to the process as a life cycle Software development process – software life cycle Coherent sets of activities for Specifying, Designing, Implementing and Testing software systems

Major problems in software developments … The developers understood it in that way The requirements specification was defined like this This is how the problem is solved now This is how the problem was solved before. This is how the program is described by marketing department This, in fact, is what the customer wanted … ;-) That is the program after debugging

The Software Process A structured set of activities required to develop a software system Specification Design Validation Evolution A software process model is an abstract representation of a process It presents a description of a process from some particular perspective

Generic Software Process Models The waterfall model Separate and distinct phases of specification and development Evolutionary development Specification and development are interleaved Formal systems development (example - ASML) A mathematical system model is formally transformed to an implementation Reuse-based development The system is assembled from existing components

1. Waterfall Model

Prescriptive Models Prescriptive process models advocate an orderly approach to software engineering That leads to a few questions … If prescriptive process models strive for structure and order, are they inappropriate for a software world that thrives on change? Yet, if we reject traditional process models (and the order they imply) and replace them with something less structured, do we make it impossible to achieve coordination and coherence in software work?

The Waterfall Model

Waterfall model phases Requirements analysis and definition System and software design Implementation and unit testing Integration and system testing Operation and maintenance The drawback of the waterfall model is the difficulty of accommodating change after the process is underway

Waterfall model problems Inflexible partitioning of the project into distinct stages This makes it difficult to respond to changing customer requirements Therefore, this model is only appropriate when the requirements are well-understood Waterfall model describes a process of stepwise refinement Based on hardware engineering models Widely used in military and aerospace industries

Why Not a Waterfall But software is different : No fabrication step Program code is another design level Hence, no “commit” step – software can always be changed…! No body of experience for design analysis (yet) Most analysis (testing) is done on program code Hence, problems not detected until late in the process Waterfall model takes a static view of requirements Ignore changing needs Lack of user involvement once specification is written Unrealistic separation of specification from the design Doesn’t accommodate prototyping, reuse, etc

2. Evolutionary development Exploratory development Objective is to work with customers and to evolve a final system from an initial outline specification. Should start with well-understood requirements. The system evolves by adding new features as they are proposed by customer. Throw-away prototyping Objective is to understand the system requirements. Should start with poorly understood requirements Develop “quick and dirty” system quickly; Expose to user comment; Refine; Until adequate system developed. Particularly suitable where: detailed requirements not possible; powerful development tools (e.g. GUI) available

Evolutionary Models: Prototyping Quick plan communication Modeling Quick design Deployment delivery & feedback Construction of prototype

Evolutionary Models: The Spiral

Evolutionary Models: Concurrent

The Incremental Model

The RAD Model

Still Other Process Models Component based development—the process to apply when reuse is a development objective Formal methods—emphasizes the mathematical specification of requirements AOSD—provides a process and methodological approach for defining, specifying, designing, and constructing aspects Unified Process—a “use-case driven, architecture-centric, iterative and incremental” software process closely aligned with the Unified Modeling Language (UML)

The Unified Process (UP) inception elaboration inception

UP Phases

UP Work Products