Download
1 / 30
300 likes | 446 Vues
Achieving high-quality software requires a comprehensive approach that balances complexity, cost, customer involvement, and features. Effective practices include early customer feedback, dynamic requirements evolution, and exploring design alternatives. Utilize appropriate process models tailored to project characteristics while minimizing intellectual distance and leveraging tools efficiently. Emphasize quality management, prioritize people over technology, and plan for change. Implement effective documentation and encapsulation techniques while avoiding traps like testing your own code. Cultivating a culture of excellence leads to superior performance and outcomes.
E N D
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
Give Products to CustomersEarly • Key to modern process framework • Involve customers in several ways throughout project life cycle
Determine the Problem BeforeWriting Requirements • Actually, requirements and architecture should evolve together • Problems become more apparent as one tries to develop a solution
Evaluate Design Alternatives • Again, analysis of design alternatives goes along with requirements specification • It’s easier to grasp what the problems are when
Use an Appropriate ProcessModel • Royce speaks of a “Process Framework” • The “Process Framework” should be configured to specific characteristics of the project at hand
Use Different Languages forDifferent Phases • Don’t use the same notation throughout the lifecycle • Different phases require different approaches
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
Put Techniques Before Tools • True, but don’t underestimate good tools • Automation through good tools facilitates standardization and good technique
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
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
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
People Are The Key to Success • Just as good management trumps good technology, quality people are more important than good tools.
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
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
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
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
Plan to Throw One Away • Never plan to throw one away • With modern development techniques there is seldom any need to start from scratch
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
Design Without Documentation is NOT Design • Software artifacts should be mostly self-documenting • Modern design tools make documentation evolve along with design
Use Tools, But Be Realistic • A good process is well established, automated, and instrumented • Don’t underestimate the need for a good development environment
Avoid Tricks • Avoid novelty solutions, but don’t avoid innovative solutions
Encapsulate • Information hiding is the underlying concept behind OO • This is as fundamental a technique to SW engineers as math is to physics
Use Coupling and Cohesion • Difficult to measure • Better to focus on amount of SW scrap and rework
Use the McCabe Complexity Measure • Complex stuff is obvious • Interesting from an academic perspective, but not terribly useful in management or decision making
Don’t Test Your Own Software • Developers need to take ownership of product quality • But independent test teams offer objectivity • Everyone should test it!
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
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’
People and Time are NOT Interchangeable • Measuring a project by person-months only makes little sense
Expect Excellence • People will perform better if you have high expectations • The concept of motivation in the workplace applies to all disciplines
