دانلود کامل ترین جزوه پایداری سازه ها

جزوه تایپ شده پایداری سازه ها

دانلود فایل

دکتر غلامپور تیموشنکو خلاصه کتاب پایداری سازه ها دکتر کاوه ازهری چاجس دکتر شیدایی پیام نور کارن خانلری مجید برقیان سیروس غلامپور

()، ً “[طرح ها]، ” : :

: ()
: ()
: ()
: ()
: (() )
: ()
: ()
: ()
: ()
: ()
(): ً، ً در ارزیابی تاثیر طراحی زیبایی را پیشنهاد می کنند:

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

پایداری سازه ها

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

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

5-3-23 واحدهای کد منبع
نظریه Halstead در مورد “علم نرم افزار”، اولین “قوانین” تحلیلی را برای نرم افزار رایانه ارائه کرد. Halstead با استفاده از مجموعه ای از اقدامات اولیه که ممکن است پس از تولید کد یا برآورد پس از اتمام طراحی به دست آید، قوانین کمی را برای توسعه نرم افزار رایانه تعیین کرد.
این معیارها عبارتند از:
n1 = تعداد عملگرهای متمایز که در یک برنامه ظاهر می شوند
n2 = تعداد عملوندهای متمایزی که در یک برنامه ظاهر می شوند
N1 = تعداد کل وقایع اپراتور
N2 = تعداد کل وقایع عملوند
Halstead از این معیارهای اولیه برای توسعه عبارات طول کلی برنامه، حداقل حجم بالقوه جزوه پایداری سازه ها یک الگوریتم، حجم واقعی (تعداد بیت های مورد نیاز برای تعیین برنامه)، سطح برنامه (اندازه پیچیدگی نرم افزار)، سطح زبان (ثابت برای یک زبان معین)، و ویژگی های دیگر مانند تلاش برای توسعه، زمان توسعه و حتی تعداد پیش بینی خطاها در نرم افزار، استفاده می کند. Halstead نشان می دهد که طول N را می توان از رابطه زیر به دست آورد:
N = n1 log2 n1 + n2 log2 n2
و حجم برنامه را می توان به صورا زیر تعریف کرد:
V = N log2 (n1 + n2)
لازم به ذکر است که V با زبان برنامه نویسی متفاوت خواهد بود و نشان دهنده حجم اطلاعات (بر حسب بیت) مورد نیاز برای تعیین یک برنامه است. از لحاظ نظری، برای یک الگوریتم خاص باید حداقل حجمی وجود داشته باشد. پایداری سازه ها نسبت حجم L را به عنوان نسبت حجم فشرده ترین شکل یک برنامه به حجم برنامه واقعی تعریف می کند. در واقع، L همیشه باید کمتر از 1 باشد. از نظر اقدامات اولیه، نسبت حجم می تواند به صورت زیر بیان شود:
L = 2 ÷ n1 × n2 ÷ N2
کارهای Halstead قابل تأیید تجربی است و تحقیقات زیادی توسط او برای بررسی علم نرم افزار انجام شده است که بحث در مورد آن ها از حوصله این کتاب خارج است.

4-23 واحدها برای آزمایش
واحدهای آزمایش به دو دسته کلی تقسیم می شوند: (1) واحدهایی که تعداد احتمالی آزمون های مورد نیاز در سطوح مختلف آزمایش را پیش بینی می کنند و (2) واحدهایی که بر پوشش آزمون برای یک جزء معین تمرکز می کنند. اکثر واحدهای پیشنهادی برای آزمایش، بر فرایند آزمایش متمرکز هستند، نه ویژگی های فنی خود آزمایش ها. به طور کلی، آزمایش کنندگان باید به تجزیه و تحلیل، طراحی و ایجاد واحدهای کد متکی باشند تا آن ها را در طراحی و اجرای موارد آزمایش، راهنمایی کنند. معیارهای طراحی معماری اطلاعاتی در مورد سهولت یا دشواری آزمایش ادغام و نیاز به نرم افزارهای تست تخصصی (به عنوان مثال، استاب و درایور) ارائه می دهد. پیچیدگی سیکلوماتیک (یک معیار طراحی در سطح جزء) در هسته آزمایش مسیر اصلی قرار دارد، و یک روش طراحی مورد آزمایشی است که در فصل 19 مطرح شده است. علاوه بر این ، پیچیدگی سیکلوماتیک می تواند برای هدف قرار دادن ماژول ها به عنوان کاندیدای آزمایش واحد گسترده، مورد استفاده قرار گیرد. ماژول هایی با پیچیدگی سیکلوماتیک بالا، بیشتر از ماژول هایی با پیچیدگی کمتر، مستعد خطا هستند. به همین دلیل، کشف خطاها در چنین ماژول هایی قبل از ادغام آن ها در یک سیستم، به تلاش بیشتری نیاز دارد. تلاش آزمایش را می توان با استفاده از واحدهای اندازه گیری شده از اندازه گیری های Halstead (بخش 23.3.5) برآورد کرد. با استفاده از تعاریف مربوط به حجم برنامه V و سطح برنامه PL، نیتجه کارهای Halstead e را می توان در روابط زیر خلاصه کرد:
PL = 1 ÷ (n1∕2)(N2∕n2)
e = V ÷ PL
درصد تلاش کلی آزمایش برای اختصاص به یک واحد k را می توان با استفاده از رابطه زیر برآورد کرد:
درصد تلاش آزمایش (k)= e(k) ÷ Σ e(i)
در رابطه فوق، جایی که e (k) برای ماژول k محاسبه می شود و جمع در مخرج، مجموع تلاش پایداری سازه ها در تمام ماژول های سیستم است.
آزمایش OO می تواند بسیار پیچیده باشد. واحدها می توانند به شما در هدف قرار دادن منابع آزمایش در موضوعات، فیلمنامه ها و بسته طبقاتی که احتمالاً بر اساس ویژگی های اندازه گیری شده هستند، کمک کنند. جزوه پایداری سازه ها طراحی OO ذکر شده در بخش 23.3.3، نشان دهنده کیفیت طراحی هستند. آن ها همچنین میزان تلاش کلی آزمایش مورد نیاز برای تمرین سیستم OO را نشان می دهند. بایندر مجموعه وسیعی از واحدهای طراحی را پیشنهاد می کند که تأثیر مستقیم بر “تست پذیری” سیستم OO دارند. این واحدها، جنبه های محصور سازی و وراثت را در نظر می گیرند.
عدم انسجام در روش ها (LCOM): هرچه ارزش LCOM بیشتر باشد، برای اطمینان از عدم ایجاد عوارض جانبی توسط روش ها، باید حالات بیشتری مورد آزمایش قرار گیرند.
درصد عمومی و تحت حفاظت (PAP): ویژگی های عمومی از طبقات دیگر به ارث رسیده است و بنابراین برای آن طبقات، قابل مشاهده هستند. ویژگی های محافظت شده برای روش های فرعی، قابل دسترسی هستند. این واحد، درصد ویژگی های طبقه عمومی یا محافظت شده را نشان می دهد. مقادیر بالای PAP احتمال عوارض جانبی را در بین طبقات افزایش می دهد؛ زیرا ویژگی های عمومی و محافظت شده، منجر به پتانسیل بالایی برای اتصال می شود. آزمایشات باید به گونه‌ای طراحی شوند که از عدم ایجاد عوارض جانبی این چنینی، اطمینان حاصل شود.
دسترسی عمومی به اعضای داده ((PAD: این واحد، تعداد طبقاتی (یا روش هایی) را نشان می دهد که می توانند به ویژگی های طبقه دیگر دسترسی داشته باشند، که این نقض محصورسازی است. مقادیر بالای PAD منجر به عوارض جانبی در بین کلاسها می شود. آزمایشات باید به گونه‌ای طراحی شوند که از عدم ایجاد عوارض جانبی این چنینی، اطمینان حاصل شود.
تعداد طبقات ریشه‌ای (NOR): این واحد، شمارش سلسله مراتب طبقه متمایزی است، که در مدل طراحی شرح داده شده است. برای هر طبقه ریشه‌ای و سلسله مراتب طبقه مربوطه، باید مجموعه‌ای از آزمایشات توسعه داده شود. با افزایش NOR، تلاش برای آزمایش نیز افزایش می یابد.
Fan-in (FIN) (تعداد ورودی هایی که می تواند به یک مدار، وصل شود): هنگام استفاده از این واحد در زمینه OO، fan-in در سلسله مراتب وراثت، نشان دهنده وراثت های متعدد است. FIN> 1 نشان می دهد که یک طبقه، ویژگی ها و عملیات خود را از بیش از یک طبقه ریشه به ارث می برد. در صورت امکان، باید از FIN> 1 اجتناب شود.
تعداد فرزندان (NOC) و عمق درخت وراثت (DIT): همانطور که در فصل 18 اشاره کردیم، روش های فوق طبقاتی، باید برای هر زیر طبقه، مجدداً آزمایش شوند.

5-23 واحدهای نگهداری
همه معیارهای نرم افزاری معرفی شده در این فصل را می توان برای توسعه نرم افزارهای جزوه پایداری سازه ها و نگهداری نرم افزارهای موجود استفاده کرد.
با این حال، واحدهایی نیز صراحتاً برای فعالیت های نگهداری طراحی شده اند. IEEE Std. 982.1 2005 [پایداری سازه ها ] یک شاخص بلوغ نرم افزار (SMI) را پیشنهاد می کند که نشانه ای از پایداری یک محصول نرم افزاری (بر اساس تغییراتی که برای هر انتشار محصول رخ می دهد) ارائه می دهد. به مطالب زیر توجه کنید:
MT = تعداد ماژول ها در نسخه فعلی
Fc = تعداد ماژول های تغییریافته در نسخه فعلی
Fa = تعداد ماژول های اضافه شده به نسخه فعلی
Fd = تعداد ماژول های نسخه قبلی که در نسخه فعلی حذف شده اند.
شاخص بلوغ نرم افزار به روش زیر محاسبه می شود:
SMI = MT − (Fa + Fc + Fd) ÷ MT
با نزدیک شدن SMI به 1.0، محصول شروع به تثبیت می کند. SMI همچنین ممکن است به عنوان واحدی برای برنامه ریزی فعالیت های نگهداری نرم افزار استفاده شود. میانگین زمان تولید یک محصول نرم افزاری را می توان با SMI ارتباط داد و مدل های تجربی برای نگهداری را می توان توسعه داد.

6-23 واحدهای فرآیند و پروژه
واحدهای فرآیند، در تمام پروژه ها و در بازه های زمانی طولانی جمع آوری می شوند و هدف آن ها ارائه مجموعه ای از شاخص های فرایند است، که منجر به بهبود طولانی مدت فرآیند نرم افزار می شود (فصل 28). معیارهای جزوه پایداری سازه ها به مدیر پروژه نرم افزاری این امکان را می دهد که: (1) وضعیت پروژه در حال انجام را ارزیابی کند، (2) خطرات احتمالی را ردیابی کند، (3) مناطق مشکل ساز را قبل از “بحرانی” شدن کشف کند. (4) جریان کار یا وظایف را تنظیم کند، و (5) توانایی تیم پروژه در کنترل کیفیت محصولات نرم افزاری را ارزیابی کند. اقداماتی جمع آوری شده توسط تیم پروژه و تبدیل شده به واحدها برای استفاده در طول پروژه، می توانند به مسئولین بهبود فرایند نرم افزار نیز منتقل شوند. به همین دلیل، بسیاری از معیارهای یکسان، در دو حوزه فرآیند و پروژه استفاده می شوند. برخلاف واحدهای فرآیند نرم افزاری مورداستفاده برای اهداف استراتژیک، اقدامات پروژه نرم افزاری، تاکتیکی هستند. یعنی واحدهای پروژه و شاخص های به دست آمده از آن ها، توسط یک مدیر پروژه و یک تیم نرم افزاری برای تطبیق جریان کار پروژه و فعالیت های فنی مورد استفاده قرار می گیرند.تنها راه منطقی برای بهبود هر فرآیند، اندازه گیری ویژگی های خاص فرایند، ایجاد مجموعه ای از واحدهای هدفمند بر اساس این ویژگی ها و سپس استفاده از واحدها برای ارائه شاخص هایی است که منجر به استراتژی بهبود می شود (فصل 28).

دانلود رایگان خلاصه کتاب پایداری سازه ها PDF

تصویر 3-23
اما قبل از بحث در مورد واحدهای نرم افزاری و تأثیر پایداری سازه ها در بهبود فرایند نرم افزار، توجه به این نکته ضروری است که فرآیند تنها یکی از تعدادی از “عوامل قابل کنترل در بهبود کیفیت نرم افزار و عملکرد سازمانی” است. با توجه به شکل 23.3 ، فرآیند، در مرکز مثلثی قرار دارد که سه عامل بسیار مؤثر بر کیفیت نرم افزار و عملکرد سازمانی را به یکدیگر متصل می کند.
مهارت و انگیزه افراد، مؤثرترین عامل در کیفیت و عملکرد، نشان داده شده اند. پیچیدگی محصول می تواند تأثیر قابل توجهی بر کیفیت و عملکرد تیم داشته باشد. فناوری (یعنی روش ها و ابزارهای مهندسی نرم افزار) کمربوط به این فرایند نیز مؤثر است. علاوه بر این، مثلث فرایند در حلقه ای از شرایط محیطی وجود دارد که شامل محیط توسعه (به عنوان مثال، ابزارهای نرم افزاری یکپارچه)، شرایط تجاری (به عنوان مثال، مهلت ها، قوانین تجاری) و ویژگی های مشتری (به عنوان مثال، سهولت ارتباط و همکاری) می شود.بنابراین شما تنها می توانید کارایی یک فرآیند نرم افزاری را به صورت غیر مستقیم اندازه گیری کنید.یعنی شما مجموعه ای از جزوه پایداری سازه ها را بر اساس نتایج قابل استخراج از فرآیند، استخراج می کنید. نتایج، شامل معیازهای خطاهای فاش شده قبل از انتشار نرم افزار، نقص های ارائه شده و گزارش شده توسط کاربران نهایی، محصولات کاری ارائه شده (بهره وری)، تلاش انسانی صرف شده، زمان تقویم مورد استفاده، زمان بندی مطابقت و سایر اقدامات است. همچنین می توانید با اندازه گیری ویژگی های وظایف خاص مهندسی نرم افزار، واحدهای فرایند را بدست آورید.
به عنوان مثال، می توانید تلاش و زمان صرف شده برای انجام فعالیت های حفاظتی و فعالیت های مهندسی نرم افزار عمومی که در فصل 1 شرح داده شده است را اندازه گیری کنید. اولین استفاده از واحدهای پروژه در اکثر پروژه های نرم افزاری، در حین برآورد رخ می دهد.واحدهای جمع آوری شده از پروژه های گذشته به عنوان مبنایی برای برآورد تلاش و زمان انجام کارهای نرم افزاری فعلی جزوه پایداری سازه ها می شود. با پیشرفت پروژه، اقدامات و زمان تقویم صرف شده، با برآوردهای اولیه (و برنامه پروژه) مقایسه می شود. مدیر پروژه از این داده ها برای نظارت و کنترل پیشرفت استفاده می کند. با شروع کار فنی، واحدهای دیگر پروژه اهمیت پیدا می کنند. نرخ تولید بر اساس مدل های ایجاد شده، ساعات بازبینی، نقاط عملکرد و خطوط منبع تحویل، اندازه گیری می شود. علاوه بر این، خطاهای کشف شده در طول هر اقدام مهندسی نرم افزار، پیگیری می شوند.همزمان با تبدیل نرم افزار از الزامات به طراحی، معیارهای فنی برای ارزیابی کیفیت طراحی و شاخص های مؤثر بر رویکرد تولید کد و آزمایش، جمع آوری می شوند.واحدهای پروژه، دو هدف را دنبال می کنند. برای به حداقل رساندن برنامه توسعه با اعمال تعدیلات لازم برای جلوگیری از تأخیرها و کاهش مشکلات و خطرات احتمالی، و ارزیابی کیفیت محصول به صورت مداوم و در صورت لزوم، اصلاح روش فنی برای بهبود کیفیت. با بهبود کیفیت، عیوب به حداقل می رسند و با کاهش تعداد نقص ها، میزان دوباره کاری مورد نیاز در طول پایداری سازه ها نیز کاهش می یابد. معیارهای فرآیند نرم افزاری می توانند مزایای قابل توجهی را به عنوان یک سازمان برای بهبود سطح کلی بلوغ فرآیند ارائه دهند. معیارهای فرآیند نرم افزاری می توانند مزایای قابل توجهی را به عنوان یک سازمان برای بهبود سطح کلی بلوغ فرآیند ارائه دهند.
گریدی یک “آداب معیارهای نرم افزاری” را پیشنهاد می کند که برای مدیران و متخصصین مسئول ایجاد برنامه اندازه گیری فرایند، مناسب است:
هنگام تفسیر داده های اندازه گیری، از عقل سلیم خود و حساسیت سازمانی استفاده کنید.
بازخوردی منظم برای افراد و تیم هایی که معیارها و واحدها را جمع آوری می کنند، ارائه دهید.
از واحدها برای ارزیابی افراد استفاده نکنید.
برای تعیین اهداف و واحدهای مشخصی که برای دستیابی به آن ها استفاده می شود، با متخصصان و تیم ها همکاری کنید.
هرگز از معیارها برای تهدید افراد یا تیم ها استفاده نکنید. داده های اندازه گیری نشان دهنده یک منطقه مشکل، نباید “منفی” تلقی شوند. این داده ها فقط یک شاخص برای بهبود فرایند هستند.
بدون در نظر گرفتن سایر واحدهای مهم، روی یک واحد مشخص وسواس نداشته باشید.
همانطور که کار یک سازمان با جمع آوری و استفاده از واحدهای فرآیند راحت تر می شود، استخراج از شاخص های ساده جای خود را به رویکرد دقیق تری می دهد که بهبود فرآیند نرم افزار آماری (SSPI) نامیده می شود. در اصل، SSPI از تجزیه و تحلیل جزوه بارگذاری سازه ها نرم افزار مورد استفاده برای جمع آوری اطلاعات در مورد تمام خطاها و نقایصی که هنگام توسعه و استفاده از یک برنامه، سیستم یا محصول، استفاده می کند.

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

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

7-23 اندازه گیری نرم افزار
اندازه گیری ها در دنیای فیزیکی را می توان به دو صورت طبقه بندی کرد: اندازه گیری مستقیم (به عنوان مثال، طول پیچ) و اندازه گیری غیر مستقیم (به عنوان مثال، “کیفیت” پیچ و مهره های تولید شده، که با شمارش مرجوعی هااندازه گیری می شود). واحدهای نرم افزاری را نیز می توان به طور مشابه طبقه بندی کرد. اندازه گیری های مستقیم فرآیند نرم افزار، شامل هزینه و تلاش اعمال شده است. معیارهای مستقیم محصول شامل خطوط کد (LOC) تولید شده، سرعت اجرا، اندازه حافظه و ایرادات گزارش شده در مدت زمان مشخص است. معیارهای غیر مستقیم محصول شامل عملکرد، کیفیت، پیچیدگی، جزوه پایداری سازه ها  و تلاش مورد نیاز برای ساخت نرم افزار، تعداد خطوط کد تولید شده و سایر اندازه گیری های مستقیم، نسبتاً آسان خواهد بود. با این حال، ارزیابی کیفیت و عملکرد نرم افزار یا کارآیی یا قابلیت نگهداری آن دشوارتر است و فقط به طور غیر مستقیم قابل اندازه گیری است. ما دامنه واحدهای نرم افزار را به واحدهای فرایند، پروژه و محصول تقسیم کرده ایم و اشاره کردیم که واحدهای محصول که منحصر به فرد هستند، اغلب برای ایجاد واحدهای پروژه عمومی برای یک تیم نرم افزاری، ترکیب می شوند. سپس واحدهای پروژه برای ایجاد واحدهای فرایند عمومی برای سازمان نرم افزار به طور کلی، ادغام می شوند. اما چگونه یک سازمان، واحدهای به دست آمده از افراد یا پروژه های مختلف را ترکیب می کند؟ برای توضیح ، یک مثال ساده را در نظر بگیرید. تمام خطاهای کشف شده در طول فرآیند نرم افزار، در دو تیم مختلف پروژه، ثبت و دسته بندی می شوند. سپس اقدامات فردی برای توسعه اقدامات گروهی ترکیب می شوند. تیم A قبل از انتشار 342 خطا ؟ /() : ()