软件可行性分析

如果在项目启动之前对需求还仅仅停留在表面上,就不要做了,肯定控制不住,注定亏本。 如果还要在项目中大量的编写源代码,进行测试,就别做了,开发能开发出来,变更、完善也要一定的周期阿。

如果一个月时间的项目,需求并不十分明确,要估计一下两个星期能否把设计、开发、测试搞完,如果搞不完就别做了,因为周期肯定会超过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、没有真正的设计过程 开发人员少,意味着不同人员的程序之间交互、接口相对少一些。开发周期短意味着往往是同样的几个人从头到尾负责一个项目。这两者都让人容易犯些错误。往往是几个人碰一下头,讨论一下最基本的数据结构、函数接口便分头去做自己的工作了,没有一份较正式的文档。 这种做法潜在的危险之一是有的人可能会对讨论出的接口、结构理解有偏差(应该承认人是会犯错误的)。一个误解可能造成以后的返工。 另一个潜在的危险是由于讨论时忽略了某些情况,等大家都按当时的分工完成属于自己的工作后,才发现各个模块组合起来却形不成一个完整的系统。其根源在于没有一个负责协调的人员不断监控整个开发过程。 第三个潜在的危险是一旦有人中途退出开发队伍,其他人加入时,新来的人难以理解以前别人做好的代码,索性自己从头来。另外,没有文档的程序,日后维护和版本升级都比较困难。 3.不经过单元测试而直接进入系统测试 造成这一现象的原因是每个模块相对比较简单,但是为了测试一个模块需要建立一些测试环境。例如,为了测试一个函数是否正确,应该用一些测试数据去调用该函数,需要编写一些测试数据。但很多开发人员嫌麻烦,觉得反正其他模块也很快出来了,直接用真正的数据来运行几次就行了。 殊不知,一旦直接进入系统测试,发现运行结果不正确后需要一步步查找。由于模块间的调用关系,可能查了很久才发现是某个模块的问题。这种方法一来效率比较低,大量的时间用在了将一个错误定位在模块上了。另外由于这种测试不完全,真正运行系统,当调用某模块时,可能大部分时候都是正常数据,极少出现边界情况,可能某些边界情况容易被忽视,很久之后才被发现。但是如果对每个模块进行单元测试时都进行一下边界测试,就会很容易消除一些隐患。真可谓欲速则不达也。三.合理的开发流程 合理的开发模式,一句话形容就是“麻雀虽小,五脏俱全”,即使是小型项目的开发,仍然应该遵循软件开发的一般规律,必须的步骤不能省略。但是小项目有它自身的一些特点,实行起来可以相对灵活些。 以下我从几个方面描述一下我认为比较合理的模式.1.需求获取 在进入正式开发之前,必须先从用户处获取准确的需求。在这上面花费相当时间是很必要的。 软件项目可以大致分为专用软件和通用软件两大类。 对于专用软件,例如给某单位开发一套该单位专用的系统,一般用户对于软件 但是,开发合同上规定的只是一个大概的框架,在进入开发之前必须与用户进行比较具体的交流和讨论,了解清楚用户心目中的产品究竟是什么样子。这个步骤如果没有好好做,往往到了开发工作的后期才发现开发人员的理解和用户的要求有一些误解,那么必然造成时间上的浪费。 对于通用软件,在开发之前应该做一定的市场调查工作,一方面是从经济效益考虑,调查产品的潜在市场有多大,另一方面是从技术的角度,必须了解清楚潜在用户对软件的各种技术上的要求,例如,用户现有硬件配置如何,软件配置如何,使用什么网络,使用什么数据库等等,根据调查的统计结果决定即将开发的软件的一些技术指标。 为了比较好地与用户进行交流,使用一些工具是很有好处的。 为了讨论用户界面,可以用VB,delphi等做一个原型,根据原型有针对性地与用户讨论需求。(原型开发不仅仅可以用于准确获取用户的需求,开发出来的原型本身可以作为下一步开发的基础,增量式地完成开发) 为了讨论软件运行的流程,可以采用UML的UseCase图。2.需求分析 在了解用户的需求之后,将需求用一种模型来表示,就是需求分析,目前比较流行的分析方法是面向对象的方法,通过分析用户需求,用类、类之间的各种关系来表示整个系统。 这部分涉及到具体的方法,在此不详细讨论,但是原则上是提取类->类之间关系,可能需要不断修改而形成一份分析文档。 我想强调几个问题。 一是要分清问题域与系统责任。系统责任是指所要开发的软件应该完成的功能,而问题域是包含所有相关的部分。例如你要开发一个程控机计费程序,程控机已经是现成,输出的数据格式也已经是固定的,你的程序仅仅需要从程控机中读取相应的信息,那么,程控机在你的系统里只是一个外部的东西,把它作为一个类也许就是不必要的,仅仅需要一个类来完成读数据的操作。又

如,你需要在一个已经存在的数据库上开发一些应用,数据库的格式已经固定,并且已经有一个后台程序在运行,你需要开发一个新的前台程序,这时,服务器程序对你来说就是一个外部的东西。但是,象这种外部的内容必须在分析文档中有一些说明,作为系统的外在约束。 二是需求获取与需求分析的关系。 用什么方法来完成需求的获取,在很大程度上影响了需求分析的做法。 例如当初采用UseCase来表示用户需求,那么从各种序列图中选出相互交互的各个实体,就是一个个类。 三是分析与设计过程的衔接。 分析过程的内容是用类的结构来表示目标系统,并不设计具体实现,如采用什么编程语言,在什么操作系统平台上运行等等。这些具体实现是在设计阶段来完成的。面向对象方法的优点是分析、设计、编码过程表示法统一,能比较好的衔接。但是,是把分析和设计阶段分开,采用瀑布式开发,还是采用其他方式,要看具体的情况。 对于需求潜在变化不大的项目,可以采用瀑布模型,有一个很明显的设计阶段,这样做的好处是有一份比较完整的分析文档,这样以后如果需要采用不同的编程语言、或者采用其他的平台时,便可以以这份分析文档作为开发的基础。 对于需求变化频繁的项目,可能采用少量分析;少量设计少量编码测试的方式更合适,而且随时可能要返回到前面某个一阶段去进行修改。但是这意味着可能没有一份完整的分析文档。 现在很多CASE工具并不区分分析和设计的阶段。但是,这并不意味着开发就可以对分析和设计不加区分,CASE工具如同一支笔,如何用好还得还人。3.设计过程 设计阶段的工作包括: 对分析模型必要的修改。可能需要对某定义界面部分、数据访问(数据库)部分。 由于目前很多编程语言都可以可视化地设计界面,所以界面部分工作往往留到了编码阶段来完成。于是设计阶段的工作量并不大。4.编码 进入编码工作之后,可能会发现前面分析或设计阶段的某些错误,这时应返回到前面的阶段进行必要的修改。5.测试 如前所述,即使是小项目,也应该严格地进行测试。四、人员的安排 比较小的项目,往往是几个人来完成,这几个人基本上从头到尾参加开发。在这几个人中,有一位项目负责人,负责分析、设计和协调的工作。由于项目小,项目负责人也要参加编程,那么这人必须把时间合理运用, 经验告诉我几条原则: 1.协调几个人的工作比自己完成一段编码更重要. 由于协调上出了漏洞,可能导致很大的问题,所以项目负责人必须随时监控各开发人员的工作,包括内容是否与要求发生偏差,进度是否滞后等等。 只有在完成这些工作之后,项目负责人剩下的时间才能用于编程。 2.给每个开发人员明确的任务书. 不管是用面向对象或者其他方法开发,分析、设计模型只是从功能的角度来描述系统。但是,具体开发时每个开发人员必须非常明确自己的任务,这些任务应该采用明确的文档来表示。 3.让大家都大致熟悉设计模型. 让每个开发人员都清楚自己所做的工作在整个系统中处于什么地位,有时侯可能会发现设计模型中的漏洞,避免了各人的代码编写完毕之后又要修改的后果。

软件开发是一项复杂的系统工程,牵涉到各方面的因素,实际工作中,经常会出现各种各样的问题,甚至面临失败。如何总结、分析失败的原因

软件开发是一项复杂的系统工程,牵涉到各方面的因素,实际工作中,经常会

出现各种各样的问题,甚至面临失败。如何总结、分析失败的原因,得出有益的教训,对一个公司来说,是在今后的项目中取得成功的关键。这是我们经常遇到的问题。一方面,由于客户(需求方)IT知识缺乏,一开始自己也不知道要开发什么样的系统,或者懒于系统地整理出来,经常是走一步算一步,不断地提出和更改需求,使得实现方叫苦连天。另一方面,实现方由于行业知识的缺乏和设计人员水平的低下,不能完全理解客户的需求说明,而又没有加以严格的确认,经常是以想当然的方法进行系统设计,结果是推倒重来。因此,需求分析必须注重双方理解和认识的一致,逐项逐条地进行确认。

软件开发的工数估算是一项很重要的工作,必须综合开发的阶段、人员的生产率、工作的复杂程度、历史经验等因素,将一些定性的内容定量化。对工数的重要性认识不足,经常用拍脑袋的方式草算,是最常见的问题。还有,软件开发经常会出现一些平时不可见的工作量,如人员的培训时间、各个开发阶段的评审时间等,经验不足的项目经理经常会遗漏。同时,还有如下一些原因也是很典型的:

(1)出于客户和公司上层的压力在工数估算上予以妥协。例如,客户威胁要用工数更少的开发商,公司因经营困难必须削减费用、缩短工期,最后只能妥协,寄希望于员工加班。

(2)设计者过于自信或出于自尊心问题,对一些技术问题不够重视,或者担心估算多被嘲笑。

(3)过分凭经验。由于有过去的成功经验,没有具体分析就认为这次项目估计也差不多,而没有想到这次项目可能规模更大、项目组成员更多、素质各异、新员工很多,而且是一个新的行业。每个公司都希望以最少的成本完成项目,人手不足是大多数项目都会面临的问题。还有一种情况是项目组成员的技术水平达不到项目的要求,公司只能提供这些分配好的技术人员,或者由于项目经理的失误,在项目工数估算时没有明确要求技术水平,寄希望于员工自己努力。还有一些项目经理认为,在项目启动时不需要高水平的技术人员。没有良好的开发计划和开发目标,项目的成功就无从谈起。开发计划太粗略,主要反映在以下几个方面:

(1)工作分担(责任范围)不明确,工作分割结构(WBS)与项目组织结构不明确或者不相对应,各成员之间的接口不明确,导致有一些工作根本无人负责。

(2)每个开发阶段的提交结果定义不明确,中间结果是否已经完成,完成了多少模糊不清,结果是到了项目后期堆积了大量工作。

(3)开发计划没有指定里程碑或检查点,也没有规定设计评审期。

(4)开发计划没有规定进度管理方法和职责,导致无法正常进行进度管理。 项目组设计人员能力的低下是项目失败的原因之一。一方面,由于对技术问题的难度未能正确评价,将设计任务交给了与要求水平不相称的人员,造成设计结果无法实现。另一方面,随着资源外包现象的日益普遍,一些公司经常因工期紧而匆忙将中标的项目部分转包给其他协作公司,这些公司的设计能力如不加仔细评价,就会对整个项目造成影响。没有及时把握进度。项目经理自己也不知道项目的状态,下属人员报喜不报忧,害怕报告问题后给自己添麻烦。进度管理必须随时收集有关项目管理的数据,开发人员总是担心管理工作会增加自己的工作量,不愿配合。管理人员甚至不知道应该收集哪些数据。

由于没有进行定期的项目评审报告会,表面上进展顺利而实际上隐藏着危机。管理人员总是轻信下属的报告而没有加以核实。

出现严重问题时,管理人员没有根据现阶段状况重新评价需求分析结果、工数估算、设计结

果等就匆忙采取头痛医头、脚痛医脚的措施,致使问题更严重。

以上谈到了项目失败的几方面原因,实际上还有很多原因,很难一一列举。在这里我们没有篇幅提出如何避免这些问题的对策,但是通过这些原因的列举,希望能激起读者的共鸣。


© 2021 实用范文网 | 联系我们: webmaster# 6400.net.cn