Chapter 2 The Process

1. Chapter 2The Process

2. What is Software Process? • A framework for the tasks that are required to build high-quality software.

3. Is Process synonym with SE? • The answer is “yes” and “no”. • A software process defines the approach that is taken as software is engineered. • But software engineering also encompasses technologies that populates the process – technical methods and automated tools.

4. 2.1 Software Engineering: A Layered Technology “Software engineering is the establishment and use of sound engineering principles in order to obtain economically software that is reliable and works efficiently on real machines.” [Fritz Beuer] Lack ofsoftware quality, customer satisfaction, timely product delivery, importance of measurement and metrics, and mature process.

5. SE: A Layered Technology • “Software engineering: (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 approach as in (1).” [IEEE]

6. A Layered Technology Software Engineering Software Engineering tools methods process model a “quality” focus

7. A “quality” focus • Continuous process improvement • Bedrock that supports software engineering

8. Process • Is the foundation of software engineering • Defines a framework for a set of key process areas (KPAs)  • Effective delivery of SE technology • Management control of software project • Context of technical methods applied • Work products • Milestones, Quality ensured • Proper change management

9. Methods • Provide technical how-to’s for building software. • Encompass a broad array of tasks that include requirements analysis, program construction, testing, and support. • Rely on a set of basic principles that govern each area of the technology and include modeling activities and other descriptive techniques

10. Tools • Provide automated or semi-automated support for the process and the methods. • CASE: computer-aided software engineering is a system for the support of software development. • Combines SW, HW, and a SE database (a repository containing important information aboutanalysis, design, program construction, and testing)

11. A Generic View of SE • Engineering is analysis, design, construction, verification, and management of technical (or social) entities. • Entity  computer software • A software engineering process must be defined: definition phase, development phase, and support phase.

12. Definition Phase Focuses on “what” • What information is to be processed? • What function and performance are desired? • What system behavior can be expected? • Interface, design constraints, validation criteria identify key requirements of the system and SW.

13. Development Phase Focuses on “how” • How data are to be constructed? • How function is to be implemented within a software architecture? • Procedural details, interfaces, design  programming, testing. Three technical tasks: software design, code generation, software testing.

14. Support Phase • Focuses on “change” associated with error correction, adaptations, changes. • Four types of changes: • Correction  Corrective maintenance • Adaptation  Adaptive maintenance • Enhancement  Perfective maintenance • Prevention  Preventive maintenance, often called Software Engineering  more easily corrected, adapted, and enhance.

15. Umbrella Activities • Software project tracking and control • Formal technical review • Software quality assurance • Software configuration management • Document preparation and production • Reusability management • Measurement • Risk management

16. A Common Process Framework • Common process framework • Framework activities • work tasks • work products • milestones & deliverables • QA checkpoints • Umbrella Activities

17. Process Maturity • Software Engineering Institute (SEI) has developed a comprehensive model predicated on a software engineering capabilities that should be present as organization reach different levels of process maturity. • Called Capability Maturity Model (CMM).

18. CMM • Level 1: Initial • The software process is characterized ad hoc and occasionally chaotic. • Level 2: Repeatable • Basic project management process are established to track cost, schedule, and functionality. • Level 3: Defined • the software process for both management and engineering activities is documented, standardized and integrated into an organizationwide software process.

19. CMM (Cont’d) • Level 4: Managed • Detailed measures of the software process and product quality are collected. • Both SW process and product are quantitatively understood and controlled using detailed measures. • Level 5: Optimizing • Continuous process improvement is enabled by quantitative feedback from the process and from testing innovative ideas and technologies.

20. Key Process Areas (KPAs) Each KPA is described by identifying the following characteristics: • Goals • Commitments • Abilities • Activities • Methods for monitoring implementation • Methods for verifying implementation

21. KPA (Cont’d) • Each of the KPAs is defined by a set of key practices that contribute to satisfying its goals. • The key practices are policies, procedures, and activities. • Key indicators: those of key practices or components of key practices that offer the greatest insight into whether the goals of a key process have been achieved.

22. 2.3 Software Process Models • A software engineer must incorporate a development strategy that encompasses the process methods, and tools layers. • This strategy is often referred to as a process model or a software engineering paradigm. • A process model is chosen based on the nature of project and application, the methods and tools to be used, and the controls and deliverables that are required.

23. Process as Problem Solving

24. 2.4 The Linear Sequential Model • Sometimes called the classic life cycle or the waterfall model.

25. The Linear Sequential Model Activities: • System/information engineering and modeling • Requirements gathering • Interface with other elements: HW, SW, database • Software requirement analysis • Understand nature of SW to be built • Function, behavior, performance and interface. • Documented and reviewed with the customer

26. The Linear Sequential Model • Design: • A multi-step process focuses on data structure, SW architecture, interface representations, and procedural (algorithmic) detail. • The design process translates requirements into a representation of the SW that can be assessed for quality before coding begins. • Documented

27. The Linear Sequential Model • Code generation • Design  machine readable form • Testing • Test all functions, both internal/external • Uncover errors • Support/maintenance • Deal with all kinds of changes that may be occurred after SW delivery

28. 2.5 The Prototyping Model • The prototype can serve as “the first system” • Users get a feel for the actual system and developers get to build something immediately • A customer defines a set of general objectives for SW but does not identify detailed input, processing, or output requirements.

29. The Prototyping Model Prototyping

30. The Prototyping Model This approach can be problematic: • The customer misunderstands as a working version with a few fixes. • The developer often makes implementation compromises in order to get a prototype to work quickly.  The customer and developer must agree that the prototype is built to serve as a mechanism for defining requirements.

31. 2.6 The RAD Model • Is a “high-speed” adaptation of the linear sequential model in which rapid development is achieved by using component-based construction. • Is an incremental software development process model that emphasizes an extremely short development cycle.

32. The RAD Model Phases: • Business modeling • Data modeling • Process modeling • Application generation: 4GT • Testing and turnover

33. The RAD Model RAD

34. The RAD Model Drawbacks: • RAD requires sufficient human resources to create the right number of RAD team, for a large project. • RAD requires strong commitment from developers and customers in much abbreviated time frame. • A system must be properly modularized. • RAD is not appropriate when technical risks are high.

35. Evolutionary Software Process Model • Business and product requirements often change as development proceeds. • Tight market deadlines, etc..

36. 2.7.1 The Incremental Model

37. 2.7.2 The Spiral Model • Proposed by Boehm. • It provides the potential for rapid development of incremental versions of the software. • A spiral model is divided into a number of framework activities, also called task regions. • Each of the regions is populated by a set of work tasks, called a task set.

38. The Spiral Model

39. 2.7.3 The WINWIN Spiral Model Addresses more on customer communication, the following activities are defined: • Identification of the system or subsystem’s key “stakeholder”. • Determination of the stakeholders’ “win conditions”. • Negotiation of the stakeholders’ win conditions to reconcile them into a set of win-win conditions for all concerned.

40. 2.8 Component-Based Development • OO technologies provide the technical framework for a component-based process model for SE. • The process to apply when reuse is a development objective.

41. 2.9 The Formal Methods Model • The process to apply when a mathematical specification is to be developed • Cleanroom software engineering—emphasizes error detection before testing

42. Homework #1 • Problem 2.11-2.13 • Due next Friday 5 July.