蜂蜜柠檬哎呦不错哦
软件开发项目有哪些风险
1、首先制定项目计划，最初计划是里程碑性质的。
可以先按瀑布模型设置，里程碑点主要为需求评审、设计评审、经过代码开发和单元测试后进行集成测试、部署上线是一个很重要的里程碑，一般用户会期望系统何时能使用，进入试运行期。
2、需求开发阶段：怎么样写好需求很关键，这个需要实践经验锻炼自己。
如果有项目成员，可以一起做需求，这个阶段对于业务理解、分析、如何开展调研以及文字表述、业务流程图描述还有文档编辑能力都有不少要求。
一般分为《用户需求说明书》和《需求规格说明书》，小项目可以写一个《需求分析报告》，《用户需求说明书》是用用户的语言进行描述，让用户和开发团队对于需求的达成一致的理解，《需求规格说明书》，则是对用户需求的分析，形成系统要具有的功能，这个是真正提供用户可交互操作的文档，也就是后期设计和代码开发的重要基线。
另外，作为了解需求，拿出用户UI和用户交流也是一项比较重要的需求获取手段，虽然这个属于设计的范畴3、系统设计阶段：系统总体架构，结合用户对系统环境、开发语言以及运行的网络硬件等要求，确定开发工具等，对应用系统关系进行架构性设计，通过需求阶段对用户的分析归类，用图的方式描述出用户和各子系统或模块的全局视图，以及和其他系统的关系。
也就是搞清楚系统的边界问题。
概要设计中除了高层架构设计，还需要设计网络拓扑图，以及系统部署图。
概要设计比较重要的还有就是子系统、模块进行合理的划分。
模块的名称很大程度上会成为用户的主要菜单，如何用用户的角度去取比较清楚的子系统和模块是很重要的。
4、代码开发和单元测试阶段：这个阶段一般来说需要改进瀑布模型，类似跌代开发，把模块进行合理划分，把项目总体计划的代码开发测试阶段划分为多个时间段，每个时间段都包括代码开发、单元测试和集成测试，这个阶段还需要对需求变更进行跟踪控制，如果需求有变更，那么要把需求文档、设计文档都重新跟上。
跌代开发的好处就是不让代码开发阶段拉的过程，没有进行及时的自我检查，不小心到了提交时间，却不是用户想要的，还有可能都不是自己想要的。
项目经理重要的责任是控制好进度，能及早发现风险，并能拿出好的预防和解决办法的措施。
合理安排好开发团队的任务，合时的任务安排和衔接，你会觉得非常有艺术感，这个要自己体会了。
另外，关注项目团队各人员的状况，保持高的战斗力，及时发现并能鼓励团队共同朝一个目标前进。
5、测试工作，测试是项目的很重要的环节，怎么测试，怎么准确测试，怎么有效测试，怎么覆盖测试，时间、人手、经验扽个方面都会有制约。
高级测试人员能够分析系统各测试要点，在需求、设计阶段都要参与，提早了解如何去测试，能写出测试用例。
6、文档工作，文档在项目开发中也占有重要位置，除非你觉得代码是项目唯一的成果，那么你把文档抛掉吧，什么都在你的脑子里，团队中人员一走，项目的一部分也就带走了。
代码开发其实也需要文档，代码是成果，代码注释是成果，模块开发卷宗也是重要的成果，因为程序员在开发时候的逻辑是怎么样的，对于今后查问题很有作用。
除非你的系统设计程度到了方法、类，把代码逻辑也都设计好了，那么程序员就CODEING去吧。
7、QA是对项目过程的质量保障，有些公司吧QA和测试工作合成一个岗位叫做QA&；测试人员，或者就叫QA人员。
QA是对项目全过程的监管，独立于项目之外。
监督项目经理在各项目里程碑提交相关成果，入库形成基线。
如何选择软件开发的生命周期
软件项目计划：计划：业务计划、资源计划PPL、WBS、配置管理计划、风险管理计划、测试策略和缺陷预防计划所有的评审文档需求：SRS、STP所有的评审文档概设：HLD、ITP所有的评审文档详设：LLD、UDP所有的评审文档编码：代码完成、单元测试报告完成所有的评审文档集成测试：集成测试报告完成系统测试：系统测试报告完成
软件的生命周期
软件生命周期是指从软件定义、开发、使用、维护到报废为止的整个过程，一般包括问题定义、可行性分析、需求分析、总体设计、详细设计、编码、测试和维护。
问题定义就是确定开发任务到底“要解决的问题是什么”，系统分析员通过对用户的访问调查，最后得出一份双方都满意的关于问题性质、工程目标和规模的书面报告。
可行性分析就是分析上一个阶段所确定的问题到底“可行吗”，系统分析员对系统要进行更进一步的分析，更准确、更具体地确定工程规模与目标，论证在经济上和技术上是否可行，从而在理解工作范围和代价的基础上，做出软件计划。
需求分析即使对用户要求进行具体分析，明确“目标系统要做什么”，把用户对软件系统的全部要求以需求说明书的形式表达出来。
总体设计就是把软件的功能转化为所需要的体系结构，也就是决定系统的模块结构，并给出模块的相互调用关系、模块间传达的数据及每个模块的功能说明。
详细设计就是决定模块内部的算法与数据结构，也是明确“怎么样具体实现这个系统”。
编码就是选取适合的程序设计语言对每个模板进行编码，并进行模块调试。
测试就是通过各种类型的测试使软件达到预定的要求。
维护就是软件交付给用户使用后，对软件不断查错、纠错和修改，使系统持久地满足用户的需求。
软件的生命周期也可以分为3个大的阶段，分别是计划阶段、开发阶段和维护阶段。
瀑布模型有时也称为V模型，它是一种线型顺序模型，是项目自始至终按照一定顺序的步骤从需求分析进展到系统测试直到提交用户使用，它提供了一种结构化的、自顶向下的软件开发方法，每阶段主要工作成果从一个阶段传递到下一个阶段，必须经过严格的评审或测试，以判定是否可以开始下一阶段工作，各阶段相互独立、不重叠。
瀑布模型是所有软件生命周期模型的基础。
原型+瀑布模型原型模型本身是一个迭代的模型，是为了解决在产品开发的早期阶段存在的不确定性、二义性和不完整性等问题，通过建立原型使开发者进一步确定其应开发的产品，使开发者的想象更具体化，也更易于被客户所理解。
原型只是真实系统的一部分或一个模型，完全可能不完成任何有用的事情，通常包括抛弃型和进化型两种，抛弃型指原型建立、分析之后要扔掉，整个系统重新分析和设计；进化型则是对需求的定义较清楚的情形，原型建立之后要保留，作为系逐渐增加的基础，采用进化型一定要重视软件设计的系统性和完整性，并且在质量要求方面没有捷径，因此，对于描述相同的功能，建立进化型原型比建立抛弃型原型所花的时间要多。
原型建立确认需求之后采用瀑布模型的方式完成项目开发。
增量模型与建造大厦相同，软件也是一步一步建造起来的。
在增量模型中，软件被作为一系列的增量构件来设计、实现、集成和测试，每一个构件是由多种相互作用的模块所形成的提供特定功能的代码片段构成。
增量模型在各个阶段并不交付一个可运行的完整产品，而是交付满足客户需求的一个子集的可运行产品。
整个产品被分解成若干个构件，开发人员逐个构件地交付产品，这样做的好处是软件开发可以较好地适应变化，客户可以不断地看到所开发的软件，从而降低开发风险。
一些大型系统往往需要很多年才能完成或者客户急于实现系统，各子系统往往采用增量开发的模式，先实现核心的产品，即实现基本的需求，但很多补充的特性（其中一些是已知的，另外一些是未知的）在下一期发布。
增量模型强调每一个增量均发布一个可操作产品，每个增量构建仍然遵循设计-编码-测试的瀑布模型。
迭代模型早在20世纪50年代末期，软件领域中就出现了迭代模型。
最早的迭代过程可能被描述为“分段模型”。
迭代，包括产生产品发布（稳定、可执行的产品版本）的全部开发活动和要使用该发布必需的所有其他外围元素。
所以，在某种程度上，开发迭代是一次完整地经过所有工作流程的过程：（至少包括）需求工作流程、分析设计工作流程、实施工作流程和测试工作流程。
实质上，它类似小型的瀑布式项目。
所有的阶段（需求及其它）都可以细分为迭代。
每一次的迭代都会产生一个可以发布的产品，这个产品是最终产品的一个子集。
软件测试项目管理之如何提高风险识别能力
在项目风险管理中，也一样，我们并不惧怕已经知道的风险，怕的是未被识别出来的风险。
在风险管理中，常常涉及到：风险的类别、风险识别、风险概率、风险后果、风险定型分析、风险定量分析、风险登记等等理论知识，我认为风险识别是最重要的。
因为风险识别是源头，只有及时的暴露出了问题才可能有解决的机会。
在电子行业新产品开发流程具有一般的共性：方案选择、项目立项、主板完成并通过测试、样机完成、系统测试完成、客户确认生产样机、小批量市场、量产安排。
同样风险管理贯穿着新产品开发流程中的整个流程。
需要注意到风险存在流程中的每一个环节，稍有不注意，就会给项目带来隐患。
风险识别首先要确定风险的责任人：项目组的所有成员、项目干系人都有风险识别、提出的责任。
项目经理或产品经理应该成为风险识别的主要责任人。
负责风险收集、分析、应对计划的制定等。
风险的类别通常分为：外部风险、组织风险、项目管理风险、技术管理风险。
外部风险来之于项目开发的环境，如社会环境、国家的规章制度、法律法规的变化；自然环境的变化，如地震、战争、水灾等的出现，给项目带来的风险。
组织风险如公司领导支持不到位，缺乏资金；PDT组织人员流失、职能墙等带来的风险。
项目管理风险：计划不到位、产品立项评审太草率，项目经理、产品经理不懂项目管理方法等产生的风险。
技术管理风险：前期技术评估不到位导致后续出现很多技术障碍、专利造成的技术壁垒而导致的风险。
风险管理贯穿整个产品开发生命周期，在生命周期的不同阶段，风险识别的重点也不一样。
来自于外部风险、组织风险、相关管理风险、技术风险在不同的项目阶段凸现的重要性也不一样。
在设计阶段：主要是缺乏相关的技术专家对技术可行性的确认；项目的范围、需求定义不清造成后续不断的变更；为做深入的可行性分析导致项目失败；目标不明确，项目开发到一定阶段，不知道针对哪个市场、需求负责。
在开发阶段：经常出现没有制定风险管理计划，没有应急措施；需求不够明确；没有得到管理层的支持；团队角色定义不清楚，缺乏有经验的成员。
在实施阶段，经常出现的风险有：劳工缺乏相关技能，组织没有提供相关培训；材料不足；由于组织外部导致的计划变更、人员变更，法律法规变更，执行失败等。
收尾阶段：质量差，客户不接受验收，设计变更、现金流出现问题等等。
风险识别出来后，最重要的要记录下来，形成一个风险清单，识别其存在的根本原因，确定潜在的应对措施。
不同的风险应该指派相应的应对负责人。
对于消极、威胁的风险采取：回避：如筛选不熟悉的承包商；转嫁：如外包；减轻：尽早采取行动。
降低风险发生的概率、结果，有时风险也是一种机会，应该开拓、提高它积极的作用。
