前言:大三课程所学总结,同时日后以此为蓝本在实际开发中规范化开发。
问题定义
可行性研究
需求分析
总体设计
详细设计
编码和单元测试
综合测试
软件维护
在了解问题定义之后,将其模型抽离出来,然后对其进行可行性分析,探索若干种解法,对每种解法仔细研究其可行性,从下面几种方面来考虑
必要时还有从法律和社会效益来研究其可行性。
系统流程图
数据流图
成本/效益分析
成本估计的几种方法
成本/效益分析的方法
F=P(1+n)^n (P 元钱在 n 年后的价值)
与用户沟通获取需求的方法
根据结构化分析准则,需求分析过程应该建立三种模型,它们分别是?以及他们所用到的工具?
其他的工具还有
软件工程所使用的方法可划分为下面三种
总体设计又称之为概要设计、初步设计
由哪两阶段组成呢?
设计原理
模块是由边界元素限定的相邻程序元素(数据说明,可执行的语句)的序列,而且有一个总体标识符代表它
模块之间的独立程度有两个标准来度量,分别是:
耦合:度量模块间的互相依赖程度
内聚:度量模块内部元素间的结合程度
尽量使用数据耦合,少用控制耦合和特征耦合,限制公共环境耦合的范围,完全不用内容耦合
7 种内聚优劣评分:功能内聚(10 分)偶然内聚(0 分)
描绘软件结构的图形工具
面向数据流的设计方法
概念:面向数据流的设计方法就是把信息流映射成软件结构,同时信息流的结构决定了映射的方法
结构程序设计
只用 3 种控制结构就能实现任何单入口单出口的程序,这三种结构分别是顺序结构、选择结构、循环结构
人机界面设计的设计问题有:
人机界面设计的设计指南:
过程设计的工具【重要】
面向数据结构的设计方法
两个最著名的方法为:Jackson 方法和 Warnier 方法
Jackson 方法
只有顺序、选择、重复三种结构
要会用伪代码表示
程序复杂程度的定量度量有 McCabe 方法和 Halstead 方法,只介绍前者
实现 = 编码 + 调试
实际过程中,调试所花费的时间远大于编码的时间
由三部分组成:分析,设计,实现
本章节探讨的是实际软件项目管理的相关工作,软件项目管理是软件项目一经启动就开始实施的一系列工作,其首先需要探讨的就是软件项目的相关估算,具体的有软件规模的估算、工作量的估算和完成项目估算,由上述的估算再对其进行制定一套完整的进度计划方案和人员组织方案,在整个项目过程中,还需要动态的软件配置管理,最后还介绍了软件质量的保证和软件能力成熟度模型这两个软件完成收尾的相关概念。
作者想要解决软件危机相关问题,具体而言就印证“后人哀之而不鉴之,亦是后人而复哀后人也”这句古话,所以一套系统的软件项目管理出来了。
估算软件规模有两种方法:代码行估算和功能点估算
代码行技术就是利用代码的行数来进行估算的,会根据几个有经验的工作者利用一个公式来进行估算(最小可能的规模+最大可能的规模+最可能的规模)/6,得到的结果有两种,第一种是规模小的时候,单位行,第二种是规模大的时候,单位是千行。
功能点技术就比较复杂了,它涉及到五个相关信息域特征的概念,分别是输入项数,输出项数,查询项数,主文件数,外部接口项数,再利用一系列步骤公式得到这个软件的功能点估算,最后得到的是功能点数 FP。
具体可以参考:功能点估算法 | MBA 智库
估算工作量有三种方法
构造的函数模型的有静态单变量模型、动态多变量模型、COCOMO2 模型这三种模型,得到的结果单位是人月(pm)。
静态单变量是基于上一个估算软件规模得出的代码行/功能点结果这一个变量函数,有一些相应的前人总结的公式
多变量模型,顾名思义,多个变量不止一个变量,有项目持续时间,特殊技术因子,生产率参数,也有相应的函数,可以去查查。
COCOMO2 模型 略、
估算开发时间
利用上一步骤得到的所估算的工作量,有一系列模型将工作量的值带进去就会得到相应的开发时间值。书中介绍了 Walston_Felix、原始的 COCOMO 模型、COCOMO2 模型、Putnam 模型。
得到开发时间,然后就是根据人员人员数量的资源来自定计划,有两种可视化方法:
第一种就是Gantt 图:典型的异于流水作业的一种方法,动态调配人员来完成工作
第二种就是工程网络:用箭头和圆圈来表示整个项目流程,优于 Gantt 图的就是能够实际根据实际项目中的潜力任务来跟踪观察,具体说就是有些任务可能在实际过程中,用原先指定的时间或人员不一定能高效完成,逾期或是提前很久完成等等这种情况。
工程网络功能可以估算工程的进度,在工程网络里面加上一些时间数字,可以灵活地查看并计算工程的计划时间。
工程网络还可以计算出机动时间。
其实在实际过程中,这两种方法都是并用的。
人员组织在所经历的阶段中,经过多次变革,书中介绍有,最初的民主制程序员组 👉 主程序员
组 👉 现代程序员组
只介绍现代程序员组,其实这个在历史中也分两种,第一种是根据职能不同分成两个组长,这种方式不能根治这过程中的软件危机,不详细讲述,第二种就是现在常说的项目经理管理下调配的,项目经理管多个组长,各个组长管理下面的多个程序员,并且,在组长与组长之间可以进行该层的交流,程序员层也一样,但是项目经理就是在该项目中的天花板了,没人管得了……
这三个就是项目管理过程中一些概念之类的,其中软件配置管理讲究动态二字,因为随着时间抑或是用户需求的推移,软件配置势必会改变,这时候就需要即时更新相应配置
后两者是对软件完成的收尾相关工作了。
评论区