系统分析与设计第一次作业

1. 软件工程的定义

软件工程一直以来都缺乏一个统一的定义,很多学者、组织机构都分别给出自己认可的定义。如:ISO、IEEE等组织及BarryBoehm、FritzBauer等学者均给出了其认可的定义。其中,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).”
–– IEEE Standard 610.12

即,软件工程是:
(1)将系统化的、严格约束的、可量化的方法应用于软件的开发、运行和维护,即将工程化应用于软件;
(2)对(1)中所述方法的研究;

2. 解释导致软件危机的本质原因、表现,述说克服软件危机的方法

  • 导致软件危机的本质原因:
    落后的软件生产方式无法满足迅速增长的计算机软件需求,从而导致软件开发与维护过程中出现一系列严重问题。
  • 软件危机的表现:
    • 项目超预算;
    • 项目未能按时交付;
    • 软件效率低;
    • 软件质量低;
    • 软件通常不符合需求;
    • 项目难以管理,代码难以维护;
    • 软件从未交付;
  • 克服软件危机的方法:
    • 正确认识计算机软件的内涵;
    • 采用工程项目管理方法实施软件开发的组织管理;
    • 采用成熟的软件开发技术和方法,开发和使用适当的软件工具;

3. 软件生命周期

软件生命周期是指:在时间维度,对软件项目任务进行划分,又称为软件开发过程。 计算机软件有一个孕育、诞生、成长、成熟、衰亡的生存过程,这样的过程称为软件的生命周期。软件生命周期将软件开发过程划分为若干阶段,每个阶段有明确的任务目标和运行机制,从而使复杂的软件开发过程能够得到适当的控制和管理。软件生命周期一般包括可行性分析与计划、需求分析、设计(概要设计和详细设计)、编码实现、测试、运行与维护等活动。
常见的用于管理软件生命周期的模型有:瀑布模型、螺旋模型、敏捷模型等。

4. SWEBoK的15个知识域

  • 软件需求(Software Requirements)
    软件需求的知识域涉及需求的提出、协商、分析、规范和验证。软件行业普遍认为:如果上述活动未能被很好地实施,软件工程的项目是脆弱的。软件需求表达了对软件产品的需求和约束,这些需求和约束有助于解决一些实际问题。
  • 软件设计(Software Design)
    软件设计的知识域覆盖从初步设计到最终产品的全过程。软件设计是软件生命周期的一个子活动,在这个过程中,我们需要对软件需求进行分析,从而能够对软件内部结构及其行为进行描述,并将其作为软件构建的基础。
  • 软件构建(Software Construction)
    软件构建是指通过详细设计、编码、单元测试、集成测试、调试和验证,进而构建一个可正确运行的程序。软件构建的知识域涵盖了软件构建的基础、软件构建管理、构建技术、实际考虑因素和软件构建工具等。
  • 软件测试(Software Testing)
    测试是一种通过寻找缺陷来评估和改进产品质量的活动。软件测试包括通过有限的测试集,根据预期的行为对程序的行为进行动态验证。软件测试的知识域包括软件测试的基础知识、测试技术、人机交互界面测试与评价、测试方法、实际考虑因素。
  • 软件维护(Software Maintenance)
    软件维护包括增强现有的功能、使软件适应新的或修改过的操作环境和修改错误。软件维护的知识域包括软件维护的基本知识,如:维护的性质和需求、维护类别、维护费用等;软件维护中的关键问题,如:技术问题、管理问题、维护成本估算、软件维护度量等;维护过程;维护技术,如:程序理解、再工程、逆向工程、重构、软件退役等;故障恢复技术和软件维护工具。
  • 软件配置管理(Software Configuration Management)
    系统的配置指硬件、固件、软件或这些组合的功能和物理特性。软件配置管理是指在不同的时间点识别系统配置的规程,从而可以系统地控制配置的变更,以及在整个软件生命周期中维护配置的可追溯性。软件配置管理的知识域包括对软件配置管理过程的管理;软件配置识别的识别、控制、状态核查和审计;软件发布管理与交付;软件配置管理工具。
  • 软件工程管理(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)
    工程基础的知识域涵盖了为软件工程实践提供必要的工程背景的基本课题。包括经验方法和实验技术;统计分析;测量和度量;工程设计;仿真和建模;根本原因分析。

5. 简单解释CMMI的五个级别

  • Level 1 - Initial: 初始级
    在该级别中,企业对项目的目标与要做的努力很清晰,项目的目标基本能够实现。但是由于任务的完成带有很大的偶然性,企业无法保证在实施同类项目的时候仍然能够完成任务。项目实施对实施人员有很大的依赖性
  • Level 2 - Managed:管理级
    在该级别中,企业在项目实施上能够遵守既定的计划与流程、有资源准备、权责到人、对相关的项目实施人员有相应的培训、对整个流程有监测与控制并与上级单位对项目与流程进行审查。这一系列的管理手段排除了企业在初始级时完成任务的随机性,保证了企业的所有项目实施都会得到成功。
  • Level 3 - Defined: 定义级
    在该级别中,企业不仅能够对项目的实施有一整套的管理措施,并保障项目的完成;而且,企业能够根据自身的特殊情况以及自己的标准流程,将这套管理体系与流程予以制度化这样,企业不仅能够在同类的项目上生到成功的实施,在不同类的项目上一样能够得到成功的实施。
  • Level 4 - Quantitatively Managed:量化管理级
    在该级别中,企业的项目管理不仅形成了一种制度,而且要实现数字化的管理。对管理流程要做到量化与数字化。通过量化技术来实现流程的稳定性,实现管理的精度,降低项目实施在质量上的波动。
  • Level 5 - Optimizing:优化级
    在该级别中,企业的项目管理达到了最高的境界。企业不仅能够通过信息手段与数字化手段来实现对项目的管理,而且能够充分利用信息资料,对企业在项目实施的过程中可能出现的次品予以预防。能够主动地改善流程,运用新技术,实现流程的优化。

6. 用自己语言简述SWEBoK或CMMI

CMMI(Capability Maturity Model Integration,能力成熟度模型集成) 的本质是软件管理工程的一个参考标准。它的出现正好迎合了企业发展的需求,因为它通过知识能力的不同,用不同级别表示软件开发企业的成熟性,不仅给出了企业能力提升的路径,也给出了企业能力评估的事实标准。它的出现意味着今后我们可以用统一的标准衡量不同组织/企业的软件项目开发实力,也象征着软件产业逐渐走向了成熟。这不仅有利于企业提升自身开发能力,也有利于客户寻找可以满足自身开发需求的合适的企业。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值