系统分析与设计（1）

※ 软件工程的定义

在IEEE标准中，软件工程的定义为：

Software engineering is “(1) the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software, that is, the application of engineering to software,” and “(2) the study of approaches as in (1).”

中文意思为：

软件工程是：
（1）将系统化的、规范的、可度量的方法应用于软件的开发、运行和维护，即将工程化方法应用于软件；
（2）在（1）中所述方法的研究。

其他对于软件工程的定义（from wikipedia）：

• “the systematic application of scientific and technological knowledge, methods, and experience to the design, implementation, testing, and documentation of software”—The Bureau of Labor Statistics—IEEE Systems and software engineering - Vocabulary
• “The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software”—IEEE Standard Glossary of Software Engineering Terminology
• “an engineering discipline that is concerned with all aspects of software production”—Ian Sommerville
• “the establishment and use of sound engineering principles in order to economically obtain software that is reliable and works efficiently on real machines”—Fritz Bauer

※ 导致 software crisis 本质原因、表现，克服软件危机的方法

• 本质原因：

The major cause of the software crisis is that the machines have become several orders of magnitude more powerful! To put it quite bluntly: as long as there were no machines, programming was no problem at all; when we had a few weak computers, programming became a mild problem, and now we have gigantic computers, programming has become an equally gigantic problem.
— Edsger Dijkstra, The Humble Programmer (EWD340), Communications of the ACM

简单地说，软件危机的发生的本质原因是计算机硬件快速发展，从而软件规模越来越大，软件复杂度越来越高，但却缺乏系统、高效的软件开发方法。因为软件开发无法跟上硬件发展的速度，从而导致的各种问题。即开发出的软件无法充分利用硬件所具有的能力。同时，软件的内在本质（复杂性、不可见性、一致性、可变性），也是导致软件为危机的根源。

• 软件危机的表现

• Projects running over-budget
• Projects running over-time
• Software was very inefficient
• Software was of low quality
• Software often did not meet requirements
• Projects were unmanageable and code difficult to maintain
• Software was never delivered

• 克服软件危机的方法：
  • 借鉴其他工程项目中行之有效的原理、概念、技术与方法，特别是吸取人类从事计算机硬件研究和开发的经验教训。在开发软件的过程中女里做到良好的组织，严格的管理，相互友好的协作。
  • 推广在实践中总结出来的开发软件的成功的技术和方法，并研究更好、更有效的技术和方法，尽快克服在计算机系统早期发展阶段形成的一些错误概念和做法。
  • 根据不同的应用领域，开发更好的软件工具并使用这些工具。将软件开发各个阶段使用的软件工具合成一个整体，形成一个良好的软件开发环境。

※ 软件生命周期

软件生命周期（Life Cycle）：在时间维度，对软件项目任务进行划分，又称为软件开发过程。常见有瀑布模型、螺旋模型、敏捷的模型等。

• 瀑布模型(Waterfall development)
  

The waterfall model is a sequential development approach, in which development is seen as flowing steadily downwards (like a waterfall) through several phases, typically:

• Requirements analysis resulting in a software requirements specification
• Software design
• Implementation
• Testing
• Integration, if there are multiple subsystems
• Deployment (or Installation)
• Maintenance

The basic principles are:

• Project is divided into sequential phases, with some overlap and splashback acceptable between phases.
• Emphasis is on planning, time schedules, target dates, budgets and implementation of an entire system at one time.
• Tight control is maintained over the life of the project via extensive written documentation, formal reviews, and approval/signoff by the user and information technology management occurring at the end of most phases before beginning the next phase. Written documentation is an explicit deliverable of each phase.

• 螺旋模型(Spiral development)
  

The basic principles are:

• Focus is on risk assessment and on minimizing project risk by breaking a project into smaller segments and providing more ease-of-change during the development process, as well as providing the opportunity to evaluate risks and weigh consideration of project continuation throughout the life cycle.
• “Each cycle involves a progression through the same sequence of steps, for each part of the product and for each of its levels of elaboration, from an overall concept-of-operation document down to the coding of each individual program.”
• Each trip around the spiral traverses four basic quadrants: (1) determine objectives, alternatives, and constraints of the iteration; (2) evaluate alternatives; Identify and resolve risks; (3) develop and verify deliverables from the iteration; and (4) plan the next iteration.
• Begin each cycle with an identification of stakeholders and their “win conditions”, and end each cycle with review and commitment.

• 敏捷的模型(Agile development)

“Agile software development” refers to a group of software development methodologies based on iterative development, where requirements and solutions evolve via collaboration between self-organizing cross-functional teams.
Agile software development uses iterative development as a basis but advocates a lighter and more people-centric viewpoint than traditional approaches. Agile processes fundamentally incorporate iteration and the continuous feedback that it provides to successively refine and deliver a software system.
There are many agile methodologies, including:

• Dynamic systems development method (DSDM)
• Kanban
• Scrum

※ SWEBOK的15个知识域

SWEBOK包括15个知识域，其中，11个为软件工程实践知识域，分别为软件需求、软件设计、软件构造、软件测试、软件维护、软件配置管理、软件工程管理、软件工程过程、软件工程模型和方法、软件质量、软件工程职业实践；4个为软件工程教育基础知识域，分别为软件工程经济学、计算基础、数学基础和工程基础。

---

软件工程实践知识域：

• 软件需求(Software Requirements)： 软件工程需求知识域关注的是软件需求的来源、协商、分析、说明和最终的确认。在软件产业中，需求知识域中的这几个活动如果不认真施行，将会对这个项目造成致命威胁。软件产品是用于解决现实生活中的问题的，而软件需求则是根据现实生活来确定软件产品的功能和约束。
• 软件设计(Software Design)： 设计被定义为设定一个系统的架构、组件、接口和其他特性的过程，或者是这个过程的结果（IEEE 1991）。软件设计包括了设计的过程和最终的产品。软件设计过程是软件生命周期中的一个阶段，在软件需求分析已经完成的基础上，用于描述软件核心的构造以及作为服务软件构造的基础的一些动作。一个软件设计（结果）必须描述软件的架构，即软件是如何分解成这些组件的以及这些组件的接口。此外，软件设计必须在能够说明架构组成的细节层面上描述这些组件。
• 软件构造(Software Construction)： 软件构造是指经过细节设计、编码、单元测试、整合测试、调试和检验等活动组合的可工作软件的细节构造。软件构造知识域包括和满足软件需求和约束设计的软件程序的开发相关的话题。这个知识域涵盖了软件架构的基础、软件架构的管理、架构的技术、实用性考量和软件架构工具。
• 软件测试(Software Testing)： 测试是对产品质量进行评估并通过识别缺陷来改进产品质量的活动。软件测试是在一组有限的测试用例上根据程序的预期行为动态地验证程序的行为。这些测试用例是从(通常非常大的)执行域中选择的。软件测试知识域包括软件测试的基础知识、测试技术、人机界面测试与评价、与测试有关的措施和事实的考虑。
• 软件维护(Software Maintenance)： 软件维护包括增强现有的功能，使软件适应在新修改的操作环境上运作，以及纠正缺陷。这些范畴被称为完善的、自适应的和纠正的软件维护。软件维修知识域包括软件维护的基础（维护的性质和需要、维护的类别、维护费用）、软件维护中的关键问题(技术问题、管理问题、维护成本估算、软件维护度量)、维护过程、软件维护技术（程序理解力、工程重组、逆向工程、重构、软件退役）、灾难恢复技术和软件维护工具。
• 软件配置管理(Software Configuration Management)： 系统的配置是硬件、固件、软件或它们的组合的功能和/或物理特征。它还可以看作是硬件、固件或软件项目的特定版本的集合，为了服务于特定的目的，将这些硬件、固件和软件项目根据特定的构建过程组合在一起。因此，软件配置管理(SCM)是在不同的时间点识别系统配置的规程，以便系统地控制配置的更改，并在整个软件生命周期中维护配置的完整性和可追溯性。软件配置管理知识域包括SCM过程的管理，软件配置识别、控制、状态核算、审计，软件发布管理和交付以及软件配置管理工具。
• 软件工程管理(Software Engineering Management)： 软件工程管理包括计划、协调、测量、报告和控制一个项目或程序，以确保软件的开发和维护是系统的、有纪律的和量化的。软件工程管理知识域包括初始化和范围定义（确定和协商需求、可行性分析以及需求的评审和修订）；软件项目规划（过程规划、工作量、成本和进度的估计、资源分配、风险分析、质量规划）；软件项目制定（测量、报告和控制；采购和供应合同管理）；产品验收；项目绩效的评审与分析；项目终止以及软件管理工具。
• 软件工程过程(Software Engineering Process)： 软件工程知识域关注软件生命周期过程的定义、实现、评估、度量、管理和改进。所涵盖的主题包括过程实现和变更（过程基础结构、过程实现和变更的模型以及软件过程管理）；过程定义（软件生命周期模型和过程，过程定义、过程适应和过程自动化的标记）；过程评估模型和方法；测量（过程测量、产品测量、测量技术、测量结果质量）以及软件过程工具。
• 软件工程模型和方法(Software Engineering Models and Methods)： 软件工程模型和方法知识域解决了包含多个生命周期阶段的方法；针对特定被其他知识域覆盖的生命周期阶段的方法。所涵盖的主题包括建模（软件工程模型的原理和属性；语法、语义、常量；前置条件、后置条件和约束条件）；模型的类型（信息、结构和行为模型）；分析（对正确性、完整性、一致性、质量和交互进行分析；可追溯性；和权衡分析）以及软件开发方法（启发式方法、正式方法、原型方法和敏捷方法）。
• 软件质量(Software Quality)： 软件质量是一个软件生命周期中普遍存在的问题，在许多SWEBOK V3的知识域中都得到了解决。此外，软件质量知识域还包括软件质量的基础（软件工程文化、软件质量特征、软件质量的价值和成本、软件质量改进）；软件质量管理过程（软件质量保证、验证和确认、评审和审计）；以及实际的考虑（缺陷特征描述、软件质量度量和软件质量工具）。
• 软件工程职业实践(Software Engineering Professional Practice)： 软件工程职业实践是指软件工程师必须具备的知识、技能和态度，以一种专业、负责和道德的方式来实践软件工程。软件工程职业实践知识域涵盖职业化（职业行为、职业协会、软件工程标准、雇佣合同、法律问题）；伦理规范；团队动态（在团队中工作，认知问题的复杂性，与利益相关者的互动，处理不确定性和模糊性，处理多元文化环境）和沟通能力。

---

软件工程教育基础知识域：

• 软件工程经济学(Software Engineering Economics)： 软件工程经济学知识域关注于在业务中做出决策，以使技术决策与组织的业务目标保持一致。所涵盖的主题包括软件工程经济学的基础（提案、资金流、货币的时间价值、规划期限、通货膨胀、折旧、重置和退休决定）；非营利性决策（成本效益分析、优化分析）；评估、经济风险和不确定性（评估技术、风险和不确定性下的决策）以及多属性决策（价值和度量尺度、补偿和非补偿技术)。
• 计算基础(Computing Foundations)： 计算基础知识域涵盖了为软件工程实践提供必要的计算背景的基本主题。包括解决问题的技术、抽象、算法和复杂性、编程基础、并行和分布式计算的基础、计算机组织、操作系统和网络通信。
• 数学基础(Mathematical Foundations)： 数学基础知识域涵盖了为软件工程实践提供必要数学背景的基本主题。包括集合、关系和函数；基本命题逻辑和谓词逻辑；证明技术；图表和树；离散概率；语法和有限状态机；数论。
• 工程基础(Engineering Foundations)： 工程基础知识域涵盖了为软件工程实践提供必要的工程背景的基本主题。所涵盖的主题包括经验上的方法和实验技术；统计分析；测量和度量；工程设计；仿真和建模；根本原因分析。

---

※ CMMI的五个级别

• Level 1 - Initial：软件过程是无序的，对过程几乎没有定义。管理是反应式的。
• Level 2 - Managed：建立了基本的项目管理过程来跟踪费用、进度和功能特性。制定了必要的过程纪律，能重复早先类似应用项目取得的成功经验。
• Level 3 - Defined：已将软件管理和工程两方面的过程文档化、标准化，并综合成该组织的标准软件过程。所有项目均使用经批准、剪裁的标准软件过程来开发和维护软件，软件产品的生产在整个软件过程是可见的。
• Level 4 - Quantitatively Managed：分析对软件过程和产品质量的详细度量数据，对软件过程和产品都有定量的理解与控制。管理有一个作出结论的客观依据，管理能够在定量的范围内预测性能。
• Level 5 - Optimizing：过程的量化反馈和先进的新思想、新技术促使过程持续不断改进。
  

※ CMMI简述

      CMMI(Capability Maturity Model Integration) ，即软件能力成熟度模型集成，由美国国防部与卡内基-梅隆大学和美国国防工业协会共同研制，目的是帮助软件企业对软件工程过程进行管理和改进，增强开发与改进能力，从而能按时地、不超预算地开发出高质量的软件。CMMI为改进一个组织的各种过程提供了一个单一的集成化框架，新的集成模型框架消除了各个模型的不一致性，减少了模型间的重复，增加透明度和理解，建立了一个自动的、可扩展的框架。因而能够从总体上改进组织的质量和效率。