软件项目设计和开发评审要求有哪些呢?
a)设计和开发评审应分级进行。
公司级的项目应进行公司级评审;业务部门级的项目一般进行业务部门级评审; b)设计和开发评审视具体情况可一次进行,也可分段进行; c)评审结论应明确; d)评审资料应及时归档。
6 评审依据 a)合同、技术协议书、需求规格说明书和设计任务书; b)有关标准、规范和质量保证文件。
7 评审内容 评审的内容可根据产品设计的研制周期、技术难度、复杂程度以及使用方的要求有所侧重和适当的增减,但应满足对设计结果进行评审的要求。
主要内容: a)设计方案正确性、先进性、可行性和经济性; b)系统组成、系统要求及接口协调的合理性; c)系统与各子系统间技术接口的协调性; d)采用设计准则、规范和标准的合理性; e)系统可靠性、维修性、安全性要求是否合理; f)关键技术的落实解决情况; g)编制的质量计划是否可行。
软件项目中如何开展有效的需求评审
1、需求评审的重要性 在软件项目中,需求分析是最开始的工作,同时也是最重要的工作。
需求分析如果做得不够详细或者是偏离用户需求或者是存在缺陷的话,往往会给项目带来灭绝性的灾难,不重视需求过程的项目团队将自食其果。
因此,如何保证需求分析的正确、准确性,成了决定软件项目成败的关键因素。
在实际的项目过程中,需求阶段往往是由一两位需求分析人员与用户沟通用户需求,然后根据自己的理解输出软件需求说明书及软件原型。
接下来的项目计划、软件设计、编码、测试等各个环节都以此为基准。
俗话说,当局者迷,旁观者清,经验再丰富的需求分析人员也可能犯错,所谓智者千虑,必有一失,这是永远不变的客观规律。
另外,受需求分析人员的理解及用户的表达等因素的影响,需求在传递过程中往往存在很大偏差。
需求分析人员输出的需求分析说明书,到设计人员、编码人员、测试人员那里往往又会有不同的理解。
因此,软件需求分析说明书的正确性必须得到彻底的验证,利益相关方必须彻底理解需求,并达成一致。
要达成这一目标、降低需求风险,需求评审是一个行之有效的方法。
目前,很多小型软件企业在需求阶段,往往是需求人员写完需求后再跟用户沟通一下,就直接进入设计开发阶段了,设计、编码、测试人员前期没有参与进来,根本没有进行需求评审。
也有不少企业的需求评审存在“走过场”的情况,其他人员根本不关心软件需求,认为软件需求就是需求分析人员的事情,他们怎么写大家怎么做就可以了,在提需求异常时简单找几个错别字提一下应付了事,没有提出有效的需求异常。
也有的时候,在需求评审会议中,大家的关注点常常会不知不觉的转向设计,结果需求评审会议成了设计讨论会议,大家想得最多的是需求如何实现,而不是需求文档本身有无问题。
或者是因为没有做好前期准备工作,导致评审时间长、效率低,结果很多问题不了了之。
这样的评审,最终效果可想而知。
2、需求评审的关键 下文根据笔者多年参与软件项目管理的切身体会及经验,从不同角度对需求评审方法进行论述。
2.1 充分准备评审 好的软件需求说明书,是进行有效需求评审的前提。
首先,需求人员在与用户确认需求的过程中,一定不要放过任何一个细节,仔细体会用户的每一个要求。
对于用户的要求,需求人员需要对其加以梳理:哪些是合理的需求,哪些是不合理的需求,还有一些可能是必要的但是用户没想到的需求。
软件需求说明书不应该只是用户意愿的表达,而应该是从软件层面上对用户需求的总结。
软件需求说明书对需求用例的描述一般分为基本流和扩展流,基本流是大家很容易想到的主要业务流程,而实际设计开发及测试过程中,最耗费时间的是实现扩展流的过程。
因此不能只注重基本流,好的软件需求说明书,扩展流一定远远多于基本流,扩展流写得越完善,说明需求人员考虑得越周全。
而实质上,如果扩展流写得不完善,后期的设计、开发及测试人员往往在相应的细节处理上无所适从。
2.2 分层次评审 用户的需求是可以分层次的,一般而言分成以下层次: ①目标性需求,定义整个系统需要达到的目标; ②功能性需求,定义了整个系统必须完成的任务; ③操作性需求,定义了完成每个任务的具体的人机交互;目标性需求是企业的高层管理人员所关注的,功能性需求是企业的中层管理人员所关注的,操作性需求是企业的具体操作人员所关注的。
对不同层次的需求,其描述形式是有区别的,参与评审的人员也是不同的。
如果让具体的操作人员去评审目标性需求,可能会很容易地导致“捡了芝麻,丢了西瓜”的现象,如果让高层的管理人员也去评审那些操作性需求,无疑是一种资源的浪费。
分层次评审,可以让不同类型的参与人分别评审他们关注的内容,从不同的角度找到需求的异常,提高评审效率。
什么是软件评审?为什么需要进行软件评审
1平衡原则 在我们讨论软件项目为什么会失败时可以列出了很多的原因,答案有很多,如管理问题、技术问题、人员问题等等,但是有一个根本的思想问题是最容易忽视的,也是软件系统的用户、软件开发商、销售代理商最不想正视的,那就是:需求、资源、工期、质量四个要素之间的平衡关系问题。
需求定义了做什么,定义了系统的范围与规模,资源决定了项目的投入(人、财、物),工期定义了项目的交付日期,质量定义了做出的系统好到什么程度,这四个要素之间是有制约平衡关系的。
如果需求范围很大,要在较少的资源投入下,很短的工期内,很高的质量要求来完成某个项目,那是不现实的,要么需要增加投资,要么工程延期;如果需求界定清楚了,资源固定了,对系统的质量要求很高,则可能需求延长工期。
对于上述四个要素之间的平衡关系最容易犯的一个错误,就是鼓吹多快好省四个字,多快好省,多么理想的境界啊?需求越多越好,工期越短越好,质量越高越好,投入越少越好,这是用户最常用的口号。
多:需求越多越好吗?软件系统实施的基本原则是全局规划,分步实施,步步见效,需求可以多,但是需求一定要分优先级,要分清企业内的主要矛盾与次要矛盾,根据PARETO的80-20原则,企业中的80%的问题可以用20%的投资来解决,如果你要大而全,对不起,你那20%的次要问题是需要你花费80%的投资的!而这一点恰恰是很多软件用户所不能忍受的。
快:真能快起来吗?快是用户、软件开发商都希望的。
传统企业里强调资金的周转情况,软件企业里强调的是人员的周转情况,开发人员应尽快做完一个项目再做另外一个项目,通过快速的启动项目、结束项目来承担更多的项目,来获利。
但是快不是主观的拍脑袋定工期就可以完成的,工期的定义一定要基于资源的状况、需求的多少与质量的需求来进行推算的。
软件毕竟需要一行代码一行代码的写出来,他的工作量是客观的,并非人有多大胆,地有多大产式的精神鼓动就可以短期完成的。
省:省到什么程度?一分钱一分货,这是中国的俗话,他是符合价值规律的。
甲方希望少投入,乙方希望降低自己的生产成本,省到乙方仅能保本的时候,再省,乙方就亏损了。
正视这四个要素之间的平衡关系是软件用户、开发商、代理商成熟理智的表现,否则系统的成功就失去了一块最坚实的理念基础。
企业实施IT系统的首要目标是要成功,而不是失败,企业可以容忍小的成功,但不一定容忍小的失败,所以需要真正理解上述四个要素的平衡关系,确保项目的成功。
2高效原则 在需求、资源、工期、质量四个要素中,很多的项目决策者是将进度放在首位的,现在市场的竞争越来越激烈,产品早上市一天,就早挣一天钱,挣的就比花的多,所以一定要多挣,基于这样一个理念,软件开发越来越追求开发效率,大家从技术、工具、管理上寻求更多更好的解决之道。
基于高效的原则,对项目的管理需要从几个方面来考虑:要选择精英成员 目标要明确,范围要清楚 沟通要及时、充分 要在激励成员上下工夫3分解原则 化繁为简,各个击破是自古以来解决复杂问题的不二法门,对于软件项目来讲,可以将将大的项目划分成几个小项目来做,将周期长的项目化分成几个明确的阶段。
项目越大对项目组的管理人员、开发人员的要求越高,参与的人员越多,需要协调沟通的渠道越多,周期越长,开发人员也容易疲劳,将大项目拆分成几个小项目,可以降低对项目管理人员的要求,减少项目的管理风险,而且能够充分地将项目管理的权力下放,充分调动人员的积极性,目标会比较具体明确,易于取得阶段性的成果,使开发人员有成就感。
作者主管过的一个产品开发项目代号为SB,该项目前期投入了5人做需求,时间达3个多月,进入开发阶段后,投入了15人,时间达10个月之久,陆续进行了3次封闭开发,在此过程中经历了需求的裁剪、开发人员的变更、技术路线的调整,项目组成员的压力极大,大家疲惫不堪,产品上市时间拖期达4个月。
项目完工后总结下来的很致命的一个教训就是应该将该项目拆成3个小的项目来做,进行阶段性版本化发布,以缓解市场上的压力,减少项目组成员的挫折感,提高大家的士气。
4实时控制原则 在一家大型的软件公司中,有一位很有个性的项目经理,该项目经理很少谈起什么管理理论,也未见其有什么明显的管理措施,但是他连续做成多个规模很大的软件项目,而且应用效果很好。
作者一直很奇怪他为什么能做的如此成功,经过仔细观察,终于发现他的管理可以用紧盯2字来概括,即每天他都要仔细检查项目组每个成员的工作,从软件演示到内部的处理逻辑、数据结构等,一丝不苟,如果有问题,改不完是不能去休息的。
正是在他这种简单的措施下,支撑他完成了很多大的项目,当然他也是相当的辛苦,通常都是在凌晨才去休息。
我们并非要推崇这种做法,这种措施也有他的问题,但是,这种实践却说明了一个很朴实的道理:如果你没有更好的办法,就要辛苦一点,实时控制项目的进展,要将项目的进展情况完全的实时的置于你的控制之下。
上述的方法中对项目经理的个人能力、牺牲精...
如何保证软件的质量
软件质量保证(SQA)是一种应用于整个软件过程的活动,它包含:⒈一种质量管理方法⒉有效的软件工程技术(方法和工具)⒊在整个软件过程中采用的正式技术评审⒋一种多层次的测试策略⒌对软件文档及其修改的控制⒍保证软件遵从软件开发标准⒎度量和报告机制SQA与两种不同的参与者相关 —— 做技术工作的软件工程师和负责质量保证的计划、监督、记录、分析及报告工作的SQA小组。
软件工程师通过采用可靠的技术方法和措施,进行正式的技术评审,执行计划周密的软件测试来考虑质量问题,并完成软件质量保证和质量控制活动。
SQA小组的职责是辅助软件工程小组得到高质量的最终产品。
SQA小组完成:⑴为项目准备SQA计划。
该计划在制定项目规定项目计划时确定,由所有感兴趣的相关部门评审。
·需要进行的审计和评审;·项目可采用的标准;·错误报告和跟踪的规程;·由SQA小组产生的文档;·向软件项目组提供的反馈数量。
⑵参与开发项目的软件过程描述。
评审过程描述以保证该过程与组织政策,内部软件标准,外界标准以及项目计划的其他部分相符。
⑶评审各项软件工程活动,对其是否符合定义好的软件过程进行核实。
记录、跟踪与过程的偏差。
⑷审计指定的软件工作产品,对其是否符合事先定义好的需求进行核实。
对产品进行评审,识别、记录和跟踪出现的偏差;对是否已经改正进行核实;定期将工作结果向项目管理者报告。
⑸确保软件工作及产品中的偏差已记录在案,并根据预定的规程进行处理。
⑹记录所有不符合的部分并报告给高级领导者。
测试计划怎么评审
1.计划评审测试计划编写完成后,一般要对测试计划的正确性、全面性以及可行性等进行评审,评审人员的组成包括软件开发人、营销人员、测试负责人以及其他有关项目负责人。
2.计划总结项目完成后,应该对计划的执行情况进行评审,看有哪些不合理的地方,以便为编写下一个项目测试计划做经验积累。
测试计划Testing plan,描述了要进行的测试活动的范围、方法、资源和进度的文档;是对整个信息系统应用软件组装测试和确认测试。
它确定测试项、被测特性、测试任务、谁执行任务、各种可能的风险。
测试计划可以有效预防计划的风险,保障计划的顺利实施。
技术评审的评审目的
正规技术评审目的(1)发现软件在功能、逻辑、实现上的错误;(2)验证软件符合它的需求规格;(3)确认软件符合预先定义的开发规范和标准;(4)保证软件在统一的模式下进行开发;(5)便于项目管理。
此外,正规技术评审为新手提供软件分析、设计和实现的培训途经,后备、后续开发人员也可以通过正规技术评审熟悉他人开发的软件。