系统分析与设计01

软件工程的定义

软件工程是研究和应用如何以系统性的、规范化的、可定量的过程化方法去开发和维护软件,以及如何把经过时间考验而证明正确的管理技术和当前能够得到的最好的技术方法结合起来的学科。

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

软件危机(software crisis)是指落后的软件生产方式无法满足迅速增长的计算机软件需求,从而导致软件开发与维护过程中出现一系列严重问题的现象。

本质原因

计算能力的提高已经超过了程序员有效利用这些能力的能力。

表现

软件危机其原因,衔接到硬件的整体复杂度,与软件开发流程。危机表现在几个方面:

  1. 项目运行超出预算。
  2. 项目运行超过时间。
  3. 软件质量低落。
  4. 软件通常不匹配需求。
  5. 项目无法管理,且代码难以维护。

克服软件危机的方法

  1. 正确认识计算机软件的内涵。
  2. 采用工程项目管理方法实施软件开发的组织管理。软件开发应该是一种组织良好、管理严密、协同配合的工程活动。
  3. 采用成熟的软件开发技术和方法,开发和使用适当的软件工具。

软件生命周期

计算机软件有一个孕育、诞生、成长、成熟、衰亡的生存过程,这样的过程称为软件的生命周期 (也称软件开发生命周期 SDLC)。软件生命周期将软件开发过程划分为若干阶段,每个阶段有明确的任务目标和运行机制,从而使复杂的软件开发过程能够得到适当的控制和管理。其生命周期包括:

  1. 可行性分析与计划阶段
    • 确定软件开发的总体目标,给出功能、性能、可靠性以及接口等方面的要求,进行可行性分析。
    • 估计可利用的开发资源 (硬件、软件、人力等)、成本、效益、开发进度,进行投资-收益分析,制订开发计划。
    • 提交可行性分析报告、开发计划等文档。
  2. 需求分析阶段
    • 分析用户提出的要求,给出用户需求详细定义,确定软件系统的各项功能、性能需求和设计约束,确定对文档编制的要求。
    • 提交软件需求说明、软件规格说明、数据要求说明等文档和初步的用户手册。
  3. 设计阶段
    • 概要设计/逻辑设计:把各项软件需求转换成软件的体系结构。结构中的每一个组成部分意义明确,并和某些需求相对应。
    • 详细设计/物理设计:对按照概要设计分解的每个模块所要完成的工作进行具体的描述,提供源程序代码编写的直接依据。
    • 提交概要结构设计说明书、详细设计说明书和测试计划初稿等文档。
  4. 实现阶段
    • 完成源程序的编码、编译 (或汇编) 和运行调试,得到没有语法错误的程序清单。程序结构良好、清晰易读,且与设计相一致。
    • 编写进度日报、周报和月报 (取决于项目的重要性和规模)。
    • 编制测试计划。
    • 提交用户手册、操作手册等面向用户的文档。
  5. 测试阶段
    • 全面测试目标软件系统,并检查审阅已编制的文档,提交测试分析报告。逐项评价所实现的程序、文档以及开发工作本身,提交项目开发总结报告。
  6. 运行与维护阶段
    • 软件提交给用户后,在运行使用中得到持续维护,根据用户新提出的需求进行必要而且可能的扩充、删改、更新和升级。
    • 软件维护包括改正性维护 (发现错误)、适应性维护 (适应运行环境变化) 和完善性维护 (增强功能)。

SWEBoK 的 15 个知识域(An Overview of the SWEBOK Guide 请中文翻译其名称与简短说明)

软件工程实践相关的知识领域

  1. 软件需求
    软件需求知识领域关注软件需求的启发,协商,分析,规范和验证。在软件行业中,人们普遍认为,当这些活动表现不佳时,软件工程项目非常容易受到攻击。软件需求表达了对软件产品的需求和限制,这些需求和约束有助于解决一些现实问题。
  2. 软件设计
    定义系统或者组件的体系结构、组件、接口和其他特征的过程,以及这个过程所得到的结果。
  3. 软件构建
    软件构建是指通过结合详细设计,编码,单元测试,集成测试,调试和验证来详细创建工作软件。
  4. 软件测试
    测试是一项旨在评估产品质量并通过识别缺陷来改进产品质量的活动。软件测试涉及在有限的测试用例集上针对预期行为动态验证程序的行为。这些测试用例是从(通常非常大的)执行域中选择的。软件测试知识领域包括软件测试的基础知识; 测试技术; 人机界面测试与评估等。
  5. 软件维护
    软件维护包括增强现有功能,调整软件以在新的和修改的操作环境中运行,以及纠正缺陷。这些类别称为完善,自适应和纠正性软件维护。软件维护知识领域包括软件维护的基础知识(维护的性质和需求,维护类别,维护成本); 软件维护中的关键问题(技术问题,管理问题,维护成本估算,软件维护测量); 维护过程; 软件维护技术(程序理解,重新设计,逆向工程,重构,软件退役); 灾难恢复技术和软件维护工具。
  6. 软件配置管理
    系统的配置是硬件,固件,软件或这些的组合的功能和/或物理特征。它还可以被视为根据特定构建过程组合的特定版本的硬件,固件或软件项的集合,以满足特定目的。因此,软件配置管理(SCM)是在不同时间点识别系统配置的规则,用于系统地控制配置的改变,以及在整个软件生命周期中维持配置的完整性和可追溯性。软件配置管理KA涵盖SCM过程的管理; 软件配置识别,控制,状态核算,审计; 软件发布管理和交付。
  7. 软件工程管理
    软件工程管理涉及规划,协调,测量,报告和控制项目或程序,以确保软件的开发和维护是系统化的,规范化的和量化的。软件工程管理知识领域涵盖了启动和范围定义(确定和协商要求,可行性分析以及要求的审查和修订); 软件项目计划(过程计划,工作量估算,成本和进度,资源分配,风险分析,质量计划); 软件项目制定(计量,报告和控制;收购和供应商合同管理); 产品验收; 审查和分析项目绩效; 项目结束等。
  8. 软件工程过程
    软件工程知识领域关注软件生命周期过程的定义,实施,评估,测量,管理和改进。
  9. 软件工程模型与方法
    软件工程模型和方法知识领域解决了涵盖多个生命周期阶段的方法。
  10. 软件质量
    软件质量是许多SWEBOK V3 知识领域中普遍存在的软件生命周期问题。此外,软件质量知识领域还包括软件质量的基础知识(软件工程文化,软件质量特性,软件质量的价值和成本以及软件质量改进); 软件质量管理流程(软件质量保证,验证和确认,审核和审核); 和实际考虑(缺陷表征,软件质量测量和软件质量工具)。
  11. 软件工程专业实践
    软件工程专业实践关注软件工程师必须具备的专业,负责和道德的软件工程知识,技能和态度。软件工程专业实践知识领域涵盖专业性(专业行为,专业协会,软件工程标准,雇佣合同和法律问题); 道德准则; 小组动态(团队合作,认知问题复杂性,与利益相关者互动,处理不确定性和模糊性,处理多元文化环境)和沟通技巧。

软件工程教育要求相关的知识领域

  1. 软件工程经济学
    软件工程经济学知识领域关注的是在业务环境中做出决策,以使技术决策与组织的业务目标保持一致。涵盖的主题包括软件工程经济学的基本原理(提案,现金流量,货币时间价值,计划视野,通货膨胀,折旧,替代和退休决策); 非营利性决策(成本效益分析,优化分析); 估计,经济风险和不确定性(估算技术,风险决策和不确定性); 和多属性决策(价值和衡量尺度,补偿和非补偿技术)。
  2. 计算基础
    计算基础知识领域涵盖了提供软件工程实践所需的计算背景的基础主题。涵盖的主题包括问题解决技术,抽象,算法和复杂性分析,编程基础,并行和分布式计算的基础知识,计算机组织,操作系统和网络通信的知识等。
  3. 数学基础
    数学基础知识领域涵盖了提供软件工程实践所必需的数学背景的基础主题。涵盖的主题包括集合,关系和功能; 基本命题和谓词逻辑; 证明技术; 图论和树; 离散数学; 概率论; 语法和有限状态机; 数论。
  4. 工程基础
    工程基础知识领域涵盖了提供软件工程实践所必需的工程背景的基础主题。涵盖的主题包括经验方法和实验技术; 统计分析; 测量和指标; 工程设计; 仿真与建模; 根本原因分析。

简单解释 CMMI 的五个级别

  1. Level 1 - Initial:无序,自发生产模式。
  2. Level 2 - Managed: 管理,对整个开发生产流程有监测与控制。
  3. Level 3 - Defined: 定义,管理体系在不同类的项目上一样能够得到成功的实施。
  4. Level 4 - Q-Managed: 量化管理,对管理流程要做到量化与数字化,实现控制管理的精度。
  5. Level 5 - Optimizing: 优化,利用信息资料,能够主动地改善流程,运用新技术,优化流程。

用自己语言简述 SWEBok 或 CMMI

CMMI是能力成熟度模型集成,CMMI可以看作是成功企业如何做好软件的一些习惯、做法、准则等的集合,是如何做好软件的最佳实践的集合。如果企业也能按照CMMI的要求做好,那么企业就很可能成为成功的企业。CMMI里面所有的要求,都是来自于成功企业的最佳实践。CMMI有两种表述方式:连续式与阶段式。阶段式表现方法仍然把CMMI中的若干个过程区域分成了5个成熟度级别,帮助实施CMMI的组织建议一条比较容易实现的过程改进发展道路;而连续式表现方法则通过将CMMI中过程区域分为四大类:过程管理、项目管理、工程以及支持。对于每个大类中的过程区域,又进一步分为基本的和高级的。这样,在按照连续式表示方法实施CMMI的时候,一个组织可以把项目管理或者其他某类的实践一直做到最好,而其他方面的过程区域可以完全不必考虑。

0%