<rt id="bn8ez"></rt>
<label id="bn8ez"></label>

  • <span id="bn8ez"></span>

    <label id="bn8ez"><meter id="bn8ez"></meter></label>

    posts - 310, comments - 6939, trackbacks - 0, articles - 3
      BlogJava :: 首頁 :: 新隨筆 :: 聯系 :: 聚合  :: 管理

    軟件體系結構標準成熟度的思考

    Posted on 2007-12-24 09:44 詩特林 閱讀(1679) 評論(0)  編輯  收藏 所屬分類: 項目管理
    應IT168寫的專稿:http://publish.itpub.net/m/2007-12-23/200712231855642.shtml

     

    軟件體系結構標準成熟度的思考

     

    軟件的體系結構標準是對系統或軟件的構造方式的描述。當組織在開發軟件應用系統時,體系結構的標準化很好的定義了開發過程當中的目標產品、開發模式、開發實踐過程等相關內容。而在本文中,讀者可以看到,軟件體系結構標準能很巧妙的加速軟件開發過程,使軟件產品交付使用周期縮短,同時可以降低軟件開發的成本。

    一、        軟件體系結構標準

    盡管對一個IT公司來說,我們承認制定了軟件體系結構標準確實是軟件成熟度的體現,但是,一個構思很差或很不成熟的標準體系,比沒有軟件體系結構標準,會由于項目的風險而變得更加的糟糕。而真正的軟件體系結構標準應該由成熟度特征、標準定義及模型分類等內容來進行體現,因此軟件體系結構標準是隨著技術的發展而發展的課題。

    乘過飛機的人都知道,航空服務的流程是十分清晰的:從定票、機場登記、行李托運、登機安檢到登機、安全注意事項、機上餐飲和娛樂服務再到下飛機離開,任何環節都是極其規范和標準的,無論哪家航空公司(國外或國內),在流程的一致性上幾乎沒有差異,顯然,在這里服務流程的標準化是高質量服務的基礎。可以設想,如果不同的航空公司服務流程不相同,將給顧客帶來怎樣的麻煩。

    為什么要積極推行軟件工程標準化工作,其道理是顯而易見的。僅就一個軟件開發項目來說,有多個層次、不同分工的人員相配合,在開發項目的各個部分以及各開發階段之間也都存在著 許多聯系和銜接問題。如何把這些錯綜復雜的關系協調好,需要有一系列統一的約束和規定。在軟件開發項目取得階段成果或最后完成時,需要進行階段評審和驗收測試。投入運行的軟件,其維 護工作中遇到的問題又與開發工作有著密切的關系。軟件的管理工作則滲透到軟件生存期的每一個環節。所有這些都要求提供統一的行動規范和衡量準則,使得各種工作都能有章可循。

    軟件工程的標準化會給軟件工作帶來許多好處,比如:提高軟件的可靠性、可維護性和可移植性(這表明軟件工程標準化可提高軟件產品的質量)提高軟件的生產率提高軟件人員的技術水平提高軟件人員之間的通信效率,減少差錯和誤解有利于軟件管理有利于降低軟件產品的成本和運行維護成本有利于縮短軟件開發周期。

    二、        軟件體系結構標準的優勢

    軟件體系結構標準定義了一系列的軟件開發邊界,而開源軟件或軟件提供商正是應用這些軟件邊界來進行軟件的開發。例如,我們日常軟件開發中所用到的應用服務器、Ajax工具包、數據庫或Web服務等等。此外,軟件體系結構標準還定義了其它一系列的軟件開發邊界,而這些軟件開發邊界主要應用于體系模式或是具體的業務問題的解決,例如B2B(電子商務,Business to business)、商業智能系統等等。同時,這類軟件邊界還可以用于構建軟件的體系基線,如在RUPRational Unified Process,統一過程)或是XPExtreme programming,極限編程)中所應用的那樣。

    由于這種軟件邊界的存在,所以很多軟件開發者或是系統架構師經常感覺到自己的創造能力受到了限制。那這種軟件邊界所帶的好處或優勢到底何在呢?通過軟件邊界的定義,就可以使已經解決的問題不在考慮的范圍之內了。從而簡化了很多問題。相反,開發人員的創造能力不但不會受到限制,反而可以集中精力于解決另外的業務問題。

    在項目管理中,始終都非常關注交付成果(Deliverable)。完成全部交付成果,就意味著覆蓋了全部的項目范圍,所有的項目活動、項目資源,都是為了有效完成這些交付成果而發生的,交付成果在很大程度上反映了項目目標的要求。通過軟件體系標準的建立,可以加速項目交付使用。。例如,對某一個項目所采用的軟件體系標準的嚴格化制定,可以將此標準廣泛的應用到類似的項目中去,可以節省類似項目的前期人力與時間投入。而組織的編輯規范可以明顯的加速軟件的交付使用過程。

    三、        標準成熟特征

    當然,并非所有的軟件體系結構標準都可以加速軟件產品的交付使用周期或是降低產品的開發費用。一套成熟與實用的標準有它自己的明顯特征。

    項目專家的建議與意見

    軟件體系結構標準的第一個特征,就是本標準是否已經得到了組織的IT項目專家的一致討論與通過,并就相關的內容進行修改與重新制定。只有經過IT項目專家組的一致認可的標準,才可有可能成軟件體系結構標準。例如,著名的De facto標準(De facto standard,有譯實質標準、業界標準或非官方標準,是指一套技術上或其他方面的規格/標準,而該套規格/標準屬于主流而且每個人都習慣依據為法定標準般跟隨),可以從已經實現的項目中獲得實惠的經驗。而通過IT項目專家討論一致通過的標準則可以應用于組織的其它項目中。

    參考模型與實現

    通過參考模型及建立的相關成文的文檔,可以比較成功的解決產品或項目開發過程的一些實質業務問題。而參考實現由于是對參考模型的具體化,從而可以更加明確的改善項目的開發過程。所以,參考模型與參考實現都將會顯著的加速體軟件系結構的制定與建設。

    支持度模型

    支持度模型需要合理的在項目或產品開發過程使用。這通常包括開發、測試及產品環境的平衡等內容。在整個開發環境中,系統應用團隊的角色及責任需要很明確的定義。而標準的制定及可操作性支持度模型的確定,通過是一個成熟標準的主要體現。

    規劃支持

    規劃支持主要通過采用特殊產品、配置的項目環境、模式等工具,來保證項目的正確實施,盡可能的避免項目失敗。

    產品實現

    產品實現是評估標準成熟度的重要的指標。

    而對于缺少如下的一些特征的項目,通過會產生一些項目風險:

    沒有經過項目專家就評估的標準,通常會以失敗或部分的失敗而告終;

    沒有參考模型和參考實現,標準將不能正確的被執行,同時可能增加軟件開發的成本;

    沒有清晰的支持度模型,將會使軟件開發人員的角色及責任重復或不清晰;

    沒有規劃支持,則過往項目的經驗不充分的加以應用與借鑒;

    最后,沒有產品實現,則軟件產品不能通過實踐來進行唯一的檢驗,不能使軟件開發嚴格的遵循軟件開發的生命周期。

    四、        軟件體系結構標準分類

    根據體系結構標準的成熟度,可以對其進行適度的分類。如下圖1所示,標準成熟度金字塔,最頂端的是最成熟的,而最低端的則是最不成熟的。


    1.結構成熟度金字塔

    1提交:這一級別意味著標準制定中已經考慮了產品、模式或實踐等因素。

    2侯選:此級別表明已經通過了IT項目專家的詳細審查。

    3推薦:推薦級別已經將參考模型及參考實現配置在合適的位置了。

    4實踐:實踐級別指已經定義了支持度模型,至少有一種產品實現。

    5最佳實踐:有多個產品實現,同時對支持度模型進行重新定義。

    上面的軟件體系結構標準成熟度分類,為標準及其成熟度提供了一種比較客觀的評估方式。可以有力排除了組織權力、個人喜愛、商業業務伙伴等人為因素的干擾。

    當然,上面的分類,基本上遵循了W3CWorld Wide Web Consortium)組織的標準分類,當然也有所變化與增加,例如增加了實踐與最佳實踐兩個階段,用來表明軟件體系結構標準的高級別的成熟度。W3C定義標準的工作流程如下所示:

    1Submission

    我們平常向會議或者雜志投遞論文叫“paper submission",這里也一樣。submission指由W3C memberwww consortium投遞自己的一個建議。W3C有可能決定不接收這個建議。

    2Notes

    如果IBMW3C提了一個Submission,而且W3C沒有拒絕這個submission,那么它就進入Note階段。Note的內容由IBM進行編輯修改,W3C是不管的。發表Note的時候,表示W3C還沒有開始和這個submission有關的任何工作。

    3Working Groups

    NotesW3C認可后,W3C會成立一個Working GroupGroup包括W3C member和有興趣的外界團隊和個人。

    4Working Draft

    Draft會在w3c的站點上公布,并邀請公共的評論和意見。Working Draft一般不應該作為參考的資料,因為它還會經過大量的修改/更新,而且可能隨時被廢棄。比如現在WSDL2.0就還在Working Draft階段,還會經過大量的修改。

    5Candidate Recommendations

    這個階段是可選的,依據論題的復雜程度而定。它一般不應該作為參考的資料,因為它還會經過大量的修改/更新,而且可能隨時被廢棄。

    6Proposed Recommendations

    Proposed RecommendationsWorking Groups工作的最后一個階段。它有被繼續修改的可能,但一般情況下,它很可能馬上不做改動地成為w3crecommendation

    7Recommendation

    Proposed Recommendations經過了W3C member的檢查和W3C的主席的蓋章后,成為 W3C recommendation。它一般是一個穩定的規范,可以作為參考資料進行學習。

    五、        小結

    在本文中,讀者可以清晰的看到使用標準如何定義組織進行軟件開發過程當中的產品、模式及實踐。同時,可以感覺與體會到標準化為軟件開發所帶來的好處,例如加速軟件產品或項目的交付周期,降低開發的總費用。

    所以的標準不盡相似。而軟件體系結構標準的主要特征卻相似,主要包括項目專家建議與意見、參考模型及參考實現、支持度模型、產品實現及規劃支持等。相應地,通過這些特征的判別,可以將標準分為以下五個級別:提交、候選、推薦、實踐及最佳實踐。

    那么,讀者所在的組織,已經建立了軟件體系結構標準嗎?他們可以按成熟度進行相應的分類嗎?已經認識、定義、溝通及成熟度標準了嗎?同時,有沒有成功的加快產品交付使用的標準實踐?如果都沒有,讀者可以考慮參考本文的內容,建立適合自己企業的標準體系。

    主站蜘蛛池模板: 亚洲AV无码专区国产乱码4SE| 亚洲精品无码久久久久秋霞| 黄页网站在线观看免费高清| 亚洲人成电影网站色| 亚洲中文字幕无码不卡电影| 1000部拍拍拍18勿入免费视频下载| 亚洲精品成a人在线观看☆| 亚洲精品蜜桃久久久久久| 99久久久精品免费观看国产| 免费一级做a爰片久久毛片潮| 亚洲AV无码久久精品蜜桃| 在线观看免费大黄网站| 中文字幕成人免费高清在线视频| 亚洲综合在线成人一区| 一级毛片直播亚洲| 亚洲免费视频观看| 国产精品永久免费视频| 亚洲AV综合色区无码二区爱AV| 久久久久久亚洲精品不卡| 无码少妇一区二区浪潮免费| 国产在线精品观看免费观看| 亚洲日本一线产区和二线产区对比| 亚洲日韩乱码中文无码蜜桃臀网站| 女人18一级毛片免费观看| 免费国产成人18在线观看| 亚洲av日韩av永久在线观看| 91精品国产亚洲爽啪在线影院| 国产精品亚洲mnbav网站| 免费看的成人yellow视频| 亚洲一区二区在线免费观看| av成人免费电影| 看Aⅴ免费毛片手机播放| 精品亚洲AV无码一区二区| 久久被窝电影亚洲爽爽爽| 丁香亚洲综合五月天婷婷| 成年性生交大片免费看| 五月亭亭免费高清在线| 无码国产精品一区二区免费模式 | 亚洲av片劲爆在线观看| 亚洲精品久久久www | 免费又黄又爽的视频|