When faced with what they believe is a problem, most engineers rush to offer a solution. Determine the problem before writing the requirements.
Depending on the domain, these mechanisms may include demonstrable prototypes, demonstration-based milestones, and alpha/beta releases.Ĥ. No matter how hard you try to learn users' needs during the requirements phase, the most effective way to determine real needs is to give users a product and let them play with it.Ī This is a key tenet of a modern process framework, and there must be several mechanisms to involve the customer throughout the life cycle. Techniques that have been demonstrated to increase quality include involving the customer, prototyping, simplifying design, conducting inspections, and hiring the best people.Ī This principle is mostly redundant with the others.ģ. Until this understanding is achieved, it is not possible to specify or manage the achievement of quality.Ģ.
Consequently, a modern process framework strives to understand the trade-offs among features, quality, cost, and schedule as early in the life cycle as possible. Quality must be quantified and mechanisms put into place to motivate its achievement.Ī Defining quality commensurate with the project at hand is important but is not easily done at the outset of a project.
I make several assertions here that are left unsubstantiated until later chapters.ġ. For each principle, I comment on whether the perspective provided later in this book would endorse or change it. Davis's top 30 principles are quoted next, in italics. While I endorse much of this wisdom, I believe some of it is obsolete. Despite its title, the article describes the top 30 principles, and it is as good a summary as any of the conventional wisdom within the software industry. The benchmark I have chosen is a brief article titled "Fifteen Principles of Software Engineering", The article was subsequently expanded into a book that enumerates 201 principles. This section describes one view of today's software engineering principles as a benchmark for introducing the primary themes discussed throughout the remainder of the book.
There are many descriptions of engineering software "the old way." After years of software development experience, the software industry has learned many lessons and formulated many principles.
0 kommentar(er)
