基線和文件版本控制
2007-05-23 12:20:18 伊達
全程建模各個階段的結束標誌，有嗎？
2007-05-23 12:20:35 伊達
例如：需求階段如何才算結束了？分析階段如何才算結束了？
2007-05-23 12:21:21 青潤
因為是迭代化開發的建議，因此沒有明顯的結束標誌，主要還是看工件的完成情況，比如需求真的全部做完了，這個可能性不大．但是，需求模型完整了，我要求的東西都有了，就可以算是乙個階段點了，或者說是基線版本吧．
2007-05-23 12:23:31 伊達
因為以前很多開發過程，基本都是基於 瀑布形式的，所要求出的文件，也是 順序進行的。例如以往在 需求階段，完成了《需求說明書》和《demo》，並得到了使用者的評審，就算需求階段結束了。而採用迭代方式開發，感覺以前的 計畫安排、文件、結束標誌都有些混亂，得重新理順了才行
2007-05-23 12:24:37 青潤
呵呵，那是你用的還少，如果你能夠明確出每乙個迭代的產出和任務，那麼，你的迭代就不是混亂的了，而是十分清晰的樂．
2007-05-23 12:25:05 青潤
另外，記得要使用基線，這個很好的名稱，定義好每乙個基線，對於所有的開發人員都是一種鼓勵和激勵．
2007-05-23 12:25:33 伊達
基線是不是就是 一次迭代的結束產物？
2007-05-23 12:25:46 青潤
不是的
2007-05-23 12:26:04 伊達
基線 具體是什麼？
2007-05-23 12:26:07 青潤
這個我記得培訓的時候我說過，呵呵．
基線是針對一些已經穩定在各個階段的版本的一次彙總．
2007-05-23 12:26:39 青潤
甚至我們可以把基線當作乙個階段的任務完成來考慮，只是這個階段完成的時候，各個功能的版本處在不同的開發階段上而已．
2007-05-23 12:27:31 青潤
比如，我們可以要求功能ａ在第一次基線版本形成的時候處於**編寫完成的狀態，而功能ｂ處於測試完成狀態，而功能ｃ則處於需求調研完成狀態．等等
2007-05-23 12:27:54 青潤
乙個迭代裡面可以設定多個基線，但是，一般小專案乙個迭代一條基線就足夠了，不需要那麼複雜．
2007-05-23 12:28:01 伊達
基線是基於什麼來定的？
2007-05-23 12:28:08 伊達
根據 迭代 還是 根據用例？
2007-05-23 12:28:15 青潤
都不是．
2007-05-23 12:28:26 青潤
它是根據你的開發進行狀態的計畫來考慮得．
2007-05-23 12:28:47 青潤
或者說，回退到這個基線的時候，你可以保證你的所有版本都是穩定可靠的．
2007-05-23 12:29:48 伊達
那不相當於整個系統完成後的1.0版本的多個前身？
2007-05-23 12:29:57 青潤
可以這麼認為．
2007-05-23 12:30:37 伊達
相當於最終完成系統的 0.1版->0.2版->……->1.0版，類似於這樣的？
2007-05-23 12:30:52 青潤
對，這樣認為也是沒有問題的．呵呵
2007-05-23 12:30:59 青潤
關鍵看你的管理者如何定義了．
2007-05-23 12:31:57 青潤
在我的版本號碼管理上，０．ａ．ｂ
ａ就相當於基線
ｂ相當於修訂，而且不穩定的狀態
2007-05-23 12:32:26 伊達
定義 基線，使用者是否能認可？使用者那邊是否能看到該基線的具體的內容？
2007-05-23 12:32:36 青潤
每一次穩定的狀態，修改ａ，不穩定狀態下的每次修改都是ｂ，而常規見到的ｂｕｉｌｄ次數，應該是整體構建的次數。
2007-05-23 12:32:55 青潤
當然你可以讓他們看到，也可以讓他們看不到，具體的就看你如何管理了。
2007-05-23 12:33:36 青潤
我認為讓他們看到會更好一些。
就像我修訂的電信集團的那個規範，
他們僅僅是看到了我的修訂次數，就已經都認同了我的工作。
2007-05-23 12:33:54 青潤
這其實是一種心理分析的對抗戰術，而不是戰略策略。呵呵
2007-05-23 12:35:24 伊達
a b的修改，都放在『文件版本控制』裡面就行了？
2007-05-23 12:35:36 青潤
對 2007-05-23 12:36:30 青潤
你把這些都放進去，讓使用者看到，讓你的技術人員也能看到。同時將這些和配置管理工具裡面的修訂與提交內容配合，就可以統計工作量。
這都是對整個團隊和公司有好處的保留。
2007-05-23 12:38:46 伊達
文件版本控制是針對整個系統，還是針對某個文稿？
2007-05-23 12:39:32 青潤
版本管理對這兩個都有效。
文件的版本管理肯定是針對文稿的
2007-05-23 12:39:54 伊達
哦
全程建模 2023年全程建模培訓的總結
這次培訓比較匆忙，但是效果還不錯。第一天從早上9點50開始到下午7點結束。因為早上我睡過了，鬧鐘沒有響。所以，中午我就請所有的人吃了頓午飯，作為賠禮。今天開始了第一天的培訓，結果早上我8點55才起來。後來才知道，因為是週日，我的鬧鐘週六日不響。中午我請所有的人吃了頓飯，有乙個人沒過來吃，就是那個小孩...
全程建模 2023年的全程建模培訓順利完成通告
培訓持續四天，這裡向過來參加的朋友表示感謝。由於 沒有發過來，過兩天我會發布培訓中的一些 培訓中使用的案例是 幼兒教育系統 屬於專家系統定位基礎的一種教育資訊系統，這個案例是參加培訓的學員在現場提出的十幾個專案中最終確定的乙個。說實話，一直到第二天，明確需求後，我才明白這個系統的作用 可能和我沒有孩...
基線整改部分文件
cp p etc group etc group bak groupadd groupname usermod g root luoshen fdisk l 方法二 修改 vi etc sudoers 檔案，找到下面一行，在root下面新增一行，如下所示 root all all all luosh...