1. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 1 Supplementary Slides for Software Engineering: A Practitioner's Approach, 6/e Part 2 Supplementary Slides for Software Engineering: A Practitioner's Approach, 6/e Part 2 copyright © 1996, 2001, 2005 R.S. Pressman & Associates, Inc. For University Use Only May be reproduced ONLY for student use at the university level when used in conjunction with Software Engineering: A Practitioner's Approach. Any other reproduction or use is expressly prohibited. This presentation, slides, or hardcopy may NOT be used for short courses, industry seminars, or consulting purposes.

2. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 2 Software Engineering: A Practitioner’s Approach, 6/e Chapter 5 Practice: A Generic View Software Engineering: A Practitioner’s Approach, 6/e Chapter 5 Practice: A Generic View copyright © 1996, 2001, 2005 R.S. Pressman & Associates, Inc. For University Use Only May be reproduced ONLY for student use at the university level when used in conjunction with Software Engineering: A Practitioner's Approach. Any other reproduction or use is expressly prohibited.

3. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 3 What is “Practice”? Practice is a broad array of concepts, principles, methods, and tools that you must consider as software is planned and developed. Practice is a broad array of concepts, principles, methods, and tools that you must consider as software is planned and developed. It represents the details—the technical considerations and how to’s—that are below the surface of the software process—the things that you’ll need to actually build high-quality computer software. It represents the details—the technical considerations and how to’s—that are below the surface of the software process—the things that you’ll need to actually build high-quality computer software.

4. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 4 The Essence of Practice George Polya, in a book written in 1945 (!) (about problem solving), describes the essence of software engineering practice … George Polya, in a book written in 1945 (!) (about problem solving), describes the essence of software engineering practice … Understand the problem (communication and analysis). Understand the problem (communication and analysis). Plan a solution (modeling and software design). Plan a solution (modeling and software design). Carry out the plan (code generation). Carry out the plan (code generation). Examine the result for accuracy (testing and quality assurance). Examine the result for accuracy (testing and quality assurance). At its core, good practice is common-sense problem solving At its core, good practice is common-sense problem solving

5. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 5 Core Software Engineering Principles The reason it all exists: Provide value to the customer and the user The reason it all exists: Provide value to the customer and the user KISS—keep it simple, stupid! KISS—keep it simple, stupid! Does not mean quick and dirty Does not mean quick and dirty Maintain the product and project “vision” Maintain the product and project “vision” What you produce, others will consume What you produce, others will consume Be open to the future Be open to the future Plan ahead for reuse Plan ahead for reuse Think! (before action) Think! (before action)

6. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 6 Software Engineering Practices Consider the generic process framework Consider the generic process framework Communication Communication Planning Planning Modeling Modeling Construction Construction Deployment Deployment Here, we’ll identify Here, we’ll identify Underlying principles Underlying principles How to initiate the practice How to initiate the practice An abbreviated task set An abbreviated task set

7. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 7 Communication Practices Principles Principles  Listen (instead of talking too much)  Prepare before you communicate Understand the business domain Understand the business domain Prepare an agenda Prepare an agenda  Facilitate the communication, there should be a leader Ensure moving in a productive direction Ensure moving in a productive direction Mediate any conflict Mediate any conflict Ensure other principles are followed Ensure other principles are followed  Face-to-face is best  Take notes and document decisions  Collaborate with the customer  Stay focused, modularize your discussion (conclude each issue)  Draw pictures when things are unclear  Move on … Once you agree to something Once you agree to something If you can’t agree If you can’t agree Something is unclear and cannot be resolved at the moment Something is unclear and cannot be resolved at the moment  Negotiation works best when both parties win (not a contest or game). Compromise when necessary Compromise when necessary

8. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 8 Communication Practices Initiation Initiation The parties should be physically close to one another The parties should be physically close to one another Make sure communication is interactive Make sure communication is interactive Create solid team “ecosystem” Create solid team “ecosystem” Use the right team structure Use the right team structure An abbreviated task set An abbreviated task set Identify who it is you need to speak with Identify who it is you need to speak with Define the best mechanism for communication Define the best mechanism for communication Establish overall goals and objectives and define the scope Establish overall goals and objectives and define the scope Get more detailed Get more detailed Have stakeholders define scenarios for usage Have stakeholders define scenarios for usage Extract major functions/features Extract major functions/features Review the results with all stakeholders Review the results with all stakeholders

9. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 9 Customer and end-users Main stakeholders Customer: Customer: Originally request the software Originally request the software Defines overall business objectives Defines overall business objectives Provides basic product requirements Provides basic product requirements Coordinate funding Coordinate funding End-user: End-user: Actually use the software to achieve some business purpose Actually use the software to achieve some business purpose Defines operational details Defines operational details

10. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 10 Generic task set for communication  Identify primary customer and other stakeholders  Meet with primary customer to address “context free questions” that define Business need and business values Business need and business values End-users characteristics / needs End-users characteristics / needs Required user-visible outputs Required user-visible outputs Business constraints Business constraints  Develop a one-page written statement of project scope that is subject to revision  Review statement of scope with stakeholders  Collaborate

11. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 11  Collaborate with customer/end-users to define Customer visible usage scenarios using standard format Customer visible usage scenarios using standard format Resulting outputs and inputs Resulting outputs and inputs Important software features, functions, and behavior Important software features, functions, and behavior Customer-defined business risks Customer-defined business risks  Develop a brief written description (a set of lists) of scenarios, output/inputs, features/functions and risks  Iterate the lists with customer to refine them.  Prioritize the items (customer-defined priorities)  Review and amend  Prepare for planning

12. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 12 Planning Practices Principles Principles  Understand the project scope Scope clears your destination Scope clears your destination  Involve the customer (and other stakeholders) Customer defines priorities and constraints Customer defines priorities and constraints Negotiate order of delivery, timelines, … Negotiate order of delivery, timelines, …  Recognize that planning is iterative (revised based on feedback)  Estimate based on what you know Provide an indication of effort, cost, and task duration (maybe unreliable) Provide an indication of effort, cost, and task duration (maybe unreliable)  Consider risk  Be realistic Noise, change, mistakes, omissions, ambiguity Noise, change, mistakes, omissions, ambiguity  Adjust granularity as you plan (level of details)  Define how quality will be achieved (formal technical reviews, pair programming)  Define how you’ll accommodate changes  Track what you’ve planned and make adjustment

13. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 13 Planning Practices Initiation Initiation Ask Boehm’s questions Ask Boehm’s questions Why is the system being developed? Why is the system being developed? Justify the expenditure of people, time, and money Justify the expenditure of people, time, and money What will be done? What will be done? Identify functionality Identify functionality When will it be accomplished? When will it be accomplished? Workflow, timeline, milestones Workflow, timeline, milestones Who is responsible for a function? Who is responsible for a function? Where are they located (organizationally)? Where are they located (organizationally)? How will the job be done technically and managerially? How will the job be done technically and managerially? How much of each resource is needed? (estimation) How much of each resource is needed? (estimation)

14. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 14 Generic task set for Planning Re-assess project scope Re-assess project scope Assess risks Assess risks Extract functions/features Extract functions/features Consider infrastructure functions/features Consider infrastructure functions/features Create a coarse granularity plan Create a coarse granularity plan Number of software increments Number of software increments Overall schedule Overall schedule Delivery dates for increments Delivery dates for increments Create fine granularity plan for first increment Create fine granularity plan for first increment Track progress Track progress

15. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 15 Create fine granularity plan for first increment Create fine granularity plan for first increment Define work tasks for each function/feature Define work tasks for each function/feature Estimate effort for each work task Estimate effort for each work task Define work products Define work products Identify quality assurance methods to be used Identify quality assurance methods to be used Describe methods for managing change Describe methods for managing change

16. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 16 Modeling Practices We create models to gain a better understanding of the actual entity to be built We create models to gain a better understanding of the actual entity to be built Analysis models represent the customer requirements by depicting the software in three different domains: the information domain, the functional domain, and the behavioral domain. Analysis models represent the customer requirements by depicting the software in three different domains: the information domain, the functional domain, and the behavioral domain. Design models represent characteristics of the software that help practitioners to construct it effectively: the architecture, the user interface, and component-level detail. Design models represent characteristics of the software that help practitioners to construct it effectively: the architecture, the user interface, and component-level detail.

17. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 17 Analysis Modeling Practices Analysis modeling principles Analysis modeling principles 1. Represent the information domain 2. Represent software functions 3. Represent software behavior 4. Partition these representations 5. Move from essence toward implementation Elements of the analysis model (Chapter 8) Elements of the analysis model (Chapter 8) Data model Data model Flow model Flow model Class model Class model Behavior model Behavior model

18. Analysis Modeling Principles 1. Represent the information domain Input data: from end-users, other systems, or external devices Input data: from end-users, other systems, or external devices Output data: via the user interface, network interface, reports, graphics, … Output data: via the user interface, network interface, reports, graphics, … The data stores The data stores 2. Represent software functions Different levels of abstraction Different levels of abstraction 3. Represent software behavior As a consequence of external events As a consequence of external events 4. Partition these representations Partitioning: divide and conquer Partitioning: divide and conquer Layered or hierarchical Layered or hierarchical 5. Move from essence toward implementation 18

19. Generic tasks of analysis modeling 1. Review business requirements, end users’ characteristics/needs, user visible outputs, business constraints, and other technical requirements (determined during communication and planning) 2. Expand and refine user scenarios (actors, interactions, functions) 3. Model the information domain (objects, attributes, relationships) 4. Model the functional domain 5. Model the behavioral domain 6. Model the user interface 7. Review to check for completeness, consistency and omission 19

20. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 20 Design Modeling Practices Principles Principles 1. Design must be traceable to the analysis model 2. Always consider architecture 3. Focus on the design of data 4. Interfaces (both user and internal) must be designed 5. Components should exhibit functional independence 6. Components should be loosely coupled 7. Design representation should be easily understood 8. The design model should be developed iteratively Elements of the design model Elements of the design model Data design Data design Architectural design Architectural design Component design Component design Interface design Interface design

21. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 21 Construction Practices Preparation principles: Before you write one line of code, be sure you: Preparation principles: Before you write one line of code, be sure you: Understand of the problem you’re trying to solve (see communication and modeling) Understand of the problem you’re trying to solve (see communication and modeling) Understand basic design principles and concepts. Understand basic design principles and concepts. Pick a programming language that meets the needs of the software to be built and the environment in which it will operate. Pick a programming language that meets the needs of the software to be built and the environment in which it will operate. Select a programming environment that provides tools that will make your work easier. Select a programming environment that provides tools that will make your work easier. Create a set of unit tests that will be applied once the component you code is completed Create a set of unit tests that will be applied once the component you code is completed.

22. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 22 Construction Practices Coding principles: As you begin writing code, be sure you: Coding principles: As you begin writing code, be sure you: Constrain your algorithms by following structured programming [BOH00] practice. Constrain your algorithms by following structured programming [BOH00] practice. Select data structures that will meet the needs of the design. Select data structures that will meet the needs of the design. Understand the software architecture and create interfaces that are consistent with it. Understand the software architecture and create interfaces that are consistent with it. Keep conditional logic as simple as possible. Keep conditional logic as simple as possible. Create nested loops in a way that makes them easily testable. Create nested loops in a way that makes them easily testable. Select meaningful variable names and follow other local coding standards. Select meaningful variable names and follow other local coding standards. Write code that is self-documenting. Write code that is self-documenting. Create a visual layout (e.g., indentation and blank lines) that aids understanding. Create a visual layout (e.g., indentation and blank lines) that aids understanding.

23. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 23 Construction Practices Validation Principles: After you’ve completed your first coding pass, be sure you: Validation Principles: After you’ve completed your first coding pass, be sure you: Conduct a code walkthrough when appropriate. Conduct a code walkthrough when appropriate. Perform unit tests and correct errors you’ve uncovered. Perform unit tests and correct errors you’ve uncovered. Refactor the code. Refactor the code.

24. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 24 Construction Practices Testing Principles Testing Principles All tests should be traceable to requirements All tests should be traceable to requirements Tests should be planned Tests should be planned The Pareto Principle applies to testing The Pareto Principle applies to testing Testing begins “in the small” and moves toward “in the large” Testing begins “in the small” and moves toward “in the large” Exhaustive testing is not possible Exhaustive testing is not possible

25. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 25 Deployment Practices Principles Principles Manage customer expectations for each increment Manage customer expectations for each increment A complete delivery package should be assembled and tested A complete delivery package should be assembled and tested A support regime should be established A support regime should be established Instructional materials must be provided to end-users Instructional materials must be provided to end-users Buggy software should be fixed first, delivered later Buggy software should be fixed first, delivered later