مستندات پروژه نرم افزار
مستندات نیازمندی ها و نقش آن در موفقیت یک پروژه نرم افزاری
برای انجام یک پروژه نرم افزاری معمولاً مشتری نیازهایش را در یک فرمت خاص (چه مکتوب و چه شفاهی) بیان می کند و شما با توجه به آن ها محصول نرم افزاری را تولید می کنید. البته به همین سادگی که من در خط قبل نوشتم، نیست! در اکثر مواقع و حتی می توان گفت همیشه یک مشتری نمی تواند نیازهایش را به درستی مشخص کند. این نکته تاثیر مستقیم بر روی کیفیت نرم افزار دارد، نرم افزاری که نیازمندی هایش به درستی مشخص نشده باشد از کیفیت خوبی برخوردار نخواهد بود. به همین دلیل شناسایی نیازهای یک پروژه نرم افزاری بخش مهمی از پروسه تولید نرم افزار را تشکیل می دهد به طوری که باید در ابتدای کار یک مستندات مفصل و بی نقص در مورد آن نوشت. در این نوشته در مورد مستندات نیازمندی های یک نرم افزار و اینکه چه نقشی در موفقیت یک پروژه نرم افزاری می تواند داشته باشد بحث خواهیم کرد.این مستندات در مورد اینکه نرم افزار چه کارهایی می کند یا چه کارهایی باید بکند، توضیح می دهد. در طول توسعه بارها به این مستندات مراجعه می شود تا نیازمندی های سیستم نرم افزاری به طور کامل پیاده سازی شود و برای استفاده آماده شود. پایه و اساس شکل گیری مستندات نیازمندی ها از قراردادی که با مشتری بسته می شود استخراج می گردد. یعنی در ابتدا فقط نیازمندی هایی که سفارش دهنده نرم افزار مشخص نموده، قابل رویت هستند. سپس تمام کسانی که قرار است درگیر این پروژه شوند آن را به صورت تدریجی کامل می کنند. کاربران نهایی، مشتری ها، مدیر پروژه، معمار نرم افزار، توسعه دهنده ها، طراحان و تست کنندگان همه می توانند نیازمندی ها را مشخص تر کنند.متغیر بودن نیازهای کاربران و پیچیدگی شناسایی برخی نیازهای آنان، نوشتن مستندات نیازمندی ها را بسیار مشکل می کند. در اکثر پروژه های نرم افزاری شناسایی نیازهای کاربران و سیستم بسیار سخت و گاه غیر ممکن است. وقتی خود مشتری ها و کاربران نهایی از نیازهای خودشان آگاهی ندارند، نباید به مهندسین نرم افزار خرده گرفت که چرا نمی توانند فرمول یا استانداردی برای شناسایی بی نقص نیازهای یک سیستم نرم افزاری پیدا کنند!!یکی از راه حل ها شاید این باشید که به صورت تدریجی نیازها را درک کنیم و به مستندات اضافه کنیم. این راه حل همیشه جوابگوی کار نیست. بخش معماری و طراحی نرم افزار به شدت به مستندات نیازمندی ها وابسته است. تغییرات زیاد در مستندات نیازمندی ها باعث تغییر در معماری و طراحی نرم افزار می شود و این یعنی نا پایداری نرم افزار و بوجود آمدن خطاهای مختلف در خروجی نرم افزار که باعث پایین آمدن کیفیت سیستم های نرم افزاری می شود. تغییر دادن بنیان های یک نرم افزار بسیار مشکل و گاه ...
چگونه یک پروپوزال خوب برای نرم افزار بنویسیم؟
همیشه تهیه و ارائه پروپوزال به دلیل عدم شناخت مشخصات نرم اقزار در زمانی که هنوز هیچگونه مصاحبه ای با کاربران صورت نگرفته است کاری دشوار است.اما این کار با ذوق و سلیقه و تجربیات جانبی مدیر پروژه و تحلیلگران امری امکان پذیر است. اما یک پروژه به طور معمول جزئیات ثابتی دارد که بایستی به هنگام ارائه پیشنهاد به کارفرما مشخص شوند.در اینجا تعدادی از موضوعات کلیدی که بایستی در یک پیشنهاد درج شوند مورد بررسی قرار میگیرند. مطلبی که در پی آمده حاصل سالها فعالیت بنده در تهیه پروپوزالهای مختلف برای سازمانها بوده است. مديريت پيکربندي طرح مديريت پيکربندي ( CMP) به منظور تدوين و مشخص کردن فعاليتهاي لازم در فرآيند مديريت پيکربندي تهيه مي شود. اين طرح فعاليتهاي الزامي مديريت پيکربندي پروژه را مشخص کرده و مسئوليت و چگونگي انجام هر يک را تعيين مي نمايد. همچنين نحوه ثبت و نگهداري سوابق پيکر بندي ابزارها و فرآورده هاي پروژه را مشخص مي کند. طرح مديريت پيکربندي سيستم در زمان اجراي پروژه ، در موقع مقتضي تعيين و اعلام خواهد شد. عناصر مشمول طرح مديريت پيکربندي در اين پروژه عبارتنداز: - طرح مديريت پروژه - استانداردهاي پروژه - کليه مستندات مراحل طراحي و ساخت مشمول طرح تضمين کيفيت پروژه - برنامه اجرايي هر زير سيستم - کتابخانه ها ، نرم افزارهاي پايه و ابزارهاي توليد نرم افزار بکار گرفته شده درفرآيند توسعه سيستم - طرحهاي آزمون - پايگاههاي اطلاعاتي اصلي ، جانبي و آزمايشي سيستم - رويه هاي بانک اطلاعاتي ابزارها و روشها مديريت پيکر بندي پروژه و کنترل آن از طريق تهيه و بهنگام سازي فهرستهاي راهنما در محيط الکترونيکي انجام خواهد پذيرفت. مسئول مستندسازي پروژه ، مسئوليت بهنگام سازي اين فهرستها را به عهده دارد. همچنين براي تسهيل گزارش دهي از وضعيت پيکربندي ، مسئول مستند سازي پروژه موظف است نسبت به طراحي ، ايجاد و بهنگام سازي پايگاه داده اي شامل وضعيت اقلام CI ( عنصر پيکربندي) تحت مديريت پيکربندي پروژه و فرمهاي SCR ( گزارش درخواست تغييرات) اقدام مي نمايد. همه مستندات مديريت پيکربندي و همچنين نسخه هاي مبناگذاري شده تا چهار سال پس از پايان مدت قرارداد در محل مناسبي نگهداري مي شوند. مبناهاي نهايي در محل ديگري غير از محل توسعه سيستم نيز بايگاني و تا چهار سال پس از پايان مدت قرارداد نگهداري مي شوند. طرح سازمان اجرايي پروژه طرح سازمان اجرايي پروژه به منظور تدوين ومستندسازي نقش ، ترکيب ، وظايف و اختيارات عوامل اجرايي ، نظارتي و مديريتي پروژه و همچنين روابط اين عوامل با يکديگر تهيه مي شود. توسعه سيستمهاي نرم افزاري ...
مندرجات سند نيازهاي نرم افزار (SRD)
قالبورئوسمطالبمستندات كليه مستندات مي بايست شامل اطلاعات زير باشند: – چكيده – فهرست مندرجات – برگه وضعيت سند – صورتجلسه تغييرات سند كه آخرين نسخه را نيز در بر مي گيرد در صورت عدم وجود اطلاعات مربوط به يك بخش مي بايست جمله ” اين بخش قابل ارائه نيست” همراه با دلايل كافي در سرآيند بخش مذكور آورده شود. رهنمودهايي در خصوص محتواي بخش هاي سند به صورت ”شكسته” ارائه مي گردد. عناوين بخش هايي كه بر حسب نظر تهيه كننده سند فراهم مي آيند ، در داخل [ ] آمده است. فهرست مندرجات سند نيازهاي كاربر( URD) مندرجات سند نيازهاي نرم افزار ( SRD) مندرجات سند طراحي معماري ( ADD) مندرجات سند طراحي تفصيلي ( DDD) مندرجات راهنماي كاربر نرم افزار (SUM ) مندرجات سند انتقال نرم افزار ( STD) مندرجات سند تاريخچه نرم افزار ( PHD) مندرجات طرح مديريت پروژه نرم افزار ( SPMP) مندرجات طرح وارسي و اعتبارسنجي نرم افزار ( SVVP) مشخصات آزمون پذيرش مندرجات طرح تضمين كيفيت نرم افزار ( SQAO) مندرجاتسندنيازهايكاربر ( URD) 1-مقدمه 1-1 هدف 2-1 دامنه نرم افزار 3-1 تعاريف، مفاهيم، سرنام ها و مخفف ها 4-1 ماخذ و مراجع 5-1 مرور اجمالي سند 2- كليات 1-2 دورنماي محصول شرح سيستم هاي خارجي و زيرسيستم هاي مربوطه 2-2 قابليت هاي كلي شرح قابليت هاي عمده لازم و دليل ضرورت آنها 3-2 محدوديت هاي كلي شرح محدوديت هاي عمده درخواستي و دليل وجود آنها 4-2 مشخصات كاربر شرح مشخصات كاربر و زمان استفاده از نرم افزار 5-2 محيط عملياتي شرح نحوه كاركرد سيستم هاي خارجي و واسط آنها با محصول 6-2 فرضيات و وابستگي ها شرح فرضيات وابسته به خواسته هاي كاربر 3- خواسته هاي ويژه فهرست خواسته هاي ويژه كاربر همراه با خصوصيات آنها 1-3 خواسته هاي مربوط به افزايش قابليت نرم افزار 2-3 خواسته هاي مربوط به اعمال محدوديت هاي نرم افزار مندرجات سند نيازهاي نرم افزار (SRD) 1- مقدمه 1-1 هدف 2-1 دامنه نرم افزار 3-1 تعاريف، مفاهيم، سرنام ها و مخفف ها 4-1 ماخذ و مراجع 5-1 مرور اجمالي سند 2- كليات 1-2 ارتباط با پروژه هاي جاري شرح ارتباط نرم افزار با پروژه هاي جاري ديگر 2-2 ارتباط با پروژه هاي قبلي و بعدي شرح ارتباط نرم افزار با پروژه هاي قبلي و آتي 3-2 كاركرد و هدف شرح وظايف عمده أي كه محصول بايد انجام دهد 4-2 ملاحظات محيطي شرح آنكه نرم افزار در كجا و توسط چه كسي مورد استفاده قرار مي گيرد. چه كسي آن را راهبري مي كندو روي چه سخت افزار و تحت چه سيستم عاملي اجرا مي شود. 5-2 ارتباط با ساير سيستم ها شرح سيستم هاي خارجي و زيرسيستم هاي مربوطه 6-2 محدوديت هاي كلي شرح محدوديت هاي عمده درخواستي و دليل وجود آنها 7-2 شرح مدل شرح مدل منطقي با استفاده از يك ...
معرفی نرم افزار PRIMAVERA EXPEDITION
این نرم افزار محصول شرکت پریماورا می باشد که قابلیت کنترل پروژه از زمان عقد قرارداد تا پایان پروژه را دارد. این نرم افزار امکان نگهداری اطلاعات پروژه از قبیل نام، لیست پیمانکاران، کارفرمایان، مبلغ پروژه و نیز مکاتبات بین کارفرمای پروژه و پیمانکاران، مباحث مربوط به REVISION در مستندات، سفارشات خرید، تغییرات قراردادها، برآوردها و نیز گزارشات مختلف دوره ای، کنترل کیفیت و ... می باشد. ماژولهای اصلی این برنامه عبارتند از : 1. PROJECT INFORMATION: حاوی اطلاعات پروژه شامل نام، مبلغ قرارداد، اطلاعات کارفرما و پیمانکاران 2. CONTRACT INFORMATION: شامل مراکز هزینه، صورتحسابها، برآوردها، سفارشات خرید، تغییر در پیشنهاد مدیریتی،تغییر سفارشات 3. COMMUNICATION: که حاوی مستندات و کنترلهای مربوط به انتقال مستندات بین کارفرما و پیمانکاران، زمان بندی و تعیین زمانهای مجاز، زمانهای ملاقات، رکوردهای اطلاعاتی ارتباط با کارفرما و پیمانکاران، نامه ها، TRANSMITTAL و SUBMITTAL و... 4. SAFETY LOGS: اطلاعات مربوط به کنترل کیفیت (QC)، گزارشات روزانه، نقشه ها و ... می باشد. این نرم افزار به ساختار بانک اطلاعاتی خود قابلیت های زیر را در اختیار کاربران قرار می دهند. - امکان تعریف مراکز هزینه، بودجه، تعهدات، صورت وضعیت و صورت حساب های پروژه، تغییرات پروژه (CHANGE ORDERS)، توزیع هزینه ها - امکان تعریف مدارک پروژه، نقشه ها، ترانسمیتال، گزارشات، SUBMITTAL و سایر مدارک پروژه و کنترل وضعیت آنها - تولید انواع گزارشات متنوع و نیز امکان تعریف LAYOUTها و نمونه گزارشات از پیش تعیین شده - ارتباط با محصولات دیگر شرکت پریماورا جهت به اشتراک گذاری اطلاعات و IMPORT / EXPORT داده ها با صفحه گسترده ها و واژه پردازنده ها - وجود ابزارها و امکانات متنوع جهت دسترسی سریع به اطلاعات، مستندات و ضمائم - ایجاد ارتباطات منطقی اطلاعات به منظور کنترل قراردادی در داخل زمان و بودجه مصوب و اعلام رویدادها و فعالیتهایی که نیاز به پیگیری دارند. - امکان به اشتراک گذاری اطلاعات از طریق WEB - ثبت وقایع و رویدادهای پروژه - امکان استفاده کاربران به طور همزمان از اطلاعات و یا ثبت و تغییر در آن (MULTI USER) - تعیین سطح دسترسی برای کاربران مختلف - امکان تعریف گروههای کاری و تعیین سطح دسترسی هر گروه کاری و تخصیص کاربران به گروه کاری
Agile Software Development
امين صفايي ماهنامه شبکه در اين شماره براي دومين يادداشت از صفحه <كدنبشته> قصد دارم يكي از مباحث جديد در مهندسي نرم‌افزار را به صورت مختصر توضيح دهم. در يادداشت‌هاي بعدي نيز سعي خواهم كرد اصول و روش هاي آن را شرح دهم. اين مدل توليدي نرم‌افزار را بارها در پروژه‌هاي نرم‌افزاري‌اي كه مديريت و اجرا كرده‌ام اعمال كردم و تجربه نشان داده است كه خيلي از مواقع اين روش توانسته است گوي سبقت را از روش‌هاي معمول و متداول بربايد. در طراحي يك نرم‌افزار رعايت اصول استاندارد طراحي، استفاده از الگوهاي آماده و بهره‌گيري از روش‌هاي نوين بسيار مهم است، ولي نكته مهم اين است كه در اصل كاربران، باعث مي‌شوند يك پروژه نرم‌افزاري به نتيجه برسد. يعني فناوري و پروسه استفاده شده، در حقيقت در رده دوم اهميت قرار دارند. بسياري از ما با پروژه‌هاي نرم‌افزاري‌اي كه بدون هيچ‌گونه اصولي تهيه مي‌شوند، مواجه شده‌ايم و ديده‌ايم كه كار با اين گونه پروژه‌ها تا چه اندازه مشكل است. در اين پروژه‌ها مشكلات عمده‌اي كه پيش ميآيند عبارتند از: عدم توانايي توليدكنندگان در تشخيص نيازهاي كاربران، وجود ايرادها و error هاي تكراري، تأخير در ارائه محصول و... . از طرف ديگر، مشتريان اين‌گونه نرم‌افزارها از عدم دقت در ارائه برنامه زمانبندي دقيق از طرف طراحان سيستم، كيفيت كمِ نرم‌افزارهاي توليدي و افزايش هزينه‌ها شكايت دارند. در اين پروژه‌ها برنامه‌نويسان ساعت‌هاي زيادي را صرف تهيه نرم‌افزاري مي كنند كه مملو از مشكل است و تلاش آنان چنان كه بايد، مؤثر نيست. وقتي با اين مشكلات مواجه مي‌شويم، به اين فكر مي‌افتيم كه بايد در كار خود روش و رويه‌اي درست داشته باشيم كه فعاليتهاي مربوط به پروژه در آن مشخص و منظم باشد، نيازهاي كاربران در آن مشخص باشد و خروجي نرم‌افزار و محصولات پروژه با موفقيت توليد شوند. براي اين كار مي‌توانيم به تجربيات كسب شده در پروژه‌هاي گذشته خود مراجعه كنيم و فعاليتهاي موفقي كه در آن پروژه‌ها انجام شده است را دوباره انجام دهيم و از كارهايي كه باعث مشكل در آن پروژه‌ها گشته‌اند، پرهيز كنيم. البته نمي‌توانيم با اين كار از وجود مشكل در نرم‌افزار خود مطمئن باشيم؛ زيرا مشكلات، چه بخواهيم چه نخواهيم، بروز خواهند كرد و از آن جايي كه در كار رويه‌اي ثابت نداريم و تنها از تجربيات قديمي خود استفاده مي‌كنيم، نمي‌توانيم انتظار داشته باشيم كه نرم‌افزارهاي ما بدون اشكال باشند؛ زيرا ممكن است با مشكلي برخورد كنيم كه تا به حال با آن برنخورده‌ايم و تجربه‌اي در رفع آن نداريم. اوايل سال 2001 تعدادي از محققان و صاحب‌نظران ...
تطبيق استانداردهاي موجود براي مستند سازي سيستم هاي اطلاعاتي در ايران
تطبيقاستانداردهاي موجود براي مستند سازي سيستم هاي اطلاعاتي در ايران چكيدهنبودن مستندات[1] دقيق و سازمان‌يافته ممكن است موجب افزايش نرخ خرابي نرم‌افزارها و حتي شكست آنها شود. مستندسازي[2] كامل و صحيح پروژه‌هاي نرم‌افزاري باعث مي‌گردد كه كليه عوامل داخلي و خارجي مؤثر بر نرم‌افزار مورد تحليل و بررسي قرار گيرد و مدير پروژه در حين مراحل توليد نرم‌افزار از سلامت آن اطمينان حاصل كند. همچنين تهيه مستندات جهت ارتباط بين افراد درگير در توليد نرم‌افزار از يك طرف، ارتباط بين كاربران از طرف ديگر و نهايتاً ارتباط بين دو گروه مزبور بسيار مفيد است و نگهداري سيستم را تا زماني طولاني، امكانپذير مي‌سازد. عوامل مؤثر در كيفيت مستندات عبارتند از: تعريف و حفظ استانداردهاي تهيه و توليد، سازماندهي مناسب و نگارش فني خوب. مستندسازي سيستمهاي اطلاعاتي علاوه بر آنكه نيازمند نوعي علم و آگاهي در زمينه توليد نرم‌افزار مي‌باشد، نيازمند نوعي هنر در نحوه نگارش و بيان موضوعات است. هدف از اين مقاله توجه به جايگاه مستندسازي در توليد نرم‌افزار و همچنين ارائه روشي مناسب براي مستندسازي سيستمهاي اطلاعاتي در ايران مي‌باشد. كلمات كليدي: مستندسازي (Documentation)، سيستم هاي اطلاعاتي (Information System)، تحليل (Analysis)، طراحي معماري (Architectural Design)، طراحي تفضيلي (Detailed Design)، انتقال و واگذاري نرم‌افزار (Transfer of the Software)، بهره‌برداري و نگهداري (Operation & Maintenance) 1- مقدمهتجربه نشان داده است [1و2و3] كه مستندسازي خوب براي اداره هر سيستم نرم‌افزاري بسيار لازم و ضروري است، اما كيفيت مستندات در بيشتر سيستم‌ها بسيار ضعيف و ناكارآمد است. با توجه به توصيه‌هاي مكرر افراد مطلع در اين رشته، باز هم مستندسازي توسط برخي از تحليل‌گران، برنامه‌نويسان و مديران ناديده گرفته مي‌شود. شايد بتوان گفت علل عديده‌اي از جمله[1و2]: فشار كار برروي توليدكنندگان نرم‌افزار، زمان كم و يا هزينه‌هاي زيادي كه مستندسازي در بر دارد باعث شده است كه مديران در اين زمينه سهل‌انگار گردند. با توجه به مصاحبه‌ها و تحقيقات انجام شده [4] از چند شركت و سازمان بزرگ توليد كننده نرم‌افزار در ايران دلايل عمده عدم توجه به مستندسازي در ايران عبارتند از: فقدان استاندارد مناسب براي مستندسازي سيستمهاي اطلاعاتي در ايران، هزينه سنگين مستندسازي، زمان مورد نياز براي مستندسازي و فشار كاربران برروي توليدكنندگان نرم‌افزار براي تحويل نرم‌افزار (به دليل عدم شناخت كاربران از مراحل توليد نرم‌افزار). كاربران و درخواست‌كنندگان سيستمهاي نرم‌افزاري، نرم‌افزار به عنوان يك كالاي لوكس مي‌شناسند ...
طراحی نرم افزار
نرم افزار نرم افزار مجموعه ای از آیتم ها و یا اشیاء است که در کنار هم یک پیکربندی را تشکیل می دهند که شامل برنامه های کامپیوتری، مستندات، داده و ... می شود. تعریف مهندسی نرم افزار: مهندسی نرم افزار یک رشته مهندسی است که تمامی جنبه های تولید نرم افزار را هدف قرار می دهد. محصولات نرم افزاری عمومی (Generic) – برای فروش به طیف وسیعی ازمشتریانگوناگون تولید می شود. سفارشی (Bespoke or Custom ) – برای یک مشتری خاص منفرد مطابق مشخصاتی و خصوصیاتی تعیین شده ازسوی او تولید می شود. انواع نرم افزارها: نرم افزارهای سیستمی real-time software (نرم افزارهای بلادرنگ) business software (نرم افزارهای تجاری) engineering/scientific software (نرم افزارهای علمی و مهندسی) embedded software (نرم افزارهای نهفته یا تعبیه شده) PC software (نرم افزارهای کامپیوترهای شخصی) AI software (نرم افزارهای هوش مصنوعی) Web applications (نرم افزارهای کاربردی تحت وب) فرآیند تولید نرم افزاری یا متدولوژی نرم افزاری: مجموعه ای از فعالیت ها که هدف آن ها توسعه و تکامل تدریجی نرم افزار می باشد فعالیت های اصلی فرآیند تولید نرم افزار عبارتند از: تحلیل، طراحی، پیاده سازی و تست و نگهداری و استقرار مدل فرآیند: روش خاصی که 4 مرحله تحلیل، طراحی، پیاده سازی و تست و نگهداری و استقرار انجام می شود. تفاوت مدل های مختلف فرآیند در ترتیب و تاخر انجام این کارهاست. انواع مدل های تولید نرم افزار: مدل ترتیبی خطی (The Linear Sequential Model) مدل نمونه سازی (Prototyping) مدل تولید سریع نرم افزار (Rapid Application Development) مدل های تکاملی تولید نرم افزار مدل حلزونی (Spiral Model) مدل حلزونی Win Win مدل مونتاژ مولفه ها (Component Assembly Model) مدل توسعه همروند (Concurent Development Model) مدل روش های رسمی (Formal Methods Model): از دستورات ریاضی برای نوشتن منطق و تحلیل برنامه ها استفاده می شود. تکنیک های نسل چهارم (4GT- Forth Generation Tool): یک محیط نرم افزاری است که در آن مشخصه ها و نیازمندی های سیستم را وارد می کنیم و در نهایت خود نرم افزار کد را تولید می کند. مدل معایب مزایا مدل آبشاری زمانبر است مکانیزم بازگشت وجود ندارد برای پروژه های بزرگ مناسب نیست عدم ارتباط با کاربر در طول تهیه پروژه مدیریت خوب و آسان مدل نمونه سازی ممکن است هیچ گاه وارد مرحله پیاده سازی نشویم در هر نظر سنجی باید نمونه ای را که تهیه کردیم کنار گذاشته و نمونه جدیدی تهیه کنیم چون توقعات کاربر بالاست مدیریت آن مشکل است با توجه به این که مشتری به خوبی از نیازها آگاه نیست، ساخت یک نمونه اولیه در پیشبرد پروژه موثر ...