1 / 30

Make Quality #1

Make Quality #1. It’s difficult to define quality at the onset of a project Modern design takes quality into account along with complexity, cost, and features. High-quality Software is Possible. Involving Customer Prototyping Simplifying Inspecting Hiring good people.

sydney
Download Presentation

Make Quality #1

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Make Quality #1 • It’s difficult to define quality at the onset of a project • Modern design takes quality into account along with complexity, cost, and features

  2. High-quality Software is Possible • Involving Customer • Prototyping • Simplifying • Inspecting • Hiring good people

  3. Give Products to CustomersEarly • Key to modern process framework • Involve customers in several ways throughout project life cycle

  4. Determine the Problem BeforeWriting Requirements • Actually, requirements and architecture should evolve together • Problems become more apparent as one tries to develop a solution

  5. Evaluate Design Alternatives • Again, analysis of design alternatives goes along with requirements specification • It’s easier to grasp what the problems are when

  6. Use an Appropriate ProcessModel • Royce speaks of a “Process Framework” • The “Process Framework” should be configured to specific characteristics of the project at hand

  7. Use Different Languages forDifferent Phases • Don’t use the same notation throughout the lifecycle • Different phases require different approaches

  8. Minimize Intellectual Distance • Software structure should resemble real-world structure • This concept gave rise to OO techniques and visual modeling • This also aids in involving the customer

  9. Put Techniques Before Tools • True, but don’t underestimate good tools • Automation through good tools facilitates standardization and good technique

  10. Get It Right Before You MakeIt Faster • It’s easier to make it work, and then make it fast. • A working program is a prerequisite to understanding performance trade-offs

  11. Inspect Code • Inspecting code is useful when focused on known issues • But today’s tools make it easy to test functionality throughout the life cycle

  12. Good Management is More Important Than Good Technology • Good technology will not compensate for poor management • Good management can attract, configure and retain a quality team

  13. People Are The Key to Success • Just as good management trumps good technology, quality people are more important than good tools.

  14. Follow With Care • These days technology fads are hard to distinguish from technology improvements • The benefits of which tools and techniques to use must be weighed carefully • Applies to determining an appropriate Process Framework

  15. Take Responsibility • It takes more than just good methods and tools to succeed • Good methods can make bad designs, and poor methods can make good designs • People, management and culture are just as important

  16. Understand the Customer’s Priorities • Take customer priorities into account with other stakeholder priorities • But don’t forget that you are obligated to do what’s right for the customer

  17. The More They See, The More They Need • True, but this should not discourage frequent customer involvement • The savvy SW Project Manager will be prepared to argue the best way to balance affordability, features, and risk

  18. Plan to Throw One Away • Never plan to throw one away • With modern development techniques there is seldom any need to start from scratch

  19. Design for Change • Attempt to predict the kinds of changes likely to occur in a system’s life cycle • Good for risk management • Key to successful software projects

  20. Design Without Documentation is NOT Design • Software artifacts should be mostly self-documenting • Modern design tools make documentation evolve along with design

  21. Use Tools, But Be Realistic • A good process is well established, automated, and instrumented • Don’t underestimate the need for a good development environment

  22. Avoid Tricks • Avoid novelty solutions, but don’t avoid innovative solutions

  23. Encapsulate • Information hiding is the underlying concept behind OO • This is as fundamental a technique to SW engineers as math is to physics

  24. Use Coupling and Cohesion • Difficult to measure • Better to focus on amount of SW scrap and rework

  25. Use the McCabe Complexity Measure • Complex stuff is obvious • Interesting from an academic perspective, but not terribly useful in management or decision making

  26. Don’t Test Your Own Software • Developers need to take ownership of product quality • But independent test teams offer objectivity • Everyone should test it!

  27. Analyze Causes for Errors • This leads to over-analysis and over-design too early in a project • Committing to prototyping and construction phases makes errors more obvious • Save analysis for production stage

  28. Realize that Software’s Entropy Increases • All software systems undergo change • Entropy - as a software system changes it becomes more difficult to manage • Remember – ‘Design for Change’

  29. People and Time are NOT Interchangeable • Measuring a project by person-months only makes little sense

  30. Expect Excellence • People will perform better if you have high expectations • The concept of motivation in the workplace applies to all disciplines

More Related