系统分析与设计Homework1

1.

软件工程的定义:

系统化的规范的可度量的方法用于软件的开发、运行和维护的过程,即将工程化应用于软件开发中。

阅读经典名著“人月神话”等资料,解释 software crisis、COCOMO 模型。

    软件危机(Software Crisis)是早期计算机科学的一个术语,是指在软件开发及维护的过程中所遇到的一系列严重问题,这些问题皆可能导致软件产品的寿命缩短、甚至夭折。软件开发是一项高难度、高风险的活动,由于它的高失败率,故有所谓“软件危机”之说。软件危机的本源是复杂、期望和改变。这个术语用来描述正急遽增加之电脑的力量带来的冲击和可能要处理的问题的复杂性。从本质上来说,它谈到了写出正确、可理解、可验证的计算机程序的困难。

    在《人月神话》中作者谈论到大型软件开发的成本随着规模指数性增加,在缺乏一定的方法论的情况下开发大型软件可能会导致难以预料的后果,可能导致软件极端复杂,难以按时交付,bug百出等情况,而加入更多的人力往往是火上浇油,非但不能使开发难度下降,还可能会让进度变得更加延后。

    构造性成本模型(Constructive Cost Model)最初发表于1981年巴里·勃姆《软件工程经济学》一书中,做为一种在软件项中估算工作量、成本以及时间表的模型。构造性成本模型由三个不断深入和详细的层次组成。第一层,“基本COCOMO”,适用对软件开发进行快速、早期地对重要的方面进行粗略的成本估计,但因其缺少不同的项目属性(“成本驱动者”)的因素,所以准确性有一定的局限性。“中级COCOMO”中考虑进了这些成本驱动者。“详细COCOMO”加入了对不同软件开发阶段影响的考量。

软件生命周期。

    软件生命周期又称为软件生存周期或系统开发生命周期,是软件的产生直到报废的生命周期,周期内有问题定义、可行性分析、总体描述、系统设计、编码、调试和测试、验收与运行、维护升级到废弃等阶段,这种按时间分程的思想方法是软件工程中的一种思想原则,即按部就班、逐步推进,每个阶段都要有定义、工作、审查、形成文档以供交流或备查,以提高软件的质量。

    软件生命周期存在多种模型,如瀑布模型,快速原型模型,螺旋模型等。

按照 SWEBok 的 KA 划分,本课程关注哪些 KA 或 知识领域?


解释 CMMI 的五个级别。例如:Level 1 - Initial:无序,自发生产模式

1. 初始级Level 1 - Initial
软件过程是无序的,有时甚至是混乱的,对过程几乎没有定义,成功取决于个人努力。管理是反应式的。
2.可管理级 Level 2 - Managed
建立了基本的项目管理过程来跟踪费用、进度和功能特性。制定了必要的过程纪律,能重复早先类似应用项目取得的成功经验。
3. 已定义级  Level 3 - Defined
已将软件管理和工程两方面的过程文档化、标准化,并综合成该组织的标准软件过程。所有项目均使用经批准、剪裁的标准软件过程来开发和维护软件,软件产品的生产在整个软件过程是可见的。
4. 量化管理级Level 4 - Quantitatively Managed
分析对软件过程和产品质量的详细度量数据,对软件过程和产品都有定量的理解与控制。管理有一个作出结论的客观依据,管理能够在定量的范围内预测性能。
5. 优化管理级Level 5 - Optimizing
过程的量化反馈和先进的新思想、新技术促使过程持续不断改进。

用自己语言简述 SWEBok 或 CMMI (约200字)

SWEBok是一个国际标准,它将软件工程所需的知识分成了多个KA(即知识领域),它提供了以一种基本的引导,描述了在软件工程中需要掌握的知识主体是什么。以下几个KA与我们的课程相关联:

Software requirements,软件需求,探知用户需要软件去做什么,有什么需求要得到满足。

Software design,软件设计,考虑软件的健壮性,易用性,正确性等要求。

Software quality,软件质量,考虑软件是否满足用户的功能需求和性能需求。

Software engineering models and methods,考虑软件工程中采用的模型和方法论,用什么样的思想知道软件开发。

SWEBok为软件工程人员刻画了一副知识的蓝图,告诉开发人员他们需要学习那些方面的知识,哪里还有欠缺,对新手开发人员有指导意义。同时SWEBok作为一个国际标准,也并非一成不变,现在SWEBok已经是version 3,因为软件工程本身也是一个知识飞速增加的领域,所以SWEBok的KA也在增加。



2、解释 PSP 各项指标及技能要求

PSP2.1
 

Planning

·         Estimate

Development

·         Analysis

·         Design Spec

·         Design Review

·         Coding Standard

·         Design

·         Coding

·         Code Review

·         Test

 

 

Record Time Spent

Test Report

Size Measurement

Postmortem

Process Improvement Plan

计划

·         估计这个任务需要多少时间

开发

·         分析需求

·         生成设计文档

·         设计复审 (和同事审核设计文档)

·         代码规范 (为目前的开发制定合适的规范)

·         具体设计

·         具体编码

·         代码复审

·         测试(包括自我测试,修改代码,提交修改)



记录时间花费

测试报告

计算工作量

事后总结

提出过程改进计划


要统计每个阶段的时间要使用有效时间,比如写程序写了两天不能把48小时全算进去,要计算确实在工作的时间,可以使用计算机上自带的计时器进行计时,需要注意一些阶段并不是连续的,比如测试,测试可能和具体的Coding工作是同时展开,需要具体进行区分。
  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值