軟件需求管理ppt課件-展示頁
2025-01-19 23:26本頁面
【正文】 plementary Specifications Features Software Requirements Needs Requirements and Associated Documents StakeholderRequests Vision Document Design, Test, Documentation Requirements Delete a Requirement in a Document 。 ?每一個(gè)已應(yīng)用的需求（是指已劃過基線）建議變更和實(shí)現(xiàn)變更的數(shù)量。 ?已實(shí)現(xiàn)需求變更（包括增、刪、改）的合計(jì)數(shù)量（也可以用在基線上占需求總數(shù)的百分比來表示）。 ?配置管理部門。 ?技術(shù)支持部門。 ?市場部或客戶代表。 ?開發(fā)部門。 簡單變更控制步驟模板 ① 目的 ② 范圍 ③ 定義 5. 任務(wù) ① 產(chǎn)生變更請(qǐng)求 ② 評(píng)估變更請(qǐng)求 ③ 作出決策 ④ 通知變更人員 6. 驗(yàn)證 7. 結(jié)束條件 變更管理活動(dòng)中可能的項(xiàng)目角色 角 色 描述及責(zé)任 變更控制委員會(huì)主席 變更控制委員會(huì)的主席 ， 在 C C B意見不一致情況下可以獨(dú)自做出決定 CCB 決定采納或拒絕針對(duì)某項(xiàng)目所建議的變更請(qǐng)求的團(tuán)體 評(píng)估者 應(yīng)項(xiàng)目管理者要求分析所建議的變更帶來影響的人員 修改者 負(fù)責(zé)實(shí)現(xiàn)已經(jīng)被認(rèn)可的請(qǐng)求變更，按時(shí)更新變更狀態(tài)的人員 建議者 提交新變更請(qǐng)求的人 項(xiàng)目管理者 負(fù)責(zé)指定評(píng)估者和修改者的人員 請(qǐng)求接受者 接受提交變更請(qǐng)求的人 驗(yàn)證者 負(fù)責(zé)決定變更是否正確執(zhí)行的人 變更控制委員會(huì)的組成 ?產(chǎn)品或計(jì)劃管理部門。 ?絕不能從數(shù)據(jù)庫中刪除或修改變更請(qǐng)求的原始文檔。 ?簡單請(qǐng)求一個(gè)變更不能保證能實(shí)現(xiàn)變更，要由項(xiàng)目變更控制委員會(huì)（ C C B）決定實(shí)現(xiàn)哪些變更。 變更控制策略 ?所有需求變更必須遵循的過程，按照此過程，如果一個(gè)變更需求未被采納，則其后過程不再予以考慮。 ?控制需求擴(kuò)展的另一個(gè)有效的技術(shù)是原型法，這個(gè)方法能夠給用戶提供預(yù)覽所有可能的實(shí)現(xiàn)，以幫助用戶與開發(fā)者溝通從而準(zhǔn)確把握用戶的真實(shí)需求。 ?評(píng)估每一項(xiàng)建議的需求和特性，將它與項(xiàng)目的視圖和范圍相比較決定是否應(yīng)該采納它。 ?若不控制范圍的擴(kuò)展將使我們持續(xù)不斷地采納新的功能，而且要不斷地調(diào)整資源、進(jìn)度、或質(zhì)量目標(biāo)，這樣做極其有害。 ?業(yè)務(wù)過程、市場機(jī)會(huì)、競爭性的產(chǎn)品和軟件技術(shù)在開發(fā)系統(tǒng)期間是可以變更的，管理部門也會(huì)決定對(duì)項(xiàng)目做出一些調(diào)整。 ?要是每個(gè)建議的需求都被采納，對(duì)于項(xiàng)目出資者（ sponsor）、參與者與客戶來說項(xiàng)目將永遠(yuǎn)也不會(huì)完成 — 事實(shí)上，這是不可能的。 控制項(xiàng)目范圍的擴(kuò)展 ?擴(kuò)展
公司管理相關(guān)推薦
鄂ICP備17016276號(hào)-1