INF3705_notes Summary. Success.

INF305 Yellow = answered textbook questions Blue = unanswered questions Chapter 3 – Process Models Prescriptive process models prescribe a set of process elements:  Framework activities, tasks, work products, quality assurance… Generic framework activities:  Communication  Planning  Modeling  Construction Deployment Linear process model: 1. Waterfall model (Classic life cycle)  Systematic, linear, sequential approach  For projects with these characteristics: o The problem is well understood (well-defined requirements) o The delivery date is realistic o Major changes in requirements are unlikely  For when work flows in a reasonably linear fashion  The linear nature can lead to ‘blocking states’, where you have to wait for other team members to complete dependent tasks  Inappropriate model for today’s fast-paced changing software  Problems: o Real projects rarely follow a sequential flow o The customer has to state all requirements explicitly o Working version of the program appears late in the project  Software projects that would be amenable to the waterfall model: o A well-understood modification to an existing program o A straightforward implementation of a numerical calculation or business rule, even if it is complex o A constrained enhancement to an existing program Incremental process models: For when requirements are well-defined, and a limited set of software functionality must be provided quickly, and then refined later. 2. Incremental model  Combines elements of the waterfall model applied iteratively  Linear sequences each produce deliverable increments of software  The first increment is usually a core product, used by customers  Each increment focuses on the delivery of an operational product  Good when staffing is unavailable for a complete implementation  Increments can be planned to manage technical risks  Software projects amenable to the incremental model: o A project that has significant functionality that must be delivered in a very tight time frame (Add on extras later) 1 3. RAD model  An incremental model that emphasizes a short development cycle  A high-speed adaptation of the waterfall model, where rapid development is achieved by using component-based construction  For when requirements are understood and scope is constrained  For when business applications can be modularized  A fully functional system is constructed in a very short time  Each major function is addressed by a separate RAD team and then integrated to form a whole  To achieve rapid development, this model assumes the existence of: a project that can be modularized in a manner that allows major functionality to be delivered within 60-90 days (This isn’t always the case – sometimes timelines can be longer) Drawbacks:  For large projects, RAD requires sufficient human resources to develop the increments in parallel  Projects will fail if people don’t commit to rapid activities  If a system can’t be modularized, you can’t build components  Might not work if high performance is an issue  Might not be appropriate when technical risks are high Evolutionary process models: For when core requirements are well understood and a limited version of the product must be introduced, which will evolve over time. Iterative, and can easily accommodate product requirement changes. 4. Prototyping  For when the customer defines a set of general objectives  For when the developer is unsure of the form of the software  Can be used as a standalone process model, but is more commonly used as a technique that can be implemented within other models  The prototype helps to identify software requirements  It should be discarded (at least in part)  Problems with prototyping: o The customer sees a working version and wants to keep it o Developers may become comfortable with inefficient choices  Software projects amenable to the prototyping model: o Ones which involve human-machine interaction and/or heavy computer graphics o Ones where results can easily be examined without real-time interaction (e.g. command-driven systems using mathematical algorithms) i.e. not embedded software!  Process adaptations required if the prototype will evolve into a deliverable system / product: o More rigorous design rules and SQA procedures must be applied from the beginning 2 o The prototype must be designed with extensibility in mind and be implemented using a programming environment that is amenable to production system development o The prototype is initially a mechanism for identifying requirements, and then becomes the framework for extensions that will cause it to evolve into a production system 5. Spiral model  Combines the iterative nature of prototyping with the controlled and systematic aspects of the waterfall model  Rapid development of increasingly complete versions of software  Software is developed in a series of evolutionary releases  Each framework activity represents 1 segment of the spiral path  Risk-driven model: risk evaluation during each iteration  Anchor point milestones are noted for each evolutionary pass  This model can apply throughout the life of the software  Good for developing large-scale systems and software  Not good if you have a fixed budget, because project cost is revised as each circuit is completed  Prototyping reduces risks, and can be applied at any stage  Problems: o May be hard to convince customers that it’s controllable o Demands considerable risk assessment and expertise o Problems if a major risk is not uncovered and managed  What happens to the software as you move outwards along the spiral process flow: o The product moves towards a more complete state o The level of abstraction at which work is performed is reduced (i.e. implementation-specific work accelerates as we move further from the origin) 6. Concurrent development model  Represented as a series of framework activities, software engineering actions & tasks, and their associated states  All activities exist concurrently but reside in different states  What the states represent and how they come into play: o The different parts of a project (framework activities) will be at different stages of completeness (e.g. ‘under development’, ‘awaiting changes’, ‘done’), so you can say that all activities are being performed concurrently o The challenge is to manage the concurrency and to be able to assess the status of the project  A series of events are defined that will trigger transitions from state to state for each of the software activities / tasks  This model is applicable to all types of software development  Often used for the development of client/server applications  Provides an accurate picture of the current state of the project