Software Engineering: A Practitioner’s Approach, 6/e
Chapter 3 Prescriptive Process Models .
Prescriptive Process Models • Prescribe a distinct ((متميزset of activities, actions, tasks, milestones, and work products required to engineer high quality software. • Adapted to meet the needs of software engineers and managers for a specific project. • Provide stability, control, and organization to a process that if not managed can easily get out of control. • Framework activities for a particular process model may be organized into a process flow that may be linear, incremental, or evolutionary. • The software engineer's work products (programs, documentation, data) are produced as a consequence of the activities defined by the software process. • The best indicators of how well a software process has worked are the quality, timeliness, and long-term viability of the resulting
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 following processes are called prescriptive because they prescribe: – a set of process elements • framework activites, SE actions, tasks, work products, quality assurance mechanisms, change control mechanisms for each project. – a workflow • ie the manner in which the process elements are interrelated to one another. • All SW process models can accommodate the generic framework activities but each applies emphasis to activities and defines a workflow that invokes each framework activity in a different way.
The Waterfall Model Communication Project initiation Requirements gathering
Planning Estimating Scheduling Tracking
Modeling Analysis Design
Construction Code Test
Deployment Delivery Support Feedback
Characteristics of waterfall: • Consists of a set of phases that a project progresses through in a sequential order. • Each phase must be completed before the project can progress to the next phase. • At the end of each phase is some form of gateway, usually a formal review where that decision is made. • There is no overlap between phases. • Straight forward, simple to understand and use. • Deliverables are frozen at the end of each phase and server as the baseline for the following phases. • You do not see the software until the end of the project (big bang software development). • Changes are not supposed to happen or are limited or are tightly controlled.
The Waterfall Model • Also known as Linear Sequential Model • Classic life cycle • Advantages: – old fashioned but reasonable approach when requirements are well understood. • Disadvantages: – Real projects rarely follow a sequential flow which is why this model sometimes fails.. – Difficult for customer to state all requirements explicitly – No working version until late in development process. • This model is often inappropriate for normal SW development where the work is fast paced and subject to a never-ending stream of changes to features, functions and information content.
Process: Generic Phases 1.
2.
Definition phase: what to build – Establish what the requirements of the system are – Use system engineering, project planning, requirements analysis Development phase: how to build it -
3.
4.
Establish how the system is to be realized – design and build
– Use software design, code generation, testing Support: – Handle changes as the software environment evolves – Must handle four types of changes: correction, adaptation, enhancement, prevention This process is complemented by a number of umbrella activities, such as: – project management, configuration control, risk management
Incremental Model
Deliver increasing functionality at each increment. First iteration is the core. (+) manages risk, deals well with staffing problems, (-) can be slow
The incremental model • Combines elements of the linear model and prototyping • Delivers a series of releases that provide progressively more functionality for the customer as each increment is delivered. • First increment often core product • Focuses on operational product (not throw-away prototype) • Used when not enough resources are available to deliver the complete product in time • Increments help to manage technical risks (e.g. currently unavailable hardware) • If the customer demands delivery by a date that is impossible to meet, suggest delivering one or more increments by that date and the rest of the SW ie additional increments later. • Word processing example: 1st basic core functionality, 2nd extended editing, 3rd spelling and grammar checks
The RAD Model Team # n Mo de lin g business modeling data modeling process modeling
Co n st ru ct io n component reuse automatic code generation testing
Team # 2
Communication
Modeling business modeling data modeling process modeling
Planning Construction
Team # 1
component reuse automatic code generation testing
Modeling business modeling data modeling process modeling
Construction
component reuse automatic code generation testing
60 - 90 days
Deployment integration delivery feedback
• Incremental SW process model emphasizes short development cycles. • RAD is a high speed adaptation of the waterfall model. – Achieved by using component based construction. • Requirements must be well understood. • Project scope must be constrained. • Each major function is addressed by a separate RAD team in parallel and then integrated to form a whole. • Drawbacks – need sufficient human resources – developers and customers must be committed to communication. – system must be modularizable. – if performance is an issue, project may fail. – if project makes heavy of a new technology, project is at risk.
Evolutionary Models: Prototyping Quick plan Quick
Communication
plan
communication
Modeling Modeling Quick design Quick design
Deployment Deployment Delivery delivery & & Feedback feedback
Construction
Construction of of prototype prototype
• SW evolves over time • Requirements change as development proceeds • Tight market deadlines sometimes makes delivery of a complete product not possible. • Core requirements are well understood but details or system extensions have yet to be defined. • This is when evolutionary process models make sense – produce an increasingly more complete version of the SW with each iteration.
Prototypting • Focuses on a representation of those aspects of the SW that are visible to the end-used. • It is deployed and then evaluated. – Feedback is used to refine requirements and then iterated. • Used when the customer has a legitimate need but clueless about the details, develop a prototype first. – Unsure of • algorithm efficiency • adaptability of the OS • human-machine interaction • Prototyping can be implemented within the context of any one of the process models. – Assists in understanding what is to be built when requirements are fuzzy
The benefits of prototyping are: • a working model is provided to the customer/user early in the process, enabling early assessment and bolstering confidence, • the developer gains experience and insight by building the model, thereby resulting in a more solid implementation of "the real thing" • the prototype serves to clarify otherwise vague requirements, reducing ambiguity and improving communication between developer and user.
• Increased customer satisfaction during development phase.
prototyping problems: • The user sees and believes that the prototype (a model) can be easily transformed into a production system. • many users have pressured developers into releasing prototypes for production use that have been unreliable, • The developer often makes technical compromises to build a "quick and dirty" model. Sometimes these compromises are propagated into the production system, resulting in implementation and maintenance problems. • Prototyping does not aim to develop final working products -> customer may disapprove of final “development” phase, turning prototype into supportable product.
• product – Quality will suffer. – usually implementation compromises have been make to get the prototype working quickly. – Possibly an inappropriate OS or programming language was chosen – Inefficient algorithm used.
Evolutionary Models: The Spiral planning
estimation scheduling risk analysis
communication modeling analysis design start
deployment delivery feedback
construction code test
The Spiral Model • Customer communication: Establish effective communication • Planning: Define resources, timelines etc. • Risk analysis: Assess technical and management risks • Construction & release: construct, test, install, provide user support • Customer evaluation: obtain feedback • Couples iterative nature of prototyping with controlled and systematic aspect of the linear sequential model • Early iterations may be paper models or prototypes • Can be used throughout the life of the product • Reduces risk if properly applied
Spiral Model • Couples the iterative nature of prototyping with the controlled and systematic aspects of the waterfall model. • Risk driven model – Incrementally growing a system’s degree of definition and implementation while decreasing its degree of risk. • Realistic approach to development of large-scale systems and SW. – The Developer and customer better understand and react to risks at each evolutionary level as the SW evolves. • Problematic for fixed-budget development – project cost is revisited and revised as each circuit is completed. – Does not work in a contract situation. • Demands considerable risk assessment expertise and relise on this expertise for success.
Evolutionary Models: Concurrent Modeling activity
Under development
Awaiting changes
none
Under review Under revision
Baselined Done
Concurrent Model • Appropriate for system engineering projects where different engineering teams are involved. • Represented as a series of framework activites, software engineering actions and tasks and their associated states. – All activites exist concurrently but reside in different states. – A series of events trigger transitions from state to state. • Applicable to all types of SW development and provides an accurate picture of the current state of a project. • A event generated at one point in the process network, triggers transitions among the states.
The concurrent development model • Defines a series of events that will trigger transitions from state to state for each of the software engineering activities. • Concurrent process model: recognizes that different stages of the project (analysis, design, coding) will have achieved different states (e.g. under development, awaiting changes, done, etc.) – + provides accurate picture of current project state – - must exist in parasitic relationship with another model
The Component-Based (OO) Model Planning Customer Communicati on
Risk Analysis
identify candidate classes lookup classes in library
construct nth iteration of system
extract classes if available
put new classes in library
Customer Evaluation
• •
Engineering, Construction & Release
engineer classes if unavailable OO analysis OO design OO programming OO testing
Similar to spiral but uses pre-packaged classes wherever possible (+) emphasises reuse, (-) must design with further reuse in mind
Component based development • It is the process to apply when reuse is a development objective • evolutionary in nature – iterative approach • Composes applications from prepackaged SW components. • Modeling and construction activities begin with the identification of candidate components.
Formal methods • A set of activities that leads to formal mathematical specification of computer SW. • Goal is to remove ambiguity, incompleteness and inconsistency. • Serve as basis for program verification. • Why not widely used? – time-comsuming and expensive – extensive training required – difficult to use the model to as a communication mechanism to unsophisticated customers. • Used frequently to build safety-critical SW (avionics and medical devices) and among developers who would suffer economic hardship should SW errors occur.
Other Process Models •
Formal methods: the process to apply when a mathematical specification is to be developed. – + Attack ambiguity, incompleteness and inconsistency – + allows formal verification – - time consuming and expensive – - requires extensive training – - not good for customer communication
Aspect-Oriented SW Development • provides a process and methodological approach for defining, specifying, designing, and constructing aspects • As systems become more complex, customer required properties or areas of technical interest called concerns span the entire architecture. – high level properties of a system • security • fault tolerance
– functions • application of business rules
– systemic • task synchronization • memory management • user interfaces, collaborative work
• crosscutting concerns: concerns cut across multiple system functions, features, and information • Aspectual requirements: define crosscutting concerns that have impact across the SW architecture
Unified Process • Attempts to draw the best features and characteristcs of conventional SW process models. – BUT characterize them in a way that implements the best principles of agile SW development.
• Recognizes the importance of customer communication and streamlined methods for describing the customer’s view – use cases
• Emphasized SW architecture – keeps the focus on the right goals • ie understandability, future change and reuse
• UML provides the technology to support OO SW but not the process framework. • The Unified Process is the framework for OO SE using UML as developed by Jacobson, Rumbaugh and Booch. • Iterative, incremental and adapted to meet specific project needs. • The idea is to make development more agile and responsive to change. • The phases are inceptiom, elaboration, construction, transition and production
The Unified Process (UP) Elaboration elaboration Inception inception
inception
construction Release software increment
production
transition
Inception phase Vision document Initial use-case model Initial project glossary Initial business case Initial risk assessment. Project plan, phases and iterations. Business model, if necessary. One or more prototypes I nc ept i o n
UP Work Products Elaboration phase Use-case model Supplementary requirements including non-functional Analysis model Software architect ure Description. Executable architectural prototype. Preliminary design model Revised risk list Project plan including iteration plan adapted workflows milestones technical work products Preliminary user manual
Construction phase Design model Software components Integrated software increment Test plan and procedure Test cases Support documentation user manuals installat ion manuals description of current increment
Transition phase Delivered software increment Beta test report s General user feedback
• From the SE point of view, the most important work product during the inception is the use-case model. – imply SW feature and functions by describing a set of preconditions, a flow of events or a scenario, and a set of post-conditions for the interaction. • The elaboration phase produces a set of work products that elaborate requriements including nonfunctional requirements and produce an architectural description and a preliminary design. • Construction produces an implementation • Deployment maps components into the physicial computing environment. • A Test model describes the tests to ensure the usecases are properly constructed.
Summary
• Prescriptive SW Processes – suggest a somewhat different process flow – perform the same set of generic framework activites • communication, planning, modeling, construction, deployment • Waterfall – linear • Incremental – series of increments • RAD larger projects with tight time frames • Evolutionary – iterative • Component – reuse and assembly • Formal Methods – mathematical • Aspect-oriented – cross-cutting concerns • Unified Process – use-case driven, architecture-centric, iterative and incremental. Framework for UML methods and tools.