Slides chapter 5


Published on

Published in: Technology
1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Slides chapter 5

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