外包软件开发流程.pdf

《外包软件开发流程.pdf》由会员分享，可在线阅读，更多相关《外包软件开发流程.pdf（3页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、-外包软件开发流程外包软件开发流程一一.商务谈判商务谈判-沃-航-科-技一款软件准备开发时，首先就是和甲方公司进展接洽和商务谈判，初步了解用户需求以及这个工程甲方对资金以及工期和其他的各方面的预估，初步达成合作意向。二二.产品需求讨论产品需求讨论需求分析是做产品的头等大事，而需求分析的第一步就是找准产品定位。产品定位实际上就是关于产品的目标、围、特征等约束条件，它包括两方面的容：产品定义和用户需求。产品定义主要由产品经理从角度考虑，用户需求主要由设计师从用户角度考虑。明确了产品定位，也就确定了产品设计的方向，统一了团队成员对产品的理解，可以防止团队很多不必要的争执。产品定义就是用一句话概括产品

2、，包括如下三个方面：使用人群：产品效劳于哪类人群。主要功能：功能围的限定。产品特色：与同类产品相比的竞争优势。举例：一款音乐应用的产品定义。使用人群：白领主要功能：播放音乐产品特色：音质清晰、更新速度快用户需求概括起来就是：谁在什么环境下想要解决什么问题。一般可以分解为一个个用户故事，包括如下三个方面：目标用户：目标用户是在使用人群细分的根底上得到的，它也在一定程度上影响了使用场景和用户目标。拆解用户的时候考虑潜在用户量和商业价值。使用场景：用户使用产品的环境，需要关注不同场景的特点。用户目标：用户在不同场景下期望完成的目标，可从中提取出功能关键词。三三.prd.prd 输出和确认输出和确认一

3、般一份 PRD 文档要包含以下这些容：1、概述局部：简单介绍一下产品的背景，产品的价值或者愿景，产品的简单介绍，一些预估的风险点，干系人，名词解释等等；2、业务需求描述局部：定义好目标用户群体，业务流程图，业务架构图，脑图等等的介绍；3、功能需求描述局部：这局部才是用到上面所述方法的点，每个功能点都可以用那样的方式描述；4、非功能需求描述局部：与产品相关的一些辅助功能，性能要求、易用性要求等等；5、接口描述局部：与外部有相关接口的需要在这个局部描述；6、附录局部：培训信息、参考资料等，还可以有运营方案等等；完整的PRD 文档中，最多的局部就是对功能需求的分解描述，A*ureRP 可以很好的支撑

4、这个局部的全部容，另外其实 A*ureRP 也有流程图、UML 图的功能，业务流程图、业务架构图等都可以在 A*ureRP.z.-里面实现出来。四四.合同拟定合同拟定需求确认完成后就要开场拟定合同了。合同要列出双方的责任与义务，验收方式，过程中遇到问题的解决情况，工程资金打款的问题协议，软件所有权，知识产权、著作权归属，外包完工之后，售后的支援与帮助。确定双方的沟通的机制及开发周期双方的主要干系人，开发负责人，产品负责人，工程支持等简历微信群，讨论组，文档上传共享的网盘等开发是每周一个周期，进展功能的测试与 UAT，然后将工期进展抄送所有人主要是双方合作方式及实现方式五五.工程方案工程方案一个

5、软件工程进入系统实施的启动阶段,主要进展的工作包括:确定详细的工程实施围、定义递交的工作成果、评估实施过程中主要的风险、制定工程实施的时间方案、本钱和预算方案、人力资源方案等。在软件工程管理过程中一个关键的活动是制定工程方案，它是软件开发工作的第一步。工程方案的目标是为工程负责人提供一个框架，使之能合理地估算软件工程开发所需的资源、经费和开发进度，并控制软件工程开发过程按此方案进展。在做方案时，必须就需要的人力、工程持续时间及本钱作出估算。这种估算大多是参考以前的花费作出的。软件工程方案包括二个任务：研究和估算。即通过研究确定该软件工程的主要功能、性能和系统界面.六六.需求变更方案需求变更方案

6、每做一次工程方案变更，都会影响到日后的本钱估算、活动顺序、行程日期、资源需求及风险控管的决策，因此甲乙双方的工程经理、IT 经理都必须以整体的视野、统一的要求，对变更进展控制、确认与纪录。而需求变更的控制关键在于建立相应的控制组织、变更控制系统以及规变更流程。充分做好前期的需求调研、系统培训等工作。深入企业一线，全面调查研究，最大程度地挖掘企业用户的潜在需求，发现可能要需求变更的地方，让企业用户尽快做出是否要进展需求变更。一般把需求变更或者新需求确实认最迟时间定在系统培训阶段。也就是说，在系统培训完成后、开场准备双线并行前，企业用户还可以提出需求变更的申请，但是，当系统开场双线运行时，就不允许

7、用户再提出需求变更等类似的请求了，如编码的容和规则、表单的数量和格式、数据流转和统计方式等，否则就要付出变更的代价。建立变更控制组织系统。工程启动时，尽可能地与客户沟通，尽快建立正式的对变更进展控制的组织，通称变更控制委员会(CCB)，成员可包括双方高层(挂名)、甲乙双方的工程负责人、相关的需求负责人等，负责裁定承受变更容、方法、步骤等。建立该系统的目的是统一管理需求变更和跟踪变更的状态，便于工程组测试人员、开发人员、系统分析员以及PM 相互之间的沟通和交流。建立变更控制系统目的不是让用户不提出变更，而是让用户不轻易、随便的提出变更。.z.-严格规变更流程。一旦需求分析阶段完毕，此后如果用户要

8、求有新的需求参加即将交付的软件系统中，甲乙双方的工程组或变更控制委员会，要根据角色定义，确定变更流程，规定严格的变更控制流程，并控制新需求提出的频率。七七.工程验收工程验收对互联网产品而言，验收有三层含义：产品功能用例化后，用例执行符合预期与需求吻合，正向操作的用户体验良好设计和前端UI 符合评审的标准第一层应该是测试人员应该重点关注的，但在小公司或创业公司，开发/产品本身就是测试，验收几乎等同于最后一次测试。但是无论是否有测试工程师这个岗位，产品需求的用例化都是十分必要的，即便通过了专门的测试，产品或领导在验收时，潜意识也是在执行相关的用例；第二层说的是普遍意义上的验收，产品通过 test

9、平台测试，部署到了 DEMO 平台，由产品需求人员进展需求验收，当然，部成员、相关领导都可以进展验收体验。对DEMO 的验收，是装成用户后对产品的使用，通常是正向操作，同时除了逻辑和流程，验收人员会更加关注用户体验；关于前端 UI 的验收，实际上是对用户体验的一局部标准化，而验收的容应该与设计评审通过的容相吻合。如果没有设计评审，则标准就是公说公有理了。为了防止这种情况，需要在需求和设计评审前，界定清楚一些根本的准则和规，比方符合公司的VI 体系、符合W3C页面标准、符合*，最直观的还是所见即所得的需求设计交互页面这个问题其实很好，好在专门提出了 UI 的验收。本质上是因为开发对 UI 或者对

10、前端、兼容性等很容易忽略，因为这是个简单但很花时间的活儿，做起来没有成就感。当然，如果你们有一套自己的UI 库或前端框架，则能够躲避很多前端上的扯皮，但如果没有，开发和前端至少需要50%的精力去搞页面。提前考虑标准、尽量使用框架、让代码公用并易于维护，这是前端和攻城师的硬功夫，否则就沉浸在无尽的BUG 中，更不用说验收了。至于谁负责.团队中的任意相关人都可以，前端、开发、产品、或者你们领导。总之，验收就是质量的最后把关，产品自己都看不过去，臭虫一堆，千万不要有任何幸运心理让用户帮着验收。八八.迭代方案迭代方案做产品 Roadmap 规划的时候，要想清楚哪些需包括在MVP(Minimal Var

11、iable Product)的。也就是说第一版必须抓住目标用户的痛点和切实需求。在时间金钱资源有限的情况下，弄明白哪些功能点是必不可少的，对产品推出后成功是至关重要的。如何弄明白这个问题.那就是从用户调研数据得来。没有经过用户验证过的产品原型一般来说都很难经得起推敲，因为这是在设计师 或者产品经理 的假设上完成的作品，而并不一定会获得用户的青睐和肯定。当有了 MVP第一版以后，就可以在市场的反响结果上做下一步考虑，哪些地方是需要修改的，哪些功能点是需要补充的，哪些地方其实用户反响并不大可以移除的。把这些点做优先级排列，最重要和最紧急的放在下一个产品迭代周期的开发之首，再对新的产品原型做用户测试再做迭代。A/B 测试不是用来测试用户需求和主要功能点的，而是当产品有了一定的用户基数以后，团队对产品有了一些新的设计想法时，不能确定这个新设计是利大于弊还是弊大于利，于是对一些访问用户展示新的设计，同时对另一局部访问用户保存原有的设计，这样可以从用户转化率等其它目标变量来测试终究哪一版的设计更改。.z.