软件设计师备考笔记(十一)系统开发基础(McCabe复杂度、CMMI、项目管理)

目录

  • 软件测试

  • 系统运行与维护

  • 软件过程改进

  • 项目管理

软件测试

McCabe复杂度

  • 每次都考一题

原则

  • 假设一张图中有向边为m条,然后由n个结点,用m-n+2就能得到整个图的环路复杂度;

  • 防止记错的方法:下图的环路复杂度为1,2-+2=1;

画法的分歧

* 一个图转为箭线图的时候都是将语句和判断抽象为结点,

  * 语句抽象为方框(1号)

  * 判断抽象位棱形(2号)

* 但是对于 或运算 是否要抽象为一个结点存在分歧

  * 实际上不管有没结点都不影响环路复杂度;

* 如果不抽象交点,那么234都连接到7上;

系统运行和维护

可维护性:

系统由什么缺陷,对进行相关调整,设计编码;

易分析性:编码规范

易改变性:修改一段代码的容易程度;耦合性要低;

维护类型:

改正性维护(正确性维护):软件开发后总有瑕疵,总有bug用户用的时候才发现,这个时候马上修改就叫改正性维护

适应性维护:软件原本运行在win2000上,现在升级到2008;软件可能由于改变了环境,运行不正常,正对这些修改叫做适应性维护;还有其他环境隐藏性更高等,如适应数据环境;

完善性维护:系统运行中,很多东西发生了改变;要扩充功能,改善性能;

企业为了适应外部市场环境和管理需求提出新需求也是适应性维护;(软件硬件需要适应的情况都是适应性维护)

预防性维护:现在不维护不会有问题,但将来可能导致问题;闲时把需要维护的模块重构、文档方面的健全工作;以后维护就更方便了;

预防性维护可能转为其他维护:在99年IT领域最多的问题千年虫问题;当时记录的年份都是只记录后两位;97、98等;但当2000年后,00年默认表示i1900年;对于金融领域等会造成重大影响;提前看到这个问题修改好就叫预防性;如果00年了才发现那就是适应性维护;

软件过程改进-CMMI

  • CMMI由CMM(能力成熟度模型)发展而来,CMM用来衡量软件开发的成熟度,即软件开发商改变软件质量的能力;

    • 但CMM局限性太大,进行了扩充;

    • CMMI属于CMM的集成,分了多个方面多个侧面;许多东西还是从CMM传承下来的;

  • CMMI:定义了组织能力的成熟度阶段的标准

    • 成熟度:其实指做事方法问题;看你人是否成熟,如果成熟那么做事一般也靠谱;

阶段式

  • 阶段式和CMM类似

  • CMM多了一个1级

    • 1级:混乱级别(没评价就是混乱级)
  • 已管理级:最为粗浅;

    • 做过同类项目时能借鉴和传承经验;

    • 仅在项目经理级别,换个经理就没了;

  • 已定义级:到了组织级别:

    • 公司有组织过程资产,做项目时公司有模板规范等能给我指导;

    • 某些东西不好用,可以修改到资产里面,其他项目经理来了也能收到帮助;

    • 知识分显性和隐性,已定义级就是把隐性知识转为显性;

    • 已经有了文档化,标准化;

  • 定量管理级:强调量化;

  • 优化级:持续优化;

连续式

  • 对于很多企业而言提升自身能力而言是更好的选择;

    • 阶段式规定了很多内容,但是不同企业有不同情况,阶段式定义的东西很多用不上;

    • 连续式就是列出很多过程域,让企业自己选择,需要加强什么就提升什么;

  • 阶段式优势:有个评判标准,招标的时候有依据;

题外话:实际往往达不到理论

  • 题外话(论文中能结合行业现状评判,更有深度;大环境不支持这么完美的过程;)

  • 但是国内比较急功近利,最求结果,很多企业有很高级别但是没有相关能力;

    • 为考证而去;拿到证之后不按上面来,觉得会提高成本,

    • 但其实CMMI就是为了降低成本提出的,之所以觉得提高成本,实际上是没有用好,认识不够深入;

    • CMMI是一个庞大的体系,要用好需要很长时间训练,所以很多人刚开始觉得不行就不行了;

项目管理

  • 分值比较低:1-2分;但是体系非常大,不细讲;

  • 时间管理和风险管理是重头戏

时间管理

  • 考点:Gantt图和PERT图:

gantt图

  • 用图的形式展示进度安排情况;

  • 特点,图简介明了,能通过图直观看到计划是咋样的;实际情况和进度都能直接表达;

  • 缺点:无法表达任务的逻辑关系;(谁先做)

PERT图:

  • 下图中就是PERT图;最长路径对应项目周期;

  • 考法:计算相关量;

  • 例子:计算事件6最晚开始时间:

    • 先正推求出最早开始时间;

    • 再逆推所有最晚开始时间

  • 注意事项:因为9号是最后一个事件,所以最迟开始事件和最早开始时间相同。

风险管理

  • 项目风险:预期项目经费不准确

  • 技术风险:技术因素导致的,不熟悉技术、技术太新/旧

  • 商业风险:不是项目组内部管理问题了;市场风险等,很可能市场不需要这样的产品;

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值