软件的本质与软件工程科学相关知识点

软件工程的定义

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).” –– IEEE Standard 610.12

（1）软件工程是一种系统化，规范化，可量化的方法在开发，操作，维护上的应用。也就是说，是工程化在软件上的应用。

（2）对（1）中描述的方法的研究。

 

导致 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

表现：

The crisis manifested itself in several ways:

• 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

• 项目运行超出预算
• 项目运行超时
• 软件效率很低
• 软件质量很差
• 软件通常不符合需求
• 项目难以管理，代码难以维护
• 软件从未交付过

克服软件危机的方法：

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

总之为了解决软件危机，既要有技术措施(方法和工具)，又要有必要的组织管理措施。

 

软件生命周期

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

通常包括问题定义，可行性研究，需求分析，开发阶段和维护。

敏捷模型：

"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. The term was coined in the year 2001 when the Agile Manifesto was formulated.

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.

瀑布模型： 

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:[1]

• 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.

 

螺旋模型

In 1988, Barry Boehm published a formal software system development "spiral model," which combines some key aspect of the waterfall model and rapid prototypingmethodologies, in an effort to combine advantages of top-down and bottom-up concepts. It provided emphasis in a key area many felt had been neglected by other methodologies: deliberate iterative risk analysis, particularly suited to large-scale complex systems.

The basic principles are:[1]

• 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."[10]
• 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.[11]
• Begin each cycle with an identification of stakeholders and their "win conditions", and end each cycle with review and commitment.

 

SWEBoK 的 15 个知识域 

又见https://www.sebokwiki.org/wiki/An_Overview_of_the_SWEBOK_Guide

软件需求（Software Requirements）

软件需求知识域关注软件需求的引出、协商、分析、规范和确认。软件需求表示一些有助于解决实际问题的需求与约束。

软件设计（Software Design）

软件设计知识域涵盖了设计过程和最终产品。而设计被定义为设定一个系统的架构、组件、接口和其他特性的过程，或者是这个过程的结果（IEEE 1991）。

软件构建（Software Construction）

软件构建知识域包括与满足软件的需求和设计约束的软件开发有关的话题。它涵盖了涵盖软件构建基础知识、软件构建管理、构建技术、实用性考虑和软件构建工具。

软件测试(Software Testing)

软件测试涉及根据一组有限的测试用例集上的预期行为对程序行为进行动态验证。软件测试知识域包括软件测试的基础知识、测试技术、人机界面测试与评价、与测试有关的措施和事实的考虑。

软件维护(Software Maintenance)

软件维修知识域包括软件维护的基础、软件维护中的关键问题、维护过程、软件维护技术、灾难恢复技术和软件维护工具。

软件配置管理(Software Configuration Management)

软件配置管理知识域包括对SCM过程的管理；软件配置识别、控制、状态核算、审核；软件发布管理和交付；以及软件配置管理工具。

软件工程管理(Software Engineering Management)

软件工程管理知识域包括初始化和范围定义；软件项目规划；软件项目制定；产品验收；项目绩效的评审与分析；项目终止以及软件管理工具。

软件工程过程(Software Engineering Process)

 软件工程知识域关注软件生命周期过程的定义、实现、评估、测量、管理和改进。所涵盖的主题包括过程实现和变更；过程定义；过程评估模型和方法；测量以及软件过程工具。

软件工程模型和方法(Software Engineering Models and Methods)

软件工程模型和方法知识域解决了包含多个生命周期阶段的方法；针对特定被其他知识域覆盖的生命周期阶段的方法。所涵盖的主题包括建模；模型的类型；分析和软件开发方法。

软件质量(Software Quality)

软件质量知识域包括软件质量基础；软件质量管理过程；以及实用性考量。

软件工程职业实践(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研究所管理。它的目的是帮助软件企业对软件工程过程进行管理和改进，增强开发与改进能力，从而能按时地、不超预算地开发出高质量的软件。CMMI 为过程定义了如下几个成熟度级别: 初始级, 可管理级, 已定义级, 量化管理级, 优化管理级CMMI是一套融合多学科的、可扩充的产品集合，其研制的初步动机是为了利用两个或多个单一学科的模型实现一个组织的集成化过程改进。