1. Software Development Process includes: all major process activities all major process activities resources used, subject to set of constraints (such as schedule) resources used, subject to set of constraints (such as schedule) intermediate and final products intermediate and final products Sub-processes, with hierarchy or links Sub-processes, with hierarchy or links entry and exit criteria for each activity entry and exit criteria for each activity sequence of activities, so timing is clear sequence of activities, so timing is clear guiding principles, including goals of each activity guiding principles, including goals of each activity constraints for each activity, resource or product constraints for each activity, resource or product

2. Reasons for modeling a process To form a common understanding To form a common understanding To find inconsistencies, redundancies, omissions To find inconsistencies, redundancies, omissions To find and evaluate appropriate activities for reaching process goal To find and evaluate appropriate activities for reaching process goal To tailor a general process for the particular situation in which it will be used To tailor a general process for the particular situation in which it will be used

3. Examples of process models Waterfall model Waterfall model Prototyping Prototyping V-model V-model Operational specification Operational specification Transformational model Transformational model Phased development: increments and iteration Phased development: increments and iteration Spiral model Spiral model

4. Tools and techniques for process modeling Example: Lai notation Example: Lai notation activity activity sequence sequence process model process model resource resource control control policy policy organization organization

6. Desirable properties of process modeling tools and techniques Facilitates human understanding and communication Facilitates human understanding and communication Supports process improvement Supports process improvement Supports process management Supports process management Provides automated guidance in performing the process Provides automated guidance in performing the process Supports automated process execution Supports automated process execution

7. The Waterfall Model

8. The Incremental Model

9. The RAD Model

10. Evolutionary Models: Prototyping communication Quick plan Modeling Quick design Construction of prototype Deployment delivery & feedback

11. Evolutionary Models: The Spiral

12. Spiral model (Barry Boehm) Important features: Important features: — Risk analysis — Prototyping — Iterative framework allowing ideas to be checked and evaluated — Explicitly encourages alternatives to be considered Good for large and complex projects but not simple ones Good for large and complex projects but not simple ones

14. The Star lifecycle model Suggested by Hartson and Hix (1989) Suggested by Hartson and Hix (1989) Important features: Important features: — Evaluation at the center of activities — No particular ordering of activities. Development may start in any one — Derived from empirical studies of interface designers

15. The Star Model (Hartson and Hix, 1989) Evaluation Conceptual/ formal design Requirements specification Prototyping task/functional analysis Implementation

16. A Lifecycle for RAD (Rapid Applications Development) JAD workshops Project set-up Iterative design and build Engineer and test final prototype Implementation review

17. Evolutionary Models: Concurrent

18. Still Other Process Models Component based development—the process to apply when reuse is a development objective Component based development—the process to apply when reuse is a development objective Formal methods—emphasizes the mathematical specification of requirements Formal methods—emphasizes the mathematical specification of requirements AOSD—provides a process and methodological approach for defining, specifying, designing, and constructing aspects AOSD—provides a process and methodological approach for defining, specifying, designing, and constructing aspects Unified Process—a “use-case driven, architecture- centric, iterative and incremental” software process closely aligned with the Unified Modeling Language (UML) Unified Process—a “use-case driven, architecture- centric, iterative and incremental” software process closely aligned with the Unified Modeling Language (UML)

19. inception The Unified Process (UP) inception elaboration

20. UP Phases

21. UP Work Products

22. Tracking project progress Do you understand customer problem and needs? Do you understand customer problem and needs? Can you design a system to solve customer problem or satisfy customer needs? Can you design a system to solve customer problem or satisfy customer needs? How long will it take you to develop the system? How long will it take you to develop the system? How much will it cost to develop the system? How much will it cost to develop the system?

23. Project deliverables Documents Documents Demonstrations of function Demonstrations of function Demonstrations of subsystems Demonstrations of subsystems Demonstrations of accuracy Demonstrations of accuracy Demonstrations of reliability, performance or security Demonstrations of reliability, performance or security

24. Milestones and activities Activity: takes place over a period of time Activity: takes place over a period of time Milestone: completion of an activity -- a particular point in time Milestone: completion of an activity -- a particular point in time Precursor: event or set of events that must occur in order for an activity to start Precursor: event or set of events that must occur in order for an activity to start Duration: length of time needed to complete an activity Duration: length of time needed to complete an activity Due date: date by which an activity must be completed Due date: date by which an activity must be completed

27. Slack or float time Slack time = available time - real time = latest start time - earliest start time

29. Project personnel Key activities requiring personnel: Key activities requiring personnel: requirements analysis requirements analysis system design system design program design program design program implementation program implementation testing testing training training maintenance maintenance quality assurance quality assurance

30. COCOMO model: stages of development application composition: application composition: prototyping to resolve high-risk user interface issues prototyping to resolve high-risk user interface issues size estimates in object points size estimates in object points early design: early design: to explore alternative architectures and concepts to explore alternative architectures and concepts size estimates in function points size estimates in function points postarchitecture: postarchitecture: development has begun development has begun size estimates in lines of code size estimates in lines of code

32. Table 3.10. Application point complexity levels. For ScreensFor Reports Number and source of data tables Number of views contained Total < 4 (<2 server, <3 client) Total < 8 (2-3 server, 3-5 client) Total 8+ (>3 server, >5 client) Number of sections contained Total < 4 (<2 server, <3 client) Total < 8 (2-3 server, 3- 5 client) Total 8+ (>3 server, >5 client) <3simple medium0 or 1simple medium 3 - 7simplemediumdifficult2 or 3simplemediumdifficult 8 +mediumdifficult 4 +mediumdifficult

33. Table 3.11. Complexity weights for application points. Object typeSimpleMediumDifficult Screen123 Report258 3GL component--10

34. Evaluating models Mean magnitude of relative error (MMRE) Mean magnitude of relative error (MMRE) absolute value of mean of absolute value of mean of [(actual - estimate)/actual] goal: should be.25 or less goal: should be.25 or less Pred(x/100): percentage of projects for which estimate is within x% of the actual Pred(x/100): percentage of projects for which estimate is within x% of the actual goal: should be.75 or greater for x =.25 goal: should be.75 or greater for x =.25

35. Risk management requirements Risk impact: the loss associated with the event Risk impact: the loss associated with the event Risk probability: the likelihood that the event will occur Risk probability: the likelihood that the event will occur Risk control: the degree to which we can change the outcome Risk control: the degree to which we can change the outcome Risk exposure = (risk probability) x (risk impact)

36. Three strategies for risk reduction avoiding the risk: change requirements for performance or functionality avoiding the risk: change requirements for performance or functionality transferring the risk: transfer to other system, or buy insurance transferring the risk: transfer to other system, or buy insurance assuming the risk: accept and control it assuming the risk: accept and control it risk leverage = difference in risk exposure divided by cost of reducing the risk

37. Boehm’s top ten risk items Personnel shortfalls Personnel shortfalls Unrealistic schedules and budgets Unrealistic schedules and budgets Developing the wrong functions Developing the wrong functions Developing the wrong user interfaces Developing the wrong user interfaces Gold-plating Gold-plating Continuing stream of requirements changes Continuing stream of requirements changes Shortfalls in externally-performed tasks Shortfalls in externally-performed tasks Shortfalls in externally-furnished components Shortfalls in externally-furnished components Real-time performance shortfalls Real-time performance shortfalls Straining computer science capabilities Straining computer science capabilities

38. Project plan contents project scope project scope project schedule project schedule project team organization project team organization technical description of system technical description of system project standards and procedures project standards and procedures quality assurance plan quality assurance plan configuration management plan configuration management plan documentation plan documentation plan data management plan data management plan resource management plan resource management plan test plan test plan training plan training plan security plan security plan risk management plan risk management plan maintenance plan maintenance plan

39. Anchoring milestones Objectives: Why is the system being developed? Objectives: Why is the system being developed? Milestones and schedules: What will be done by when? Milestones and schedules: What will be done by when? Responsibilities: Who is responsible for a function? Responsibilities: Who is responsible for a function? Approach: How will the job be done, technically and managerially? Approach: How will the job be done, technically and managerially? Resources: How much of each resource is needed? Resources: How much of each resource is needed? Feasibility: Can this be done, and is there a good business reason for doing it? Feasibility: Can this be done, and is there a good business reason for doing it?