requirements and user requirements

requirements and user requirements will originate through the same process in OSS.

Figure 1: Research Model for OSS Quality
In OSS communities, user of the software detects defects and reports them (user can be a maintainer, author or an end user). Individual projects have their own structure to remove defects. Addition of new code to remove the defect will increase the complexity of the software. The more complex the software is, the harder it will be to make additions to it in future. If the code is not well documented, maintainers will be reluctant to remove existing lines of code. Corrective maintenance will reduce the reliability and maintainability of the software. We expect a negative relationship between corrective maintenance and quality.
Adaptive maintenance can present a complex scenario in case of corporate use of OSS. If OSS is used in organizations which have existing PSS applications, adaptive maintenance will be required to accommodate interfaces to PSS. Perfective maintenance in OSS will be very similar to Adaptive maintenance; therefore we group the two together in our model. The effect of this category of maintenance will be domain dependent. If the operational environment of OSS is very dynamic then there will be a frequent need for such maintenance. If on the other hand the operational environment is stable and the users are not demanding frequent addition of new functionality, there will less need for such maintenance.
Preventative maintenance is proactive approach to maintenance. We believe that OSS projects sustain a high level of quality through significant preventative maintenance. We expect a positive effect of such maintenance on software quality.
5. DATAANALYSISANDRESULTS
We are examining the research model using empirical data from our analysis of the Linux source code, as it evolved through version 2.4.0 to 2.4.20, a total of 21 releases. The period of release was 2001 to 2003. We measure the size of individual modules in each release and then use an aggregate measure for the entire release. The total number of modules analyzed increase from 5571 in version 2.4.0 to 11340 in version 2.4.20. Software size is measured in Source Lines of code (SLOC). We measure the raw size from the tar ball of the kernel and the SLOC using Linux commands for each module and for the complete system. We also measure size in terms of number of C modules. All results are validated and verified against test files. Changes to a Linux version are provided in the form of a new patch. The user can

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

ความต้องการและความต้องการของผู้ใช้จะมาผ่านขบวนการใน OSSรูปที่ 1: รูปแบบวิจัยคุณภาพ OSSในชุมชน OSS ผู้ใช้ของซอฟต์แวร์ตรวจพบข้อบกพร่อง และรายงานดังกล่าว (ผู้ใช้สามารถดูแลคุณภาพการ ผู้เขียน หรือผู้ใช้) ได้ แต่ละโครงการมีโครงสร้างของตัวเองเพื่อลบข้อบกพร่อง นอกจากนี้รหัสใหม่เพื่อลบข้อบกพร่องจะเพิ่มความซับซ้อนของซอฟต์แวร์ เป็นซอฟต์แวร์ที่ซับซ้อน ยากที่จะทำการเพิ่มเติมได้ในอนาคต ถ้ารหัสเป็นไม่จัดดี maintainers จะไม่ลบบรรทัดที่มีอยู่ของรหัส แก้ไขบำรุงรักษาจะลดความน่าเชื่อถือและ maintainability ซอฟต์แวร์ เราคาดว่าความสัมพันธ์เชิงลบระหว่างการบำรุงรักษาแก้ไขและคุณภาพบำรุงรักษาที่เหมาะสมสามารถแสดงสถานการณ์ซับซ้อนในกรณีที่บริษัทใช้ OSS ถ้ามีใช้ OSS ในองค์กรที่มีอยู่โปรแกรม PSS จะต้องบำรุงรักษาที่เหมาะสมเพื่อรองรับอินเทอร์เฟซการ PSS บำรุงรักษา perfective ใน OSS จะคล้ายกันมากกับการบำรุงรักษาที่เหมาะสม ดังนั้น เราจัดกลุ่มทั้งสองเข้าด้วยกันในรูปแบบของเรา ผลของการบำรุงรักษาประเภทนี้จะขึ้นอยู่กับโดเมน ถ้าสภาพแวดล้อมในการดำเนินงานของ OSS เป็นแบบไดนามิกมาก แล้วจะต้องบ่อยสำหรับการบำรุงรักษาดังกล่าว ถ้าคง สภาพแวดล้อมการทำงานมีเสถียรภาพ และผู้ใช้จะต้องเพิ่มฟังก์ชันใหม่บ่อย มีน้อยจำเป็นสำหรับการบำรุงรักษาดังกล่าวบำรุงรักษาเชิงป้องกันเป็นวิธีการเชิงรุกเพื่อบำรุงรักษา เราเชื่อว่า โครงการ OSS รักษาระดับคุณภาพที่ผ่านการบำรุงรักษาเชิงป้องกันอย่างมีนัยสำคัญ เราคาดว่าผลบวกของการบำรุงรักษาเช่นคุณภาพซอฟต์แวร์5. DATAANALYSISANDRESULTSเราจะตรวจสอบแบบวิจัยที่ใช้ข้อมูลประจักษ์จากรหัสต้นฉบับของ Linux การวิเคราะห์ของเราขณะนี้พัฒนาถึงรุ่นมหาการ 2.4.0 2.4.20 รวมรุ่น 21 ระยะเวลาของรุ่น 2001-2003 ได้ เราวัดขนาดของแต่ละโมดูลในแต่ละรุ่น และใช้วัดการรวมสำหรับทั้งหมด จำนวนของโมดูลการวิเคราะห์เพิ่มขึ้นจากในเวอร์ชัน 2.4.0-11340 ในเวอร์ชัน 2.4.20 5571 วัดขนาดของซอฟต์แวร์ในบรรทัดแหล่งที่มาของรหัส (SLOC) เราวัดขนาดวัตถุดิบจากลูกทาร์ของเคอร์เนล SLOC ที่ใช้คำสั่ง Linux สำหรับแต่ละโมดูล และระบบที่สมบูรณ์ นอกจากนี้เรายังวัดขนาดในแง่ของจำนวนของโมดูล C ผลลัพธ์ทั้งหมดจะถูกตรวจสอบ และตรวจสอบกับแฟ้มทดสอบ เปลี่ยนเวอร์ชัน Linux การให้ในรูปแบบของแพทช์ใหม่ ผู้ใช้สามารถ

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

ความต้องการและความต้องการของผู้ใช้จะมาผ่านกระบวนการเดียวกันใน OSS. รูปที่ 1: การวิจัยแบบจำลองสำหรับโอเอสคุณภาพในชุมชนโอเอสผู้ใช้ซอฟแวร์ตรวจพบข้อบกพร่องและรายงานให้พวกเขา (ผู้ใช้สามารถดูแลผู้เขียนหรือผู้ใช้) แต่ละโครงการมีโครงสร้างของตัวเองเพื่อลบข้อบกพร่อง นอกเหนือจากรหัสใหม่ที่จะลบข้อบกพร่องจะเพิ่มความซับซ้อนของซอฟต์แวร์ ที่ซับซ้อนมากขึ้นซอฟต์แวร์เป็นที่ยากก็จะทำให้การเพิ่มเติมในอนาคต ถ้ารหัสไม่ได้เอกสารดีดูแลจะไม่เต็มใจที่จะลบบรรทัดที่มีอยู่ของรหัส การบำรุงรักษาที่ถูกต้องจะช่วยลดความน่าเชื่อถือและการบำรุงรักษาของซอฟแวร์ เราคาดว่ามีความสัมพันธ์เชิงลบระหว่างการบำรุงรักษาที่ถูกต้องและมีคุณภาพ. การซ่อมบำรุงการปรับตัวสามารถนำเสนอสถานการณ์ที่ซับซ้อนในกรณีของการใช้งานขององค์กรของโอเอส หาก OSS ที่ใช้ในองค์กรที่มีการใช้งานที่มีอยู่ PSS การบำรุงรักษาการปรับตัวจะต้องรองรับการเชื่อมต่อไปยัง PSS การบำรุงรักษาที่สมบูรณ์แบบในโอเอสจะคล้ายกันมากกับการซ่อมบำรุงการปรับตัว; ดังนั้นเรากลุ่มทั้งสองร่วมกันในรูปแบบของเรา ผลของประเภทของการบำรุงรักษานี้จะขึ้นอยู่กับโดเมน หากสภาพแวดล้อมการดำเนินงานของโอเอสเป็นแบบไดนามิกมากแล้วจะมีความจำเป็นสำหรับการบำรุงรักษาบ่อยเช่น ถ้าในทางกลับกันสภาพแวดล้อมในการดำเนินงานมีเสถียรภาพและผู้ใช้จะไม่ได้เรียกร้องนอกจากนี้บ่อยของการทำงานใหม่ที่มีน้อยจะต้องมีการบำรุงรักษาเช่น. การบำรุงรักษาเชิงป้องกันเป็นวิธีการเชิงรุกในการบำรุงรักษา เราเชื่อว่าโครงการ OSS รักษาระดับสูงของคุณภาพผ่านการบำรุงรักษาเชิงป้องกันอย่างมีนัยสำคัญ เราคาดว่าผลบวกของการบำรุงรักษาดังกล่าวในซอฟต์แวร์ที่มีคุณภาพ. 5 DATAANALYSISANDRESULTS เรากำลังตรวจสอบรูปแบบการวิจัยโดยใช้ข้อมูลเชิงประจักษ์จากการวิเคราะห์ของเราของรหัสที่มาลินุกซ์ขณะที่มันพัฒนาผ่านรุ่น 2.4.0 เพื่อ 2.4.20 รวม 21 รุ่น ระยะเวลาของการปล่อยเป็นปี 2001 ถึงปี 2003 เราวัดขนาดของแต่ละโมดูลในแต่ละรุ่นและจากนั้นใช้ตัวชี้วัดรวมสำหรับการเปิดตัวทั้งหมด จำนวนรวมของโมดูลวิเคราะห์เพิ่มขึ้นจาก 5,571 ในรุ่น 2.4.0 ไป 11,340 ในรุ่น 2.4.20 ขนาดซอฟแวร์เป็นวัดในสายที่มาของรหัส (SLOC) เราวัดขนาดดิบจากลูก tar ของเมล็ดและ SLOC ใช้คำสั่ง Linux สำหรับแต่ละโมดูลและระบบที่สมบูรณ์ นอกจากนี้เรายังวัดขนาดในแง่ของจำนวนของโมดูล C ผลทั้งหมดจะถูกตรวจสอบและตรวจสอบกับแฟ้มการทดสอบ การเปลี่ยนแปลงรุ่นลินุกซ์ที่มีให้ในรูปแบบของแพทช์ใหม่ ผู้ใช้สามารถ

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

They sing so much fun.They sing so much fun.They sing so much fun.They sing so much fun.They sing so much fun.They sing so much fun.They sing so much fun.They sing so much fun.