高レベルな設計の目的は次のようになる。アーキテクチャ上の問題やプログラムの概念や構造に関する問題を実際のデータ処理に関わるコード上の問題と分離する。ソフトウェアコンポーネントを細分化することで個々のコンポーネントの開発に関わるものに制約を与え、結果としてバグを作りこみにくくする。コンポーネント間のインタフェースを定義することで複数のチームがそれぞれ別のコンポーネントを並行して開発できるようにし、各チームがその役割を認識できるようにする。また、実装言語を指定せずにプログラムの機能を記述することで、言語に依存した偏向を排除する。
プログラミング

プログラミング言語の開発史は、プログラムの複雑さを克服する試みの歴史であり、言語の発展がなければプログラムはその規模に対して指数関数的に理解が困難になっていただろう。プログラミング言語はコンピュータにより多くの仕事をさせるべく進化したと言う事もできるが、これは同じことを別の観点で言っているだけである。プログラム全体の構造や機能を見失うと、バグを見逃すことが多くなる。従って、よい言語を使えば理解が容易になり、バグも減らせる。

言語はソフトウェア設計の意図していることをなるべく簡単に記述できるよう進化してきた。文、サブルーチン、ファイル、クラス、テンプレート、ライブラリ、コンポーネントといった概念の導入により、プログラムの記述が抽象化・階層化・モジュール化され、コードの理解が容易になってきた。

さらに言語の進化によってデータの構造や利用に関しても正確な制御が可能となってきた。
テスト

プログラムが要求仕様などの通りに動作するかを判定するのがソフトウェアテストである。単体テストは、プログラムのごく一部（多くの場合1つのサブルーチン毎）を対象に仕様通りに動作することを確認する。結合テストは、より大きなモジュール単位での動作を確認する。
実行時

実行時の信頼性の判定はテストと似ているが、その観点はより単純であり、性能、他のコードとの相互運用性、特定のハードウェア構成で動作可能かといった点で評価される。
ソフトウェア品質の要因

ソフトウェア品質要因は機能面以外の要求仕様と考えられるが、顧客との契約に明記されることは少ない。しかし、ソフトウェアの品質を強化することは望ましい。

以下に主なソフトウェア品質要因を列挙する。
理解可能性(Understandability)
製品の目的が明らかなソフトウェア製品は理解可能である。この要因は単に目的だけではなく、設計文書やユーザー文書が容易に理解可能な形で書かれていることも含む。これは想定されるユーザーによっては重要な要因となる。例えば、ソフトウェア開発者向けのソフトウェア製品なら、素人が理解可能である必要はない。
完全性(Completeness)
製品が単独で機能できること、その機能が目的に対して十分であることを意味する。例えば、外部のライブラリを必要とするなら、少なくともそのライブラリの入手方法を付属文書などで示さなければならないし、バージョンなどの必要な情報も示す必要がある。
簡潔性(Conciseness)
無駄な情報がないことを意味する。メモリ容量が限られている環境では重要である。また、コードの行数を削減することも様々な意味で重要である。同じ機能を実現するコードが繰り返し出現する箇所をサブルーチン化することで改善される。また、文書についても同様のことが言える。
移植性(Portability)
様々なコンピュータ構成で容易に動作することを意味する。ハードウェアの違い（PC と Mac など）に関する移植性と、OSの違い（Mac OS X と GNU/Linux など）に関する移植性がある。
一貫性(Consistency)
記法や用語が一貫していることを意味する。
保守性(Maintainability)
新たな要求を満たすために改良する際の容易さを意味する。保守性の良いソフトウェア製品は、文書が完備されており、複雑でなく、メモリ容量や性能面で余裕がある必要がある。
試験性(Testability)
受け入れ基準が明確で性能評価が可能であることを意味する。設計段階での組み込みが重要となる。また、複雑な設計は試験性の低下を招く。
ユーザビリティ(Usability)
ユーザーにとって便利で実用的であることを意味する。特にユーザインタフェースが重要となる。
信頼性(Reliability)
ユーザーに影響するエラーを防ぎ、目的の機能が十分に実現されていることを意味する。これには機能をある時間内に実施できるという面も含まれる。また、必要とされたときには、エラーが発生しても停止しないで動作し続けることが要求される。これを堅牢性(ロバストネス(Robustness))とも呼ぶ。
構造化の度合い(Structuredness)
構成部品が一様なパターンとなっていることを意味する。構造化言語（Pascalなど）で書かれたソフトウェアはこの特性を満足する。
効率性(Efficiency)
目的達成の際にリソースを無駄に消費しないことを意味する。この場合のリソースとはメモリ使用量とプロセッサ使用時間である。
セキュリティ(Security)
不正アクセスからデータを守り、悪意ある操作に耐性があることを意味する。認証機構、アクセス制御、暗号化などのコンピュータセキュリティ機構の有無に関係する。
ソフトウェア品質要因の測定

ソフトウェア品質の測定には様々な観点がある。しかし、万人が納得する測定の観点は珍しい。人によってはソフトウェア品質の定量的測定が必須であるとされるが、他の人は定量的測定が有効な場面は限られると考えており、そのため定性的測定を好む。真に望ましい測定を行うことの難しさはソフトウェアテストの分野の権威が何人か書いている。例えば、Cem Kaner（英語版） の Software Engineering Metrics: What Do TheyMeasure and How Do We Know?[※ 2] と Douglass Hoffman The Darker Side of Metrics[※ 3] がある。

よく使われるメトリックの例として、検出バグ数がある。バグの少ないソフトウェアはバグの多いソフトウェアに比べて品質が高いとされる。以下のような質問の回答を考えることで、このメトリックが特定の場面で役立つかどうかを考えることができる。
どんなバグが多いのか? ソフトウェアの目的の違いを考慮しているか? ソフトウェアの規模や複雑さの違いを考慮しているか?

バグの重大性を考慮しているか? 障害の重大性やユーザーへの影響によって重み付けしているか? もし重み付けしていない場合、100件のバグと1000件のバグのどちらが品質が良いのかをどう判断するのか?

検出バグ数が時と共に減っている場合、その意味をどう判断するか? 例えば、その製品が従来よりも品質が良くなっていると判断できるのか? あるいは、改造を以前ほどしなくなっただけか? あるいは、評価を行う者が変わって以前よりバグを検出できなくなっただけか? あるいは、チームが意図的にバグ数の報告を少なくしようとしているのか?

最後の質問は、特に管理上の難しさを示している。ソフトウェアは人間が作るものであるため、ソフトウェア品質のメトリックは、ある意味で人間の振る舞いを測定することである[2]。チームがバグを過少に報告することで何らかの利益が得られるなら、そのチームは少なくバグを報告する傾向が強くなる。バグ追跡システムを出し抜く方法を見出したり、4、5件のバグを1件の報告にまとめてしまったり、些細なバグを報告しないことで作業量を減らすといったことである。意図したとおりの測定をすることは難しい。特にプログラマや評価者が、意識的か無意識的かに関わらず、測定そのものにゲームとしての誘因を見出さない場合、その傾向がある。例えば、品質保証部門がそのチームの過去のバグ傾向などから新たなソフトウェア開発におけるバグ収束曲線を予測し、実際のバグ報告とその予測を比較することで残存バグ数を見積もるとする。予測が正確であれば学習効果によって実際に報告されるバグ数は予測よりも少なくなる。予測通りのバグ数の報告が無ければ出荷が認められないとすれば、チームがバグ報告を過少に行うことはなくなる。