بنام خدا

با سلام

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

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

اگر با استفاده از روشهايي بتوانيم بر اين مشكلات فائق آييم مي توانيم ريسك توسعه سيستمهاي نرم افزاري را (ريسك عدم پوشش نيازمنديها) تا حد زيادي كاهش دهيم.

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

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

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

  • كامل بودن(Complete) : نيازمنديها مي بايد تا حد ممكن كامل باشد آنها بايد منعكس كننده نيازهاي سيستم و ارتباط بين نرم افزار با ساير قسمتها باشد.
  • قابل رديابي (Traceable) : هر كدام از نيازمنديها مي بايست قابل رديابي باشد هر يك از آنها داراي يك كد منحصر به فرد بوده بطوريكه امكان رديابي در مراحل تجزيه ، توسعه و تست وجود داشته و از طريق آن بتوان به آساني به نيازمندي مربوطه رسيد.
  • قابل تست (‏Testable) : كليه نيازمنديها مي بايست قابل تست بوده تا نشان دهد كه نرم افزار ايجاد شده كليه نيازمنديها را پوشش مي دهد. بدين منظور نيازمنديها بايد مشخص ، واضح و با توضيحات كافي همراه باشد و از توضيحات مبهم و كلي خودداري گردد.
  • سازگار(Consistent) : نيازمنديها بايد با يكديگر سازگار باشد. هيچ نيازمنديها نبايد در تضاد با ساير نيازمنديها باشد بدين منظور مي بايد كليه نيازمنديها را از لحاظ سازگاري و ا نطباق با ساير نيازمنديها مورد ارزيابي قرار دهيد.
  • امكان پذير بودن (Feasible) : كليه نيازمنديها مي بايست بصورت كامل قابل پياده سازي باشند اگر در امكان پذيري تعدادي از نيازها شك وجود دارد مي بايد نسبت به آناليز آنها اقدام و اصلاحات لازم را در راستاي عملي بودن انجام داد و هر نيازمندي كه قابل پياده سازي نباشد  مي بايست حذف گردد.
  • قابليت يكتايي (Uniquely Identified) : منحصر به فرد بودن هر نيازمندي با توجه به خواص قابل رديابي بودن و قابل تست بودن اجتناب ناپذير بوده و علاوه بر آن استفاده از شناسه منحصر به فرد كمك مي كند تا براي بيان آنها از يك روش واضح و يكسان استفاده نماييم.
  • مستقل از طراحي (Design Free) : نيازمنديها مي بايست در سطح نيازمندي بوده و در سطح طراحي عنوان نشود. كليه قابليت هاي سيستم  مي بايست از نقطه نظر نيازمندي نرم افزاري و نه از نقطه نظر طراحي نرم افزار بيان گردد. بطور مثال شما بايد قابليتي كه سيستم مي بايست پوشش دهد را بيان نماييد يك نيازمندي اينكه چه چيزي مي بايست ايجاد شود را بيان نموده در صورتي كه طراحي چگونه يك چيز مي بايست پياده سازي شود را بيان مي نمايد.

 

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

 

مثالهاي مرتبط :

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

 

مثال 1 :

نيازمندي اوليه : بدون تست و تاييد نرم افزار ، نرم افزار نمي بايد توسط يك شخص ناشناس بر روي سيستم بارگذاري شود.

ايرادات : اگر نرم افزار تست و تاييد گرديد آيا توسط يك شخص ناشناس مي تواند بارگذاري شود؟اگر شخص ناشناس نباشد آيا مي تواند بدون آنكه تست و تاييد صورت پذيرد نسبت به بازگذاري آن اقدام نمايد؟اين نيازمندي مبهم بوده و لذا تست و پياده سازي آن مشكل است از طرفي بصورت يك نيازمندي منفي (كاري كه نبايد صورت پذيرد) بيان گرديده است كه پياده سازي آن را مشكل مي نمايد. و اما مشكل ديگر عدم اختصاص شماره شناسايي به نيازمندي است كه ردگيري آن را با مشكل روبرو مي نمايد.

نيازمندي بازنويسي شده : 3.2.2.2 نرم افزار مي بايست تنها بعد از اينكه تست و تاييد گرديد بعنوان سيستم عملياتي بارگذاري گردد.

 

مثال 2 :

نيازمندي اوليه : 3.4.6.3 سيستم مي بايست از پذيرش فايلهاي الكترونيك تكراري با ارزيابي ركورد SDATE فايل جديد خودداري نمايد.يك نامه الكترونيكي مي بايست ارسال شود.

ايرادات : در اين نيازمندي دو بار كلمه مي بايست تكرار شده است كه موجب ابهام مي شود . نامه الكترونيكي جهت چيست؟ ، علاوه بر اين در اين نيازمندي از مفاهيم طراحي استفاده شده است(ركورد SDATE) يك نيازمندي مي بايد محتواي اطلاعات ركورد و نه عنوان آنها را بيان نمايد زيرا قابل تست و يا پياده سازي نمي باشد.

نيازمندي بازنويسي شده : 3.4.6.3 سيستم مي بايست :

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

 

خوب دوستان اينم از اين قسمت – سري بعد ادامه اين مطلب رو با هم مرور مي كنيم مثالهاي بعدي رو از دست نديد

اميدوارم از اين مطالب استفاده كنيد و براتون مفيد باشه لطفا نظرات اصلاحي و تكميلي خودتون رو در قسمت نظرات بگيد

و من ا... التوفيق – مدير سايت