The Process

1. The Process Infsy 570 Dr. R. Ocker

2. Chapter 2 (Pressman, 1997) and Readings (Boehm88, Alavi84, Mantei&Teorey88)

3. The Process • software process • framework for the tasks that are required to build high-quality software • Quality - basic notion behind SWE

4. some SWE definitions • the establishment and use of sound engineering principles in order to obtain economically software that is reliable and works efficiently on real machines • (1) the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software. • (2) the study of approaches used in (1).

5. Process, Methods, and Tools

6. SWE Process • glue that holds everything together; supposed to enable rational and timely development of SW • process defines the framework that must be followed for sw delivery • used for management control • establish the context in which technical methods are applied, etc.

7. SWE Methods • provide the technical how to’s for building sw; • methods encompass tasks, including: • requirements analysis • design • program construction • testing • maintenance

8. SWE Tools • provide automated support for the process and methods • CASE - when tools are integrated so that information created by one tool can e used by another

9. Generic view of SWE • engineering is the analysis, design, construction, verification, and management of technical entities.

10. 3 generic phases of SWE: • definition • development • maintenance

11. 1. definition phase - focus on what • what information is to be processed • what function and performance are desired • what system behavior can be expected • what interfaces are needed • what design constraints exist • what validation criteria are required to define a successful system

12. 3 tasks occur • 1. system or information engineering • 2. software project planning • 3. requirements analysis

13. 2. development phase - focus on how • how data are to be structured • how function is to be implemented • how interfaces are to be characterized • how design will be translated into programming languages • how testing will be performed

14. 3 specific technical tasks always occur • 1. software design • 2. code generation • 3. software testing

15. 3. maintenance phase - focus on change • error correction • adaptations required as SW evolves • changes due to enhancements brought about by changing customer requirements

16. Umbrella activities • applied throughout the sw process; include: • project tracking and control • formal technical reviews • quality assurance • configuration management • document preparation and production • measurement • risk management

17. SW Process • emphasis on process maturity • Software Engineering Institute (SEI) developed comprehensive model based upon a set of SWE capabilities that should be present as organizations reach different levels of process maturity

18. capability maturity model • defines key activities required at different levels of process maturity • 5 process maturity levels

19. level 1 - initial • sw process is ad hoc, maybe even chaotic • few processes are defined • success depends on individual effort

20. level 2 - repeatable • basic project management processes are established to track cost, schedule, and functionality • Necessary process discipline is in place to repeat earlier successes on projects with similar applications

21. level 3 - defined • sw process for both management and engineering activities is documented, standardized, and integrated into an organization-wide sw process • all projects use a documented and approved version the this for developing and maintaining sw

22. level 4 - managed • detailed measures of sw process and product quality are collected • both sw process and products are quantitatively understood and controlled using detailed measures

23. level 5 - optimizing • continuos process improvement is enabled by quantitative feedback from the process and from testing innovative ideas and technologies.

24. Software Process Models • Process models differ from a sw method/methodology • method’s primary focus is on: • how to navigate through each phase • e.g. partitioning functions • how to represent the products of each phase • e.g. structure charts • software process models specify the order in which a project should carry out its major tasks

25. We will look at: • code-and-fix model • linear sequential model (life cycle) • prototyping model • human factors approach*** • RAD model • Evolutionary process models (iterative) • incremental model • Spiral model*****

26. A. Code-and-Fix Model (2 steps) • 1. Write some code • 2. Fix the problem in the code • earliest process model • problems: spaghetti code, lack of planning, difficult to maintain over time, no requirements phase

27. B. Linear Sequential/ Stagewise/Life Cycle and Waterfall Models(fig. 1, Boehm88) • software developed in successive stages (linear sequential) • Waterfall - added feedback loops between stages • followed code-and-fix model • traditional approach to development • not iterative but sequential stages • deliverables and milestones at each stage

28. basic stages: • analysis • design • coding • testing • maintenance

29. Advantages: • designed for control • complete system delivered after linear sequence completed

30. Disadvantages: • emphasis on document driven standards (e.g. fully elaborated documents as completion criteria for early requirements and design phases); • can result in elaborate specs. of poorly understood user interfaces followed by design and development of large quantities of unusable code

31. C. Prototyping Model • designed to help understand requirements • build an experimental system rapidly and inexpensively for users to evaluate

32. 2 types of prototypes: • 1. evolutionary • prototype evolves into working system • 2. throw away • after prototype completed and requirements determined, it is “thrown away” • software developed beginning with design stage

33. iterative process of development (fig. 1 Alavi84) • 1. identify initial user requirements • 2. develop prototype • 3. use & evaluate prototype • 4. revise prototype (back to 3)

34. prototyping • prototyping much more iterative than SDLC • promotes design changes • less formal approach than SDLC • quickly generate working model of system

35. Advantages of prototyping: • useful when uncertainty about information requirements or design solutions • good for design of user interface • encourages user involvement throughout development

36. Disadvantages: • no detailed specifications - should not substitute for careful requirements analysis • better suited for smaller applications • more difficult to control than SDLC - must plan the effort in advance to control for cost, effort, and time limits • be prepared for more changes than in SDLC

37. D. Human Factors (Mantei & Teory, 1988) • incorporates changes into prototyping process model based on human factors engineering

38. prototyping lifecycle (fig. 1) • fits prototyping into linear sequential (life cycle) process model • feasibility study • requirements definition • global design • prototype construction • user evaluation • system implementation • testing • update and maintenance

39. fig. 2 add human factors to life cycle • market analysis • feasibility study • requirements definition • product acceptance analysis • task analysis • global design • prototype construction

40. fig. 2 (cont.) add human factors to life cycle • user testing and evaluation • user evaluation • system implementation • product testing • user testing • update and maintenance • product survey

41. Human Factors aspects: • MARKET ANALYSIS (iterative) *- Run “focus groups” with users to determine their perceptions and needs • PRODUCT ACCEPTANCE ANALYSIS * - Prepare a system “mockup” for presentation to a sample of users (changes can be recommended at this point). These changes result in a loop back to the requirements definition stage.

42. Human Factors aspects: • TASK ANALYSIS *- Examines the users’ mental process relative to the procedures currently being used. The results are employed in the global design and prototype construction stages in “tuning” the user interface to reflect their thought process.

43. Human Factors aspects: • USER TESTING AND EVALUATION * - finished prototype presented to sample of users for testing (ease of use, functionality and performance). • Resultant design changes require looping back through the global design and prototype construction stages. • Major system failings call for revisiting the requirements definition stage.

44. Human Factors aspects: • USER TESTING * - Upon completion of “user testing and evaluation”, the system is implemented and undergoes traditional product testing (unit and system) by the developers. The system is now subjected to a second round of USER testing.

45. Human Factors aspects: • PRODUCT SURVEY * -obtain more user feedback • This stage is tied to the ongoing update and maintenance process. • Small changes handled by looping back to requirements determination stage. • significant revisions may require going all the way back to “market analysis”, for a complete re-evaluation.

46. Other Considerations: • Cost effectiveness increases with the number of users • Savings from running user studies also rise with user population • Rule of thumb - use a prototype when the cost is less than 25% of the total project cost • Human factors model not recommended for small/simple projects, better suited to large user base or complex systems

47. Good example... • NOTE: This article provides a great example of applying numbers (benefits and costs) to SWE.

48. E. RAD Model • linear sequential process • emphasizes very short development cycle (60-90 days) • use when requirements are well-understood and project is scaleable (able to break into concurrent pieces) • each major function developed by a separate RAD team • emphasizes reuse

49. RAD phases: • 1. business modeling • look at information flow among business processes • 2. data modeling • data objects to support the business • 3. process modeling • create process descriptions to support business functions

50. RAD phases: • 4. application generation • 4th generation languages, reuse existing programs • 5. testing & turnover • test new components only