1. The Software Development Process "It is better not to proceed at all, than to proceed without method." --Descartes "Stop the life cycle--I want to get off" -- Barry Boehm

2. A Software Development Process Organizes the Activities of Software Development Gather Requirements Design System Test Unit Test Implement Rework Correct Mistakes Review Create Prototype Manage Risks Integrate Developing software without a defined process is chaotic and inefficient Following a defined process makes software development more orderly, predictable and repeatable...

3. Software Process A software process is more detailed than a life cycle model. A Software process says who does what when. A software process includes: –Roles –Workflows –Procedures –Standards –Templates

4. Resistance to Process Some people view following a process as an unnecessary tax on productivity. That is, they view the time devoted to following a process as taking away from time that could otherwise be spent on “productive work” without any otherwise appreciable affects on the development process [McConnell 1998].

5. The Reality A group not following a defined process might show more productivity at the start, but rework due to poor development practices will quickly outweigh any time saved by not following a process [McConnell 1998]. Too little process in the beginning often leads to too much process towards the end The overhead of following a process decreases with time

6. When Bad Process Happens to Good People Some processes are rigid and bureaucratic; don’t use these Some people abuse process for their own agenda (i.e. feed their desire to have power and control, block changes or developments they don’t agree with); don’t allow these people to have authority over the process

7. Characteristics of a Good Process A good software process is: –Repeatable – a process is repeatable if it can be performed again on a new project? If the process isn’t documented, it probably isn’t repeatable. –Predictable – Organizations like predictability. It means they know what to expect when repeating the process. –Adaptable - the process can be tailored for the unique aspects of a project. In general, the more adapted a process is, the less predictable it will be. –Learnable – –Measurable – Measurability is important for tracking, control, visibility and improvability. –Improvable

8. Terminology Software Life Cycle – The high-level phases or stages that software goes through from the moment it is conceptualized until the last version is removed from the last machine. The software life cycle consists of new development followed by a number of maintenance updates and finally retirement. [IEEE 610] Software Development Life Cycle (SDLC) – The sequence of phases a project goes through from start to finish. The standard phases of the SDLC are: requirements specification, analysis, design, implementation and test. Inception and delivery may also be included. Note, these phases are not necessarily sequential. They may overlap or be performed iteratively. The SDLC is applied to new development and maintenance updates. [IEEE 610]

9. Terminology [cont] Software Life Cycle Models (aka Software Process Models) – abstract models that describe a class of development approaches with similar characteristics. Some of the criteria used to distinguish software life cycle models are: timing between phases, entry and exit criteria between phases and the artifacts created during each phase. Examples include: Waterfall, Spiral, Rapid Prototyping, Incremental Development, etc.

10. Terminology [cont] Software Process, Methods, and Methodologies

11. Big-M Methodology

12. Phase Names vs. Activity Names Is requirements (or design, or coding, or etc.) a phase or an activity? Terms such as requirements, design, coding, etc. are used to characterize a phase (adjective) and also an activity (verb/adverb) that might occur during one or more phases. It’s important to distinguish between a label given to a phase and the activity that occurs during that phase.

13. Phase Names vs. Activity Names [cont] The label on a phase is descriptive of the dominate activity performed during that phase. It becomes confusing when there isn’t a one-to-one correspondence between phase name and activity within that phase.

14. Phase Names vs. Activity Names [cont] The Rational Unified Process (RUP) avoids any ambiguity/confusion by using phase names that can’t be confused with the activities that might take place during a phase. The names are also more appropriate because they better match the milestones and deliverable of the phases.

16. Software Life Cycle Models Abstract models that define a few broad types of software development processes Life cycle models specify: –Major phases including milestones and deliverables –Timing between each phase –Entry and exit criteria for each phase Life cycle models are a starting point for project management

17. Antiquated Software Life Cycle Models Code-and-Fix Development Waterfall

18. Code-and-Fix Development Not a viable development model for most projects. Code-and-Fix is to software development as dog paddling is to swimming.

19. Waterfall Sequential stages with little or no backtracking

20. The Waterfall Model Illustrated

21. Risk Profile of Waterfall Project When following the waterfall process model risks aren’t resolved until late in the development cycle.

22. What’s Wrong with these Antiquated Life Cycle Models? Code-and-fix lacks discipline and is inefficient Waterfall, although appropriate for some projects, doesn’t fit well in today’s environment

23. Iterative and Incremental A characteristic of modern life cycle models. The product evolves incrementally over a series of iterations.

24. Benefits of an Iterative and Incremental Approach More appropriate for applications with emergent requirements. For many UI applications, requirements aren’t well-known form the start but rather emerge over time based on experience with early increments and prototypes. Incremental functionality is a more accurate measure of progress than paper deliverables. This provides better visibility into project status. Manages risks better (technical risks with architecture and programming and project risks with meeting schedule and budget targets)

25. Modern Software Life Cycle Models Spiral Staged Evolutionary Prototyping Evolutionary Delivery

26. Spiral

27. Staged Requirements and planning occur up-front but product is developed and delivered over a series of iterations.

28. Evolutionary Prototyping The contents of each iteration is driven by feedback from previous iterations.

29. Evolutionary Delivery The middle ground. Considerable planning and product definition occur up-front, but the content of each iteration is also influenced by feedback from previous iterations.

30. Guidelines for Selecting a Lifecycle Model

31. Other forms of prototyping Evolutionary prototyping is a life cycle model—a way of organizing the activities of software development. Prototyping can also be used selectively on any project as a technique for buying information. Developing the wrong product can be costly. Sometimes it pays to invest in an early quick-and-dirty prototype to explore requirements and resolve technical risks before committing to expensive production-quality development. With evolutionary prototyping the product increment is expected to evolve into the eventual production system. With other forms of prototyping the software created may or may not be a part of the eventual implementation. If it is a paper prototype, definitely not. If the prototype is a series of screens created with an IDE, the screens may very well end up in the final product.

32. Options for creating a prototype Paper mock-ups are perhaps the simplest form of prototyping. A paper mock-up is a stack of fabricated screen shots created by hand or with the help of a graphics editing or desktop publishing system. There should be a page for every view and/or state of the application you want to test. The experimenter simulates the behavior of the application by showing different pages at different times in reaction to the test subject’s actions [Nielson 93]. Most integrated development environments (IDE’s) come with tools for creating UI’s by dragging and dropping UI elements on a canvas. You don’t have to implement the behavior behind each screen to have a useful prototype. A small amount of control logic may be helpful to move from screen to screen. If your target language isn’t conducive to prototyping, you can create the prototype with a prototyping tool or high level (possibly scripting) language that has better support for rapid application development.

33. Horizontal and vertical prototyping A prototype represents a subset of the eventual system functionality. There are two dimensions along which a prototype can vary.

34. Horizontal and vertical prototyping A horizontal prototype is one that includes many features but little functionality behind each one. Think of a movie set with store front facades but no actual stores behind them. Horizontal prototyping helps to clarify requirements and evaluate usability. A vertical prototype is one that implements only a few features but each one in depth. Vertical prototyping can be used to explore various design and implementation options.

35. Other definitions of horizontal and vertical prototyping In the 1995 book, Advances in Computers, Marvin Zelkowitz defines horizontal and vertical prototyping such that the vertical axis is quality. This interpretation of the terms has been largely replaced by the definition given by Nielsen on page 94 in Usability Engineering [1993].

36. Throwaway Prototyping When code is written quickly without regard for sound engineering practices, it is poor bases on which to build and should be thrown out once the goals for creating the prototype have been accomplished. This form of prototyping is appropriately called throwaway prototyping.

37. Throwaway Prototyping With throwaway prototyping, a mock-up is created to learn more about a system’s requirements, design or implementation. Once the goals of creating the prototype are accomplished, it is discarded and the information is used to proceed with a production-quality increment of the system under development. The creation of throwaway prototypes is standard engineering practice.

38. Anchoring the Software Process Intuitively—Requirements, Architecture, Design, Code—seem like good milestones for marking progress during a software project, but in practice they don’t work so well. Rarely do these products evolve sequentially as discrete entities. More commonly, these artifacts evolve slowly in parallel. This makes them poor milestones for anchoring a software development process

39. Anchoring the Software Process - 2 Barry Boehm proposes an alternative set of milestones that are more appropriate for iterative development [IEEE Software July 1996]: –Life cycle objectives (Major requirements, major scenarios of operation, candidate architecture, and top-level plan are known) –Life cycle architecture (Most requirements and scenarios of operations are known, validated system architecture) –Initial operational capability (The product is ready for transition to its production environment.