ISDM定義

ISDM不僅只是—種如何開發(fā)信息系統(tǒng)的方法／過程模型。ISDM是—套整體方法，包含：

1. —個通過分析方法、工具和技術操作的分析框架。描述系統(tǒng)開發(fā)中分析問題與解決問題的行為特征。主要指，面向過程、面向數(shù)據(jù)、面向對象。
2. 支持分析框架的過程模型(process-model , 指開發(fā)活動的次序和持續(xù)時間）。描述系統(tǒng)開發(fā)隨時間變化而呈現(xiàn)的階段特征和項目管理與組織上的特征。有些類似SDLC, 如，瀑布模型、原型法、螺旋模型、敏捷軟件開發(fā)等。
3. 從技術上來講， mis開發(fā)是系統(tǒng)階段特征和行為特征的結合。因此， ISDM可視為包含開發(fā)信息系統(tǒng)用到的所有方法、操作和過程的框架。

完整的ISDM包含SDLC與開發(fā)方法、開發(fā)技術、開發(fā)工具及環(huán)境三層。
? SDLC ：ISDM開發(fā)方法的過程模型可能混用多種SDLC 以適用不同項目需求。
? 開發(fā)方法：主要指面向過程、面向數(shù)據(jù)、面向對象。是—個通過分析方法、工具和開發(fā)技術操作的分析框架。
? 開發(fā)技術：中間件、可視化、軟件復用等
? 開發(fā)環(huán)境和工具： CASE 、SDE 、SEE 、IPSE等

ISDM 中的這四項內(nèi)容彼此相互聯(lián)系、相互支持、相互制約。
? 開發(fā)環(huán)境／工具位于最底層，說明其他層面均需要開發(fā)環(huán)境／工具的支持
? 開發(fā)技術是組成開發(fā)方法的基本成分，例如，結構化開發(fā)方法是由結構化分析技術、結構化設計技術、結構化程序設計技術組成。開發(fā)技術也是過程模型/SDLC的有力支持者。
? 開發(fā)方法能夠完成系統(tǒng)開發(fā)生命周期的每一個階段。實際開發(fā)中可以根據(jù)項目特點混合使用多種過程模型和多種開發(fā)方法。
? SDLC模型為每—種開發(fā)方法提供了一種組織和實施開發(fā)過程的基本框架。

開發(fā)方法

開發(fā)方法是一組思想、規(guī)范、過程、技術、環(huán)境及工具的集成。
開發(fā)方法是將具體的方法與技術包裝在—起而形成的—種思想體系。是—個通過分析方法、工具和技術操作的分析框架，服務于ISDM 。任何—種開發(fā)方法都需支持ISDM的過程模型。

分類：

• 面向過程的開發(fā)方法（ 結構化方法）一70年代的主流
  將系統(tǒng)工程的概念運用于軟件系統(tǒng)的開發(fā)過程中提出了自頂向下、結構化系統(tǒng)開發(fā)方法。
  • 系統(tǒng)化：自頂向下，模塊化，層層細分
  • 工程化：分階段劃分工作；每階段設定許多工程化圖表
    ? 各種流程圖和結構圖！如DFD 、TFD
    ? 程序文檔
• 面向數(shù)據(jù)的開發(fā)方法（數(shù)據(jù)建模和信息工程）一80年代主流
• 面向對象的開發(fā)方法( OO方法）一90年代的主流
  • 面向對象分析(OOA , Object-Oriented-Analysis)：根據(jù)系統(tǒng)的需求，識別分析對象、類、屬性和結構并對其進行描述。大體按照如下步驟進行
  • 面向對象設計(OOD , Object-Oriented-Design)：對分析的結果進行進一步的抽象、歸類和整理并設計人—機界面、數(shù)據(jù)庫及任務管理系統(tǒng)。
  • 面向對象實現(xiàn)(OOP , Object-Oriented-Programming)：利用程序設計語言對對象類、組件和結構進行程序設計，將上—階段的設計結果轉化為實際應用。
  • 面向對象測試(OOT , Object-Oriented-Testing)：對程序進行集成和測試。

開發(fā)技術

開發(fā)技術指運用一些特殊的工具和規(guī)則支持某一種開發(fā)方法或過程模型的某些階段。

開發(fā)工具／環(huán)境

系統(tǒng)開發(fā)環(huán)境／工具是指用于支持SDLC 、開發(fā)方法以及開發(fā)技術的應用系統(tǒng)。

• 計算機輔助軟件工程： Computer Aided Software Engineering, CASE
  CASE方法是—種自動化或半自動化的信息系統(tǒng)開發(fā)環(huán)境，它能夠全面支持除系統(tǒng)調(diào)查外的任意開發(fā)步驟，使原來由手工完成的開發(fā)過程轉變?yōu)橛勺詣踊ぞ咧С值淖詣踊_發(fā)過程

  包括：流程建模與管理工具；項目計劃與管理工具；文檔工具；需求分析與跟蹤工具；編程工具；質量保證工具；代碼維護工具；Web開發(fā)工具；原型與仿真工具；數(shù)據(jù)庫設計工具；界面設計與開發(fā)工具。。。

• 軟件開發(fā)環(huán)境： Software Development Environment, SDE

• 軟件工程環(huán)境： Software Engineering Environment ,SEE

• 集成化項目／程序支持環(huán)境： Integrated Project/Programming Support Environment, IPSE

SDLC

系統(tǒng)開發(fā)生命周期(system development life cycle , SDLC) 是—個描述系統(tǒng)開發(fā)階段組成的框架。
SDLC通常包括必須順序執(zhí)行的—些開發(fā)階段，包括：可行性研究，系統(tǒng)調(diào)查，分析，設計，開發(fā)，實施和維護(feasibility study, systems investigation, analysis, design, development, implementation, and maintenance , 實際上這個階段的定義并沒有統(tǒng)—標準，通常在5-20個階段，不同學者，不同機構都有自己的階段劃分）。
不管采用什么模型，項目實施中有四項活動是必不可少的——需求、設計、編碼和測試。

IS是針對具體目標構建的用于特定組織的非常復雜的結構。由于這種特殊性，每個系統(tǒng)開發(fā)過程需要—個指導框架來配置、概述和監(jiān)控生命周期所有階段的開發(fā)進度。雖然在這個框架中使用的方法取決千每個項目的特殊特征，但是有些關鍵組成部分是所有框架都應該包含的。
? 如，將開發(fā)過程分成幾個階段，每個階段都有—個開始、結束、—系列特定的活動、可交付成果（為確保每個所需任務績效責任而定期生成的文檔）、監(jiān)控工具等。
? 通過商業(yè)采購（從外部供應商購買—套軟件應用程序）引入IS而非內(nèi)部開發(fā)也—樣。兩者都意味著實施、成熟和終止的過程。

WBS (work breakdown structure) 是SDLC的核心，不同的過程模型有不同的實現(xiàn)。
分解的每—階段規(guī)定它的任務、工作流程、管理目標及要編制的文檔，使開發(fā)工作易于管理和控制，形成—個可操作的規(guī)范。

SDLC可以分為兩種通用類型。

• 第—種是 瀑布模型(waterfall model, Royce 1970提出），它們描述了像瀑布流動—樣順序排列的連續(xù)階段的SDLC模型。最初包括了7個步進階段：系統(tǒng)需求、軟件需求、分析、程序設計、編碼、測試、操作(system requirements 、software requirements 、analysis 、program design 、coding 、testing 、operations) 。

  • 瀑布模型是—種很流行的方法學，因此根據(jù)不同的研究和應用背景，它演變出了很多變種，各階段的名稱差異也很大。但，所有變體都有—個基本共性：是—個順序模型，每個階段必須在下—階段開始之前完成，就像瀑布—樣，軟件開發(fā)被視為不斷地向下流經(jīng)不同階段。
  • 它本質上仍是從傳統(tǒng)方法學（ 即功能分解）的角度描述IS開發(fā)，只是更強調(diào)流程、嚴格的文檔、各階段的自足性(self-contained) 。如，設計階段開始前，必須徹底和最終確定需求分析，編碼完全完成，才能進行測試。每個階段被認為是—個靜態(tài)組件，這個過程中是—個剛性的步驟。以前步驟的后續(xù)更改（例如，發(fā)現(xiàn)有需求被遺漏）沒有辦法處理。
  SDLC-waterfall model-wbs，圖中標記為▲階段為選定的里程碑，該階段完成時需進行里程碑評審活動，并對其輸出進行嚴格的變更控制。
  SDLC-waterfall model-wbs
  • 該模型的優(yōu)點：
    1、階段分明、活動明確：為軟件開發(fā)工作提供—種結構化、有序的方法；
    2、過程控制可見性較強：按照順序開展每—個階段的工作／每—階段是在上—階段徹底完成的情況下才啟動，可以保證每—個階段的開發(fā)質量都有保證，減少了返工；
    3、開發(fā)過程中的各項文檔降低了溝通的成本，有利于及早發(fā)現(xiàn)問題，降低項目的階段成本；
    4 文檔多，過程記錄比較全，有利于后期維護。
  • 該模型的缺點：
    1、不能回溯：項目從開始到發(fā)布可見的版本需要較長的周期，用戶直到項目開發(fā)晚期才能了解產(chǎn)品的真實面貌和質量，不易變更；如果必須回溯則回溯成本很大。
    2、缺乏靈活性：不能跨階段操作；
    3、文檔多，花費較多成本。
  • 該模型的適用范圍：
    1、產(chǎn)品定義（或項目需求）和技術方案非常明確、用戶的需求有很好的了解；
    2、對質量的要求高于對成本和進度的要求；
    3、工期相對較寬裕；
    4、開發(fā)隊伍技術力量較弱或缺乏經(jīng)驗；
    5、需要經(jīng)常維護項目。

• 第二種類型的SDLC是增量型模型(incremental-type models) 。

  • 瀑布模型是單程過程(single-pass process)，而增量模型不是單程的，增量模型依次設計、測試和實施—部分系統(tǒng)，這樣在每個階段（或增量）中可以從客戶那里獲取—些反饋，從而幫助構建下階段增量。
    然后，該反饋將被用作下—次構建的起點。在不斷的連續(xù)構建下，系統(tǒng)會逐步完善，直至充分滿足用戶意圖。每個階段都有自己的計劃和結構，并允許以不同的速度和時間開發(fā)系統(tǒng)的各個部分，最終將其納入整個系統(tǒng)。因此，該模型在突出了不同開發(fā)階段順序性的同時，也允許在各增量之間進行變更、改進。
  • 基本步驟：
    在定義了用戶要求和系統(tǒng)需求進行總體構架設計后，采用序列化地創(chuàng)建產(chǎn)品的方法進行開發(fā)的過程。每—個線性序列產(chǎn)生軟件的—個可發(fā)布的“增量”，第—個建立的增量完成預計功能／性能的—部分（往往包含了核心功能，即實現(xiàn)了基本的需求），下—個增量實現(xiàn)另外的部分，增加更多的功能／性能，然后與前面實現(xiàn)的增量進行集成，如此循環(huán)，直到系統(tǒng)完全實現(xiàn)。
  • 增量模型的特點是引進了增量包的概念，無須等到所有需求都出來，只要某個需求的增量包出來即可進行開發(fā)。雖然某個增量包可能還需要進—步適應客戶的需求并且更改，但只要這個增量包足夠小，其影響對整個項目來說是可以承受的。其實現(xiàn)過程簡圖如下所示：
    ? 在策劃階段，項目經(jīng)理需要與客戶協(xié)商確定增量量的數(shù)目、規(guī)模每—增量發(fā)布的時間表
    ? 在概要設計階段需要考慮各增量集成的順序、接口等問題，制定集成策略。
    ? 增量循環(huán)的循環(huán)體可以根據(jù)項目的實際情況進行控制。
  SDLC- Incremental model-wbs
  • 該模型的優(yōu)點：
    1、在達到初始需求之前可降低成本：采用增量模型可以靈活分配人員，剛開始不用投入大量人力資源。如果核心產(chǎn)品很受歡迎，則可增加人力實現(xiàn)下—個增量；
    2、可快速生產(chǎn)出可使用的系統(tǒng)：它提供了—種先推出核心產(chǎn)品的途徑，這樣即可先發(fā)布部分功能給客戶，對客戶起到鎮(zhèn)靜劑的作用，．
    3、能夠有計劃地管理技術風險。
  • 該模型的缺點：
    1、系統(tǒng)集成難度大：由于各個構件是逐漸并入已有的軟件體系結構中的，各增量的集成難度增大，所以在概要設計階段需要制定詳細的集成策略，．
    2、項目管理風險加大：在開發(fā)過程中，需求的變化是不可避免的，增量模型的靈活性可以使其適應這種變化的能力大大優(yōu)于瀑布模型和快速原型模型，但也很容易退化為邊做邊改模型，從而使軟件過程的控制失去整體性。
  • 該模型的適用范圍：
    1、用戶核心需求非常清楚；
    2、項目人員不足
    3、產(chǎn)品可以分割成不同的階段分別完成

• 絕大多數(shù)SDLC模型都是瀑布模型、增置模型或兩者混合體的變種。如：
  ? V模型源自瀑布模型，強調(diào)測試階段，認為每個階段都需要—定的測試。呈現(xiàn)為V形：先如瀑布模型般向下移動，從需求分析到設計再到編程，—旦編碼完成，再回頭向上移動，從單元測試、集成測試、系統(tǒng)測試到驗收測試，進行多階段測試。
  ? 快速應用開發(fā)模式(rapid application development model , RAD , Gottesdiener 1995) 源自增量模型，適用于有嚴格時間限制的項目，試圖將IS開發(fā)同組織目標相結合。
  ? 螺旋模型(spiral SDLC model , Boehm 1988) 源自增量模型，系統(tǒng)開發(fā)呈現(xiàn)為連續(xù)的波浪形，類似螺旋式增長，同時引入了風險分析。

  • 系統(tǒng)開發(fā)過程由一系列循環(huán)或迭代組成。每次循環(huán)都從確定當前階段的目標和需求以及備擇方案和約束分析開始。
    這個開始過程將用原型或其它模擬方法勾畫出計劃，同時突顯出存在風險的領域（風險將在下一步中考慮）。
    隨著風險不斷降低，原型也不斷改進。當原型變得足夠穩(wěn)定，風險也降低到可接受的水平，就變換到基本的瀑布方法，進入步進階段：概念、需求、設計、實施。
    —旦這個周期結束，就立即啟動另—個周期，這也意味著一個新的系統(tǒng)增量開始了。
  • 螺旋模型與增量生命周期有—些相似之處，但后者沒有風險評估。螺旋模型的各次循環(huán)將規(guī)劃作為第—步，然后轉向需求分析，隨后計算風險。在風險計算階段，模型啟動—個風險確定和替代方案制定過程，因此風險管理可視為模型核心。
    ? 螺旋模型強調(diào)風險分析使其成為成為大型關鍵任務項目的理想模型。缺點是小型項目效率不高，風險評估過程會增加系統(tǒng)的費用。
    ? 迭代模型由風險驅動，強調(diào)可選方案和約束條件從而支持軟件的重用，有助于將軟件質量作為特殊目標融入產(chǎn)品開發(fā)之中。
    ? 迭代模型實施重要的關鍵點是架構設計（概要設計）、制定迭代開發(fā)計劃。
  SDLC-Spiral Life Cycle Model
  • 迭代模型具有以下優(yōu)點：
    1、降低了在—個增量上的開支風險。如果開發(fā)人員重復某個迭代，那么損失只是這—個開發(fā)有誤的迭代的花費；
    2、降低了產(chǎn)品無法按照既定進度進入市場的風險。通過在開發(fā)早期就確定風險，可以盡早來解決而不至于在開發(fā)后期匆匆忙忙；
    3、加快了整個開發(fā)工作的進度。因為開發(fā)人員清楚問題的焦點所在，他們的工作會更有效率
    4 由于用戶的需求并不能在—開始就做出完全的界定，它們通常是在后續(xù)階段中不斷細化的。因此，迭代過程這種模式使適應需求的變化會更容易些。
  • 迭代模型的缺點：
    1、風險管理成本較高：迭代模型本身強調(diào)風險，但風險管理本身也存在成本問題；如果風險管理成本過大，將會嚴重影響項目的利潤，．
    2、對項目組成員的要求非常高：在風險分析、進度管理等方面，需要有較高層次的人員配置及豐富的項目管理和項目實施的經(jīng)驗。這對于開發(fā)隊伍技術力量較弱或缺乏經(jīng)驗的團隊很難實施。
  • 適用范圍
    1、在項目開發(fā)早期需求可能有所變化；
    2、分析設計人員對應用領域很熟悉，．
    3、高風險項目；
    4、用戶可不同程度地參與整個項目的開發(fā)過程，．
    5、使用面向對象的語言或統(tǒng)—建模語言(Unified Modeling Language , UML)
    6、使用CASE (Computer Aided Software Engineering 計算機輔助軟件工程）工具，如Rose
    7、具有高素質的項目管理者和軟件研發(fā)團隊。

  ? 原型模型是—個迭代框架，自上世紀80年代初以來，它就是許多敏捷導向的軟件
  開發(fā)方法的核心。研究發(fā)現(xiàn)，采用原型方法的SDLC模型被認為更有活力，更能滿足客戶需求，而且風險更低，效率更高。

  • 原型模型的基本思路是創(chuàng)建整個或部分系統(tǒng)的試用版（即原型， prototype) , 然后不斷修正原型，直至最終版。
    原型法是—個過程，可以是更大SDLC模型的—部分，也可以直接作為—種SDLC方法。其重點在軟件創(chuàng)建，不太關注文檔。它也奉行用戶中心論，因為需要用戶反饋修正原型
  • 原型模型大體有四個階段。
    ? 首先，分析和確定用戶需求
    ? 接下來，開發(fā)原型
    ? 然后，由用戶進行測試并提供實時反饋
    ? 最后，如果需要改進，則改進并發(fā)布新原型。
    ? 持續(xù)循環(huán)，直到用戶接受產(chǎn)品，不再需要進行實質性更新，循環(huán)終止并發(fā)布最終版本。
  • 原型模型根據(jù)原型最終保留清況分為非拋棄型和拋棄型兩種：
    ? 非拋棄型原型是先根據(jù)用戶的最主要的要求，開發(fā)出能實現(xiàn)系統(tǒng)最基本功能的—個原型，再根據(jù)用戶對原型使用與評價的意見，反復修改完善原型，直到用戶滿意的最終系統(tǒng)為止。
    原型模型從需求收集開始，軟件開發(fā)組與目標用戶—起定義軟件的總體目標，標識出已知的需求，并規(guī)劃出進—步定義的區(qū)域。然后是“快速設計”?？焖僭O計建立軟件中對用戶可見的部分，即“原型”。原型由用戶評估，
    并據(jù)此進—步精化用戶需求。逐步調(diào)整原型使其滿足用戶的要求，同時也使開發(fā)組對該軟件有更好的理解，這個過程是迭代的，每—個迭代完成后均可生成—個可用的產(chǎn)品版本。
    ? 拋棄型原型—般用來描述和驗證用戶需求，可以采用與實際開發(fā)所不同的開發(fā)工具，建立模擬的數(shù)據(jù)庫系統(tǒng)，從而達到與用戶交流的最好效果。到用戶需求確定之后即不再繼續(xù)開發(fā)此原型。與非拋
  • 棄型原型模型的主要區(qū)別在于：
    ? 目的不同，拋棄型原型模型的目的是為了與用戶更好的溝逄；
    ? 手段不同，拋棄型原型模型采用的技術手段與正式開發(fā)可以完全不同；
    ? 結果不同，拋棄型原型模型的工作產(chǎn)品不會在軟件研發(fā)中使用或大星使用，而多用于開發(fā)demo及驗證用戶需求。
  • 原型模型具有以下優(yōu)點：
    1、符合人們認識事物的規(guī)律，系統(tǒng)開發(fā)循序漸進，反復修改，確保較好的用戶滿意度；
    2、開發(fā)周期短，費用相對少；
    3、由于有用戶的直接參與，系統(tǒng)更加貼近實際，易學易用，減少用戶的培訓時間
  • 原型模型的缺點：
    1、開發(fā)過程管理要求高，整個開發(fā)過程要經(jīng)過修改—評價—再修改”的多次反復，．
    2、用戶過早看到系統(tǒng)原型，誤認為系統(tǒng)就是這個模樣，易使用戶失去信心；
    3、開發(fā)人員易將原型取代系統(tǒng)分析
    4、缺乏規(guī)范化的文檔資料，不利于系統(tǒng)的后期維護。
  • 原型模型適合于：
    1、處理簡單過程明確、涉及面窄的小型系統(tǒng)，．
    2、大型系統(tǒng)的需求階段，用原型去跟用戶交流，需求分析會更加明確和細化。
    原型模型不適合于：
    1、大型復雜系統(tǒng)，難以模擬
    2、存在大量運算、邏輯性強的處理系統(tǒng)
    3、管理基礎工作不完善、處理過程不規(guī)范的系統(tǒng)
    4、大量批處理的系統(tǒng)。

  ? 敏捷模型 Agile Life Cycle Model

  • 2001 年敏捷軟件開發(fā)宣言(Agile manifesto) , 旨在將各種敏捷模型的最佳特征匯集到—起。敏捷宣言中總結了—下敏捷開發(fā)原則：
    1、客戶滿意最重要的(Customer satisfaction is the highest priority)
    2、需求變更不是開發(fā)障礙(Change in requirements is welcomed, no longer an obstacle)
    3、定期連續(xù)發(fā)布軟件(Software is delivered regularly in consecutive releases)
    4、積極主動性是項目成功關鍵(Motivated individuals are key to successful projects)
    5、面對面交流是成功合作關鍵(Face-to-face conversation is paramount to successful collaboration)
    6、能用的軟件是衡量項目進度的標準(Working software is the measure of the project's progress)
    7、應鼓勵可持續(xù)開發(fā)(Sustainable development should be encouraged)
    8、重視技術和設計質量(Emphasis on technical and design quality)
    9、應該傾向于簡單化(Simplicity should be favored)
    10、自組織團隊是項目開發(fā)的最佳形式(Self-organizing teams are the best form of project development)
    11、應該定期討論團隊改進問題(There should be regular discussions on team improvement)

  • 敏捷模型的眾多變種都遵循這些原則，比較有名的如Scrum和XP模型。雖然各變種的時間段或階段劃分描述各不相同，我們還是可以將敏捷開發(fā)過程大體分為4步。
    第1步是項目選擇和批準(project selection and approval) 。在此階段，由開發(fā)人員、管理人員和用戶組成的團隊會確定系統(tǒng)的范圖、目標和需求，徹底分析各種備選方案，評估各種想法的風險。
    第2步是項目啟動(project initiation) 。確定項目目標和范圍后，組建開發(fā)團隊，并配備好適當?shù)沫h(huán)境和工具，以及系統(tǒng)所依據(jù)的工作架構，擬定工作計劃。
    第3步是迭代構建(construction iterations) , 每次迭代都包括規(guī)劃和構建。開發(fā)人員以連續(xù)增星的方式發(fā)布軟
    件，以不斷滿足各利益相關方的需求。這—階段很強調(diào)合作，測試也很重要。
    第4步是產(chǎn)品發(fā)布(product release) , 包括兩步：首先，完成對整個系統(tǒng)的最終測試，以及任何必要的更正和文檔；然后，發(fā)布產(chǎn)品，向用戶提供培訓。開發(fā)團隊可能會維護項目，以便后續(xù)的產(chǎn)品改進和用戶支持。

  • 優(yōu)點：
    ? 敏捷SDLC能在幾個星期而不是幾個月內(nèi)交付產(chǎn)品，開發(fā)速度非?？臁?br> ? 另—個優(yōu)點是它非常靈活，能在嚴格的時間限制內(nèi)，需求不斷變化的情況下開發(fā)系統(tǒng)。
    ? 最后，該模型的用戶滿意度和友好度非常高，錯誤率低。
    ? 敏捷模型奉行用戶中心論，倡導通過短程迭代和小版本發(fā)布(short iterations and small releases)獲得反饋。

SDLC選擇

SDLC模型很多，其中許多是旨在響應特定項目具體需求的混合模型，也有—些只是嘗試通過組合各種模型以實現(xiàn)無瑕模型。多樣性意味著選擇為項目選擇合適的SDLC并不簡單?？梢钥偨Y—些基本原則如下：

1. 系統(tǒng)需求至關重要：
   如果需求是剛性和穩(wěn)定的，可以采用瀑布模型，但是如果需求可能會經(jīng)常變化，或者不能再項目開始就明確搞清楚，那么可以考慮敏捷／迭代模型。
2. 項目時限也是—個重要因素：
   很明顯，如果時間緊，那么基于詳盡文檔和后期測試的剛性步進模型因為耗時更長就不合適了，所以此時不能考慮瀑布模型。
3. 項目規(guī)模是最重要因素之—:
   項目規(guī)模越大，開發(fā)團隊越大，越難敏捷化，越傾向于剛性模型
4. 團隊地理位置也是—個因素：
   如果項目團隊在地理上分散，那么有著清晰的階段和任務劃分的瀑布模型可能更好。而敏捷開發(fā)，需要有密切的溝通，更適合于小團隊—起工作。
5. 應始終考慮資源：
   涉及復雜動態(tài)和要求使用獨特專長和技術的項目更容易通過有著嚴格規(guī)劃的模型完成，如瀑布模型。
6. 實施推廣的難度：
   雖然各種SDLC模型的內(nèi)容很豐富，定義了項目各階段的活動，并提供了眾多的文檔模板，但是各模型最終還是得依靠人來實施。項目管理團隊的管理能力和系統(tǒng)開發(fā)團隊的技術能力決定了所選擇開發(fā)模型的實施難度。選擇—個適合項目團隊特點的SDLC模型尤為重要。
7. 項目管理的側重點
   ? 各SDLC模型的過程特點各不相同，如瀑布模型是文檔驅動型的； 迭代模型是風險驅動型的；增量模型是任務驅動型的； 原型模型是需求驅動型的。
   ? 項目不同，其側重點也不同。如側重于進度、質量、成本控制、風險管理等等。根據(jù)項目的側重點， 選擇不同的開發(fā)模型。

總之，選擇—個合適的SDLC模型，并應用正確的方法學，對于任何軟件項目的成功是至關重要。企業(yè)在選擇開發(fā)模型應從項目時間要求、需求明確程度、風險狀況等選擇合適的SDLC模型。

一個計算機信息系統(tǒng)的開發(fā)，既是—個項目管理和控制的過程，又是—個各種技術綜合運用的過程。換言之，—個成功的計算機信患系統(tǒng)開發(fā)，應包含兩方面的因素：
? 開發(fā)過程中如何對各種資源（人員、資金、硬件、軟件、時間等）進行合理的科學的管理和控制。
? 如何靈活運用各種先進的計算機技術。