软件系统分析与设计(一)

系统分析与设计 作业一

软件工程的定义

软件工程“有很多版本的定义,比如

  • BarryBoehm:运用现代科学技术知识来设计并构造计算机程序及为开发、运行和维护这些程序所必需的相关文件资料。

  • IEEE:在软件工程术语汇编中的定义:软件工程是:1.将系统化的、严格约束的、可量化的方法应用于软件的开发、运行和维护,即将工程化应用于软件;2.在1中所述方法的研究

  • FritzBauer(在NATO会议上给出的定义):建立并使用完善的工程化原则,以较经济的手段获得能在实际机器上有效运行的可靠软件的一系列方法。

  • 《计算机科学技术百科全书》:软件工程是应用计算机科学、数学、逻辑学及管理科学等原理,开发软件的工程。软件工程借鉴传统工程的原则、方法,以提高质量、降低成本和改进算法。其中,计算机科学、数学用于构建模型与算法,工程科学用于制定规范、设计范型(paradigm)、评估成本及确定权衡,管理科学用于计划、资源、质量、成本等管理。

最新的定义是(摘录维基百科)

GB/T11457-2006《信息技术 软件工程术语》中将其定义为”应用计算机科学理论和技术以及工程管理原则和方法,按预算和进度,实现满足用户要求的软件产品的定义、开发、和维护的工程或进行研究的学科。

软件危机 (software crisis)

软件危机泛指在计算机软件的开发和维护过程中所遇到的一系列严重问题。

本质原因

  • 用户需求不明确

    在软件开发过程中,用户需求不明确问题主要体现在四个方面:

    在软件开发出来之前,用户自己也不清楚软件开发的具体需求;

    用户对软件开发需求的描述不精确,可能有遗漏、有二义性、甚至有错误;

    在软件开发过程中,用户还提出修改软件开发功能、界面、支撑环境等方面的要求;

    软件开发人员对用户需求的理解与用户本来愿望有差异。

  • 缺乏正确的理论指导

    缺乏有力的方法学和工具方面的支持。

    由于软件开发不同于大多数其他工业产品,其开发过程是复杂的逻辑思维过程,其产品极大程度地依赖于开发人员高度的智力投入。

    由于过分地依靠程序设计人员在软件开发过程中的技巧和创造性,加剧软件开发产品的个性化,也是发生软件开发危机的一个重要原因。

  • 软件开发规模越来越大

    随着软件开发应用范围的增广,软件开发规模愈来愈大。

    大型软件开发项目需要组织一定的人力共同完成,而多数管理人员缺乏开发大型软件开发系统的经验,而多数软件开发人员又缺乏管理方面的经验。

    各类人员的信息交流不及时、不准确、有时还会产生误解。

    软件开发项目开发人员不能有效地、独立自主地处理大型软件开发的全部关系和各个分支,因此容易产生疏漏和错误。

  • 软件开发复杂度越来越高

    软件开发不仅仅是在规模上快速地发展扩大,而且其复杂性也急剧地增加。

    软件开发产品的特殊性和人类智力的局限性,导致人们无力处理“复杂问题”。

    所谓“复杂问题”的概念是相对的,一旦人们采用先进的组织形式、开发方法和工具提高了软件开发效率和能力,新的、更大的、更复杂的问题又摆在人们的面前。

表现

  • 软件开发进度难以预测

    拖延工期几个月甚至几年的现象并不罕见,这种现象降低了软件开发组织的信誉。

  • 软件开发成本难以控制

    投资一再追加,令人难于置信。往往是实际成本比预算成本高出一个数量级。

    而为了赶进度和节约成本所采取的一些权宜之计又往往损害了软件产品的质量,从而不可避免地会引起用户的不满。

  • 用户对产品功能难以满足

    开发人员和用户之间很难沟通、矛盾很难统一。

    往往是软件开发人员不能真正了解用户的需求,而用户又不了解计算机求解问题的模式和能力,双方无法用共同熟悉的语言进行交流和描述。

    在双方互不充分了解的情况下,就仓促上阵设计系统、匆忙着手编写程序,这种”闭门造车”的开发方式必然导致最终的产品不符合用户的实际需要。

  • 软件产品质量无法保证

    系统中的错误难以消除。

    软件是逻辑产品,质量问题很难以统一的标准度量,因而造成质量控制困难。

    软件产品并不是没有错误,而是盲目检测很难发现错误,而隐藏下来的错误往往是造成重大事故的隐患。

  • 软件产品难以维护

    软件产品本质上是开发人员的代码化的逻辑思维活动,他人难以替代。除非是开发者本人,否则很难及时检测、排除系统故障。

    为使系统适应新的硬件环境,或根据用户的需要在原系统中增加一些新的功能,又有可能增加系统中的错误。

  • 软件缺少适当的文档资料

    文档资料是软件必不可少的重要组成部分。

    实际上,软件的文档资料是开发组织和用户的之间权利和义务的合同书,是系统管理者、总体设计者向开发人员下达的任务书,是系统维护人员的技术指导手册,是用户的操作说明书。

    缺乏必要的文档资料或者文档资料不合格,将给软件开发和维护带来许多严重的困难和问题。

克服软件危机的方法

  • 应用 软件工程学 开发软件

    软件工程诞生于60年代末期,它作为一个新兴的工程学科,主要研究软件生产的客观规律性,建立与系统化软件生产有关的概念、原则、方法、技术和工具,指导和支持软件系统的生产活动,以期达到降低软件生产成本 、改进软件产品质量、提高软件生产率水平的目标。软件工程学从硬件工程和其他人类工程中吸收了许多成功的经验,明确提出了软件生命周期的模型,发展了许多软件开发与维护阶段适用的技术和方法,并应用于软件工程实践,取得良好的效果。

  • 使用 软件工具 解决 软件危机

    在软件开发过程中人们开始研制和使用软件工具,用以辅助进行软件项目管理与技术生产,人们还将软件生命周期各阶段使用的软件工具有机地集合成为一个整体,形成能够连续支持软件开发与维护全过程的集成化软件支援环境,以期从管理和技术两方面解决软件危机问题。

  • 发展新的软件技术

    此外,人工智能与软件工程的结合成为80年代末期活跃的研究领域。基于程序变换、自动生成和可重用软件等软件新技术研究也已取得一定的进展,把程序设计自动化的进程向前推进一步。在软件工程理论的指导下,发达国家已经建立起较为完备的软件工业化生产体系,形成了强大的软件生产能力 。软件标准化与可重用性得到了工业界的高度重视,在避免重用劳动,缓解软件危机方面起到了重要作用。

软件生命周期

软件生命周期(Software Development LifeCycle)是指软件的产生直到成熟的全部过程。

生命周期是事物发展的客观规律,软件同样存在生命周期。早期的软件生命周期往往是说“软件从计划、需求开始,经历分析设计、实现、部署、维护,直到最后逐渐消亡的”。

这是受到了第一个软件生命周期模型—瀑布模型影响,上述语句实质上简要的描述了瀑布型生命周期。

现在的软件生命周期不再只考虑瀑布型生命周期,另外常见的软件生命周期模型有原型模型、螺旋模型、迭代模型。所以现在的软件生命周期说明应当不再包括瀑布型生命周期中的典型阶段

SWEBoK

Software Engineering Body of Knowledge软件工程知识体系

包括以下15个知识领域

  1. 软件要求

    软件要求KA关注软件需求的启发,协商,分析,规范和验证。在软件行业中,人们普遍认为,当这些活动表现不佳时,软件工程项目非常容易受到攻击。软件需求表达了对软件产品的需求和限制,这些需求和约束有助于解决一些现实问题。

  2. 软件设计

    设计被定义为两个限定的体系结构,组件,接口,以及其它的系统或部件的特性的过程中,并[即]过程的结果(IEEE 1991)。软件设计KA涵盖了设计过程和最终产品。软件设计过程是软件工程生命周期活动,其中分析软件需求以产生软件内部结构及其行为的描述,其将作为其构造的基础。软件设计(结果)必须描述软件体系结构 - 即软件如何分解和组织成组件以及这些组件之间的接口。它还必须描述能够构建它们的详细程度的组件。

  3. 软件构建

    软件构建是指通过结合详细设计,编码,单元测试,集成测试,调试和验证来详细创建工作软件。软件构建KA包括与满足其要求和设计约束的软件程序开发相关的主题。该KA涵盖了软件构建基础; 管理软件建设; 建筑技术; 实际考虑; 和软件构建工具。

  4. 软件测试

    测试是一项旨在评估产品质量并通过识别缺陷来改进产品质量的活动。软件测试涉及在有限的测试用例集上针对预期行为动态验证程序的行为。这些测试用例是从(通常非常大的)执行域中选择的。软件测试KA包括软件测试的基础知识; 测试技术; 人机界面测试与评估; 与测试有关的措施; 和实际考虑。

  5. 软件维护

    软件维护包括增强现有功能,调整软件以在新的和修改的操作环境中运行,以及纠正缺陷。这些类别称为完善,自适应和纠正性软件维护。软件维护KA包括软件维护的基础知识(维护的性质和需求,维护类别,维护成本); 软件维护中的关键问题(技术问题,管理问题,维护成本估算,软件维护测量); 维护过程; 软件维护技术(程序理解,重新设计,逆向工程,重构,软件退役); 灾难恢复技术和软件维护工具。

  6. 软件配置管理

    系统的配置是硬件,固件,软件或这些的组合的功能和/或物理特征。它还可以被视为根据特定构建过程组合的特定版本的硬件,固件或软件项的集合,以满足特定目的。因此,软件配置管理(SCM)是在不同时间点识别系统配置的规则,用于系统地控制配置的改变,以及在整个软件生命周期中维持配置的完整性和可追溯性。软件配置管理KA涵盖SCM过程的管理; 软件配置识别,控制,状态核算,审计; 软件发布管理和交付;

  7. 软件工程管理

    软件工程管理涉及规划,协调,测量,报告和控制项目或程序,以确保软件的开发和维护是系统化的,规范化的和量化的。软件工程管理KA涵盖了启动和范围定义(确定和协商要求,可行性分析以及要求的审查和修订); 软件项目计划(过程计划,工作量估算,成本和进度,资源分配,风险分析,质量计划); 软件项目制定(计量,报告和控制;收购和供应商合同管理); 产品验收; 审查和分析项目绩效; 项目结束; 和软件管理工具。

  8. 软件工程过程

    软件工程KA关注软件生命周期过程的定义,实施,评估,测量,管理和改进。涵盖的主题包括流程实施和变更(流程基础架构,流程实施和变更模型以及软件流程管理); 流程定义(软件生命周期模型和流程,流程定义,流程适应和流程自动化的符号); 过程评估模型和方法; 测量(过程测量,产品测量,测量技术和测量结果的质量); 和软件处理工具。

  9. 软件工程模型和方法

    软件工程模型和方法KA解决了涵盖多个生命周期阶段的方法; 其他KAs涵盖特定生命周期阶段的特定方法。涵盖的主题包括建模(软件工程模型的原理和属性;语法与语义与不变量;前置条件,后置条件和不变量); 模型类型(信息,结构和行为模型); 分析(分析正确性,完整性,一致性,质量和相互作用;可追溯性;以及权衡分析); 和软件开发方法(启发式方法,形式方法,原型方法和敏捷方法)。

  10. 软件质量

    软件质量是许多SWEBOK V3 KAs中普遍存在的软件生命周期问题。此外,软件质量KA还包括软件质量的基础知识(软件工程文化,软件质量特性,软件质量的价值和成本以及软件质量改进); 软件质量管理流程(软件质量保证,验证和确认,审核和审核); 和实际考虑(缺陷表征,软件质量测量和软件质量工具)。

  11. 软件工程专业实践

    软件工程专业实践关注软件工程师必须具备的专业,负责和道德的软件工程知识,技能和态度。软件工程专业实践KA涵盖专业性(专业行为,专业协会,软件工程标准,雇佣合同和法律问题); 道德准则; 小组动态(团队合作,认知问题复杂性,与利益相关者互动,处理不确定性和模糊性,处理多元文化环境); 和沟通技巧。

  12. 软件工程经济学

    软件工程经济学KA关注的是在业务环境中做出决策,以使技术决策与组织的业务目标保持一致。涵盖的主题包括软件工程经济学的基本原理(提案,现金流量,货币时间价值,计划视野,通货膨胀,折旧,替代和退休决策); 非营利性决策(成本效益分析,优化分析); 估计,经济风险和不确定性(估算技术,风险决策和不确定性); 和多属性决策(价值和衡量尺度,补偿和非补偿技术)。

  13. 计算基础

    计算基础KA涵盖了提供软件工程实践所需的计算背景的基础主题。涵盖的主题包括问题解决技术,抽象,算法和复杂性,编程基础,并行和分布式计算的基础知识,计算机组织,操作系统和网络通信。

  14. 数学基础

    数学基础KA涵盖了提供软件工程实践所必需的数学背景的基础主题。涵盖的主题包括集合,关系和功能; 基本命题和谓词逻辑; 证明技术; 图形和树木; 离散概率; 语法和有限状态机; 和数论。

  15. 工程基础

    工程基础KA涵盖了提供软件工程实践所必需的工程背景的基础主题。涵盖的主题包括经验方法和实验技术; 统计分析; 测量和指标; 工程设计; 仿真与建模; 和根本原因分析。

CMMI

Capability Maturity Model Integration能力成熟度模型集成

包括以下五个级别

1. Level 1 - Initial 初始级

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

2.Level 2 - Repeatable 记录级

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

3. Level 3 - Defined 规格化级

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

4. Level 4 - Managed (Capable) 量化管理级

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

5. Level 5 - Optimizing (Efficient) 优化管理级

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

总结CMMI

CMMI是一个可用于指导项目,部门或整个组织的流程改进 的评价标准。

关于CMMI所达到的目标,第一个是质量,第二个是时间表,第三就是要用最低的成本。

不过特别强调的是,CMMI不是传统的、仅局限于软件开发的生命周期,它应该被运用于更广泛的一个范畴——工程设计的生命周期。

CMMI究竟是什么呢?它并不是一个过程,也不是告诉你怎么去做一件事情。如果用一句话来概括什么是CMMI,它就是各个进程的一个关键的元素,在很多领域里面一个集成的点。它是这样的一个基本架构,能够用来度量你的有效性和实用性;能够找出这样的一些机会,继续改进的机会,包括在商业目标、策略还有降低项目的风险等方面。

CMMI对于中小型企业比SWEBoK更具指导意义!

参考资料

维基百科

百度百科

感谢资助辣条吃!