如何進行軟件架構(gòu)驗收？

本期話題:如何進行軟件架構(gòu)驗收?

一、背景介紹

受診人職位： 甲方項目經(jīng)理，也是部門經(jīng)理

公司：最近公司委托乙方為我們開發(fā)軟件產(chǎn)品，從目前開發(fā)的產(chǎn)品來看，產(chǎn)品質(zhì)量不盡人意。而且最近我們也理解到我們這個產(chǎn)品是其的第一個產(chǎn)品(無實際經(jīng)驗)，經(jīng)驗嚴(yán)重不足。乙方告訴我們他們會以產(chǎn)品化的方式來開發(fā)這個產(chǎn)品，但從實際的種種現(xiàn)象看，乙方僅僅是為了交付而交付，沒有按照產(chǎn)品化的方式來開發(fā)。其架構(gòu)設(shè)計的更多是強調(diào)分層，而不是我們需要的基于組件化的思想下的結(jié)構(gòu)。

問題：如何對其軟件架構(gòu)進行驗收，確保其是基于組件化的思想下的結(jié)構(gòu)，避免出現(xiàn)軟件各子模塊之間強耦合的情況?

二、嘉賓分享

01

受診人遇到的問題分析及解決方案：

問題1：

產(chǎn)品質(zhì)量不盡人意 ，從題目看產(chǎn)品質(zhì)量不盡人意，大多數(shù)指可交付成果不滿足用戶要求。軟件方面的可交付成果不足，一般表現(xiàn)為功能缺失或不符，界面美觀度，操作易用性，業(yè)務(wù)流程明晰…

解決方案：

1、產(chǎn)品高保真圖的設(shè)計與批準(zhǔn)、完成美觀度的審驗

2、產(chǎn)品原型圖的設(shè)計與批準(zhǔn)、完成功能及流程的審驗

3、提交測試報告 、完成功能完整性的驗收

4、階段試運行 、完成真實情況下的實際運行情況驗收

問題2:

缺少管控：第一個產(chǎn)品 、缺少經(jīng)驗。

這個在實際情況中很容易遇到，而且是甲乙雙方產(chǎn)生問題的主要爆發(fā)點。

原因很簡單：

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

乙方只針對甲方提出的進行開發(fā)，沒有一個很好的產(chǎn)品、市場、業(yè)務(wù)等的調(diào)研。

最終結(jié)果就是甲方不斷的要求添加或者變更功能，乙方不斷的要求加預(yù)算，加工期【一般情況下都是大包合同即固定總價】。

導(dǎo)致雙方的不平衡，導(dǎo)致矛盾的產(chǎn)生。

解決方案：

1、 合同：雙方采用非固定總價合同 ，商量出一個都符合雙方利益的合同方式，實際情況下改變合同方式，比較難。因為很多單位的財務(wù)等要求關(guān)系，很難變更合同方式。

2、 甲方雇傭一個有豐富經(jīng)驗的人員來替代甲方提出業(yè)務(wù)需求。這種解決方案情況下，甲方風(fēng)險較高，而且需要有合適人員，對于沒有一點經(jīng)驗的甲方來講，容易挨坑。

3、 乙方提供人員，完成甲方需求的收集及可交付成果的設(shè)計確認(rèn)。

4、 乙方派人，甲方管理，這種人員外包的形式比較考驗甲方的管理能力，但是也能相對應(yīng)的提高質(zhì)量及速度。

問題3:

無法或很難核實或者說無法寫到合同中：

乙方說他們會以產(chǎn)品化的方式開發(fā)，沒有按照產(chǎn)品化基于組件 而是更多的強調(diào)分層。

解決方案：

明確一點：軟件開發(fā)的分層到目前為止還是比較好的一個模式。

1、分層技術(shù)其具有良好的擴展性及穩(wěn)定性，能更好的促進整個軟件系統(tǒng)的抽象化發(fā)展，并且將軟件系統(tǒng)中的復(fù)雜部分，逐步轉(zhuǎn)化到軟件開發(fā)之中。

這對于軟件系統(tǒng)的維護及發(fā)展都具有深遠(yuǎn)影響，一個層面出現(xiàn)了技術(shù)問題，并不會對其他層面造成影響，只會影響到這個層面的上下層面。

2、如果甲方認(rèn)為有問題，那么我個人認(rèn)為可能出現(xiàn)的問題就是：軟件設(shè)計的分層與甲方所說的基于組件的開發(fā)。

可以要求乙方看能否快速的變更通用的功能點，如果是組件化開發(fā)通用的功能點肯定是組件化了，是可以快速的更變。

3、個人理解產(chǎn)品化與分層的開發(fā)：

分層是表示將功能進行有序的分組：應(yīng)用程序?qū)Ｓ霉δ芪挥谏蠈?，跨越?yīng)用程序領(lǐng)域的功能位于中層，而配置環(huán)境專用功能位于低層。分層從邏輯上將子系統(tǒng)劃分成許多集合，而層間關(guān)系的形成要遵循一定的規(guī)則。通過分層，可以限制子系統(tǒng)間的依賴關(guān)系，使系統(tǒng)以更松散的方式耦合，從而更易于維護。

二者的區(qū)別除管理方式外，我認(rèn)為最大的不同之處就在于抽離實際業(yè)務(wù)中“對象”的高低程度。

總結(jié)：

新手(如甲方)要做好步步審核及授權(quán)，對于無法驗真的問題及需求需要落實到合同或者文檔中盡量的實例化，細(xì)致化，避免后期交付問題。需要自己分內(nèi)工作(需求)，如果沒有很好的處理方法可以適當(dāng)?shù)恼埻庠?/span>(外聘或者與乙方協(xié)商)。

02

本人沒有甲方經(jīng)驗，但是和甲方合作過很多年，我們甲方基本都具備多年項目經(jīng)驗，類似的問題基本不會發(fā)生，對于這個案例我也是和大家一塊進行探索。

案例中明顯存在的問題有以下幾點：

1、乙方經(jīng)驗不足，沒有類似項目經(jīng)驗

2、乙方對產(chǎn)品的設(shè)計不滿足甲方要求

3、對產(chǎn)品質(zhì)量不滿意

出現(xiàn)問題的原因主要出現(xiàn)下以下過程中：

1、對供應(yīng)商的選擇;

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

3、對產(chǎn)品的質(zhì)量的管理;

建議：

甲方項目經(jīng)理作為項目負(fù)責(zé)人，解決以上問題，建議從以上幾個過程中進行把控，而不是僅僅通過最后的驗收進行管控：

1、對供應(yīng)商的選擇，選擇資質(zhì)、有類似項目案例經(jīng)驗的乙方，通過招投標(biāo)方式選擇有實力的供應(yīng)商;

2、可以將產(chǎn)品的架構(gòu)等內(nèi)容作為非功能性需求進行明確;合同中將產(chǎn)品關(guān)注的需求點、架構(gòu)等要求進行明確，且作為驗收的標(biāo)準(zhǔn);

3、對產(chǎn)品研發(fā)過程中的重要成果物進行審核和把控，比如需求規(guī)格說明書、整體設(shè)計方案、系統(tǒng)架構(gòu)、技術(shù)選型等必須甲方評審確認(rèn)后方可進入下一階段，如果甲方項目經(jīng)理不具備相關(guān)能力，可邀請相關(guān)方面希賽網(wǎng)參與評審;

4、對乙方研發(fā)監(jiān)控管理過程中，暴露出來的風(fēng)險問題，及時上報甲乙方領(lǐng)導(dǎo)，要求給乙方給出解決方案和措施，避免風(fēng)險和問題堆積到驗收階段，導(dǎo)致項目失敗。

03

/ 我有話說 /

凱-青島-軟件：

1、組件化，如果是一款普通應(yīng)用的話，比如一個款類似微信的聊天應(yīng)用，這樣不需要分包部署，組件化更多是底層開發(fā)的組件化，從外面整體應(yīng)用是看不出來的。不是所有的問題，都會導(dǎo)致產(chǎn)品掛掉，有的時候表現(xiàn)是性能方面。

2、有一個專業(yè)開發(fā)和測試進行驗收是必不可少的。所以他們項目這里有沒有專業(yè)人員也很重要，要不然很容易被坑。

3、現(xiàn)在產(chǎn)品已經(jīng)開發(fā)完了，我覺得及時止損最佳方案是找一個專業(yè)稱職的技術(shù)人員，和他講明白產(chǎn)品需求，讓他按照需求檢查開發(fā)完的產(chǎn)品，找出問題，讓外包公司及時更改，至于變更產(chǎn)生的各種費用，就要看具體溝通能力了”

阿德-淄博-城市公用：

“如果項目針對架構(gòu)有要求的話，應(yīng)該在設(shè)計階段就應(yīng)該介入，進行評審。而不是到了最后驗收階段的話，才對架構(gòu)方面進行驗收判斷 "

“這種對架構(gòu)要求比較嚴(yán)格的，我感覺這個甲方應(yīng)該也是一個開發(fā)公司，乙方開發(fā)完成以后，應(yīng)該把所有的源代碼之類的全部提交交付，然后甲方在此進行二次開發(fā)的時候可以進行復(fù)用?！?/p>

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

”首先要看合同有沒有定義驗收標(biāo)準(zhǔn)，沒有就要補上，其次，舉個例子，假如框架是做優(yōu)化的，可以做下對比，跟原有框架，或者世面上的成熟框架對比，復(fù)核足夠標(biāo)準(zhǔn)，就可以跟領(lǐng)導(dǎo)交差，走驗收，以后再根據(jù)情況起新項目，最后，要是沒有達(dá)到標(biāo)準(zhǔn)，只好先不驗收，甲方介入項目促進完成，其實這就費勁了，雙輸預(yù)警?！?/p>

簡單-西安-軟件：

”依據(jù)場景，項目處于準(zhǔn)備驗收階段，主要有以下幾點問題：

1. 甲方認(rèn)為項目未能按照產(chǎn)品化開發(fā)。 2. 是否達(dá)到驗收條件。

處理建議：

1. 可要求乙方提供軟件產(chǎn)品功能詳細(xì)設(shè)計、數(shù)據(jù)庫設(shè)計、架構(gòu)設(shè)計等相關(guān)文檔。審核是否能夠達(dá)到產(chǎn)品化要求?？捎杀竟緝?nèi)部進行也可尋找第三方審核。

2. 合同是否約定驗收標(biāo)準(zhǔn)，若有則按照合同履約即可;若沒有，依據(jù)行業(yè)產(chǎn)品標(biāo)準(zhǔn)要求乙方整改。

3. 查看項目風(fēng)險計劃(若有) 下下策，告知項目發(fā)起人。 綜上，項目應(yīng)該處于失控狀態(tài)，且目前階段，項目經(jīng)理對項目干預(yù)程度較弱。 建議對項目復(fù)盤，更新組織過程資產(chǎn)。避免類似情況發(fā)生。

此場景，但項目處于驗收階段，項目經(jīng)理在此階段對項目的影響已經(jīng)非常弱了，兩條路可選，按著乙方繼續(xù)做，再找個乙方。對整個項目而言，此舉以是事后了，即便明知不可為。而項目事前和事中并未交代。此項目經(jīng)理應(yīng)該注重其事前和事中?！?/p>

聰少-廣州-無業(yè)閑人：

”項目軟件規(guī)劃、分析、設(shè)計，這三步少不了，沒經(jīng)驗，得也得有清晰可見文檔，驗收是對著這些文檔做 集成測試、功能測試和驗收測試。“

天天-北京-鐵路自動化：

”首先要甲方把需求提明確，再就是乙方對甲方需求的分解落地情況要及時參與評審;甲方如果需求明確的話 是否能夠找到類似原型的設(shè)計，供乙方做標(biāo)桿“

?佚名氏?-上海-IT：

”本來，軟件驗收的時候，應(yīng)該有個驗收依據(jù)，比如招投標(biāo)書，合同，需求說明書，總體設(shè)計書書等，我估計甲方只有合同吧。

如果沒有驗收依據(jù)，沒有對架構(gòu)作事先的要求說明，沒沒啥好驗收了，請不請第三方都一樣?！?/p>

總結(jié)：

1、合同中將產(chǎn)品關(guān)注的需求點、架構(gòu)等要求進行明確，且作為驗收的標(biāo)準(zhǔn)。

2、沒有經(jīng)驗的甲方可以尋求專業(yè)的第三方幫助。

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

三、討論內(nèi)容整理

[以上關(guān)于項目團隊管理的內(nèi)容都來自于希賽「PM創(chuàng)造營」群內(nèi)話題討論，由?@小M妹妹? 妹妹整理，由以下小伙伴分享完成@飛入閑窗@安靜@zhanghx@凱-青島-軟件@阿穎-深圳-信息安全@凡塵若夢-長沙-IT@Fiona-福州-軟件@Zen.Wu-政務(wù)教育高校@MISS丁 杭州 軟件@追星騎士-深圳-金融IT@?佚名氏?-上海-IT@walker-成都-IT@上海-青春-制造業(yè)-ERP@Soda-寧波-汽車@欣鑫-成都-運營@合肥-Lee-IT實施@踏風(fēng)而至-北京-通信@王昱-長沙-在線教育@牧云-成都-互聯(lián)網(wǎng)產(chǎn)品@阿敏敏-武漢-互聯(lián)網(wǎng)產(chǎn)品@李潔蘭-廣州-軟件@涼風(fēng)有信-廣州-ERP@浩-深圳南山-金融行業(yè)@阿德-淄博-城市公用@Bysing-廣東-珠寶@黑科技-貴陽-IT@天天-北京-鐵路自動化@閃光創(chuàng)世-上海-IT@追星騎士-深圳-金融IT@D-深圳-OTA@Roy-濟南-智慧停車@沈秋成-成都-IT@和煦風(fēng)-成都-軟件@建慶-深圳-智慧城市-GIS@簡單-西安-軟件@孤獨老狼-鎮(zhèn)江-ERP]