软件开发过程中的主要问题和好的解决方法在线视频

同 学们 今天我们开始讲面向对象分析与设计这门课

我们首先讲第一节课 软件开发过程中的主要问题和好的解决方法

在现代软件开发过程中 我们遇到的问题主要有

首先是用户的需求没有满足

比如说我们提供给用户的软件产品并不是用户最终想要的

例如我们给农民提供了一辆宝马车 而农民他可能只需要的是一辆卡车

第二点 在软件开发过程中 我们对软件的需求可能是由于在设计开发过程中有些需求会被遗漏

也就是说 并不是所有的用户需求都能够被软件产品所实现

第三点 软件开发的模块无法有效地集成

我们知道 现在软件系统都非常的复杂

有几万行 几十万行 几百万行甚至更多

那么在软件开发过程中 这些模块在设计中

可能会由于接口的不匹配

导致最终软件没有办法进行有效的集成

第四点来讲 就是软件维护非常的困难

软件的维护是很难避免的

可能是由于修改软件里面的错误

也可能是软件运行的硬件平台升级

或者用户需要增加新的功能 都可能会引起软件的维护

那么当我们软件架构设计的不合理的时候

我们对软件的某个部分或者模块修改

都会导致相关的其他模块引入无法预料或者说不可避免的一些错误

使得软件系统难以维护

第四点来讲 就是软件中缺陷发现的很晚

我们知道软件缺陷发现的越晚

我们需要维护和修改这个缺陷所需要付出的时间和代价就会越高

再下来 就是用户体验很差

我们所开发的软件在这个界面设计 用户很难学习和掌握

对我们软件的操作 用户感到有很多的困惑

再下来 就是用户的性能很差

也就是说 当多个用户并发访问的时候

可能响应时间很慢甚至整个系统可能会崩溃

然后就是团队合作没有办法进行有效地协调

现在软件系统的规模很大以后

对软件项目的开发可能是几十人 几百人 上千人甚至上万人并行开发

如果没有办法对多个软件团队进行有效地协调和管理

可能就会导致整个项目延期甚至失败

最后就是Build和released的问题

也就是构建和发布的问题

我们知道现在软件会有很多个版本

有开发版本 有发布版本

同时随着对软件缺陷的修改可能还会发布很多小版本

那么如何对众多版本进行有效地管理

也是现在软件开发过程中面临的一个主要的问题和挑战

那么针对这些问题 我们需要分析

每一个问题 引发它的根本原因是什么

这里我们以软件模块无法集成为例

那么引起软件模块无法进行有效集成的根本原因主要有两个

一个是在设计阶段缺乏有效的沟通

也就是说设计中的沟通存在模糊性

第二个 没有及时发现这种不一致

针对这些根本原因

我们进一步在软件开发企业 工程界中总结了一些好的方法

来避免和解决这些问题

比如针对模糊性沟通问题

在工程界里面我们通常采用可视化建模

我们采用UML等可视化语言

我们把我们的设计用图形的方式进行描述

从而避免传统的用文字描述它的天然的模糊性

第二个我们通过对软件项目开发中持续的质量验证

比如说进行评审 进行测试

我们来尽早的发现软件中存在的各种不一致和各种问题

而且在现代软件开发过程中总结出来好的实践方法主要有这么几个

第一个是迭代开发

第二个是需求管理

第三个是组件化体系结构

第四个 可视化建模

第五个 持续的质量验证和确认

最后一个是变更管理

而且这六个好的实践方法 它们之间不是孤立的

它们可能会形成一个1+1＞2这样一个效果

我们举个例子 比如以迭代开发为例

那么通过迭代开发 我们就可以保证

我们把整个软件项目的开发过程分解成多个迭代过程

在每个迭代过程中

我们可以邀请用户参与到需求的分析和需求的验证过程中

也就是说 用户可以持续的进入到我们的项目开发活动中来

这样就避免我们最终所开发的产品

不是用户真实想要的 或者说没有满足用户的真实需求

那么同样的 采用迭代化开发

我们可以在迭代的早期

我们就可以验证我们所设计的软件其架构是否有效 或者说它的质量是否能满足要求

同样的话 迭代开发我们每次只分析设计软件的一部分

这样可以降低我们进行软件设计 建模的复杂性

那么首先我们来看迭代开发

什么是迭代开发呢

也就是说 我们把一个完整的软件产品

在第一步 做一个迭代计划

我们把它分解成多个迭代过程 比如说三次或者五次

然后每一次我们只完成整个软件系统里面的一部分功能

所以在每一次迭代里面 我们制定本次迭代的项目开发计划

然后完成本次迭代所关注的这些软件功能的需求分析

软件的分析设计 软件的实现 进行测试 部署

然后同时对这次迭代进行质量的评估和验证

那么在这一次迭代周期完成以后 在进入到第二个迭代周期

一直到最后一次迭代 再给用户发布一个可执行的 完整的软件产品

那么第二个 我们介绍一下需求管理

我们需求管理的目标有两个

第一个确保我们所开发的软件 是能够帮用户解决他需要解决的真正问题

第二个我们要确保我们所实现的软件产品是一个正确的软件系统 它能够满足我们的需求

那么整个需求管理活动主要包括有四个步骤

第一个是需求的收集和提取

通过调研和用户的访谈等各种方式来收集用户的原始需求

然后对用户的原始需求 在第二个步骤我们要进行相应的组织和整理

在第三个部分我们把我们最终确认的用户需求进行文档化

比如说我们要编写预期需求的规格说明书 把它固化下来

最后我们还要对需求进行有效的管理和控制 要控制需求的变更

再下来 我们介绍一下组件化软件体系架构

组件化软件体系架构从本质上讲 就是把软件的架构设计成有多个组件

通过组件之间的集成 来构成整个完整的软件系统

那么组件化软件体系架构 它的优点是首先有助于对组件的复用

我们可以复用商业组件 可以复用已有的软件产品开发出来的组件 等等

还可以复用一些第三方的或者开源的一些组件

那么组件化体系架构它的好处是它不仅可以满足当前的用户需求 而且具有良好的扩展性

当用户提出新的需求之后 我们可以通过升级组件或者增加新的组件来满足用户新的需求

第二 组件化体系架构有助于复用 我们同一个组件可以在多个软件产品中进行复用

第三 我们每个组件都有明确的接口

这样可以确保每个组件都有较好的分装性或者说独立性

那么组件化软件体系架构我们说它的复用首先可以支持组件复用

就是同一个组件在多个软件系统中进行复用

第二个还可以实现架构复用

同一个软件体系架构在相似的或者类似的产品组或者说产品线中进行复用

而且可以以组件为基础 进行软件项目的组织和管理

以组件为单位 分配软件开发的人员

以组件为单位 进行软件产品的发布

另外的话 基于组件的软件开发可以控制和管理软件系统设计开发的复杂性

可以维护整个软件系统之间的一致性

下面我们介绍一下可视化建模

在面向对象里面我们常用到的可视化建模方法只要是UML

那么UML这种可视化建模方法

它首先可以帮助我们捕获整个软件系统的结构和行为

以及显示软件系统中的组成元素 比如组件是如何把它有效地集成在一起的

可以用来检查软件的设计和它的实现是否一致

另外的话 可视化建模支持在不同抽象层次的建模

通过建立不同抽象层次的模型可以帮助我们根据需要隐藏或者展示软件设计的一些细节

可视化建模与传统的语言描述相比 它更为清晰准确

这样可以避免在团队开发中模糊的通讯问题

确保项目开发团队对软件系统的理解是一致的

在典型的UML中 主要的模型有这么几个

首先是静态模型 那么第一个静态模型就是这个用例模型

它描述了软件系统的功能需求

第二个是类图 它描述了软件系统的静态结构

第三个是对象图 对象图不是独立的

当类图太复杂的时候

我们说类是对象的实例 那么对象图就是类图的实例

当类图太负责的时候 我们可能需要创建若干个对象图来补充说明类图

再下来是组件图 组件图描述软件系统开发完成以后软件的物理组件

再往下是部署图

部署图描述这些软件开发完的物理组件是如何安装部署在不同的计算机 这样的一些计算平台上去的

那么第二部分 蓝颜色的我们把它称之为动态图

那么第一个动态图我们讲的是时序图

这个时序图是以时间的先后顺序来描述软件的组成部分

比如说类 对象 或者组件们是如何相互协作的

那么第二个是通信图 通信图和时序图是完全等价的

或者说 它包含的元素 包含的寓意是完全相同的 只是表现形式不一样

再往下是状态图 状态图描述了软件系统

它在不同的状态下 它的行为以及状态之间的迁移关系

最后一个是活动图

活动图主要是描述软件项目开发软件系统的事件流或者说它的控制流

活动图可以作为用例图的一个补充

来说明用例里面描述的用户功能在软件系统中具体的执行过程或者说控制过程

它也可以作为对一些项目软件系统中的复杂算法或者说函数的具体实现

具体实现的操作用活动图进行说明

下面我们说一下软件缺陷的持续的验证和确认

从这张图我们上可以看到 对软件缺陷

如果我们在早期发现一个软件缺陷 我们的修复成本是非常低的

但如果我们在软件交付用户以后 后期再发现一个同样的缺陷

我们需要的修复成本可能是之前的一百倍甚至一千倍

这也就要求我们通过持续的质量验证之后确保我们尽早的发现软件问题

尽早的进行修复

对于软件质量的确认主要检查这么几个（方面）

第一个是检查它的功能的正确性

第二个检查软件是否易用 它的易用性

第三个检查软件系统的可靠性 是否能够稳定持续的运行

第四个检查它的性能

在大用户量并发访问的时候是不是软件能够稳定的及时的进行相应

最后检查软件系统的可支持性 是否给用户提供相应的操作帮助 操作提示等等

最后一个我们讲一下变更管理

我们知道现在软件系统非常的复杂 软件项目开发通常由团队进行

团队少则五六人 多则几十几百人甚至更多

那么多团队并行开发过程中 可能会引入一些不可避免的错误

比如说团队中成员对某个文件A作了修改 然后成员B也对同样的文件A作了修改

那么最后提交的时候很可能后提交的就会把先提交的覆盖掉

导致某个成员的工作无效 从而引入一些错误

所以需要通过变更管理能够提供一个安全的可靠的并行的软件开发环境

所以变更管理是覆盖整个软件项目开发的全过程的

它是以软件开发项目的活动

比如说任务缺陷等为基础的进行软件开发项目的一个管理

而且它能持续对软件开发项目的状态进行跟踪

以图形 报表的方式来展示软件开发项目的状态

同学们 我们今天的课就讲到这里

今天我们主要介绍了软件项目开发过程中遇到的主要问题和工程界针对这些问题一些好的解决方法

谢谢大家