สิ่งที่จะต้องกำหนดในแต่ละ Artifact ในการทำ Software Configuration Management

คือ
•    Configuration Item Identifier : กำหนด code หรือ ID ที่เป็น unique ให้แต่ละ item
•    Description : item นั้นมีไว้เพื่ออะไร
•    Change history : ทุกครั้งที่มีการแก้ไขจะต้องทีการเก็บ history ไว้ เช่น
      o    Owner : ใครเป็นเจ้าของ file (ในกรณีที่ถ้ามีการแก้ไข ต้อง notify คนนี้ หรือ ต้องแจ้งให้ owner แก้)
      o    Current version : ปัจจุบัน version อะไร o    Last modified : แก้ครั้งสุดท้ายเมื่อไหร่ o    Last modified By : แก้โดยใคร
      o    What’s modified : อะไรที่ถูกแก้ o    Comment : ทำไมถึงแก้ artifact นั้น ในกรณีที่เป็น change request (CR) ก็จะมีเพิ่มเติมอีก (รายละเอียดของ change request จะกล่าวถึงในหัวข้อถัดไป) เช่น
•    Synopsis : หัวข้อหรือ title ของ CR นั้น
•    Description : รายละเอียดต่างๆ
•    Status : สถานะของ CR นั้น
•    Enter / Submit By : ใครเป็นคนบันทึก CR
•    Severity : ความรุนแรงของ CR นั้น
•    Responsibility : ใครเป็นผู้ดูแล CR นั้น เช่น ถ้าเป็น bug ใครจะเป็นคนแก้ไข เป็นต้น Repository เมื่อต้องทำการรวบรวม Artifact ต่างๆ เข้าด้วยกัน สิ่งที่ต้องคำนึงถึงต่อไปคือ ที่เก็บ ซึ่งจะต้องเป็นที่เก็บส่วนกลางที่ทุกคนต้องสามารถ access ได้ตามสิทธิ์ที่แต่ละคนได้รับ สิ่งที่ต้องคำนึงถึงหลักๆ คือ
•    Location : กำหนดว่าจะจัดเก็บอย่างไร
•    Access Right : สิทธิ์ในการเข้าถึงที่แตกต่างกัน จะจัดการอย่างไร
•    Version control : ควบคุม version และเก็บ history อย่างไร
•    Add file, Check-in and Check-out : ใครจะเป็นคนเพิ่ม file ใหม่ๆ เข้าไปใน repository แล้วคนอื่นจะ check-in และ check-out file ได้อย่างไร
•    Merging : กรณีที่ต้องแก้ไข file เดียวกัน จะทำการ merge อย่างไร
• Backup and Restore : มีแผนการทำ backup อย่างไร และจะ restore อย่างไรเมื่อเกิดปัญหากับ repository Project Management ในระหว่างการพัฒนา requirement ต่างๆ ก็จะถูก implement ไปเป็น software ซึ่ง project manager ก็จะต้องคอยควบคุมความคืบหน้าต่างๆ ซึ่งโดยทั่วไปก็จะมีการกำหนด mile stone ของ project เช่น เมื่อ implement ทุก requirement แล้วก็จะถึง phase ของการ test ในระหว่างนี้เราจะกำหนดว่าเป็น Beta1 เมื่อ fix bug รอบและ ก็จะนำไป test ใหม่ เรียกว่า Beta 2 ไปเรื่อยๆ จน version ไหนที่ไม่มี bug ใหม่ๆ อีก ก็จะเรียกว่า version 1.0 การกำหนด version ของ program ก็จะต้องมีการระบุว่าใน version นั้นๆ ประกอบด้วย file อะไรบ้าง แต่ละ file เป็น version อะไร เพราะในระหว่างการ test (ตามกรณีนี้) เมื่อมีการแจ้ง bug จะต้องระบุว่า bug ที่เกิดอยู่ใน version ไหน เพราะ tester หลายๆ คนอาจจะ test ต่าง feature กัน จึงมีโอกาสที่จะ test คนละ version กันได้ ถ้าไม่มีการระบุ version ก็อาจจะไปเสียเวลา fix เอา bug ที่แก้ไปแล้วได้ เป็นต้น Change Management ในระหว่างการพัฒนา ซอฟท์แวร์ก็จะเกิดการเปลี่ยนแปลงไปเรื่อยๆ บางครั้งก็จะเป็น request ต่างๆ ไม่ว่าจะเป็น requirement หรือ feature ต่างๆ เราจะเรียก request เหล่านี้ว่า change request คืออะไรที่ request มาแล้วมีโอกาสทำให้เกิดการ change ใดๆ ขึ้นกับ source code หรือ document เราเรียก change request หมด เพียงแต่จะแยก type ว่าเป็นอะไร เช่น Request requirement change, New Requirement, Issue, Suggestion ซึ่ง bug ที่ user แจ้งมา ก็ถือเป็น type หนึ่งของ change request เหมือนกัน และ change request เหล่านี้จะต้องมีการ control โดยทั่วไปก็อาจจะเป็น tester หรือ helpdesk ของทีมที่จะช่วยรับ change request เหล่านี้ แต่ไม่ควรที่จะให้ developer หรือ programmer เป็นผู้รับ change request เอง เพราะ
•    programmer จะรู้ solutionที่จะ implement change request เหล่านั้น ก็จะรับปากไปโดยที่ไม่ได้คำนึงถึงผลที่จะกระทบจาก change request นั้น
•    เสียเวลา programmer เพราะงานพัฒนาเองก็มีงานมากพอสมควรอยู่แล้ว การพูดคุยกับ user เพื่อ submit change request ก็จะเสียเวลางานไป ควรแยกงานออกไปให้ role อื่นเข้ามาช่วยดูแล เมื่อถึงเวลา review จึงค่อยให้ programmer เข้ามาสรุปแนวทางแก้ไข การ implement change ก็จะต้องคำนึงถึงผลกระทบที่จะเกิดขึ้นด้วย เช่น ถ้าจะ implement requirement นั้น มันจะกระทบกับ design อะไรบ้าง code จุดไหนที่กระทบ จะต้องมีการ test แล้ว change request นั้นมี priority สูงถึงขนาดที่จะต้องแทรกงานที่กำลัง implement หรือไม่ ถ้าต้องแทรก จะกระทบกับ schedule และ cost อย่างไร และจะ deploy ที่ version ไหน สิ่งเหล่านี้คือเรื่องที่ต้องคำนึงถึง โดยทั่วไปก็จะมีอีก role หรือ team