第9章ソフトウェア工学
Summaryまとめ
9.1 Software Engineering Fundamentals9.1 ソフトウェア工学の基礎
• Software engineering is concerned with how to effectively develop software.
• ソフトウェア工学は、ソフトウェアを効果的に開発する方法に関わる分野である。
• Software engineering is about solving practical issues that arise in software development, while computer science is more about theoretical principles used in software.
• ソフトウェア工学が、開発で生じる実際の問題の解決を扱うのに対し、コンピューターサイエンスは、ソフトウェアに用いる理論的原理に、より重点を置く。
• A good software engineer should have a solid background in computer science and must have good practical skills in areas such as computer programming.
• 優れたソフトウェアエンジニアは、コンピューターサイエンスの確かな基礎を持つとともに、コンピュータープログラミングなどの分野で優れた実践技能を持たなければならない。
• Software is usually developed in a team in which people have different roles and responsibilities.
• ソフトウェアは通常、異なる役割と責任を持つ人々のチームで開発する。
• Developing software involves addressing both the described desired functional and nonfunctional features.
• ソフトウェアの開発では、記述された望ましい機能的特性と非機能的特性の両方に対処する。
• There are a number of categories of software, including application, system, and embedded.
• ソフトウェアには、アプリケーションソフトウェア、システムソフトウェア、組み込みソフトウェアなど、いくつもの種類がある。
• Software engineers should understand software engineering processes, specific activities such as testing, and software tools.
• ソフトウェアエンジニアは、ソフトウェア工学のプロセス、テストなどの個別の活動、ソフトウェアツールを理解しておくべきである。
• Soft skills such as communication and problem-solving skills are important to being successful in the role of a software engineer.
• ソフトウェアエンジニアとして成功するには、意思疎通や問題解決などのソフトスキルが重要である。
9.2 Software Engineering Process9.2 ソフトウェア工学のプロセス
• A software engineering process framework is used to define the software process model or SDLC model that will be used to create a software solution.
• ソフトウェア工学のプロセスの枠組みは、仕組みの制作に用いるソフトウェアプロセスモデル、またはSDLCモデルを定めるために使う。
• Most SDLC models use phases or standard framework activities. The four common phases are inception, elaboration, construction, and deployment.
• 多くのSDLCモデルは、フェーズ、すなわち標準的な基本活動を使う。一般的な四つのフェーズは、立ち上げ、推敲、構築、配備である。
• SDLC models differ in terms of the rigidity and number of software engineering actions they specify need to be completed as part of the software development process.
• SDLCモデルによって、開発プロセスの一環として完了が必要だと指定するソフトウェア工学のアクションの数と、厳格さが異なる。
• One major category of process models is the traditional process models, which are usually prescriptive, sequential, and may not be suitable for projects with rapidly changing requirements.
• プロセスモデルの主要な種類の一つは、従来型プロセスモデルである。通常は規定的かつ逐次的であり、要求が急速に変化するプロジェクトには適さない場合がある。
• A second major category of process models is the Agile process models, which are less rigid, allowing for activities to skipped or accelerated to deliver a project solution faster and integrating user input early in the process.
• もう一つの主要な種類は、アジャイルプロセスモデルである。厳格さが小さく、プロジェクトの成果をより早く提供するために活動を省略したり加速したりでき、プロセスの早期にユーザーの意見を取り込む。
• In software development, developers use software architecture to view and evaluate the system as a whole before moving to component design.
• ソフトウェア開発では、部品の設計に進む前に、ソフトウェアアーキテクチャを使ってシステム全体を見渡し、評価する。
• In addition to the generic framework activities, there are other activities that crosscut the entire software development process but aren’t part of the main building steps themselves, such as communication and training, risk management and planning, software configuration and content management, software quality management (SQM), architecture management, and software security engineering.
• 汎用的な基本活動のほかに、開発プロセス全体を横断するものの、主要な構築手順そのものには含まれない活動がある。意思疎通と研修、リスク管理と計画、ソフトウェアの構成管理とコンテンツ管理、ソフトウェア品質管理(SQM)、アーキテクチャ管理、ソフトウェアセキュリティ工学などである。
• Software engineers should understand the various models and how they differ. Some of the popular software process models include the waterfall model, V-model, incremental model, prototyping model, spiral model, Unified Process model, and Agile Process models (such as Scrum and DevOps, among others).
• ソフトウェアエンジニアは、さまざまなモデルと、それらの相違を理解しておくべきである。よく使われるソフトウェアプロセスモデルには、ウォーターフォールモデル、Vモデル、増分モデル、プロトタイピングモデル、スパイラルモデル、統一プロセスモデル、ScrumやDevOpsなどのアジャイルプロセスモデルがある。
9.3 Special Topics9.3 個別の重要な話題
• Testing is a critical part of building successful software solutions.
• 成功するソフトウェアによる仕組みを構築するうえで、テストは極めて重要な部分である。
• To ensure quality, software goes through various levels of testing, such as unit testing, integration testing, and system testing, and it is subject to different testing approaches, such as acceptance testing, usability testing, stress testing, performance testing, and security testing. Each test serves an important function.
• 品質を確保するため、ソフトウェアには単体テスト、結合テスト、システムテストなど、さまざまな水準のテストを行う。また、受け入れテスト、ユーザビリティテスト、ストレステスト、性能テスト、セキュリティテストなど、異なる手法を適用する。各テストが重要な役割を果たす。
• Test-driven development in a process in which developers write unit tests before they write code. While counterintuitive, this can help clarify requirements, facilitate early bug detection, and even improve design and code quality.
• テスト駆動開発は、コードを書く前に単体テストを書くプロセスである。直感に反するものの、要求の明確化、バグの早期発見、さらには設計やコード品質の改善にも役立つ。
• Whereas unit testing focuses on the various units or pieces within a software solution, system testing focuses on the complete and fully integrated software product. Systems can be manual or automated.
• 単体テストがソフトウェアによる仕組みの個々の単位や部分に重点を置くのに対し、システムテストは完成し、完全に統合された製品に重点を置く。システムは手動にすることも自動化することもできる。
• Acceptance testing is used to determine that the software system works as was specified in the requirements. Taking place after system testing, this is typically done by the customer, client, or other end user of the software.
• 受け入れテストは、要求で指定したとおりにソフトウェアシステムが動作するかを判断するために使う。システムテストの後に、通常は顧客、依頼者、またはほかのエンドユーザーが行う。
• Usability testing tests the user interface by gaining feedback from a small group of users who are representative of the target audience.
• ユーザビリティテストでは、対象の利用者層を代表する少人数のユーザーからフィードバックを得て、ユーザーインターフェースをテストする。
• When developing software, developers use tools such as compilers, debuggers, profilers, integrated development environment (IDEs), version control systems, and bug tracking systems.
• ソフトウェアの開発では、コンパイラー、デバッガー、プロファイラー、統合開発環境(IDE)、バージョン管理システム、バグ管理システムなどのツールを使う。
• To resolve problems that commonly occur in the development of a software system, developers use reusable solutions called architectural patterns and design patterns.
• システム開発でよく生じる問題を解決するために、開発者は、アーキテクチャパターンやデザインパターンと呼ばれる、再利用可能な解決策を使う。
• Refactoring is a technique for restructuring an existing piece of code without changing its functionality.
• リファクタリングは、機能を変えずに、既存のコードの構造を組み直す技法である。
• Open-source software is provided with source code. Examples of open-source projects are Linux, Android, NetBeans IDE, Eclipse IDE, and the C# programming language.
• オープンソースソフトウェアはソースコードとともに提供される。プロジェクトの例には、Linux、Android、NetBeans IDE、Eclipse IDE、C#プログラミング言語がある。
• Whether you simply use software or create software, it is important to understand licensing so that you know what you can or cannot do with the software.
• ソフトウェアを使うだけの場合も、制作する場合も、何をしてよく、何をしてはいけないかが分かるように、ライセンスを理解することが重要である。
• Software engineers should abide by a code of ethics that guides the work that they do and the solutions that they produce.
• ソフトウェアエンジニアは、仕事と作り出す仕組みを導く倫理規範を守るべきである。
• The ACM/IEEE-CS Joint Task Force produced a Software Engineering Code of Ethics and Professional Practices that states that software engineers shall commit themselves to making the analysis, specification, design, development, testing, and maintenance of software a beneficial and respected profession.
• ACMとIEEE-CSの合同作業部会は、「ソフトウェア工学の倫理と専門的実践の規範」を作成した。この規範は、ソフトウェアエンジニアが、ソフトウェアの分析、仕様策定、設計、開発、テスト、保守を、有益で尊重される専門職にすることに尽力すると定める。
• Software engineering and the development of software solutions is evolving. As technology changes, so do some of the ways software is coded.
• ソフトウェア工学と、ソフトウェアによる仕組みの開発は進化している。技術が変わるにつれて、コードの書き方の一部も変化する。