پورتال مقالات مدیریت

گزارش اول
شناخت استانداردهاي ساخت و مستند‌‌سازي محصولات نرم‌‌افزاري

بخش سوم معرفي استاندارد MIL-STD-498

1- مقدمه
MIL-STD-498 به عنوان يك استاندارد ساخت و مستندسازي نرم‌‌افزار (Software Development and Documentation ) در 8 نوامبر 1994 توسط سازمان صنايع دفاع آمريكا (DOD) ارائه گرديد.
اين استاندارد با 4 هدف اصلي توليد گرديد كه عبارتند از :
• الحاق استاندارد DOD-STD-2167 A كه براي ساخت نرم‌‌افزارهاي توكار (Embeded ) در سيستم‌‌هاي دفاعي استفاده مي‌‌شد با DOD-STD-7935 كه براي اتوماسيون سيستم‌‌هاي اطلاعاتي بكار مي‌‌رفت. الحاق دو استاندارد مي‌‌توانست يك استاندارد واحد را براي توليد سيستم‌‌هاي نرم‌‌افزاري ارائه دهد.
• تأكيد بر نقاط قوت در استفاده از اين استانداردها
• افزايش سازگاري با ديگر استانداردهاي DOD
• تهيه يك مبنا براي پياده‌‌سازي استاندارد ISO/IEC 12207
مجموعه DOD-STD-498 شامل يك استاندارد و بيست و دو مورد(دDID (Data Item Descriptionمي‌‌باشد كه هر DID يك جزء از پروسه ساخت را توصيف نموده و اقلام اطلاعاتي لازم آن جزء را ارائه مي‌‌نمايد.

2- ويژگي‌‌هاي استاندارد MIL-STD-498
استاندارد 498 ويژگيهاي متعددي دارد كه در زير به صورت خلاصه ارائه مي‌‌گردد :
پشتيباني از مدل‌‌هاي پياده‌‌سازي افزايشي (Incremental ) ، تكاملي (Evolutionary ) ، و آبشاري
استانداردهاي قديمي‌‌تر DOD مانند DODI 2000. 2 و DODI 8120.2 ، استراتژي‌‌هاي چند برنامگي را براي توليد يك سيستم نرم‌‌افزاري پشتيباني مي‌‌كنند. يكي از اهداف كليدي استاندارد نيز پشتيباني از مدلهاي مختلف مهندسي نرم‌‌افزار مي‌‌باشد. براي رسيدن به اين هدف، اين استاندارد، توسعه نرم‌‌افزار را به صورت Multiple Build پشتيباني مي‌‌كند. هر build يك بخشي از نرم‌‌افزار مي‌‌باشد كه يك زير مجموعه‌‌اي از نيازها را بصورت كامل پوشش مي‌‌دهد. اين خصيصه باعث مي‌‌گردد اين استاندارد در توسعه نرم‌‌افزار محدوديت انتخاب مدل را رفع نموده و انواع مدلهاي آبشاري، افزايشي و تكاملي را پشتيباني نمايد. جدول شماره 1 نمونه‌‌اي از اينكه چطور هر فعاليت استاندارد 498 مي‌‌تواند در يك يا تعداد بيشتري Build بكار گرفته شود را نشان مي‌‌دهد.

جدول شماره 1- نگاشت فعاليتهاي MIL-STD-498 به چندين build

تجديدنظر در روشهاي بازرسي ( Audit ) رسمي
يكي از بزرگترين آشفتگي‌‌ها در پروژه‌‌هاي توسعه نرم‌‌افزار، آماده‌‌سازي براي بازرسي رسمي مي‌‌باشد. يك معضل در اين حالت اين است كه هر شخص كار واقعي خود را شش هفته قبل از بازرسي و مرور رسمي متوقف مي‌‌كند و شروع به توليد گرافهاي بازرسي مي‌‌نمايد. به جاي روشهاي رسمي، استاندارد 498 به صورت تدريجي و تكراري كار بازرسي را انجام مي‌‌دهد و به‌‌جاي تهيه گرافهاي خاص و آماده‌‌سازي منابع خاص، بر روي كار واقعي متمركز مي‌‌شود. اين بازرسي‌‌ها (review) به صورت غيررسمي (informal) بر روي وضعيت، ايده‌‌ها، روشها و ريسكها تكيه مي‌‌كند.

كاهش تأكيد روي مستندسازي دستي و افزايش سازگاري با ابزارهاي CASE
يك كار متداوم در ساخت نرم‌‌افزار تحت استاندارد نظامي اين است كه تمامي فعاليتها بر مبناي مستندات باشد. به جاي تأكيد و تمركز روي كار واقعي، مجري بايستي يك سري بي‌‌پاياني از مستندات را توليد كند.
استاندارد 498 اين مشكل را با راههاي مختلفي حل نموده است. اول اينكه فعاليتهايي كه توسط مجري انجام مي‌‌گيرد به‌‌صورت Define & Record مي‌‌باشد نه به‌‌صورت آماده‌‌سازي يك سري مستندات داده شده. بيان ديگر فوق آن است كه مجري بايستي قادر باشد اطلاعات مورد نياز يك قسمت تعريف شده را به صورت دقيق ارائه نمايد حال چه اين اطلاعات به صورت اسناد كاغذي باشد، چه به صورت اطلاعات ذخيره شده در ابزار CASE، و چه راههاي ديگر. دوم اينكه اين استاندارد، فعاليتهايي را كه مربوط به كارهاي مهندسي و طرح (كه كار واقعي را تشكيل مي‌‌دهد) است از فعاليتهاي آماده‌‌سازي اطلاعات قابل تحويل، متمايز مي‌‌كند. اين عمل باعث مي‌‌شود هر وقت نياز به ارائه اطلاعات باشد با انجام فعاليتهاي ديگر، قابليت ايجاد گزارشات قابل تحويل از منابع موجود مهيا باشد. سوم اينكه بيشتر فعاليتها در استاندارد 498 در DID ها به‌‌صورت كامل تعريف شده است. در هر كدام از اين DID ها با برخورد به فعلهايي مثل "Record " مشخص مي‌‌شود اقلام داده‌‌اي فوق، بايستي به طريقي ثبت شوند كه اين ثبت مي‌‌تواند روي فايل كامپيوتري، ابزار CASE و يا بر روي اسناد كاغذي باشد.

بهبود اتصالات با مهندسي سيستم
يك ديدگاه كليدي براي تلفيق DOD-STD-2167 با DOD-STD-7935 اين بود كه هر يك از اين استانداردها فقط يكي از دو نوع سيستم را پوشش مي‌‌داد :
سيستم‌‌هاي نرم‌‌افزاري - سخت‌‌افزاري (همانند سيستم‌‌هاي رادار) كه استاندارد فقط قسمت نرم‌‌افزار را پوشش مي‌‌داد و سيستم‌‌هاي نرم‌‌افزاري خالص (همانند سيستم پرداخت) كه استاندارد، كل پروسه توليد نرم‌‌افزار را پوشش مي‌‌داد.

استاندارد 498 با افزودن فعاليتهاي در سطح سيستم، توليد هر دو نوع نرم‌‌افزار را پشتيباني مي‌‌كند. در اين استاندارد، سازنده نرم‌‌افزار بايستي به نوع سيستم دقت كند و بطور كلي نحوة عمل سازنده نرم‌‌افزار در كليه مراحل توليد توسط استاندارد مشخص شده است و وظايف سازنده نرم‌‌افزار در برخورد با اين دو نوع وضعيت در استاندارد 498 معين شده است.

استفاده از شاخصهاي مديريت و ارزيابي نرم‌‌افزار
در اين استاندارد براي دستيابي به يك ديد در مورد پيشرفت نرم‌‌افزار، اندازه، كيفيت و ديگر خصيصه‌‌هاي نرم‌‌افزار، تأكيد بيشتري روي اندازه‌‌گيري مقداري شده است كه نشان‌‌دهنده پيشرفت واقعي و بهبود پروسه‌‌هاي ساخت نرم‌‌افزار مي‌‌باشد. در استاندارد 498 براي اينكه توسعه‌‌دهنده، ملزم به تعريف و بكارگيري شاخصهاي مديريت نرم‌‌افزار ويا تهيه يك مجموعه از شاخصهاي كانديد باشد اقداماتي پيش‌‌بيني شده است.در طرح توليد نرم‌‌افزار (SDP-DID ا)(Software Development Plan DID) كه بخشي از استاندارد 498 است و نوع داده‌‌هايي كه بايستي جمع‌‌آوري شود، روش تفسير داده‌‌ها و همچنين روشهاي گزارش‌‌گيري از داده‌‌ها ارائه شده است.

بهبود پوشش تغييرات، استفاده مجدد و مهندسي مجدد (Reengineering )
يكي از اهداف اين استاندارد پوشش دادن نيازهاي مجري از نظر استفاده مجدد از توليدات نرم‌‌افزار موجود مي‌‌باشد. در واقع به‌‌جاي آنكه هر چيزي از ابتدا توسعه يابد وقتي امكان استفاده از بخشهاي توليد شده وجود دارد در اينصورت با استفاده مجدد از آن بخشها، هزينه و زمان توليد نرم‌‌افزار كاهش خواهد يافت.

استاندارد 498 اين قابليتها را پشتيباني مي‌‌نمايد. هر فعاليتي در اين استاندارد مي‌‌تواند به شكل تغيير يا استفاده مجدد و يا مهندسي مجدد از ساير فعاليتها انجام گيرد بطوري كه كيفيت آن با توليد جديد اين فعاليتها برابري‌كند. استاندارد، مجري را ملزم مي‌‌نمايد كه محصولات نرم‌‌افزاري را كه قابليت استفاده مجدد دارند شناسايي و ارزيابي نمايد. معيارهاي ارزيابي آنها نيز بدين‌‌صورت است كه بايستي نيازهاي تعيين شده در قرارداد بصورت كامل پوشش داده شود.

سازگاري با شي‌‌گرايي و ديگر روش‌‌ها
در استاندارد DOD-STD-2167A ، اگرچه صريحاً اشاره نشده است ولي نرم‌‌افزار در حال ساخت، قابليت عملياتي از بالا به پايين بر اساس متدولوژيهاي مختلف را دارا مي‌‌باشد. در 2167A مكرراً گفته شده است كه معماري نرم‌‌افزار بر اساس اجزاء پيكربندي نرم‌‌افزار (CSCI) (اComputer Software Configuration Items ) مي‌‌باشد كه هر كدام از آنها به چندين جزء نرم‌‌افزاري (CSC) (اComputer Software Component) قابل تجزيه مي‌‌باشد. همين قابليت تجزيه تا چندين مرحله مي‌‌تواند ادامه يابد تا اينكه در نهايت به يك واحد نرم‌‌افزاري (CSU) (اComputer Software Unit) كه با يك موجوديت فيزيكي كه برنامه متناظر است، منتهي شود. درحالي كه تعداد زيادي از كاربران هيچ مشكلي با اين نوع چارچوب در استاندارد 2167A ندارند اما عده‌‌اي ديگر آنرا مانعي براي بكارگيري متدولوژي‌‌هاي برتر مي‌‌دانند.

استاندارد 498 با ملزم كردن تجزيه CSCI به تعدادي CSU ، معماري نرم‌‌افزار را مورد بازبيني قرار داده است. هر واحد نرم‌‌افزاري (Software Unit) مي‌‌تواند هر نوع عنصري از طراحي يك CSCI باشد، به‌‌عنوان مثال هر كدام از اجزاي يك بخش، يك بخش اصلي، يك كلاس، شي، پيمانه، تابع، زيربرنامه يا بانك اطلاعات مي‌‌تواند يك واحد نرم‌‌افزاري باشد. واحدهاي نرم‌‌افزاري مي‌‌توانند در سطوح مختلف يك ساختار ظاهر شوند و ممكن است شامل واحدهاي نرم‌‌افزاري ديگري باشند. در استاندارد 498، واحدهاي نرم‌‌افزاري مي‌‌توانند با همديگر ارتباط يك به يك داشته باشند و هر كدام از آنها مي‌‌تواند شامل كد، داده و يا فايلي حاوي موجوديتهاي مختلف باشد.

اين عمومي‌‌سازي از واحدهاي نرم‌‌افزاري و جداسازي موجوديتهاي منطقي از موجوديتهاي فيزيكي انعطاف‌‌پذيري بالايي را در ساخت سيستم‌‌ها بوجود مي‌‌آورد. و قابليت بكارگيري متدولوژيهاي مختلف توسعه نرم‌‌افزار را در حيطه وسيعي فراهم مي‌‌آورد.
3- ساختار استاندارد MIL-STD-498
اين استاندارد در دو بخش زير ارائه شده است :

الف- استاندارد پياد‌‌ه‌‌سازي و مستندسازي نرم‌‌افزار
ب- بيست و دو مورد DID (اData Item Description ) براي توصيف وظايف

هر DID ، چگونگي انجام بخشي از استاندارد 498 را تشريح مي‌‌كند. فهرست DID ها در جدول شماره 2 ارائه شده است. بطور كلي استاندارد 498 در پنج بخش و يك پيوست با عناوين زير تدوين شده است.

- Scope
- Referenced Documents
- Definitions
- General Requirements
- Detailed Requirements
- Appendix

بخش اول و دوم مربوط به معرفي استاندارد و ارتباط آن با ديگر استانداردها مي‌‌باشد و در بخش سوم نيز تعاريف استفاده شده در اين استاندارد، ارائه شده است. در بخش چهارم، اصول كلي استاندارد و در بخش پنجم اقداماتي كه براي ساخت نرم‌‌افزار بايستي بعمل آيد، ارائه شده است. در ادامه، رئوس كلي بخشهاي چهارم و پنجم استاندارد معرفي مي‌‌گردد.

جدول شماره 2- DID هاي استاندارد MIL-STD-498

3-1- رئوس كلي بخش General Requirements
هدف از اين بخش تأسيس پروسه ساخت نرم‌‌افزار با ثبات مي‌‌باشد، بطوريكه نيازهاي مندرج در قرارداد را پوشش دهد و شامل فعاليتهاي موجود در Detailed Requirements باشد.
 
اصول كلي استاندارد 498 در زير ارائه شده است.
 
                   ·        استفاده از روشهاي سيستماتيك و مستند شده
                   ·       توسعه و بكارگيري استاندارد براي نمايش نيازها و خواسته‌‌ها، طراحي، كدنويسي و اطلاعات آزمايشي
                   ·       ارزيابي محصولات نرم‌‌افزاري قابل استفاده مجدد
                   ·       مشخص نمودن فرصتهايي براي ساخت محصولات نرم‌‌افزاري براي استفاده مجدد
                   ·       ايجاد و بكارگيري استراتژي‌‌هايي براي پرداختن به نيازهاي بحراني، همانند اطمينان، امنيت و خصوصي‌‌سازي
                   ·       تحليل نيازهاي استفاده بهينه از منابع سخت‌‌‌‌افزاري كامپيوتري
                   ·       ثبت اطلاعات اساسي به عنوان كليدهاي تصميم‌‌گيري براي استفاده توسط بخش پشتيباني
 
3-2- رئوس كلي بخش Detailed Requirements
فعاليتهايي كه در استاندارد 498 بايستي براي ساخت نرم‌‌افزار بعمل آيد در زير نام برده شده است. در ادامه، اقداماتي كه بايستي در هر يك از اين فعاليت‌‌ها بعمل آيد به طور كلي شرح داده مي‌‌شود و DID مورد استفاده براي انجام آن فعاليت، معرفي مي‌‌گردد.
 
يادآوري مي‌‌گردد در استاندارد 498، صرفاً اقداماتي كه براي ساخت يك نرم‌‌افزار بايستي بعمل آيد نام برده شده و در DID ها چگونگي انجام آنها تعريف شده است. بنابراين ترتيب اعمال اين فعاليت‌‌ها بستگي به متدولوژي انتخابي براي ساخت نرم‌‌افزار دارد. در نتيجه، استاندارد 498 بدون وابستگي به متدولوژي خاصي، اقداماتي كه بايستي براي ساخت هر نرم‌‌افزار (توكار، مستقل) بعمل آيد را تشريح مي‌‌كند.

   
5-1- Project planning and oversight
5-2- Establishing a Development Environment
5-3 - System Requirements analysis
5-4- System Design
5-5- Software Requirements analysis
5-6- Software Design
5-7- Software Implementation and Unit Testing
5-8- Unit Integration and Testing
5-9- CSCI Qualification Testing
5-10- CSCI/HWCI Integration and Testing
5-11- System Qualification Testing
5-12- Preparing for Software Use
5-13- Preparing for Software Transition
5-14- Software Configuration
5-15- Software Product Evaluation
5-16- Software Quality Assurance
5-17- Corrective Action
5-18- Joint Technical and Management Reviews
5-19- Other Activities
·       Risc Management
·       Software Management indicators
·       Subcontractor Management
·       Interface with IV & V agents
·       Coordination with Association Developers
·       Improvement of Project Processes
 

3-2-1- فعاليت Project Planning and Oversight
در اين فعاليت، بر اساس اقدامات زير، اجراي پروژه برنامه‌‌ريزي مي‌‌شود.
- برنامه‌‌ريزي براي ساخت نرم‌‌افزار (SDP-DID)
- طرح براي آزمايش صلاحيت (STP-DID) CSCI
- مشاركت در برنامه‌‌ريزي آزمايش سيستم (STP-DID)
- طرح راه‌‌اندازي نرم‌‌افزار در سايت كاربر (SIP-DID)
- طرح براي نقاط اساسي نرم‌‌افزار براي استفاده در پشتيباني (STRP-DID)
 
3-2-2-  فعاليت Establishing a Development Environment
در اين فعاليت، بر اساس اقدامات زير، محيط توليد نرم‌‌افزار آماده مي‌‌شود.
- تأسيس و كنترل و نگهداري يك محيط مهندسي نرم‌‌افزار
- تأسيس و كنترل و نگهداري يك محيط آزمايشي نرم‌‌افزار
- تأسيس و كنترل و نگهداري يك كتابخانه ساخت نرم‌‌افزار
- تأسيس و كنترل و نگهداري فايلهاي ساخت نرم‌‌افزارSDFر(Software Development Files)
 
3-2-3- فعاليت System Requirements Analysis
در اين فعاليت، بر اساس اقدامات زير، خواسته‌‌هاي سيستم مورد تحليل قرار مي‌‌گيرد.
- تحليل اطلاعات دريافتي از كاربر
- تعريف و ثبت مفاهيم عملياتي سيستم (OCD-DID)
- تعريف و ثبت نيازهاي سيستم (SSS-DID)
 
3-2-4- فعاليت System Design
در اين فعاليت بر اساس اقدامات زير، سيستم طراحي مي‌‌شود.
- تعريف و ثبت تصميمات طراحي گسترده سيستم (SSDD-DID)
اين تصميمات در مورد رفتار سيستم، بدون در نظر گرفتن عمليات داخلي و ديگر تصميماتي كه بر روي انتخاب و طراحي اجزاء سيستم تأثير مي‌‌گذارند انجام مي‌‌گيرد. تصميمات طراحي با صلاحديد سازنده آغاز مي‌‌گردد، مگر اينكه به صورت رسمي تبديل به نيازها شود. به عبارت ديگر تصميمات طراحي به عنوان يك سري نيازها مطرح مي‌‌شود كه بايستي پياده گردد.
 
- تعريف و ثبت طراحي معماري سيستم (SSDD-DID)
منظور از معماري سيستم مشخص نمودن اجزا سيستم (همانند HWCI (Hardware Configuration Items)، CSCI ، عمليات دستي)، واسطهاي آنها و مفاهيم اجرايي مابين آنها مي‌‌باشد.

3-2-5- فعاليت Software Requirements Analysis
در اين فعاليت، بر اساس اقدامات زير، نيازها و خواسته‌‌ها از نرم‌‌افزار مورد تحليل قرار مي‌‌گيرد.
- تعريف و ثبت نيازهاي نرم‌‌افزاري كه بايستي بوسيله هر CSCI پوشش داده شود (SRS-DID)
- تعريف و ثبت نيازهاي واسط‌‌هاي CSCI (IRS-DID)
 
3-2-6- فعاليت Software Design
در اين فعاليت بر اساس اقدامات زير، ابتدا نرم‌‌افزار بطور كلي و سپس بطور جزئي طراحي مي‌‌شود.
- تعريف و ثبت تصميمات طراحي CSCI به صورت سطح بالا (SDP-DID)
اين تصميمات در مورد رفتار CSCI ها با صرفنظر كردن از پياده‌‌سازي داخلي مي‌‌باشد. در اين قسمت هر تصميمي كه بر روي انتخاب و طراحي واحدهاي نرم‌‌افزاري انجام مي‌‌گيرد، ارائه مي‌‌شود.
 
- تعريف و ثبت طراحي معماري هر (SDD-DID) CSCI
منظور از طراحي معماري CSCI ، مشخص نمودن واحدهاي نرم‌‌افزاري، واسطهاي آنها و مفاهيم اجرايي مابين آنهاست. واحدهاي نرم‌‌افزاري ممكن است از واحدهاي نرم‌‌افزاري ديگر ساخته شده باشند و ممكن است در چندين سطح سازماندهي شده باشند.
 
- تعريف و ثبت طراحي جزئي هر (SDD-DID) CSCI
منظور از اين طراحي مشخص نمودن واحدهاي نرم‌‌افزار مي‌‌باشد. مي‌‌توان طراحي واسط‌‌هاي CSCI و يا بانك اطلاعاتي را نيز ارائه كرد. هر كدام از واحدهاي فوق (بانكهاي اطلاعاتي و طراحي واسط) مي‌‌توانند به صورت مجزا در DBDD-DID و IDD-DID آورده شوند.
 
3-2-7- فعاليت Software Implementtation and Unit Testing
در اين فعاليت، بر اساس اقدامات زير، واحدهاي نرم‌‌افزار، پياده‌‌سازي و مورد آزمون انفرادي قرار مي‌‌گيرند.
- پياده‌‌سازي و ثبت هر واحد نرم‌‌افزاري با استفاده از زبان برنامه‌‌نويسي تصويب شده
پياده‌‌سازي شامل نوشتن برنامه كامپيوتري، ساختن بانكهاي اطلاعاتي، پركردن بانكهاي اطلاعاتي، و ديگر فعاليتها مي‌‌باشد. كدهاي منتج شده و موجوديت‌‌هاي داده‌‌اي نياز ندارند كه حتماً داراي ارتباط يك به يك با واحدهاي نرم‌‌افزاري باشند.
 
 
 
- آماده‌‌سازي Unit Test Cases، رويه‌‌ها و داده‌‌ها
- انجام Unit Testing  
- بازبيني و آزمايش مجدد در صورت نياز
- تحليل نتايج و ثبت در SDF
 
(از آنجا كه برخي از واحدهاي نرم‌‌افزاري شامل واحدهاي ديگر مي‌‌باشند لذا ممكن است اين آزمايشات در قسمت Unit Testing انجام گيرد.)
 
3-2-8- فعاليت Unit Integratian and Testing
در اين فعاليت، بر اساس اقدامات زير، نرم‌‌افزار مجمتع شده و مورد آزمون قرار مي‌‌گيرد.
- آماده‌‌سازي Test Cases، رويه‌‌ها، و داده‌‌ها براي مجمتع كردن واحدهاي نرم‌‌افزاري
- انجام آزمايشات مجتمع‌‌سازي
- بازبيني و آزمايش مجدد در صورت نياز
- تحليل و ثبت در SDF
 
(از آنجا كه برخي از واحدهاي نرم‌‌افزاري شامل واحدهاي نرم‌‌افزاري ديگر مي‌‌باشند لذا ممكن است اين آزمايشات در قسمت Unit Testing انجام ‌‌گيرد.)
 
3-2-9- فعاليت CSCI Qualification Testing
در اين فعاليت، بر اساس اقدامات زير، هر CSCI مورد آزمون كيفيت قرار مي‌‌گيرد.
- آماده‌‌سازي Test Cases، رويه‌‌ها، و داده‌‌ها براي آزمايش كيفيت CSCI (STD-DID)
- اجراي آزمايشي Test Cases اگر بايستي تحويل گيرنده آزمايشات را گواهي كند.
- تجديدنظر و تكرار آزمايشات در صورت نياز
- تحليل و ثبت نتايج در گزارش آزمايش نرم‌‌افزار (STR-DID)
- دادن ضمانت به اشخاصي كه طراحي جزئي انجام نمي‌‌دهند.
- انجام آزمايشات در كامپيوتر مقصد
  

3-2-10- فعاليت CSCI/HWCI Integration and Testing
در اين فعاليت، بر اساس اقدامات زير، مجموعه سخت‌‌افزار و نرم‌‌افزار مجتمع شده، مورد آزمون قرار مي‌‌گيرد.
- آماده‌‌سازي Test Cases ، رويه‌‌ها، داده‌‌ها براي مجتمع‌‌سازي CSCI/HWCI
- انجام آزمايشات مجتمع‌‌سازي CSCI/HWCI
- بازبيني و تكرار آزمايشات در صورت نياز
- تحليل نتايج و ثبت در SDF
 
3-2-11- فعاليت System Qualification Testing
در اين فعاليت، بر اساس اقدامات زير، كل سيستم مورد آزمون كيفيت قرار مي‌‌گيرد.
- توسعه و ثبت Test Cases در صورتيكه تحويل گيرنده بايستي آزمايشات را گواهي كند.
- انجام آزمايشات كيفيت سيستم
- بازبيني و تكرار آزمايشات در صورت نياز
- تحليل و ثبت نتايج آزمايشات (STR-DID)
- دادن ضمانت به اشخاصي كه طراحي جزئي را انجام نداده‌‌اند.
- انجام آزمايشات روي كامپيوتر مقصد
 
3-2-12- فعاليت Preparing For Software Use
در اين فعاليت، بر اساس اقدامات زير، نرم‌‌افزار براي استفاده در كامپيوتر مقصد آماده‌‌سازي مي‌‌شود.
- آماده‌‌سازي نرم‌‌افزار اجرايي براي سايت كاربران (SPS-DID)
- مشخص نمودن و ثبت نسخه دقيق نرم‌‌افزاري كه بايستي به سايتها فرستاده شود (SVD-DID)
- آماده‌‌سازي اطلاعات مورد نياز براي :
- نحوه استفاده از نرم‌‌افزار (SUM-DID)
- نحوه ارائه وروديها و تفسير خروجيها (SIOM-DID)
- عمليات نرم‌‌افزار در مراكز نرم‌‌افزاري يا محيط‌‌هاي شبكه (SCOM-DID)
- عمليات كامپيوترها (COM-DID)
- نصب در سايتهاي كاربر، آموزش و ساير كمكهاي مورد نياز
 


3-2-13- فعاليت Preparing for Software Transition
در اين فعاليت، بر اساس اقدامات زير، قدم‌‌هاي لازم براي انتقال مسئوليت به نرم‌‌افزار جديد برداشته مي‌‌شود.
- آماده‌‌سازي نرم‌‌افزار اجرايي (SPS-DID)
- آماده‌‌سازي فايلهاي منبع (Source file) براي پشتيباني نرم‌‌افزار در سايت (SPS-DID)
- تعيين و ثبت نمودن نسخه دقيقي از نرم‌‌افزار كه بايستي به سايت ارسال شود (SVD-DID)
- بهنگام‌‌سازي توصيفات طراحي CSCI و آماده‌‌سازي ديگر اطلاعات مورد نياز (SPS-DID)
- بهنگام‌‌سازي توصيفات طراحي سيستم (SSDD-DID)
- آماده‌‌سازي اطلاعات مورد نياز براي :
                             ·        برنامه‌‌ريزي كامپيوترهاي مقصد (CPM-DID)
                             ·       برنامه‌‌ريزي سيستم‌‌هاي (FSM-DID) Firmware
- نصب نرم‌‌افزار در سايت پشتيباني، توصيف توليد مجدد نرم‌‌افزار از روي Source آن و آموزش
 
3­-2-14- فعاليت Software Configuration Management
در اين فعاليت، بر اساس اقدامات زير، مديريت پيكربندي نرم‌‌افزار انجام مي‌‌شود.
- مشخص نمودن تمام موجوديتهايي كه بايستي در طول ساخت نرم‌‌افزار كنترل شود كه عبارتند از: CSCI ها، فايلهاي كامپيوتري، مستندات، ديگر توليدات نرم‌‌افزار و عناصر محيط نرم‌‌افزاري
- ايجاد رويه‌‌هايي براي كنترل هر موجوديت
- آماده‌‌سازي و نگهداري ثبت وضعيتهاي هر موجوديت
- ايجاد رويه‌‌هايي براي بسته‌‌بندي، ذخيره، عمليات و تحويل
 
3-2-15- فعاليت Software Product Evaluation
در اين فعاليت، بر اساس اقدامات زير، محصول نرم‌‌افزاري مورد ارزيابي قرار مي‌‌گيرد.
- انجام ارزيابي محصولات نرم‌‌افزاري به صورت پروسه‌‌هاي مجزا و به صورت نهايي با تمركز بر :
                             ·        خروجيهاي طبيعي پروسه‌‌هاي توليد نرم‌‌افزار
                             ·        معيارهاي ارائه شده در استاندارد (ضميمه D از استاندارد)
- آماده‌‌سازي ثبت ارزيابي‌‌ها (بيشتر براي ثبت گزارشهاي مشكلات و تغييرات براي تصحيح سيستم)
 
 


3- 2-16- فعاليت Software Quality Assurance
در اين فعاليت، بر اساس اقدامات زير، كيفيت نرم‌‌افزار مورد تأييد قرار مي‌‌گيرد.
- انجام ارزيابيها براي تضمين
                             ·        فعاليتهاي مورد نياز در قرارداد و يا فعاليتهاي توصيف شده بر اساس SDP-DID
                             ·       انجام ارزيابي، آزمايش و عمليات تصحيح براي توليدات نرم‌‌افزاري
 
- آماده‌‌سازي ثبت ارزيابيها (بيشتر براي ثبت گزارش‌‌هاي مشكلات و تغييرات براي تصحيح سيستم)
 
3-2-17- فعاليت Corrective Action
در اين فعاليت اقدامات زير بعمل مي‌‌آيد.
- آماده‌‌سازي گزارشهاي مشكلات / تغييرات براي مسائلي كه در موارد زير يافت شده‌‌اند.
                             ·        توليدات نرم‌‌افزاري در سطوح پروژه يا كنترلهاي بالاتر
                             ·        فعاليتهاي مورد نياز مندرج در قرارداد يا فعاليتهاي ذكر شده بر اساس SDP-DID
 
- پياده‌‌سازي يك سيستم عملياتي تصحيح براي اعمال روي مسائل زير
                             ·        دادن اطمينان به اين كه سيستم  يك حلقه بسته (Closed Loop)مي‌‌باشد
                             ·        طبقه‌‌بندي مشكلات بر اساس اولويت
                             ·        انجام تحليل براي مشخص شدن روند
                             ·        ارزيابي عمليات تصحيح
 
3-2-18- Joint Technical and Management Reviews
در اين فعاليت، بر اساس اقدامات زير، بازبيني‌‌هاي مديريتي و فني بطور مشترك انجام مي‌‌شود.
- برنامه‌‌ريزي براي مرورهاي فني و مديريتي (سازنده/ تحويل گيرنده)(Acquirer / Developer) شامل افرادي با دانش فني از كار  به منظور
                             ·       مرور استنتاجي از توليدات نرم‌‌افزاري
                             ·       استخراج پيامد/ ريسك‌‌ هاي Issue / Risks فني
                             ·       مشخص نمودن پيامد/ ريسك براي بررسي بيشتر در وارسي مديريتي
 
- برنامه‌‌ريزي براي بازبيني‌‌هاي مديريتي شامل افرادي با نفوذ
                             ·        براي ساختن تصميمات Cost / Schedule
                             ·        استخراج پيامد/ ريسك‌‌هايي كه در بازبيني فني نيامده است.
 
3-2-19- Other Activities
در اين بخش ساير فعاليتهاي مورد نياز انجام مي‌‌شود.
- مشخص نمودن ريسكهاي پروژه، استراتژي‌‌هاي ساخت و پياده‌‌سازي براي مديريت آنها
- مشخص نمودن و بكارگيري شاخص‌‌هاي مديريت نرم‌‌افزار
- برآوردن نيازهاي امنيتي و خصوصي در قرارداد
- قرار دادن تمامي نيازهاي لازم در قراردادهاي فرعي بطوريكه محصولات نرم‌‌افزاري ساخته شده با قرارداد اصلي مطابق باشد.
- ارتباط با عامل IV&V ا(Independent Verification and Validation) بصورت مشخص شده در قرارداد
- هماهنگي با گروههاي كاري و گروههاي واسط مشخص شده در قرارداد
- ارزيابي پروسه‌‌هاي مورد استفاده در پروژه به صورت دوره‌‌اي