本人英文水平有限，如有錯誤還請海涵~

201 principles of software development

軟體開發的201個原則

by Alan M.Davis

chapter 1

This book contains a collection of principles of software engineering.These principles represent the state-of-the-art of what we believe is”right”when engineering software. Other engineering disciplines have principles based on the laws of physics, or biology, or chemistry, or mathematics. Because the product of software engineering is nonphysical, the laws of the physical do not easily form a solid foundation

The software industry has been flooded by hundreds of books that discuss techniques, languages, and tools. None has attempted to compile the list of underlying principles. As shown in Fig 1-1, principles are the rules to live by; they represent the collected wisdom of many dozens of people who have learned through experience. They tend to be stated as absolute truths(this is always true)or as inferences(when X occurs, Y will occur).

Techniques are step-by-step procedures that aid a software developer in performing a part of the software engineering process Techniques tend to enforce a subset of the underlying principles. Most techniques create either documents and /or programs. Many techniques also analyze existing documents and /or programs, or they transform existing documents and /or programs into the products.

Languages consist of a set of primitive elements(such as words or graphical symbols) and a set of rules by which one can construct more complex entities(such as sentences, diagrams, models) from those primitive elements as well as semantics that endow each combination of entitieswith meaning. Languages are used to express all products of software engineering, whether intermediate or final The documents and programs created or analyzed by techniques are typically represented in some language.

Tools are software programs that assist a soft ware engineer in performing some step of software engineering. They may:

• Serve in an advisory capacity to the engineer(like the knowledge-based Requirements Assistant)
• Analyze something for conformity to a technique(a data-flow diagram checker, for example)or a subset of principles
• Automate some aspect of software engineering(such as any compiler)
• Aid the engineer in doing some aspect of the job(as an editor)

The set of principles for a discipline evolve as the discipline grows.Existing principles are modified. New ones are added. Old ones are discarded. It is the practice and experience gained through that practice that cause us to evolve those principles. If we were to examine the set of software engineering principles from 1964 they would look downright silly today(for example, always use short variable names, or do whatever it takes to make your program smaller). Todays principles will look equally silly in thirty years.

And now,today’s principles of software engineering.

介紹本書。略~

chapter 2

principle 1 : quality is #1

A customer will not tolerate a product with poor quality, regardless of the definition of quality. Quality must be quantified and mechanisms put into place to motivate and reward its achievement. It may seem politically correct to deliver a product on time, even though its quality is poor, but it is politically correct in the short term only; it is political suicide in the middle and long term. There is no trade-off to be made. The first requirement must be quality. Edward Yourdon suggests that you Just say no”when you’re asked to speed up testing, ignore a few bugs, or code before agreeing on a design or a set of requirements

1、質量是no.1

無論質量如何定義，客戶都不會容忍質量較差的產品。 質量必須要量化，並且激勵和成就獎勵機制要落實。 即使按時交付質量差的產品在政治上看起來是正確的，但僅在短期內是正確的；在中長期來看，相當於政治自殺。 沒有權衡取捨（沒得商量）。 第一個要求就是必須做得有質量。

Edward Yourdon建議你在以下情況直接說no：1.被要求加快測試速度；2.忽略一些bug；3.在設計和需求確認之前開發。

principle 2 : quality is the eyes of the beholder

There is no one definition of software quality. To developers ,it might be an elegant design or elegant code. To users ,who work in stress environments,it might be response time or high capacity. For cost-sensitive projects, it might be low development cost. For some customers, it might be satisfying all their perceived and not-yet-perceived needs. The dilemma is that these may not be all compatible. Optimizing one persons quality might be detrimental to anothers.(This is Weinberg’s”Political Dilemma”principle. )A project must decide on its priorities and articulate them to all parties.

2、質量是旁觀者的眼睛

沒有人定義軟體質量。對於開發者來說，它們可能是優雅的設計或優雅的程式碼。對於工作在壓力環境的使用者們，也許意味著響應時間或者高吞吐。對於成本敏感的專案，也許是低開發成本。對於一些消費者，也許是滿足他們自己發現或者沒發現的需求。困難的是，他們可能沒辦法全部實現。提升一類人的體驗，可能會犧牲其他人的。一個專案必須決定它的優先事項，並且告知所有人。

principle 3 : productivity and quality are inseparable

There is a clear relationship between productivity(measured by numbers of widgits–whether they be lines of code or function points–per person month)and quality. The higher the demand for quality, the lower your productivity becomes. The lower the demand for quality, the higher your productivity becomes. The more you emphasize increased productivity, the lower your resulting quality. Bell Labs has found that, to achieve one to two bugs per thousand lines of code, productivities of 150 to 300 lines of code per person-month are common [see Fleckenstein, W,”Challenges in Software Development, ” IEEE Computer, 16, 3(March 1983), Pp 60-64].As attempts are made to drive productivity up ,the density of bugs increases.

3、生產效率和質量是形影不離的

生產效率（呵呵不太好翻呢）和質量之間有一個清晰的關係。質量要求更高，生產效率則越低。越注重增加生產效率，結果的質量就越低。Bell Labs發現，在每人月150~300行的效率下，每1000行程式碼出現1~2個bug是普遍的。當試圖提高生產效率時，bug出現的密度將增加。

principle 4 : high-quality software is possible

Although our industry is saturated with examples of software systems that perform poorly, that are full of bugs, or that otherwise fail to satisfy users’ needs, there are counter examples.large-scale software systems can be built with very high quality, but for a steep price tag: on the order of $1000 per line of code. One such example is IBMS on-board flight software for NASAS space shuttle. Totaling approximately three million lines of code,the rigorous software development process resulted in less than one error found per ten thousand lines of code after product release.

As a developer, be aware of the techniques that have been demon-strated to increase quality considerably. These include involving the customer(Principle 8), prototyping(to verify requirements prior to full-scale development; Principles 11 through 13), keeping the design simple (Principle 67), inspections(Principle 98), and hiring the best people ( Principles 130 and 131). As a customer, demand excellence but be aware of the high costs involved

4、高質量的軟體是可能的

雖然我們的行業充滿了軟體系統的例子，這些軟體系統效能不好，充滿缺陷，或者不能滿足使用者的需求，但有一些反例。大規模的軟體系統可以高質量的建造，但是程式碼也被標以高價：$1000/行。其中的一個例子是IBM為NASA的太空梭做的機載飛行軟體。大約3百萬行程式碼，嚴格的軟體開發流程的結果是，在釋出後萬行程式碼的錯誤數小於1。
作為一個開發者，要知道已經被證明可以大幅提高質量的技術。這些包括涉及客戶（原則8），原型（在全面驗證需求前進行全面開發；原則11到13），保持設計簡單（原則67），檢查（原則98），聘用最優秀的人（原則130和131）。作為一個消費者，要求卓越，但要意識到所涉及的高成本。

principle 5 : don’t try to retrofit quality

Quality cannot be retrofit into software .This applies to any definition of quality: maintainability, reliability, adaptability, testability, safety, and so on. We have a very difficult time building quality into software during development when we try to. How can we possibly expect to achieve quality when we don’ t try? This is primarily why you must not try to convert a throwaway prototype into a product(Principle 11).

5、 不要試圖改進質量

軟體質量不能被改進。這適用任何質量的定義：可維護性，可靠性，適應性，可測試性，安全性等。當我們嘗試開發時，在開發過程中很難提高軟體質量。如果我們不嘗試，怎麼可以達到我們期望的質量。這就是為什麼你不能試圖將一次性原型（個人理解：臨時、口頭的、未經過推敲驗證的原型）轉換成產品的主要原因（原則11）。

principle 6 : poor reliability is worse than poor efficiency

When software is not efficient, it is generally possible to isolate the sections of the program that consume most of the execution time and redesign or recode them for increased efficiency(Principle 194).Poor reliability is not only more difficult to detect, it is also more difficult to fix.A system’s poor reliability may not become apparent until years after the system is deployed–and it kills somebody.Once the poor reliability manifests itself, it is often difficult to isolate its cause.

6、低可靠性比低效率更糟糕

當軟體效率不高時，通常可以將其中消耗大部分執行時間的部分隔離起來，重新設計或重新編碼來提升效率(原則194)。低可靠性不僅很難檢測，並且更難修復。一個系統的低可靠性可能在部署後的幾年內都不會有明顯的改變–它殺死了某些人。一旦低可靠性顯現出來，往往很難分離其原因。

principle 7 : give products to customers early

No matter how hard you try to learn users’needs during the requirements phase, the most effective means to ascertain their real needs is to give them a product and let them play with it.If you follow a conventional interpretation of the waterfall model, the first delivery of a product to the customer occurs after 99 percent of the development resources are already expended.Thus, the majority of customer feedback on their needs occurs after the resources are expended.Contrast that with an approach, for example, of constructing a quick and dirty prototype early in the development process.Deliver this to the customer, gather feedback, and then write a requirements specification and proceed with a full-scale development.In this scenario, only 5 to 20 percent of the development resources are expended by the time customers experience their first product.f the appropriate features were built into the prototype, the highest-risk user needs will become better known and the final product is more likely to be user-satisfactory.This helps ensure that the remainder of the resources are spent building the right system.

7、儘早呈現產品給使用者

無論你在需求階段多努力的去了解使用者的需求，最有效查明他們真實需求的手段是給他們一個產品，然後讓他們體驗。如果你遵從瀑布模型的常規解釋，第一次交付產品給使用者發生在99%的開發資源已經耗盡之後。於是，最重要的關於他們需求的使用者反饋發生在資源已經被耗盡之後。先比較一個方法，例如，在開發過程的早期構建一個快速且髒亂的原型。將此交付使用者，收集反饋，然後寫需求文件並進行全面開發。在這個方案中，只有5-20%的開發資源被消費，當消費者體驗他們第一個產品時。如果適當的特徵加入到了原型中，這些高風險的使用者需求將變得更好了解並且最終產品也將更接近使用者滿意的樣子。這些有助於確保資源的其餘部分用於構建正確的系統。

principle 8 : communicate with customers/users

Never lose sight of why software is being developed:to satisfy real needs,to solve real problems.The only way to solve real needs is to communicate with those who have the needs.The customer or user is the most important person involved with your project.If you are a commercial developer, talk often with the clients.Keep them involved.Sure, it is easier to develop software in a vacuum, but will the customer like the result?If you’re a producer of shrinkwrap software,”customers”are harder to locate during development.So role-play.Designate three or four individuals in your organization as prospective customers and tap them for ideas that will keep them as customers or make them happy.If you’re a government contractor, talk often with the contracting officers, their technical representatives, and, if possible, the users.People and situations change often in the government.the only way to keep up with the change is communication.Ignoring the changes may make life seem easier in the short term, but the final system will not be useful.

8、和客戶/使用者交流

永遠不要忽視為什麼要進行軟體開發。滿足實際的需要，解決實際的問題。這唯一的途徑去解決實際需要的方法就是去溝通那些有需要的人。客戶或者使用者是與你的專案相關的最重要的人。如果你是一個盈利性質的開發者，要經常和客戶交談。讓他們參與進來。當然，空白開發是很容易的，但是客戶會喜歡這樣的結果？如果你是軟體外包的生產商，那麼在開發階段顧客就更難定位了。所以，換位思考以下。在你的組織中指定三個或四個人作為客戶，並利用他們的想法，將他們作為客戶或使他們高興。如果你是一個政府專案的承包商，經常和政府軍官，他們的技術該表，如果可能，還有他們的使用者進行交談。政府的認識變化是很頻繁的。唯一能跟上這種變化的方式就是溝通。忽略這種變化可能短期的能讓生活看起來更簡單一些，但是最終系統可能將不那麼好用。

principle 9 : align incentives for developer and customer

Projects often fail because customers and developers have different(and perhaps incompatible) goals.For example, take the simple case in which the customer wants features 1, 2, and 3 by a specific date and the developer wants to maximize revenue or profit.To maximize revenue the develper may attempt to build all three features in their entirety even if late.To maximize revenue the develper may attempt to build all three features in their entirety even if late.To help align the two organizations’ goals:
(1)Prioritize requirements (Principle 50)so that developers understand their relative importance,
(2) reward the developer based on the relative priorities(for example, all highpriority requirements must be satisfied, each medium priority requirement earns the developer a small additional bonus of some kind and each low priority requirement satisfied earns a very small bonus),
(3)use strict penalties for late delivery

9、調整開發者和使用者的獎勵機制

專案會經常因為顧客和開發者之前不同的（也許根本不相容的）目標而失敗。舉個栗子，一個簡單的情況，客戶想要在要給特殊的時間獲得特徵1，2和3，而開發者想要最大化的收入和利潤。為了最大化收入，開發者可能會在他們的整體專案中接受生成全部的三個特徵，即便會延期。與此同時，顧客可能會首選少做一個特徵來保證其他的能準時上線。為了幫助平衡這兩個組織的目標：
（1）給需求排優先順序（原則50）為了讓開發者明白它們之間的重要性。
（2）基於優先順序，相對地給開發者獎勵（舉個栗子，所有高優先順序必須被滿足，每個中等優先順序需求將為開發者贏得一個小的額外的某種型別的獎勵，每個更低優先順序的需求被滿足則給一個更小的獎勵）。
（3）對未完成的情況使用嚴格的處罰手段。

principle 10 : plan to throw one away

One of the most important critical success factors for a project is whether it is entirely new.Programs that tread on brand new territory(whether it be with respect to application, architecture, interface, or algorithm) rarely work the first time.Fred Brooks, in his Mythical Man Month, makes this perfectly clear with his advice, “Plan to throw one away; you will anyway.”This advice was originally presented by Winston Royce in 1970, when he said one should plan for the first fully deployed system to be the second one created.The first should at least check out the critical design issues and the operational concept.Furthermore Royce recommended that such a prerelease version should be developed with approximately 25 percent of the total system development resources.As a developer of a new custom product, plan to build a series of throwaway prototypes(Principles 11, 12, and 13)before embarking on the full-scale product development.As a commercial high-volume developer expect that your first product version will be able to be modified for a certain period of years, after which it will need to be fully replaced(related Principles 185, 186, 188, and 201).As a maintainer of a product, be aware that you can fiddle with the program just so much before it becomes unstable and must be replaced (see related Principles 186, 191, 195, and 197).

10、計劃扔掉第一個

專案最重要的關鍵成功因素之一是它是否是全新的。進入嶄新領域的程式（無論是關於應用程式，體系結構，介面或者演算法）很少會在第一次就正常工作。Fred Brooks,在他的《Mythical Man Month》(人月神話)用他的忠告明確地說，“ 打算丟棄一個，無論如何你還會擁有的”。[ps:有點怪]。這個建議最初是在1970年被Winston Royce提出的，當時他說應該為第一個完全部署的系統升級為第二個系統做計劃。第一個系統至少應該檢查決定性設計問題和操作理念。此外，Royce推薦這樣一個預版本本應該用25%的系統資源來開發。作為一個新的定製產品的開發人員，計劃在開始大規模產品開發之前建立一系列一次性原型（原則11，12和13）。作為一個商業大容量的開發人員一定要確認你的第一個產品版本在數年內能夠被修改，未來它需要完全被替換（原則185, 186, 188和201）。作為一個程式的維護者，請注意，在程式變得不穩定並必須被替換之前，你可以對程式進行儘可能多的修改（見相關原則 186, 191, 195 和 197）。