可行性分析与需求分析
可行性分析是要决定“做还是不做”。
需求分析是要决定“做什么,不做什么”。
即使可行性分析是客观的、科学的,但决策仍有可能是错误的。因为决策者是人,人会冲动,有赌博心态。如果可行性分析表明做某件事的成功率是10%,失败率是90%,倘若该事情的意义非常大,决策者也许会一拍脑袋:“豁出去,干!”于是这世界就多了一份极喜与极悲。4.1节讲述可行性分析的四大要素:经济、技术、社会环境和人。
目前国内很多软件公司做系统集成项目,如果谈谈系统集成项目的可行性分析将很有意思。可是那些系统集成项目大多是政府机构的,由于软件行业尚不规范并且客户方存在腐败现象,所以业内流传“没有做不了的系统集成项目”。软件公司的注意力几乎全集中在“如何拿到项目订单”以及“拿到订单后如何蒙混过关”上,使我丧失了卖弄“可行性分析”的机会。既然不能正面指点一个人如何做好事,那么就规劝他不要做坏事吧。
4.2节讲述可行性分析案例——投资软件公司失败的教训。作者本来没有资格谈论投资,但事有凑巧:近一年来我关闭了一个亏损30万元的软件公司(我自己的);休克一个年亏损200万元的软件公司(朋友的);扼杀一个200万元的投资方案(陌生人的);踩灭一个处于萌芽状态的100万元的投资设想(熟人的)。鉴于现在比较富有的民营企业渴望投资软件行业的越来越多,值得谈谈这方面的可行性分析。我将讲述亲身经历后的感受,提一些建议。
不论是为客户做软件项目还是为自己做软件产品,都要进行需求分析。需求分析最恼人之处是难以在项目刚启动时搞清楚需求,如果在项目做了一大半时需求发生了变化,那将使项目陷入困境。4.3节解释需求分析为什么困难,4.4节讲述如何进行需求分析。本章的需求分析均不涉及编程,所以不考虑结构化、面向对象等分析方法。
4.1可行性分析的要素
做可行性分析不能以偏盖全,也不可以什么鸡毛蒜皮的细节都加以权衡。可行性分析必须为决策提供有价值的证据。
联想集团领导人柳传志曾说:“没钱赚的事我们不干;有钱赚但投不起钱的事不干;有钱赚也投得起钱但没有可靠的人选,这样的事也不干。”柳传志为决策立了上述准则,同时也为可以行性分析指明了重点。
一般地,软件领域的可行性分析主要考虑四个要素:经济、技术、社会环境和人。本节只是泛泛地解释这四个要素,旨在建立全局分析的观念。4.2节将结合案例围绕上述要素进行重点分析与评注。
4.1.1 经济
经济可行性分析主要包括:“成本——收益”分析和“短期——长远利益”分析。 1
一、成本——收益分析
成本——收益分析最容易理解,如果成本高于收益则表明亏损了,如果成本大大高于收益那就亏大了。商人都不喜欢做吃亏的事情。有些商店成天贴着“最后一天跳楼大拍卖”的标语,意思是:我准备吃大亏让你占便宜,同志,你快上钩吧。
如果是为客户做软件项目,那么收益就写在合同中。如果是做自己的软件产品,那么收益就是销售额。
人们在预估产品销售额时常常过分乐观而犯下大错。那些对你的产品说恭维话的人并不见得就是要买货的人,俗话说“嫌货才是买货人”。当你没碰到一个挑刺的人而感觉这产品好得会让你发大财时,就要做好会破产的心理准备。
如果做的是小本生意,那可得对成本进行细算。软件的成本不是指存放软件的那张光盘的成本,而是指开发成本。要考虑的成本有:
(1)办公室房租。
(2)办公用品,如桌、椅、书柜、照明电器、空调等。
(3)计算机、打印机、网络等硬件设备。
(4)电话、传真等通讯设备以及通讯费用。
(5)资料费。
(6)办公消耗,如水电费、打印复印费等。
(7)软件开发人员与行政人员的工资。
(8)购买系统软件的费用,如买操作系统、数据库、软件开发工具等。有些老板买盗版的系统软件,却按市场价算成本,可从美国佬那里赚一笔。
(9)做市场调查、可行性分析、需求分析的交际费用。
(10)公司人员培训费用。
(11)产品宣传费用。如果用Internet作宣传,则要考虑建设Web站点的费用。
(12)如果客户是政府部门,还要充分考虑用于吃喝玩乐、行贿的费用。
(13)如果公司的风水不好,会有很多莫名其妙的管理费。每戳一个红艳艳的公章都要化一把钞票。
二、短期——长远利益分析
人们喜欢吃着碗里的、看着锅里的,还想着别人家里的。短期利益和长远利益兼得是人们梦寐以求的事。在商业上,这等好事可不会轻易降临。
短期利益容易把握,风险较低。国内软件公司经常出现一窝蜂地去做信息管理系统、多媒体光盘、系统集成项目或Internet服务。每当我们沉迷于短期利益不思进取时,应该好好回忆童年时代那些伟大的抱负,给自己一些激励。
长远利益难以把握,风险较大。能为了长远利益不惜短期亏损的人,要么是雄心勃勃的将帅之才,要么是“纸上谈兵”、“眼高手底”的那一类庸人。国内目前有不少Internet企业,只投入不产出。为了成就将来的霸业,甘愿现在拼财力、比耐性。最后存活下来的几个公司将瓜分市场。
那些为长远利益奋斗的人们,你们可得把长征的路途走完啊,千万别让事业中途夭折。 2
4.1.2 技术
技术可行性分析至少要考虑以下几方面因素:
(1)在给定的时间内能否实现需求说明中的功能。如果在项目开发过程中遇到难以克服的技术问题,麻烦就大了。轻则拖延进度,重则断送项目。
(2)软件的质量如何?有些应用对实时性要求很高,如果软件运行慢如蜗牛,即便功能具备也毫无实用价值。有些高风险的应用对软件的正确性与精确性要求极高,如果软件出了差错而造成客户利益损失,那么软件开发方可要赔惨了。
(3)软件的生产率如何?如果生产率低下,能赚到的钱就少,并且会逐渐丧失竞争力。在统计软件总的开发时间时,不能漏掉用于维护的时间。软件维护是非常拖后腿的事,它能把前期拿到的利润慢慢地消耗光。如果软件的质量不好,将会导致维护的代价很高,企图通过偷工减料而提高生产率,是得不偿失的事。
技术可行性分析可以简单地表述为:做得了吗?做得好吗?做得快吗?
4.1.3 社会环境
社会环境的可行性至少包括两种因素:市场与政策。
市场又分为未成熟的市场、成熟的市场和将要消亡的市场。
涉足未成熟的市场要冒很大的风险,要尽可能准确地估计潜在的市场有多大?自己能占多少份额?多长时间能实现?
挤进成熟的市场,虽然风险不高,但油水也不多。如果供大于求,即软件开发公司多,项目少,那么在竞标时可能会出现恶性杀价的情形。国内第一批卖计算机的、做系统集成的公司发了财,别人眼红了也挤进来,这个行业的平均利润也就下降了。
将要消亡的市场就别进去了。尽管很多程序员怀念DOS时代编程的那种淋漓尽致,可现在没人要DOS应用软件了。学校教学尚可用用DOS软件,商业软件公司则不可再去开发DOS软件。
政策对软件公司的生存与发展影响非常大。整个90年代,中国电信的收费相当高,仅此一招就把国内互联网企业打得奄奄一息。某些软件行业的利润很高,但可能存在地方保护政策,使竞争不公平。政策不当将阻碍软件公司的健康发展,可最怕的还是政府干预企业的正当行为。例如:
现在家电行业竞争非常激烈,其中有一个著名企业的总裁十分了得,把对手打得节节败退。于是中央领导人就来视察该企业并作讲话:“你们的业绩辉煌,得到了中央的高度重视,……但我们是社会主义国家,不是资本主义国家,你们总得给兄弟企业的同志们留口饭吃吧!”
有一次我拜访了北京大学一位研究经济学的朋友。这个年青人,还是个党员,竞然这么说:“我最近在研究国内明星企业的兴衰问题,我发现了一个规律,明星企业一旦被政府领导人视察过,它就忘了自己是谁,就会做些走向死亡的蠢事。”
我实在不明白企业中为什么还要有“书记”职位。我以为“书记”乃是天下第一号可笑的官衔,“书记”本是“秘书”(secretary)的同义词,是个可有可无的行政人员的称呼,在中国竟然成了最大的官衔。每次看到新闻联播把国家主席错叫成***我都十分气愤:因为***的称喟只对几千万的党员适用,国家的新闻机构难道不面向十多亿
3
普通老百姓?如果我将来的工作单位还靠“书记”来管事,我每天准忙着生气,那里还有精力去编程。
4.1.4 人
有句名言:“人分四类——人物,人才,人手,人渣。”
如果一个软件公司里上述四类人齐全了,那么最好的分工是让“人物”当领导,“人才”做第一线的开发人员,“人手”做行政人员,“人渣”负责行贿。
这里只谈公司的领导与开发人员“行还是不行”。“人物”毕竟是少数,“人才”可是济济的。举重若轻的那类“人才”可以做领导,举轻若重的那类人才适合做软件开发人员。假如一群持有学士、硕士和博士文凭的毕业生到软件公司应聘,该如何录用呢?我的建议如下:
先选择本科毕业生,因为他们正当青春、干劲十足、不摆架子、不耻下问、要求不高、奉献甚多。
其次选择硕士毕业生,如果该生没象范进中举时那么老,并且在读硕士时没有天天去造文章而丢弃了编程工作,那么让有经验的学士程序员带他们煅练几个月就可以用了。
如果学士、硕士被其它公司取光了,那只好捡几个博士充数。博士到了软件公司有什么用呢?我想不出有什么用,只知道他们挺值得可怜的:从硕士读到博士出头,这六七年时间,真本事没学多少,倒学会“眼高手低”甚至“弄虚作假”;毕业时蓦然回首,发觉青春已被虚度,心灵已呈老态,唯有长叹短嘘,强把自负作自信。我也将博士毕业,就要论为三手贷贱卖了。真羡慕那些比我年轻的学士、硕士们,他们可以远走高飞,唉!
软件项目分析需求
需求分析,我刚做了个项目就用它,不知道是不是你想要的
1引言 2
1.1编写目的 2
1.2背景 2
1.3定义 2
1.4参考资料 2
2任务概述 2
2.1目标 2
2.2用户的特点 3
2.3假定和约束 3
3需求规定 3
3.1对功能的规定 3
3.2对性能的规定 3
3.2.1精度 3
3.2.2时间特性要求 3
3.2.3灵活性 4
3.3输人输出要求 4
3.4数据管理能力要求 4
3.5故障处理要求 4
3.6其他专门要求 5
4运行环境规定 5
4.1设备 5
4.2支持软件 5
4.3接口 5
4.4控制 5
软件需求说明书的编写提示
1引言
1.1编写目的
说明编写这份软件需求说明书的目的,指出预期的读者。
1.2背景
说明:
待开发的软件系统的名称;
本项目的任务提出者、开发者、用户及实现该软件的计算中心或计算机网络;
该软件系统同其他系统或其他机构的基本的相互来往关系。
1.3定义
列出本文件中用到的专门术语的定义和外文首字母组词的原词组。
1.4参考资料
列出用得着的参考资料,如:
本项目的经核准的计划任务书或合同、上级机关的批文;
属于本项目的其他已发表的文件;
本文件中各处引用的文件、资料、包括所要用到的软件开发标准。 列出这些文件资料的标题、文件编号、发表日期和出版单位,说明能够得到这些文件资料的来源。
2任务概述
2.1目标
叙述该项软件开发的意图、应用目标、作用范围以及其他应向读者说明的有关该软件开发的背景材料。解释被开发软件与其他有关软件之间的关系。如果本软件产品是一项独立的软件,而且全部内容自含,则说明这一点。如果所定义的产品是一个更大的系统的一个组成部分,则应说明本产品与该系统中其他各组成部分之间的关系,为此可使用一张方框图来说明该系统的组成和本产品同其他各部分的联系和接口。|
2.2用户的特点
列出本软件的最终用户的特点,充分说明操作人员、维护人员的教育水平和技术专长,以及本软件的预期使甩频度。这些是软件设计工作的重要约束
2.3假定和约束
列出进行本软件开发工作的假定和约束,例如经费限制、开发期限等。
3需求规定
3.1对功能的规定
用列表的方式(例如IPO表即输入、处理、输出表的形式),逐项定量和定性地叙述对软件所提出的功能要求,说明输入什么量、经怎样的处理、得到什么输出,说明软件应支持的终端数和应支持的并行操作的用户数。
3.2对性能的规定
3.2.1精度
说明对该软件的输入、输出数据精度的要求,可能包括传输过程中的精度。
3.2.2时间特性要求
说明对于该软件的时间特性要求,如对:
响应时间;
更新处理时间;
数据的转换和传送时间;
解题时间;等的要求。
3.2.3灵活性
说明对该软件的灵活性的要求,即当需求发生某些变化时,该软件对这些变化的适应能力,如:
操作方式上的变化;
运行环境的变化;
同其他软件的接口的变化;
精度和有效时限的变化;
计划的变化或改进。
对于为了提供这些灵活性而进行的专门设计的部分应该加以标明。
3.3输人输出要求
解释各输入输出数据类型,并逐项说明其媒体、格式、数值范围、精度等。对软件的数据输出及必须标明的控制输出量进行解释并举例,包括对硬拷贝报告(正常结果输出、状态输出及异常输出)以及图形或显示报告的描述。
3.4数据管理能力要求
说明需要管理的文卷和记录的个数、表和文卷的大小规模,要按可预见的增长对数据及其分量的存储要求作出估算。
3.5故障处理要求
列出可能的软件、硬件故障以及对各项性能而言所产生的后果和对故障处理的要求。
3.6其他专门要求
如用户单位对安全保密的要求,对使用方便的要求,对可维护性、可补充性、易读性、可靠性、运行环境可转换性的特殊要求等。
4运行环境规定
4.1设备
列出运行该软件所需要的硬设备。说明其中的新型设备及其专门功能,包括:
处理器型号及内存容量;
外存容量、联机或脱机、媒体及其存储格式,设备的型号及数量;
输入及输出设备的型号和数量,联机或脱机;
数据通信设备的型号和数量;
功能键及其他专用硬件
4.2支持软件
列出支持软件,包括要用到的操作系统、编译(或汇编)程序、测试支持软件等。
4.3接口
说明该软件同其他软件之间的接口、数据通信协议等。
4.4控制
说明控制该软件的运行的方法和控制信号,并说明这些控制信号的来源。
软件工程与软件项目管理的分析
这个题目不知是要分析些什么?是分析软件工程与软件项目管理的差别,还是分析两者的作用?
分析软件工程与软件项目管理的差别比较简单啦,分别说明两者的内容以及在软件项目执行过程中所起的作用即可,这个对于学习过软件工程和项目管理的人来说应该不是什么难事吧。
若是分析两者的作用则相对比较复杂些,可以从软件工程和软件项目管理的内容(软件工程:规划、需求调研、需求分析、系统设计、编码开发、测试、发布等,项目管理:九大知识领域)开始入手,再说明两者在软件开发项目过程中的相互作用和影响范围,就基本上可以将两者的作用说明清楚。如在软件工程中的规范阶段,如何利用项目管理的知识领域对其产生正面影响,或利用哪些知识领域进行影响、产生哪些影响等等;或在软件项目管理过程中的不同领域中使用到哪些软件工程的阶段或知识、产生什么影响等等。
总之,软件工程与软件项目管理是软件项目中两个不同的管理角度,两者可以相辅相承、共同作用于软件项目,使软件项目能够以更高效、更低成本的目标完成。
软件项目计划和需求分析哪个先?
可以先制定项目,然后在进行调查完成需求分析,再在需求分析的基础上,对所写的项目启动进行修改完善!
项目案例分析
案例一解决:
1、前期OA项目已经试运行,在前期项目调研中没有这块需求,如实沟通给副局长,沟通进行阶段性(无劳资)这块的验收。
2、向这个副局长请教,并由他牵头,做劳资方面需求,给出解决方案,报价,再次销售。
案例二解决:
1、委婉通知对方提前验收。理由系统运行情况很好已经符合验收标准,为领导节约时间。
2、张局长可以委派其他人处理。
案例三解决:
1、要弄清楚客户什么原因提出的这个需求。
一般解决应该为:PRO/E的接口应该客户协调对方软件提供。他们用的是盗版,肯定提供不出来。向对方要接口文件进行方案探讨。为保证整体项目,分阶段实现,先将一阶段需求实现,其他可以放在二阶段解决。
软件开发过程一般有几个阶段
软件开发一般分为五个阶段:
1.问题的定义及规划
此阶段是软件开发与需求放共同讨论,主要确定软件的开发目标及其可行性。
2.需求分析
在确定软件开发可行性的情况下,对软件需要实现的各个功能进行详细需求分析。需求分析阶段是一个很重要的阶段,这一阶段做的好,将为整个软件项目的开发打下良好的基础。“唯一不变的是变化本身”,同样软件需求也是在软件爱你开发过程中不断变化和深入的,因此,我们必须定制需求变更计划来应付这种变化,以保护整个项目的正常进行。
3.软件设计
此阶段中偶要根据需求分析的结果,对整个软件系统进行设计,如系统框架设计、数据库设计等。软件设计一般分为总体设计和详细设计。还的软件设计将为软件程序编写打下良好的基础。
4.程序编码
此阶段是将软件设计的结果转化为计算机可运行的程序代码。在程序编码中必定要制定统一、符合标准的编写规范。以保证程序的可读性、易维护性。提高程序的运行效率。
5.软件测试
在软件设计完成之后要进行严密的测试,一发现软件在整个软件设计过程中存在的问题并加以纠正。整个测试阶段分为单元测试、组装测试、系统测试三个阶段进行。测试方法主要有白盒测试和黑盒测试。
以上就是软件开发过程的五个阶段,但是有的时候在软件爱你开发过程中并不是必须按照这个过程进行的。
参考资料:软件工程
怎样做软件的需求分析?
软件需求的定义:
(1)用户解决问题或达到目标所需的条件或能力。
(2)系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或能力。
(3)一种反映上面(1)或(2)所描述的条件或权能的文档说明。 实通俗的讲,“需求”就是用户的需要,它包括用户要解决的问题、达到的目标、以及实现这些目标所需要的条件,它是一个程序或系统开发工作的说明,表现形式一般为文档形式。
需求工程的定义:
需求分析的过程,也叫做需求工程和需求阶段,它包括了需求开发和需求管理两个部分。需求开发是指从情况收集、分析和评价到编写文档、评审等一系列产生需求的活动,分为四个阶段:情况获取、分析、制订规格说明和评审。这四个阶段不一定是遵循线性顺序的,他们的活动是相互独立和反复的。需求管理是软件项目开发过程中控制和维持需求约定的活动,它包括:变更控制、版本控制、需求跟踪、需求状态跟踪等工作。
需求开发与管理的一些方法:
(1)绘制关联图:绘制系统关联图是用于定义系统与系统外部实体间的界限和接口的简单模型。
(2)可行性分析:在允许的成本、性能要求下,分析每项需求实施的可行性,提出需求实现相关风险,包括与其它需求的冲突,对外界因素的依赖和技术障碍。
(4)系统原型:当用户自身对有的需求不十分清楚时,我们可以建立一个系统原型,用户通过评价原型更好地理解所要解决的问题。。
(5)图形分析模型:绘制图形分析模型是编制软件需求规格说明重要手段。它们能帮助分析人员理清数据、业务模式、工作流程以及他们之间的关系,找出遗漏、冗余和不一致的需求。这样的模型包括数据流图、实体关系图、状态变换图、对话框图、对象类及交互作用图。
(6)数据字典:数据字典是对系统用到的所有数据项和结构的定义,以确保开发人员使用统一的数据定义。在需求阶段,数据字典至少应定义客户数据项,确保客户与开发小组是使用一致的定义和术语。
需求管理的方法主要包括以下一些方面:
1)确定需求变更控制过程。制定一个选择、分析和决策需求变更的过程,所有的需求变更都需遵循此过程。
2)进行需求变更影响分析。评估每项需求变更,以确定它对项目计划安排和其它需求的影响,明确与变更相关的任务并评估完成这些任务需要的工作量。通过这些分析将有助于需求变更控制部门做出更好的决策。
3)建立需求基准版本和需求控制版本文档。确定需求基准,这是项目各方对需求达成一致认识时刻的一个快照,之后的需求变更遵循变更控制过程即可。每个版本的需求规格说明都必须是独立说明,以避免将底稿和基准或新旧版本相混淆。
4)维护需求变更的历史记录。将需求变更情况写成文档,记录变更日期、原因、负责人、版本号等内容,及时通知到项目开发所涉及的人员。为了尽量减少困惑、冲突、误传,应指定专人来负责更新需求。
5)跟踪每项需求的状态。可以把每一项需求的状态属性(如已推荐的,已通过的,已实施的,或已验证的)保存在数据库中,这样可以在任何时候得到每个状态类的需求数量。
6)衡量需求稳定性。可以定期把需求数量和需求变更(添加、修改、删除)数量进行比较。过多的需求变更"是一个报警信号",意味着问题并未真正弄清楚。
4.需求分析评价标准
(1)清晰:目前大多数的需求分析采用的仍然是自然语言,自然语言对需求分析最大的弊病就是它的二义性,所以开发人员需要对需求分析中采用的语言做某些限制。例如尽量采用主语+动作的简单表达方式。需求分析中的描述一定要简单,千万不要采用疑问句、修饰这些复杂的表达方式。 除了语言的二义性之外,注意不要使用行话,就是计算机术语。需求分析最重要的是和用户沟通,可是用户多半不是计算机的专业人士,如果在需求分析中使用了行话,就会造成用户理解上的困难。
(2)完整:需求的完整性是非常重要的,如果有遗漏需求,则不得不返工,在软件开发过程中,最糟糕的事情莫过于在软件开发接近完成时发现遗漏了一项需求。但实际情况是,需求的遗漏是常发生的事情,这不仅仅是开发人员的问题,更多发生在用户那里。要做到需求的完整性是很艰难的一件事情,它涉及到需求分析过程的各个方面,贯穿整个过程,从最初的需求计划制定到最后的需求评审。
(3)一致:一致性是指用户需求必须和业务需求一致,功能需求必须和用户需求一致。在需求过程中,开发人员需要把一致性关系进行细化,比如用户需求不能超出预前指定的范围。严格的遵守不同层次间的一致性关系,就可以保证最后开发出来的软件系统不会偏离最初的实现目标。
(4)可测试:一个项目的测试从什么时候开始呢?有人说是从编码完成后开始,有人说是编码的时候同时进行单元测试,编码完成后进行系统测试,这些结论都不完全正确。实际上,测试是从需求分析过程就开始了,因为需求是测试计划的输入和参照。这就要求需求分析是可测试的,只有系统的所有需求都是可以被测试的,才能够保证软件始终围绕着用户的需要,保证软件系统是成功的。
转载请注明出处51数据库 » 软件项目分析 如何对软件项目进行可行性分析