系分論文1

企業(yè)人事信息系統(tǒng)的應(yīng)用

【摘要】

    本文討論《企業(yè)人事信息系統(tǒng)》項(xiàng)目的需求分析方法與工具的選用。該系統(tǒng)的建設(shè)目標(biāo)是幫助該企業(yè)管理好企業(yè)內(nèi)部的人員和人員的活動(dòng)，人事信息管理指的是企業(yè)員工從招聘面試到離職退休的全過程，涉及的主要活動(dòng)包括面試、報(bào)到、培訓(xùn)、升職、離職或其他的人事變動(dòng)，也包括電子化考勤、工資性收入的計(jì)算與分發(fā)、使用其他公司資源的有關(guān)記錄（如宿舍、保險(xiǎn)、證件辦理等等）。此外，本系統(tǒng)也涉及到企業(yè)在全國各地的人事信息管理，企業(yè)的組織架構(gòu)的設(shè)置，級(jí)別與職務(wù)管理，人力申請(qǐng)直至人力需求報(bào)表，從而形成一個(gè)對(duì)企業(yè)真正有用的人事信息管理應(yīng)用系統(tǒng)。在本文中首先討論了選用面向?qū)ο蠓椒ㄅc工具的主要理由與策略，進(jìn)一步通過一個(gè)簡(jiǎn)例說明該方法與工具使用的效果，也討論了使用多種工具與方法在需求分析中的必要性，最后簡(jiǎn)要小結(jié)了選用正確工具與方法的意義和作用。

    在項(xiàng)目開展期間，我擔(dān)任了系統(tǒng)分析、系統(tǒng)設(shè)計(jì)與數(shù)據(jù)庫管理等大量工作。

【正文】

    人事信息管理系統(tǒng)是一個(gè)有著廣泛應(yīng)用面的實(shí)用性系統(tǒng)，但是，我國各個(gè)企業(yè)有著自身的體制、機(jī)制、特點(diǎn)與不同的要求；在開發(fā)這類系統(tǒng)時(shí)，系統(tǒng)需求分析是極為重要的一環(huán)。在整個(gè)分析過程中，我們都采用了面向?qū)ο蟮姆治龇椒ǎ�這是因?yàn)槲覀冊(cè)诮鼛啄甑膶?shí)踐中已堅(jiān)信這種方法能夠更加有效地表達(dá)和描述現(xiàn)實(shí)世界。軟件要具有適用性和擴(kuò)展性，就必須更接近于現(xiàn)實(shí)世界本身的發(fā)展規(guī)律。

    以一個(gè)簡(jiǎn)單的例子來看，假設(shè)要求設(shè)計(jì)關(guān)于引進(jìn)人才評(píng)估的一個(gè)系統(tǒng)，按我們過去的做法，先會(huì)要求提供給我們一份相關(guān)的引進(jìn)人才評(píng)估表，然后依葫蘆畫瓢地設(shè)計(jì)相應(yīng)的表單與界面。在短期來說，這樣做是簡(jiǎn)便而實(shí)用的，但并不能夠符合現(xiàn)實(shí)世界的長遠(yuǎn)目標(biāo)，這套設(shè)計(jì)方法不具有擴(kuò)展性，因?yàn)槿魏我环菰u(píng)估表的結(jié)構(gòu)都會(huì)有可能發(fā)生許多改變的。采用面向?qū)ο蟮姆椒�，可以從中提取出表類型、表結(jié)構(gòu)、評(píng)分方法以及能考慮繼承等各方面的要素，這樣就可以保證軟件的通用性，可配置性與可維護(hù)性。

    在工具的選擇過程中，我們選擇了現(xiàn)在已十分流行的Rational系列，包括Rational Rose、RUP、SoDA等，為什么選取這個(gè)系列工具呢？這是基于我們對(duì)軟件需求分析目標(biāo)的看法，我們認(rèn)為需求分析應(yīng)當(dāng)能正確地回答如下的幾個(gè)關(guān)鍵性問題：

   （1）用戶的需求是否已詳盡地被考慮到了？

   （2）用戶能理解或明白我們所描述的內(nèi)容嗎？

   （3）分析是否會(huì)和設(shè)計(jì)相脫節(jié)，

   （4）程序員能明白我們的分析與設(shè)計(jì)要求嗎？等等。

    以下對(duì)上述幾個(gè)問題逐一簡(jiǎn)要地加以說明：

   （1）詳盡地獲取用戶的需求。

    用戶的需求可分為顯式的需求與隱性的需求，用戶的傾向往往只顧及到當(dāng)前的與明顯的需求。要達(dá)到對(duì)需求理解的全面性，不僅僅只是依靠有效的用戶談話和調(diào)查，因?yàn)槲覀兯�面�?duì)的用戶需求往往會(huì)有些片面的，采用Rational Rose（基于UML）提供的用例，以及多種圖的聯(lián)合使用，可以使我們發(fā)現(xiàn)其中的遺漏。

   （2）使用戶能充分地理解我們的表示方法，能夠真正明白我們描述的內(nèi)容。

    軟件需求分析規(guī)格說明書通常會(huì)是冗長而枯燥的，一般的用戶不容易深入理解，這樣就削弱了分析的正確性。通過支持面向?qū)ο蠹癠ML語言的Rational Rose可以更好地和用戶交流，讓用戶了解系統(tǒng)的運(yùn)作方式甚至細(xì)節(jié)的操作。

   （3）使分析和設(shè)計(jì)兩個(gè)階段互相聯(lián)系與貫通。

    這是我們選擇面向?qū)ο蟮姆椒�及Rational Rose工具的重要原因，系統(tǒng)分析要向用戶描述的不僅僅是用戶的需求，而且包括解決方法，解決方法當(dāng)然應(yīng)包括設(shè)計(jì)（程序）、數(shù)據(jù)庫與系統(tǒng)配置，我們當(dāng)然不希望用戶得到的是一個(gè)與需求規(guī)格說明不相同的軟件，也不可能要求程序員完成一個(gè)不可勝任的任務(wù)。然而我們?cè)谝郧暗亩囗?xiàng)工作中經(jīng)常發(fā)現(xiàn)這類情節(jié)，因?yàn)橄到y(tǒng)分析與設(shè)計(jì)相互脫節(jié)，導(dǎo)致一頭扎在分析中不顧設(shè)計(jì)有關(guān)的事宜。

    分析與設(shè)計(jì)的脫節(jié)，還不利于設(shè)計(jì)現(xiàn)格說明的評(píng)估，因?yàn)榉治鐾�往�?huì)脫離現(xiàn)實(shí)，導(dǎo)致缺乏評(píng)估的依據(jù)。

    因?yàn)椴豢赡艹晒Φ赝瓿稍O(shè)計(jì)而使分析需要重來，就會(huì)造成巨大的浪費(fèi)與損失。一個(gè)好的工具可以使分析與設(shè)計(jì)更緊密地連結(jié)起來，甚至于—一對(duì)應(yīng)。面向?qū)ο蟮姆治龇椒ㄊ箤?duì)象之間相對(duì)而言有獨(dú)立性，減少了任何影響到全局的改動(dòng)，能避免因需求變化而導(dǎo)致全盤皆動(dòng)的被動(dòng)局面。

   （4）使程序員明白我們的設(shè)計(jì)。

    一個(gè)好的設(shè)計(jì)應(yīng)該讓程序員感到清晰明白，更少疑問。一個(gè)疑問很多的設(shè)計(jì)加上溝通不暢，絕對(duì)會(huì)出現(xiàn)在應(yīng)用環(huán)境下所不需要的另一個(gè)軟件，所以設(shè)計(jì)規(guī)格說明書務(wù)必清楚、形象與明確，當(dāng)然，Rational Rose具有足夠的圖形與其他形式，能使程序員更加明確，甚至能細(xì)微到每一個(gè)語句（事實(shí)上如果使用VB，程序架構(gòu)都有可能直接生成了）。

   （5）選擇UML可能會(huì)有更多的理由。

    比如用戶文檔的編寫、數(shù)據(jù)庫設(shè)計(jì)，我們都需要做到有延續(xù)性，有自動(dòng)化支持和具有質(zhì)量上的保證。

    所以，我們選用了以上的方法和工具。

    在分析中，面對(duì)考勤班次的問題時(shí)，由于過去一直使用紙卡方式考勤，使用戶對(duì)班次形成了固定的概念，而現(xiàn)在的許多考勤軟件也采用多次刷卡的方法來形成一天的記錄。經(jīng)過面向?qū)ο蟮姆治隹梢园l(fā)現(xiàn)，事實(shí)上每天的上班記錄是由多個(gè)時(shí)段所形成的，時(shí)段的多少在各個(gè)公司，各個(gè)工種與部門都不盡相同，每個(gè)時(shí)段可能有不同的屬性，時(shí)段與時(shí)段組合可形成為班次，這更適合于現(xiàn)實(shí)的情況，使之能更加靈活與更有擴(kuò)展性。其實(shí)，在天與天之間也都有相互之間的關(guān)系。在這一點(diǎn)上，我們又發(fā)現(xiàn)必須在考勤與薪金工資中加入與MRP中相似的期段（Periods）的基本概念，比如可以稱之為考勤期段，允許為用戶更加方便地設(shè)置考勤期段，可能使之不一定與自然年月日相同等等。

    Rational Rose使我們更方便地把上面的想法在類上去實(shí)現(xiàn)，更進(jìn)一步地設(shè)計(jì)好我們的高效率的數(shù)據(jù)庫。

    當(dāng)然，使用單一的一個(gè)工具去完成一個(gè)中大型的應(yīng)用系統(tǒng)的需求分析，是不可能成功的。因?yàn)樯鐣?huì)在發(fā)
展，用戶的需求也在改變，如何把握住用戶的需求是需要時(shí)間的，面向?qū)ο蟮姆椒ㄓ袝r(shí)也會(huì)忽略外在的與表層的要求，不僅僅是要獲得關(guān)鍵的需求，其他更多的需求往往要等到用戶在使用后才知道，然而等到用戶使用是不現(xiàn)實(shí)的，作為原型開發(fā)模型中的原型也是收集用戶需求，描述與解釋需求的一類相當(dāng)有效的方法與工具。

    在我們的開發(fā)過程中，為了更好地讓用戶了解我們的系統(tǒng)和我們的設(shè)計(jì)方案，讓用戶在見面會(huì)上更有方向性與針對(duì)性，我們首先用Access開發(fā)出原型，讓用戶先試用。這樣，我們?cè)谡嬲�的分析與設(shè)計(jì)時(shí)就能更加符合用戶的要求。

    總之，軟件需求分析方法和工具的使用，對(duì)我們軟件開發(fā)過程影響是很深遠(yuǎn)的，選用高效能的正確的方法與工具，可以使我們的軟件更加正確地反映現(xiàn)實(shí)需求，更加具有可用性、可擴(kuò)展性和可維護(hù)性；降低了軟件項(xiàng)目的風(fēng)險(xiǎn)。

評(píng)注：（1）寫得有些特色，觀點(diǎn)鮮明。（2）摘要寫得不錯(cuò)，既反映了項(xiàng)目內(nèi)容，也小結(jié)了本文的寫作要點(diǎn)。（3）文中所舉的例子雖然簡(jiǎn)單，但很實(shí)際。（4）多種方法與工具的使用，敘述得簡(jiǎn)明扼要。（5）內(nèi)容可更豐富一些，更深入的例子也可再增多一些，則會(huì)更有說服力。（6）對(duì)需求分析的全過程的描述太少。（本文主要參考了廣東延國慶等人的論文）

系分論文2

企業(yè)集團(tuán)的信息管理系統(tǒng)應(yīng)用

【摘要】
    本文以某個(gè)IT產(chǎn)品銷售公司的信息系統(tǒng)項(xiàng)目的開發(fā)為背景，討論了一個(gè)信息系統(tǒng)需求分析的整個(gè)過程，其重要特征是：所涉及的項(xiàng)目是原有系統(tǒng)的一個(gè)升級(jí)替換版本。因此，需求分析過程不同于建立一個(gè)全新的系統(tǒng)，大體上可分為三個(gè)階段：（）實(shí)施逆向工程獲得對(duì)系統(tǒng)的初步了解；（2）在第1步的基礎(chǔ)上寫出基本需求，交由客戶評(píng)審補(bǔ)充；（3）在第2步的基礎(chǔ)上開發(fā)原型，利用原型與客戶交流，最終獲得基線需求。針對(duì)上述三個(gè)階段，本文論述了所使用的分析方法與工具以及所遇到過的一些典型問題和措施，最后對(duì)需求分析中使用的工具，談一些自己的初步體會(huì)。

【正文】

    我于1998年8月至2000年7月參加了某個(gè)大型集團(tuán)的企業(yè)信息系統(tǒng)的開發(fā)工作，該大型集團(tuán)的業(yè)務(wù)主要涉及到IT類產(chǎn)品的進(jìn)銷存。本人在項(xiàng)目中負(fù)責(zé)系統(tǒng)分析的工作，該集團(tuán)企業(yè)原先已委托某個(gè)電腦公司開發(fā)過一套IT類產(chǎn)品管理系統(tǒng)，但是該老系統(tǒng)存在兩個(gè)主要的問題：（一）系統(tǒng)運(yùn)行速度非常慢，如商品銷售開單時(shí)，從確定開單到開單完成有時(shí)需要1～2分鐘左右的響應(yīng)時(shí)間，讓客戶無法忍受。（二）系統(tǒng)數(shù)據(jù)不準(zhǔn)確，經(jīng)常出現(xiàn)實(shí)物庫存與電腦庫存嚴(yán)重不相匹配的情況，使銷售數(shù)據(jù)的統(tǒng)計(jì)產(chǎn)生一些混亂，有關(guān)財(cái)務(wù)的數(shù)據(jù)因此無法有效使用，只能采用人工錄入方式補(bǔ)充進(jìn)行。在這種情況下，該集團(tuán)的總經(jīng)理決定參考原有系統(tǒng)重新開發(fā)一個(gè)系統(tǒng)，以便解決原系統(tǒng)所存在的上述兩個(gè)難以克服的難題。注；原系統(tǒng)采用PB6.5開發(fā)，數(shù)據(jù)庫采用SYBASE，服務(wù)器采用Windows2000Server，客戶端采用Windows 98，程序架構(gòu)采用的是傳統(tǒng)的C/S結(jié)構(gòu)。

    鑒于該集團(tuán)業(yè)務(wù)操作復(fù)雜，流程多，涉及人員多等特點(diǎn)，以及項(xiàng)目完成時(shí)間短，經(jīng)費(fèi)有限，人員有限等限制約束條件，再考慮到必須避免前一系統(tǒng)出現(xiàn)過的結(jié)構(gòu)混亂與難于維護(hù)等問題，我們決定要對(duì)原系統(tǒng)的需求做一個(gè)比較徹底的和切實(shí)可行的分析，由于原有系統(tǒng)已經(jīng)開發(fā)了近兩年，并且客戶也有了一定的使用經(jīng)驗(yàn)，業(yè)務(wù)基本流程本身也并沒有太大的變化，因此，我們把需求分析的過程分為三步：（）分析原有系統(tǒng)的結(jié)構(gòu)，主要是數(shù)據(jù)庫結(jié)構(gòu)和程序結(jié)構(gòu)，（2）在獲得第（1）步結(jié)果的基礎(chǔ)上寫出基本需求，交由客戶評(píng)審補(bǔ)充，（3）在第（2）步的基礎(chǔ)上開發(fā)原型，利用此原型與客戶交流，從而獲得最終可用的需求結(jié)果。下面按上述三步分別加以論述。

    第一步是實(shí)施逆向工程，獲取原有系統(tǒng)的基本需求。

    由于原有系統(tǒng)在功能上大體上能基本滿足客戶的需求，并且在兩年多的開發(fā)中也積累了不少經(jīng)驗(yàn)，因此，從中可以獲得一些有益的參考，也可以避免多走彎路。在這一階段，我們采用的主要工具是PB自帶的Power Designer和PB Documents；前者主要用來分析數(shù)據(jù)庫結(jié)構(gòu)，后者主要用來分析程序結(jié)構(gòu)，便于開發(fā)人員與高級(jí)用戶理解程序。采用這兩個(gè)工具的原因是：原系統(tǒng)過于龐大，模塊多，數(shù)據(jù)庫模式多，表格量很大，僅靠人工的方法很難從中獲得一個(gè)比較完整的、明確的系統(tǒng)結(jié)構(gòu)以及整體構(gòu)成，而且原有系統(tǒng)未能提供一套正確完整有效的設(shè)計(jì)文檔，于是我們只能依靠工具輔助來進(jìn)行。在使用Power Designer分析數(shù)據(jù)庫，并且用PB Documents分析原程序中的PBL以后，我們對(duì)原系統(tǒng)的結(jié)構(gòu)有了一個(gè)初步的了解，再結(jié)合對(duì)原系統(tǒng)的使用，基本明確了功能與流程的需求，并在此基礎(chǔ)上用人工錄入方式，產(chǎn)生了初步需求的自然語言文檔。這里指出，使用Power Designer的一個(gè)不足之處是：如果一個(gè)表中的字段過多，而且又同時(shí)依賴多個(gè)表時(shí)，輸出的表格相關(guān)圖形很復(fù)雜，有很多交叉，且難于調(diào)整，不方便閱讀及打印。

    第二步是在第一步的基礎(chǔ)上進(jìn)行的，即寫出系統(tǒng)基本需求，交由客戶評(píng)審和補(bǔ)充。

    通過第一步的逆向工程，我們獲得了系統(tǒng)的基本需求。為了充分記錄需求的變化及需求之間的依賴關(guān)系，我們決定選用Rational公司的Requisite PRO作為我們的需求管理工具，Rational公司有一整套用于需求管理的工具，功能非常強(qiáng)大，包括Requisite Pro、Clear Quest等等，這些需求分析工具可以對(duì)需求進(jìn)行全面的管理，包括記錄需求的變化情況，需求之間的依賴關(guān)系等等。但是，我們考慮到Rational的一套工具全面實(shí)施會(huì)非常昂貴與復(fù)雜，需要非常強(qiáng)的項(xiàng)目管理能力才能全面實(shí)施，因此，我們只采用了其中最簡(jiǎn)單的一部分功能，那就是記錄需求變更，記錄需求之間的依賴關(guān)系，其他跟RUP有關(guān)的功能都給略去了。之所以這樣做，主要是考慮到項(xiàng)目的經(jīng)費(fèi)、人力以及國內(nèi)軟件開發(fā)的實(shí)際情況。正如前面所說，我們根據(jù)自己的理解并寫出基本需求后，交由客戶做評(píng)審井做適當(dāng)補(bǔ)充，我們將經(jīng)過補(bǔ)充整理后的需求作為正式需求記錄入Requisite Pro所維護(hù)的數(shù)據(jù)庫中，并對(duì)各個(gè)需求進(jìn)行分類，設(shè)定優(yōu)先級(jí)等，這些工作完成后，就可以從數(shù)據(jù)庫中直觀地了解客戶到現(xiàn)在為止提出了哪些需求，哪些需求是必須優(yōu)先考慮的，哪些是難度較大的等等。在這個(gè)過程中，我們遇到了一些問題，譬如：用戶對(duì)我們用自然語言書寫的需求文檔有許多地方不理解，往往在花了較長時(shí)間閱讀之后，仍不明白我們所描寫的需求過程與他們所完成的業(yè)務(wù)之間的對(duì)應(yīng)關(guān)系；另外是由于首次采用Requisite Pro進(jìn)行需求管理，在類型劃分，屬性值的確定上，部分開發(fā)人員沒有經(jīng)驗(yàn)，造成了不少反復(fù)，對(duì)于前者，我們的方法是想辦法增加一些示意圖，將大的流程分解為小流程，再與客戶反復(fù)交流與溝通，最終達(dá)到雙方理解一致的目的。對(duì)第二個(gè)問題，則參考了一些例子，再結(jié)合實(shí)際中屬性的使用情況，給予取舍或者選擇，經(jīng)過這一階段的工作，我們建立了基本的需求庫，定出了基本需求規(guī)格說明。

    第三步則是在第二步的基礎(chǔ)上建立起原型，利用原型與客戶進(jìn)行更深入的交流，通過交流修改相應(yīng)的需求。

    在這一階段的工作是在對(duì)第二步任務(wù)進(jìn)行報(bào)告交流的基礎(chǔ)上進(jìn)行的。我們用PB開發(fā)了一個(gè)原型系統(tǒng)，就具體的業(yè)務(wù)流程與客戶進(jìn)行交流與溝通，通過原型，客戶發(fā)現(xiàn)了許多我們與他們的理解相互不協(xié)調(diào)的地方，我們?cè)谛薷男枨蟮耐瑫r(shí)，也在Requisite Pro需求數(shù)據(jù)庫中記錄下修改的歷史。事實(shí)證明，這種記錄歷史的作用是很有效的，如曾經(jīng)有客戶在兩個(gè)不同的時(shí)間對(duì)同一需求提了相反的需求，我們根據(jù)歷史記錄很快證實(shí)了該客戶的提法有錯(cuò)誤，在事實(shí)面前無需再作爭(zhēng)論，同時(shí)利用Requisite Pro，我們還發(fā)現(xiàn)了一些需求相互之間有矛盾。經(jīng)過這一階段工作，我們終于獲得了經(jīng)過用戶認(rèn)可的需求基線，即是可用于下一步進(jìn)行詳細(xì)設(shè)計(jì)的基線需求。

    在這個(gè)項(xiàng)目中，我們利用了Power Designer、PB Documents等逆向工程分析工具和Requisite Pro需求管理工具，這些工具的使用，使我們提高了工作效率，起到了一定的輔助作用。但是，就需求分析工具方面而言。我們覺得國內(nèi)應(yīng)用得還是太少了，這一方面是因?yàn)閷?duì)需求分析不夠重視，另一方面是因?yàn)楣芾硭�平還達(dá)不到相應(yīng)的層次。Rational公司的一整套需求分析工具，其功能是非常強(qiáng)大的，國外已在普遍地使用，在國內(nèi)也逐漸開始普及，特別是那些通過CMM二級(jí)以上評(píng)審的單位，都必須使用工具對(duì)需求進(jìn)行管理。在本項(xiàng)目中，我們僅僅利用了Requisite Pro功能的一些小方面，已經(jīng)體會(huì)到該工具對(duì)于項(xiàng)目管理的諸多好處。如果一個(gè)有實(shí)力的公司能夠全面實(shí)施RUP，那么需求管理這個(gè)老大難的問題會(huì)變得不再那么棘手了，項(xiàng)目的質(zhì)量也會(huì)得到相應(yīng)的提高。目前國內(nèi)由于CMM熱潮的興起，已經(jīng)逐漸重視需求分析，也逐漸使用需求分析工具，這是非常可喜的，當(dāng)然，更希望在不久的將來，能用上國產(chǎn)的需求分析工具，那時(shí)我們的軟件產(chǎn)業(yè)也許會(huì)真正地騰飛了。

評(píng)注；采用逆向工具進(jìn)行再工程的應(yīng)用很多，本文給出了一個(gè)實(shí)際的例子。寫作有條理，也很實(shí)際。合理地界定了需求分析的現(xiàn)實(shí)水平。所采用的需求分析的方法與工具相對(duì)較合理科學(xué)。能在對(duì)項(xiàng)目討論的同時(shí)抒發(fā)議論、使用體會(huì)、愛國心和事業(yè)心。深度還可以提高，例子宜更加豐富一些。（本文主要參考了廣東劉小波等人的論文）