یه قول

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

جمله قصار

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

Robert Dunn

مهندسي نرم افزار و روش هاي تست در ويژوال استوديو 2005

مقدمه

ايجاد و توسعه نرم افزار، نيازمند رعايت كليه اصول و ساختارهاي مهندسي است كه در مبحث مهندسي نرم افزار مطرح مي شود. يكي از مهم ترين دروس تخصصي كه محصلان رشته مهندسي كامپيوتر ملزم به گذراندن آنند، مهندسي نرم افزار (۱) و (۲) است. در اين درس نحوه ايجاد و توسعه نرم افزار به روش علمي مورد بحث و بررسي قرار مي گيرد.

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

از مهندسي نرم افزار نترسيد!

شايد شما با مهندسي نرم افزار آشنا نباشيد و يا حتي اسم آنرا هم نشنيده باشيد، در اين صورت نترسيد و به مطالعه اين مقاله ادامه دهيد.

ويژوال استوديو و مهندسي نرم افزار

در اين مقاله سعي مي كنيم خيلي ساده و گويا جنبه هايي از ابزار مهندسي نرم افزار موجود در ويژوال استوديو را معرفي كنيم.علاقمندان براي كسب اطلاعات بيشتر مي توانند به كتاب هاي موجود در اين زمينه مراجعه كنند.

در دنياي امروزه كه مبتني بر دانش و تكنولوژي است،هيچ كاري بدون طرح و نقشه قبلي انجام نمي شود.توسعه و ايجاد نرم افزار هم از اين مقوله مستثنا نيست تا جايي كه در اكثر موارد بدون طرح ريزي مهندسي يك پروژه نرم افزاري اغلب به شكست مي انجامد.در اين راستا قبل از توليد، تمامي جزئيات طراحي و پياده سازي نرم افزار را با دياگرام هايي نمايش مي دهند كه به مثابه نقشه در ساختن يك بنا محسوب مي شود.در اين ميان Class Diagram در مبحث متدلوژي شي گرا (MethodologyObject Oriented) مهم ترين دياگرامي است كه طراحي و ايجاد آن ضروري و الزامي است.

Class Diagram چيست؟

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

Class Diagram : دياگرامي است كه تمامي كلاس هاي موجود در يك پروژه را به همراه محتويات كلاس ها و ارتباط بين آن ها نشان مي دهد.

محتويات يك كلاس عبارت است از:

· متغيرها

· خصيصه ها

· توابع

ارتباط بين كلاس ها مي تواند شامل موارد زير باشد :

· Inheritance ( ارث بري ) : يكي از مفاهيم برنامه نويسي است كه در آن كلاس جديد ( فرزند ) از كلاس موجود (پدر) تمامي ويژگي ها را به ارث مي برد.

· Association ( همكاري ) : عبارت از آن است كه يك كلاس، از كلاس ديگري براي مقاصد خود استفاده كند.

حال كه مفهوم Class Diagram بيان شد،امكانات موجود در ويژوال استوديو را بررسي مي كنيم.براي كار با كلاس دياگرام، ويژوال استوديو امكانات زير را در اختيار قرار مي دهد:

همانطور كه در شكل مشاهده مي شود، امكان اضافه كردن كلاس، نوع داده شمارشي (Enum)، واسط (Interface)، كلاس انتزاعي (Abstract Class)، ساختار (Struct) و نماينده (Delegate) به كلاس دياگرام وجود دارد.همچنان ارتباط بين كلاس ها را توسط دو نوع مفهوم Inheritance ( ارث بري ) و Association ( همكاري ) مي توان نشان داد.در نهايت مي توانيد توضيحات خود را به شكل Comment در هر جاي لازم به كلاس دياگرام اضافه كنيد.

نحوه توليد كلاس دياگرام براي پروژه ها

توليد كلاس دياگرام در هر مرحله از كار امكان پذير است.اما اصولا! قبل از هر گونه پياده سازي بايد آن را توليد كرد.

براي توليد كلاس دياگرام، مسير Project > Add New Item… را دنبال و از ديالوگ ظاهر شده آيتم Class Diagram را انتخاب كنيد ( اسم دياگرام را به دلخواه وارد كنيد ) سپس بر روي دكمه Add كليك كنيد تا كلاس دياگرام اضافه شود.

پس از اضافه شدن كلاس دياگرام، مي توانيد از تمامي ابزارهاي آن استفاده كنيد.براي بررسي كامل تر و جامع تر، پروژه اي را در نظر بگيريد كه شامل كلاس هاي زير است:

براي ايجاد كردن كلاس دياگرام پروژه بالا، بر روي پروژه كليك راست كرده گزينه View Class Diagram را انتخاب مي كنيم:

با اين انتخاب، كلاس دياگرام به شكل زير ايجاد خواهد شد:

با اضافه شدن كلاس دياگرام به پروژه، منوي Class Diagram نيز به مجموعه منوهاي ويژوال استوديو اضافه مي گردد:

با استفاده از اين منو به ترتيب مي توانيد :

· عضو جديدي به كلاس دياگرام ( اعم از كلاس، واسط ، داده شمارشي و ... ) اضافه كنيد. (Add)

· دياگرام را به اندازه مطلوب تغيير دهيد (Zoom).

· اعضا را به شكل دلخواه دسته بندي كنيد.(Group Members)

· فرمت نمايش اعضا را تغيير دهيد.(Change Members Format)

· عرض اشكال را تنظيم كنيد.(Adjust Shapes Width)

· دياگرام را با فرمت تصوير ذخيره كنيد.(Export Diagram as Image)

اگر بخواهيد اعضاي كلاس را مشاهده كنيد بايد با كليك ماوس آنرا باز كنيد (Expand) در اين صورت اعضاي كلاس اعم از متغيرها و توابع قابل مشاهده خواهند بود:

پس از انتخاب كلاس مورد نظر، در صورتي كه منوي Class Diagram را دوباره بررسي كنيد، خواهيد ديد كه گزينه هايي به آن اضافه شده اند:

با استفاده از موارد اضافه شده به منوي Class Diagram، مي توان عمليات بيشتري را بر روي كلاس انجام داد از جمله:

· عضو جديد شامل تابع ( سازنده – نابود كننده )، متغير، پراپرتي و رخداد به كلاس اضافه كرد. (Add)

· يك واسط از كلاس انتخاب شده ايجاد كرد يا نام اعضاي آنرا تغيير داد.(Refactor)

· يك كلاس انتزاعي را پياده سازي كرد يا اعضاي كلاس را سرباگذاري نمود (IntelliSense)

تست كلاس ها با استفاده ازابزارهاي كلاس دياگرام

يكي از توانايي هاي فوق العاده اي كه كلاس دياگرام در اختيار شما قرار مي دهد اين است كه شما مي توانيد از هر كلاس، نمونه سازي كرده و توابع آن را براي تست فراخواني كنيد!

براي نمونه سازي از كلاس مورد نظر، بر روي كلاس كليك راست كرده، گزينه Create Instance را انتخاب كنيد. سپس با كليك بر روي يكي از سازنده هاي موجود، عمل نمونه سازي از آن كلاس را انجام دهيد. (مانند شكل زير)

اگر تابع شما آرگومان پذير باشد، طي ديالوگي مانند شكل، مي توانيد مقادير مورد نظر را وارد كنيد:

پس از وارد كردن آرگومان هاي تابع سازنده، بر روي OK كليك كنيد تا آبجكت مورد نظر ساخته شود:

حال مي توانيد تمامي توابع نمونه ساخته شده را فراخواني كنيد.براي اين منظور بر روي آبجكت نمونه كليك راست كرده از منوي Invoke Method، توابع مورد نظر را فراخواني كنيد:

به عنوان مثال، فراخواني تابع ValidCreditCardNumber را با آرگومان "002524" در نظر بگيريد.نتيجه حاصل در ديالوگ شكل زير نشان داده شده است:

دقت كنيد كه نتيجه تست تابع موفقيت آميز بوده و مقدار بازگشتي true مي باشد.در صورتي كه لازم باشد مي توانيد مقدار بازگشتي را با وارد كردن نام متغير مربوطه براي عمليات ديگر ذخيره كنيد.

جالب است بدانيد كه در هر لحظه مي توان وضعيت نمونه ساخته شده را بررسي كرد.براي اين منظور كافيست كه اشاره گر ماوس را بر روي نمونه ساخته شده هدايت كنيد تا اطلاعات آن مانند شكل زير در اختيار شما قرار گيرد:

اين گزينه شما را قادر مي سازد كه صحت مقادير اعضاي كلاس را مورد بررسي قرار دهيد.

همانطور كه مي دانيد براي فراخواني توابع استاتيك نيازي به نمونه سازي از كلاس نيست.براي اين منظور بر روي كلاس كليك راست كرده، با انتخاب گزينه Invoke Static Method، توابع مورد نظر را به راحتي فراخواني كنيد.

در پايان يادآور مي شويم كساني كه نيازمند ابزارهاي تست قوي تر باشند، مي توانند از امكانات نسخه Team Edition ويژوال استوديو استفاده كنند كه امكانات تست بيشتري را در اختيار توسعه دهنگان و توليد كنندگان نرم افزار قرار مي دهد.

منبع : http://www.persiadevelopers.com

debugger یعنی چه؟!!!

هنر اشکال زدایی

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

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

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

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

قرآیند اشکال زدایی یکی از این دو نتیجه را به دنبال دارد:

۱-علت، یافت شده و اصلاح می شود، یا 2- متاسفانه علت یافت نمی شود.

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

چرا اشکال زدایی این چنین مشکل است؟

در تمام احتمالات، پاسخ به این سوال بیشتر به روانشناسی انسانی مربوط می شود تا تکنولوژی نرم افزار . به هر حال، چند خصوصیت اشکالات، کلید هایی را فراهم می نمایند:

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

۲-علامت ممکن است وقتی که خطای دیگری اصلاح می گردد به طور موقت ناپدید شود.

۳-علامت ممکن است توسط هیچ خطایی ایجاد نشده باشد.(برای مثال عدم دفت در نتیجه گرد کردن یک عدد)

۴-علامت ممکن است ناشی از خطای انسانی باشد که به راحتی قابل پیگیری نیست.

۵-علامت ممکن است در نتیجه ی مشکلات زمانبندی به وجود آید ، به جای ای که در اثر مشکلات پردازش پدید آمده باشد.

۶-ممکن است ایجاد مجدد شرایط ورودی با دقت، مشکل باشد.(برای مثال ، یک ک اربرد بلادرنگ که در آن ترتیب ورودی نامشخص است.)

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

۸-علامت ممکن است در اثر عللی باشد که در چند task که بر روی پردازنده های متفاوت اجرا می شوند توزیع شده باشد.

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

ملاحظات روانشناسی

بدبختانه، شواهدی وجود دارد که به نظر می رسد توانایی اشکال زدایی، جزء توانایی فرای انسان است. برخی افراد آنرا به خوبی انجام می دهند و برخی دیگر خیر. اگر چه شواهد آزمایش شده در اشال زدایی ، برای تقسیر آزاد می باشد، تفاوت های زیاد در توانایی اشکال زدایی برای برنامه نویسهایی که تجربه و آموزش یکاسن داشته اند مشاهده شده است. در واقع چند Debugger  که آموزش های یکسانی دیده اند نظرات متفاوتی در در مورد یک پروژه واحد ارائه خواهند داد.

در رابطه با جنبه های انسانی اشکال زدایی، shneiderman می گوید:

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

اگر چه ممکن است فراگیری اشکال زدایی مشکل باشد، ولی چند روش برای حل مسئله پیشنهاد می شود.

شیوه های اشکال زدایی

علیرغم شیوه ای که به کار گرفته می شود، اشکال زدایی یک هدف پوشش دهنده دارد: یافتن و تصحیح علت خطای نرم افزار.

این هدف با ترکیب ارزیابی سیستماتیک،ادراک و شانس بدست می آید. Bradley شیوه اشکال زدایی را اینگونه توصیفی می کند.

اشکال زدایی، کاربردی مشخص از روشی علمی است که در طول 2500 سال توسعه یافته است.مبنای اشکال زدایی، یافتن مبدا مشکل (علت) باتقسیم دودویی، از طریق کار فکری می باشد که مقادیر جدید را برای بررسی پیش بینی میکند.

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

در حالت کلی سه دسته بندی برای روش های اشکال زدایی پیشنهاد می شود

۱-اتفاقی                   2-عقب گردی                 3-حذف علت

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

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

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

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

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

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

Van Vleck سه سوال ساده را پیشنهاد می کند هک هر مهندس نرم افزار باید قبل از انجام اصلاحاتی که باعث حذف علت خطا می شود بپرسد:

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

۲-چه خطای دیگری ممکن است در اثر عمل اصلاحی که در حال انجام آن هستیم ایجاد شود؟ قبل از انجام تصحیح ،کد مبدا باید ارزیابی شد تا کوپل منطق و ساختمان داده ها مشخص گردد. اگر اصلاح در یک بخش با کوپل زید در برنامه انجام شود ، ملاحظه خاصی باید در زمان هر تغییر صورت گیرد.

۳-در مرحله اول، چه کاری باید انجام می شد تا از این خطا جلوگیری می شد؟ این سوال ، اولین مرحله به سمت ایجا ی کروش آماری تضمین کیفیت نرم افزار است. اگر فرآیند همانند محصول اصلاح شود، خطا از برنامه جاری حذف می شود و ممکن است از تمام برنامه های بعدی نیز حذف گردد.

منبع : مهندسی نرم افزار .... نویسنده: راجر اس پرسمن ..... مترجم : محمد مهدی سالخورده

فصل هجده ... صفحات 440-443

پی نوشت : اطلاعات مفیدی در این سایت موجود می باشد...www.bugnet.com 

Source: Software engineering ….. Author : Preman Rager S.

  Translated By:Salkhorde MohammadMehdi 

جمله قصار

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

مهندسي هزينه

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

در اينجا به مهندسي هزينه مي پردازيم!

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

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

علائم شدت برداشت‌هاي نادرست، زماني به‌اوج مي‌رسد که شنيده مي‌شود،"مهندسي هزينه نوعي بازنگري طراحي است و مشخص نيست که چه چيز آن را متفاوت و يکتا کرده است."‌ اين جمله نشان مي‌دهد که از نظر بسياري افراد هيچ گونه تفاوتي ميان‌اين دو مفهوم وجود ندارد.

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

عدم مرزبندي ميان‌اين دو مفهوم، با موارد و علت‌هاي زير مرتبط باشد:

1. مهندسي هزينه، براي افراد ناآشنا با مفاهيم آن بدرستي تشريح نشده است.

2. مخاطبان، روش مهندسي هزينه را نمي‌شناسند و آن را بدرستي درک نکرده‌اند.

3. افراد به‌واسطه تجربيات ناموفق قبلي، درباره مهندسي هزينه پيش داوري‌هاي درستي دارند.

4. ترس طبيعي انسان از تغييرات و هوشياري در برابر هر روش يا محصول جديد و ناشناخته.

 

اهميت مسئله

منشاء يکي از بزرگترين برداشت‌هاي نادرست، به‌اين باور باز مي‌گردد که: «روش مهندسي هزينه براي اصلاح اشتباهات به‌کار گرفته مي‌شود.» و بر همين مبنا، در برابر آن مقاومت شده و يا موضع دفاعي اتخاذ مي‏شود. ‌اين برداشت را مي‌توان با تشريح‌اين نکته که روش ارزش، فرايندي است که هر کس مي‌تواند و بايد در کارهاي معمول و روزمره آن را به‌کار ببرد، اصلاح کرد. افراد بايد به‌اين باور برسند که متدولوژي هزينه، نوعي فرايند تصميم‌سازي بسيار کارامد است که به‌طور کامل آزموده شده و بسيار قابل اعتماد است. همچنين، ضروري است که‌اين آگاهي پديد‌ايد که مي‌توان با آموختن و پيروي از قواعد‌اين روش، از تکرار تجربه‌هاي ناگوار پيش‏گيري کرد.

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

از1960 به‌بعد، روش هزينه در بسياري از پروژه‌هاي عمراني‌ سازمان‌هاي دولتي به‌کار گرفته شده‌ و با توسعه و پيشرفت متدولوژي، ميزان صرفه‏جويي نيز افزايش يافته است. هم‌اکنون، روش ارزش در مسير تشويق کاربرد ابتکارات و خلاقيت‌ها براي دستيابي به‌بهبود طرح، صرفه‌جويي و افزايش ارزش، در حال پيشرفت و رشد است.

به‌عنوان نمونه، طرح اوليه ارائه شده از سوي اداره احياي زمين (USBR) براي سد "Hungry Hors" اجرايي، اما بسيار دشوار و نيازمند فناوري خاص بود. طي مطالعه مهندسي هزينه که در مورد‌اين پروژه خاص صورت گرفت، راه حلي ارائه شد که منجر به‌40 درصد صرفه جويي در مقايسه با طرح اوليه شد.‌اين امر نشان‏دهنده پتانسيل بالاي بهبود در خلال مطالعات هزينه است.

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

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

با توجه به‌اين نكته که ارزش اضافي پديدآمده براي پروژه/ محصول/ سيستم، پس از مطالعات هزينه معمولاً از هزينه مطالعات بيشتر است، دراکثر مواقع، نتايج مطالعات هزينه، اعتبار خود را تأمين مي‌کند. به‌طور معمول شرکت‌ها و دولت‌ها را مشکل مجزابودن محل تأمين اعتبار مطالعات طراحي از اعتبارات اجرايي (ساخت) رنج مي‌برند. متأسفانه در اکثر موارد، بهاي مطالعات هزينه از محل بودجه مطالعات طراحي تأمين مي‌شود، در حالي که صرفه جويي واقعي در مرحله ساخت روي مي‌دهد. در مدت دو سال، اداره احياي زمين‌ ايالات متحده، هزينه تخميني مرحله طراحي مفهومي ‌حدود 80 پروژه را با هزينه واقعي اجراي آنها طي دو سال، مقايسه کرده است.‌اين بررسي نشان مي‌دهد که قيمت اجراي پروژه‌هاي مورد مطالعه، به‌طورميانگين 7 درصد کمترازهزينه تخميني اوليه بوده است. اما در پروژه‌هايي که از مطالعه هزينه مستثني شده‌اند، ميانگين بهاي اجرا 10 درصد بيش از تخمين‌هاي اوليه بوده است.

بررسي نتايج‌ اين مطالعه نشان مي‌دهد که عدم اجراي مطالعات هزينه به‌بهانه نبود منابع مالي، تنها به‌ضرر کارفرما بوده و منجر به‌اتلاف منابع مالي وي مي‌شود.

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

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

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

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

 

مهندسي هزينه

متدولوژي هزينه يک سيستم، طرح يا محصول و اجرا و مؤلفه‌هاي مرتبط با آنها را به‌منظور تعيين هزينه هر يک، تحليل مي‌کند. طي فرايند تحليل کارکرد، کارکردهاي زيبا شناختي و ثانويه، تعيين شده و بهاي هريک براورد مي‌شود.

مهندسي هزينه براي تعيين ميزان تحقق ارزش حقيقي، الزامات طراحي را مورد بررسي قرار داده و در پي تحقق کارکردهاي ضروري با حداقل هزينه کل است.

موارد زير را مي‌توان به‌عنوان وجوه مشخصه مهندسي هزينه برشمرد:

1. پيروي از برنامه کار مهندسي هزينه‌ طي اجراي مطالعات هزينه(آماده‌سازي،تحليل کارکرد، گردآوري ‌ايده‌ها، ارزيابي، توسعه، تهيه گزارش،ارائه گزارش و اجرا).

2. روش‌حل مسئله مهندسي هزينه را مي‌توان در فرايندهاي مديريتي، طراحي، صنعت ساخت، توليد، بهره‌برداري و نگهداري به‌کار گرفت.

3. در پروژه‌هاي صنعت ساخت، مهندسي هزينه را مي‌توان در تمامي‌مراحل دوره عمر پروژه به‌کار برد.

4. اجراي مطالعات مهندسي هزينه در مراحل اوليه (برنامه ريزي و طرزاحي مفهوم) منجر به‌بيشترين دستاورد، با صرف حداقل منابع مي‌شود.

5. تحليل و بررسي معيارهاي طراحي بر مبناي کارکردهاي پايه.

6. مرزبندي بين نيازها و خواسته‌ها و نيز تعيين زمينه‌هاي پر هزينه.

7. مقايسه سطح عملکرد مورد نياز با سطح عملکرد طراحي.

8. به‌چالش طلبيدن حاشيه‌هاي‌ايمني، احتمالات و ارزيابي آنها به‌منظور حصول اطمينان از قرار داشتن در حدود مورد نياز.

9. شناسايي زمينه‌هاي پرهزينه و خلق‌ايده‌ها و گزينه‌هايي براي ارزش بهتر.

10. اطمينان از قرارگرفتن هزينه‌هاي طرح ارائه شده در محدوده بودجه موجود، بدون کاهش سطح عملکرد و کيفيت مورد نظر.

11. بررسي نيازهاي استفاده کننده و منظور کردن آنها در تببين معيارهاي طراحي.

12. خلق‌ايده‌هايي که کارکردهاي مورد نياز را با حداقل هزينه کل (سرمايه گذاري + هزينه‌هاي بهره برداري و نگهداري) امکان پذير ‌سازد.

13. نقد و بررسي رويه‌هاي مرسوم طراحي و اجرا.

14. تعيين بهاي هر کارکرد و نه بهاي يک مؤلفه، تعيين ارزش (نيبت به‌هزينه) به‌عنوان مشخصه اصلي مهندسي هزينه.

15. بهبود هزينه با خلق‌ايده‌هاي جديد به‌گونه‌اي که تمامي‌جنبه‌هاي مرتبط نظير: اقتصاد، زمان، سهولت اجرا و عملکرد در نظر گرفته شوند.

مهندسي هزينه، رويکرد و روش سامان يافته‏اي است که مي‌توان آن را در مراحل اوليه طراحي به‌کار گرفت و در طول فرايند طراحي نيز در مواقع نياز از آن استفاده کرد، اما بايد توجه داشت که بيشترين دستاورد مهندسي هزينه به‌علت هزينه‌هاي‌اندک طراحي مجدد، از اجراي مطالعات در مراحل اوليه طراحي و تعيين محدوده پروژه حاصل مي‌شود. مهندسي هزينه را مي‌توان در ديگر مراحل طراحي نيز به‌کار برد و حتي در دوره اجرا نيز مي‌توان از ‌سازوکار VECP استفاده کرد. در هر حال، بايد توجه داشت که دستاوردها، ميزان بهبود و نيز بازگشت سرمايه حاصل از اجراي مطالعات در‌اين مرحله،‌اندک خواهد بود.

 

قواعد بازنگري فني طرح

همان گونه که از عنوان بازنگري فني طرح برمي‌آيد،‌اين فرايند نوعي مرور نقشه‌ها، مشخصات فني، معيارهاي طراحي و... براي حصول اطمينان از رعايت استانداردها و ‌آيين‌نامه‌هاي مهندسي و نيز عدم مغايرت‌هاست. همچنين، حفظ پيوستگي و ارتباط مؤلفه‌هاي طرح که توسط تخصص‌هاي مختلف ارائه شده‌اند، يکي از اهداف بازنگري فني است. دراکثرموارد، به‌هنگام بازنگري فني طرح به‌ کنترل ‌ايمني و صحت محاسبات اکتفا مي‌شود.

موارد زير مشخصات فرايند کلي بازنگري طرح را نشان مي‌دهند:

1. کنترل و حصول اطمينان از انجام تمامي ‌تعهدات قراردادي از سوي مشاور طراح.

2. کنترل نقشه‌ها با تاکيد بر موارد ذيل:

§ تطابق پلان معماري با نيازها و نبود ناسازگاري بين مؤلفه‌هاي مربوط به‌تخصص‌هاي مختلف.

§ کنترل محاسبات و مفروضات طراحي به‌منظور اطمينان از کفايت مطالعات.

§ کنترل طراحي شالوده با در نظر گرفتن ظرفيت باربري خاک بستر.

§ تاييد محاسبات سيستم‌هاي مکانيکي و تطابق آنها با‌ آيين‏نامه‌ها و ضوابط.

3. بررسي قابليت اجراي طرح و تطابق آن با‌آيين‏نامه‌ها و قوانين.

4. کنترل و تاييد تطابق اجزاي اسناد پيمان و اطمينان از پيوستگي مؤلفه‌ها.

5. کنترل تمامي ‌اسناد و مستندات براي کاهش تعداد خطاهاي احتمالي و نيز امکان ادعاي زيان از سوي پيمانکار.

6. کنترل تخمين هزينه.

7. فرايند بازنگري فني طرح، فرايندي معطوف به‌تخصص است.

8. بازنگري فني پس از تکميل طراحي اوليه (35 درصد پيشرفت طراحي) قابل اعمال است.

9. در‌اين فرايند، تحليل کارکرد انجام نمي‌شود.

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

 

ضرورت مطالعات مهندسي ارزش

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

پيش از پاسخ به‌پرسش مطرح شده، توجه به‌دو نکته زير ضروري است:

1. هر طرحي، نتيجه برداشت‌هاي طراح از نيازها، الزامات، خواسته‌ها و آرزوهاست. برداشت‌هاي طراح رابطه‌اي مستقيم با تجربه، محيط، سليقه، زمان و بودجه دارد. اگر مسئله مشابهي براي دو طراح متفاوت مطرح شود، به‌واسطه گرايش‌ها و سوابق ذهني مخالف، ممکن است دو طرح کاملاً متفاوت خلق شود.

2. چه کسي بايد در مورد طرح يا محصول اظهار نظر کند؟ کارفرما، طراح، استفاده کننده و يا...؟ معيار طراحي خوب چيست؟

براي پاسخگويي به‌اين موارد، به‌طور خلاصه برخي از دلايل لزوم انجام مطالعات مهندسي هزينه در مورد طرح ارائه شده، عبارتند از:

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

2. به‌طور طبيعي، طراح حساسيت خاصي نسبت به‌هزينه‌ها ندارد.

3. به‌طور معمول، تمرکز طراح معطوف به‌جنبه‌هاي زيبا شناختي طرح است .

4. سابقه فرهنگي و کاري طراح، امکان شناخت عميق فرهنگ، مقتضيات و نيازهاي جوامع ديگري را محدود مي‌سازد.

5. در صورتي که طراح بومي ‌منطقه نباشد، معمولاً استانداردها و مواد اوليه‌اي را مبناي طراحي قرار مي‌دهد كه نسبت به‌آنها شناخت کافي دارد.

6. تجربيات و تحصيلات طراح، ساختار و فرايند تفکر او را سامان مي‌دهد.

7. طراح، مجري نيازهاي کارفرماست و پاسخگويي درمورد ضرورت‌اين نيازها، مهارت و تلاشي خارج از محدوده اصلي وظايف اوست.

8. هر شخصي داراي تعبير خاص خود از کيفيت است. در بسياري موارد،‌ اين تعابير شخصي با يکديگر‌ سازگار نيستند.

9. تغييرات سريع فناوري و قديمي‌شدن برخي سيستم‌ها، نياز به‌راهکارهاي جديد را مطرح مي‌سازد.

10. بروزبودن فناوري و شناخت روش‌هاي بهتر اجراي پروژه‌ها و توليد محصولات، امري اجتناب ناپذير است.

11. لازمه تشخيص نياز واقعي، تخصص و تجربه‌اي بالاست که کارفرما و بهره بردار، معمولاً فاقد آن است.

اين موارد، تنها دلايل ضرورت کاربرد روش ارزش نيستند بلکه تصويري کلي از واقعيات را ارائه مي‌دهند.

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

فرم های اجرایی پروژه کارخانه

برای اینکه شما عزیزان ارتباط بیشتری با اطلاعاتی که دوست خوبم ارائه کرد آشنا شوید تیم ، تصمیم گرفت تا فرم هایی مشابه با فرم های بخش فروش مرکزی کارخانه در نظر بگیرد که به شرح ذیل می باشد:

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

بعد او باید اطلاعات مشتری را در فرم مربوط به خود با کلیک کردن روی دکمه ثبت اطلاعات مشتری انجام دهد تا به صفحه زیر وارد شود.

بعد او باید فرم پیش فاکتور/ حواله را پر کند که به صورت زیر خواهد بود.

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

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

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

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

و میتواند با فشردن گزینه ی چاپ نسخه ای را هم در اختیار مشتری قرار دهد.

تحلیل یک پروژه--فاز آلفا--

در این پست تیم چهار نفره ی ما می خواد یه پروژه کوچولو رو مورد بررسی قرار بده که البته هنوز اشکالات زیادی داره که ما اون رو در فاز آلفا و بتا رو وبلاگ می گذاریم .

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

البته می تونید تصاویر رو با کیفیت بالا از این قسمت دانلود کنید...

دانلود     حجم : 898.8 k

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

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

---

---

اين پروژه براي اتوماسيون شركتي تعريف شده است كه از نظر جغرافيايي، بخشي از آن در دفتر مركزي و بخشي از آن در كارخانه قرار دارد. مديريت فروش در دفتر مركزي، مديريت انبار ها و مديريت توليد در كارخانه قرار دارند. بخشي از مديريت فروش در كارخانه مستقر بوده و به نام مديريت فروش كارخانه ناميده مي شود. ارتباط بين كارخانه و دفتر مركزي از طريق مودم برقرار مي گردد

---ویژگی سیستم

...تصدیق هویت و اعتبار کاربران

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

...ثبت پیش فاکتور

پیش فاکتور در دفتر فروش در دفتر مرکزی با مراجعه مشتری ثبت می شود. کارشناس فروش، مسئول ثبت و ویرایش پیش فاکتور ها می باشد.

...ثبت حواله

پس از ثبت پیش فاکتور، به دنبال تایید مشتری و با ارائه پیش فاکتور، حواله برای وی صادر می گردد. این کار توسط کارشناس فروش انجام می گیرد. باید توجه داشت که سیستم ثبت حواله را از روز پیش فاکتور صادر شده انجام می دهدو

...تایید حواله

پس از ثبت حواله، حواله با تایید مدیر فروش رسمیت خواهد داشت.

...ارسال درخواست تولید یا صدور دستور بارگیری

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

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

---

---

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

در اولین گام از ترسیم ERD یا همان Enterprise Relation Dieagram باید انواع موجودیت های موجود در فضای مسئله را شناسایی نمود.

در این پروژه موجودیت های قسمت دفتر فروش مرکزی ؛ مشتری، کارشناس فروش ، مدیر فروش، نام کاربری و رمزعبور، پیش فاکتور/حواله و صورت حساب می باشد.

بعد در گام بعدی از ترسیم ERD باید ارتباط میان هر دو زوج با بررسی نمود. به عنوان مثال در شکل مربوطه ارتباط میان کارشناس فروش و صورتحساب از نوع صدور می باشد. همچنین ارتباط میان کارشناس فروش با مشتری و پیش فاکتور/حوله از نوع ثبت.

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

بعد از این گام باید درجه و الزام این ارتباط ها را بررسی نمود.

یاد آوری: درجه 1:1 درجه 1:n درجه m:n

در پروژه فوق هر مدیر فورش می تواند یک یا چند پیش فاکتور را ثبت کند که ارتباطی از نوع 1:n است و در ترسیم نمودار ERD معمولا ارتباط سمت N را با علامت > نشاند داده و ارتباط های سمت یک را با |

منظور از الزام هم الزام وجود این موجودیت است که یا O است یا |

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

بعد از بررسی تمام مراحل فوق می توان ER Diagram را ترسیم نمود.

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

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

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

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

در اینجا هم flag2 را در نظر گرفته ایم که اگر true شود یعنی این گزینه تیک خورده است و حواله مربوطه تایید شده است.

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

توجه کنید که در دنیای واقع اطلاعات مربوطه خیلی فراتر از پروژه مذکور خواهد بود و ما از عنوان کردن تمامی آنها خود داری نمود ه ایم .

---

---

بعد از ترسیم ERD باید DFD یا Data Flow Diagram را ترسیم نمود. نام دیگر این دیاگرام Bubble Chart هم هست چون در آن کلیه ارتباطات مابین موجودیت ها را در حباب هایی ترسیم می کنیم.

توجه کنید که علامت à مربوط بی علامت اطلاعات و داده ها می باشد. منظور ورودی و خروجی هاست.

در حباب ها هم فراید و توابعی که لازم می باشد را باید نگاشت.

توجه به اینکه که برای ترسیم نمودار جریان داده باید پروژه را به سطح هایی تقسیم نمود حتی پروژه ای به کوچکی!

کلیه سطح های مربوطه در تصاویر زیر مشخص می باشد. که مسلما با کمک گرفته از نمودار ER ترسیم شده است.

نکته: دیاگرام سطح اول به Context Diagram معروف است.

---

---

---

---

---

همانطور که مشاهده می کنید در این قسمت از pspec هم استفاده شده که در آن اطلاعاتی مربوط به flag های عنوان شده دقیق تر مورد بررسی قرارد گیرد.

در گام بعدی باید به مدلسازی رفتاری بپردازیم یعنی کلیه رفتار های سیستم را پیش بینی کرده و در نمودار STD عنوان کنیم . نمودار STD که تیم ما برای این پروژه در نظر گرفته است به شرح زیر می باشد.

نکته: خط سبز در نظر گرفته شده چون از طریق شبکه و دیتابیس مربوطه بود با رنگی متفاوت بررسی شده است تا ارتباط بین این دو بخش مشخص گردد.

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

---

---

پی نوشت: تحلیل گران گرامی در این مرحله می توانند خستگی رفع نمایند و ادامه کار را به طراحان محترم بسپارند...(البته اگر از مدل SSADM استفاده کنیم تحلیل گرا باید دیگه برن خونه هاشون و دنبال یه پروژه دیگه بگردن ولی چون SSADM دیگه یه جورایی از دور خارجه ما از روش Incremental استفاده می کنیم )

خــُب حالا دیگه نوبت به طراحان عزیز رسید. در این فاز باید 4 عمل اصلی و اساسی انجام شود:

1-طراحی داده ها

2-طراحی معماری

3-طراحی واسطه ها

4-طراحی رویه ها

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

انواع معماری داده ها

1-Data center: که در ان کلاینت ها به طور مستقل به داده ها دسترسی داشته و می توانند رو آن تغییراتی را انجام دهند – تمامی داده ها هم در بیتا بیس مربوطه قرار دارد.

2- جریان داده: منطق آن روی تبدیلات است. تبدیلات زیادی روی داده ها انجام می شود . دراین نوع معماری عملیات پردازش یا همان تبدیل بیشتری روی منطق الگوریتم می پردازد نه حذف و اظافه کردن داده ها روی دیتابیس. و اغلب در نرم افزار های علمی مورد استفاده قرار می گرید.

3-معماری لایه : که نرم افزار را به لایه های واسط،کاربرد،ارتباط با دیتابیس، و هسته تقسیم می نماید. که در هر کدام عملیات خاصی صورت می گیرد.

4-معماری شی گرا: بخش تشکیل دهنده برنامه اشیا هستند که این اشیا از طریق message passing با هم در ارتباط اند.

5-معماری call-return : در این مدل یک main در نظر میگیریم و زیر برنامه های فراخوانی را در آن در نظر میگیریم . کل DFD را در نظر گرفته و به بخش های وروردی، تبدیل(پردازش) و خروجی تقسیم می کنیم وبعد در نموداری ترسیم می نمانییم.

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

---

---

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

تا اینجای کار اگه همه چیز به خوبی پیش رفته باشه نوبت به استراحت تیم طراحی مرسه (البته کارهای بسیاری رو باید انجام می داد که مااز گفتنش فاکتور گرفتیم...)

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

امید وارم اطلاعات مربوطه به شما عزیزان کمک بکنه.

اگر سوالی بود بهم میل بزنید تا سوال رو برطرف کنیم...

موفق باشید...

امیدوارم بتونیم باز هم پروژه های بعدی رو براتون تشریح کنیم.

جمله قصار

بناهای جدید به عنوان نبض پروژه محسوب می شوند. اگر ضربان وجود نداشته باشد، پروژه مرده است.

Jim McCarthy

مركز معماري نرم افزار و سرويس مايكروسافت راه اندازي شد

شركت مايكروسافت مركز معماري جديد Software Plus Services را راه اندازي كرده است.اين وب سايت شامل منابع مورد نياز معماران و همه كساني است كه در تلاش اند تا مفهوم جديد Microsoft (Software Plus Services (S+S را دريابند.
طراح اين معماري Gianpaolo Carraro مدير معماري SaaS در تيم استراتژي معماري مايكروسافت مي باشد كه تعريف S+S را ارائه كرده است.او مي گويد:"Software Plus Services درك اين مفهوم مي باشد كه دنياي امروزي به سمت مدلي پيش مي رود كه در آن مفهوم نرم افزار روي دسكتاپ مانند روال چند سال اخير نخواهد بود.آينده تركيبي از راه حل هاي محلي به همراه سرويس هاي اينترنتي خواهد بود كه با يكديگر در تعامل اند."
معماري S+S توليد كنندگان مستقل نرم افزار را جلب خواهد كرد. همچنين فراهم كنندگان ميزباني سرويس ها به نحوه اجراي اين معماري اهميت خواهند داد.

خبر فوری........

نرم افزار مدیریت ریسک

با سلام

بنا به ضرورت ارزیابی و تجزیه و تحلیل ریسک شرکت های متعددی من جمله شرکت پریماورا و مایکروسافت و ... اقدام به تهیه این گونه از نرم افزارها نموده اند. از جمله مهمترین محصولات آنالیز ریسک پروِِژه نرم افزار پرت مستر و نیز مونت کارلو می باشد. یکی دیگر از این نرم افزارها که کاربردهای فراوانی از جمله آنالیز ریسک در بازار اروپا و آمریکا وجود دارد نرم افزار کریستال بال crystall ball است که آخرین ورِژن آن در سال ۲۰۰۷ ارایه شده است. ویرایش ۷.۲ این نرم افزار حجمی در حدود ۵۰ مگابایت دارد که به نرم افزار اکسل ۲۰۰۳ اضافه شده و کاربر می تواند با وارد کردن داده های خود ریسک های پروِژه را آنالیز کند. دوستانی که مایل هستند این نرم افزار را داشته باشند با آدرس میل زیر تماس بگیرند.

[e-mail]

استاندارد هاي توليد و توسعه نرم‌افزار

نظام مهندسي و استانداردهاي توليد و توسعه نرم‌افزار (نماتن) كه از سالها قبل ايده تدوين آن در نهادهاي انفورماتيكي كشور از جمله شوراي‌عالي انفورماتيك و انجمن شركتهاي انفورماتيك مطرح بود سرانجام در سال 1381 به مرحله اجرايي وارد شد و در نخستين فاز، استانداردهاي تعريف و ارجاع كار پروژه‌هاي نرم‌افزاري تدوين و ارائه گرديد.

اجراي فاز دوم نظام مهندسي و استانداردهاي توليد و توسعه نرم‌افزار (نماتن) در ادامه فاز اول اين نظام و با هدف تهيه استانداردهاي پايه‌اي توليد و توسعه نرم‌افزار در بهمن‌ماه 1382 از سوي شورايعالي انفورماتيك كشور به شركت مهندسي نرم‌افزاري گلستان واگذار گرديد.

به‌طور مشخص تهيه استانداردهاي زير در اين پروژه موردنظر بوده است:

· استاندارد طرح مديريت پروژه

· استاندارد طرح كيفيت پروژه

· استاندارد طرح مديريت پيكربندي

· استاندارد سند توصيف متدولوژي

· استاندارد طرح آزمون

· استاندارد طرح تصديق و صحه‌گذاري

· استاندارد طرح انتقال و تحويل نرم‌افزار

· استاندارد طرح ضمانت نرم‌افزار

· استاندارد طرح نظارت

هم‌چنين به‌منظور سهولت بهره‌برداري از اين استانداردها، گزارش‌هاي زير نيز به مجموعه فرآورده‌هاي پروژه افزوده شده است:

· درآمدي بر استانداردهاي توليد و توسعه نرم‌افزار

· واژه‌نامه

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

جمله قصار

مهندسین نرم افزار تا حد زیادی تعداد آزمایشهای لازم برای بازبینی برنامه را کم اهمیت میدانند.

Martyn Ould & Charles Unwin

 

تست نرم افزار-1

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

تست فقط می تواند وجود خطاها را نشان دهد نه عدم وجود آنها را

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

وارسی:  "آیا محصول درستی را می سازیم؟"

اعتبارسنجی: "آیا محصول را به درستی می سازیم؟"

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

استراتژی تست

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

استراتژی جعبه سیاه:

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

در یک استراتژی آزمایش جعبه سیاه ما عموما موارد زیر را مورد بررسی و آزمایش قرار می دهیم:

1.       بررسی اینکه سیستم نیازمندهای عملیاتی و غیر عملیاتی را تامین می کند یا نه.

2.       اعتبارسنجی ورودیها

3.       بررسی مقادیر مرزی برای متغییرها: به یک متغییر مقداری کمتر از حداقل مقداری که می تواند قبول کند یا بیشتر از حداکثر مقداری که می تواند قبول کند می دهیم و سیستم را در این شرایط تست می کنیم.

4.       بررسی خروج های سیستم: یک مجموعه از ورودهای صحیح با خروج های مربوط به آن را تهیه می کنیم و سپس ورودها را به سیستم وارد می کنیم و خروج های که توسط سیستم داده می شود را با خروجی های واقعی مقایسه می کنیم.

5.       بررسی رفتار سیستم در برابر پردازش ورودها و پرس و جوهای بزرگ و سنگین

6.       ...

برای موارد بالا و مواردی دیگری که ذکر نشد روشهای مختلف تست در استراتژی جعبه سیاه وجود دارد که عبارتند از:

functional testing, stress testing, recovery testing, volume testing, User Acceptance Testing, system testing, Sanity or Smoke testing, load testing, Usability testing, Exploratory testing, ad-hoc testing, alpha testing, beta testing , ….

آیا می توان در استراتژی جعبه سیاه، از این مطمئن شد که سیستم به طور کامل تست شده است؟ خیر، هرگز در این استراتژی نمی توان مطمئن شد که سیستم به طور کامل تست شده است. برای نمونه با چه احتمالی کاربر می تواند ورودهای را انتخاب کند تا شرط زیر چک شود.

if (name=="Lee" && employeeNumber=="1234" &&

    employmentStatus=="RecentlyTerminatedForCause") {

    send Lee a check for $1,000,000;

    }

پس همیشه در این استراتژی مسیرهای خواهند بود که تست نمی شوند و همیشه سیستم با داده های ورودی محدود می توانند تست شوند.

 

استراتژی جعبه سفید

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

در یک استراتژی آزمایش جعبه سفید ما عموما موارد زیر را مورد توجه و بررسی قرار می دهیم:

1.       بررسی سطر به سطر کد (Code coverage): در این حالت باید سیستم را به گونه ای اجراء و بررسی کنیم که مطمئن شویم سطر به سطر کد برنامه حداقل یکبار اجراء شده است.

2.       بررسی همه انشعاب ها در کد برنامه (branch) : در کد برنامه باید تمام عبارت های شرطی ( if elseها و Switch case ها)   را تک به تک مورد بررسی قرار داد. به این صورت که در یک عبارت if else هم فسمت if و هم قسمت else هر کدام بصورت مجزا یکبار اجراء شوند. 

3.       بررسی همه حلقه ها در برنامه : حلقه ها در نرم افزار نقش اساسی دارند، چون می تونند با اشتباه جزئی مقدار زیادی از منابع را مصرف کرد برای مثال شرط خروج از حلقه به اشتباه هیچ وقت True نشود. برای نمونه حلقه ها را با ورودی بزرگتر از شرط خروج حلقه چک کنید یعنی حلقه اصلا اجر نشود. تستی طراحی کنید که حلقه دقیقا یکبار اجراء شود، تستی طراحی کنید که حلقه در یک بازه خاص اجراء شود و ....

4.       مدیریت خطای مطلوب : برسی اینکه اگر به یک متد یک ورودی نامعتبر وارد شود، نحوه آگاه سازی و نمایش مطلوب خطا برای کاربر چگونه باشد؟

5.       بررسی امنیت : سیستم را از این جهت که چگونه در برابر دسترسی های غیرمجاز، هک، کرک و هر چیز دیگر که می تواند به آن آسیب برساند مورد بررسی قرار می دهد. در اینجا  ما باید مکانهای از کد را که داده ها را اعتبارسنجی و مدیریت می کنند، دسترسی به منابع یا عملیات مهم و حیاتی را انجام می دهند را بررسی کنیم.

6.       ...

7.       برای موارد بالا و مواردی دیگری که ذکر نشد روشهای مختلف تست در استراتژی جعبه سفید وجود دارد که عبارتند از:

Basis Path Testing, Equivalence Partitioning/Boundary Value Analysis, Method Coverage, Statement Coverage, Branch Coverage, Condition Coverage, Data Flow Testing, Flow Graphs Revisited, ….

 

طرح RMMM

یک استراتژی مدیریت ریسک میتواند به طرح پروژه نزم افزار ضمیمه شودیا مراحل مدیریت ریسک میتوانند به مجزایی سازماندهی شوند شامل:کاهش ریسک،طرح نظارت و مدیریت پروژه.طرحRMMM تمام کارهای انجام شده را به عنوان بخشی از طرح کلی پروژه استفاده می شود.

برخی تیم های نرم اقزاری مستنداتی را با قالب RMMMتوسعه نمی دهند.در عوض،هر ریسک به صورت مجزا با استفاده از صفحه اطلاعات ریسک((RIS مستند میگردد.در اکثر موارد،RIS با استفاده از سیستم بانک اطلاعاتی نگهداری می شود به گونه ای که ایجاد وورود اطلاعات،ترتیب بر مبنای اولویت،جستجو ها و تحلیلهای دیگر به راحتی انجام می شوند.قالب RIS در شکل5-6 نشان داده شده است.

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

منبع : مهندسی نرم افزار .... نویسنده: راجر اس پرسمن ..... مترجم : محمد مهدی سالخورده

مدیریت ریسک

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

 تعاریف

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

در منابع مختلف، تعاریف دیگری نیز ارائه شده‌است. بنا بر نظر بوهم، مدیریت ریسک فرایندی شامل دو فاز اصلی است؛ فاز تخمین ریسک (شامل شناسایی، تحلیل و اولویت بندی) و فاز کنترل ریسک (شامل مراحل برنامه ریزی مدیریت ریسک، برنامه ریزی نظارت ریسک و اقدامات اصلاحی) می‌باشد. بنا به اعتقاد فیرلی مدیریت ریسک دارای هفت فاز است: ۱) شناسایی فاکتورهای ریسک؛ ۲) تخمین احتمال رخداد ریسک و میزان تأثیر آن؛ ۳) ارائه راهکارهایی جهت تعدیل ریسک‌های شناسایی شده؛ ۴) نظارت بر فاکتورهای ریسک؛ ۵) ارائه یک طرح احتمالی؛ ۶) مدیریت بحران؛ ۷) احیا سازمان بعد از بحران.

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

موسسه مدیریت پروژه، در راهنمای خود در مورد کلیات دانش مدیریت پروژه (نسخه سال ۲۰۰۰)، برای فرایند مدیریت ریسک پروژه شش فاز را معرفی کرده‌است: ۱) برنامه ریزی مدیریت ریسک، ۲) شناسایی، ۳) تحلیل کیفی ریسک، ۴) تحلیل کمّی ریسک، ۵) برنامه ریزی پاسخ ریسک و ۶) نظارت و کنترل ریسک. کلیم و لودین، برای مدیریت ریسک یک فرایند چهار مرحله‌ای را معرفی کرده‌اند (شناسایی، تحلیل، کنترل و گزارش) که در موازات چهار قدم معروف دمینگ در مدیریت پروژه (برنامه ریزی، اجرا، بررسی و عمل) قرار می‌گیرند.

چاپمن و وارد، یک فرایند مدیریت ریسک پروژه کلی را ارائه کرده‌اند که از نه فاز تشکیل شده‌است: ۱) شناسایی جنبه‌های کلیدی پروژه؛ ۲) تمرکز بر یک رویکرد استراتژیک در مدیریت ریسک؛ ۳) شناسایی زمان بروز ریسک ها؛ ۴) تخمین ریسکها و بررسی روابط میان آنها؛ ۵) تخصیص مالکیت ریسکها و ارائه پاسخ مناسب؛ ۶) تخمین میزان عدم اطمینان؛ ۷) تخمین اهمیت رابطه میان ریسک¬های مختلف؛ ۸) طراحی پاسخها و نظارت بر وضعیت ریسک و ۹) کنترل مراحل اجرا.

کرزنر، مدیریت ریسک را به صورت فرایند مقابله با ریسک تعریف کرده و آن را شامل مراحل چهارگانه زیر می‌داند: ۱) برنامه ریزی ریسک، ۲) ارزیابی (شناسایی و تحلیل) ریسک، ۳) توسعه روشهای مقابله با ریسک و ۴) نظارت بر وضعیت ریسکها.

مراحل اصلی در پیاده‌سازی مدیریت ریسک

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

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

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

قریب الوقوع بزرگ‌تر از ۸۵٪

بالا = ۸۵٪

محتـــــمل = ۶۰٪

متوسط = ۵۰٪

ممــــــکن = ۴۰٪

پایین = ۱۵٪

غیرمحتـمل = ۱۵٪

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

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

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

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

منبع: ویکی پدیا