Software Engineering Lecture 02: Processes Peter Thiemann University of Freiburg, Germany SS 2013 Peter Thiemann (Univ. Freiburg) Software Engineering SWT 1 / 41
Terms Software Component SW System Organized collection of computer data and instructions Solves isolated task Developed by a single person Multiple components Developed by a team Peter Thiemann (Univ. Freiburg) Software Engineering SWT 2 / 41
Programming in the Small Development of a system comprised of a small number of mind-sized components Often clear requirements Sometimes algorithmic aspects Procedure for a single component: Procedural decomposition, top-down stepwise refinement (N. Wirth), Peter Thiemann (Univ. Freiburg) Software Engineering SWT 3 / 41
Programming in the Large Development of a software system comprised of many components requirements at first fuzzy Size or complexity dictate... decomposition in a large number of components development in a team size determines duration, but beware of Brook s law! Peter Thiemann (Univ. Freiburg) Software Engineering SWT 4 / 41
Brook s law: Adding manpower to a late SW project makes it later Image: http://bulldozer00.files.wordpress.com/2010/11/productivity-and-capability.png?w=595 Peter Thiemann (Univ. Freiburg) Software Engineering SWT 5 / 41
Issues Arising with Programming in the Large Requirements need to be investigated Communication problem customer developer Understanding the problem Design of the system is significant task Decomposition in components (interfaces, contracts) Information hiding (D.L. Parnas) Design for maintenance Long life span High probability of changes (aging) Promising approach: object-oriented analysis and design Construction of components: programming in the small Testing required on many levels Peter Thiemann (Univ. Freiburg) Software Engineering SWT 6 / 41
Conclusion Programming in the large is a structured approach to all activities in the development of a software system Unfortunately,... Peter Thiemann (Univ. Freiburg) Software Engineering SWT 7 / 41
Conclusion Programming in the large is a structured approach to all activities in the development of a software system Unfortunately,... there are many overall approaches (process models) there are many techniques with similar goals Peter Thiemann (Univ. Freiburg) Software Engineering SWT 7 / 41
Process Models Process Model: structured network of activities and artifacts An activity transforms a set of artifacts into new artifacts Given Artifacts Methods Guidelines Conventions Check Lists Patterns Tools Changed or new Artifacts Employee Y Role X Peter Thiemann (Univ. Freiburg) Software Engineering SWT 8 / 41
Phases Phases provide structure of process model Description of a phase goals activities roles required/new artifacts patterns, guidelines, and conventions Peter Thiemann (Univ. Freiburg) Software Engineering SWT 9 / 41
Desiderata for Process Models The fewer phases, artifacts, roles, the better Artifacts should cover standard case Tool support Quality assurance for each artifact Traceability Peter Thiemann (Univ. Freiburg) Software Engineering SWT 10 / 41
The Classic: Waterfall Model Requirements Specification Design Coding Testing Integration Early error correction is cheaper (e.g. after analysis phase 100 times cheaper than after deployment) Hence, after every phase: check of previous phases Potentially return to previous phase Phases may overlap Operation Maintenance Peter Thiemann (Univ. Freiburg) Software Engineering SWT 11 / 41
Requirements Analysis tractability cost analysis result: documents: decision on continuation of project (artifacts) Requirement specification (Lastenheft) Cost estimation Project plan Peter Thiemann (Univ. Freiburg) Software Engineering SWT 12 / 41
Definition / Specification starting point: vague, incomplete, inconsistent requirements result: documents: complete, consistent, unequivocal, accomplishable requirements System specification (Pflichtenheft) Product model (e.g. OOA) GUI model User manual Peter Thiemann (Univ. Freiburg) Software Engineering SWT 13 / 41
Definition / Specification (cont d) Only external behavior of system Analysis of requirements functional / non-functional requirements prioritization Main outcome: system specification fixes the scope of the product serves as basis for contract between customer and contractor basis for final acceptance functionality user interface interfaces to other systems performance (response time, space usage) required hard and software guidelines for documentation time scheduling quality Peter Thiemann (Univ. Freiburg) Software Engineering SWT 14 / 41
Design starting point: system specification / product model Decomposition in components / subsystems Logical interfaces of each component Choice of technologies result: Software architecture (with specification of components) Peter Thiemann (Univ. Freiburg) Software Engineering SWT 15 / 41
Implementation and Testing starting point: Software architecture Coding of component specifications Compilation to machine language Unit testing up to component level result: implemented components and testing protocols Peter Thiemann (Univ. Freiburg) Software Engineering SWT 16 / 41
Integration, system test, and deployment Integration stepwise addition of single components tested with data fixed in advance (functional requirements only) System test entire system (incl. hardware) non-functional requirements (performance, GUI) Deployment transfer of software system to its working environment result: deployed product, protocol of final acceptance Peter Thiemann (Univ. Freiburg) Software Engineering SWT 17 / 41
Maintenance Supervision Bug fixes Changes due to changes in requirements (incl. extensions) result: maintained product Peter Thiemann (Univ. Freiburg) Software Engineering SWT 18 / 41
Concrete Process Models 1. V-Model 2. Prototyping model 3. Phased models (evolutionary, incremental, spiral) 4. Unified Software Process 5. Agile development techniques Peter Thiemann (Univ. Freiburg) Software Engineering SWT 19 / 41
V-Model Entwicklungsstandard für Systeme des Bundes level of abstraction system requirements software requirements system integration acceptance test Analyze and Design preliminary design detailed design software integration component test Test and Integrate code and debug unit test time Peter Thiemann (Univ. Freiburg) Software Engineering SWT 20 / 41
V-Model Builds on waterfall model Emphasizes validation connections between late phases and early phases Objectives risk minimization quality assurance cost reduction communication between stakeholders Current instance: V-Model XT Peter Thiemann (Univ. Freiburg) Software Engineering SWT 21 / 41
Prototyping Model Lifecycle require ments design prototype build prototype test prototype document requirements design code test integrate Peter Thiemann (Univ. Freiburg) Software Engineering SWT 22 / 41
Prototyping - Overview Advantages: understanding the requirements for the user interface improves understanding between developer and client early testing of feasibility, usefulness, performance, etc. Problems: customers treat the prototype as the product a prototype is not a specification significant user involvement Peter Thiemann (Univ. Freiburg) Software Engineering SWT 23 / 41
Phased Models Evolutionary Development 1. model core requirements 2. design and implement 3. deploy 4. feedback from customer 5. revise/extend requirements 6. revise/extend design 7. revise/extend implementation 8. iterate from 3 until all requirements met Incremental Development 1. model all requirements 2. design and implement only core requirements 3. deploy 4. feedback from customer 5. revise requirements 6. design further requirements 7. implement further requirements 8. iterate from 3 until all requirements met Peter Thiemann (Univ. Freiburg) Software Engineering SWT 24 / 41
Incremental Development (each iteration adds more functionality) release 1 design code test integrate O&M requirements release 2 design code test integrate O&M release 3 design code test integrate O&M release 4 design code test integrate O&M Peter Thiemann (Univ. Freiburg) Software Engineering SWT 25 / 41
Evolutionary Development (each iteration incorporates new requirements) version 1 reqts. design code test integrate O&M version 2 reqts. lessons learned design code test integrate O&M lessons learned version 3 reqts. design code test integrate O&M Peter Thiemann (Univ. Freiburg) Software Engineering SWT 26 / 41
Spiral Model (Barry Boehm 1988) Determine Goals, Alternatives, Constraints alternatives 4 alternatives 3 constraints4 constraints3 2 2 alternativesconstraints risk analysis 2 risk analysis 1 budget4 budget3 budget2 budget1 prototype1 prototype2 prototype3 prototype4 Plan integration and test plan requirements, lifecycle plan development plan alternatives constr. implementation plan concept of operation risk analysis 3 software validated requirements validated, verified design acceptance test risk analysis 4 requirements system test software design Evaluate Alternatives and Risks unit test code detailed design Develop and Test Peter Thiemann (Univ. Freiburg) Software Engineering SWT 27 / 41
Comments on Phased Models Incremental development avoids big bang implementation but assumes all requirements known up-front Evolutionary development allows for lessons from each version to be incorporated into the next but: hard to plan for versions beyond the first; lessons may be learned too late Spiral model primarily targeted at very large projects iterative model that incorporates prototyping and risk analysis but: cannot cope with unforeseen changes not clear how to analyze risk Peter Thiemann (Univ. Freiburg) Software Engineering SWT 28 / 41
The Unified Software Process Use-Case Driven Which user-visible processes are implemented by the system? Analysis, design, implementation, and testing driven by use-cases Architecture centric Architecture developed in parallel to use cases (mutual dependency) Iterative and Incremental eliminate risks first checkpoint after each iteration on failure of an iteration step, only current extension needs to be reconsidered small steps speed up project easy stepwise identification of the requirements Peter Thiemann (Univ. Freiburg) Software Engineering SWT 29 / 41
Structure of the Unified Software Process sequence of cycles after each cycle: product release with code, manuals, UML models, and test cases Start... End Zeit Cycles (each completing a new version) cycle consists of 4 phases: Inception, Elaboration, Construction, Transition each phase consists of iterations Peter Thiemann (Univ. Freiburg) Software Engineering SWT 30 / 41
Cycle Time Inception Elaboration Construction Transition Iteration Iteration............... Iteration Iteration #1 #2 #n 1 #n... new product versions Peter Thiemann (Univ. Freiburg) Software Engineering SWT 31 / 41
Main-Workflows and Phases Core Workflows Inception Elaboration Phases Construction Transition Requirements Analysis Design Implementation Testing.................. It. #1 It. #2 It. #n each phase ends with a mile stone each phase processes all workflows (with varying intensity) Peter Thiemann (Univ. Freiburg) Software Engineering SWT 32 / 41
Inception Phase functionality of system from users perspective most important use cases (stakeholder needs) preliminary sketch of suitable architecture project plan and cost identify most important risks (with priorities) plan elaboration phase GOAL: rough vision of the product Peter Thiemann (Univ. Freiburg) Software Engineering SWT 33 / 41
Elaboration Phase specify (most) use cases in detail design architecture implement most important use cases result: initial architecture plan activities and resources for remaining project use cases and architecture stable? risk management? GOAL: prototype (proof-of-concept for architecture) Peter Thiemann (Univ. Freiburg) Software Engineering SWT 34 / 41
Construction Phase implement system high resource needs small architectural changes GOAL: system ready for customer (small errors acceptable) Peter Thiemann (Univ. Freiburg) Software Engineering SWT 35 / 41
Transition Phase deliver beta-version to customer address problems (immediately or in next release) train customer Peter Thiemann (Univ. Freiburg) Software Engineering SWT 36 / 41
Agile Development Techniques Extreme Programming (XP, Kent Beck 1999) frequent releases short development cycles pair programming unit testing w tests developed before the code features specified by tests implement features when needed clear progress marks don t spend much time on design stakeholder involvement Peter Thiemann (Univ. Freiburg) Software Engineering SWT 37 / 41
Agile Development Techniques Scrum (Hirotaka Takeuchi and Ikujiro Nonaka 1986) Flexible approach to development; incremental process Adaptability to changing requirements Core roles Product owner, Scrum master, Team Ancillary roles Stakeholders, Managers Sprint 2-4 weeks of intense development; goal: working increment that implements the sprint backlog; sprint backlog frozen during a sprint; self organization; burn down chart Sprint Backlog requirements chosen for a sprint Product Backlog as yet unimplemented requirements Peter Thiemann (Univ. Freiburg) Software Engineering SWT 38 / 41
The Pig and the Chicken Roles in Scrum Image http://www.implementingscrum.com/images/060911-scrumtoon.jpg Peter Thiemann (Univ. Freiburg) Software Engineering SWT 39 / 41
Last Word On Agile Development Image http: //www.rallydev.com/community/sites/rallydev.com.community/files/agileblog/2009/04/061218-scrumtoon1.jpg Peter Thiemann (Univ. Freiburg) Software Engineering SWT 40 / 41
Summary Software has unique problems with far-reaching consequences Creating software systems requires structured process models Classic process phases: waterfall model Commonly used process models: V-model, prototyping, evolutionary, incremental, spiral, unified SW process, agile development Peter Thiemann (Univ. Freiburg) Software Engineering SWT 41 / 41