敬請註冊 ... !    登入
關於本協會
登入
軟體品質資源專區
主選單
最新討論文章
討論區主頁
   軟體需求規格
     軟體開發文件的必要性與價值 ?
無發表權

樹狀顯示 | 舊的在前 前一個主題 | 下一個主題 | 頁尾
發表者 討論內容
tyrone
發表時間: 2009-11-14 22:16
網站管理員
註冊日: 2003-04-19
來自: CSQA
發表數: 342
Re: 軟體開發文件的必要性與價值 ?
寫文件不能找兼職的人員,而且需要受過相關的訓練,寫需求文件、設計文件、使用者手冊、維護技術手冊,各有不同的側重與技巧,因為這些文件的閱讀者都不相同,他們的技術背景也不同,所以就算要找兼職的人,找工讀生絕對是行不通的。

規定與要求要能夠落實,其實需要審查、稽核及教育訓練,甚至於獎懲制度的配合,才能進而形成習慣及文件,這個部分又需要管理者的管理技巧了。

文件在短期看不到被使用的需求,因為不會被詳實製作與及時維護,久而久之,當文件使用的需求發生時,卻又發現文件與產品不一致,這種情況,又需要建立嚴謹之組態管理才能進一步解決了,以定期的組態稽核確保文件與產品的持續一致,才能在最需要(需求變更、軟體功能提升等情況)的時候,提供最正確、完整、一致的相關資訊。


----------------
引文:

凡所有相皆是虛妄。見諸相非相。即見如來。

林泰龍
◎軟體品質協會 理事
◎經濟部標準檢驗局資訊及通信國家標準技術委員會(TC21/SC3資訊軟體分組委員會)委員
Youtube Channel: http://www.youtube.com/user/tyrone9304

flying
發表時間: 2009-11-13 12:46
Just popping in
註冊日: 2009-11-13
來自: 桃園楊梅
發表數: 1
Re: 軟體開發文件的必要性與價值 ?
我們是小公司,小到常態編制剩我一人,程式也都賣不到百萬等級,我也不是資訊管理出身,所以看不懂SRS、SDD、WBS、等專業名詞,但我深切知道reuse重用的重要性,因為平常都是在接專案,如果做過的東西沒有提升reuse的百分率,那每個專案可能就會變成每個坑,所以不同的系統,像會計,進銷存,公務薪資,貿易等不同體值的系統,仍然可以做到90以上的重用率,意思是不同系統有90%相同的程式庫,只有少數差異才需編寫個別的程式庫,所以完成不同類型新專案速度就會很快.而且主系統也很小.因為系統完成快,所以就有必較多的時間整理文件.

我們是將幾乎全部的商業邏輯都以存到資料庫的方法來處理系統,因為是資料庫而不是程式庫,所以可以編寫維護資料庫的方式來為維護系統邏輯.大部分客戶要擴充或修改商業邏輯的場合,只需打開文件,加以編修即可符合客戶所需.

文件除商業邏輯以外,個別專案的function,UI介面,database table,stored procedure等資料也可自動匯入,這些都必須進行管理,系統才會透明化.主要目的是方便後勤與交接,不然要回想過去做過的事,或看同伴走過的痕跡都會很辛苦.另外系統文件多了,未來也有機會變成業務用文件.

我們也建立後勤網,個人認定這也是文件之一,將客戶的原始需求post到論壇,分析與解決過程也記錄起來,就可以有系統的管理專案細節.同時等著有機會時交接給新人.

想招兼職文件人員,幾次登老半天都無人響應,而招募過的員工,不管全職或兼職,要求他們依論壇公告標準化程序行事,都還是有困難,包含UI排定規則,資料欄位命名規則等,都像青年守則一樣只被用來喊喊而已,我想原因可能是大部分員工都喜貪圖方便,並與不認同文件重要性有關,畢竟要體會出文件與自己的切身關係很難,加上平常無書寫文件習慣,要將思考的內容表達成文字都變成困難重重.這跟他們進來前滿口答應可以配合寫文件,登論壇,再驗證其表現,我想文件的本質與付出都超出他們所能預想空間與能力範圍之外了.程式可以一天產出一千列,但說明文字卻寫不出來,最後伏留下一千列的盲點.


所以我的文件幾乎都我自己在看,流程圖也自己在畫,說明也自己在打,不錯,在這邊看到有人認同文件重要性.雖然文件的內容與對象跟我做的可能不一樣.
我的文件網後勤網,歡迎大家有空時光臨.
albertchou
發表時間: 2009-10-27 11:56
Just can't stay away
註冊日: 2003-04-21
來自:
發表數: 71
Re: 軟體開發文件的必要性與價值 ?
軟體專案中可再利用的東西很多,不只是程式碼。它們有:SRS、SDD、WBS、產品結構與型態項目、測試個案、時程綱路圖、各種計畫,還有軟體度量與估計…。其實就是組織裡所有以往的工作結果,都可以再利用。其實組織訂定的過程、生命週期模型無一不是再利用過去的東西。甚至所謂的“專業分工”也都是“再利用”,它再利用“人”過去的經驗。

當然任何東西在“再利用”之前,首要條件是要把它做出來啦!。當我們在軟體專案中沒有可資再利用的東西,就問問我們自己:過去我們有真正地完成軟體工作嗎?過去我們真地把需求分析做完了嗎?軟體設計做完了嗎?專案管理計畫書完成了嗎?型態識別我們做完了嗎?測試文件與異常問題報告呢?…

可憐啦,什麼都沒有。有的盡是一些自欺欺人,唬人的垃圾。

以前不知也就罷了,現在知道了,還不回頭就…。不講了,真誠地

祝福大家 都有 金不換!

周茂松 敬上
RCI@Taiwan
發表時間: 2009-10-27 00:24
Not too shy to talk
註冊日: 2008-04-20
來自:
發表數: 24
Re: 軟體開發文件的必要性與價值 ?
1.開發案合約的roles只是12207(life cycle)中的一部份(籌獲方與供應方/發展方爾),全部(開發案所需交付之)"文件"加總起來(就算未經裁適全數照標準列,且考量轉移至使用方與後續維護方,亦應)不致於有八十幾種那麼多,....

2.講到reuse的諸多"好處"....書上是說得很好聽啦,....實務上並不盡然...除非當初就是為reuse而作,否則有時代價還不如重寫....

3.講到"文件"與"軟體工程"...誠如周兄所言是也!
joker
發表時間: 2009-10-22 10:05
Not too shy to talk
註冊日: 2006-12-22
來自:
發表數: 31
Re: 軟體開發文件的必要性與價值 ?
是否有CMMI-Level x公司能分享完成一份Software Requirements Specification所需投入之資源?
albertchou
發表時間: 2009-10-21 22:23
Just can't stay away
註冊日: 2003-04-21
來自:
發表數: 71
Re: 軟體開發文件的必要性與價值 ?
再提供兩個觀點,讓大家思考一下:

1. 一個成功的軟體開發組織,有許多過去的工作成果可資“再利用(reuse)’,而卻只有少數的現前工作須要“重工(rework)”。反觀失敗的軟體開發組織正好相反,過去已完成的工作只有很少很少的部份可以“再利用”,而現前的工作又有太多太多的部份須要“重工”才能被客戶接受。其原因何在?

2. 如果,我們把“文件”這玩意從軟體工程中抽離。那麼,請問軟體工程還剩下什麼?沒有了軟體工程,又如何保障軟體的品質?如果,從CMMI中抽離軟體工程的概念,CMMI又還剩下什麼?各組織努力花大錢企望通過CMMI的評鑑與提昇評鑑等級,卻又不重視文件,又代表什麼?

最後,還是祝福大家

心想事成!

周茂松 敬上
albertchou
發表時間: 2009-10-20 14:21
Just can't stay away
註冊日: 2003-04-21
來自:
發表數: 71
Re: 軟體開發文件的必要性與價值 ?
關於這個問題,我提供一些方向讓大家思考一下。

要回答這個問題“軟體開發文件的必要性與價值?”之前,先要為“文件”做個定義,否則就會發生“鷄同鴉講” 的(這是軟體開發專案中最容易發生的事,也是軟體工程要解決的基本問題之一)事了。個人以為軟體開發中的文件,代表的是一“書面的資訊”。有了這樣的理解,接著,我們要問的是:軟體開發專案中除了“編寫程式”之外,還有哪些工作?也就是“需求分析”、“軟體設計”、“型態管理”、“品質保證”、“測試”乃至“問題追蹤與管理”、“專案規劃、監控”、“需求管理”…這一拖拉古有的没的,是不是軟體開發中的“工作”?如果,它們不是工作,那就没有討論下去的必要了。如果,這些是必要 (RFP要求) 的工作,那麼這些工作的結果(產出)不是文件,那又是什麼?我們如何認定專案中已“正確地”執行了這些工作?還有為什麼要執行這些工作?也就是這些工作的結果,是做什麼用的?如果,它沒有作用,那為什麼要做這件事?如果,它有用。那又是給誰用的?什麼時候要用?用它有什麼好處?我們要如何檢查它已被“正確地”執行了?還有我們如何知道工作已經完成了?我們如何管理這些已完成的工作結果?…

以上這些問題,如果您想通了,“軟體開發文件的必要性與價值?”的答案也就呼之欲出了,那您可以自己再問自己一些更深入的問題(譬如:業主要如何規範這些工作的成果?我們如何再利用以往類似工作的成果?我們如何…)。如果,您想不通,那就多看看、多聽聽,也再多想想吧。

順祝 平安愉快!

周茂松 敬上
tyrone
發表時間: 2009-10-19 18:17
網站管理員
註冊日: 2003-04-19
來自: CSQA
發表數: 342
Re: 軟體開發文件的必要性與價值 ?
這樣的原因,我想是因為大家誤解、或者連標準的條文都沒有弄清楚的關係。小型的專案按照IEEE/EIA 12207是不需要寫到那麼多文件的。更何況,所稱遵IEEE/EIA 12207寫文件時,根據IEEE/EIA 12207.1所提列的文件,共有八十多項,有較為明確之的內容範圍者,亦有三十多項,絕非所提的二十多項。認為是二十多項文件,應該是受到MIL-STD 498影響的關係吧。
IEEE/EIA 12207也好、ISO/IEC 12207或者CMMI-DEV也罷,使用者對於tailoring學習,是一項重要的工作,沒有學會tailoring之前,隨意訂出文件要求,恐怕會是專案成功的一項傷害吧。


----------------
引文:

凡所有相皆是虛妄。見諸相非相。即見如來。

林泰龍
◎軟體品質協會 理事
◎經濟部標準檢驗局資訊及通信國家標準技術委員會(TC21/SC3資訊軟體分組委員會)委員
Youtube Channel: http://www.youtube.com/user/tyrone9304

RCI@Taiwan
發表時間: 2009-10-19 03:26
Not too shy to talk
註冊日: 2008-04-20
來自:
發表數: 24
Re: 軟體開發文件的必要性與價值 ?
如果小弟看到RFP中"要求得標廠商必須依照 IEEE/EIA 12207規範,交付約二十餘種技術文件"的案子,再大的利潤一定不會去投標....

因為只有幾千萬的案子並不大,"(幾乎或近)全套文件照交"對籌獲者及供應者或發展者言,其風險均是極高的

編撰這份RFP的軍方單位或承辦者,恐怕並不懂得自古以來各種軟體規範(如1679→1703/2167→498→12207)的精義所在
Member
發表時間: 2009-10-14 12:40
Not too shy to talk
註冊日: 2005-04-07
來自:
發表數: 29
Re: 軟體開發文件的必要性與價值 ?
今天中國時報 [時論廣場] 刊出貴會前理事長程家麒先生的文章,內文也有提到軟體技術文件的重要性 :

以專業立場來看,民國百年「電腦年序錯亂」只是個技術問題,對政府與企業而言,若能妥善處理,危機其實也可能是轉機。因為目前尚未因應民國百年「電腦年序錯亂」的資訊系統,多為早期設計的系統,當時的軟體工程觀念尚不成熟,多半沒有完整的軟體技術文件,如今要修改資訊系統就如同維修建築物管線卻沒有線路圖,恐怕很多資訊系統都必須重新開發;但是現在重新設計資訊系統時,已經有了軟體工程和技術文件的國家標準,可依循標準規範來施作,日後的維護修改也可以一勞永逸。

現在距離民國一百年元旦已剩下不到五百天,雖然時間緊迫,但筆者仍須提醒,無論修改舊系統或重新設計新系統,都需要透過周延的測試規畫設計來進行嚴謹的系統測試。尤其是事關民眾權益的自動化或資訊系統,妥善的風險管理和備援應變作業規畫更不可少。否則一旦發生意外狀況,輕者可能影響服務品質和聲譽形象,重者可能造成嚴重傷害或損失,絕不能掉以輕心。

以上謹供大家參考。


(1) 2 »
樹狀顯示 | 舊的在前 前一個主題 | 下一個主題 | 頁首

無發表權
 
-=協會通訊地址:330047 桃園市桃園區大林路100號6樓 =-
電話:(03) 367-8567 電子信箱:register@csqa-tw.org.tw=-
-=本網著作權為中華民國資訊軟體品質協會所有,禁止未經授權轉貼節錄=-
Powered by XOOPS , Twe76.net