1. 1 Chapter 1 Software and Software Engineering Software Engineering: A Practitioner’s Approach, 7th edition by Roger S. Pressman

2. 2 Chapter Overview  What? A software process - a series of predictable steps that leads to a timely, high-quality product.  Who? Managers, software engineers, and customers.  Why? Provides stability, control, and organization to an otherwise chaotic activity.  Steps? A handful of activities are common to all software processes, details vary.  Work product? Programs, documents, and data.  Correct process? Assessment, quality deliverable.  What? A software process - a series of predictable steps that leads to a timely, high-quality product.  Who? Managers, software engineers, and customers.  Why? Provides stability, control, and organization to an otherwise chaotic activity.  Steps? A handful of activities are common to all software processes, details vary.  Work product? Programs, documents, and data.  Correct process? Assessment, quality deliverable.

3. 3 Outline  Software Engineering  The Software Process  Software Engineering Practices  Software Myths  How it All Starts  Software Engineering  The Software Process  Software Engineering Practices  Software Myths  How it All Starts

4. 4 Some Realities a concerted effort should be made to understand the problem before a software solution is developed design becomes a pivotal activity software should exhibit high quality software should be maintainable

5. 5 Software Engineering Definition Software engineering: the establishment and use of sound engineering principles in order to obtain economically software that is reliable and works efficiently on real machines. -The Seminal Definition(1969)

6. 6 Software Engineering Definition 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 approaches as in (1). - IEEE Standard 610.12-1990

7. SWEBOK Guide V3.0  Requirements  Design  Construction  Testing  Maintenance  Configuration management  Engineering management  Engineering process  Models and methods  Quality  Professional practice  Engineering economics  Computing foundations  Mathematical foundations  Engineering foundations 15 Knowledge Areas See: http://www.swebok.org 7

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

9. 9 Outline  Software Engineering  The Software Process  Software Engineering Practices  Software Myths  How it All Starts  Software Engineering  The Software Process  Software Engineering Practices  Software Myths  How it All Starts

10. 10 A Process Framework Process framework Umbrella activities framework activity #1 SE action #1.1 Software process task sets  work tasks work products QA points milestones SE action #1.2 task sets  work tasks work products QA points milestones framework activity #2 SE action #2.1 task sets  work tasks work products QA points milestones SE action #2.2 task sets  work tasks work products QA points milestones

11. 11 Umbrella Activities （管理活动） What should we do to develop a software?  Software project management  Formal technical reviews  Software quality assurance  Software configuration management  Work product preparation and production  Reusability management  Measurement  Risk management What should we do to develop a software?  Software project management  Formal technical reviews  Software quality assurance  Software configuration management  Work product preparation and production  Reusability management  Measurement  Risk management

12. 12 Framework Activities （技术活动）  Communication  Planning  Modeling  Analysis of requirements  Design  Construction  Code generation  Testing  Deployment  Communication  Planning  Modeling  Analysis of requirements  Design  Construction  Code generation  Testing  Deployment

13. 13 The Process Model: Adaptability  The framework activities will always be applied on every project... BUT  The tasks (and degree of rigor) for each activity will vary based on:  the type of project  characteristics of the project  common sense judgment; concurrence of the project team  The framework activities will always be applied on every project... BUT  The tasks (and degree of rigor) for each activity will vary based on:  the type of project  characteristics of the project  common sense judgment; concurrence of the project team

14. 14 Personal Software Process (PSP)  Recommends five framework activities:  Planning  High-level design  High-level design review  Development  Postmortem  Stresses the need for each software engineer to identify errors early and as important, to understand the types of errors  Recommends five framework activities:  Planning  High-level design  High-level design review  Development  Postmortem  Stresses the need for each software engineer to identify errors early and as important, to understand the types of errors

15. 15 Team Software Process (TSP)  Each project is “launched” using a “script” that defines the tasks to be accomplished  Teams (of 2 to 20 engineers) are self-directed:  Plan and track work, set goals, own processes and plans  Measurement is encouraged  Measures are analyzed with the intent of improving the team process (through coaching, motivation, …)  Each project is “launched” using a “script” that defines the tasks to be accomplished  Teams (of 2 to 20 engineers) are self-directed:  Plan and track work, set goals, own processes and plans  Measurement is encouraged  Measures are analyzed with the intent of improving the team process (through coaching, motivation, …)

16. 16 Process Patterns  Process patterns define a set of activities, actions, work tasks, work products and/or related behaviors  A template is used to define a pattern  Typical examples:  Customer communication (a process activity)  Analysis (an action)  Requirements gathering (a process task)  Reviewing a work product (a process task)  Design model (a work product)  Process patterns define a set of activities, actions, work tasks, work products and/or related behaviors  A template is used to define a pattern  Typical examples:  Customer communication (a process activity)  Analysis (an action)  Requirements gathering (a process task)  Reviewing a work product (a process task)  Design model (a work product)

17. 17 Process Assessment  The process should be assessed to ensure that it meets a set of basic process criteria that have been shown to be essential for a successful software engineering.  Many different assessment options are available:  SCAMPI  CBA IPI  SPICE  ISO 9001:2000  The process should be assessed to ensure that it meets a set of basic process criteria that have been shown to be essential for a successful software engineering.  Many different assessment options are available:  SCAMPI  CBA IPI  SPICE  ISO 9001:2000

18. 18 Assessment and Improvement

19. 19 The Primary Goal of Any Software Process Remember: High quality  project timeliness Why? Less rework!

20. 20 Outline  Software Engineering  The Software Process  Software Engineering Practices  Software Myths  How it All Starts  Software Engineering  The Software Process  Software Engineering Practices  Software Myths  How it All Starts

21. 21 The Essence of Practice  George Polya suggests: 1.Understand the problem (communication and analysis). 2.Plan a solution (modeling and software design). 3.Carry out the plan (code generation). 4.Examine the result for accuracy (testing and quality assurance).  George Polya suggests: 1.Understand the problem (communication and analysis). 2.Plan a solution (modeling and software design). 3.Carry out the plan (code generation). 4.Examine the result for accuracy (testing and quality assurance).

22. 22 Understand the Problem  Who has a stake in the solution to the problem? That is, who are the stakeholders?  What are the unknowns? What data, functions, and features are required to properly solve the problem?  Can the problem be compartmentalized? Is it possible to represent smaller problems that may be easier to understand?  Can the problem be represented graphically? Can an analysis model be created?  Who has a stake in the solution to the problem? That is, who are the stakeholders?  What are the unknowns? What data, functions, and features are required to properly solve the problem?  Can the problem be compartmentalized? Is it possible to represent smaller problems that may be easier to understand?  Can the problem be represented graphically? Can an analysis model be created?

23. 23 Plan the Solution  Have you seen similar problems before? Are there patterns that are recognizable in a potential solution? Is there existing software that implements the data, functions, and features that are required?  Has a similar problem been solved? If so, are elements of the solution reusable?  Can subproblems be defined? If so, are solutions readily apparent for the subproblems?  Can you represent a solution in a manner that leads to effective implementation? Can a design model be created?  Have you seen similar problems before? Are there patterns that are recognizable in a potential solution? Is there existing software that implements the data, functions, and features that are required?  Has a similar problem been solved? If so, are elements of the solution reusable?  Can subproblems be defined? If so, are solutions readily apparent for the subproblems?  Can you represent a solution in a manner that leads to effective implementation? Can a design model be created?

24. 24 Carry Out the Plan  Does the solution conform to the plan? Is source code traceable to the design model?  Is each component part of the solution provably correct? Has the design and code been reviewed, or better, have correctness proofs been applied to algorithm?  Does the solution conform to the plan? Is source code traceable to the design model?  Is each component part of the solution provably correct? Has the design and code been reviewed, or better, have correctness proofs been applied to algorithm?

25. 25 Examine the Result  Is it possible to test each component part of the solution? Has a reasonable testing strategy been implemented?  Does the solution produce results that conform to the data, functions, and features that are required? Has the software been validated against all stakeholder requirements?  Is it possible to test each component part of the solution? Has a reasonable testing strategy been implemented?  Does the solution produce results that conform to the data, functions, and features that are required? Has the software been validated against all stakeholder requirements?

26. 26 Hooker’s General Principles 1: The Reason It All Exists 2: KISS (Keep It Simple, Stupid!) 3: Maintain the Vision 4: What You Produce, Others Will Consume 5: Be Open to the Future 6: Plan Ahead for Reuse 7: Think! 1: The Reason It All Exists 2: KISS (Keep It Simple, Stupid!) 3: Maintain the Vision 4: What You Produce, Others Will Consume 5: Be Open to the Future 6: Plan Ahead for Reuse 7: Think!

27. 27 Outline  Software Engineering  The Software Process  Software Engineering Practices  Software Myths  How it All Starts  Software Engineering  The Software Process  Software Engineering Practices  Software Myths  How it All Starts

28. 28 Software Myths  Affect managers, customers (and other non-technical stakeholders) and practitioners  Are believable because they often have elements of truth, but …  Invariably lead to bad decisions, therefore …  Insist on reality as you navigate your way through software engineering  Affect managers, customers (and other non-technical stakeholders) and practitioners  Are believable because they often have elements of truth, but …  Invariably lead to bad decisions, therefore …  Insist on reality as you navigate your way through software engineering

29. 29 Software Myths  If we get behind schedule, we can add more programmers and catch up.  A general statement about objectives is sufficient to begin building programs.  Change in project requirements can be easily accommodated because software is flexible.  If we get behind schedule, we can add more programmers and catch up.  A general statement about objectives is sufficient to begin building programs.  Change in project requirements can be easily accommodated because software is flexible.

30. 30 Software Myths  Once we write a working program, we’re done.  Until I get the program running, I have no way of assessing its quality.  The only deliverable work product for a successful project is the working program.  Software engineering will make us create too much documentation and will slow us down.  Once we write a working program, we’re done.  Until I get the program running, I have no way of assessing its quality.  The only deliverable work product for a successful project is the working program.  Software engineering will make us create too much documentation and will slow us down.

31. 31 Management Myths  “We already have a book of standards and procedures for building software. It does provide my people with everything they need to know …”  “If my project is behind the schedule, I always can add more programmers to it and catch up …” (a.k.a. “The Mongolian Horde concept”)  “If I decide to outsource the software project to a third party, I can just relax: Let them build it, and I will just pocket my profits …”  “We already have a book of standards and procedures for building software. It does provide my people with everything they need to know …”  “If my project is behind the schedule, I always can add more programmers to it and catch up …” (a.k.a. “The Mongolian Horde concept”)  “If I decide to outsource the software project to a third party, I can just relax: Let them build it, and I will just pocket my profits …”

32. 32 Customer Myths  “A general statement of objectives is sufficient to begin writing programs - we can fill in the details later …”  “Project requirements continually change but this change can easily be accommodated because software is flexible …”  “A general statement of objectives is sufficient to begin writing programs - we can fill in the details later …”  “Project requirements continually change but this change can easily be accommodated because software is flexible …”

33. 33 Practitioner’s Myths  “Let’s start coding ASAP, because once we write the program and get it to work, our job is done …”  “Until I get the program running, I have no way of assessing its quality …”  “The only deliverable work product for a successful project is the working program …”  “Software engineering is baloney. It makes us create tons of paperwork, only to slow us down …”  “Let’s start coding ASAP, because once we write the program and get it to work, our job is done …”  “Until I get the program running, I have no way of assessing its quality …”  “The only deliverable work product for a successful project is the working program …”  “Software engineering is baloney. It makes us create tons of paperwork, only to slow us down …”

34. Q&A  Please think of one or two software myths of your own. 34

35. 35 Outline  Software Engineering  The Software Process  Software Engineering Practices  Software Myths  How it All Starts  Software Engineering  The Software Process  Software Engineering Practices  Software Myths  How it All Starts

36. 36 How It all Starts  SafeHome:  Every software project is precipitated by some business need—  the need to correct a defect in an existing application;  the need to the need to adapt a ‘legacy system’ to a changing business environment;  the need to extend the functions and features of an existing application, or  the need to create a new product, service, or system.  SafeHome:  Every software project is precipitated by some business need—  the need to correct a defect in an existing application;  the need to the need to adapt a ‘legacy system’ to a changing business environment;  the need to extend the functions and features of an existing application, or  the need to create a new product, service, or system.

37. Q&A  Based on the sidebar ( Page 24 ), Please develop a list of 10 questions about SafeHome. 37

38. 38 Summary  The Evolving Role of Software  Software  The Changing Nature of Software  Legacy Software  Software Myths  The Evolving Role of Software  Software  The Changing Nature of Software  Legacy Software  Software Myths