Software Engineering of Standalone Programs

1. Software Engineering of Standalone Programs • Prof. Ruth Dameron, dameron@colorado.edu • Course web site with course materials is under WebCT • Need an identikey and password • Call 303-735-HELP

2. Course web site contents • Go to http://webct.colorado.edu/ • Login if you have identikey and user-password • Lecture material -- PowerPoint files • Print in “handout” or in Notes format • “Pure black and white” • Homework assignments • Some additional items such as short articles or book excerpts • Other course information • syllabus with reading assignments, holidays • textbook information, PowerPoint lecture files • final exam information • office hours, contact information

3. Part of a whole • Software Engineering Certificate -- 9 hrs graduate credit • http://ece.colorado.edu/~swengctf/ • Software Engineering of Standalone Programs • Software Engineering of Multiprogram Systems • Software Engineering of Distributed Systems • The links at the above web site point to course materials that are not under control of WebCT. • Their purpose is to let you see what is covered in the 3 courses • Warning: Lecture notes that match the ones I use in class PLUS your homework assignments are the ones that are under WebCT.

4. Requirements Engineering Slides originally developed by Michael Madigan StorageTek Manager, PAL Engineering

5. Cobb’s Paradox "We know why projects fail, we know how to prevent their failure -- so why do they still fail?” Martin CobbTreasury Board of Canada SecretariatOttawa, Canada

6. Project Resolution Resolution Type 2 Challenged Resolution Type 1 Project Success Resolution Type 3 Impaired

7. Cost Overruns Percent Over Budget

8. Time Overruns Percent of Time Under Estimated

9. Content Deficiencies Percent of Originally Planned Functionality

10. Project Success Factors Other User Involvement Ownership Executive Management Support Smaller Project Milestones Realistic Expectation Competent Staff Clear Statement of Requirements Proper Planning Clear Vision and Objectives Hard-Working Focused Staff

11. Top Ten Project Success Factors 1. user involvement 2. executive management support 3. clear statement of requirements 4. proper planning 5. realistic expectations 6. smaller project milestones 7. competent staff 8. ownership 9. clear vision and objectives 10. hard-working, focused staff

12. Properties of Challenged Projects Other Unclear Objectives Lack of UserInvolvement Inc. Requirements & Specs Changing Requirements & Specs Unrealistic Time Frame Unrealistic Expectation Technology Incompetence Lack of Resources Lack of Executive Support New Technology

13. Top Ten Challenged Project Factors 1. Lack of user involvement 2. Incomplete requirements and specifications 3. Changing requirements and specifications 4. Lack of executive support 5. Technology Incompetence 6. Lack of Resources 7. Unrealistic expectations 8. Unclear objectives 9. Unrealistic timeframe 10. New technology

14. Incomplete Requirements Other Didn’t Need any Longer Lack of User Involvement Changing Requirements & Specs Lack of Resources Lack of IT Management Technology Illiteracy Unrealistic Expectations Lack of Executive Support Lack of Planning Properties of Impaired Projects

15. Top Ten Impaired Project Factors 1. Incomplete requirements 2. Lack of user involvement 3. Lack of resources 4. Unrealistic Expectations 5. Lack of executive support 6. Changing requirements & specs 7. Lack of planning 8. Didn’t need anymore 9. Lack of IT management 10. Technology illiteracy

16. Case Studies

17. High Level Software Concepts Model Based (System) Architecture Software Engineering (MBASE) Iterative Development (agile methods)

18. The Model-Clash Spider Web: Master Net7

19. Business case IKIWISI Stakeholder win-win Life cycle anchor points Risk management Key practices Domain model Requirements Architecture Code Documentation Cost Schedule Performance Reliability MBASE Integration Framework7 Success models Process Product entry/exit evaluation criteria criteria Planning and control Process models Product models Milestone content Evaluation and analysis Property models

20. What Does a Process Do for You? A software development process gives you • The information you need • When you need it • In a form that you can use • As much or as little as you need • Easy to find what you need

21. Dynamic structure Phases Process Disciplines Inception Elaboration Construction Transition Business Modeling Requirements Analysis & Design Implementation Static structure Test Deployment Configuration Mgmt Proj. Management Environment Preliminary Iteration(s) Iter.#1 Iter.#2 Iter.#n Iter.#n+1 Iter.#n+2 Iter.#m Iter.#m+1 Iterations Introducing the Rational Unified Process Process Made Practical

22. Tools Unified Tools for the Project Team Best Practices Process Made Practical Tools Unified Tools for the Project Team Select and DeployBest Practices Plan and Execute Iterative Projects Develop Iteratively Manage Requirements Use Component Architectures Model Visually (UML) Continuously Verify Quality Manage Change Requirements Management Visual Modeling Automated Testing Content Management Change Management Plan and Execute Iterative Projects Requirements Management Visual Modeling Automated Testing Content Management Change Management Measure Progress and Quality Measure Progress and Quality Collaborate & Communicate Project Information Collaborate & Communicate Project Information Unified Software Project Management Unified Software Project Management: an integrated solution to deploy, plan, execute, and monitor best practices

23. Requirements Engineering The disciplined application of scientific principles and techniques for developing, communicating, and managing requirements.6

24. User Requirements User Requirements ComponentDevelopment Systems Requirements Engineering Lifecycle User Requirements AcceptanceTest Capability Development SystemRequirements SystemArchitecture IntegrationTest System Development Component Development

25. SoftwareRequirements Architecturaldesign Integration &Verification Detailed design & coding User Requirements User Requirements User Requirements ComponentDevelopment Component Development Lifecycle

26. Requirements Engineering

27. Requirements Elicitation • Identify relevant sources of requirements (usually customer) • Determine what information is needed. • Analyze the gathered information, looking for implications, inconsistencies, or unresolved issues • Confirm your understanding of the requirements with the source • Synthesize appropriate statements of the requirements SoftwareRequirements

28. Outcome of good elicitation activities • The buyer/customer fully explore and fully understand their requirements. • The buyer/customers are able to separate their wants from their needs. • The buyer/customers are able to understand the capabilities and limitations of computer technology. • The buyer/customers understand the alternative solutions and impact of each alternative. • The buyer/customers understand the impact of the requirements on the developer and themselves. • The developers are solving the right problem. • The developers have confidence that the system to be delivered is feasible to build. • The developers have the trust and confidence of the customer. • The developers gain domain knowledge of the system

29. Outcome of poor elicitation effort • The customer probably will be dissatisfied. • The customer and developer have to cope with constantly changing requirements. • The developer is solving the wrong problem. • The developer has a difficult time building the system.

30. Project Success Factors User Involvement Executive Management Support Other Smaller Project Milestones Ownership Clear Statement of Requirements Realistic Expectation Proper Planning Competent Staff Clear Vision and Objectives Hard-Working Focused Staff Requirements ElicitationUser Involvement Criteria2 • Do I have the right user(s)? • Did I involve the user(s)early and often? • Do I have a quality user(s) relationship? • Do I make involvement easy? • Did I find out what the user(s) needs? SoftwareRequirements

31. Requirements Analysis • Obtain Requirements from all possible sources (include but not limited to): • observation and measurements of the current system • interviews with customers • current system documentation • feasibility studies • models and prototypes • competitive analysis SoftwareRequirements

32. Quality attributes

33. Requirements Specification • Software function • Performance • External Interfaces • Design Constraints • Quality Attributes SoftwareRequirements

34. Statement of Requirements Criteria Project Success Factors • Do I have a concise vision? • Do I have a functional analysis? • Do I have a risk assessment? • Do I have a business case? • Can I measure the project? SoftwareRequirements

35. Requirements Verification • To identify and resolve software problems and high risk issues early in the software cycle. • The assurance that the software requirement specification is in compliance with the system requirements, conforms to document standards, and is an adequate basis for the architectural design. Integration &Verification

36. Requirements Management • Basic responsibility is to keep project within costs, within budget, and to meet customers needs. • Estimate cost of system based on requirements. • Control the volatility of the requirements. • Manage the requirements configuration of the system • Negotiate requirement changes • Re-estimate cost of the system when requirements change. SoftwareRequirements

37. Requirements Engineering Requirements Elicitation Requirements Verification Requirements Analysis Requirements Specification Requirements Management

38. Requirements Elicitation Requirements Elicitation Requirements Elicitation Requirements Analysis Requirements Analysis Requirements Analysis Requirements Verification Requirements Verification Requirements Verification Requirements Specification Requirements Specification Requirements Specification Requirements Management Requirements Management Requirements Management Requirements Engineering III Release 1 Release 2 Release 3 Foundation Foundation Requirements Elicitation Requirements Analysis Requirements Verification Requirements Specification Requirements Management Requirements Management

39. Successful Release Cycle Proportions 4N months 3N months 2N Months

40. Success Attributes that Requirements Engineering Affect Project Success Factors • User Involvement • Clear Statement of requirements • Proper Planning • Realistic Expectations • Smaller Project Milestones • Clear Vision and Objectives • Hard Working, Focused Staff

41. SoftwareRequirements Detailed design & coding Architecturaldesign Integration &Verification User Requirements User Requirements User Requirements ComponentDevelopment Requirements Engineering Conclusion • Software Requirements Engineering includes: • elicitation • analysis • specification • verification and validation • management of requirements development process • Affects 7 of 10 attributes of successful projects

42. References • 1 The Standish Group, Chaos, January 1995 • 2 The Standish Group, UnfinishedVoyages, September 1995 • 3 Software Quality Measurement for Distributed Systems, RADC-TR-83-175 • 4 Requirements Engineering, Thayer, SMC 10/97, version 2 • 5 Richard Thayer, Software Requirements Engineering, IEEE, 1997 • 6 STEP, Operational Requirements for Automated Capabilities, STEP, 1991 • 7 MBASE, “Avoiding the Software Model-Clash Spiderweb,” IEEE Computer, November, 2000, pp. 120-122.