一、軟件架構如何能夠滿足ASPICE流程
架構的用途是把整個產品劃分為更為細節的板塊:軟件、硬件、通信等。在這個基礎上軟件整體將按照用途、功能等細分下去。軟件模塊的細分程度是盡可能把相互依賴的部分放置在一個模塊中,模塊與模塊間只有前后執行順序、調度優先級等比較獨立的關系。建立一個外部流動變量較少,相互依存影響較輕、可替換性適當的劃分。一方面,這樣劃分得到的模塊后續其他項目的復用價值最大,另一方面,將不同模塊交給不同工程師進行開發中相互扯皮的情況也將減少。
在這個基礎上,可以進行模塊調度和接口的測試,因為這些測試不依賴與模塊功能是否實現。硬件底層驅動、通信等的測試也需要在這個階段進行,已保證整個系統的基底是有效而完整的。
同時由于軟件模塊已經實現了劃分,不同模塊的職責已經明確,可以十分明確地系統需求分撥到各個模塊上。
這里需要關注的是什么是軟件需求,比如說我們現在有一個電控液壓剎車(后續參數全部瞎編的,千萬別較真),那么假定整車重量空載為1.4噸,滿載1.6噸,要求在干燥的水泥路面上80車速以下全剎車實現5秒內剎停,最大剎車距離不超過100米。選定液壓剎車系統為某某品牌某某型號,提供最大200Mpa液壓剎車力,延遲1s,工作電壓350V,工作電流1.5a等(再次說明,我對剎車一點都不懂,以上都是瞎扯淡的數據,很可能還各種錯誤)。
延伸閱讀:
二、系統需求的可行性和成本估算
名列前茅種是產品必須具備的性能、功能的實現可行性,已有移植、市場采購、自行開發,都可以。但是需要考慮最終實現這些需要多少時間、成本、占用的人力物力。
第二種是產品期望實現的需求,則在名列前茅種情況的基礎上,需要篩選出可行性和成本能接收的需求與客戶進行討價還價。
名列前茅種情況更多的是在于這個項目我們到底做不做、有沒有能力接下來,第二種情況更多是在于后續合同中我們該要多少錢,做這個項目是否劃得來。
也就是說客戶需求那里溝通到一定程度后,進行的刪減(比如說有些功能不能實現,有些功能需要更改指標,有些功能需要加錢等)后,這個才能算項目開展的系統需求。