作者 内容  haiger   这个分析如何写？？ 背景： 我公司有一个很成熟的ERP产品，客户量很大。不过是基于ACCESS/SQL Server的C/S模式的。 想法： 眼见因为开发工具的落后而导致的损失，我打算将在原有系统的基础上进行改造和扩展，大致思路是只从原来系统中提取业务模型（这是原来系统的强项），然后采用新的开发工具（比如JAVA、VB+SQL Server（Oracle））来重新设计系统架构。拟采用标准的B/S混合C/S模式来开发，开发过程采用标准的面向对象软件工程的思路，大量采用UML和CASE工具，实施标准的项目管理来完成整个新系统。 难点： 1、公司开发人员很少，要大面积招新人； 2、公司以前的完全是作坊式开发，开发人员没有对OOA、OOD不感兴趣； 3、整个项目有一定风险； 4、项目要求投资比较大； 我的目的： 说服公司董事会，对该项目进行投资。 我的问题： 业务模型的收集已经差不多，不过我还要写一个类似保证整个项目可以顺利、完全符合预期计划正常实现的技术可行性分析报告。该报告应该涉及比如： 1、当前系统的弱点； 2、国内软件业界当前面临的问题； 3、针对这些问题应该采取的对策； 4、软件系统选型； 但是有个问题想请大家讨论一下，我现在对以上提到的东西虽然有点了解，但是总觉得难以下笔，不知道大家有没有这方面的资料，请不啬和我交流一下。十分感谢！！  01/08/10 17:51 酷帖！    臭帖！    回复   酷帖评价：           臭帖评价： 返回页首  jason_jee   回复: 这个分析如何写？？ 如果我是贵公司的决策人，我最关心的问题是：公司投资翻新ERP的成本会不会大于翻新后系统的收益。IF RESULT=TRUE THEN CANCEL ELSE OK。  01/08/10 18:07 酷帖！    臭帖！    回复   酷帖评价：           臭帖评价： 返回页首  儒商   一些个人建议 1.ERP它主要是满足企业内部的应用。 也就是说，使用它的人与使用它的时间有95%(主观)以上是在局域网中使用，因此从满足性能的角度出发，用C/S结构是较好的。它能获得较好的性能。 同时，它也不存在异构、分布的特点。所以不宜有用Java。 2.从你们的ERP产品所用的数据库来看，你们是采用胖客户端的方式，即所有的业务的操作与处理都是放在前台来实现，如果是这样，它对后台的数据库的联系就很低。 这时，如果是出于满足不同客户的数据库的需要（因为有些企业可能已经有了某种数据库，而不需购买新的数据库）,系统的版本化应用工作就不会很大。 3.对功能的重新布署，即将一部分功能从前台移向后台。 这时的情况就比较复杂。 因为这时的功能实现方式有很多种形式，而且会产生不同优点，如性能的提高、 如采用J2EE，或采用中间的应用服务器、或将业务处理封装成存储过程等等。 这时都会对设计带来不同的影响，如在分析时，将这些因素充分考虑，则对设计的影响将会很小。 4.要充分意识到，做为企业级应用软件，则企业的业务对象（各种报表，数据元素，表等数据对象）和业务过程或工作流是会发生变化的。 可从几个方面来解决这种变化： a.将业务对象尽可能分离出它的不变要素及可变要素，即对象建模。 b.多建视图。 c.提高系统的配置性.  01/08/10 18:36 酷帖！    臭帖！    回复   酷帖评价：           臭帖评价： 返回页首  cubewind  回复: 这个分析如何写？？ 我遇到同样的问题,不过,不是ERP类型的项目. 一个老项目,如何用uml 来翻新,好像难度比新建项目大得多. 这不仅是一个技术问题,更多的是人员素质的问题. 如果贵公司从未将ooa/oop用于知道设计和编程, 上UML将是及其危险的. 建议: 从推广使用ROSE入手.  01/08/11 09:59 酷帖！    臭帖！    回复   酷帖评价：           臭帖评价： 返回页首  greatbear  回复: 这个分析如何写？？ 你的建议是从推广使用ROSE入手，我想问的是：这是不是意味着上UML的时间至少得要往后推迟半年？ 我现在也正遭遇同样的问题，以前的系统功能比较简单，结构也不是很复杂，可随着版本的升级，在上面打的补丁越来越多，而且几乎所有的补丁都是直接根据源代码进行修改，没有任何结构方面的文档资料。 如你所说，要用一种开发人员并不熟悉，甚至并不认可的方式（尽管确实很好）进行系统翻新难度真的不亚于重写一遍，可从项目的角度出发要重写一遍似乎不大可能。真是头疼死了，不知哪位网友有好的建议！  01/08/11 12:40 酷帖！    臭帖！    回复   酷帖评价：           臭帖评价： 返回页首  qiubole   回复: 这个分析如何写？？ 既然是个成熟的产品 那么更改的难度很大 领导所认为的只是更改后带来的效益,以及所冒的风险 除非你能将风险降到最低 只然不可能只是些夸夸其谈的话  01/08/11 21:54 酷帖！    臭帖！    回复   酷帖评价：           臭帖评价： 返回页首  superyxb   回复: 这个分析如何写？？ 在这个分析中，可能最能打动人的一点就是公司和产品如何走的设想了。 6个月之后，以所期望的公司，产品，及其外部的竞争环境如何？ 12个月之后，又如何？ 2年之后又如何？ 老板们主要关心的不过是“前途”二字，如何能持续的赚钱是最大的目标。他们的投资要求有回报，风险需要能被控制。 在你的产品升级后，是能够吸引更多的新用户呢？还是主要吸引现有用户升级，还是希望吸引别的产品用户转到你的产品来？是主动的出击呢？还是主动的防御？你的竞争对手是谁？相对于他们，你的优势如何，短处又如何？ 只有你的设想符合了老板们的战略意图，才有可能得以有进一步讨论的空间。接着才会是风险的分析，项目的安排和实施。  01/08/11 22:31 酷帖！    臭帖！    回复   酷帖评价：           臭帖评价： 返回页首  suyyme   这就不光是分析设计的事了 建议你先做商业前景分析，特别要阐明作修改的商业理由。风险分析不可少，你要是别对项目影响的主要风险及其克服风险的手段，也就是风险缓解计划。可行性分析也需要，说明你想用什么方法来实现它，做出你的软件开发计划来。待老板批准后，你就可以进行设计了。下一不是什么？招人呗。  01/08/12 00:38 酷帖！    臭帖！    回复   酷帖评价：           臭帖评价： 返回页首  umlsz   回复: 这个分析如何写？？ 看不出重写的好处在哪？有那么资源不如作个全新的系统。  01/08/13 09:23 酷帖！    臭帖！    回复   酷帖评价：           臭帖评价： 返回页首  coldsnake   你的分析重點--經濟效益 其實老闆最關心的是經濟效益,所以本人個人認為你應該把側重點放在這兒. 不要在技術上過多注意細節問題,當然了,你的認為你又能里組織好項目的開發  01/08/13 10:24 酷帖！    臭帖！    回复   酷帖评价：           臭帖评价： 返回页首  儒商   这只是过方式、方法的问题。 用不用Rose，我认为只是个方式、方法的问题。 如果团队都习惯于原来的开发模式及方法，并且文档化工作也比较齐全， 而且考虑到市场进度的要求，还是不用为好。 待产品开发完后，再进行Rose的文档化工作，或提升团队的Rose分析、 开发能力。 因为改变工作方式，在一定程度上是提升了开发的风险，并且不能提升产品开发的效率及质量，它只是为以后的产品开发提供了较好的应用开发经验和熟练程度。  01/08/13 11:15 酷帖！    臭帖！    回复   酷帖评价：           臭帖评价： 返回页首  儒商   商业前景很重要，如果从这个层面来考虑，这实际上就是个商业计划书。 1.ERP在国内、国外的市场行情如何，客户对ERP的哪些是关心的？ 价格、服务、性能、品牌知名度... 市场容量有多大？ 2.国内、国外的访类软件的销售开发现况是什么？有何新的发展趋势？ 竞争对手的现状及趋势如何？ 3.开发该产品周期、人力等项目及风险分析 4.采取何种营销策略来推广该产品。费用多大，周期会有多长。 5.什么时候能走向润利期，润利规模会有多大？ 最好是抽取相关业务人员来进行市场信息的调研、分析。  01/08/13 11:35 酷帖！    臭帖！    回复   酷帖评价：           臭帖评价： 返回页首  billpan   不成熟的看法 考察最终用户 1）现实用户有没有对现系统升级改造的需求 2）新产品占领潜在市场的能力 考察新产品 1）新的项目需要多少投入 2）总体的开发时间 3）风险因素 考查投资回报 综合上面的情况得出投资回报 看起来真是商业计划书，可是要得到董事会的投资批准，又何尝不是一份商业计划  01/08/13 12:15 酷帖！    臭帖！    回复   酷帖评价：           臭帖评价： 返回页首  greatbear   回复: 这只是过方式、方法的问题。 其实我个人觉得Rose只是个工具，我遇到的问题是如何让开发人员改变以前的只写代码，不作分析或者说分析只在脑子里做的开发习惯，并转而接受Rose背后的OOA,OOD思想。而且非常遗憾的是我们并没有如你所说的“文档化工作也比较齐全”  01/08/13 18:39 酷帖！    臭帖！    回复   酷帖评价：           臭帖评价： 返回页首  jordan-gxj   回复: 这个分析如何写？？ ERP是一个非常大型非常复杂的系统，要投入大量的人力和物力，对于这样的项目一定要计划周全。我觉的你方法可以采取外包的方式。如果要自己开发设计，一定要有实际使用OOA、OOD及ROSE进行设计开发经验的人，另外可以分步分系统进行总结成功经验寻求老板（这点非常重要！！！）的支持再推而广之（Aim higher,start lowly!)。哥们，慎重一点吧。祝你好运！！！  01/08/13 22:32 酷帖！    臭帖！    回复   酷帖评价：           臭帖评价： 返回页首  mouri   回复: 这个分析如何写？？ 我不是在打击你，但你的理由确实不充分 1、当前系统的弱点； 这确实是个很有说服力的理由，但要与你所设想的新系统做比较才更具杀伤力 2、国内软件业界当前面临的问题； 这和你对旧系统改造关系很大吗？既然软件业面临那么多问题，董事会反倒会考虑是不是该压缩投资了，不说也罢 3、针对这些问题应该采取的对策； 对一个系统的改造，我认为还不足以应对如果有的危机 4、软件系统选型； 这实际是在做投入产出分析（也是风险分析的一部分），当然也应该包括硬件选型 说点个人的看法，改造一个系统，完全按照OO的方法，真不是好的方法，如果你们已经习惯了这样的方法则另当别论，否则会给人以“花公司钱练手”的感觉，尤其对刚刚接触OO或UML的人来说，会走很多弯路，这是学费，每个人都要交的，还有如果真象大家说的，IT业正面临危机，有哪家公司会考虑“大面积招新人”呢。还有做项目光有技术可行性是远远不够的，尤其是系统改造，还要考虑经济可行性、社会可行性等  01/08/14 09:27 酷帖！    臭帖！    回复   酷帖评价：           臭帖评价： 返回页首