Achieving Required Quality

Many of what are accepted today as software best practices are derived from the development process and technologies summarized in this chapter. These practices have impact in addition to improving cost efficiency. Many of them also permit improvements in quality for the same cost. Table 3-5 summarizes some dimensions of quality improvement.

Table 3-5. General quality improvements with a modern process

quality driver

conventional process

modern iterative processes

Requirements misunderstanding

Discovered late

Resolved early

Development risk

Unknown until late

Understood and resolved early

Commercial components

Mostly unavailable

Still a quality driver, but tradeoffs must be resolved early in the life cycle

Change management

Late in the life cycle, chaotic and malignant

Early in the life cycle, straightforward and benign

Design errors

Discovered late

Resolved early

Automation

Mostly error-prone manual procedures

Mostly automated, error-free evolution of artifacts

Resource adequacy

Unpredictable

Predictable

Schedules

Overconstrained

Tunable to quality, performance, and technology

Target performance

Paper-based analysis or separate simulation

Executing prototypes, early performance feedback, quantitative understanding

Software process rigor Document-based Managed, measured, and tool-

supported

Software process rigor Document-based Managed, measured, and tool-

supported

Key practices that improve overall software quality include the following:

Focusing on driving requirements and critical use cases early in the life cycle, focusing on requirements completeness and traceability late in the life cycle, and focusing throughout the life cycle on a balance between requirements evolution, design evolution, and plan evolution

Using metrics and indicators to measure the progress and quality of an architecture as it evolves from a high-level prototype into a fully compliant product

Providing integrated life-cycle environments that support early and continuous configuration control, change management, rigorous design methods, document automation, and regression test automation

Using visual modeling and higher level languages that support architectural control, abstraction, reliable programming, reuse, and self-documentation

• Early and continuous insight into performance issues through demonstra-tion-based evaluations

Improved insight into run-time performance issues is even more important as projects incorporate mixtures of commercial components and custom-developed components. Conventional development processes stressed early sizing and timing estimates of computer program resource utilization. However, the typical chronology of events in performance assessment was as follows:

• Project inception. The proposed design was asserted to be low risk with adequate performance margin.

• Initial design review. Optimistic assessments of adequate design margin were based mostly on paper analysis or rough simulation of the critical threads. In most cases, the actual application algorithms and database sizes were fairly well understood. However, the infrastructure—including the operating system overhead, the database management overhead, and the interprocess and network communications overhead—and all the secondary threads were typically misunderstood.

• Mid-life-cycle design review. The assessments started whittling away at the margin, as early benchmarks and initial tests began exposing the optimism inherent in earlier estimates.

• Integration and test. Serious performance problems were uncovered, necessitating fundamental changes in the architecture. The underlying infrastructure was usually the scapegoat, but the real culprit was immature use of the infrastructure, immature architectural solutions, or poorly understood early design trade-offs.

This sequence occurred because early performance insight was based solely on naive engineering judgment of innumerable criteria. In most large-scale distributed systems composed of many interacting components, a demonstration-based approach can provide significantly more-accurate assessments of performance issues. These early demonstrations may be on host or target platforms or partial network configurations. In any case, they can be planned and managed to provide a fruitful engineering exercise. Early performance issues are typical. They may even be healthy, because they tend to expose architectural flaws or weaknesses in commercial components early in the life cycle when the right trade-offs can be made.

Was this article helpful?

0 0
Project Management Made Easy

Project Management Made Easy

What you need to know about… Project Management Made Easy! Project management consists of more than just a large building project and can encompass small projects as well. No matter what the size of your project, you need to have some sort of project management. How you manage your project has everything to do with its outcome.

Get My Free Ebook


Responses

  • maureen
    What are t general quality improvement with modern process?
    4 years ago
  • asphodel sackville
    What is Achieving required quality?
    3 years ago
  • pasi
    How to achiving require quality?
    3 years ago
  • kelsi graham
    How to achieve required software quality?
    2 years ago

Post a comment