فرآيند توسعه
مقدمه
UML يك زبان مدل سازي است و نه يك فرآيند و بر اين اساس هيچ گونه علامت گذاري نيز براي فرآيند توسعه و ايجاد سيستم ارائه نمي دهد. سه مبدع UML ، فرآيندي را كه در ابتدا به Objectory و هم اكنون به Unified Process معروف است را ارائه كرده اند. اين فرآيند در شركت Rational از سال ها قبل در حال اجرا است . البته در ايجاد يك سيستم نرم افزاري نمي توان فقط يك فرآيند را مطرح كرد. عوامل مختلفي كه مي توانند در فرآيند توسعه نرم افزار اثر گذار باشند ، موارد متعددي هستند ، مواردي نظير : نوع نرم افزار (بيلادرنگ ، سيستم اطلاعاتي ، محصول روميزي ، بازي كامپيوتري ) ، اندازيه (يك نفر توسعه دهنده ، گروه كوچك ، گروه بيش از 100 نفر ) و غيره .
بنابراين براي درك بهتر خواننده كمي هم از Unified Pricess مي گوييم. فرآيند توسعه ، فرآيندي تكراري و افزايشي است و در چهار مرحله به انجام مي رسد (شكل 1-7 ) . هر مرحله مي تواند از چند تكرار تشكيل شود. در هر تكرار ، قدم هاي چرخه عمر وجود دارد. يعني قدم هاي تعيين نيازمندي ها ، تحليل ، طراحي ، پياده سازي و تست در هر تكرار انجام مي شود.
تعيين اساس كار و محدوده پروژه و اخذ تعهد از كاربر براي ادامه كار در اولين مرحله يعني مرحله شروع انجام ميشود.
جمع آوري مفصل نيازمندي ها و تحليل و طراحي سطح بالا براي ايجاد خطوط پايه معماري در مرحله دوم يعني مراحل تفضيل انجام مي گردد.
در عين حال كارهايي را مجبوريد به آخرين مرحله بياندازيد، به عنوان مثال بتاتست ، آموزش كاربر ، و … به آخرين مرحله يعني مرحله انتقال سپرده مي شود.
ساخت نرم افزار كه عمده وقت پروژه را به خود اختصاص مي دهد سومين مرحله فرآيند توسعه است. كليه مدل هاياساس و ريز تا حد پياده سازي در اين مرحله ساخته مي شود.
هر يك از مراحل مي تواند داراي چندين تكرار باشد. اما در شكل 1-7 اين تكرار را فقط برا ي مرحله سوم يعني مرحله ساخت نشان دادم. فرض بر اين است كه در هر تكرار ، حداقل چهار قدم چرخه عمر وجود دارد. يعني قدم هاي تحليل ، طراحي ، پياده سازي و تست در هر تكرار انجام مي شود . اين تكرارها به وسيله شكل هاي7-2 و 7-3 نيز قابل مشاهده است . در شكل 7-3 قدم هاي بيشتري براي چرخه عمر ذكر شده است كه در صورتع علاقه مندي خواننده مي تواند به سايت شركت Rational مراجعه كند و توضيحات بيشتري را ببيند.
مرحله شروع
در اين مرحله ممكن است به امكاان سنجي ، تحليل مقدماتي براي به دست آوردن اندام پروژه و … نياز شود. اين مرحله با توجه به پروژ ه مي تواند خيلي كوتاه و يا طولاني باشد. اساس كار و تعيين نيازمندي هاي كلي كاربر و نيز محدوده و مرز سيستم پروژه در اين مرحله انجام مي شود. وقتي كه از نقطه نظرات جدي كاربر آگاه شديم، مجوز ادامه كار را از او مي گيريم. اين مرحله از ديد كاربر نبايد چندان طولاني شود.
مرحله تفصيل
درك بهتر پروژه در اين مرحله انجام مي شود. در اين مرحله كليه نيازمندي هاي كاربر به صورت دقيق در قالب موارد كاربرد شناسايي مي گردد. در تصميم هاي اين مرحله نياز به ريسك و مخاطره داريد.
انواع ريسك هاي ممكن مي تواند به صورت زير دسته بندي شود.:
1 – ريسك نيازمندي ها : احتمال آنكه نيازمندي را خوب تشخيص ندهيم. كاربر چيزي بگويد و چيز ديگري فكر كنيم. نقطه شروع تعيين نيازمندي ها ، تعيين موارد كاربرد هستند.
2 – ريسك فني : آيا مي توانيم طراحي OO كنيم ؟ آيا با Web,java و بانك اطلاعاتي مي توانيم خوب كار كنيم ؟ به عبارتي احتمال انتخاب معماري فني مناسب چقدر است ؟
3 – ريسك مهارت ها : آيا نيروي متخصص داريم ؟ احتمال آنكه تخصص هاي لازم در پروژه را در دسترس داريم يا نه ، تحت عنوان ريسك مهارت ها مطرح مي شود.
4 – ريسك شناسي : آيا نيروهاي اثر گذار بيروني وجود دارند ؟ يعني چقدر احتمال دارد كه از نظر سياسي ، پروژه تحت تاثير نيروهاي بيروني قرار گيرد؟
ريسك نيازمندي ها
نقطه شروع تعيين نيازمندي ها ، تعيين موارد كاربرد است . مورد كاربرد تعاملي نوعي اس كه كاربر با سيستم دارد براي آنكه به هدفي دست يابد. نقطه اساسي در هر مورد كاربرد اينست كه هر مورد كاربرد ، يك وظيفه با اهميت براي كاربر است . مهم ، كشف و شناسايي هر چه بيشتر موارد كاربرد بالقوه و مهم در سيستم است. موارد كاربرد خيلي ريز نمي شوند . ما بهتر است قبل از ترسيم نمودار مورد كاربرد ، نمودارهايي را كه مدل حوزه مسئله را نشان مي دهد ترسيم كنيم. مدل حوزه مسئله به مدل هايي اطلاق مي شود كه به حوزه مسئله و جهان واقعي بر مي گردد و به نوعي حوزه مسئله مورد مطالعه ما را توصيف مي كند.
اين مدل مي تواند هر نوع شكل ، نمودار ، تصوير ، جمله ، متن ، جدول ، ماكت و …. باشد تنها چيزي كه از آن انتظار داريم آن است كه بتواند تصوري كلي از ماهيت سيستم تحت مطالعه و عناصر آ را در اختيار ما قرار دهد.
