تطبيق استانداردهاي موجود براي مستند سازي سيستم هاي اطلاعاتي در ايران

تطبيقاستانداردهاي موجود براي مستند سازي سيستم هاي اطلاعاتي در ايران

چكيده
نبودن مستندات[1] دقيق و سازمان‌يافته ممكن است موجب افزايش نرخ خرابي نرم‌افزارها و حتي شكست آنها شود. مستندسازي[2] كامل و صحيح پروژه‌هاي نرم‌افزاري باعث مي‌گردد كه كليه عوامل داخلي و خارجي مؤثر بر نرم‌افزار مورد تحليل و بررسي قرار گيرد و مدير پروژه‌ در حين مراحل توليد نرم‌افزار از سلامت آن اطمينان حاصل كند. همچنين تهيه مستندات جهت ارتباط بين افراد درگير در توليد نرم‌افزار از يك طرف، ارتباط بين كاربران از طرف ديگر و نهايتاً ارتباط بين دو گروه مزبور بسيار مفيد است و نگهداري سيستم را تا زماني طولاني، امكانپذير مي‌سازد. عوامل مؤثر در كيفيت مستندات عبارتند از: تعريف و حفظ استانداردهاي تهيه و توليد، سازماندهي مناسب و نگارش فني خوب. مستندسازي سيستم‌هاي اطلاعاتي علاوه بر آنكه نيازمند نوعي علم و آگاهي در زمينه توليد نرم‌افزار مي‌باشد، نيازمند نوعي هنر در نحوه نگارش و بيان موضوعات است. هدف از اين مقاله توجه به جايگاه مستندسازي در توليد نرم‌افزار و همچنين ارائه روشي مناسب براي مستندسازي سيستم‌هاي اطلاعاتي در ايران مي‌باشد.
 كلمات كليدي: مستندسازي (
Documentation)، سيستم هاي اطلاعاتي (Information System)، تحليل (Analysis)، طراحي معماري (Architectural Design)، طراحي تفضيلي (Detailed Design)، انتقال و واگذاري نرم‌افزار (Transfer of the Software)، بهره‌برداري و نگهداري (Operation & Maintenance)
 
1- مقدمه
تجربه نشان داده است [1و2و3] كه مستندسازي خوب براي اداره هر سيستم نرم‌افزاري بسيار لازم و ضروري است، اما كيفيت مستندات در بيشتر سيستم‌ها بسيار ضعيف و ناكارآمد است. با توجه به توصيه‌هاي مكرر افراد مطلع در اين رشته، باز هم مستندسازي توسط برخي از تحليل‌گران، برنامه‌نويسان و مديران ناديده گرفته مي‌شود. شايد بتوان گفت علل عديده‌اي از جمله[1و2]: فشار كار برروي توليدكنندگان نرم‌افزار، زمان كم و يا هزينه‌هاي زيادي كه مستندسازي در بر دارد باعث شده است كه مديران در اين زمينه سهل‌انگار گردند.
با توجه به مصاحبه‌ها و تحقيقات انجام شده [4] از چند شركت و سازمان بزرگ توليد كننده نرم‌افزار در ايران دلايل عمده عدم توجه به مستندسازي در ايران عبارتند از: فقدان استاندارد مناسب براي مستندسازي سيستم‌هاي اطلاعاتي در ايران، هزينه سنگين مستندسازي، زمان مورد نياز براي مستندسازي و فشار كاربران برروي توليدكنندگان نرم‌افزار براي تحويل نرم‌افزار (به دليل عدم شناخت كاربران از مراحل توليد نرم‌افزار). كاربران و درخواست‌كنندگان سيستم‌هاي نرم‌افزاري، نرم‌افزار به عنوان يك كالاي لوكس مي‌شناسند كه بايستي از آن استفاده كرد ولي هزينه چنداني براي آن پرداخت ننمود.
بايد توجه داشت كه براي اعمال مديريت مؤثر در روند توليد يك محصول، لازم است فرآيند توليد كاملاً قابل رويت باشد اما به دليل آن كه فرآيند توليد نرم‌افزار نامحسوس مي‌باشد و با كارهاي فيزيكي و به ظاهر آشنا تفاوت زيادي دارد تنها راه مناسب براي مديريت نرم‌افزار و ارتباط افراد درگير در پروژه،‌ مستندسازي دقيق تمام مراحل توليد نرم‌افزار مي‌باشد [5]. ضمن آن كه مستندسازي مسائل و مشكلاتي [6] كه ممكن است در حين مراحل تحليل، طراحي، پياده‌سازي و نگهداري يك سيستم پيش آيد به حداقل مي‌رساند.
 
2- مستندات نرم‌افزار
براساس مراجع [1و2و3و5و6] مستندات نرم‌افزار، به هر مطلبي كه به اطلاعاتي درباره ايجاد، عمليات يا استفاده از نرم‌افزار اشاره دارد، گفته مي‌شود و بايستي حداقل شامل موارد زير باشد:
- توصيفي از نيازمندي‌ها و اهداف درخواست كننده نرم‌افزار
- امكان‌سنجي‌ها[3] و بررسي نيازمند‌ي‌هاي نرم‌افزار
- توصيفي از معماري سيستم كه براساس آن تصميم‌گيري مي‌شود آيا سيستم پياده‌سازي گردد يا خير؟
- تعيين معماري و چارچوب سيستم، شامل: توصيفي از روش طراحي، مراحل طراحي، عملكرد برنامه‌هاي سيستم و داده‌هايي كه بين قسمت‌هاي مختلف برنامه‌ها رد و بدل مي‌شوند.
- ليست برنامه‌ها به همراه توضيحات لازم در قسمت‌هايي كه كد برنامه پيچيده است.
- مستندات ارزيابي سيستم كه شامل نتايج آزمون‌هاي انجام شده برروي سيستم مي‌باشد.
- تعيين بودجه، زمان و نيروي انساني مورد نياز براي توليد نرم‌افزار
- راهنماي استفاده از سيستم، كه به كاربر مي‌گويد چگونه سيستم را نصب نمايد و آن را بكار گيرد.
- مستندات نگهداري سيستم كه مشكلات شناخته‌شده نرم‌افزاري و سخت‌افزاري را توضيح مي‌دهد و نكاتي را كه در مراحل طراحي سيستم جهت توسعه سيستم در نظر گرفته شده است، شرح مي‌دهد.
نكته مهمي كه بايد در طول حيات يك نرم‌افزار در نظر داشت اين است كه هنگامي كه تغييراتي در سيستم ايجاد مي‌شود تمام مستندات مربوط به آن بايستي بهنگام گردد تا باز هم از طريق سازگاري مستندات با نرم‌افزار، كارايي لازم در استفاده از نرم‌افزار وجود داشته باشد. گارگ و اسكاچي [7] پيشنهاد كردند به همراه مستندات از نرم‌افزاري استفاده شود كه روابط بين مستندات در آن ثبت شده باشد و زماني كه تغييراتي در هريك از مستندات داده مي‌شود، مستندات وابسته ديگر كه بايستي بهنگام شوند در آن مشخص گردد. براي توليد مستندات بهينه بايستي به مراحل توليد نرم‌افزار توجه كرد. معمولاً توليد نرم‌افزار در روشهاي متداول [1و 5 و6] شامل مراحل زير است:
مرحله
UR- بيان نيازهاي كاربر يا User Requirements
مرحله
SR- بيان نيازهاي نرم‌افزار يا Software Requirements
مرحله
AD- طراحي معماري يا Architectural Design
مرحله
DD- طراحي تفضيلي و توليد برنامه يا Detailed Design
مرحله
TR- انتقال و واگذاري نرم‌افزار براي بهره‌برداري يا Transfer of the Software
مرحله
OM- بهره‌برداري و نگهداري سيستم يا Operation & Maintenance
در ادامه توضيحات هريك از مراحل فوق بصورت خلاصه بيان مي‌گردد.
مرحله بيان نيازهاي كاربر (
UR): در اين مرحله كليه نيازهاي كاربر توسط كاربر بيان مي‌گردد. در روش‌هاي جديد سيستم‌هاي اطلاعاتي به آن مهندسي خواسته‌ها [8] گفته مي‌شود.
مرحله نيازهاي نرم‌افزار (
SR): در اين مرحله تمام خواسته‌هاي كاربر از نظر تكنيكي و اقتصادي بررسي مي‌گردد و تصميمي مبني بر اينكه آيا سيستم جديدي پياده‌سازي شود يا خير، گرفته مي‌شود.
مرحله طراحي معماري (
AD): از طراحي معماري مي‌توان به عنوان مهمترين مرحله از مراحل توليد نرم‌افزار نام برد كه مي‌بايست در آن تمام نيازهاي نرم‌افزار را بصورت ساخت يافته و در قالب نمودارهاي گردش اطلاعات نمايش داد [9]. براي طراحي يك نرم‌افزار روشهاي مختلفي [1و4و6] از جمله طراحي شيءگرا، طراحي تابعي، طراحي بلادرنگ، طراحي Form Base و طراحي Menu Driven وجود دارد كه بسته به نظر طراح سيستم يكي از روشهاي بيان شده، براي طراحي در نظر گرفته مي‌شود.
مرحله طراحي تفضيلي و توليد برنامه (
DD): در مرحله طراحي تفضيلي، طراحي‌هاي انجام شده در مرحله طراحي معماري بصورت نهايي درمي‌آيد. هدف اين مرحله طراحي تكنيكي سيستم جديد با جزئيات كافي است. خروجي‌هاي اين مرحله عبارتند از [9و10] سند طراحي تفضيلي، برنامه‌، سند راهنماي كاربر (SUM)[4] و مستندات آزمون‌هاي انجام شده برروي سيستم. پس از برنامه‌نويسي، رفع خطاها و بازبيني برنامه‌ها، آزمون‌هاي مختلفي انجام مي‌شود كه بايستي مستنداتي براي هر آزمون تهيه گردد. اين آزمونها عبارتند از [5 و 6 و 11]: آزمون واحد[5]، آزمون يكپارچگي[6]، آزمون سيستم[7]، آزمون پذيرش [8].
توليد‌كنندگان نرم‌افزاري بايستي [11و12] طرح آزمون واحد را در مرحله طراحي تفضيلي، طرح آزمون يكپارچگي را در مرحله طراحي معماري و طرح آزمون سيستم را در مرحله بيان نيازهاي نرم‌افزار تهيه كنند. همچنين طرح آزمون پذيرش، توسط كاربر بايستي در مرحله بيان نيازهاي كاربر توسط درخواست‌كنندگان سيستم تهيه گردد و مستند گردد.
مرحله‌ انتقال و واگذاري نرم‌افزار براي بهره‌برداري (
TR): در اين مرحله نرم‌افزار در محيط عملياتي نصب مي‌گردد تا قابليت‌هاي كه براي نرم‌افزار در سند نيازهاي كاربر ذكر شده، به نمايش گذارده شود. مرحله انتقال نرم‌افزار با پذيرش موقت نرم‌افزار آغاز و با شروع مرحله بهره‌برداري خاتمه مي‌يابد.
مرحله بهره‌برداري و نگهداري سيستم (
OM): اين مرحله كه توليدكنندگان نرم‌افزار نيز در آن مشاركت دارند تا زمان پذيرش نهايي نرم‌افزار ادامه مي‌يابد و عملكرد سيستم براي مدت مورد بررسي قرار مي‌گيرد تا از تطابق عملكرد واقعي سيستم با نيازهاي كاربر اطمينان حاصل گردد و امكانات توسعه سيستم و قابليت هاي جديد در آينده بررسي شود.
با توجه به مراحلي كه در بالا اشاره شد، در هر مرحله مستنداتي كه توليد مي‌شوند عبارتند از [5]:
- مرحله بيان نيازهاي كاربر (
UR): سند نيازهاي كاربر[9] (URD)
- مرحله نيازهاي نرم‌افزار (
SR): سند نيازهي نرم‌افزار[10] (SRD)
- مرحله طراحي معماري (
AD): سند طراحي معماري[11] (ADD)
- مرحله طراحي تفضيلي و توليد برنامه (
DD): سند طراحي تفضيلي [12] (DDD)
- مرحله انتقال و واگذاري نرم‌افزار براي بهره‌برداري (
TR): سند انتقال و واگذاري نرم‌افزار[13] (STD)
- مرحله بهره‌برداري و نگهداري سيستم (
OM): سند نگهداري سيستم[14] (SMD)
با توجه به آنچه در مراجع مختلف به خصوص استانداردهاي
IEEE[15] [9و10و11و12و13و14] ذكر شده است، هريك از مستندات فوق‌الذكر شامل موارد زيادي است كه مندرجات اين مستندات به طور خلاصه در جدول شماره 1 ارائه شده است.


جدول شماره 1- مستندات مراحل توليد نرم‌افزار براساس استاندارهاي بين‌المللي
IEEE [9و10و11و12و13و14]
 <?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />

نام سند

مندرجات

سند نيازهاي كاربر

تعيين محيط عملياتي، تشخيص نيازهاي كاربر

سند نيازهاي نرم‌افزار

هدف از تهيه سند، دامنه نرم‌افزار، تعاريف، مفاهيم، سرنام‌ها، مخفف‌ها، ماخذ و مراجع، مرور اجمالي سند، شرح ارتباط نرم افزار با پرو‍ژه هاي قبلي، جاري و آتي،‌ شرح وظايف عمده نرم‌افزار، شرح آنكه نرم‌افزار در كجا و توسط چه كسي مورد استفاده قرار مي گيرد و چه كسي آن را راهبري مي كند، سخت افزار و سيستم عامل مورد نياز نرم‌افزار، شرح ارتباط نرم‌افزار با ساير سيستم ها، شرح محدوديت هاي درخواستي از طرف كاربر، شرح مدل منطقي سيستم با استفاده از يك روش تجزيه و تحليل شناخته شده، شرح نيازهاي ويژهُ نرم‌افزار،‌ ارائهُ يك ماتريس براي رديابي نيازهاي نرم‌افزار در قبال نيازهاي كاربر

سد طراحي معماري

هدف از تهيه سند، دامنه نرم‌افزار، تعاريف، مفاهيم، سرنام‌ها، مخفف‌ها، ماخذ و مراجع، مرور اجمالي سند، مرور اجمالي نرم‌افزار، روش طراحي، شرح سيستم و طراحي آن همراه با نمودارهاي لازم، مشخصات طراحي، امكان سنجي و برآورد منابع، ارائهُ يك جدول ارجاعات متقابل بين مؤلفه‌هاي طراحي شده و نيازهاي نرم‌افزار

سند طراحي تفضيلي

هدف از تهيه سند، دامنه نرم‌افزار، تعاريف، مفاهيم، سرنام‌ها، مخفف‌ها، ماخذ و مراجع، مرور اجمالي سند، استانداردهاي طراحي و مستندسازي و برنامه‌سازي، قراردادهاي نام گذاري برنامه ها و فايل‌ها، ابزار توليد نرم افزار، مشخصات طراحي و مؤلفه‌ها، ليست متن برنامه‌ها، ارائهُ يك جدول ارجاعات متقابل بين مؤلفه‌ها و نيازهاي نرم‌افزار

راهنماي كاربر نرم‌افزار

1- مقدمه شامل: شرح هدف سند، هدف نرم‌افزار، نحوهُ استفاده از راهنما، مستندات وابسته و قراردادها، 2- شرح نرم‌افزار 3- بخش دستورالعمل ها شامل: احتياط و هشدارها، روال‌هاي برپاسازي و راه اندازي سيستم، خطاهاي احتمالي، دلايل آنها و چگونگي رفع خطاهاي پيش آمده 4- بخش مراجعه شامل ارائهُ مثالهاي از عمليات نرم‌افزار، شرح روال هاي ترميم سيستم، فهرست كليهُ پيغام‌هاي خطا، واژه‌نامه‌ و نمايه (براي راهنماهاي 40 صفحه به بالا)

سند آزمون هاي نرم‌افزار

خلاصه‌اي از عناصر نرم‌افزار، فهرست عناصري كه بايستي مورد آزمون قرر گيرند، شرح مشخصات داده‌هاي ورودي براي انجام آزمون و نتايج مورد انتظار، طرح كلي انجام آزمون، شرح معيارهاي قبول يا رد يك آزمون،‌ فهرست عناصري كه بايستي قبل و بعد از آزمون تحويل داده شوند، شرح ويژگي‌هاي لازم براي محيط آزمون، شرح مشخصات كساني كه: اجازه مي‌دهند آزمون انجام شود، آزمون را انجام مي‌دهند، نتايج آزمون را بررسي مي‌كنند و كامل بودن آن را تأييد مي‌نمايند، مشخصات نيروي انساني لازم براي انجام آزمون‌ها همراه با سطح مهارت مورد نياز، خلاصه‌اي از زمان انجام فعاليت هاي آزمون

سند انتقال نرم‌افزار

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

سند نگهداري سيستم

شرح محصول توليد شده، شرح برنامه ريزي اصلي و آنچه كه عملاً اتفاق افتاده است، ارائهُ حجم برنامه برآورد شده در پايان مرحله طراحي معماري، ارائهُ حجم برنامه واقعي در پايان مرحله انتقال نرم‌افزار، فهرست مستندات پروژه‌ همراه با تعداد كلمات و صفحات، حجم كار برآورده شده و واقعي، ارائهُ برآوردهاي بهره‌وري به عنوان مثال تعداد خط برنامه نوشته شده در روز، خلاصهُ فعاليت‌هاي تضمين كيفيت، فهرست منابع كامپيوتري اعلام شده در پايان مرحله طراحي معماري و منابع استفاده شده در پايان مرحله انتقال نرم‌افزار


3- تطبيق استانداردها براي مستندسازي سيستم هاي اطلاعاتي در ايران
تحقيفات و مطالعه ميداني در شركت‌ها و سازمان‌هاي توليد كننده نرم‌افزار نشان مي دهد [4] كه به دليل پيچيدگي و مفصل بودن قالب هاي ارائه شده براي هريك از مستندات در جدول شماره 1، افراد درگير در توليد نرم افزار رغبت كمتري به استفاده از اين استانداردها نشان مي‌دهند. به اين دليل در اين مقاله سعي شده است با استفاده از نظرات ارائه شده از طرف شركت هاي مزبور، قالب هاي بيان شده در جدول شماره 1، ضمن در نظرگرفتن جامعيت آنها، بصورت ساده‌تر بيان گردد. براي اطلاعات بيشتر مي‌توان به مرجع شماره 4 مراجعه كرد. براساس بررسي هاي انجام شده [4] كليه مستندات در تمام مراحل توليد نرم‌افزار شامل موارد مشترك و موارد تخصصي مي باشد كه در ادامه هريك به طور جداگانه شرح داده مي شود.
 
3-1- موارد مشترك مستندات هر مرحله از توليد نرم‌افزار
براي مستندات كليه مراحل توليدكننده نرم‌افزار [4] بايستي موارد زير تهيه گردد:
الف- صفحه جلد كه در آن نام شركت توليدكننده نرم‌افزار، نام سيستم نرم‌افزاري، كد سيستم نرم‌افزاري، نام شركت درخواست‌كننده‌ نرم‌افزار، نام سند (سند نيازهاي كاربر، سند نيازهاي نرم‌افزار، سند طراحي معماري و ...) كد سند، نام و امضا تهيه‌كنندگان، تاييدكنندگان، تصويب كنندگان و دريافت كنندگان سند به همراه تاريخ تاييد و اجرا در آن ذكر شده باشد. همچنين بايستي در صفحه ي جلد، نوع سند (عادي يا محرمانه)، شماره بازنگري،‌ تاريخ بازنگري و تعداد كل صفحات سند مشخص شده باشد.
ب- فهرست كنترل مستندات كه در آن مواردي از قبيل محتواي فني گزارش‌ها، رعايت دستورالعمل هاي تضمين كيفيت، رعايت متدلوژي و استانداردها، صحت گزارش از نظر املائي، نوشتاري، رعايت سياست ها، مقررات و ساختار گزارش دهي توسط كارشناسان مختلف (كارشناسان سيستم كارشناسان تكنولوژي) و مدير و مسئول پروژه تأييد مي شود.
ج- فهرست مطالب
د- چكيده
ه- مقدمه
و- صورتجلسه تغيير در مستندات
ز- فهرست مآخذ و مراجع كه در آن بايستي ليست كاملي از همه مستندات كه به آن اشاره مي‌شود، ذكر گردد.
ك- فهرست سرنام هاي[16] مورد استفاده در سند
 
3-2-1- مندرجات سند نيازهاي كاربر (
URD)
اين سند هميشه قبل از آغاز يك پروژه نرم‌افزاري تهيه مي‌گردد كه در آن كليه نيازهاي كاربر گنجانده مي‌شود و لازم است حداقل حاوي مطالب زير باشد:
- ارزيابي درخواست كاربر با در نظر گرفتن حيطه كاري و امكان‌پذيري آن
- ارائه يك نمودار مفهومي كه نشاندهنده درك اوليه از نيازهاي كاربر است و در آن ورودي‌ها و خروجي‌ها سيستم مشخص گرديده است.
- تخمين و ارزيابي بسيار كلي در زمينه هزينه‌، زمان، نيروي انساني و تجهيزات مورد نياز و منافعي كه در صورت قبول درخواست كاربر، پيش‌بيني مي شود.
- مصاحبه‌ها، يادداشت‌ها و نتايج بدست آمده در خلال مرحله
UR (مهندسي خواسته‌ها)
- شرحي از كليه محدوديت‌هايي كه كاربر براي هر راه حل پيشنهادي،‌ تحميل خواهد نمود.
- شرح قابليت‌ها و عملكردهاي اصلي نرم افزار
- شرح مسائل و مشكلات موجود
- توصيفي از خواسته‌هاي مربوط به توسعه و افزايش قابليت نرم‌افزار
در نهايت پس از بررسي نيازهاي كاربر كميته‌اي جهت تصميم‌گيري در مورد قبول يا رد درخواست كاربر تشكيل مي گردد و نتايج اين تصميم‌گيري در سند نيازهاي كاربر ثبت مي گردد. ضمناً كنترل و نظارت بر تغييرات اين سند بر عهده كاربر مي باشد.
 
3-2-2- سند نيازهاي نرم‌افزار (
SRD)
اين سند در برگيرنده نتايج حاصل از امكان‌سنجي‌ها، تجزيه و تحليل‌هايي است كه پيرامون سيستم نرم‌افزاري انجام گرفته است و بايستي حداقل حاوي مطالب زير باشد:
- تخميني از هزينه‌ها و منابع مورد نياز شامل منابع سخت افزاري، نرم‌افزاري، نيروي انساني، تخصص‌هاي مورد نياز و تخمين نفر- ساعت هر تخصص (حداكثر تا 20% خطا)
- شرح محدوديت هاي تعيين شده توسط مدير پروژه و درخواست كننده سيستم نرم‌افزاري
- توصيفي از سيستم نرم‌افزاري موجود در قالب نمودار (مثلاً ترسيم نمودار جريان داده براي سيستم موجود[17])
- ارائه يك يا چند راه حل براي سيستم پيشنهادي
- بيان نيازهاي سيستم پيشنهادي
- شرح عمليات و وظايفي كه سيستم پيشنهادي انجام مي‌دهد.
- ايجاد يك جدول ارجاع متقابل[18] كه در آن براي هر نياز نرم‌افزار ارجاعي به خواسته‌هاي كاربر وجود دارد.
 
3-2-3- سند طراحي معماري (
ADD)
بسته به نوعي طراحي، مستندات اين مرحله مي‌توانند در هر شكل و نوع اندكي متفاوت باشد. مثلاً در طراحي شيءگرا بهتر است نمودار سلسله مراتبي سيستم رسم و مستند گردد تا ارتباط بين اشيا مشخص شود و ترسيم يك شبكه كاري كه نشان مي‌دهد چه اشيايي از سرويس‌هاي اشيا ديگر استفاده مي‌كند، نيز مناسب است. اما در طراحي
Form Base كه سيستم شامل تعداد زيادي فرم مي‌باشد، بايستي اطلاعات اين فرم‌ها مستند گردد تا نشان دهد در هر فرم مجموعه هاي اطلاعاتي و فرمهاي قبلي و بعدي کدامند. همچنين فايلهاي در برگيرنده اين فرم‌ها و برنامه‌هايي كه از طريق فرم‌ها احضار مي‌شوند، مشخص گردند. ولي بطور كلي سند طراحي معماري مي‌بايست شامل موارد مشترك زير باشد:
- تأييديه كاربر براي طراحي سيستم
- تأييد و تعهد طراحان سيستم مبني براينكه طراحي طبق جدول زمانبندي تعيين شده، انجام خواهد شد.
- برنامه‌ زمانبندي براي انجام پروژه
- استانداردها و قراردادهاي پروژه که شامل:
· استانداردهاي طراحي كه بايستي روش طراحي شرح داده شود و يا به يك روش استاندارد ارجاع داده شود.
· استانداردهاي مستندسازي شامل شرح، شيوه و ابزار مستندسازي
· انتخاب زبان برنامه نويسي
· استانداردهاي برنامه‌نويسي و قواعد نامگذاري فايل‌ها، جداول، فرم‌ها و برنامه‌ها
· ابزارهاي توليد نرم‌افزار
- روش مورد استفاده در طراحي سيستم
- توصيفي از طراحي سيستم به همراه نمودارهاي جريان داده سيستم پيشنهادي[19]
- طراحي مقدماتي ساختار فايل‌ها،‌ پايگاه داده‌ها و ساختمان داده ورودي و خروجي‌ها
- شرح وظايف سيستم
- امكان سنجي و برآورد هزينه‌ها، منابع سخت افزاري و نيروي انساني مورد نياز (حداكثر با 10% خطا)
- ارائه يك جدول ارجاع متقابل از مولفه‌هاي طراحي به نيازهاي نرم‌افزار
 
3-2-4- سند طراحي تفضيلي (
DDD)
در سند طراحي تفضيلي حداقل بايستي موارد زير گنجانده شود:
- مشخصات طراحي شامل:
· ترسيم نمودارهاي جريان داده‌ سيستم پيشنهادي كه كليه نمودارهاي ترسيم شده در مرحله طراحي معماري در اين مرحله با جزئيات كامل شكسته مي شود و بايستي در فرم‌هايي براي هر پردازه، منطق اصلي پردازش اطلاعات شرح داده مي‌شود.
· ترسيم نمودار ساختاري سيستم (
SSC)[20] كه در آن زيرسيستم ها و ارتباط آنها با يكديگر تعيين مي‌شود و براي زيرسيستم ها مشخصات كامل فايل‌ها و جداول آنها و نحوه ارتباط آنها با يكديگر مشخص مي‌گردد.
· ترسيم نمودار ارتباط بين (
ERD)[21] كه بايستي كليه موجوديت‌هاي سيستم‌ شناسايي و ارتباط بين‌ آنها مشخص گردد.
· مشخصات و شرح ورودي‌ها و خروجي‌‌هاي سيستم
- ليست كد و مشخصات كامل برنامه‌ها، شامل نام برنامه‌، نام فايل‌ها و جداول ايجاد شده يا استفاده‌شده در برنامه، ورودي‌ها و خروجي‌هاي برنامه، نام برنامه‌هاي فراخواننده اين برنامه يا برنامه‌هاي فراخواني شده در اين برنامه و فلوچارت هر برنامه در صورت لزوم
- تعيين پيكربندي نهايي سخت افزار، نرم‌افزار و شبكه مورد نياز سيستم
- ارائه يك جدول ارجاع متقابل بين مؤلفه‌ها و نيازهاي نرم‌افزار
 
3-2-5- سند راهنماي كاربر (
SUM)
همانطور كه قبلاً گفته شد يكي از خروجي‌هاي مرحله طراحي تفضيلي، سند راهنماي كاربر مي‌باشد. اين سند بايستي حداقل شامل موارد زير باشد:
- نحوه استفاده از اين سند
- بيان كليه قراردادهاي بكاررفته در ساختار نحوي و نگارشي مطالب
- شرح سيستم شامل اهداف سيستم، قابليت‌ها و محدوديت‌هاي سيستم، ترتيب و توالي هريك از فعاليت‌هاي سيستم، شرح منوها، مشخصات كامل ورودي ها و خروجي هاي سيستم
- بيان نحوه تأمين امنيت سيستم
- پيغام هاي خطا و دلائل آنها و راهكارهاي رفع آنها
- روال هاي ترميم[22] سيستم بعد از كار افتادن سيستم
- روال پشتيباني[23] در صورت اتفاقات غيرمترقبه
براي سهولت كار، راهنماي كاربر مي‌تواند به عنوان بخشي از يك راهنماي حين كار [24]باشد، تا كاربر بتواند با انتخاب كلمات كليدي، از توضيحات و راهنماي هر بخش استفاده نمايد.
 
3-2-6- مستندات آزمون
مستندات آزمون واحد،‌ يكپارچگي، سيستم و پذيرش شامل موارد مشترك زير است:
- نام آزمون
- تاريخ شروع و خاتمه آزمون
- مشخصات افرادي كه آزمون را انجام مي‌دهند و نتايج كامل بودن آزمون را تأييد مي‌كنند.
- محدوديت‌هاي خاص آزمون
- ليست متغيرها و ورودي ها به هر بخش
- ليست گزارشات و خروجي‌هاي هر بخش
- نتيجه آزمون
 
3-2-7- سند انتقال و واگذاري نرم افزار براي بهره‌برداري (
STD)
سند انتقال نرم‌افزار بايستي حداقل شامل موارد زير باشد:
- تاريخ نصب و نام نصب كننده سيستم نرم‌افزار
- حداقل سخت افزار موجود براي نصب سيستم
- نرم‌افزارهاي لازم جهت نصب سيستم
- خلاصه‌اي از گزارش آزمون پذيرش
- شرح چگونگي نصب، راه‌اندازي و اجراي سيستم نرم‌افزاري برروي كامپيوتر
- گزارشي از درخواست تغيير يا اصلاح نرم‌افزار در طي مرحله انتقال نرم‌افزار
- نوع نصب سيستم نرم‌افزاري[25]
 
3-2-8- سند نگهداري سيستم (
SMD)
در مستندات اين مرحله بايستي تاريخ بررسي و دوره بررسي سيستم مشخص گردد. سپس گزارشاتي كه در اين دوره تهيه مي گردد مورد تجزيه و تحليل قرار گيرد و خطاهاي احتمالي و يا درخواست‌هاي جديد كاربر بررسي گردد. همچنين بايستي هزينه واقعي ايجاد و توسعه سيستم با هزينه پيش‌بيني شده مقايسه گردد و هرگونه پيشنهادي كه باعث بهبود وضعيت سيستم در آينده خواهد شد، مشخص گردد. سپس اعلاميه پذيرش نهايي سيستم از طرف نمايندگان كاربران، تهيه و به توليد‌كنندگان نرم‌افزار تحويل داده شود و به مستندات اين مرحله ضميمه گردد.
 
4- خلاصه و نتيجه گيري
مدير يك پروژه نرم‌افزاري به علت غيرملموس بودن يك سيستم نرم‌افزاري نمي‌تواند بسادگي بر پيشرفت پروژه نظارت داشته باشد ولي با تهيه مستندات مراحل مختلف توليد يك نرم‌افزار مي‌تواند بر فرآيند نرم‌افزار نظارت داشته باشد. اما به دلايل مسائل و مشكلات متعددي كه در زمينه مستندسازي سيستم‌هاي اطلاعاتي در ايران وجود دارد بطور جدي به اين مهم پرداخته نشده است. اهم اين مسائل عبارتند از:
- عدم شناخت نرم‌افزار به عنوان يك سرمايه و صنعت از سوي كاربران
- عدم وجود استاندارد مناسب جهت مستندسازي سيستم‌هاي اطلاعاتي در ايران
- عدم شناخت كاربران و درخواست‌كنندگان سيستم از مراحل توليد يك نرم‌افزار و تحت فشارگذاردن توليدكنندگان براي تحويل سريع نرم‌افزار و در نتيجه عدم توجه توليدكنندگان نرم افزار به مستندسازي سيستم‌ها
- عدم تهيه مستندات كافي از طرف توليدكنندگان نرم‌افزار به جهت وابسته شدن كاربران به آنها
با اين همه مستندسازي دقيق و كامل سيستم هاي نرم‌افزار مزاياي بسياري، هم براي توليدكنندگان نرم‌افزار و هم براي كاربران در بردارد. از جمله اين مزايا مي‌توان به موارد زير اشاره كرد:
- براي برقراري ارتباط بين افراد درگير در پروژه
- براي آموزش كاربراني كه مي‌خواهند از سيستم استفاده كنند.
- به عنوان مرجع كاملي براي افرادي كه مي‌خواهند از نحوه عملكرد سيستم آگاهي يابند و يا كساني كه در توليد و نگهداري نرم‌افزار شركت داشته‌اند و مي‌خواهند تغييراتي در جهت توسعه نرم‌افزار ايجاد كنند.
- مشاهده كليه نتايج و گزارشات قطعي نرم‌افزار براي استفاده توليدكنندگان و كاربران
- ملموس كردن مراحل توليد نرم‌افزار و كارهاي انجام شده در حين پروژه، جهت آگاهي كاربران و مدير پروژه و نشان دادن اهميت و جايگاه مستندسازي
با در نظر گرفتن مزاياي فوق به نظر مي‌رسد با ارائه روشهاي مناسب بتوان مستندسازي را براي سيستم‌هاي اطلاعاتي در ايران به صورت ساده‌تري به انجام رساند. هرگونه روش و چارچوبي براي مواردي چون مستندسازي پيشنهاد گردد، وقتي مي‌تواند مفيد بودنش اثبات شود كه در چند مورد مختلف به صورت عملي به كار گرفته شود و نتايج اين استفاده عملي مورد بررسي قرار گيرد. نكته مهم اين است كه استفاده از روش ارائه شده در اين مقاله و بررسي نتايج آن، نياز به زمان زيادي دارد كه انشاءا... در فعاليت‌هاي آتي مدنظر قرار خواهد گرفت.
 
5- نگاهي به آينده
هنگامي كه مستندات بصورت كاغذي تهيه مي‌گردند مسائل و مشكلاتي در بر خواهند داشت كه ممكن است باعث كاهش كارايي آنها گردد. اين مسائل و مشكلات بصورت خلاصه عبارتند از:
- حجم زياد مستندات كاغذي
- مشكل گردآوري، دسته‌بندي، سازماندهي، تكثير و نگهداري مستندات كاغذي (همواره خطراتي از قبيل آتش‌سوزي حفظ و نگهداري آنها را به خطر مي‌اندازد.)
- مشكل بهنگام سازي مستندات
- سرعت پايين و زمان زياد براي بررسي و مطالعه مستندات
بنابراين به نظر مي‌رسد كه مي‌توان تمام مستندات را به صورت مستندسازي حين كار (
OLD)[26] طراحي كرد و با طراحي آنها به صورت سيستم فرامتن[27]، ساختاري جامع ايجاد كرد تا بتوان با انتخاب كلمات كليدي، توضيحات هر بخش را مشاهده كرد و ارتباط بين مستندات را به سادگي فراهم آورد. مثلاً بتوان با مشاهده فرآيندي در طراحي تفضيلي مستندات نياز به آن فرآيند را در سند نيازهاي نرم‌افزار مشاهده كرد. مسلماً اين روش مزاياي بسيار را در بر خواهد داشت از جمله:
- سهولت دسترسي به مستندات هر مرحله از توليد نرم‌افزار
- امكان دسترسي سريع به مستندات مرتبط به هم
- تكثير سريع با هزينه بسيار كم
- امنيت بالا در نگهداري مستندات
- بهنگام‌سازي سريع مستندات
- سهولت در نقل و انتقال مستندات
- قابليت بالا در جهت آموزش سريع به كاربران و كساني كه مي‌خواهند در مورد سيستم، اطلاعاتي داشته باشند.


تشكر و قدرداني

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

يادداشتها

[1] Documents
[2] Documentation
[3] Feasibility Study
[4] Software User Manual

 

2 آزمون واحد (Module Test): اين آزمون مشخص مي‌كند آيا واحدها از نظر منطقي و عملكرد درست عمل مي‌كنند يا خير؟
3 آزمون يكپارچگي (
Integration Test): هنگامي كه هركدام از واحدها مورد آزمايش قرار گرفت و مورد قبول واقع شد، واحدها به صورت تركيبي جهت آنكه مشخص گردد اتصال بين آنها عملي است و نتايج مورد نظر را توليد مي‌كنند، مورد آزمايش قرار مي‌گيرند. به اين آزمون، آزمون يكپارچگي گفته مي‌شود..
4 آزمون سيستم (
System Test): در اين آزمون عملكرد كل سيستم و صحت عمل آن در ارتباط با سخت‌افزار، نرم‌افزار، وسايل جانبي و هر جزمؤثر در سيستم مورد آزمايش قرار دارد و تا حصول معيارهاي قابل قبول سيستم كه توسط درخواست كننده سيستم، تعيين شده است آزمون تكرار مي‌گردد.
5 آزمون پذيرش (
Acceptance Test): پس از انجام آزمون‌هاي فوق، آزمون پذيرش با حضور نمايندگان درخواست‌كننده سيستم انجام مي‌شود تا سيستم نرم‌افزاري مورد تأييد آنها قرار گيرد.

[9] User Requirements Document
[10] Software Requirements Document
[11] Architectural Design Document
[12] Detailed Design Document
[13] Software Transfer Document
[14] Software Maintenance Document
[15] Institute of Electrical and Electronics Engineers
[16] Acronyms
[17] Current Physical & Logical Data FlowDiagram
[18] Cross Reference
[19] Required Physical & Logical DFD
[20] System Structure Chart
[21] Entity Relationship Diagram
[22] Recovery
[23] Back up
[24] Online help

[25] طريقه نصب يك سيستم به طراحي سيستم، درخواست كاربر و ريسك‌هايي كه مي‌توان پذيرفت، وابسته است. نوع نصب سيستم مي‌تواند بصورت تبديل مستقيم (direct)، تبديل موازي (parallel)،‌ تبديل قسمت به قسمت (modular) و تبديل مرحله‌اي (phase in) باشد. در تبديل مستقيم، سيستم جديد جايگزين سيستم قبلي مي گردد. در تبديل موازي، سيستم جديد و قديمي به موازات هم كار مي‌كنند تا اگر سيستم جديد مشكلاتي پيدا كرد برطرف گردد،‌ پس از مدتي سيستم جديد جايگزين سيستم قبلي مي گردد. در روش تبديل قسمت به قسمت، سيستم جديد در يك قسمت پياده‌سازي مي‌گردد و عملكرد آن بررسي مي‌شود و سپس در ساير قسمت‌ها نصب مي‌گردد. مثلاً يك سيستم حسابداري ابتدا در يك قسمت نصب و راه‌اندازي مي شود و عملكرد آن بررسي مي‌شود، سپس در قسمت هاي ديگر به اجرا در مي‌آيد. در روش تبديل مرحله‌اي سيستم به چند مرحله تقسيم مي‌شود. مثلاً سيستمي كه شامل بخش‌هاي حسابداري، انبارداري و بايگاني مي‌باشد، ابتدا مي‌تواند بخش حسابداري آن نصب و راه‌اندازي گردد سپس بخشهاي ديگر.

[26] Online Documentation
[27] Hypertext

مراجع


 [1] Sommervil, Ian, Software Engineering, 4th ed., 1992.
[2] Green, Steve, Information system design, first edition, Chapman and Hall, 1996.
[3] Phona, Vir, A Standard for Software Documentation, ANSI/ANS, 10-13, 1995.

[4] بهشتي زهرا، بررسي روشهاي مستندسازي و ارائه روش مناسب مستندسازي براي سيستم هاي اطلاعاتي در ايران، پايان‌نامه كارشناسي ارشد، دانشكده فني و مهندسي، دانشگاه آزاد اسلامي نجف‌آباد، 1378.
[5] مرآت‌نيا احمد (ترجمه)، استانداردهاي مهندسي نرم‌افزار، تأليف مازاك.، چاپ اول 1377.


[6] Pressman Rger S., Software Engineering A Practitioner's Approach, Third Edition, 1994.
[7] Garg P.K. and Scacchi W., A hypertext system to maintain software life-cycle documents, IEEE Software, 1990, 7(3), 90-98.
[8] Davarpanahjazi M., Flynn D., "Constructing user requirements: a social process for a social context", Information System Journal, 8(1), January 1998, 53-83.
[9] ANSI/IEEE std 1016-1-1993, Guide to Software Design Description, 1993.
[10]ANSI/IEEE std 1016-1987, Recommended Practice for Software Design Documentation, 1987.
[11] IEEE std 1012-1986, IEEE Standard for Software Verification and Validation Plans, 1986.
[12] IEEE std 829-1983, IEEE Standard for Software Test Documentation, 1983.
[13] ANSI/IEEE std 830-1984, IEEE Guide to Software Requirements Specifications, 1984.
[14] IEEE std 1063-1987, IEEE Standard for Software User Documentation, 1987.

 


مطالب مشابه :


مستندات نیازمندی ها و نقش آن در موفقیت یک پروژه نرم افزاری

برای انجام یک پروژه نرم افزاری معمولاً مشتری نیازهایش را در یک فرمت خاص (چه مکتوب و چه شفاهی




چگونه یک پروپوزال خوب برای نرم افزار بنویسیم؟

طرح مديريت پروژه نرم افزار ( spmp ) - استانداردهاي پروژه - مستندات طراحي و توسعه




مندرجات سند نيازهاي نرم افزار (SRD)

مندرجات طرح مديريت پروژه نرم افزار راهنماي كاربر نرم افزار در مجموعه مستندات پروژه.




معرفی نرم افزار PRIMAVERA EXPEDITION

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




Agile Software Development

مستندات نرمافزار بايد اهميت نقش كاربران سيستم در پروژهنرمافزار را نمي‌توان




تطبيق استانداردهاي موجود براي مستند سازي سيستم هاي اطلاعاتي در ايران

مستندات نرمافزار، به هر مطلبي اين سند هميشه قبل از آغاز يك پروژه نرم‌افزاري تهيه




طراحی نرم افزار

مدل تولید سریع نرم افزار. مدیریت پروژه دشوار مستندات نرمافزار




برچسب :