مقاله متریک های نرم افزاری برای ارزیابی محصول مربوطه  به صورت فایل ورد  word و قابل ویرایش می باشد و دارای ۱۰۲  صفحه است . بلافاصله بعد از پرداخت و خرید لینک دنلود مقاله متریک های نرم افزاری برای ارزیابی محصول نمایش داده می شود، علاوه بر آن لینک مقاله مربوطه به ایمیل شما نیز ارسال می گردد

فهرست مطالب

۱- مقدمه ۱
۱-۱- دلایل ارزیابی نرم افزار ۱
۱-۲- کیفیت نرم افزاری چیست؟ ۴
۱-۳- مسایل مربوط به جمع‌‌‌آوری داده ۶
۱-۴- پروژه SCOPE 11
۱-۵- ساختار این اثر ۱۵
خلاصه ۱۷
۲- شیوه‌‌‌های ارزیابی نرم افزار ۱۸
۲-۱- ارزیابی، ارزشیابی و تایید ۱۸
۲-۲- مجموعه متریک ها در متن ۱۹
۲-۳- شیوه SCOPE 21
۲-۳-۱- شیوه SCOPE برای چیست؟ ۲۱
۲-۳-۲- شیوه ارزیابی ۲۳
۲-۴- تایید فرآیند کلی ۲۴
۲-۵- ارزیابی فرآیند ویژه ۲۷
۲-۶- ارزیابی محصول ویژه ۲۸
۲-۷- ارزیابی ویژگی به خصوص ۳۰
۱-۲-۷- وجود یک استاندارد (یا پیش استاندارد) ۳۰
۲-۲-۷- وجود یک استاندارد بالقوه صنعتی ۳۲
۳-۲-۷- یک شرکت با محصولات متعدد نرم افزاری ۳۲
۴-۲-۷- یک شرکت با پیمانکاران فرعی متعدد ۳۳
۲-۸- بهینه کاوی ۳۳
۲-۹- ارزیابی محصول جعبه سیاه ۳۶
۱-۲-۹- طرح GGS 37
۲-۲-۹- طرح BSI 38
۲-۱۰- مدیریت به وسیله متریک ها ۳۹
خلاصه ۴۳
۶- تحلیل متریک ها ۴۴
۶-۱- استفاده از آمار در ارزیابی محصول ۴۵
۶-۲- مشکلات مربوط به داده های متریک ها ۴۷
۶-۲-۱- توزیع نرمال ۴۸
۶-۲-۲- outlier ها ۵۰
۶-۲-۳- مقیاس های اندازه گیری شده ۵۰
۶-۲-۴- چندمجموعه ای ۵۳
۶-۳- جمع آوری متریک ها ۵۴
۶-۴- محدوده کلی داده ها ۵۶
۶-۵- تحلیل خارجی ۵۷
۶-۵-۱- استفاده از آمارهای توصیفی ۵۸
۶-۵-۲- outlier های چندبعدی ۵۹
۶-۶- ایجاد آستانه ها و هنجارها ۶۱
۶-۷- مقایسه پروژه ها ۶۴
۶-۸- روابط بین متریک ها ۶۵
۶-۸-۱- شیوه های تایید ۶۵
۲-۸-۶- تست یک فرضیه ۶۸
۶-۹- ارزیابی قابلیت اطمینان ۷۰
۶-۹-۱- توسعه و ثبات قابلیت اطمینان ۷۱
۶-۹-۲- انتخاب مدل صحیح قابلیت اطمینان ۷۲
۶-۹-۳- تحلیل داده های شکست با آمارهای ساده ۷۵
۶-۱۰- محدودیت های پیش بینی قابلیت اطمینان ۷۵
۶-۱۰-۱- نرم افزاری که هرگز شکست نخورده است ۷۶
۶-۱۰-۲- افزایش ارزیابی با عقاید پیشین ۷۶
۶-۱۰-۳- استفاده از شیوه های رسمی ۷۷
خلاصه ۷۸
۷- ابزار جمع آوری داده ۷۹
۷-۱- الزامات مربوط به ابزارهای جمع آوری داده ۷۹
۷-۲- سیستم های جمع آوری داده session 83
۷-۲-۱- اصول SDCS 83
۷-۲-۱- معماری سطح بالا ۸۴
۷-۲-۳- اندازه های زمانی ۸۶
۷-۲-۴- طراحی front end های SDCS 86
۷-۲-۵- فرمت کردن داده session 88
۷-۲-۶- عیب یابی نسخه ۸۹
۷-۲-۷- مثال هایی از SDCS ها ۹۰
۷-۳- مدیر چک لیست ۹۰
۷-۳-۱- تعریف یک چک لیست ۹۰
۷-۳-۲- استفاده از یک بسته صفحه گسترده تجاری ۹۲
۷-۳-۳- تعیین مدیر فهرست کنترل ۹۳
۷-۴- فیلتری برای لینت ۹۳
۷-۴-۱- تنظیم محیط ۹۵
۷-۴-۲- انتخاب پیامهای مناسب ۹۵
۷-۴-۳- تعیین راهبردهای فیلتر ۹۷
۷-۵- پیشرفت های تحلیل گران برنامه ۹۹
۷-۵-۱- QULAMS 100
خلاصه ۱۰۱

– مقدمه

۱-۱- دلایل ارزیابی نرم افزار

سیستم‌‌‌های رایانه ای دارای اهمیت چشمگیری در سراسر جامعه است. ما بیش از هر زمان دیگری به آنها متکی بوده و این اتکا دلیلی بر این مدعاست که وابستگی ما رو به رشد است. چنانچه این سیستم‌‌‌ها به طریقی که ما انتظار داریم پیش نرود، منجر به صرف هزینه و وقت خواهد شد. در حوزه امنیتی، این هزینه می‌‌‌تواند بالاتر باشد و به آسیب جدی، مرگ و خسارت به اموال منجر شود. بنابراین، کیفیت این سیستم‌‌‌ها مورد توجه همگان قرار دارد. در هر سیستم رایانه ای، نرم افزار (برنامه‌‌‌ها و مستندات آنها) بخش مهمی را تشکیل می‌‌‌دهد. وقت و پول اغلب برای ایجاد نرم افزاری که بزرگتر از اجزا سخت افزاری آن است به کار می‌‌‌رود. بنابراین، کیفیت نرم افزار به نوبه خود موضوع مهمی تلقی می‌‌‌شود.

موارد بی‌‌‌شماری از عدم موفقیت نرم افزار برای انجام آنچه مدنظر ما بوده ، توقف غیرمنتظره سخت افزاری یا دشواری استفاده از آن وجود دارد. اینها بارزترین نمونه‌‌‌های کیفی ضعیف است. اگرچه هنگامی که تغییر یک نرم‌‌‌افزار به دلیل ساختار بد آن دشوار است موضوع چشمگیری نیست ولی مهم تلقی می‌‌‌شود. تصور اینکه اگر یک سیستم نرم افزاری بزرگ رها شده و سیستم دیگری که دارای قابلیت تغییر است جایگزین آن شود موجب هدر رفتن هزینه می‌‌‌شود دشوار نیست.

همه این موارد نمونه‌‌‌هایی از کیفیت ضعیف نرم افزاری محسوب می‌‌‌شود. ما بعداً به تعریف این مورد می‌‌‌پردازیم اما باید برای افرادی که با سیستم‌‌‌های رایانه ای کار می‌‌‌کنند آشکار شود که کیفیت ضعیف نرم افزاری به مثابه مساله‌‌‌ای قابل شناسایی است. جای شگفتی نیست که، مهندسین نرم افزاری در بیش از ۲۵ سال گذشته، به ارایه روش‌‌‌های متعددی پرداخته‌‌‌اند که سعی در بهبود کیفیت نرم افزاری داشته است. آنها روش‌‌‌های تصریحی و طراحی، زبان‌‌‌های جدید، ابزارهای CASE (مهندسی نرم افزار به کمک کامپیوتر)، برنامه‌‌‌های مترجم (کامپایلرهای) معتبر، راهبردهای آزمایشی، الگوهای تکاملی، شیوه‌‌‌های مدیریتی و از قبیل آن را ارایه نموده‌‌‌اند. هر ایجاد کننده نرم افزاری می‌‌‌تواند یک یا ترکیبی از این روش‌‌‌ها را انتخاب کند، اما هیچ تضمینی وجود ندارد که سطح مورد نیاز کیفی در اجرای آن حاصل شود. بی‌‌‌شک، مخترعان و فروشندگان روش‌‌‌های مختلف با ابزارهای مرتبط، کتاب‌‌‌ها و دوره‌‌‌های آموزشی مدعی خواهند شد که چنانچه شیوه‌‌‌های خاص آنها اجرا شود، کیفیت بهبود خواهد یافت. با وجود این، قصد ما زیر سوال بردن صداقت آنها نیست، بلکه روشن شدن این نکته است که آیا کیفیت به طور رضایت بخشی بالا است یا خیر. ما جهت اطمینان از مناسب بودن سطح کیفی راهی جز ارزیابی جداگانه نداریم.

تحقیق گسترده اروپایی در مورد نیازها و خواسته‌‌‌های مربوط به ارزیابی و تایید نرم افزار، به طور واضح حاکی از مفاهیم ذیل است که توسط تولیدکنندگان و کاربران نرم افزاری حاصل شده است:

تایید فرآیند نرم افزار برای تضمین کیفیت محصولات نرم افزاری کافی نیست اما جهت تایید محصول ضروری است.
مشتریان به دنبال بهتر نمودن کیفیت محصولات نرم افزاری هستند تا حدی که حاضرند میزان ۲۰ درصد بیشتر از سفارشی که به آنها داده شده بپردازند.
ارزیابی محصول نرم افزاری اهمیت بسیاری در تصمیم گیری درباره راهبرد تکاملی آن محسوب می‌‌‌شود.

ما در این کتاب برآنیم که روش خاصی از ارزیابی کیفی نرم افزار را که مبتنی بر اندازه گیری ویژگی‌‌‌های کیفی محصول است ارایه کنیم. چنین ارزیابی به معنی تایید از سوی فرد شناخته شده مستقل است. این امر انگیزه‌‌‌ای برای بهبود ایده‌‌‌ها و روش‌‌‌های ارایه شده در این قسمت بود. با وجود این کلیه روش‌‌‌های ارایه شده به بسیاری از اشکال تضمین کیفیت نرم افزاری (QA) مرتبط هستند. این امر شامل QA انجام شده توسط خود تولیدکنندگان نرم افزاری یا شخص ثالثی به عنوان تایید کننده مستقل و معتبر می‌‌‌باشد.

در حال حاضر روش‌‌‌های ارزیابی محصول محول متعددی وجود دارد. بسیاری از آنها، از قبیل روش‌‌‌های آزمایش جعبه سیاه و تحلیل آماری اکنون در توسعه نرم افزاری به کار می‌‌‌رود. اما چنین شیوه‌‌‌هایی اغلب مستقل محسوب شده و یک شیوه خاص مانند بازرسی یا پوشش تست در نقطه خاصی از چرخه دوام استفاده می‌‌‌شود. آنها به عنوان بخشی از شمای کلی ارزیابی کیفیت نرم افزاری به عنوان کل تلقی نمی‌‌‌شود. ما در اینجا روش یکپارچه سازی شیوه‌‌‌های گوناگون در یک شمای منسجم را ارایه می‌‌‌کنیم، به طوری که این اطلاعات را به عنوان معیارهایی جهت ارزیابی کیفی محصولات جمع‌‌‌آوری نمود. برای تحقق این امر، نخست به حل تعدادی مسایل فنی می‌‌‌پردازیم:

هدف اولیه این کار عبارت از تولید وسیله‌‌‌ای برای ارزیابی نرم افزار جهت تایید است. این روش‌‌‌ها می‌‌‌تواند به وضوح جهت QA داخلی و توجیه آن نیز به کار رود. اما این روش کاربردهای دیگری نیز دارد. معیارهای نرم افزاری به منظور هدف‌‌‌های مختلفی جمع آوری می‌‌‌شود که از جمله آنها می‌‌‌توان به تایید نرم افزار اشاره کرد. معیارها ممکن است به منظور برآورد هزینه، مدیریت یا ارزیابی فرآیندهای مختلف توسعه نیز به کار رود. این ایده‌‌‌ها همچنین در مورد محققین زمینه مهندسی نرم افزار که مایل به تعیین کارآیی یک شیوه پیشنهادی جدید، زبان و غیره هستند نیز قابل اجرا می‌‌‌باشد. بنابراین، بسیاری از این ایده‌‌‌های مطرح شده کاربردی فراتر از تایید نرم افزار دارند.

۱-۲- کیفیت نرم افزاری چیست؟

تاکنون درباره معنای کیفیت نرم افزار دچار ابهام بوده‌‌‌ایم. ما قطعا در مرحله اول به تعریف مختصر تشخیص مسایل کیفی احتیاج نداریم. با وجود این، چنانچه بخواهیم به روش‌‌‌های ارزیابی نرم افزار دست یابیم، شناخت معیارهای مربوط به ارزیابی ضروری است.

ISO 9000 (که تحت عنوان BS 5750 شناخته می‌‌‌شود) کیفیت را به صورت “مجموع ویژگی‌‌‌ها و مشخصه‌‌‌های یک محصول یا سرویس که شامل قابلیت جلب رضایت نیاز تعیین شده یا ضمنی است” تعریف می‌‌‌کند.

دو بخش مهم این تعریف عبارت از “مجموع ویژگی‌‌‌ها” و “نیازهای ضمنی یا تعیین شده” می‌‌‌باشد. مجموع ویژگی‌‌‌ها به معنای این است که ما می‌‌‌توانیم مفهوم کیفیت را به تعدادی از مشخصه‌‌‌ها تقسیم کنیم. همچنین اینها به عنوان عوامل کیفیت، قابلیت‌‌‌ها یا فقط عیوب شناخته می‌‌‌شوند زیرا توسط کلماتی از قبیل قابلیت اطمینان، قابلیت پشتیبانی و قابلیت آزمون پذیری تشریح می‌‌‌شود. ایده فروپاشی مفهوم جهانی کیفیت به عوامل کیفی، اولین بار توسط “مک کال”[۱] و همکاران مطرح شد. تلاش‌‌‌های فراوانی به منظور تجزیه کیفیت به مشخصه‌‌‌های خاص و سپس نامگذاری هریک از آنها تحت عنوان یک معیار صورت گرفته است. در این میان می‌‌‌توان به آثار “آرتور”[۲]، “بوئم”[۳] و همکاران، “بوئن”[۴] و همکاران، “دوئیچ”[۵] و “ویلیس”[۶]، “فورس”[۷]، “گیلیس”[۸]، “گریدی”[۹] و “کاسول”[۱۰] و “وان ماری هاوسر”[۱۱] اشاره کرد. ما می‌‌‌توانیم هریک از این الگوهای کیفی را که در بسیاری از جهات به یکدیگر شبیه بوده و به طور عمده از لحاظ واژگان با یکدیگر تفاوت دارند برگزینیم. با وجود این، برآنیم تا ویژگی‌‌‌هایی را که در استاندارد ISO 9126 به صورت استاندارد درآمده است را بپذیریم.

این استانداردها به صورت الگوهای کیفی مختلفی برای ایجاد مجموعه کوچکی از شش مشخصه همسان درآمده است که مفاهیم اصلی مورد نظر ما را پوشش می‌‌‌دهد. به هر روی، بیشتر روش‌‌‌های توصیفی جهت جمع‌‌‌آوری، ذخیره و تحلیل داده‌‌‌ها مستقل از الگوی کیفی انتخاب شده است. یک فرد تاییدکننده یا بخش QA ممکن است الگوی کیفی مختلفی را انتخاب کنند، اما هنوز هم بخش بزرگی از کار به یکدیگر مرتبط است.

در تعریف کیفیت، اصطلاح “نیاز ضمنی” به معنای این است که ما نمی‌‌‌توانیم فرض کنیم که ویژگی محصول خودمان به طور مطلق کامل و صحیح است.

ویژگی‌‌‌های غیرکاربردی از قبیل قابلیت نگهداری به ندرت مشخص شده است، اما اغلب دارای اهمیت زیادی برای مشتری است. همچنین ویژگی یک محصول ممکن است شامل از قلم افتادگی یا اشتباهاتی باشد. بنابراین ممکن است یک سیستم به طور کامل با نیازها و خواسته‌‌‌های مشتری در تضاد باشد. برای مثال، یک از قلم افتادگی در ویژگی‌‌‌های سیستم می‌‌‌تواند بدین معنا باشد که نرم افزار می‌‌‌تواند حالتی خطرناک ایجاد کند. ماشین لباسشویی کامپیوتری ممکن است دچار یک موقعیت مخاطره آمیز شود. برای مثال، ممکن است تحت سرریز مجموعه‌‌‌ای از شرایط احتمالی پیش بینی نشده قرار گیرد. چنین محصولی اگرچه دارای تطابق با ویژگی‌‌‌های خود است لیکن می‌‌‌تواند به صورت کیفیت نامناسب تلقی شود.

هنگامی که در مورد کیفیت نرم افزار بحث می‌‌‌کنیم، صرفا بدان معنا نیست که کد منبع بسیاری از روش‌‌‌های ارزیابی آماده ارزیابی این کد هستند. تاکید بدان علت است که در بخش‌‌‌های بزرگ، روش‌‌‌های کاملی جهت ارزیابی محصولات پیشین چرخه دوام نداریم. به منظور انجام ارزیابی، شیوه‌‌ ارزیابی تصریحی و طراحی را در نظر خواهیم گرفت. ما قبول داریم که مساله مهمی محسوب نمی‌‌‌شود، اما برخی پژوهشگران نظر مخالفی دارند. آنها عقیده دارند که کددهی یک بخش مهم از ایجاد نرم افزار محسوب می‌‌‌شود: هنگامی که طراحی‌‌‌ها و ویژگی‌‌‌ها صحیح باشند، کددهی عملی ناچیز شمرده می‌‌‌شود. این دیدگاه در این قسمت مورد حمایت قرار نمی‌‌‌گیرد، نگهداری که اغلب بزرگترین بخش مربوط به هزینه چرخه عمر را تشکیل می‌‌‌دهد به شدت تحت تاثیر کیفیت این کد قرار دارد. هنوز هم تعدادی از تولیدات نرم افزاری وجود دارد که به طور کامل مشتمل بر کد هستند، خوشبختانه سایر اسناد یا از تاریخ گذشته یا در وهله اول تولید نمی‌‌‌شود.

۱-۳- مسایل مربوط به جمع‌‌‌آوری داده

هر ارزیابی یا تایید مبتنی بر ارزیابی محصول نیاز به معیارهایی دارد که به دقت جمع‌‌‌آوری شده باشند. بدون مجموعه‌‌‌ای از داده‌‌‌ها به وضوح نمی توان به ارزیابی پرداخت؛ این راحت توسط استانداردهای EN45000 ایجاد می‌‌‌شود. بهترین چارچوب سازمانی و بیشترین الگوی کیفی دنیا به طور قطع بدون ابزاری برای کسب داده‌‌‌های معیارمتری مناسب قابل استفاده نخواهد بود. ما بر این نکته اذعان داریم که این مسایل فنی تاکنون مانع اصلی استفاده از معیارهای نرم افزاری جهت ارزیابی یا سایر هدف‌‌‌ها محسوب می‌‌‌شدند.

از آنجا که هر نوع ارزیابی رسمی یا نتایج تاییدی پیشین باید بایگانی شود، داده‌‌‌هایی که در خلال ارزیابی جمع‌‌‌وری شده است نیاز به ذخیره دارد. علاوه بر این، داده‌‌‌های پیشین برای ایجاد هنجارها، تعیین مقادیر نوعی مربوط به معیارها و نمایش معیارهای قبول/ رد به کار می‌‌‌رود. در نهایت، به روشهای تحلیل داده نیاز داریم. کمیت داده مربوط به یک محصول نرم افزاری نسبتا کوچک نیز می تواند به صورت چندین صفحه اعداد اجرا شود.

هر طرح ارزیابی نیازمند روشهای استخراج اطلاعات مرتبط از حجمی از داده‌‌‌ها است. اقدامات مربوط به جمع‌‌‌آوری، ذخیره و تحلیل داده‌‌‌ها طرح معیار نامیده می‌‌‌شود. این طرح بخشی اساسی در طرح تایید مبتنی بر ارزیابی محصول محسوب می‌‌‌شود. همانگونه که قبلا نیز ذکر شد، یک طرح معیارمتری ممکن است برای اهداف کاملا متفاوتی از قبیل ارزیابی روش‌‌‌ها یا مدیریت هزینه به کار رود. این معیارهای جمع‌‌‌آوری شده ممکن است متفاوت باشد اما بسیاری از اصول و راهبردهای آنها به یکدیگر شباهت دارد.

در گذشته، برای تعدادی از اهداف مانند مدیریت، QA و ارزیابی برخی الگوهای پیشنهادی نرم افزاری، طرح‌‌‌های معیارمتری بسیاری تعریف، اجرا و به کار رفته است. پروژه‌‌‌های پژوهشی زیادی مانند REQUEST و SWDL همگی چنین طرح‌‌‌های معیارمتری را با درجه‌‌‌های متفاوتی از موفقیت به کار بسته‌‌‌اند. بسیاری از شرکت‌‌‌های بزرگتر برای ارزیابی محصولات و فرآیندهای خودشان، طرح‌‌‌های معیارمتری خود را به کار برده‌‌‌اند. یکی از اولین و بهترین نمونه‌‌‌های عمومی تجربه تشریح شده در “هیولت ـ پکارد”[۱۲] است: ایجاد یک برنامه گسترده شرکتی  جایی است که در آن شرکت برنامه‌‌‌ای برای جمع‌‌‌آوری معیارها و ذخیره آنها در سایت مرکزی با نگرش به بهبود بهره وری تاسیس می‌‌‌کند. در واقع، این برنامه کاملا متفاوت از برنامه‌‌‌ای است که برای ارزیابی به آن نیاز داریم. طرح ما به جمع آوری معیارهای بیشتر و کسب داده‌‌‌های کمی‌‌‌تری نیاز خواهد داشت.

ما با دو سطح از جهل موضوعی مواجه هستیم : ابتدا، ندانستن موضوعی، دوم، عدم اطلاع از نداستن موضوعی. شاید به این دلیل است که مردم اغلب در سطح دوم قرار دارند و بر این باورند که جمع آوری داده موضوعی ساده و بی‌‌‌اهمیت است. بسیاری از پروژه‌‌‌های معیارمتری درگیر مسایل خاصی هستند. هدف این کتاب نشان دادن نحوه حل چنین مسایلی است. نخست، این مسایل چگونه هستند؟

جمع‌‌‌آوری داده اغلب بدون ایده مشخصی از الزامات داده و نحوه تحلیل آنها شروع می‌‌‌شود. پروژه‌‌‌ها اغلب سعی در “جمع آوری هر چیز” می‌‌‌نمایند. این امر منجر به انباشت حجم زیاد و پیچیده‌‌‌ای از داده خواهد شد. به مرور زمان درخواهید یافت که معیارهای واقعی استفاده حذف شده یا اصلا به شیوه‌‌‌ای درست جمع‌‌‌آوری نشده است. اساساً، چنانچه هدف مشخصی از جمع آوری داده ندارید، زحمت جمع‌‌‌آوری آن را به خود ندهید.
تعاریف معیارها اغلب واضح نیست. این بدان معناست که سایت‌‌‌های مختلف معیارها را با روش‌‌‌های متناقضی جمع آوری می‌‌‌کنند. چنانچه به مدیران سایت‌‌‌های مختلف هر حوزه‌‌‌ای برای تغییر تعاریف و دیکته کردن ماهیت انسانی داده شود تلاش می‌‌‌کنند تا شخصیت خود را در آن قالب قرار دهند. بنابراین، این داده‌‌‌ها قابل مقایسه با یکدیگر نیستند. این مشکلی کلاسیک و به مثابه مقایسه سیب و گلابی با یکدیگر است.
پروژه‌‌‌های معیارمتری اغلب به بررسی مقالات یا انکار کارهای موجود در زمینه‌‌‌های ساختگی نخواهند پرداخت، بلکه به دنبال حصول مواردی بهتر و بیشتر هستند. این امر سندروم کلاسیک NIH نامیده می‌‌‌شود.آنها اغلب معیارهای خودشان را ابداع می‌‌‌کنند.

این امر ممکن است غیرعینی باشد و جزو هیچ فرضیه مورد اعتباری نباشد.

از مورد ۳ نتیجه می شود که ممکن است معیارمتری بدون هیچ ابزار پشتیبانی به کار رود. این امر منجر به جمع‌‌‌آوری داده‌‌‌های مستعد خطا و پرهزینه می‌‌‌شود.

پروژه‌‌‌های معیارمتری فقط مجموعه بسیار ساده‌‌‌ای از معیارها را در سطحی بسیار بالا جمع‌‌‌آوری می‌‌‌کند (به عنوان مثال خطوط کد بیش از کل پروژه‌‌‌ها). در این مورد آنها به طور موقت از وضعیت فعلی خارج شده، زیرا معیارهای بهتری برای به دست آوردن ویژگی‌‌‌های خاص مورد نظر وجود دارد.

معیارها بر روی فرم‌‌‌های کاغذی جمع‌‌‌آوری می‌‌‌شوند. اگر شما تنها مجموعه کوچکی از معیارهای ساده، اما نه برای مجموعه‌‌‌ای گسترده را جمع آوری کنید، می توانید فرم کاغذی ایجاد کنید. فرم‌‌‌های کاغذی می‌‌‌توانند ارزان و به سرعت تولید شوند. با وجود این در دراز مدت به صرفه نیستند. فرم‌‌‌ها در نهایت باید تایپ کامپیوتری شوند. ناگزیر، خطاهای دست نوشت ایجاد خواهد شد، به ویژه هنگامی که توسط کارمندی که هیچ اطلاعی در مورد نرم افزار ندارد انجام شود. هیچ چیز از این بدتر نیست که یک پروژه معیارمتری ۱۵۰۰۰ فرم داشته باشد که پس از گذشت ۲ سال از پایان پروژه وارد پایگاه داده نشده است. احتمالا هرگز نیز وارد نخواهد شد.

هرگونه طرح معیارمتری با اندازه منطقی می تواند با نسخه‌‌‌های مختلف و متفاوت سخت افزاری مربوط به سیستم‌‌‌های عملکردی منطبق شود. چنانچه این فرم‌‌‌ها الکترونیکی باشد ممکن است باعث بروز مشکلاتی در انتقال داده بین ماشین‌‌‌ها شود.

اغلب داده‌‌‌ها در سطوح نامتناسب با اهداف مورد نظر جمع‌‌‌آوری می‌‌‌شوند. برای مثال، چنانچه تعدادی خطا در سطح کل پروژه جمع‌‌‌آوری شود، آن اطلاعات نمی تواند برای معرفی چنین بخش مستعد خطایی به کار رود.

اغلب داده‌‌‌ها از سوی تهیه کنندگان حساس تلقی می‌‌‌شوند. این داده‌‌‌ها بدون اینکه بلااستفاده تعبیر شود باید با تغییر علایم مشخصه آن حفظ و نگهداری شود.

اغلب، مسئولیت جمع‌‌‌آوری داده بر عهده برنامه نویسان است. آنها ممکن است فراموش کنند که مواردی را ثبت کرده یا موارد باشد که به نظر آنها اضافی جلوه کند و به آن توجه کافی ننمایند.

اغلب برنامه نویسان تمایل دارند که کار خود یا همکارشان را ارزیابی کنند. آنها تلاش خواهند کرد تا بهترین اثر ممکن را ارایه داده به طوری که به اثر همکار خود نیز خیانت نکرده باشند.

تاثیر “هاوثورن” را نیز باید مورد توجه قرار داد. در واقع، نظارت مردم به این معناست که آنها به طور ناخودآگاه تمایل دارند تا به روش‌‌‌های مختلفی کار کنند تا بهترین‌‌‌ها را نشان دهند.

۱۰٫ چنانچه داده‌‌‌ها با روش‌‌‌ها و توسط افراد مختلف و در زمان‌‌‌های متفاوتی جمع آوری شده باشد باید بتوان به هنگام ذخیره سازی آنها را به یکدیگر مرتبط نمود.

۱۱٫ اغلب، راهبردهای آماری نامناسبی در مورد داده‌‌‌های معیارمتری نرم افزاری بدون توجه به فرضیات، اهداف و محدودیت‌‌‌های فنی به کار می‌‌‌رود.

۱۲٫ مخزن اصلی ذخیره داده اغلب متناسب با پیچیدگی و کمیت داده نمی باشد.

به نظر می‌‌‌رسد که مسایل ذکر شده در بالا مشهود و راه حلی آسان داشته باشند. با وجود این در بسیاری تجارب مربوط به پروژه‌‌‌های معیارمتری اشتباهات مشابهی حاصل شده است. به عنوان مثال یکی از تهیه کنندگان، پیش از شروع مطالعه  موردی یک ثبت وقایع دارای خطا ایجاد کرده بود. این یک شروع خوب محسوب می‌‌‌شد اما وی معتقد بود که برنامه معیارمتری کامل است. تهیه کننده دیگری می‌‌‌خواست از SCOPE برای بهبود روش ارزیابی مربوط به تکمیل یا ثبات ویژگی‌‌‌های نوشتاری در انگلیسی غیررسمی استفاده کند.

آیا به وجود مسایل عملی و نظری عمیق اذعان دارید.

مرحله مهم در حل این مسایل استفاده از ابزار است. ابزار جمع آوری داده را آسان تر نموده و در مقیاس‌‌‌های بزرگ داده‌‌‌های با ثبات تری را جمع آوری می کند. اما استفاده از ابزار هنگامی که خارج از طرح معیارمتری تهیه شده باشد نیز مشکلاتی به همراه دارد.

۱-۴- پروژه SCOPE

این کتاب به پروژه‌‌‌های تحقیقاتی متعدد از جمله SCOPE پرداخته است. بسیاری از پژوهشگران SCOPE قبلا بر روی پروژه های دیگری کار کرده و دارای تجارب زیادی هستند. ما از موفقیت‌‌‌ها و ناکامی‌‌‌های پروژه‌‌‌های پیشین تجربه کسب می‌‌‌کنیم.

SCOPE [13] یک همکاری چهارساله مربوط به پروژه ESPRIT II محسوب می‌‌‌شود که توسط مجمع جوامع اروپایی (CEC) تامین اعتبار شده بود. آنها مشتمل بر ۱۲ شریک بودند که ۴ نفر مرتبط با کل هشت کشور محسوب می شوند. براساس پیوست فنی پروژه، هدف آنها تعریف، آزمون و تایید روش‌‌‌های ارزیابی نرم افزار اروپایی بود که به آنها امکان تایید می‌‌‌دهد.

طرح تایید SCOPE متمایل به پوشش کلی محصولات بحرانی کم و متوسط از قبیل راکتورهای هسته‌‌‌ای و هواپیماهای نظامی بوده است.

این پروژه دارای سه زمینه اصلی است:

یک تعریف کلی بالا به پایین از ارزیابی و طرح تاییدی با جزییات سازمانی تاییدی و الگوهای مختلف باید پروژه را مورد پشتیبانی قرار دهد.

یک برنامه کاربردی تجربی از پایین به بالا که مبتنی بر تلاش برای ارزیابی تولیدات نرم افزاری واقعی به عنوان مطالعات موردی است. این مطالعات موردی از سوی ساختار پایگاه داده و مجموعه‌‌‌ای از ابزار به منظور جمع‌‌‌آوری و انتقال داده به آن مورد پشتیبانی قرار می گیرد.

یک مطالعه قانونی برای ارزیابی مبنای قانونی مربوط به تایید کشورهای مختلف کمیسیون اروپایی باشد.