如何进行软件架构验收？

本期话题:如何进行软件架构验收?

一、背景介绍

受诊人职位： 甲方项目经理，也是部门经理

公司：最近公司委托乙方为我们开发软件产品，从目前开发的产品来看，产品质量不尽人意。而且最近我们也理解到我们这个产品是其的第一个产品(无实际经验)，经验严重不足。乙方告诉我们他们会以产品化的方式来开发这个产品，但从实际的种种现象看，乙方仅仅是为了交付而交付，没有按照产品化的方式来开发。其架构设计的更多是强调分层，而不是我们需要的基于组件化的思想下的结构。

问题：如何对其软件架构进行验收，确保其是基于组件化的思想下的结构，避免出现软件各子模块之间强耦合的情况?

二、嘉宾分享

01

受诊人遇到的问题分析及解决方案：

问题1：

产品质量不尽人意 ，从题目看产品质量不尽人意，大多数指可交付成果不满足用户要求。软件方面的可交付成果不足，一般表现为功能缺失或不符，界面美观度，操作易用性，业务流程明晰…

解决方案：

1、产品高保真图的设计与批准、完成美观度的审验

2、产品原型图的设计与批准、完成功能及流程的审验

3、提交测试报告 、完成功能完整性的验收

4、阶段试运行 、完成真实情况下的实际运行情况验收

问题2:

缺少管控：第一个产品 、缺少经验。

这个在实际情况中很容易遇到，而且是甲乙双方产生问题的主要爆发点。

原因很简单：

甲方说不清需求以及想要的功能说明;

乙方只针对甲方提出的进行开发，没有一个很好的产品、市场、业务等的调研。

最终结果就是甲方不断的要求添加或者变更功能，乙方不断的要求加预算，加工期【一般情况下都是大包合同即固定总价】。

导致双方的不平衡，导致矛盾的产生。

解决方案：

1、 合同：双方采用非固定总价合同 ，商量出一个都符合双方利益的合同方式，实际情况下改变合同方式，比较难。因为很多单位的财务等要求关系，很难变更合同方式。

2、 甲方雇佣一个有丰富经验的人员来替代甲方提出业务需求。这种解决方案情况下，甲方风险较高，而且需要有合适人员，对于没有一点经验的甲方来讲，容易挨坑。

3、 乙方提供人员，完成甲方需求的收集及可交付成果的设计确认。

4、 乙方派人，甲方管理，这种人员外包的形式比较考验甲方的管理能力，但是也能相对应的提高质量及速度。

问题3:

无法或很难核实或者说无法写到合同中：

乙方说他们会以产品化的方式开发，没有按照产品化基于组件 而是更多的强调分层。

解决方案：

明确一点：软件开发的分层到目前为止还是比较好的一个模式。

1、分层技术其具有良好的扩展性及稳定性，能更好的促进整个软件系统的抽象化发展，并且将软件系统中的复杂部分，逐步转化到软件开发之中。

这对于软件系统的维护及发展都具有深远影响，一个层面出现了技术问题，并不会对其他层面造成影响，只会影响到这个层面的上下层面。

2、如果甲方认为有问题，那么我个人认为可能出现的问题就是：软件设计的分层与甲方所说的基于组件的开发。

可以要求乙方看能否快速的变更通用的功能点，如果是组件化开发通用的功能点肯定是组件化了，是可以快速的更变。

3、个人理解产品化与分层的开发：

分层是表示将功能进行有序的分组：应用程序专用功能位于上层，跨越应用程序领域的功能位于中层，而配置环境专用功能位于低层。分层从逻辑上将子系统划分成许多集合，而层间关系的形成要遵循一定的规则。通过分层，可以限制子系统间的依赖关系，使系统以更松散的方式耦合，从而更易于维护。

二者的区别除管理方式外，我认为最大的不同之处就在于抽离实际业务中“对象”的高低程度。

总结：

新手(如甲方)要做好步步审核及授权，对于无法验真的问题及需求需要落实到合同或者文档中尽量的实例化，细致化，避免后期交付问题。需要自己分内工作(需求)，如果没有很好的处理方法可以适当的请外援(外聘或者与乙方协商)。

02

本人没有甲方经验，但是和甲方合作过很多年，我们甲方基本都具备多年项目经验，类似的问题基本不会发生，对于这个案例我也是和大家一块进行探索。

案例中明显存在的问题有以下几点：

1、乙方经验不足，没有类似项目经验

2、乙方对产品的设计不满足甲方要求

3、对产品质量不满意

出现问题的原因主要出现下以下过程中：

1、对供应商的选择;

2、需求、合同范围的把控;

3、对产品的质量的管理;

建议：

甲方项目经理作为项目负责人，解决以上问题，建议从以上几个过程中进行把控，而不是仅仅通过最后的验收进行管控：

1、对供应商的选择，选择资质、有类似项目案例经验的乙方，通过招投标方式选择有实力的供应商;

2、可以将产品的架构等内容作为非功能性需求进行明确;合同中将产品关注的需求点、架构等要求进行明确，且作为验收的标准;

3、对产品研发过程中的重要成果物进行审核和把控，比如需求规格说明书、整体设计方案、系统架构、技术选型等必须甲方评审确认后方可进入下一阶段，如果甲方项目经理不具备相关能力，可邀请相关方面希赛网参与评审;

4、对乙方研发监控管理过程中，暴露出来的风险问题，及时上报甲乙方领导，要求给乙方给出解决方案和措施，避免风险和问题堆积到验收阶段，导致项目失败。

03

/ 我有话说 /

凯-青岛-软件：

1、组件化，如果是一款普通应用的话，比如一个款类似微信的聊天应用，这样不需要分包部署，组件化更多是底层开发的组件化，从外面整体应用是看不出来的。不是所有的问题，都会导致产品挂掉，有的时候表现是性能方面。

2、有一个专业开发和测试进行验收是必不可少的。所以他们项目这里有没有专业人员也很重要，要不然很容易被坑。

3、现在产品已经开发完了，我觉得及时止损最佳方案是找一个专业称职的技术人员，和他讲明白产品需求，让他按照需求检查开发完的产品，找出问题，让外包公司及时更改，至于变更产生的各种费用，就要看具体沟通能力了”

阿德-淄博-城市公用：

“如果项目针对架构有要求的话，应该在设计阶段就应该介入，进行评审。而不是到了最后验收阶段的话，才对架构方面进行验收判断 "

“这种对架构要求比较严格的，我感觉这个甲方应该也是一个开发公司，乙方开发完成以后，应该把所有的源代码之类的全部提交交付，然后甲方在此进行二次开发的时候可以进行复用。”

追星骑士-深圳-金融IT：

”首先要看合同有没有定义验收标准，没有就要补上，其次，举个例子，假如框架是做优化的，可以做下对比，跟原有框架，或者世面上的成熟框架对比，复核足够标准，就可以跟领导交差，走验收，以后再根据情况起新项目，最后，要是没有达到标准，只好先不验收，甲方介入项目促进完成，其实这就费劲了，双输预警。“

简单-西安-软件：

”依据场景，项目处于准备验收阶段，主要有以下几点问题：

1. 甲方认为项目未能按照产品化开发。 2. 是否达到验收条件。

处理建议：

1. 可要求乙方提供软件产品功能详细设计、数据库设计、架构设计等相关文档。审核是否能够达到产品化要求。可由本公司内部进行也可寻找第三方审核。

2. 合同是否约定验收标准，若有则按照合同履约即可;若没有，依据行业产品标准要求乙方整改。

3. 查看项目风险计划(若有) 下下策，告知项目发起人。 综上，项目应该处于失控状态，且目前阶段，项目经理对项目干预程度较弱。 建议对项目复盘，更新组织过程资产。避免类似情况发生。

此场景，但项目处于验收阶段，项目经理在此阶段对项目的影响已经非常弱了，两条路可选，按着乙方继续做，再找个乙方。对整个项目而言，此举以是事后了，即便明知不可为。而项目事前和事中并未交代。此项目经理应该注重其事前和事中。“

聪少-广州-无业闲人：

”项目软件规划、分析、设计，这三步少不了，没经验，得也得有清晰可见文档，验收是对着这些文档做 集成测试、功能测试和验收测试。“

天天-北京-铁路自动化：

”首先要甲方把需求提明确，再就是乙方对甲方需求的分解落地情况要及时参与评审;甲方如果需求明确的话 是否能够找到类似原型的设计，供乙方做标杆“

㊧佚名氏㊨-上海-IT：

”本来，软件验收的时候，应该有个验收依据，比如招投标书，合同，需求说明书，总体设计书书等，我估计甲方只有合同吧。

如果没有验收依据，没有对架构作事先的要求说明，没没啥好验收了，请不请第三方都一样。“

总结：

1、合同中将产品关注的需求点、架构等要求进行明确，且作为验收的标准。

2、没有经验的甲方可以寻求专业的第三方帮助。

3、注重事前、事中控制。

三、讨论内容整理

[以上关于项目团队管理的内容都来自于希赛「PM创造营」群内话题讨论，由@小M妹妹 妹妹整理，由以下小伙伴分享完成@飞入闲窗@安静@zhanghx@凯-青岛-软件@阿颖-深圳-信息安全@凡尘若梦-长沙-IT@Fiona-福州-软件@Zen.Wu-政务教育高校@MISS丁 杭州 软件@追星骑士-深圳-金融IT@㊧佚名氏㊨-上海-IT@walker-成都-IT@上海-青春-制造业-ERP@Soda-宁波-汽车@欣鑫-成都-运营@合肥-Lee-IT实施@踏风而至-北京-通信@王昱-长沙-在线教育@牧云-成都-互联网产品@阿敏敏-武汉-互联网产品@李洁兰-广州-软件@凉风有信-广州-ERP@浩-深圳南山-金融行业@阿德-淄博-城市公用@Bysing-广东-珠宝@黑科技-贵阳-IT@天天-北京-铁路自动化@闪光创世-上海-IT@追星骑士-深圳-金融IT@D-深圳-OTA@Roy-济南-智慧停车@沈秋成-成都-IT@和煦风-成都-软件@建庆-深圳-智慧城市-GIS@简单-西安-软件@孤独老狼-镇江-ERP]