﻿<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:trackback="http://madskills.com/public/xml/rss/module/trackback/" xmlns:wfw="http://wellformedweb.org/CommentAPI/" xmlns:slash="http://purl.org/rss/1.0/modules/slash/"><channel><title>BlogJava-Javaren就是爪洼人！-文章分类-OOM</title><link>http://www.blogjava.net/javaren/category/38683.html</link><description>一起来研究java</description><language>zh-cn</language><lastBuildDate>Mon, 30 Mar 2009 23:20:25 GMT</lastBuildDate><pubDate>Mon, 30 Mar 2009 23:20:25 GMT</pubDate><ttl>60</ttl><item><title>读书笔记-软件开发过程-系统构思</title><link>http://www.blogjava.net/javaren/articles/262960.html</link><dc:creator>Terry Lee</dc:creator><author>Terry Lee</author><pubDate>Mon, 30 Mar 2009 11:05:00 GMT</pubDate><guid>http://www.blogjava.net/javaren/articles/262960.html</guid><wfw:comment>http://www.blogjava.net/javaren/comments/262960.html</wfw:comment><comments>http://www.blogjava.net/javaren/articles/262960.html#Feedback</comments><slash:comments>0</slash:comments><wfw:commentRss>http://www.blogjava.net/javaren/comments/commentRss/262960.html</wfw:commentRss><trackback:ping>http://www.blogjava.net/javaren/services/trackbacks/262960.html</trackback:ping><description><![CDATA[UML面向对象建模与设计(第2版) Object-Oriented Modeling and Design with UML Second Edition<br />
<br />
系统构思(system conception)要处理的是某项应用的起源。系统构思的目的是延迟细节实现，理解完整图景。<br />
<br />
<strong>1.形成系统概念</strong><br />
多数有关新系统的思想都是对已有思想的扩展。偶尔，新系统也会大大地偏离原有系统。作者又利用下面的方法帮助发现新的系统概念：<br />
新的功能；流水化；简化；自动化；整合；类比；全球化<br />
<br />
<strong>2. 阐释概念</strong><br />
作者对优秀的系统给定了个标准，就是能回答下面几个问题：<br />
<strong>a.应用程序是为谁而做的？</strong>就是风险承担人有哪些。用户不会主动考虑新系统，除非能帮助他们获利。作者指出：如果不能让他们参与项目，那样项目的需求就很可疑，需要重写考虑。我觉得也对，做的项目如果毫无用处，干嘛费大力气去做呢？<br />
<strong>b.它解决了哪些问题？</strong>通过这个问题来帮助我们界定工作量，确定工作范围。<br />
<strong>c.它会用在什么地方？</strong>是关键性软件、实现性软件、新部署的功能等等<br />
<strong>d.何时会需要它？</strong>这里提到了2个时间：可行时间和必需时间，如果这两个时间脱节不一致了，技术人员和业务专家就得通过对话找解决方法。<br />
<strong>e.为什么会需要它？</strong>可以做一份业务案例，包括成本、有形效益、无形效益、风险和候选方案，清晰的理解新系统的动机。<br />
<strong>f.它是如何工作的？</strong>集体讨论问题的可行性，这里不是选择解决方案，是让我们知道该问题有方法解决。<br />
<br />
作者通过ATM案例来说明如何回答上面几个问题。<br />
<br />
<strong>3.准备问题陈述</strong><br />
回答了上面几个问题后，下面要进行需求陈述，来概述待构建系统的目标和总体方案。<br />
需求要从用户的观点来描述系统的行为，把系统看成黑盒子。问题陈述应该描述要完成哪些事情，而不是如何实现。它应该是需求的陈述，而不是对系统架构的建议。大多数问题陈述都是模糊的、不完整的、前后不一致的甚至完全错误的，所以要经过全面分析去除那些会对系统造成不良影响的部分。<br />
<br />
作者通过ATM案例来展示了问题陈述内容。<br />
<br />
<strong>4. 小结</strong><br />
项目的第一个阶段是形成新的构思。在开发之前，先要评估系统的可行性、开发系统的困难和风险、系统的需求以及成本效益比例。这个过程，我们应该考虑到系统所有风险承担人的观点，做出必要的权衡。(开始，我是认为这些评估貌似不是开发人员应该关心的，但是想想如开发起来我们才发现这个项目不太现实，或者困难太多成本增高，再去和客户沟通就会比较麻烦了，如果前期做好这方面工作后面开发就比较顺了。)<br />
<img src ="http://www.blogjava.net/javaren/aggbug/262960.html" width = "1" height = "1" /><br><br><div align=right><a style="text-decoration:none;" href="http://www.blogjava.net/javaren/" target="_blank">Terry Lee</a> 2009-03-30 19:05 <a href="http://www.blogjava.net/javaren/articles/262960.html#Feedback" target="_blank" style="text-decoration:none;">发表评论</a></div>]]></description></item></channel></rss>