问题描述
最近公司委托乙方为我们开发软件产品,从目前开发的产品来看,产品质量不尽人意。而且最近我们也理解到我们这个产品是其的第一个产品(无实际经验),经验严重不足。乙方告诉我们他们会以产品化的方式来开发这个产品,但从实际的种种现象看,乙方仅仅是为了交付而交付,没有按照产品化的方式来开发。其架构设计的更多是强调分层,而不是我们需要的基于组件化的思想下的结构。
问题:如何对其软件架构进行验收,确保其是基于组件化的思想下的结构,避免出现软件各子模块之间强耦合的情况?
一、解决方案一
问题分析和解决
问题 1:
产品质量不尽人意,从题目看产品质量不尽人意,大多数指可交付成果不满足用户要求。软件方面的可交付成果不足,一般表现为功能缺失或不符,界面美观度,操作易用性,业务流程明晰…
解决方案:
1、产品高保真图的设计与批准、完成美观度的审验
2、产品原型图的设计与批准、完成功能及流程的审验
3、提交测试报告 、完成功能完整性的验收
4、阶段试运行 、完成真实情况下的实际运行情况验收
问题 2:
缺少管控:第一个产品 、缺少经验。这个在实际情况中很容易遇到,而且是甲乙双方产生问题的主要爆发点。原因很简单:甲方说不清需求以及想要的功能说明;乙方只针对甲方提出的进行开发,没有一个很好的产品、市场、业务等的调研。最终结果就是甲方不断的要求添加或者变更功能,乙方不断的要求加预算,加工期【一般情况下都是大包合同即固定总价】。导致双方的不平衡,导致矛盾的产生。
解决方案:
1、 合同:双方采用非固定总价合同 ,商量出一个都符合双方利益的合同方式,实际情况下改变合同方式,比较难。因为很多单位的财务等要求关系,很难变更合同方式。
2、 甲方雇佣一个有丰富经验的人员来替代甲方提出业务需求。这种解决方案情况下,甲方风险较高,而且需要有合适人员,对于没有一点经验的甲方来讲,容易挨坑。
3、 乙方提供人员,完成甲方需求的收集及可交付成果的设计确认。
4、 乙方派人,甲方管理,这种人员外包的形式比较考验甲方的管理能力,但是也能相对应的提高质量及速度。
问题 3:
无法或很难核实或者说无法写到合同中:乙方说他们会以产品化的方式开发,没有按照产品化基于组件 而是更多的强调分层。
解决方案:
明确一点:软件开发的分层到目前为止还是比较好的一个模式。
1、分层技术其具有良好的扩展性及稳定性,能更好的促进整个软件系统的抽象化发展,并且将软件系统中的复杂部分,逐步转化到软件开发之中。这对于软件系统的维护及发展都具有深远影响,一个层面出现了技术问题,并不会对其他层面造成影响,只会影响到这个层面的上下层面。
2、如果甲方认为有问题,那么我个人认为可能出现的问题就是:软件设计的分层与甲方所说的基于组件的开发。可以要求乙方看能否快速的变更通用的功能点,如果是组件化开发通用的功能点肯定是组件化了,是可以快速的更变。
3、个人理解产品化与分层的开发:分层是表示将功能进行有序的分组:应用程序专用功能位于上层,跨越应用程序领域的功能位于中层,而配置环境专用功能位于低层。分层从逻辑上将子系统划分成许多集合,而层间关系的形成要遵循一定的规则。通过分层,可以限制子系统间的依赖关系,使系统以更松散的方式耦合,从而更易于维护。
二者的区别除管理方式外,我认为最大的不同之处就在于抽离实际业务中“对象”的高低程度。
总结
新手(如甲方)要做好步步审核及授权,对于无法验真的问题及需求需要落实到合同或者文档中尽量的实例化,细致化,避免后期交付问题。需要自己分内工作(需求),如果没有很好的处理方法可以适当的请外援(外聘或者与乙方协商)。
二、解决方案二
本人没有甲方经验,但是和甲方合作过很多年,我们甲方基本都具备多年项目经验,类似的问题基本不会发生,对于这个案例我也是和大家一块进行探索。
案例中明显存在的问题有以下几点:
1、乙方经验不足,没有类似项目经验
2、乙方对产品的设计不满足甲方要求
3、对产品质量不满意
出现问题的原因主要出现下以下过程中:
1、对供应商的选择;
2、需求、合同范围的把控;
3、对产品的质量的管理;
建议:
甲方项目经理作为项目负责人,解决以上问题,建议从以上几个过程中进行把控,而不
是仅仅通过最后的验收进行管控:
1、对供应商的选择,选择资质、有类似项目案例经验的乙方,通过招投标方式选择有
实力的供应商;
2、可以将产品的架构等内容作为非功能性需求进行明确;合同中将产品关注的需点、
架构等要求进行明确,且作为验收的标准
3、对产品研发过程中的重要成果物进行审核和把控,比如需求规格说明书、整体设计
方案、系统架构、技术选型等必须甲方评审确认后方可进入下一阶段,如果甲方项目经理不具备相关能力,可邀请相关方面专家参与评审;
4、对乙方研发监控管理过程中,暴露出来的风险问题,及时上报甲乙方领导,要求给
乙方给出解决方案和措施,避免风险和问题堆积到验收阶段,导致项目失败。