软件开发过程与项目管理期末复习(持续更新)

本文用来记录对软件开发过程与项目管理这门课的期末复习

软件开发过程与项目管理

概述

1.软件的基本概念

 软件(Software):一组对象或项目所形成的一个“配置”,由程序、文档和数据等部分构成。
– 程序(program):可被计算机硬件理解并执行的一组指令,提供期望的功能和性能
– 数据(data structure):程序能正常操纵信息的数据结构
– 文档(document):与程序开发、维护和使用有关的图文材料

软件的四大特征: 复杂性 不可见性 易变形 一致性

– 软件必须不断的变化以适应新的计算环境或新技术的发展
– 软件必须通过不断的功能增强以实现新的业务需求
– 软件必须通过扩展以与其他软件系统进行互操作
– 软件必须被不断的重构以使其生命周期得以延续

软件的分类

软件及其开发方式的发展
1.结构化方法
2.面向对象的方法
3.构件化方法
4.面向服务的体系结构SOA方法,基于Internet与云计算的软件开发方法

2.软件工程的基本概念

软件危机(Software Crisis):计算机软件的开发和维护过程所遇到的一系列严重问题
软件危机的表现:
– 对软件开发成本和进度的估算很不准确,甚至严重拖期和超出预算
– 无法满足用户需求,导致用户很不满意
– 质量很不可靠,经常失效
– 难以更改、调试和增强
– 没有标准、完整的文档
– 软件成本严重上升
– 软件开发生产率跟不上计算机应用迅速发展的趋势

软件神话(software myths):
关于软件及其开发过程被人盲目相信的一些说法
– 影响到几乎所有的角色:管理者、顾客、其他非技术性的角色、具
体的技术人员
– 看起来是事实的合理描述(有时的确包含真实的成分)、符合直觉,
并经常被拿来做宣传
– 实际上误导了管理者和技术人员对软件开发的态度,从而引发了严
重的问题

软件工程的概念
– 软件开发过程(分析、设计、实现、测试、运行、维护)
– 软件开发中应遵循的原则和管理技术
– 软件开发中所采用的技术和工具
– 满足用户需求
– 按时交付
– 控制成本
– 高质量
软件工程知识体系
(1)软件开发方法学
(2)软件工程与软件工程环境
(3)软件过程
(4)软件工程管理
(5)软件质量特性

3.软件工程工具:CASE工具

在这里插入图片描述

软件工程核心思想

1.软件工程的本质:不同抽象层次之间的映射与转换

单步映射和多步映射
概念映射和业务逻辑映射
在这里插入图片描述

2.软件工程所关注的目标

 产品:各个抽象层次的产出物
 过程:在各个抽象层次之间进行映射与转换
 软件工程具有“产品与过程二相性”的特点,必须把二者结合起来去考虑,而不能忽略其中任何一方

 功能性需求(Functional Requirements):软件所实现的功能达到它的设计规范和满足用户需求的程度
 非功能性需求(Non-Functional Requirements):系统能够完成所期望的工作的性能与质量

3.软件开发中的多角色

在这里插入图片描述

4.软件工程=最佳实践

 软件系统的复杂性、动态性使得:
– 高深的软件理论在软件开发中变得无用武之地
– 即使应用理论方法来解决,得到的结果也往往难以与现实保持一致
 因此,软件工程被看作一种实践的艺术:
– 做过越多的软件项目,犯的错误就越少,积累的经验越多,承接项目的成功率就越高
– 对新手来说,要通过多实践、多犯错来积累经验,也要多吸收他人的失败与教训与成功的经验
——当你把所有的错误都犯过之后,你就是正确的了!

5.软件工程的四个核心理论概念

(1)分而治之
(2)复用
(3)折中
(4)演化

软件过程模型

1.软件过程

软件生命周期
在这里插入图片描述
软件过程的典型阶段
 Dream(提出设想)
 Investigation(深入调研)
 Software Specification(需求规格说明)
 Software Design(软件设计)
 Software Implementation(软件实现)
 Software Deployment (软件部署)
 Software Validation(软件验证)
 Software Evolution(软件演化)
软件过程的实质
在这里插入图片描述

2.典型软件过程模型

预测型过程模型
–项目开发活动通常按照固定顺序执行,前一步活动结果是后一步活动的“蓝图”,前一步对后一步结果的预期约束十分精准
– 需要提前进行大量的计划工作,然后一次性执行,执行过程是一个连续的过程
– 瀑布模型 (Waterfall)、V模型(V Model)、W模型(W Model)形式化过程 (Formal model)

迭代过程模型
– 允许对未完成的工作进行反馈,可以进行修改和改进
– 允许对部分已经完成的工作进行反馈,从而进行修改和改进
– 逐步反馈、改进完善,直至开发完成
– 螺旋模型 (Spiral)、原型模型 (Prototype)
增量过程模型
– 将未来系统分阶段完成,每个阶段都会产生一个可交付成果
– 每个阶段成果都是一个增量
– 每个增量都是一个独立的开发过程,包括分析、设计、实现、测试、交付
– 增量模型 (Incremental)、快速应用开发(RAD)
在这里插入图片描述

敏捷过程模型
– 应对变化、增量开发、快速反馈、快速迭代、快速交付
– 基于迭代的敏捷过程:每次迭代,都是针对最重要的系统功能,团队合作开发
– 基于流程的敏捷过程:不是按照迭代计划,而是根据团队能力,领取任务,恒速开发
– XP、Scrum、Kanban、DevOps等

典型模型
瀑布模型
上一个阶段结束,下一个阶段才能开始
 每个阶段均有里程碑和提交物
 上一阶段输出是下一阶段输入
 每个阶段均需要进行V&V
 侧重于文档与产出物
在这里插入图片描述
在这里插入图片描述
V模型
在这里插入图片描述

优点——开发过程重视测试/验证
– 简单易用,只要按照规定的步骤执行即可
– 强调测试或验证与开发过程的对应性和并行性; 测试方案在编码之前就已经制定了
– 与瀑布模型相比,项目开发成功的机会更高
– 避免缺陷向下游流动
 缺点
– 比瀑布模型繁琐

迭代过程模型
在这里插入图片描述
在这里插入图片描述
螺旋模型
在这里插入图片描述
在这里插入图片描述

增量模型
在这里插入图片描述本质:以迭代的方式运用瀑布模型

 优点:
– 在时间要求较高的情况下交付产品:在各个阶段并不交付一个可运行的完整产品,而是交付满足客户需求的一个子集的可运行产品,对客户起到“镇静剂”的作用
– 人员分配灵活:如果找不到足够的开发人员,可采用增量模型:早期的增量由少量人员实现,如果客户反馈较好,则在下一个增量中投入更多的人力
– 逐步增加产品功能可以使用户有较充裕的时间来学习和适应新产品,避免全新软件可能带来的冲击
– 因为具有较高优先权的模块被首先交付,而后面的增量也不断被集成进来,这使得最重要的功能肯定接受了最多的测试,从而使得项目总体性失败的风险比较低

 困难:
– 每个附加的增量并入现有软件时,必须不破坏原来已构造好的部分
– 同时,加入新增量时应简单、方便 ——该类软件的体系结构应当是开放的
– 仍然无法处理需求发生变更的情况
– 管理人员必须有足够的技术能力来协调好各增量之间的关系

RAD模型
在这里插入图片描述

 快速应用开发RAD (Rapid Application Development)
– 侧重于短开发周期(一般为60~90天)的增量过程模型,是瀑布模型的高速变体,通过基于构件的构建方法实现快速开发
– 多个团队并行进行开发,但启动时间有先后,先启动团队的提交物将作为后启动团队的输入
 缺点:
– 需要大量的人力资源来创建多个相对独立的RAD团队
– 如果没有在短时间内为急速完成整个系统做好准备,RAD项目将会
失败
– 如果系统不能被合理的模块化,RAD将会带来很多问题
– 技术风险很高的情况下(采用很多新技术、软件需与其他已有软件建立集成等等),不宜采用RAD

敏捷方法与过程

1.敏捷过程模型

在这里插入图片描述

2.极限编程(XP)

3.Scrum

在这里插入图片描述

4.与传统开发过程模型的对比

在这里插入图片描述

软件演化与配置管理

1.软件演化

软件演化的Lehman定律
(1)持续变化
(2)复杂度逐渐增大
软件演化的处理策略
 软件维护(Software Maintenance)
– 为了修改软件缺陷或增加新的功能而对软件进行的变更
– 软件变更通常发生在局部,不会改变整个结构
 软件再工程(Software Re-engineering)
– 为了避免软件退化而对软件的一部分进行重新设计、编码和测试,提高软件的可维护性和可靠性等
 前者比后者的力度要小

2.软件维护

软件维护的类型
 纠错性维护:修改软件中的缺陷或不足
 适应性维护:修改软件使其适应不同的操作环境,包括硬件变化、操
作系统变化或者其他支持软件变化等
 完善性维护:增加或修改系统的功能,使其适应业务的变化
 预防性维护:为减少或避免以后可能需要的前三类维护而提前对软件
进行的修改工作在这里插入图片描述
软件维护的内容
数据 程序 硬件

3.软件配置管理(SCM)

在这里插入图片描述
SCM的基本元素
 配置项(Configuration Item, CI)
 基线(Baseline)
 配置管理数据库(CMDB)
 最终硬件库(Definitive Hardware Store, DHS)
 最终软件库(Definitive Software Library, DSL)

4.持续集成

持续集成:敏捷开发的一项重要实践
– Martin Fowler:团队开发成员经常集成他们的工作,每个成员每天
至少集成一次,每天可能会发生多次集成;每次集成都通过自动化
的构建(包括编译,发布,自动化测试)来验证,从而尽快地发现集
成错误,大大减少集成的问题,让团队能够更快的开发内聚的软件
 价值:
– 减少风险:不是等到最后再做集成测试,而是每天都做
– 减少重复过程:通过自动化来实现
– 任何时间、任何地点生成可部署的软件
– 增强项目的可见性
– 建立团队对开发产品的信心
持续集成
 所有的开发人员需要在本地机器上做本地构建,然后再提交到版本控
制库中,从而确保他们的变更不会导致持续集成失败
 开发人员每天至少向版本控制库中提交一次代码
 开发人员每天至少需要从版本控制库中更新一次代码到本地机器
 需要有专门的集成服务器来执行集成构建,每天要执行多次构建
 每次构建都要100%通过
 每次构建都可以生成可发布的产品
 修复失败的构建是优先级最高的事情

5.git

github

软件项目管理

1.个人/开发团队管理

2.开发任务分解

3.开发成本及工作量核算

成本估算方法

  1. 代码行估算法
    就是按照代码的行数来估算成本
  2. 功能点估算法

在这里插入图片描述
UFC = 不同复杂度的功能点的个数乘以权值的和
TCF = 0.65+0.01*sum(系数)
要是计算工时的话,还得再乘以 开发生产率PE
在这里插入图片描述

  1. 用例点估算法
    步骤:
    计算未调整的角色权值UAW
    计算未调整的用例权值UUCW
    计算未调整的用例点UUCP UUCP = UAW + UUCW
    计算技术复杂度因子TCF TCF = 0.6 + ( 0.01×∑i=1 to 13 TCF_Weighti×Valuei)
    在这里插入图片描述

计算环境复杂度因子ECF ECF = 1.4 + ( -0.03×∑i=1 to 8 ECF_Weighti×Valuei)
在这里插入图片描述

计算调整的用例点UCP UCP = UUCP × TCF × ECF
计算工作量Effort 项目工作量Effort = UCP × PE

4.类比估算法
估算人员根据以往的完成类似项目所消耗的总成本(或工作
量),来推算将要开发的软件的总成本(或工作量)
类比估算 — 适用情况
 有类似的历史项目数据
 信息不足(例如市场招标)的时候
 要求不是非常精确估算的时候
<例子>
在这里插入图片描述
在这里插入图片描述

  1. 自下而上估算法

  2. 三点估算法
    在这里插入图片描述
    在这里插入图片描述

  3. 专家估算法

4.开发计划及进程管理

进度计划

在这里插入图片描述
历时估算计算方法:
 定额估算法
在这里插入图片描述

 经验导出模型
在这里插入图片描述

 CPM(关键路径法估计)
ADM PDM
在这里插入图片描述
在这里插入图片描述
正推法 逆推法
ES EF LS LF TF FF CP
 类比估算
 专家判断
 基于承诺的估计

团队计划

在这里插入图片描述
软件开发团队的组织方式:
窝蜂模式
主治医师模式
明星模式
社区模式
交响乐团模式
爵士乐模式
功能团队模式
官僚模式
组织结构的主要类型
 职能型
 项目型
 矩阵型

敏捷团队

补充

软件开发过程
软件的特性:复杂性 不可见性 易变形 一致性
软件及其开发方法的发展
结构化方法 面向对象的方法 构件化方法 敏捷开发方法

面向服务的体系结构SOA 方法 基于Internet与云计算的软件开发方法 ?

软件工程的本质:不同抽象层次之间的映射与转换。概念映射 业务逻辑映射
用严格的规范和管理手段来缩小偏差,通过牺牲“时间”来提高“质量”

软件工程所关注的目标:产品和过程 产品与过程的二相性
功能性需求:软件所实现的功能达到它的设计规范和满足用户需求的程度。
完备性 正确性 可靠性 健壮性
非功能性需求:系统能够完成所期望的工作的性能与质量
软件工程 = 最佳实践
软件工程的四大核心理论概念:分而治之 复用 折中 演化

软件过程模型的分类
预测型 瀑布模型 V模型 W模型
迭代型 螺旋模型 制定计划 风险分析 实施工程 客户评估 原型模型
增量型 增量模型 RAD(基于构件的开发方法)
敏捷型 XP 计划阶段 设计阶段 编码与测试阶段 结对编程
scrum sprint
固定节奏、小步快跑、及时反馈、应对变化、快速交付 以快速的增量和
迭代方式进行软件开发
形式化过程模型 面向复用的软件过程

软件项目管理:
任务分解 传统 WBS 全部需求 敏捷 Story Map 渐进式需求
工作分解结构WBS

成本估算:
功能点估算法 EO EI EQ ILF EIF 计算出UFC
TCF=0.65+0.01sum
FP=UFC
TCF

用例点估算法
UAW + UUCW =UUCP
TCF=0.6+0.01sum
ECF=1.4+(-0.03
sum)
UCP=UUCPTCFECF

PE是效率

类比估算:
算两个项目的distance 分母是最大减最小

自下而上估算法

三点估算法
CM最可能 CO最乐观 CP最悲观
CE=f(CO,CM,CP)
三角分布 求平均 (1+1+1)/3
贝塔分布 1+4+1/6

专家估算 贝塔分布

Story Point 估算方法
快速故事点估算
计划扑克估算

 传统估算 — 绝对值估算
 敏捷估算 — 相对值估算

进度计划

定额估算法
经验导出模型
D=a*E^b

关键路径法
正推法 逆推法

团队计划:
OBS

软件演化

在这里插入图片描述

软件维护

在这里插入图片描述

软件配置管理

在这里插入图片描述

持续集成

持续集成:敏捷开发的一项重要实践

  • 1
    点赞
  • 6
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 1
    评论

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

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

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

@业精于勤荒于嬉

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值