Software Life Cycle Main Topics Study the different life cycle models Study the difference between software maintenance and evolution Study product line engineering as a design methodology 2 Introduction Software development projects are large and complex Proper control requires a phased approach to development Traditional models are document-driven: there is a new pile of paper after each phase is completed Evolutionary models recognize that much of what is called maintenance is inevitable Latest trend: agile methods, extreme Programming Life cycle models can be explicitly modeled, in a process modeling language 3
Simple life cycle model problem requirements engineering reqs specification design design implementation system working system maintenance 4 Point to ponder #1 Why does the model look like this? Is this how we go about it? 5 Simple Life Cycle Model document driven, planning driven, heavyweight milestones are reached if the appropriate documentation is delivered (e.g., requirements specification, design specification, program, test document) much planning upfront, often heavy contracts are signed Hard to adapt to changes 6
Waterfall Model reqs engineering V & V design V & V implementation V & V V & V maintenance V & V 7 Waterfall Model includes iteration and feedback validation (are we building the right system?) and verification (are we building the system right?) after each step user requirements are fixed as early as possible problems too rigid developers cannot move between various abstraction levels 8 V-Model reqs eng acceptance global design integration det. design unit coding 9
Activity versus phase Phase Activity Design Implementation Integration Acceptance Integration 4.7 43.4 26.1 25.8 Coding 6.9 70.3 15.9 6.9 Design 49.2 34.1 10.3 6.4 10 Agile Methods Model based development assumes complete or close to complete knowledge about the application s world Agile methods assume that the world is inherently undeterministic 11 The Agile Manifesto Individuals and interactions more important than processes and tools Working software more important than comprehensive documentation Customer collaboration more important than contract negotiation Responding to change more important than following a plan 12
Agile Methods Prototyping Incremental development Rapid application development (RAD), and the dynamic system development model (DSDM) extreme Programming (XP) 13 Prototyping Requirements elicitation is difficult software is developed because the present situation is unsatisfactory however, the desirable new situation is as yet unknown Prototyping is used to obtain the requirements of some aspects of the system 14 Prototyping Prototyping should be a relatively cheap process use rapid prototyping languages and tools (Functional but inefficient) not all functionality needs to be implemented production quality is not required 15
Prototyping as a tool for requirements engineering reqs engineering design design implementation implementation maintenance 16 Prototyping Approaches Throwaway prototyping: the n-th prototype is followed by a waterfalllike process Evolutionary prototyping: the nth prototype is the final system 17 Advantages of Prototyping The resulting system is easier to use The resulting system has fewer features User needs are better accommodated The design is of higher quality Problems are detected earlier The resulting system is easier to maintain The development incurs less effort 18
Disadvantages of Prototyping The resulting system has more features The design is of lower quality The performance of the resulting system is worse The resulting system is harder to maintain The prototyping approach requires more experienced team members 19 Prototyping, recommendations Users and designers must be well aware of the issues and the pitfalls Use prototyping when the requirements are unclear Use prototyping in situations where a heavy emphasis is placed on the user interface Prototyping needs to be planned and controlled as well 20 Incremental Development A software system is delivered in small increments, thereby avoiding the Big Bang effect The waterfall model is employed in each phase The user is closely involved in directing the next steps The most risky functionality is implemented first Incremental development prevents overfunctionality 21
Rapid Application Development (RAD) Evolutionary development, with time boxes: fixed time frames within which activities are done Time frame is decided upon first, then one tries to realize as much as possible within that time frame 22 Rapid Application Development (RAD) Utilizes a triage process to prioritize requirements into 4 categories: Must haves Should haves Could haves Won t haves 23 Rapid Application Development (RAD) Design and planning activities carried out jointly among developers and users in: Joint Requirements Planning (JRP) workshops Joint Application Design (JAD) workshops development by a SWAT team: Skilled Workers with Advanced Tools 24
Dynamic System Development Method (DSDM) A RAD framework Fundamental idea: fix time and resources (timebox), adjust functionality accordingly One needs to be a member of the DSDM consortium 25 DSDM Phases Feasibility: delivers feasibility report and outline plan Business study: use a series of joint workshops to develop a high level architecture 26 DSDM Phases (cont.) Functional model iteration: Identify activities to be performed Plan for performing the activities Perform the activities Verify the implementation of the activities Design and build iteration Implementation: transfer to production environment 27
DSDM practices Active user involvement is imperative Teams must be empowered Frequent delivery of products Acceptance determined by fitness for business purpose Iterative, incremental development All changes are reversible Requirements baselined at a high level Testing integrated in life cycle Collaborative, cooperative approach shared by all stakeholders is essential 28 extreme Programming (XP) Everything is done in small steps The system always compiles, always runs Clients and developers work collaboratively Development is often done by pairs of programmers, one of them watching over the other s shoulder 29 Principle practices of XP Rapid feedback Simplicity Incremental change Embracing change Quality work 30
Rational Unified Process (RUP) Complements UML (Unified Modeling Language) Relies on use cases for modeling requirements Tool-supported 31 RUP Phases Inception: establish scope, boundaries, critical use cases, candidate architectures, schedule and cost estimates Elaboration: foundation of architecture, establish tool support, get all use cases Construction: manufacturing process, one or more releases Transition: release to user community, often several releases 32 Two-dimensional Process Structure of RUP 33
MDA Model Driven Architecture model model maintenance implementation transformation code maintenance code 34 Essence of MDA 1. Computation independent model (CIM) 2. Platform Independent Model (PIM) 3. Platform Specific Model (PSM) 4. Code Transition from 1 to 2 is not automated, transitions from 2 to 3 and 3 to 4 are often automated 35 Maintenance or Evolution Maintenance like systems are not built from scratch there is time pressure on maintenance 36
Laws of Software Evolution Continuing change Increasing complexity Self regulation Conservation of organizational stability Conservation of familiarity Continuing growth Declining quality Feedback system 37 Software Product Lines Developers are not inclined to make a maintainable and reusable product, it has additional costs Generally, developers have no incentive for reuse This changes if the product family is the focus of attention rather than producing a single version of a product two processes result: domain engineering, and application engineering 38 Process Modeling The process itself is often modeled using one of several methods: Process programming languages State transition diagrams (typically in UML) Petri nets 39
Example Process Programming Language function review(document, threshold): boolean; begin prepare-review; hold-review{document, no-ofproblems); make-report; return no-of-problems < threshold end review; 40 Example UML Diagram coding ready submit ready for next step re-review review prepare ready do done make report ready report 41 Example Petri-net Representation from coding code ready hold review code update revised code end next step from management scheduled minutes 42
Purposes of Process Modeling facilitates understanding and communication by providing a shared view of the process supports management and improvement; it can be used to assign tasks, track progress, and identify trouble spots serves as a basis for automated support (usually not fully automatic) 43 Caveats of Process Modeling not all aspects of software development can be caught in an algorithm a model is a model, thus a simplification of reality progression of stages differs from what is actually done some processes (e.g. learning the domain) tend to be ignored no support for transfer across projects 44 Summary Traditional models focus on control of the process There is no one-size-fits-all model; each situation requires its own approach A pure project approach inhibits reuse and maintenance There has been quite some attention for process modeling, and tools based on such process models 45