一、软件架构如何能够满足ASPICE流程
架构的用途是把整个产品划分为更为细节的板块:软件、硬件、通信等。在这个基础上软件整体将按照用途、功能等细分下去。软件模块的细分程度是尽可能把相互依赖的部分放置在一个模块中,模块与模块间只有前后执行顺序、调度优先级等比较独立的关系。建立一个外部流动变量较少,相互依存影响较轻、可替换性适当的划分。一方面,这样划分得到的模块后续其他项目的复用价值最大,另一方面,将不同模块交给不同工程师进行开发中相互扯皮的情况也将减少。
在这个基础上,可以进行模块调度和接口的测试,因为这些测试不依赖与模块功能是否实现。硬件底层驱动、通信等的测试也需要在这个阶段进行,已保证整个系统的基底是有效而完整的。
同时由于软件模块已经实现了划分,不同模块的职责已经明确,可以十分明确地系统需求分拨到各个模块上。
这里需要关注的是什么是软件需求,比如说我们现在有一个电控液压刹车(后续参数全部瞎编的,千万别较真),那么假定整车重量空载为1.4吨,满载1.6吨,要求在干燥的水泥路面上80车速以下全刹车实现5秒内刹停,最大刹车距离不超过100米。选定液压刹车系统为某某品牌某某型号,提供最大200Mpa液压刹车力,延迟1s,工作电压350V,工作电流1.5a等(再次说明,我对刹车一点都不懂,以上都是瞎扯淡的数据,很可能还各种错误)。
延伸阅读:
二、系统需求的可行性和成本估算
名列前茅种是产品必须具备的性能、功能的实现可行性,已有移植、市场采购、自行开发,都可以。但是需要考虑最终实现这些需要多少时间、成本、占用的人力物力。
第二种是产品期望实现的需求,则在名列前茅种情况的基础上,需要筛选出可行性和成本能接收的需求与客户进行讨价还价。
名列前茅种情况更多的是在于这个项目我们到底做不做、有没有能力接下来,第二种情况更多是在于后续合同中我们该要多少钱,做这个项目是否划得来。
也就是说客户需求那里沟通到一定程度后,进行的删减(比如说有些功能不能实现,有些功能需要更改指标,有些功能需要加钱等)后,这个才能算项目开展的系统需求。