2015年软件可行性分析.docVIP

如果在项目启动之前对需求还仅仅停留在表面上，就不要做了，肯定控制不住，注定亏本。如果还要在项目中大量的编写源代码，进行测试，就别做了，开发能开发出来，变更、完善也要一定的周期阿。如果一个月时间的项目，需求并不十分明确，要估计一下两个星期能否把设计、开发、测试搞完，如果搞不完就别做了，因为周期肯定会超过1个月，做下来还是亏。还有像这样的小项目最好一个人做，人多了沟通成本就会变成累赘。1．项目开始时，小组应有统一编程规范，包括界面外观标准和操作控制要求。2．计划项目时间并保证按时交付，需要用2周时间来编写程序，1周单元测试（可以交叉测试），1周集成测试。3．项目经费不要考虑如何分配了，另外1万到手才分配；利润呢，去处发生的成本，在计算30％的维护费用吧；4．在什么情况下，项目完全没有利润？超期1周就没有利润了；5．如果在第一周末，有一人的模块不能按时交付，应当采取措施是说明情况，调整计划。6．如果不得以突破交付期，应当先谈判，部分交付！7．如果开发过程中一人因故不能工作（如生病），应当有什么措施？ 缩小工作量。8．测试应当在何时介入，总体测试应当注意什么？第一个界面就看看；整体测试注意彼此的连接和风格一致。9．如何保证开发过程顺利推进？保证进度和程序质量？项目负责人应该详细分解任务、分析任务，把类似的任务分给同一个人；自己的编程时间少些，为检查留出时间。10．不可预知（意外）因素可能有哪些影响项目开发？ ·project顺利完成中的有效控制方案(2003-10-31)?? [作 者] 马金君? [公 司] 洁具公司 项目开始时，小组首先应明确各人负责的程序块内容和报酬分配标准，同时应制定阶段性的控制的具体事项（质量标准，项目执行速度，成本预算等）。其次预备一个以应付非正常因素的方案。其中人力资源搭配上也必须确保至少有一人懂得整个程序的编制，以应付不可预知的因素的出现。将整个程序划分为项目周期内的几个阶段，和但必须安排一个备用阶段，以应付非预期性因素的出现来确保项目按时交付。最后利润应以按时和延期交付分别来估算。延期一个阶段视为无利润。如果在第一周末，有一人的模块不能按时交付应执行小组协议，以尽快的速度来完成初期阶段的工作。如果不得以突破交付期，应事先重新估算项目周期和通知客户延期时间。在保证进度和程序质量方面除了阶段性控制外，同时还要做好其他不可预知因素出现的心里准备和估计可能会出现非正常因素出现的解决方案。不可预知因素我认为有以下几点，1 人事变动 2 程序编制过程出现新的问题，例如无法满足客户要求等 3 预算周期内其他人为因素，例如项目性质或内容变更，客户没有履行承诺等。 小软件项目开发的管理 ======　 网友上传2008-11-16 23:30:45　　一个企业的管理，大公司有大公司的方式，小公司也有小公司的方式，如果把别人的经验生搬硬套到自己身上，可能会适得其反。同样，管理一个软件项目也一样，大项目和小项目的方式不完全一样。但从另一个角度来看，项目的大与小并没有本质的区别，很多方法是共通的。本文的目的是从作者的经验来谈谈小项目开发的管理。一、小项目的特点　大家知道，“软件危机”的出现起源于一些大型项目的不断延迟甚至失败。小项目相比之下，具有以下特点:　1.项目功能相对较少　2.开发人员较少　3.开发周期较短　　另外，在现实中，有很多小项目是由一些中小公司进行开发的，这些公司往往人员流动性较大，这也是不容忽视的一个现实.二、小项目开发中常犯的错误　　　　小项目看起来比较简单，比较容易成功，因而人们往往忽视了小项目的管理，其实这是一种误解，从本人的经验看来，小项目开发中容易犯以下的一些错误:　　1、开发之前没有认真地进行项目可行性和工作量的估计。　　往往由于项目较小，便很草率地制定一个开发日程表，没有认真地估计项目难度，结果实际完成时间与估计完成时间往往有较大差别。　　2、没有真正的设计过程　　开发人员少，意味着不同人员的程序之间交互、接口相对少一些。开发周期短意味着往往是同样的几个人从头到尾负责一个项目。这两者都让人容易犯些错误。往往是几个人碰一下头，讨论一下最基本的数据结构、函数接口便分头去做自己的工作了，没有一份较正式的文档。　　这种做法潜在的危险之一是有的人可能会对讨论出的接口、结构理解有偏差(应该承认人是会犯错误的)。一个误解可能造成以后的返工。　　另一个潜在的危险是由于讨论时忽略了某些情况，等大家都按当时的分工完成属于自己的工作后，才发现各个模块组合起来却形不成一个完整的系统。其根源在于没有一个负责协调的人员不断监控整个开发过程。　　第三个潜在的危险是一旦有人中途退出开发队伍，其他人加入时，新来的人难以理解以前别人做好的代码，索性自己从头来。另外，没有文档的程序，日后维护和