| English | 意味 |
|---|---|
| requirements/rɪˈkwaɪəmənts/ | 要件 |
| development life cycle/dɪˈveləpmənt laɪf ˈsaɪkl/ | 開発ライフサイクル |
| waterfall/ˈwɔːtəfɔːl/ | ウォーターフォールモデル |
| maintenance/ˈmeɪntənəns/ | 保守 |
| iterative model/ˈɪtərətɪv ˈmɒdl/ | 反復モデル |
| rapid application development/ˈræpɪd ˌæplɪˈkeɪʃn dɪˈveləpmənt/ | ラピッド・アプリケーション・ディベロップメント |
| prototype/ˈprəʊtəʊtaɪp/ | プロトタイプ |
| agile/ˈædʒaɪl/ | アジャイル |
| implementation/ˌɪmplɪmənˈteɪʃn/ | 実装 |
The airport that opened sixteen months late
- Denver's new airport was due to open in October 1993 with the most ambitious baggage system ever built: 4,000 automatic carts, 35 km of track, no human hands. It opened in February 1995, $560 million over budget, with the carts shredding suitcases in test runs.
- The schedule had been fixed before anyone analysed what the system had to do. Requirements kept changing while it was being built. Testing started when there was no time left to fix what it found.
- Every one of those failures has a name in this lesson. A development life cycle 开发生命周期 exists so that a project is planned, managed and controlled instead of discovered.
- This lesson is what a life cycle is for, the three models the syllabus names, and the five stages every program goes through.
Why a life cycle is needed
- A development life cycle is the set of stages from idea to finished, maintained software. Its purpose is to plan, manage and control a project: the right product, on time, with good quality.
- It manages complexity by breaking a big program into phases, coordinates a team, and tracks progress against milestones.
- It builds in testing rather than leaving it to the end, records design decisions for whoever maintains the program later, and manages risk.
開発ライフサイクルは次のために使用される:
難易度 1/5 · 100 コイン + 今日初回完了時に小ボーナス付与
作業を段階に分割することで、チームが品質の高い製品を期限通りに構築できるよう構造化する。
開発ライフサイクルの目的として正しいものを すべて 選択せよ。
難易度 2/5 · 140 コイン + 今日初回完了時に小ボーナス付与
ライフサイクルは計画・管理・統制を行う。正しさを保証することはできないが、欠陥の発見と修正を計画の一部とする。
Why there is more than one
- No single life cycle fits every project, so several exist and the exam asks you to choose.
- The choice depends on the size and complexity of the program, how clear the requirements 需求 are at the start, how much change is expected, the risk if it fails, the team, and the deadline.
- A payroll system with fixed legal rules and a game whose players do not yet know what they want are different projects. They deserve different cycles.
Waterfall
- The waterfall 瀑布模型 model is a linear sequence: analysis, design, coding, testing, maintenance. Each stage is finished, documented and signed off before the next begins.
- Benefits: clear structure, easy to manage and schedule, thorough documentation at every stage, well suited to stable requirements.
- Drawbacks: a change of requirements mid-project means going back up the waterfall; the customer sees nothing working until the end; errors in analysis surface only at testing.

Water does not flow back uphill
ウォーターフォールモデルが適しているプロジェクトは、以下の通り:
難易度 1/5 · 100 コイン + 今日初回完了時に小ボーナス付与
ウォーターフォールは各段階が完了してから次の段階へ進む線形モデルであり、安定した要件には最適だが、途中での変更には不向きである。
ウォーターフォールモデルでは、顧客はプロジェクトの初めから動作中のバージョンを確認できる。
難易度 1/5 · 100 コイン + 今日初回完了時に小ボーナス付与
コーディングとテストが終了する近辺まで何も動かない。早期に動作するソフトウェアを確認できるのは、イテレーティブモデルやRADの強みである。
Iterative
- The iterative model 迭代模型 makes repeated passes. Each pass produces a partial working version that is reviewed by the user and refined in the next pass.
- Benefits: problems are caught earlier; the user sees working software early and often; good when requirements are discovered over time.
- Drawbacks: harder to estimate the total cost and time; repeated reviews need the user's attention; the design can drift without discipline.

Build, show, refine, repeat
Rapid application development
- Rapid application development 快速应用开发 (RAD) builds a prototype 原型 quickly, puts it in front of the users, and rebuilds it from their feedback until it becomes the product. Teams often work on parts in parallel.
- Benefits: a very fast first delivery; requirements that change are absorbed as they appear; users shape the product directly.
- Drawbacks: it depends on users being available throughout; the prototype's shortcuts can survive into the product; it suits smaller systems better than large safety-critical ones. Agile 敏捷 methods take the same idea further, with short sprints and constant testing.

Prototype, feedback, prototype again
ウォーターフォールモデルでは各段階が完了してから次の段階に進むのに対し、アジャイルは短いイテレーションスプリントで進め、継続的なフィードバックを得る。
難易度 1/5 · 100 コイン + 今日初回完了時に小ボーナス付与
ウォーターフォールは線形(安定した要件に適しています);アジャイルは短期スプリントによる継続的な顧客との協力およびテストを通じて適応します。
各モデルをその主要なアイデアと対応させなさい。
難易度 2/5 · 140 コイン + 今日初回完了時に小ボーナス付与
ウォーターフォール=線形;反復的=反復による改善;RAD=プロトタイプ駆動型かつ高速。
迅速アプリケーション開発では、ユーザーが試してフィードバックを与えた後、再構築するための____を構築します。
難易度 1/5 · 100 コイン + 今日初回完了時に小ボーナス付与
プロトタイプはRADの定義的特徴であり、それに対するユーザーのフィードバックこそが要件の発見方法です。
Worked example: choose a life cycle and justify it
- A company needs software to calculate employees' pay under tax rules that are fixed by law. Which life cycle, and why? Waterfall: the requirements are stable and fully known at the start, the rules can be documented completely in analysis, and the thorough documentation matters for a system that must be correct and audited.
- A start-up wants an app for a new kind of social event; its users are not sure what features they want. RAD: the requirements are unclear and will change, so a prototype that users try and react to discovers them quickly, and the small system suits fast rebuilding.
- Name the model, then link two of its properties to two facts in the scenario.
ユーザーが何を求めているか不明确なアプリを小さなチームで構築し、ユーザーが毎週バージョンを試せる場合、最も適したライフサイクルはどれか?
難易度 1/5 · 100 コイン + 今日初回完了時に小ボーナス付与
不明確で変化する要件+利用可能なユーザーはRADのケースである。ウォーターフォールは要件を当初に固定する必要がある。
The five stages
- Analysis: find out what the program must do; gather and document the requirements from the users.
- Design: decide how: data structures, algorithms, modules, the user interface, file layouts, expressed in structure charts, flowcharts and pseudocode.
- Coding (implementation 实现): write the source code following the design. Testing: run it against planned test data and correct the errors found.
- Maintenance 维护: after release, keep it working and useful, correcting faults, adapting to change and improving it.
ソフトウェア開発ライフサイクル
プロジェクトが通す各段階を順を追う。分析における要件の把握が最も重要であり、テストで発見されるミスよりも早期に発見されるミスの修正コストの方が遥かに高い。
分析段階の主な目的は何かを決定することである:
難易度 1/5 · 100 コイン + 今日初回完了時に小ボーナス付与
分析は要件(「何」)を集約し、設計は「どうするか」を決定する。
プログラムの開発ライフサイクルの段階を正しい順序で並べなさい。
難易度 3/5 · 200 コイン + 今日初回完了時に小ボーナス付与
何をするか、どうするか、構築、検証、動作維持。反復モデルでは中間段階が繰り返されるが、各パス内の順序は同じである。
Worked example: what happens in analysis and design
- Describe what happens during the analysis and design stages of the program development life cycle. [4]
- Analysis: the developers interview and observe the users to find out what the program must do; they identify the inputs, the outputs and the processing required, and write a requirements specification that the customer agrees.
- Design: the developers decide how the program will meet those requirements: they choose the data structures and algorithms, decompose the program into modules on a structure chart, design the screens and files, and write pseudocode.
- Two actions and a product for each stage. "They analyse the problem" restates the heading and earns nothing.
Marks that slip away
- Analysis is what, design is how. "Deciding the algorithms" belongs to design.
- Waterfall is not "the bad one". Its strength is stable, documented requirements; its weakness is change. Give both when asked for benefits and drawbacks.
- RAD is not just "fast". Its defining feature is the prototype and the users' feedback on it.
- Maintenance is a stage, not an afterthought: most of a program's lifetime cost is spent there.
You've got it
- a life cycle plans, manages and controls a project: phases, milestones, testing built in, decisions recorded, risk managed
- waterfall: linear, each stage signed off, best for stable requirements, poor at change · iterative: repeated refined versions, catches problems early, harder to estimate · RAD: prototype plus user feedback, fast and flexible, needs available users
- choose by requirement clarity, expected change, size and risk, and justify with the scenario
- the stages: analysis (what) → design (how) → coding → testing → maintenance