目录
软件开发工程——软件开发模型
软件开发工程——软件开发模型——瀑布模型(SDLC)
瀑布模型(Waterfall Model) 是一个项目开发架构,开发过程是通过设计一系列阶段顺序展开的,从系统需求分析开始直到产品发布和维护,每个阶段都会产生循环反馈,因此,如果有信息未被覆盖或者发现了问题,那么最好“返回”上一个阶段并进行适当的修改,项目开发进程从一个阶段“流动”到下一个阶段,这也是瀑布模型名称的由来。包括软件工程开发、企业项目开发、产品生产以及市场销售等构造瀑布模型。
优点:
- 为项目提供了按阶段划分的检查点。
- 当前一阶段完成后,只需要去关注后续阶段。
- 可在迭代模型中应用瀑布模型。
- 它提供了一个模板,使得分析、设计、编码、测试和支持的方法可以在该模板下有一个共同的指导。
缺点:
- 各个阶段的划分完全固定,阶段之间产生大量的文档,增加了工作量。
- 由于开发模型是线性的,用户只有等到整个过程的末期才能见到开发成果,从而增加了开发风险。
- 通过过多的强制完成日期和里程碑来跟踪各个项目阶段。
- 瀑布模型的突出缺点是不适应用户需求的变化。
其中:
软件计划到需求分析为定义阶段。
软件设计到软件测试为开发阶段。
运行维护为维护阶段。
软件开发工程——软件开发模型——原型模型(演化模型)
快速原型模型是原型模型在软件分析、设计阶段的应用,用来解决用户对软件系统在需求上的模糊认知,用来试探某种设计是否能够获得预期结果。
软件开发工程——软件开发模型——增量模型与螺旋模型
增量模型:增量模型是把待开发的软件系统模块化,将每个模块作为一个增量组件,从而分批次地分析、设计、编码和测试这些增量组件。运用增量模型的软件开发过程是递增式的过程。相对于瀑布模型而言,采用增量模型进行开发,开发人员不需要一次性地把整个软件产品提交给用户,而是可以分批次进行提交。
螺旋模型:螺旋模型是一种演化软件开发过程的模型,它兼顾了快速原型的迭代的特征以及瀑布模型的系统化与严格监控。螺旋模型最大的特点在于引入了其他模型不具备的风险分析,使软件在无法排除重大风险时有机会停止,以减小损失。同时,在每个迭代阶段构建原型是螺旋模型用以减小风险的途径。螺旋模型更适合大型的昂贵的系统级的软件应用。
软件开发工程——软件开发模型——V模型
V模型是软件开发过程中的一个重要模型,由于其模型构图形似字母V,所以又称软件测试的V模型。
软件开发工程——软件开发模型——喷泉模型与RAD(V模型)
喷泉模型:喷泉模型(Fountain Model)是一种以用户需求为动力,以对象为驱动的模型,主要用于描述面向对象的软件开发过程。该模型认为软件开发过程自下而上周期的各阶段是相互迭代和无间隙的特性。
RAD模型:快速应用开发(Rapid Application Development、RAD)不仅是一种需求抽取方法,它还是是软件开发为一体的方法。 快速应用开发目的是快速发布系统方案,而技术上的优美相对发布的速度来说是次要的。
软件开发工程——软件开发模型——构件组装模型(CBSD)
构件组装模型融合了螺旋模型的许多特征。它本质上是演化的支持软件开发的迭代方法。但是,构件组装模型是利用预先包装好的软件构件(有时称为“类”)来构造应用程序的。
软件开发工程——软件开发模型——统一过程模型(UP)
统一过程主要分五个阶段:开启阶段(Inception),细化阶段(Wlaboration),构建阶段(Xonstruction),移交阶段(Transition),生产阶段(Production)。
软件开发工程——软件开发方法
软件开发工程——软件开发方法——敏捷开发方法
敏捷开发以用户的需求进化为核心,采用迭代、循序渐进的方法进行软件开发。在敏捷开发中,软件项目在构建初期被切分成多个子项目,各个子项目的成果都经过测试,具备可视、可集成和可运行使用的特征。换言之,就是把一个大项目分为多个相互联系,但也可独立运行的小项目,并分别完成,在此过程中软件一直处于可使用状态。
软件开发工程——软件开发方法——信息系统开发方法
软件开发工程——需求开发
软件开发工程——结构化设计
软件开发工程——结构化设计——内聚与耦合
内聚类型 ↓ | 描述 | 耦合类型 ↑ | 描述 |
---|---|---|---|
功能内聚 | 完成一个单一的功能,各个部分协同工作,缺一不可。 | 非直接耦合 | 两个模块之间没有直接关系,它们之间的联系完全是通过主模块的控制和调用来实现的。 |
顺序内聚 | 处理元素相关,而且必须顺序执行 | 数据耦合 | 一组模块借助参数表传递简单数据 |
通信内聚 | 所有处理元素几种在一个数据结构的区域上 | 标记耦合 | 一组模块通过参数表传递记录信息(数据结构) |
过程内聚 | 处理元素相关,而且必须按特定的次序执行 | 控制耦合 | 模块之间传递的信息中包含用于控制模块内部逻辑的信息 |
瞬时内聚(时间内聚) | 所包含的任务必须在同一时间间隔内执行 | 外部耦合 | 一组模块都访问同一全局简单变量,而且不是通过参数表传递该全局变量的信息 |
逻辑内聚 | 完成逻辑上相关的一组任务 | 公共耦合 | 多个模块都访问同一个公共数据环境 |
偶然内聚(巧合内聚) | 完成一组没有关系或松散关系的任务 | 内容耦合 | 一个模块直接访问另一个模块的内部数据 一个模块不通过正常入口转到另一个模块的内部 两个模块有一部分程序代码重叠 一个模块有多个入口 |
软件开发工程——结构化设计——系统结构 / 模块结构
软件开发工程——软件测试
软件开发工程——软件测试——测试原则与类型
- 尽早、不断的进行测试。
- 程序员避免测试自己设计的程序。
- 既要选择有效、合理的数据,也要选择无效、不合理的数据。
- 修改后应进行回归测试
- 尚未发现的错误数量与该程序已发现错误数成正比。
软件开发工程——软件测试——测试用例设计
软件开发工程——软件测试——测试阶段
软件开发工程——软件测试——McCabe复杂度
计算有向图G的环路复杂度公式为: 。
说明:其中 V(G) 是有向图 G 中的环路个数,m 是 G 中的有向弧度,n 是 G 中的节点数。
软件开发工程——系统运行与维护
软件维护是生命周期的一个完整部分。可以将软件维护定义为需要提供软件支持的全部活动,这些活动包括在交付前完成的活动,以及交付后完成的活动。交付前完成的活动包括交付后运行的计划和维护计划等。交付后的活动包括软件修改、培训、帮助资料等。
可维护性 |
| 维护类型 |
|
软件开发工程——软件过程改进(软件成熟度模型CMMI)
成熟度等级 | 过程域 | 连续式分组 | 过程域 |
---|---|---|---|
已管理级 | 需求管理、项目计划、配置管理、项目监督与控制、供应商合同管理、度量和分析、过程和产品质量保证 | 过程管理 | 组织级过程焦点、组织级过程定义、组织级培训、组织级过程性能、组织级改革与实施 |
已定义级 | 需求开发、技术解决方案、产品集成、验证、确认、组织级过程焦点、组织级过程定义、组织级培训、集成项目管理、风险管理、集成化的团队、决策分析和解决方案、组织级集成环境 | 项目管理 | 项目计划、项目监督与控制、供应商合同管理、集成项目管理、风险管理、集成化的团队、定量项目管理 |
定量管理级 | 组织级过程性能、定量项目管理 | 工程 | 需求管理、需求开发、技术解决方案、产品集成、验证、确认 |
优化级 | 组织级改革与实施、因果分析和解决方案 | 支持 | 配置管理、度量和分析、过程和产品质量保证、决策分析和解决方案、组织级集成环境、因果分析和解决方案 |
软件开发工程——项目管理
答:
(1):D.各任务之间的依赖关系
(2):C.10
解释:
(1):
(2):
通过计算事件9最早开始时间为15,最晚开始时间为15。
通过逆推得知事件8的最早开始时间为9,最晚开始时间为11。
再次逆推得知时间6的最早开始时间为4,最晚开始时间为10。
软件开发工程——风险管理
风险是指“损失或伤害的可能性”。
- 项目风险
- 技术风险
- 商业风险
- 关心未来
- 关心变化
- 关心选择
风险曝光度(Risk Exposure):计算方法是风险出现的概率乘以风险可能造成的损失。