【系统分析与设计】软件与软件工程

本文探讨了软件工程的定义,分析了软件危机的原因、表现及解决策略。阐述了软件生命周期、SWEBoK的15个知识域和CMMI的五个级别,旨在理解和提升软件开发的系统性与效率。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

简答题

一、软件工程的定义

Software engineering is the application of engineering to the development of software in a systematic method.

Notable definitions of software engineering include:

  • “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
  • “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 本质原因、表现,述说克服软件危机的方法

本质原因:

软件危机的根源在于软件的大量需求与软件生产力效率之间的矛盾,以及软件系统的复杂性与软件开发方法之间的矛盾。

表现:

  1. 对软件开发成本和进度的估计常常很不准确。这种现象降低了软件开发组织的信誉。而为了赶进度和节约成本所采取的一些权宜之计又往往损害了软件产品的质量,从而不可避免地会引起用户的不满。

  2. 用户对“已完成的”软件系统不满意的现象经常发生。软件开发人员和用户之间的信息交流往往很不充分,“闭门造车”必然导致最终的产品不符合用户的实际需要。

  3. 软件质量保证技术(审查、复审和测试) 没有坚持不懈地应用到软件开发全过程中。

  4. 软件常常是不可维护的。由于开发过程没有统一的、公认的规范,软件开发人员按各自的风格工作,各行其是。很多程序中的错误是非常难改正的,实际上不可能使这些程序适应新的硬件环境,难适应用户要求增加的新的功能需求,软件的复用性不高。

  5. 软件通常没有适当的文档资料。计算机软件不仅仅是程序,还应该有一整套文档资料。这些文档资料应该是在软件开发过程中产生出来的,而且应该是“最新式的”(即和程序代码完全一致的)。软件通常没有适当的文档资料,文档资料的作用是:管理和评价软件开发过程的进展情况,开发者与用户和开发者之间通信的工具,维护工具。

  6. 软件成本在计算机系统总成本中所占的比例逐年上升。由于微电子学技术的进步和生产自动化程fe的不断提高,硬件成本逐年下降,然而软件开发需要大量人力,软件成本随着通货膨胀以及软件,规模和数量的不断扩大而持续上升。1985年美国软件成本占计算机系统总成本的比例90%。

  7. 软件开发生产率提高的速度,远远跟不上计算机应用迅速普及深入的趋势。软件产品“供不应求”的现象使人类不能充分利用现代计算机硬件提供的巨大潜力。

克服方法

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

三、软件生命周期

在软件工程中,软件开发过程是将软件开发工作划分为不同阶段以改进设计,产品管理和项目管理的过程。它也被称为软件开发生命周期。

四、SWEBoK 的 15 个知识域

  • 软件需求(Software Requirements )
    软件需求KA涉及软件需求的引出、协商、分析、规范和验证。在软件行业中,人们普遍认为,当这些活动执行得不好时,软件工程项目是非常脆弱的。软件需求表达了对软件产品的需求和约束,这些需求和约束有助于解决一些实际问题。
  • 软件设计(Software Design)
    软件设计KA包括设计过程和最终产品。软件设计过程是软件工程生命周期活动,在该活动中,软件需求被分析,以产生对软件内部结构及其行为的描述,这些描述将作为软件构建的基础。软件设计(结果)必须描述软件体系结构——即,如何将软件分解和组织成组件以及这些组件之间的接口。它还必须在支持组件构造的详细级别上描述组件。
  • 软件构造(Software Construction)
    软件构建是指通过详细设计、编码、单元测试、集成测试、调试和验证相结合,对工作软件进行详细创建。软件构建知识域包括与满足其需求和设计约束的软件程序开发相关的主题。这个知识域涵盖了软件构建基础;管理软件建设;施工技术;实际问题;以及软件构建工具。
  • 软件测试(Software Testing)
    测试是对产品质量进行评估并通过识别缺陷来改进产品质量的活动。软件测试涉及到在一组有限的测试用例上根据预期行为动态地验证程序的行为。这些测试用例是从(通常非常大的)执行域中选择的。软件测试KA包括软件测试的基础知识;测试技术;人机界面测试与评价;任何跟测试有关的措施;和实际的考虑。
  • 软件维护(Software Maintenance)
    软件维护包括增强现有的功能,使软件适应新的和修改的操作环境,以及纠正缺陷。这些类别被称为完善的、自适应的和纠正的软件维护。软件维修KA包括软件维修的基本知识(维修的性质和需要、维修的类别、维修费用);软件维护中的关键问题(技术问题、管理问题、维护成本估算、软件维护度量);维护过程;软件维护技术(程序理解、再工程、逆向工程、重构、软件退役);灾难恢复技术和软件维护工具。
  • 软件配置管理(Software Configuration Management)
    系统的配置是硬件、固件、软件或它们的组合的功能和/或物理特征。它还可以看作是硬件、固件或软件项目的特定版本的集合,为了服务于特定的目的,将这些硬件、固件和软件项目根据特定的构建过程组合在一起。因此,软件配置管理(SCM)是在不同的时间点识别系统配置的规程,以便系统地控制配置的更改,并在整个软件生命周期中维护配置的完整性和可追溯性
  • 软件工程管理(Software Engineering Management )
    运用管理活动,确保软件开发和维护是系统的、规范的、可度量的。它设计基础设施管理、项目管理、度量和控制计划三个层次。度量是软件管理决策的基础。
  • 软件工程过程(Software Engineering Process)
    软件工程知识领域关注软件生命周期过程的定义,实现,评估,测量,管理和改进。主题包括过程实现和改变(过程基础设施,过程实现和改变模型,和软件过程管理),过程定义(软件生命周期模型和过程,过程定义,过程适应和自动化过程的符号),过程评估模型和方法,测量(过程测量,产品测量,技术测量和测量结果质量)和软件过程工具
  • 软件工程模型与方法(Software Engineering Models and Methods)
    软件工程模型和方法KA解决了包含多个生命周期阶段的方法;针对特定生命周期阶段的方法由其他ka覆盖。所涵盖的主题包括建模(软件工程模型的原理和属性;语法、语义、不变量;(前置条件、后置条件和不变量);模型的类型(信息、结构和行为模型);分析(对正确性、完整性、一致性、质量和交互进行分析;可追溯性;和权衡分析);以及软件开发方法(启发式方法、正式方法、原型方法和敏捷方法)。
  • 软件质量(Software Quality)
    软件质量是软件生命周期普遍关注的,存在于许多 SWEBOK V3 知识领域中。此外,软件质量知识领域包括软件质量基础(软件工程文化,软件质量特征,软件质量价值和成本和软件质量改进),软件质量管理过程(软件质量保证,认证和确认,审核和审计)和实际考量(缺陷特征,软件质量测量和软件质量工具)。
  • 软件工程专业实践(Software Engineering Professional Practic)
    软件工程专业实践关注软件工程师必须具备的知识,技巧和态度,以用一种专业,负责和正直的态度来时间软件工程。软件工程专业实践知识领域涵盖专业性(专业行为,专业协会,软件工程标准,雇佣合同和法律问题),道德准则,动态小组(团队合作,认知问题复杂性,与利益相关者交互,不确定性和模糊性的处理,多元环境处理)和交流技巧。
  • 软件工程经济学(Software Engineering Economics)
    软件工程经济学KA关注于在业务上下文中做出决策,以使技术决策与组织的业务目标保持一致。所涵盖的主题包括软件工程经济学的基本原理(建议、现金流量、金钱的时间价值、规划期限、通货膨胀、折旧、重置和退休决定);非营利性决策(成本效益分析、优化分析);评估、经济风险和不确定性(评估技术、风险和不确定性下的决策);以及多属性决策(值和度量尺度、补偿和非补偿技术)。
  • 计算基础(Computing Foundations)
    计算基础KA涵盖了为软件工程实践提供必要的计算背景的基本主题。主题包括问题解决技术、抽象、算法和复杂性、编程基础、并行和分布式计算的基础、计算机组织、操作系统和网络通信。
  • 数学基础(Mathematical Foundations)
    数学基础KA涵盖了为软件工程实践提供必要数学背景的基本主题。主题包括集合、关系和函数;基本命题逻辑和谓词逻辑;证明技术;图表和树木;离散型概率;语法和有限状态机;和数论。
  • 工程基础(Engineering Foundations)
    工程基础KA涵盖了为软件工程实践提供必要的工程背景的基本主题。所涵盖的主题包括实证方法和实验技术;统计分析;测量和度量;工程设计;仿真和建模;以及根本原因分析。

五、CMMI的五个级别

CMMI全称是Capability Maturity Model Integration,即软件能力成熟度模型集成模型。分为5个级别,25个过程域(Process Area,PA)。

初始级(Initial)

软件过程是无序的,有时甚至是混乱的,对过程几乎没有定义,成功取决于个人努力。管理是反应式的。

可重复级/受管理级(Repeatable)

建立了基本的项目管理过程来跟踪费用、进度和功能特性。制定了必要的过程纪律,能重复早先类似应用项目取得的成功经验。

共7个过程域:
1)需求管理 Requrements Management
2)项目规划 Project Planing
3)项目跟踪和控制 Project Monitoring and Control
4)供应商协议管理 Supplier Agreement Management
5)度量与分析 Measurement and Analysis
6)过程与产品质量保证 Process and Product Quality Assurance
7)配置管理 Configuration Management

已定义级(Defined)

已将软件管理和工程两方面的过程文档化、标准化,并综合成该组织的标准软件过程。所有项目均使用经批准、剪裁的标准软件过程来开发和维护软件,软件产品的生产在整个软件过程是可见的。

共14个过程域:
1)需求开发 Requirements Development
2)技术解决方案 Techical Solution
3)产品集成 Product Integration
4)验证 Verification
5)确认 Validation
6)组织过程焦点 Organization Process Focus
7)组织过程定义 Organization Process Defintion
8)组织培训 Orgnizational Training
9)集成项目管理 Integrated Project Management
10)风险管理 Risk Management
11)决策分析和解决 DecisionAnalysis and Resolution
12)集成团队 Integrated Teaming
13)集成组织环境 Organizational Environment for Integration
14)集成供应商管理 Integrated Suppliers Management

其中12、13是针对大型软件团队提出的要求,一般情况下中小型软件企业可以不用。14是如果软件企业需要管理大量的供应商,则需要考虑这个PA。

量化管理级(Managed)

分析对软件过程和产品质量的详细度量数据,对软件过程和产品都有定量的理解与控制。管理有一个作出结论的客观依据,管理能够在定量的范围内预测性能。

共2个过程域:
1)组织过程性能 Orgnizational Process Performance
2)量化项目管理 Quantitative Project Management

优化管理级(Optimizing)

过程的量化反馈和先进的新思想、新技术促使过程持续不断改进。

共2个过程域:
1)组织创新及部署 Orgnizational Innovation and Deployment
2)原因分析与决策 Causal Analysis and Resolution

六、用自己语言简述 SWEBok 或 CMMI

CMMI(Capability Maturity Model Integration)即能力成熟度集成模型,起初是美国国防部的一个设想,由工业界、美国政府和卡内基•梅隆大学软件工程研究所率先倡导。他们想把现在所有的以及将被发展出来的各种能力成熟度模型,集成到一个框架中去。

这个框架有两个功能,第一,软件采购方法的改革;第二,建立一种从集成产品与过程发展的角度出发、包含健全的系统开发原则的过程改进。

就软件而言,CMMI是SW-CMM的修订本。它兼收了SW-CMM 2.0版C稿草案和SPA中更合理、更科学和更周密的优点。

CMMI项目更为工业界和政府部门提供了一个集成的产品集,其主要目的是消除不同模型之间的不一致和重复,降低基于模型改善的成本。CMMI将以更加系统和一致的框架来指导组织改善软件过程,提高产品和服务的开发、获取和维护能力。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值