Chapter 5 Practice: A Generic View Software Engineering: A Practitioner’s Approach, 6th edition by Roger S. Pressman
What is “Practice”? Practice consists of the concepts principles methods tools that must be considered as software is planned and developed. It represents the details —the how-to’s—of the software process.
The Essence of Practice George Polya, in a book written in 1945 (!), describes the essence of software engineering practice … Understand the problem  (communication and analysis). Plan a solution  (modeling and software design). Carry out the plan  (code generation). Examine the result for accuracy  (testing and quality assurance). At its core, good practice is  common-sense problem solving
Core Software Engineering Principles Provide Value to Your Users KIS (Keep It Simple) Maintain the Vision What You Produce, Others Will Consume Be Open to the Future Plan Ahead for Reuse Think before You Do
Software Engineering Practices Consider the generic process framework Communication Planning Modeling Analysis Modeling Design Modeling Construction Coding Testing Deployment
Communication Practices Principles Listen effectively Prepare before you communicate Someone should facilitate the activity Face-to-face communication is best Take notes and document decisions Strive for collaboration Stay focused, modularize your discussion If something is unclear, draw a picture Know when to move on Negotiation works best when both parties win.
Planning Practices Principles Understand the project scope Involve the customer in planning Recognize that planning is iterative Estimate based on what you know Consider risk as you define the plan Be realistic Adjust granularity as you define the plan Define how you intend to ensure quality Describe how you intend to accommodate changes Track the plan frequently and make necessary adjustments
Planning Practices Bohem’s W5HH Organizing Principle. Answers to the following questions lead to the project plan: Why is the system begin developed? What will be done? When will it be accomplished? Who is responsible? Where are they located (organizationally)? How will the job be done technically and managerially? How much of each resource is needed?
Modeling Practices Analysis modeling principles Represent the information domain Represent software functions Represent software behavior Partition these representations Move from essence toward implementation
Modeling Practices Design Modeling Principles Design must be traceable to the analysis model Always consider architecture Focus on the design of data Interfaces (both user and internal) must be designed User interface should consider the user first Components should exhibit functional independence Components should be loosely coupled Design representations should be easily understood The design model should be developed iteratively
Modeling Practices Agile Modeling Principles [Ambler 2002] The primary goal is to create software, not build models Don’t create more models than you need Produce the simplest model that will describe the problem Build models that are easy to change Be able to state an explicit purpose for each model Adapt the models you develop to the system at hand Build useful models, not  perfect  ones Focus on the what the model communicates, not its syntax If you are uncomfortable with a model, something’s probably wrong Get feedback as soon as you can
Construction Practices Coding Principles Preparation.  Before you write one line of code, be sure you: Understand of the problem you’re trying to solve Understand basic design principles and concepts. Pick an appropriate programming language. Select an appropriate programming environment and tools. Create unit tests for each component you plan to create.
Construction Practices Coding Principles Coding.  As you begin writing code, be sure you: Follow structured programming [BOH00] practice. Select data structures that will meet the needs of the design. Create interfaces consistent with the software architecture. Keep conditional logic as simple as possible. Create nested loops in a way that makes them easily testable. Select meaningful variable names and follow other local coding standards. Write code that is self-documenting. Create a visual layout that aids understanding.
Construction Practices Coding Principles Validation.  After you’ve completed the first pass, be sure you: Conduct a code walkthrough when appropriate. Perform unit tests and correct errors you’ve uncovered. Refactor the code.
Construction Practices Testing Principles All tests should be traceable to requirements Tests should be planned The Pareto Principle applies to testing Testing begins “in the small” and moves toward “in the large” Exhaustive testing is not possible Note: A successful test is one that uncovers an as-yet-undiscovered error.
Deployment Practices Principles Manage customer expectations for each increment A complete delivery package should be assembled and tested A support regime should be established Instructional materials must be provided to end-users Buggy software should be fixed first, delivered later

Slides chapter 5

  • 1.
    Chapter 5 Practice:A Generic View Software Engineering: A Practitioner’s Approach, 6th edition by Roger S. Pressman
  • 2.
    What is “Practice”?Practice consists of the concepts principles methods tools that must be considered as software is planned and developed. It represents the details —the how-to’s—of the software process.
  • 3.
    The Essence ofPractice George Polya, in a book written in 1945 (!), describes the essence of software engineering practice … Understand the problem (communication and analysis). Plan a solution (modeling and software design). Carry out the plan (code generation). Examine the result for accuracy (testing and quality assurance). At its core, good practice is common-sense problem solving
  • 4.
    Core Software EngineeringPrinciples Provide Value to Your Users KIS (Keep It Simple) Maintain the Vision What You Produce, Others Will Consume Be Open to the Future Plan Ahead for Reuse Think before You Do
  • 5.
    Software Engineering PracticesConsider the generic process framework Communication Planning Modeling Analysis Modeling Design Modeling Construction Coding Testing Deployment
  • 6.
    Communication Practices PrinciplesListen effectively Prepare before you communicate Someone should facilitate the activity Face-to-face communication is best Take notes and document decisions Strive for collaboration Stay focused, modularize your discussion If something is unclear, draw a picture Know when to move on Negotiation works best when both parties win.
  • 7.
    Planning Practices PrinciplesUnderstand the project scope Involve the customer in planning Recognize that planning is iterative Estimate based on what you know Consider risk as you define the plan Be realistic Adjust granularity as you define the plan Define how you intend to ensure quality Describe how you intend to accommodate changes Track the plan frequently and make necessary adjustments
  • 8.
    Planning Practices Bohem’sW5HH Organizing Principle. Answers to the following questions lead to the project plan: Why is the system begin developed? What will be done? When will it be accomplished? Who is responsible? Where are they located (organizationally)? How will the job be done technically and managerially? How much of each resource is needed?
  • 9.
    Modeling Practices Analysismodeling principles Represent the information domain Represent software functions Represent software behavior Partition these representations Move from essence toward implementation
  • 10.
    Modeling Practices DesignModeling Principles Design must be traceable to the analysis model Always consider architecture Focus on the design of data Interfaces (both user and internal) must be designed User interface should consider the user first Components should exhibit functional independence Components should be loosely coupled Design representations should be easily understood The design model should be developed iteratively
  • 11.
    Modeling Practices AgileModeling Principles [Ambler 2002] The primary goal is to create software, not build models Don’t create more models than you need Produce the simplest model that will describe the problem Build models that are easy to change Be able to state an explicit purpose for each model Adapt the models you develop to the system at hand Build useful models, not perfect ones Focus on the what the model communicates, not its syntax If you are uncomfortable with a model, something’s probably wrong Get feedback as soon as you can
  • 12.
    Construction Practices CodingPrinciples Preparation. Before you write one line of code, be sure you: Understand of the problem you’re trying to solve Understand basic design principles and concepts. Pick an appropriate programming language. Select an appropriate programming environment and tools. Create unit tests for each component you plan to create.
  • 13.
    Construction Practices CodingPrinciples Coding. As you begin writing code, be sure you: Follow structured programming [BOH00] practice. Select data structures that will meet the needs of the design. Create interfaces consistent with the software architecture. Keep conditional logic as simple as possible. Create nested loops in a way that makes them easily testable. Select meaningful variable names and follow other local coding standards. Write code that is self-documenting. Create a visual layout that aids understanding.
  • 14.
    Construction Practices CodingPrinciples Validation. After you’ve completed the first pass, be sure you: Conduct a code walkthrough when appropriate. Perform unit tests and correct errors you’ve uncovered. Refactor the code.
  • 15.
    Construction Practices TestingPrinciples All tests should be traceable to requirements Tests should be planned The Pareto Principle applies to testing Testing begins “in the small” and moves toward “in the large” Exhaustive testing is not possible Note: A successful test is one that uncovers an as-yet-undiscovered error.
  • 16.
    Deployment Practices PrinciplesManage customer expectations for each increment A complete delivery package should be assembled and tested A support regime should be established Instructional materials must be provided to end-users Buggy software should be fixed first, delivered later