团队技能之一——分析问题

团队技能之一——分析问题

软件开发不能真正满足商业需求的原因：软件开发团队总是在“真正理解业务问题”、“理解用户和其他涉众的需求”、“理解将来软件可能的运行环境”方面花的时间太少。开发团队习惯于埋头编程，给出的技术解决方案是基于对所解决问题的不完全理解。

第五章 问题分析的五个步骤

在某种意义上，问题与机遇是一枚硬币的两面。当我们换一个看问题的角度，你的问题就是我的机遇。

问题分析：理解真实世界中的问题和用户的需要，并对如何满足这样的需求提出解决方案。

Gause和Weinberg的观点：问题可以被定义为我们所感觉到的与所期望得到的事物之间的区别。－－这个定义在任何领域都适用，且由两个解决方案，一是提高用户感觉到的系统，另一个是降低用户对系统的期望。

开发者经常认为真正的问题是用户不理解什么是真正的问题。－－依照Gause的观点，可以解决开发者的问题。要让用户指出它对系统的现实与期望的差异。

有时候，最简单的解决方案或许是一个变通或是一个经过修订的商业过程，而不是一个新系统。改变用户的期望或感觉可能是最划算的方法。

问题分析的目标：在开发之前对要解决的问题有一个更好的理解。分为如下几个步骤：

1、在问题定义上达到共识

2、理解根本原因——问题背后的问题

3、确定涉众与用户

4、定义解决方案系统的界限

5、确定问题解决方案上的约束条件

达成共识的最简单方法：简单地把问题写下来，看看是否每个人都同意。

问题陈述的表格

要素	描述
问题	描述问题
影响	确定受问题影响的涉众
结果	确定问题对涉众和商业活动的影响
优点	指出解决方案并列出主要优点

找问题方法：询问真正的业务人员而不是管理者，很多时候管理者都不知道问题发生的真正原因。

将问题采用定量数据发分析，可以排除很多不值得考虑的原因。

为有效地解决问题，了解用户及其他涉众的需要是关键一步。

涉众：任何将从新系统或应用的实现中受到实质性影响的人。分析涉众可采用如下分析步骤：系统用户是谁？客户（花钱购买）的是谁？哪些人会受系统输出的影响？系统投入使用后，评估者是谁？还有没有系统的内部或外部用户？系统的维护者？

对于系统边界而言，我们关心的世界仅为：我们的系统；和我们系统进行交互的事物。

确定系统的主角步骤：谁会对系统提供信息、使用信息、删除信息？系统的操作者、维护者？系统在哪使用？从哪得到信息？那些外部系统要和系统进行交互？

约束：对提供解决方案的我们拥有的自由度的限制。

潜在的系统约束源有：经济的、行政的、技术的、系统的、环境的与进度及资源的。

确定约束后，有些约束会成为新系统的需求，而其他的约束会影响到资源、实现计划及项目计划等。

第六章：业务建模

业务建模是一种分析问题的技术，有助于定义系统及其应用。业务用例模型由主角喝用例构成，是业务功能的模型。业务对象模型描述了提交实现业务的用例功能的实体以及这些实体之间的交互。

业务建模的目的：理解现有的业务组织的静态结构和动态运作方式；确保客户、最终用户以及开发人员对业务的共同理解。

下部分：团队技能之二－－理解用户和涉众的需要