关于软件原型方法若干问题的讨论

下载本文示例代码
　　1 引子　　太多了！终于签下合同-->得到了“正式”的客户提供的“需求书”的几片纸-->凭借自己的理解立即投入开发-->“木已成舟”，生米终于熬成粥-->用户拒绝接受？-->艰难地修改，反复修改，开发人员厌倦了，而用户对系统用之无味，弃之可惜，遂成鸡肋。-->由此后期收款遥遥无期，软件公司不再和用户保持沟通-->互相埋怨，扯皮由此而生。或者，一个项目拆成为多期，从而收取一部分款项，而很多的开发都作废。这样的案例真是何其多也！　　究其主要原因，与其说是没有搞定关键客户，或者项目管理不当，不如说是没有帮助客户解决其问题，对客户真正的需求研究不够。实际上，原型方法是解决此类问题、确保项目成功的最佳途径。我在写此文的同时，也试图寻找资料，不知道是本就没有，还是自己所不幸而未找到。看来原型并没有明确的标准，而目前不同软件公司的理解和做法各不相同也就不奇怪了。但从软件过程的角度来考察，原型法仍有着通用的优化的做法。本文试图从作者的实践经验出发，对原型方法进行思考与探讨。　　另外，本文是发散型的，在研究原型的同时，也讨论了原型相关的内容。原型本质上有些象是抛砖引玉，而本文也旨在抛砖引玉，但无意于一概地论定什么。　　2 什么是原型　　2.1 原型的定义　　原型(prototype)即把系统主要功能和接口通过快速开发制作为“软件样机”，以可视化的形式展现给用户，及时征求用户意见，从而明确无误地确定用户需求。同时，原型也可用于征求内部意见，作为分析和设计的接口之一，可方便于沟通。　　2.2 原型的主要价值　　原型法主要价值是可视化，强化沟通，降低风险，节省后期变更成本，提高项目成功率。一般来说，采用原型法后可以改进需求质量；虽然投入了较多先期的时间，但可以显著减少后期变更的时间；原型投入的人力成本代价并不大，但可以节省后期成本；对于较大型的软件来说，原型系统可以成为开发团队的蓝图；另外，原型通过充分和客户交流，还可以提高客户满意度。　　2.3 基本要求　　对原型的基本要求包括：　　* 体现主要的功能；　　* 提供基本的界面风格；　　* 展示比较模糊的部分，以便于确认或进一步明确，防患于未然。　　* 原型最好是可运行的，至少在各主要功能模块之间能够建立相互连接。　　2.4 处理方法　　原型的处理方法基本上有2种不同类型，即抛弃型和演化型（不同的软件工程书籍称发不同，实质意义则类似）。可以抛弃原型，在取得的明确需求基础上重新开始设计与开发；也可在原型的基础上继续开发。一般小项目不采用抛弃型原型，否则成本和代价似乎会偏高。　　2.5 表达工具　　原型的表达工具可以有很多，如果是演化型的原型，当然优先选用软件本身的开发工具。否则还可以应用各种快速显示的工具，例如，HTML，Powerpoint等等，只要能够充分而形象地表达就可以了。　　根据笔者的经验，在原型系统中，可以采用一些与常规不同的做法，例如，可以在界面上比较显著的地方写明当前模块或界面的主要目的，由哪些角色操作，能解决其什么问题。这么做可以使得用户或开发团队成员一开始就有非常清楚的概念；又如，对于决策分析，你可以直接把一些分析结果画成图，并且配上一些文字说明，这样可以避免输入大量初始数据，等等。共3页。 1 2 3 : 　　1 引子　　太多了！终于签下合同-->得到了“正式”的客户提供的“需求书”的几片纸-->凭借自己的理解立即投入开发-->“木已成舟”，生米终于熬成粥-->用户拒绝接受？-->艰难地修改，反复修改，开发人员厌倦了，而用户对系统用之无味，弃之可惜，遂成鸡肋。-->由此后期收款遥遥无期，软件公司不再和用户保持沟通-->互相埋怨，扯皮由此而生。或者，一个项目拆成为多期，从而收取一部分款项，而很多的开发都作废。这样的案例真是何其多也！　　究其主要原因，与其说是没有搞定关键客户，或者项目管理不当，不如说是没有帮助客户解决其问题，对客户真正的需求研究不够。实际上，原型方法是解决此类问题、确保项目成功的最佳途径。我在写此文的同时，也试图寻找资料，不知道是本就没有，还是自己所不幸而未找到。看来原型并没有明确的标准，而目前不同软件公司的理解和做法各不相同也就不奇怪了。但从软件过程的角度来考察，原型法仍有着通用的优化的做法。本文试图从作者的实践经验出发，对原型方法进行思考与探讨。　　另外，本文是发散型的，在研究原型的同时，也讨论了原型相关的内容。原型本质上有些象是抛砖引玉，而本文也旨在抛砖引玉，但无意于一概地论定什么。　　2 什么是原型　　2.1 原型的定义　　原型(prototype)即把系统主要功能和接口通过快速开发制作为“软件样机”，以可视化的形式展现给用户，及时征求用户意见，从而明确无误地确定用户需求。同时，原型也可用于征求内部意见，作为分析和设计的接口之一，可方便于沟通。　　2.2 原型的主要价值　　原型法主要价值是可视化，强化沟通，降低风险，节省后期变更成本，提高项目成功率。一般来说，采用原型法后可以改进需求质量；虽然投入了较多先期的时间，但可以显著减少后期变更的时间；原型投入的人力成本代价并不大，但可以节省后期成本；对于较大型的软件来说，原型系统可以成为开发团队的蓝图；另外，原型通过充分和客户交流，还可以提高客户满意度。　　2.3 基本要求　　对原型的基本要求包括：　　* 体现主要的功能；　　* 提供基本的界面风格；　　* 展示比较模糊的部分，以便于确认或进一步明确，防患于未然。　　* 原型最好是可运行的，至少在各主要功能模块之间能够建立相互连接。　　2.4 处理方法　　原型的处理方法基本上有2种不同类型，即抛弃型和演化型（不同的软件工程书籍称发不同，实质意义则类似）。可以抛弃原型，在取得的明确需求基础上重新开始设计与开发；也可在原型的基础上继续开发。一般小项目不采用抛弃型原型，否则成本和代价似乎会偏高。　　2.5 表达工具　　原型的表达工具可以有很多，如果是演化型的原型，当然优先选用软件本身的开发工具。否则还可以应用各种快速显示的工具，例如，HTML，Powerpoint等等，只要能够充分而形象地表达就可以了。　　根据笔者的经验，在原型系统中，可以采用一些与常规不同的做法，例如，可以在界面上比较显著的地方写明当前模块或界面的主要目的，由哪些角色操作，能解决其什么问题。这么做可以使得用户或开发团队成员一开始就有非常清楚的概念；又如，对于决策分析，你可以直接把一些分析结果画成图，并且配上一些文字说明，这样可以避免输入大量初始数据，等等。共3页。 1 2 3 : 下载本文示例代码


关于软件原型方法若干问题的讨论关于软件原型方法若干问题的讨论关于软件原型方法若干问题的讨论关于软件原型方法若干问题的讨论关于软件原型方法若干问题的讨论关于软件原型方法若干问题的讨论关于软件原型方法若干问题的讨论关于软件原型方法若干问题的讨论关于软件原型方法若干问题的讨论关于软件原型方法若干问题的讨论关于软件原型方法若干问题的讨论关于软件原型方法若干问题的讨论关于软件原型方法若干问题的讨论关于软件原型方法若干问题的讨论关于软件原型方法若干问题的讨论