1. Chapter 2 The 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 of software 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 about analysis, 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
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 Level 2: Repeatable Level 3: Defined
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 Level 5: Optimizing
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
Due next Friday 5 July.