9.4. The Configuration Status Repor

9.4. The Configuration Status Report: CSR
The CSR form is first used to report configuration status after the SRS document has been
developed, inspected, and baselined. This is done in the requirements phase. The SRS will be the
first product to be baselined. Until it is, there is nothing to report on the CSR form.
Things to Check: CSR Form
The principal thing to check is that the team has baselined the SRS document and that the support
manager has recorded the number of text pages. Thereafter, check each week to make sure that all
appropriate new items were added when they were completed and inspected. This would be the
SDS at the end of the design phase and all the source code at the end of implementation. In
addition, make sure that all changes to baselined products are approved with a CCR, that the
proper INS forms are attached to the CCR, and that all changes are reported on the CSR.
Interpreting the Data: CSR Form
For the modest-sized TSPi projects, you will not generally be able to draw much useful
information from the CSR reports. With larger projects, the CSR data can indicate when the
requirements have settled down and when a product is stabilizing in integration or system test.
These data can also show code growth during implementation as well as the decline of change
activity as testing nears completion. These analyses, however, require trend data over an extended
period. With TSPi, there is not enough time to get trend data. You can look at the volume of test
defects and compare the results among teams or development cycles, but because the test phase
will takes one week or less, there will be not be weekly trend data.
Common Reporting Mistakes: CSR Form
The principal mistakes are that teams either do not baseline all their products or they do not
properly track their configuration and change activity and status.
General Comments: CSR Form
Again, for the small TSPi products, the software configuration management process need not be
overly formal. The students should recognize that the CCR process is a mechanism to ensure
proper consideration of every change. Teams need to learn to manage all their baseline changes,
not only to control the projects but also to maintain control of quality from the beginning of the
job.

ผลลัพธ์ (ไทย) 1:

9.4 การตั้งค่าคอนฟิกรายงานสถานะ: CSRแบบ CSR ครั้งแรกใช้ในการรายงานสถานะการกำหนดค่าหลังจากได้รับเอกสาร SRSพัฒนา ตรวจสอบ และ baselined นี้เสร็จในขั้นตอนข้อกำหนด SRS จะเป็นการผลิตภัณฑ์แรกที่จะ baselined จนกว่าจะมี ไม่มีอะไรต้องรายงานในรูปแบบ CSRสิ่งที่ต้องตรวจสอบ: แบบฟอร์มกิจกรรมเพื่อสังคมสิ่งหลักการตรวจสอบคือ ว่า ทีมงานมี baselined เอกสาร SRS และที่สนับสนุนจัดการได้บันทึกหมายเลขหน้าข้อความ หลังจากนั้น ตรวจสอบทุกสัปดาห์เพื่อให้แน่ใจว่าทั้งหมดเพิ่มรายการใหม่ที่เหมาะสมเมื่อพวกเขาเสร็จ และตรวจสอบ นี้จะเป็นการSDS เมื่อสิ้นสุดขั้นตอนการออกแบบและรหัสแหล่งที่มาทั้งหมดเมื่อสิ้นสุดการดำเนินงาน ในนอกจากนี้ การตรวจสอบให้แน่ใจว่า การเปลี่ยนแปลงผลิตภัณฑ์ baselined ทั้งหมดได้รับการอนุมัติกับ CCR ที่การเติมแบบฟอร์มแนบกับ CCR และเปลี่ยนแปลงทั้งหมดจะถูกรายงานใน CSRการตีความข้อมูล: แบบฟอร์มกิจกรรมเพื่อสังคมสำหรับรอง TSPi โครงการ คุณจะไม่โดยทั่วไปจะวาดมีประโยชน์มากข้อมูลจากรายงาน CSR มีโครงการขนาดใหญ่ ข้อมูล CSR สามารถระบุเมื่อการต้องตั้งหลักปัก และเมื่อผลิตภัณฑ์มีเสถียรภาพในการรวมหรือการทดสอบระบบข้อมูลเหล่านี้สามารถแสดงรหัสการเจริญเติบโตระหว่างการใช้งานตลอดจนการลดลงของการเปลี่ยนแปลงกิจกรรมเป็นการทดสอบที่ใกล้เสร็จสมบูรณ์ วิเคราะห์เหล่านี้ อย่างไรก็ตาม ต้องการข้อมูลแนวโน้มช่วงขยายรอบระยะเวลา กับ TSPi ไม่มีเวลาพอที่จะรับข้อมูลแนวโน้ม คุณสามารถดูการทดสอบความบกพร่อง และการเปรียบเทียบผลระหว่างทีมหรือรอบการพัฒนา แต่เนื่องจากระยะการทดสอบจะใช้เวลาหนึ่งสัปดาห์ หรือน้อยกว่า จะไม่เป็นรายสัปดาห์แนวโน้มข้อมูลรายงานลาภ: แบบฟอร์ม CSRความผิดพลาดหลักเป็นว่า ทีมทำไม่พื้นฐานผลิตภัณฑ์ของตน หรือไม่ถูกติดตามการกำหนดค่าของพวกเขา และเปลี่ยนแปลงกิจกรรมและสถานะทั่วไปความคิดเห็น: แบบฟอร์ม CSRอีกครั้ง สำหรับผลิตภัณฑ์ขนาดเล็ก TSPi กระบวนการจัดการการกำหนดค่าซอฟต์แวร์ไม่จำเป็นเป็นทางการมากเกินไป นักเรียนควรตระหนักว่า กระบวนการ CCR เป็นกลไกเพื่อให้มั่นใจคำนึงถึงการเปลี่ยนแปลง ทีมต้องเรียนรู้การจัดการแปลงทั้งหมดของพวกเขาหลักไม่เพียงแต่ เพื่อควบคุมโครงการ แต่ การควบคุมคุณภาพจากจุดเริ่มต้นของการงาน

ผลลัพธ์ (ไทย) 2:

9.4 สถานะการตั้งค่าคอนฟิกรายงานความรับผิดชอบต่อสังคม
ในรูปแบบ CSR ถูกนำมาใช้ครั้งแรกในการรายงานสถานะการกำหนดค่าหลังจากที่เอกสาร SRS ได้รับการ
พัฒนาตรวจสอบและ baselined ซึ่งจะดำเนินการในขั้นตอนความต้องการ ระบบเสียง SRS จะเป็น
ผลิตภัณฑ์แรกที่จะ baselined จนกว่าจะมีอะไรที่จะรายงานในรูปแบบ CSR.
สิ่งที่ต้องตรวจสอบ: CSR แบบ
สิ่งที่หลักในการตรวจสอบคือการที่ทีมงานได้ baselined เอกสาร SRS และสนับสนุน
ผู้จัดการมีการบันทึกจำนวนหน้าข้อความ หลังจากนั้นเป็นต้นมาตรวจสอบในแต่ละสัปดาห์เพื่อให้แน่ใจว่าทุก
รายการใหม่ที่เหมาะสมถูกเพิ่มเมื่อพวกเขามีความสมบูรณ์และการตรวจสอบ นี่จะเป็น
SDS ในตอนท้ายของขั้นตอนการออกแบบและทุกรหัสที่มาในตอนท้ายของการดำเนินการ ใน
นอกจากนี้ตรวจสอบให้แน่ใจว่าการเปลี่ยนแปลงทั้งหมดกับผลิตภัณฑ์ baselined ได้รับการอนุมัติด้วย CCR ว่า
รูปแบบการประท้วงที่เหมาะสมจะแนบไปกับ CCR และว่าการเปลี่ยนแปลงทั้งหมดจะมีการรายงานเกี่ยวกับความรับผิดชอบต่อสังคม.
ตีความข้อมูล: แบบ CSR
สำหรับเจียมเนื้อเจียมตัวขนาด TSPi โครงการคุณจะไม่ได้โดยทั่วไปสามารถวาดภาพที่มีประโยชน์มาก
ข้อมูลจากรายงานความรับผิดชอบต่อสังคม ด้วยโครงการขนาดใหญ่ข้อมูลที่สามารถบ่งบอกถึงความรับผิดชอบต่อสังคมเมื่อ
ต้องการได้ตัดสินลงและเมื่อสินค้ามีเสถียรภาพในการบูรณาการหรือระบบการทดสอบ.
ข้อมูลเหล่านี้ยังสามารถแสดงการเจริญเติบโตของรหัสในระหว่างการดำเนินเช่นเดียวกับการลดลงของการเปลี่ยนแปลง
กิจกรรมการทดสอบเกือบเสร็จสิ้น การวิเคราะห์เหล่านี้ แต่ต้องทำแนวโน้มข้อมูลมากกว่าการขยาย
ระยะเวลา ด้วย TSPi ไม่มีเวลาพอที่จะรับข้อมูลแนวโน้ม คุณสามารถดูปริมาณของการทดสอบ
ข้อบกพร่องและเปรียบเทียบผลระหว่างทีมหรือรอบการพัฒนา แต่เนื่องจากขั้นตอนการทดสอบ
จะต้องใช้เวลาหนึ่งสัปดาห์หรือน้อยกว่าจะมีไม่ได้เป็นข้อมูลที่แนวโน้มรายสัปดาห์.
ข้อผิดพลาดการรายงานสามัญ: CSR แบบ
ข้อผิดพลาดที่สำคัญคือ ที่ทีมงานอย่างใดอย่างหนึ่งไม่ได้พื้นฐานทุกผลิตภัณฑ์ของพวกเขาหรือพวกเขาไม่
ต้องติดตามการกำหนดค่าและการเปลี่ยนแปลงกิจกรรมและสถานะของพวกเขา.
ความคิดเห็นทั่วไป: แบบ CSR
อีกครั้งสำหรับผลิตภัณฑ์ TSPi ขนาดเล็กกระบวนการการจัดการการกำหนดค่าซอฟต์แวร์ไม่จำเป็นต้อง
เป็นทางการมากเกินไป นักเรียนควรตระหนักว่ากระบวนการ CCR เป็นกลไกเพื่อให้แน่ใจว่า
การพิจารณาที่เหมาะสมของการเปลี่ยนแปลงทุกครั้ง ทีมจำเป็นต้องเรียนรู้ในการจัดการการเปลี่ยนแปลงพื้นฐานของพวกเขาทั้งหมด
ไม่เพียง แต่จะควบคุมโครงการ แต่ยังรักษาการควบคุมคุณภาพจากจุดเริ่มต้นของ
งาน

ผลลัพธ์ (ไทย) 3:

9.4 . การปรับแต่งรายงานสถานะความรับผิดชอบแบบฟอร์มรายงานการใช้ CSR เป็นครั้งแรกหลังจากได้รับเอกสาร SRS สถานะพัฒนา ตรวจสอบ และ baselined . นี้จะกระทำในความต้องการของเฟส SRS จะเป็นผลิตภัณฑ์แรกที่ถูก baselined . จน ไม่มีอะไรจะรายงานในรูปแบบ CSR .สิ่งที่ต้องตรวจสอบรูปแบบความรับผิดชอบสิ่งสำคัญที่สุดที่จะตรวจสอบว่าทีมงานได้ baselined SRS และเอกสารที่สนับสนุนผู้จัดการมีการบันทึกหมายเลขของข้อความหน้า หลังจากนั้น ตรวจสอบในแต่ละสัปดาห์เพื่อให้แน่ใจว่าทั้งหมดรายการใหม่ที่เหมาะสมถูกเพิ่มเมื่อพวกเขาเสร็จสมบูรณ์และการตรวจสอบ นี้จะเป็นSDS ที่ส่วนท้ายของขั้นตอนการออกแบบและรหัสที่มาที่ส่วนท้ายของการใช้งาน ในนอกจากนี้ตรวจสอบให้แน่ใจว่าทุกการเปลี่ยนแปลงผลิตภัณฑ์ baselined ได้รับการอนุมัติกับ CCR , ว่าที่เหมาะสมในแบบฟอร์มที่แนบกับ CCR และการเปลี่ยนแปลงทั้งหมดจะรายงานเกี่ยวกับ CSR .การตีความข้อมูลรูปแบบความรับผิดชอบสำหรับเจียมเนื้อเจียมตัวขนาดโครงการ tspi , คุณจะไม่ได้โดยทั่วไปสามารถที่จะวาด มีประโยชน์มากข้อมูลจาก CSR รายงาน กับโครงการขนาดใหญ่ ข้อมูล CSR สามารถระบุเมื่อความต้องการได้ตัดสินลงและเมื่อผลิตภัณฑ์มีเสถียรภาพในการบูรณาการ หรือ ทดสอบระบบข้อมูลเหล่านี้ยังสามารถแสดงการเจริญเติบโตของรหัสในการใช้งาน ตลอดจนการลดลงของการเปลี่ยนแปลงเป็นการทดสอบเมื่อจบกิจกรรม การวิเคราะห์แนวโน้มเหล่านี้ แต่ต้องมีข้อมูลเพิ่มเติมระยะเวลา กับ tspi ไม่มีเวลาเพียงพอที่จะได้รับข้อมูลแนวโน้ม คุณสามารถดูที่ปริมาณของการทดสอบข้อบกพร่องและเปรียบเทียบผลระหว่างทีมหรือรอบการพัฒนา แต่เนื่องจากการทดสอบระยะที่จะใช้เวลาหนึ่งสัปดาห์หรือน้อยกว่านั้นจะไม่ได้ข้อมูลแนวโน้มรายสัปดาห์การรายงานข้อผิดพลาด : CSR ในรูปแบบทั่วไปความผิดพลาดหลักที่ทีมใดไม่พื้นฐาน ผลิตภัณฑ์ของตนหรือพวกเขาไม่ได้การติดตามการตั้งค่าอย่างถูกต้องและกิจกรรมการเปลี่ยนแปลงและสถานะความคิดเห็นที่ : CSR ในรูปแบบทั่วไปอีกครั้ง สำหรับผลิตภัณฑ์ tspi ขนาดเล็ก , การปรับแต่งซอฟต์แวร์การจัดการกระบวนการไม่ต้องสุดเหวี่ยงอย่างเป็นทางการ นักเรียนควรจำว่า กระบวนการ CCR เป็นกลไกเพื่อให้แน่ใจว่าการพิจารณาที่เหมาะสมของทุกการเปลี่ยนแปลง ทีมต้องเรียนรู้ที่จะจัดการการเปลี่ยนแปลงพื้นฐานทั้งหมดของพวกเขาไม่เพียง แต่เพื่อควบคุมโครงการ แต่ยังเพื่อรักษาคุณภาพของการควบคุมจากจุดเริ่มต้นของงาน