1. Based on presentation by Mira Balaban Department of Computer Science Ben-Gurion university Based on slides of: Igor Potapov : http://www.csc.liv.ac.uk/~igor/COMP201http://www.csc.liv.ac.uk/~igor/COMP201 Ian Sommerville : http://www.comp.lancs.ac.uk/computing/resources/IanS/SE7/Presentations/index.htmlhttp://www.comp.lancs.ac.uk/computing/resources/IanS/SE7/Presentations/index.html Kent Beck and Ward Cunningham Amir Tomer: http://webcourse.cs.technion.ac.il/234321/Winter2004-2005/en/ho.htmlhttp://webcourse.cs.technion.ac.il/234321/Winter2004-2005/en/ho.html Alistair Cockburn Software processes Software Engineering Software processes Software Engineering 2011 Department of Computer Science Ben-Gurion university

2. Software Engineering, 2011Software Processes 2 The Software Process A structured set of activities required to develop a software system Specification Analysis, design and implementation. Validation Evolution A software process model is an abstract representation of a process It presents a description of a process from some particular perspective

3. Software Engineering, 2011Software Processes 3 Software Development Approaches Generic Software Process Models 1. The waterfall model (Linear Sequential Model) Separate and distinct phases of specification and development 2. Evolutionary development Specification, development and testing are interleaved Formal systems development (example - ASML) A mathematical system model is formally transformed to an implementation

4. Software Engineering, 2011Software Processes 4 Waterfall Model

5. Software Engineering, 2011Software Processes 5 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

6. Software Engineering, 2011Software Processes 6 Waterfall model Requirement and Design Artefacts produced in the requirements and Design phases SRS -Software Requirements specification document SRS might include: User usage stories (scenarios) – Use cases. Static analysis – class diagrams. Behavioural analysis – sequence diagrams, statecharts. The specification and design activities are heavily time consuming.

7. Software Engineering, 2011Software Processes 7 The requirements document The requirements document is the official statement of what is required of the system developers. Should include both a definition of user requirements and a specification of the system requirements. It is NOT a design document. As far as possible, it should set of WHAT the system should do rather than HOW it should do it

8. Software Engineering, 2011Software Processes 8 Users of a requirements document

9. Software Engineering, 2011Software Processes 9 The Waterfall process characterization: Figure out what Figure out how Then do it Verify was done right Hand product to customer Perfect requirement definition?

10. Software Engineering, 2011Software Processes 10 Waterfall model problems Inflexible partitioning of the project into distinct stages Difficult to respond to changing customer requirements This model is only appropriate when the requirements are well-understood Waterfall model describes a staged development process Based on hardware engineering models Change during development is unlikely Widely used in large systems: military and aerospace industries

11. Software Engineering, 2011Software Processes 11 Why Not a Waterfall Because 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

12. Software Engineering, 2011Software Processes 12 Evolutionary development

13. Software Engineering, 2011Software Processes 13 Characteristics of Evolutionary Development Modern development processes take evolution as fundamental, and try to provide ways of managing, rather than ignoring, the risk. System requirements always evolve in the course of a project. Specification is evolved in conjunction with the software – No complete specification in the system development contract. Difficult for large customers. Two (related) process models: Incremental development Spiral development

14. Software Engineering, 2011Software Processes 14 Incremental Development Rather than deliver the system as a single delivery, the development and delivery is broken down into increments with each increment delivering part of the required functionality. User requirements are prioritised and the highest priority requirements are included in early increments. Once the development of an increment is started, the requirements are frozen though requirements for later increments can continue to evolve.

15. Software Engineering, 2011Software Processes 15 Incremental Development – Version I

16. Software Engineering, 2011Software Processes 16 Incremental Development – Version I פיתוח אחזקה הפעלה מבצעית פרישה מימוש הקמת מבנה (build) 1,2,...,n אימות דרישות אימות ניתוח אימות ארכיטקטורה הנדסת מערכת תכן מפורט מימוש שילוב בדיקות מסירה

17. Software Engineering, 2011Software Processes 17 Incremental Development – Version II ניתוח תכן מימוש ושילוב מסירה מבנה 2 ניתוח תכן מימוש ושילוב מסירה קבוצת ניתוח קבוצת תכן קבוצת מימוש מבנה 1 ניתוח תכן מימוש ושילוב מסירה מבנה n

18. Software Engineering, 2011Software Processes 18 Incremental Development – Advantages Customer value can be delivered with each increment so system functionality is available earlier. Early increments act as a prototype to help elicit requirements for later increments. Lower risk of overall project failure. The highest priority system services tend to receive the most testing.

19. Software Engineering, 2011Software Processes 19 Incremental Development – Problems Lack of process visibility. Systems are often poorly structured. Applicability claims in the literature: For small or medium-size interactive systems. For parts of large systems (e.g. the user interface). For short-lifetime systems.

20. Software Engineering, 2011Software Processes 20 Incremental means adding, iterative means reworking (by Alistair Cockburn) Incremental development is a staging and scheduling strategy in which the various parts of the system are developed at different times or rates and integrated as they are completed. The alternative is to develop the entire system with a big bang integration at the end. Iterative development is a rework scheduling strategy in which time is set aside to revise and improve parts of the system. The alternative development is to get it right the first time (or at least declare that it is right!). http://www.stickyminds.com/BetterSoftware/magazine.asp?fn=cifea&id=108 IncrementIterate fundamentally means “add onto”.fundamentally means “change”. repeating the process on a new section of work. repeating the process on the same section of work repeat the process (, design, implement, evaluate),

21. Software Engineering, 2011Software Processes 21 Incremental Development The first increment delivers one slice of functionality through the whole system. The second increment delivers another slice of functionality through the whole system. The third increment delivers the rest of the system

22. Software Engineering, 2011Software Processes 22 Iterative Development \ The first iteration delivers enough of feature 1 to evaluate what is correct and what needs revision. After the second iteration, some revised parts still need improvement. The third iteration produces the final and stable feature

23. Software Engineering, 2011Software Processes 23 Incremental & iterative - summary Iterative model - This model iterates requirements, design, build and test phases again and again for each requirement and builds up a system iteratively till the system is completely build. Incremental model - It is non integrated development model. This model divides work in chunks and one team can work on many chunks. It is more flexible. Spiral model - This model uses series of prototypes in stages, the development ends when the prototypes are developed into functional system. It is flexible model and used for large and complicated projects. Evolutionary model - It is more customer focused model. In this model the software is divided in small units which is delivered earlier to the customers. V-Model - It is more focused on testing. For every phase some testing activity are done.

24. Software Engineering, 2011Software Processes 24 The (Rational) Unified Process A modern process model derived from the work on the UML. Normally described from 3 perspectives A dynamic perspective that shows phases over time; A static perspective that shows process activities; A practice perspective that suggests good practice.

25. Software Engineering, 2011Software Processes 25 (R)UP phase model

26. Software Engineering, 2011Software Processes 26 (R)UP phases One cycle consists of four phases: Inception Establish the business case for the system. Elaboration Develop an understanding of the problem domain and the system architecture. Construction System design, programming and testing. Transition Deploy the system in its operating environment.

27. Software Engineering, 2011Software Processes 27 (R)UP phases and iterations Picture taken from: http://www.ibm.com/developerworks/webservices/library/ws-soa-term2/http://www.ibm.com/developerworks/webservices/library/ws-soa-term2/

28. Software Engineering, 2011Software Processes 28 (R)UP In each phase many different workflows (like management, environment, design, implementation workflow, etc.) can be addressed simultaneously. At the end of each cycle some kind of prototype or artifact are produced. The phases can be repeated many times (i.e. iterations), producing one or many prototypes or artifacts. During the cycles the requirements are stable which offers possibilities to plan the development process for this cycle. Between the cycles the requirements change.

29. Software Engineering, 2011Software Processes 29 (R)UP good practice Develop software iteratively Manage requirements Use component-based architectures Visually model software Verify software quality Control changes to software

30. Software Engineering, 2011Software Processes 30 Spiral Development Process is conceived as a spiral rather than as a sequence of activities with backtracking. Each loop in the spiral represents a phase in the process. No fixed phases such as specification or design - loops in the spiral are chosen depending on what is required. Risks are explicitly assessed and resolved throughout the process.

31. Software Engineering, 2011Software Processes 31 Spiral model (Boehm 87) Objective setting Specific objectives for the phase are identified. Risk assessment and reduction Risks are assessed and activities put in place to reduce the key risks. Development and validation A development model for the system is chosen which can be any of the generic models. Planning The project is reviewed and the next phase of the spiral is planned.

32. Software Engineering, 2011Software Processes 32 Spiral model sectors Objective setting Specific objectives for the phase are identified. Risk assessment and reduction Risks are assessed and activities put in place to reduce the key risks. Development and validation A development model for the system is chosen which can be any of the generic models. Planning The project is reviewed and the next phase of the spiral is planned.

33. Software Engineering, 2011Software Processes 33 Agile Methods Result from dissatisfaction with the overheads involved in design methods. Software Development History: During the 1970s, it was discovered that most large software development projects failed. During the 1980s, many of the reasons for those failures began to be recognized. In the 1990s, experiments and measurements were used to validate individual methods to prevent failure. The current decade is characterized by complete processes to improve success.

34. Software Engineering, 2011Software Processes 34 Project Failure – the trigger for Agility One of the primary causes of project failure was the extended period of time it took to develop a system. Costs escalated and requirements changed. Agile methods intend to develop systems more quickly with limited time spent on analysis and design.

35. Software Engineering, 2011Software Processes 35 Agile Development

36. Software Engineering, 2011Software Processes 36 What is an Agile method? (1) Focus on the code rather than the design. Based on an iterative approach to software development. Intended to deliver working software quickly. Evolve quickly to meet changing requirements. There are claims that agile methods are probably best suited to small/medium-sized business systems or PC products.

37. Software Engineering, 2011Software Processes 37 What is an agile method? (2) Agile proponents believe: Current software development processes are too heavyweight or cumbersome Too many things are done that are not directly related to software product being produced Current software development is too rigid Difficulty with incomplete or changing requirements Short development cycles (Internet applications) More active customer involvement needed

38. Software Engineering, 2011Software Processes 38 What is an agile method? (3) Agile methods are considered Lightweight People-based rather than Plan-based Several agile methods No single agile method Extreme Programming (XP) most popular No single definition Agile Manifesto closest to a definition Set of principles Developed by Agile Alliance

39. Software Engineering, 2011Software Processes 39 Summary of Principles of agile methods

40. Software Engineering, 2011Software Processes 40 What are the Agile Methodologies? eXtreme Programming has received the most attention, but here is a list: XP SCRUM DSDM The Crystal Family ASD  FDD  dX (agile RUP)  Open Source  Agile Modeling  Pragmatic Programming Since Larman is based on (R)UP, dX might be interesting.

41. Software Engineering, 2011Software Processes 41 eXtreme Programming Development and delivery of very small increments of functionality. Relies on constant code improvement, user involvement in the development team and pair wise programming. Emphasizes Test Driven Development (TDD) as part of the small development iterations.

42. Software Engineering, 2011Software Processes 42 Claimed Problems with agile methods It can be difficult to keep the interest of customers who are involved in the process. Team members may be unsuited to the intense involvement that characterizes agile methods. Prioritising changes can be difficult where there are multiple stakeholders. Maintaining simplicity requires extra work. Contracts may be a problem as with other approaches to iterative development.

43. Software Engineering, 2011Software Processes 43 Problems with incremental development (from a waterfall eye…) Management problems Progress can be hard to judge and problems hard to find because there is no documentation to demonstrate what has been done. Contractual problems The normal contract may include a specification; without a specification, different forms of contract have to be used. Validation problems Without a specification, what is the system being tested against? Maintenance problems Continual change tends to corrupt software structure making it more expensive to change and evolve to meet new requirements.

44. Software Engineering, 2011Software Processes 44 Is / Isn’t: Misconstruing the message 1. Agile SD is cheating 2. Agile SD requires the best developers 3. Agile SD is hacking 4. Agile SD won’t work for all projects

45. Software Engineering, 2011Software Processes 45 1. Agile techniques are “cheating”. · Hire good people; ·Seat them close together to help each other out; ·Get them close to the customers and users; ·Arrange for rapid feedback on decisions; ·Let them find fast ways to document their work; ·Cut out the bureaucracy. This is: cheating stacking the deck a good idea the heart of agile software development

46. Software Engineering, 2011Software Processes 46 2. Agile only works with the best developers. Every project needs at least one experienced and competent lead person. (Critical Success Factor) Each experienced and competent person on the team permits the presence of 4-5 “average” or learning people. With that skill mix, agile techniques have been shown to work many times.

47. Software Engineering, 2011Software Processes 47 3. Agile is hacking. (Hacker interpretations are available & inevitable.) Hackers: “...spend all their time coding” Agilists:...test according to project priorities, recheck results with users often. Hackers: “...talk to each other when they are stuck” Agilists:...talk to each other and customers as a matter of practice. Hackers: “...avoid planning” Agilists:...plan regularly Hackers: “...management caves in out of fear” Agilists:...expect management to provide priorities, & participate jointly project adjustments.

48. Software Engineering, 2011Software Processes 48 4. Agile won’t work for all projects. Right. (Business isn’t fair). Agile is an attitude prioritizing: Project evaluation based on delivered code. Rapid feedback. People as a value center. Creativity in overcoming obstacles. Not every team... values the Agile value set.... can set up the needed trust and communication.