【正文】 量取決于原型的強健性。對于紙上原型測試，可用性工程師就是計算機，并且在測試的過程中與用戶在一起。 在許多種情況下，嚴(yán)謹(jǐn)?shù)目捎眯詼y試是過猶不及的。在建模階段，您仍可使用簡化的方法進行有效的可用性測試，這些方法通常稱為“打折扣的”可用性測試。 如 Jakob Nielsen 所述，反復(fù)的可用性測試包括： 1. 用戶和任務(wù)觀察 — 觀察用戶，保持安靜，讓用戶做一切通常情況下會做的操作。 2. 情況 — 使用一 種可以減少功能數(shù)量、降低功能級別的建模方法。 3. 簡化的對談式測試 — 一次安排一個用戶完成一組任務(wù)，并要求用戶“發(fā)現(xiàn)問題就直接告知測試人員”。 4. 啟發(fā)式評估 — 基于基本可用性原則來評價界面。 開發(fā)階段 開發(fā)階段是將產(chǎn)品用實際的代碼來實現(xiàn)的階段。在此階段中，您可以對實際產(chǎn)品的早期版次進行可用性測試。您仍有可能不時要用到原型，但隨著時間的推移產(chǎn)品將逐漸完善。不是所有的功能都將在開發(fā)階段同時完成，所以您有可能在原型和實際代碼之間往復(fù)轉(zhuǎn)換。 在理想條件下，您將可以把大部分時間用來進行推敲，在建模 階段就能夠找出主要問題。 真實代碼測試 讓用戶測試真實代碼版本可能會有助于針對在計算機上使用產(chǎn)品發(fā)現(xiàn)問題。這些問題更有可能是設(shè)計問題而非概念問題。它們通常涉及相當(dāng)?shù)图壍慕换プ饔脝栴}，如在屏幕上選擇項目、拖放，以及僅在實際產(chǎn)品中才有的動態(tài)圖形。對于產(chǎn)品的大多方面，真實代碼不一定比設(shè)計上的原型或其它模型的真實度更高，所以不要拖延到有真實代碼后再進行可用性測試。 可用性實驗室測試 在開發(fā)階段，您可進行可用性實驗室測試，該測試類似于規(guī)劃階段的反復(fù)可用性測試。但是，由于產(chǎn)品的更多部分已趨于完善，您可測試更多任務(wù)。 您仍可在 Director 中使用模型，或?qū)⑸宰鲂薷牡陌娲斡迷诳捎眯詼y試中。隨著時間的推移，產(chǎn)品會越來越完善，原型就越來越不象一個模型了。但是，用“已完成”產(chǎn)品進行測試的問題在于，由于已進行了如此之多的工作，剩下的時間如此之少，您就不能指望對發(fā)現(xiàn)的問題做太多的修改了。 注意： 作為此任務(wù)的一部分，您還可能進行焦點組分析或群集分析，以對產(chǎn)品進行可用性測試。 穩(wěn)定化階段 當(dāng)開發(fā)結(jié)束、錯誤已修正后，就進入了穩(wěn)定化階段。在此階段中，要創(chuàng)建一個可發(fā)售的穩(wěn)定的產(chǎn)品。在此階段對可用性進行測試的重點是進行微調(diào)。新的功能 以及代價高昂的可用性增強功能應(yīng)被記錄下來，以備下一版本使用。 基準(zhǔn)測試 對可用性進行基準(zhǔn)測試類似于“質(zhì)量保證”中的綜合測試?；鶞?zhǔn)測試的目的是通過測試用戶想要完成的所有頂級任務(wù)，就產(chǎn)品的可用性提供可靠的量化數(shù)據(jù)。這些測試的目標(biāo)與其說是要找出問題（雖然找出問題是大多數(shù)可用性測試的目的），不如說是要評估產(chǎn)品可用性的狀態(tài)。 要進行基準(zhǔn)測試，請首先觀察產(chǎn)品的功能，然后將這些功能按任務(wù)細(xì)分。在穩(wěn)定化階段，特別是對于復(fù)雜的產(chǎn)品，您將不能對用戶界面進行可提高每個任務(wù)性能的修改。理想情況下，您可以確定哪些是頂級任務(wù)，并且確 保大多數(shù)頂級任務(wù)都是可用的。低優(yōu)先級的任務(wù)的可用性可以較低，可記錄下來在將來的版本中再作改進。 為下一版本做準(zhǔn)備 將此階段視為開始對過程進行回顧的階段。您將全面考慮在構(gòu)思階段和規(guī)劃階段所進行的許多相同任務(wù)。例如，您將進行： ? 競爭性測試 — 在穩(wěn)定化階段，這種測試是對自己的產(chǎn)品進行測試，以將其與先前收集的有關(guān)競爭產(chǎn)品的數(shù)據(jù)作比較。 ? 現(xiàn)場研究 — 類似于環(huán)境研究（該研究是要了解“我們要做什么軟件？”），使用您已構(gòu)建的軟件來找出存在哪些問題，可在下一版本加以解決。 ? 關(guān)于事件的工具化版本研究 — 軟件的工具化版本基本上用來觀測軟件自身并在發(fā)生事件時記錄數(shù)據(jù)。您在大量會話和用戶的基礎(chǔ)上對產(chǎn)品進行測量以找到使用趨勢。 如何構(gòu)建軟件開發(fā)團隊取決于可供選擇的人員、項目的需求以及組織的需求。本文闡述了各種團隊組織的策略。 有效的軟件項目團隊由擔(dān)當(dāng)各種角色的人員所組成。每位成員扮演一個或多個角色；可能一個人專門負(fù)責(zé)項目管理，而另一些人則積極地參與系統(tǒng)的設(shè)計與實現(xiàn)。常見的一些項目角色包括： ? 分析師 ? 策劃師 ? 數(shù)據(jù)庫管理員 ? 設(shè)計師 ? 操作／支持工程師 ? 程序員 ? 項目 經(jīng)理 ? 項目贊助者 ? 質(zhì)量保證工程師 ? 需求分析師 ? 主題專家（用戶） ? 測試人員 您是如何組織項目團隊的？是采用垂直方案、水平方案還是混合方案？以垂直方案組織的團隊由多面手組成，每個成員都充當(dāng)多重角色。以水平方案組織的團隊由專家組成，每個成員充當(dāng)一到兩個角色。以混合方案組織的團隊既包括多面手，又包括專家。 一個重要的考慮因素是可供選擇的人員的性質(zhì)。如果大多數(shù)人員是多面手，則您往往需要采用垂直方案，同樣，如果大多數(shù)人員是專家，則采用水平方案。如果您正引入一些新人，即使這些人員都是合同工 ，則仍然需要優(yōu)先考慮您的項目和組織。本文描述了形成團隊組織的垂直、水平和混合方案，并指出了它們各自的優(yōu)缺點。本次討論的一個重要含意是您的團隊組織和用于管理項目的手段之間應(yīng)構(gòu)成默契；任何方法上的失諧都很可能導(dǎo)致項目產(chǎn)生問題。 垂直團隊組織 垂直團隊由多面手組成。用例 分配給了個人或小組，然后由他們從頭至尾地實現(xiàn)用例。 優(yōu)點 ? 以單個用例為基礎(chǔ)實現(xiàn)平滑的端到端開發(fā)。 ? 開發(fā)人員能夠掌握更廣泛的技能。 缺點 ? 多面手通常是一些要價很高并且很難找到的顧問。 ? 多面手通常不具備快速解決具體 問題所需的特定技術(shù)專長。 ? 主題專家可能不得不和若干開發(fā)人員小組一起工作，從而增加了他們的負(fù)擔(dān)。 ? 所有多面手水平各不相同。 成功因素 ? 每個成員都按照一套共同的標(biāo)準(zhǔn)與準(zhǔn)則工作。 ? 開發(fā)人員之間需要進行良好的溝通，以避免公共功能由不同的組來實現(xiàn)。 ? 公共和達成共識的體系結(jié)構(gòu)需要盡早在項目中確立。 水平團隊組織 水平團隊由專家組成。此類團隊同時處理多個用例，每個成員都從事用例中有關(guān)其自身的方面。 優(yōu)點 ? 能高質(zhì)量地完成項目各個方面（需求、設(shè)計等）的工作。 ? 一些外部小組， 如用戶或操作人員，只需要與了解他們確切要求的一小部分專家進行交互。 缺點 ? 專家們通常無法意識到其它專業(yè)的重要性，導(dǎo)致項目的各方面之間缺乏聯(lián)系。 ? “后端”人員所需的信息可能無法由“前端”人員來收集。 ? 由于專家們的優(yōu)先權(quán)、看法和需求互不相同，所以項目管理更為困難。 成功因素 ? 團隊成員之間需要有良好的溝通，這樣他們才能彼此了解各自的職責(zé)。 ? 需要制定專家們必須遵循的工作流程和質(zhì)量標(biāo)準(zhǔn)，從而提高移交給其他專家的效率。 混合團隊組織 混合團隊由專家和多面手共同組成。多面手繼 續(xù)操作一個用例的整個開發(fā)過程，支持并處理多個使用例中各部分的專家們一起工作。 優(yōu)點 ? 擁有前兩種方案的優(yōu)點。 ? 外部小組只需要與一小部分專家進行交互。 ? 專家們可集中精力從事他們所擅長的工作。 ? 各個用例的實現(xiàn)都保持一致。 缺點 ? 擁有前兩種方案的缺點。 ? 多面手仍然很難找到。 ? 專家們?nèi)匀徊荒苷J(rèn)識到其他專家的工作并且無法很好地協(xié)作，盡管這應(yīng)該由多面手來調(diào)節(jié)。 ? 項目管理仍然很困難。 成功因素 ? 項目團隊成員需要良好的溝通。 ? 需要確定公共體系結(jié)構(gòu)。 ? 必須 適當(dāng)?shù)囟x公共流程、標(biāo)準(zhǔn)和準(zhǔn)則。 項目團隊士氣是項目成功的一個因素 大部分項目成功的定義說的是項目如何按時完成、是否在預(yù)算內(nèi)以及是否滿足用戶的需要。但是，在如今要找到好的軟件專業(yè)人員都非常困難，更不用說留住他們的這種情況下，還需要將項目成功的定義擴展為包括項目團隊的士氣?？赡茉谂ν瓿梢粋€軟件項目后，不料卻因為壓榨他們過度而失去了重要的開發(fā)人員，這樣做可能會符合組織的短期需要，但它對構(gòu)建一個高效的軟件部門的長遠利益來說肯定是有害的。衡量項目成功與否的一個重要手段是項目結(jié)束后團隊的士氣。在項目結(jié)束之際 ，項目團隊的各個成員是否覺得他們從自己的經(jīng)歷中學(xué)到了一些知識、是否喜歡為這次項目工作，以及是否希望參與組織的下一個項目都是非常重要的。 編者按： CMM 認(rèn)證是當(dāng)今 IT 界最熱的話題之一，這表明中國軟件企業(yè)已開始重視與軟件項目管理有關(guān)的問題了。為了了解國內(nèi)軟件企業(yè)對軟件項目管理的認(rèn)識程度以及他們在軟件項目管理方面的具體做法，日前，記者采訪了開思、東方通、瑞星三家純軟件公司的相關(guān)負(fù)責(zé)人。三家公司中，東方通業(yè)已開始按照 CMM 規(guī)范進行軟件開發(fā)。在采訪中，三家公司的負(fù)責(zé)人分別介紹了各自企業(yè)在軟件項目管理方面的經(jīng) 驗。開思公司的產(chǎn)品總監(jiān)石宏峰先生還為記者詳細(xì)講解了開思公司的《產(chǎn)品部開發(fā)規(guī)范》。 經(jīng)過整理，我們將東方通和瑞星兩家公司的負(fù)責(zé)人在采訪中所說的主要內(nèi)容刊登于此。我們相信，其具有一定的認(rèn)識價值。另外，我們將開思公司《產(chǎn)品部開發(fā)規(guī)范》的一部分也刊登于此 —— 我們并不認(rèn)為開思的規(guī)范就是最好的規(guī)范。對軟件項目管理而言，普適性是不存在的，好壞是相對的，適用不適用才是絕對的 —— 我們相信，其具有一定的參照價值。 加強相關(guān)教育和培訓(xùn) 朱律瑋（東方通科技首席軟件設(shè)計師） 楊樺（東方通科技總經(jīng)理助理） 東方通科技從去年底開始為參加 CMM 認(rèn)證（二級）做準(zhǔn)備。擬議中正式參評的時間是今年11 月。在這之前我們會請國內(nèi)咨詢公司的有關(guān)專家和國外的評估師進行兩次預(yù)評估。 半年多來，我們覺得一切還算順利。起初我們擔(dān)心編程人員會有抵觸情緒 —— 因為每完成一天的工作或一道工序或一個項目后都要做記錄、編文檔、寫報告，較之以前，工作量無疑是增加了 —— 后來看看，大家對執(zhí)行 CMM 規(guī)范還是理解的、支持的。 按照 CMM規(guī)范開展工作后，到目前為止，公司的運營成本是增加了 —— 因為要增加管理人員、撰寫文檔也需要人手 —— 但從長遠看，其會帶來 降低成本、提高質(zhì)量、提高用戶滿意度等好處。對此，我們確信不疑。 與國外相比，我們在軟件工程管理方面的差距不僅表現(xiàn)為管理體制、管理方法、管理思想的陳舊，整個軟件業(yè)的落后才是根源。 個人英雄主義情結(jié)、喜歡單打獨斗是我們的民族性之一，其在軟件人才身上表現(xiàn)得尤為明顯，已成為中國軟件企業(yè)做大的一個瓶頸。造成這種狀況的原因，除了國內(nèi)軟件業(yè)的發(fā)展水平不高、軟件項目規(guī)模不大和軟件企業(yè)管理者自身素質(zhì)不高外，還有很重要的一點，即與軟件工程管理有關(guān)的教育內(nèi)容幾乎沒有。在國外， PSP 和 GSP 均為軟件專業(yè)學(xué)生的必修課，可在國 內(nèi)，這兩門課在學(xué)校里至今還沒有開起來。國外施行的是定崗培訓(xùn)，比如撰寫文檔就是一門專業(yè)課，專門有人修它，畢業(yè)后拿它來“安身立命”，國內(nèi)則是大家過獨木橋，統(tǒng)統(tǒng)都學(xué)寫程序。應(yīng)該說，目前國內(nèi)同行對軟件工程管理的重要性已有了一定的認(rèn)識，但在相關(guān)人員的培訓(xùn)上下的力氣仍遠遠不夠。 其實人才才是最關(guān)鍵的?，F(xiàn)在軟件業(yè)最缺的人才之一就是產(chǎn)品經(jīng)理，他們是軟件工程管理的主角。產(chǎn)品經(jīng)理必須具備以下素質(zhì)：具有長期的軟件開發(fā)經(jīng)驗 —— 般來講，要在 8年以上；了解用戶的需求；對產(chǎn)品熟、對市場熟 —— 他可以不了解一個產(chǎn)品的底層技術(shù)，但必須了解其功能，能把握其發(fā)展方向；具有協(xié)調(diào)能力?？傊a(chǎn)品經(jīng)理并不一定非常聰明，并不需要在某一方面特別突出，但要八面玲瓏。這樣的人才太難找了。東方通的產(chǎn)品經(jīng)理都是自己培養(yǎng)的。 CMM 規(guī)范并非只適用于大型軟件企業(yè)，其也適用于中小型企業(yè)。 CMM 規(guī)范只是一個框架、綱要性質(zhì)的東西。企業(yè)在落實它時要細(xì)化一次；企業(yè)將其落實到具體的某個項目時，要再細(xì)化一次；中小企業(yè)可以不像大型企業(yè)那樣將 CMM規(guī)范細(xì)化得那么細(xì)，夠用就好，不要教條。 實施 CMM規(guī)范、通過 CMM認(rèn)證有如下一些好處：確定工作流程和方式，從而使產(chǎn)品的質(zhì)量和開發(fā)的 可延續(xù)性有了保證；可以提高企業(yè)在用戶中的信譽度，增加企業(yè)與強勢公司競爭的籌碼；可以承接國際大公司的外包項目 ——— 美國公司愿意找印度公司來承接其外包項目，就是因為印度公司對 CMM規(guī)范普遍比較重視，通過 CMM認(rèn)證的軟件企業(yè)也多；公司不再受制于人，人走了，事照做，這是一個公司成熟的表現(xiàn)。 軟件商業(yè)化的必要手段 談文明（北京瑞星科技股份有限公司研發(fā)部經(jīng)理） 中國軟件產(chǎn)業(yè)發(fā)展時間不長，雖然已有部分技術(shù)達到國際水平，但由于商業(yè)環(huán)境還不夠完善，在軟件技術(shù)的商業(yè)化與軟件工程管理等方面，與國際同行相比，還存在差距 。 只有率先將技術(shù)先進的產(chǎn)品推向市場的公司才會贏得利潤。在瑞星，技術(shù)商品化已被當(dāng)作一種制度，它有助于提高整個企業(yè)的素質(zhì)。 瑞星意識到在充滿競爭的環(huán)境中要獲得成功，天才人物是必不可少的，但他們并不是全部。目前，一個軟件工程的成功更多地要依靠科學(xué)家、工程師、制造人員和銷售人員的協(xié)同努力。 在軟件商業(yè)化的過程之中，建立規(guī)范化的易于操作的軟件開發(fā)行為規(guī)范是首先要做的工作。針對殺毒軟件的特點，瑞星專門設(shè)計了瀑布模型結(jié)合增量模型的開發(fā)方式，即將項目分階段來實現(xiàn)。首先實現(xiàn)市場最需求的核心功能，然后在此基礎(chǔ)上繼 續(xù)開發(fā)，每個單獨的階段都采用瀑布模型的開發(fā)方式。