第9章ソフトウェア工学

Popular Software Process Modelsよく使われるソフトウェアプロセスモデル

The framework activities (or phases) that have been presented as part of the process framework are general phases that get applied within software process models/SDLCs. The types of software engineering actions that get applied with each phase depend on the software development model that is used for the project at hand.

英語のヒント

ここまで枠組みの一部として示した活動、すなわちフェーズは、ソフトウェアプロセスモデルやSDLCのなかで適用する一般的な段階である。各フェーズでどの種類のアクションを行うかは、当該プロジェクトに使う開発モデルによって異なる。

There is a multitude of SDLC models. These models have evolved over time and offer various approaches to creating software solutions. Some more traditional SDLCs are prescriptive in terms of the software engineering actions that must be conducted, while others are agile. Agility, as you know by now, has to do with the ability to skip some software engineering actions or make some of the deliverables optional in order to meet deadlines and still deliver a quality product within budget constraints. As you may recall from Figure 9.4, there is a spectrum of agility between software process models. By nature, SDLCs are incremental as it is always possible to consider a subset of requirements for a given release. In fact, there are typically as many increments as there are subsets of requirements. To accommodate changes in requirements and possibly new requirements within an increment, SDLCs can involve iterations that make it possible to add to and replan increments on an ongoing basis. This adding and replanning may introduce backlogs because, usually, the original timeline cannot be changed.

英語のヒント

SDLCには多数のモデルがある。時代とともに発展し、ソフトウェアによる仕組みを作るための多様なアプローチを提供してきた。実施すべきアクションを規定する従来型のものもあれば、アジャイル型のものもある。これまで学んだように、俊敏性とは、一部のアクションを省いたり、一部の成果物を任意にしたりすることで、期限を守り、予算内で高品質な製品を届ける能力に関わる。図9.4で見たように、各モデルの俊敏性には幅がある。あるリリースで要求の一部だけを扱うことは常に可能なので、SDLCは本来、増分的なものである。実際、通常は要求の部分集合の数だけ増分がある。一つの増分の中で要求の変更や追加に対応するため、SDLCには、増分の追加や再計画を継続的に行う反復を含めることができる。通常は当初の日程を変更できないため、この追加や再計画によって、未完了の作業がバックログとして残ることもある。

In short, SDLCs can be made agile, incremental, and iterative. Historically, traditional models were incremental but not iterative or agile. The Unified Process (UP) model was the first traditional model to introduce iteration and it was quite prescriptive and, therefore, not agile, in terms of expected deliverables. Agile software process models are always incremental and iterative. That said, it does not make sense to use an Agile software model if the requirements are known and not expected to change during the increment. In that case, using out-of-the-box solutions may, with the help of some collaborative features found in Agile process guidelines set forth in agile ASDEs/SDLCs, produce better results. Traditional software process models follow a step-by-step plan, akin to building a house according to a blueprint. They are good for projects with clear requirements that don’t change much. While some organizations define the software development model their software engineers are expected to use, it is almost often better for teams to pick or tailor a software process model, so it aligns with the project at hand.

英語のヒント

つまり、SDLCはアジャイル型にも、増分型にも、反復型にもできる。歴史的には、従来型のモデルは増分的ではあったが、反復的でもアジャイル型でもなかった。統一プロセス（UP）は、従来型モデルで最初に反復を導入したものだが、期待する成果物についてはかなり規定的であり、アジャイルではなかった。アジャイル型のモデルは常に増分的かつ反復的である。もっとも、要求が既知で、その増分の途中で変化する見込みがないなら、アジャイル型モデルを使う意義はない。この場合、既製の解決策を使い、アジャイル型ASDEやSDLCの指針にある協働の機能を一部取り入れるほうが、よい結果になることもある。従来型のモデルは、設計図に従って家を建てるように、一段階ずつ計画を進める。要求が明確で、あまり変わらないプロジェクトに向いている。組織が使うモデルを定める場合もあるが、多くの場合、チーム自身が当該プロジェクトに合うようにモデルを選び、または調整するほうがよい。

6 https://hub.docker.com/ 7 https://jfrog.com/artifactory/

6 https://hub.docker.com/7 https://jfrog.com/artifactory/

Some of the popular software process models include:

よく使われるプロセスモデルには、次のものがある。

• Waterfall model

• ウォーターフォールモデル。

• V-model

• Vモデル。

• Incremental model

• 増分型モデル。

• Prototyping model

• プロトタイピングモデル。

• Spiral model

• スパイラルモデル。

• Unified Process (UP) model

• 統一プロセス（UP）モデル。

• Agile Process models

• アジャイル型プロセスモデル。

Waterfallウォーターフォール

Predominantly used in the early days of software engineering, the waterfall model is a continuous prescriptive software process model in which phases “flow” into another the way water flows from the top of a waterfall down to the bottom. In the waterfall model, the requirements are first gathered and analyzed, then a complete software system is designed, the system is implemented, and then final testing is done before the system is finally deployed. Unfortunately, the traditional waterfall model did not make a distinction between phases and software engineering actions, and, therefore, the steps it uses correspond to specific software engineering actions or task sets with custom names that should be conducted in a prescribed sequence. Our generic process framework may still be used to represent the waterfall process, but framework activities would have to be ignored and specific software engineering actions or task sets that correspond to the waterfall phase names would have to be used. For example, some of the testing task sets from the SQA software engineering action of the Quality Management umbrella activity could be pulled together to make up the waterfall testing phase.

英語のヒント

ソフトウェア工学の初期に主に使われたウォーターフォールモデルは、連続的で規定的なモデルである。滝の上から下へ水が流れるように、あるフェーズから次のフェーズへ「流れる」。まず要求を収集・分析し、次にシステム全体を設計して実装し、最後のテストを経て配備する。残念ながら、従来のウォーターフォールモデルは、フェーズとソフトウェア工学のアクションを区別していなかった。そのため、各段階は、独自の名前を持つ特定のアクションやタスクの集合に対応し、規定された順番で実施する。本書の汎用的な枠組みでもウォーターフォールを表せるが、枠組み上の活動は無視し、ウォーターフォールのフェーズ名に対応するアクションやタスクを使う必要がある。たとえば、品質管理というアンブレラ活動のSQAアクションから、テストのタスクをいくつか集め、ウォーターフォールのテストフェーズを構成できる。

In the waterfall model, software engineering actions or task sets are performed in a strict order as shown in Figure 9.8, and each one of these has a required output in the form of artifacts, such as a document, diagram, or code. This software process is not Agile, so it is not possible to skip a step or drop a deliverable. For example, the output of requirements analysis is a document that describes all requirements for the system. Because this process is not iterative, it is not possible to go back to a previous step to modify this output. For example, if the final design document contains a mistake, it could not be revised during the implementation step—the next step would be testing. Note, however, that there is nothing that keeps the waterfall model from being used incrementally. The concept of incremental development was simply not understood when waterfall was first used.

英語のヒント

ウォーターフォールでは、図9.8のように、アクションやタスクの集合を厳密な順序で実施する。それぞれに、文書、図、コードなどの成果物という形で、必須の出力がある。アジャイルではないため、段階を飛ばしたり、成果物を省いたりすることはできない。たとえば要求分析の出力は、システムのすべての要求を記述した文書となる。反復的な工程ではないため、出力を修正するために前の段階へ戻ることもできない。たとえば最終的な設計文書に間違いがあっても、実装の段階で直すことはできず、次はテストへ進む。ただし、ウォーターフォールを増分的に使うことを妨げるものはない。最初にこのモデルが使われた時代には、増分開発の概念がまだ理解されていなかったのである。

Figure 9.8 In the waterfall model, one step of the software development process “flows” into another, and each is required to produce an output in the form of a document, diagram, or code. (attribution: Copyright Rice University, OpenStax, under CC BY 4.0 license)

図9.8 ウォーターフォールモデルでは、一つの開発段階が次の段階へ「流れる」。各段階は、文書、図、コードという形の成果を生み出さなければならない。（帰属：Rice University、OpenStax著作権、CC BY 4.0ライセンス。）

The major advantages of the waterfall model include:

ウォーターフォールモデルの主な利点は、次のとおりである。

• It is easy to understand and use.

• 理解しやすく、使いやすい。

• Steps and corresponding software engineering actions or task sets are conducted sequentially.

• 各段階と、それに対応するアクションやタスクの集合を順番に実施する。

• The artifacts are well documented.

• 成果物が十分に文書化される。

Although the waterfall model has some advantages, they are often outweighed by its disadvantages:

英語のヒント

いくつかの利点はあるものの、次の欠点がそれを上回ることも多い。

• It cannot easily accommodate changes in requirements. If there is a change in requirements, it is necessary to go back to the first step of the process model and update all the artifacts that were previously completed.

• 要求の変更に容易には対応できない。変更があると、最初の段階へ戻り、既に完成したすべての成果物を更新する必要がある。

• No software product is provided until late in the life cycle. Because software is not available until the end of the implementation/construction step, it is not possible to ask the customer for feedback during the process.

• ライフサイクルの終盤までソフトウェア製品が提供されない。実装・構築段階の終わりまで使えるソフトウェアがないため、途中で顧客の意見を求められない。

• It produces many artifacts, which are not always necessary; therefore, a lot of time may be spent creating unnecessary artifacts.

• 必ずしも必要ではない成果物を多く作るため、不必要なものの作成に多くの時間を使う場合がある。

Despite these disadvantages, the waterfall method is useful in situations where requirements do not change and interaction with the users of a system is limited or nonexistent during a project.

こうした欠点があっても、要求が変わらず、プロジェクト中の利用者とのやり取りが限られるか、まったくない状況では、ウォーターフォールは有用である。