صفحه 195 منبع

17. مدل ساختاری

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

در فعالیت موازی، مشخصات نیازمندی‌ها (Requirements Specification) با جزئیات به ابزارها، عناصر، خدمات، ویژگی‌ها و انواع شیء موجود در محیط پیاده‌سازی تبدیل می‌شود؛ عناصری که عملیات سیستم را در قالب مشخصات رسمیِ پردازش‌های پرس‌وجو و به‌روزرسانی/تغییر تعریف می‌کنند.

دو گروه در این فعالیت‌ها مشارکت دارند:

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

پیش‌شرط‌های فعالیت‌های ماژول:

محصولات/اسناد مدیریتی:

• برنامه‌های ماژول طراحی منطقی سیستم؛
• روش‌های کنترل ماژول طراحی منطقی سیستم؛
• تصمیم انتخاب گزینه فنی سیستم.

مواد ورودی:

• اطلاعات ارزیابی‌شده برنامه‌ریزی ظرفیت؛
• راهنمای محیطی در سطح سازمان؛
• منشور پروژه؛
• مشخصات نیازمندی‌ها؛
• گزینه منتخب سازمان‌دهی سیستم.

مواد مرجع:

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

صفحه 196 منبع

17. مدل ساختاری

محصولات:

• طراحی منطقی سیستم.

فعالیت‌ها:

• مرحله 4: گزینه‌های فنی سیستم؛
• مرحله 5: طراحی منطقی سیستم.

17.10 مرحله 4: گزینه‌های فنی سیستم

هدف مرحله:

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

شرح:

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

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

در انتخاب گزینه فنی سیستم باید اعضای مدیریتی‌ای مشارکت کنند که اختیار منابع مالی را دارند؛ زیرا قضاوت آنان درباره ارزش دریافت‌شده در برابر پول سرمایه‌گذاری‌شده تعیین‌کننده است.

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

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

صفحه 197 منبع

17. مدل ساختاری

پیش‌شرط‌های فعالیت‌های مرحله:

محصولات/اسناد مدیریتی:

• روش‌های کنترل مرحله 4؛
• برنامه‌های مرحله 4؛
• تصمیم انتخاب گزینه فنی سیستم.

مواد ورودی:

• اطلاعات ارزیابی‌شده برنامه‌ریزی ظرفیت؛
• راهنمای محیطی در سطح سازمان؛
• منشور پروژه؛
• مشخصات نیازمندی‌ها؛
• گزینه منتخب سازمان‌دهی سیستم.

مواد مرجع:

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

محصولات:

• راهنمای محیطی در سطح کاربرد؛
• مبنای برنامه‌ریزی ظرفیت؛
• شرح محیط فنی برای گزینه منتخب؛
• گزینه‌های فنی سیستم.

تکنیک‌ها:

• طراحی گفت‌وگو (Dialogue Design)؛
• طراحی فیزیکی داده؛
• طراحی فیزیکی فرایند؛
• تدوین گزینه‌های فنی سیستم.

صفحه 198 منبع

17. مدل ساختاری

فعالیت‌ها:

• گام 410: تعیین گزینه‌های فنی سیستم؛
• گام 420: انتخاب گزینه فنی سیستم.

17.10.1 گام 410: تدوین گزینه‌های فنی سیستم

هدف گام:

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

شرح:

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

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

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

مدیر پروژه، تحلیلگر ارشد نیازمندی‌ها، نمایندگان کاربران، اعضای گروه کاری و تأمین‌کنندگان خدمات فناوری اطلاعات در این فعالیت‌ها شرکت دارند. در بعضی موارد گزینه‌ها توسط پیمانکاران رقیب تدوین می‌شوند که با اطلاع مدیر پروژه با کاربران همکاری می‌کنند. گاهی این رویکرد «مطالعه طراحی فنی» نامیده می‌شود.

صفحه 199 منبع

17. مدل ساختاری

مبانی شروع:

• اطلاعات ارزیابی‌شده برنامه‌ریزی ظرفیت؛
• منشور پروژه؛
• مشخصات نیازمندی‌ها؛
• گزینه منتخب سازمان‌دهی سیستم.

مبانی مرجع:

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

وظایف:

10. با استفاده از فهرست نیازمندی‌ها، منشور پروژه، گزینه منتخب سازمان‌دهی سیستم و سایر اسناد راهبردی، محدودیت‌های سیستم شناسایی شوند. همه گزینه‌ها باید این محدودیت‌ها را رعایت کنند.

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

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

40. نسخه نخست هر گزینه فنی سیستم تهیه شود و موارد زیر را در بر گیرد:

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

صفحه 200 منبع

17. مدل ساختاری

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

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

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

محصولات ایجاد/اصلاح‌شده:

• اطلاعات برنامه‌ریزی ظرفیت؛
• گزینه‌های فنی سیستم.

17.10.2 گام 420: انتخاب گزینه فنی سیستم

هدف گام:

• ارائه گزینه‌های فنی سیستم به مدیریت پروژه و فراهم‌کردن امکان انتخاب راه‌حل فنی برای نیازمندی‌های سیستم؛
• دریافت و مستندسازی تصمیم انتخاب، با تعیین چارچوب ماژول طراحی فیزیکی سیستم.

شرح:

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

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

صفحه 201 منبع

17. مدل ساختاری

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

در این گام مدیر پروژه، تحلیلگر ارشد نیازمندی‌ها و تأمین‌کنندگان خدمات فناوری اطلاعات مشارکت دارند.

مبانی شروع:

• اطلاعات ارزیابی‌شده برنامه‌ریزی ظرفیت؛
• راهنمای محیطی در سطح سازمان؛
• گزینه‌های فنی سیستم.

مبانی مرجع:

• مشخصات نیازمندی‌ها.

وظایف:

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

20. بخش‌های گزینه فنی منتخب مطابق تصمیم اتخاذشده بازنگری شوند. معماری فنی/تکنیکی سیستم برای گزینه منتخب تدوین گردد.

30. با استفاده از برنامه‌ریزی ظرفیت، اطمینان حاصل شود سیستم منتخب همچنان نیازمندی‌های سطح خدمت را برآورده می‌کند.

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

محصولات ایجاد/اصلاح‌شده:

• راهنمای محیطی در سطح کاربرد؛
• اطلاعات برنامه‌ریزی ظرفیت؛
• شرح محیط فنی برای گزینه منتخب؛
• گزینه‌های فنی سیستم.

صفحه 202 منبع

17. مدل ساختاری

17.11 مرحله 5: طراحی منطقی سیستم

هدف مرحله:

• تعیین تفصیلی ساختار فرایندهای پردازش داده که در مشخصات نیازمندی‌ها به‌صورت ضمنی بیان شده‌اند؛
• تعریف رابط پردازش میان انسان و رایانه در سطح مناسب جزئیات و در قالب گفت‌وگوها؛
• تهیه مشخصات تفصیلی که:
• غیررویه‌ای (Non-procedural) باشد؛
• در طیفی از محیط‌های فنی قابل پیاده‌سازی باشد؛
• بیشترین امکان استفاده مجدد را فراهم کند.

شرح:

مشخصات نیازمندی‌ها به اسناد تشکیل‌دهنده خود تفکیک می‌شود و سپس دستخوش تبدیل مهمی خواهد شد.

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

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

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

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

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

پیش‌شرط‌های فعالیت‌های مرحله:

محصولات/اسناد مدیریتی:

• روش‌های کنترل مرحله 5؛
• برنامه‌های مرحله 5.

مواد ورودی:

• راهنمای محیطی؛
• مشخصات نیازمندی‌ها.

صفحه 203 منبع

17. مدل ساختاری

مواد مرجع:

• ساختارهای فرمان حاصل از نمونه اولیه؛
• ساختارهای منو حاصل از نمونه اولیه؛
• ارزیابی نمونه اولیه؛
• قالب‌های گزارش حاصل از نمونه اولیه.

محصولات:

• طراحی منطقی سیستم.

تکنیک‌ها:

• طراحی گفت‌وگو؛
• مدل‌سازی فرایند مفهومی.

فعالیت‌ها:

• گام 510: تعیین گفت‌وگوهای کاربر؛
• گام 520: طراحی پردازش‌های به‌روزرسانی؛
• گام 530: طراحی پردازش‌های پرس‌وجو.

17.11.1 گام 510: تعیین گفت‌وگوهای کاربر

هدف گام:

• تعیین ساختار هر گفت‌وگو؛
• تعیین ساختارهای منو و فرمان.

شرح:

گفت‌وگوها از نسخه نخست توابعی پشتیبانی می‌کنند که پیش‌تر در گام 330 تعیین شده‌اند. در این گام باید ساختار گفت‌وگوها، همراه با نیازهای ناوبری درون هر گفت‌وگو و میان گفت‌وگوها، تعیین شود.

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

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

صفحه 204 منبع

17. مدل ساختاری

مبانی شروع:

• فهرست داده؛
• شرح توابع؛
• ساختارهای داده ورودی/خروجی؛
• فهرست نیازمندی‌ها؛
• راهنمای محیطی در سطح سازمان و کاربرد؛
• ماتریس نقش کاربر–تابع؛
• مدل گردش کار.

مبانی مرجع:

• ساختارهای فرمان، حاصل از نمونه اولیه گام 350؛
• ساختارهای منو، حاصل از نمونه اولیه گام 350؛
• ارزیابی نمونه اولیه.

وظایف:

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

20. در هر گفت‌وگو مسیرهای ناوبری ممکن مشخص و جدول کنترل گفت‌وگو تعیین شود.

30. برای هر نقش کاربری، سلسله‌مراتب منو یا درخت منو تعیین شود. در پایان هر گفت‌وگو، ساختارهای کنترلی معتبر و مسیرهای ناوبری مشخص شوند.

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

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

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

محصولات ایجاد/اصلاح‌شده:

• ساختارهای فرمان؛
• جدول‌های کنترل گفت‌وگو؛
• اطلاع‌رسانی و خدمات راهنما در سطح گفت‌وگو؛
• نمودارهای ساختار گفت‌وگو.

صفحه 205 منبع

17. مدل ساختاری

ادامه محصولات:

• شرح عناصر گفت‌وگو؛
• ساختارهای منو؛
• فهرست نیازمندی‌ها؛
• شرح مشاغل.

17.11.2 گام 520: طراحی پردازش‌های به‌روزرسانی

هدف گام:

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

شرح:

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

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

برای هر رویداد، بر پایه نمودار اثر رویداد مربوط که در گام 360 تعیین شده است، یک مدل فرایند پردازشی واحد ساخته می‌شود و عملیات و شرایط لازم به آن نسبت داده می‌شود؛ کنترل‌های معنایی نیز باید در نظر گرفته شوند.

اعضای گروه طراحی فرایند در این گام شرکت می‌کنند.

مبانی شروع:

• فهرست داده؛
• نمودارهای اثر رویداد؛
• تاریخچه عمر موجودیت‌ها؛
• شرح توابع؛
• مدل منطقی داده سیستم موردنیاز.

وظیفه 10:

نمودار اثر رویداد به مدل فرایند پردازش تبدیل شود.

صفحه 206 منبع

17. مدل ساختاری

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

30. خروجی‌های مربوط به مدیریت خطا تعیین شوند.

محصولات ایجاد/اصلاح‌شده:

• مدل‌های فرایندهای تغییر/به‌روزرسانی.

17.11.3 گام 530: تعیین پردازش‌های پرس‌وجو

هدف گام:

• کامل‌کردن مشخصات پردازش‌های پایگاه داده مربوط به پرس‌وجوها؛
• تعیین مدیریت خطا برای پرس‌وجوها.

شرح:

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

اعضای گروه طراحی فرایند در این گام مشارکت دارند.

مبانی شروع:

• فهرست داده؛
• مسیرهای پرس‌وجو؛
• مدل منطقی داده سیستم موردنیاز.

وظیفه 10:

مسیر پرس‌وجوی مربوط به پرس‌وجو به مدل فرایند مفهومی تبدیل شود.

صفحه 207 منبع

17. مدل ساختاری

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

30. خروجی‌های مربوط به خطا تعیین شوند.

محصولات ایجاد/اصلاح‌شده:

• مدل‌های فرایند مفهومی پرس‌وجو.

17.12 ماژول PD: طراحی فیزیکی سیستم

این ماژول تنها از یک مرحله تشکیل می‌شود: مرحله 6، طراحی فیزیکی سیستم.

17.13 مرحله 6: طراحی فیزیکی سیستم

هدف مرحله:

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

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

شرح:

این مرحله فعالیت‌های زیر را شامل می‌شود:

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

صفحه 208 منبع

17. مدل ساختاری

• بهینه‌سازی؛
• بازبینی و مرور.

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

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

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

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

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

پیش‌شرط‌های فعالیت‌های مرحله:

محصولات/اسناد مدیریتی:

• توافق درباره راهبرد طراحی فیزیکی؛
• روش‌های کنترل مرحله 6؛
• برنامه‌های مرحله 6.

مواد ورودی:

• استانداردهای توسعه در سطح سازمان؛
• مشخصات منطقی سیستم؛
• مشخصات محیط فیزیکی.

محصولات:

• استانداردهای توسعه در سطح کاربرد؛
• طراحی فیزیکی سیستم.

تکنیک‌ها:

• طراحی فیزیکی داده.

صفحه 209 منبع

17. مدل ساختاری

تکنیک دیگر:

• طراحی پردازش‌های فیزیکی.

فعالیت‌ها:

• گام 610: آماده‌سازی برای طراحی فیزیکی؛
• گام 620: تهیه طرح فیزیکی داده؛
• گام 630: تهیه طرح پیاده‌سازی اجزای تابع؛
• گام 640: بهینه‌سازی طرح فیزیکی داده؛
• گام 650: نهایی‌کردن مشخصات تابع؛
• گام 660: نهایی‌کردن رابط فرایند–داده.

17.13.1 گام 610: آماده‌سازی برای طراحی فیزیکی

هدف گام:

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

شرح:

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

شیوه‌ای که محیط فیزیکی این خدمات را ارائه می‌کند به‌طور مستقیم بر طراحی سیستم اثر دارد. محیط فیزیکی باید بر اساس روش‌هایی که برای ارائه این خدمات به کار می‌گیرد طبقه‌بندی شود.

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

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

• ایجاد استانداردهای استفاده از سامانه پردازش فیزیکی؛
• ایجاد استانداردهای مشخصات برنامه، از جمله قالب مشخصات؛

صفحه 210 منبع

17. مدل ساختاری

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

اگر راهنمای اختصاصی محصول وجود داشته باشد، برای مثال راهنمای استفاده از یک DBMS مشخص در SSADM، بیشتر اطلاعات لازم را در بر خواهد داشت. با این حال، بعضی فعالیت‌های این گام همچنان برای درک و ارزیابی امکانات شرح‌داده‌شده در راهنمای مرتبط ضروری‌اند.

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

مبانی شروع:

• استانداردهای توسعه در سطح سازمان؛
• مشخصات منطقی سیستم؛
• مشخصات محیط فیزیکی.

وظایف:

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

20. فرم‌های برآورد فضای ذخیره‌سازی و زمان پاسخ برای DBMS منتخب طراحی شوند.

30. استانداردهای استفاده از سامانه پردازش فیزیکی و DBMS تعیین شوند.

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

50. استانداردهای نام‌گذاری یا قراردادهای نام‌گذاری کاربرد تعیین شوند.

60. استانداردهای مشخصات برنامه و طراحی داده توسعه داده شوند و ساختار شکست محصول و شرح محصولات طراحی فیزیکی تعیین گردد. شبکه فعالیت‌ها و شرح فعالیت‌های ادامه مرحله 6، مانند شبکه برنامه‌ریزی یا نمودار گانت، نیز تهیه شود. این موارد می‌توانند گونه‌های مناسبِ مدل ساختاری استاندارد برای محیط پروژه باشند.

صفحه 211 منبع

17. مدل ساختاری

70. تهیه راهنماهای کاربری، عملیات/بهره‌برداری و آموزش آغاز شود. این محصولات در چرخه عمر توسعه محصول مستقلی تهیه می‌شوند که ممکن است تا مراحل ساخت و استقرار پروژه ادامه یابد.

80. درباره راهبرد طراحی فیزیکی با مدیریت پروژه توافق حاصل شود.

محصولات ایجاد/اصلاح‌شده:

• استانداردهای توسعه در سطح کاربرد.

17.13.2 گام 620: تهیه طرح فیزیکی داده

هدف گام:

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

شرح:

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

راهبرد تهیه طرح فیزیکی اولیه داده را راهبرد طراحی فیزیکی تعیین می‌کند. این راهبرد بیان می‌کند کدام امکانات DBMS باید مورد استفاده قرار گیرند و چگونه محدودیت‌های آن به حداقل برسند.

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

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

مبانی شروع:

• استانداردهای توسعه در سطح کاربرد؛
• نمودارهای اثر رویداد؛
• مسیرهای پرس‌وجو؛
• شرح توابع؛
• مدل منطقی داده سیستم موردنیاز.

صفحه 212 منبع

17. مدل ساختاری

وظایف:

10. ویژگی‌های مدل منطقی داده سیستم موردنیاز که برای طراحی فیزیکی داده لازم‌اند شناسایی شوند.

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

30. نقاط آغازین یا عناصر ریشه‌ای سلسله‌مراتب فیزیکی شناسایی شوند.

40. گروه‌های فیزیکی داده مجاز برای هر موجودیت غیرریشه تعیین شوند.

50. در صورت وجود چند گروه ممکن، قاعده «کمترین وقوع وابسته» اعمال شود.

60. اندازه بلوک تعیین شود.

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

80. قواعد طراحی داده اختصاصی محصول با استفاده از تصمیم‌های اتخاذشده در گام 610 «آماده‌سازی برای طراحی فیزیکی» درباره بهره‌گیری از امکانات DBMS اعمال شوند.

محصولات ایجاد/اصلاح‌شده:

• طرح فیزیکی اولیه داده، نسخه 1؛
• برآورد نیاز فضای ذخیره‌سازی.

17.13.3 گام 630: تهیه طرح پیاده‌سازی اجزای تابع

هدف گام:

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

شرح:

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

صفحه 213 منبع

17. مدل ساختاری

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

تعریف فرایندهای دسترسی به پایگاه داده باید تا آغاز گام 660 «نهایی‌کردن رابط فرایند–داده» به تعویق افتد، زیرا این فرایندها بخشی از رابط فرایند–داده هستند.

اعضای گروه طراحی فیزیکی در این گام شرکت دارند و برای مسائل مربوط به رابط کاربری، نمایندگان کاربران نیز به گروه افزوده می‌شوند.

مبانی شروع:

• استانداردهای توسعه در سطح کاربرد؛
• طراحی منطقی.

وظایف:

10. پردازش‌های تکراری شناسایی و حذف شوند.

20. شرح فرایندهای مشترک شناسایی یا بازبینی شود.

وظایف 30 تا 80 برای هر تابع انجام شوند:

30. واحدهای اجرایی مؤثر تعیین شوند.

40. مدیریت خطاهای نحوی مشخص شود.

50. کنترل‌ها و مدیریت خطاهای کنترلی مشخص شوند.

60. قالب ورودی‌ها و خروجی‌های فیزیکی مشخص شود.

70. گفت‌وگوهای فیزیکی مشخص شوند.

80. اجزای تابعی که در سامانه پردازش فیزیکی می‌توان به‌صورت غیررویه‌ای مشخص کرد، به‌جز اجزای دسترسی به پایگاه داده، توصیف شوند.

محصولات ایجاد/اصلاح‌شده:

• طرح پیاده‌سازی اجزای تابع؛
• شرح توابع؛
• فهرست نیازمندی‌ها.

صفحه 214 منبع

17. مدل ساختاری

17.13.4 گام 640: بهینه‌سازی طرح فیزیکی داده

هدف گام:

ایجاد طرح فیزیکی داده‌ای که نیازهای مربوط به فضای ذخیره‌سازی و زمان پاسخ را برآورده کند.

شرح:

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

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

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

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

اعضای گروه طراحی فیزیکی در این گام مشارکت می‌کنند و نمایندگان کاربر نیز برای تعیین نحوه ارزیابی مصالحه‌های ناشی از تغییر طرح و نحوه ارائه آن‌ها به مدیریت حضور دارند.

مبانی شروع:

• استانداردهای توسعه در سطح کاربرد؛
• نمودار اثر رویداد؛
• مسیرهای پرس‌وجو؛
• مدل‌های پردازش پرس‌وجو؛
• شرح توابع؛
• طرح اولیه داده؛
• فهرست نیازمندی‌ها؛
• برآورد نیاز فضای ذخیره‌سازی؛
• مدل‌های پردازش به‌روزرسانی.

مبانی مرجع:

• مدل منطقی داده سیستم موردنیاز.

صفحه 215 منبع

17. مدل ساختاری

وظایف:

10. نیاز فضای ذخیره‌سازی برآورد شود. طرح داده به‌گونه‌ای تغییر یابد که محدودیت‌های ذخیره‌سازی را در نظر بگیرد و در حد امکان تطابق یک‌به‌یک با طرح منطقی حفظ شود.

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

محصولات ایجاد/اصلاح‌شده:

• شرح توابع، شامل نیازهای مرتب‌سازی؛
• طرح فیزیکی داده بهینه‌شده؛
• فهرست نیازمندی‌ها، شامل نیازهای بهینه‌سازی؛
• برآورد فضا؛
• برآورد زمان.

17.13.5 گام 650: نهایی‌کردن مشخصات تابع

هدف گام:

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

شرح:

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

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

مبانی شروع:

• راهنمای توسعه در سطح کاربرد؛
• طرح پیاده‌سازی اجزای تابع؛
• شرح توابع، شامل نیازهای مرتب‌سازی.

صفحه 216 منبع

17. مدل ساختاری

ادامه مبانی شروع:

• طراحی منطقی؛
• فهرست نیازمندی‌ها.

وظایف:

وظایف 10 و 20 برای هر تابع اجرا شوند.

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

20. پردازش‌های منطقی در قالب برنامه‌های فیزیکی یا واحدهای اجرا سازمان‌دهی شوند.

محصولات ایجاد/اصلاح‌شده:

• طرح پیاده‌سازی اجزای تابع؛
• شرح توابع؛
• فهرست نیازمندی‌ها.

17.13.6 گام 660: نهایی‌کردن رابط فرایند–داده

هدف گام:

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

اهداف گروه توسعه در این محدوده عبارت‌اند از:

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

شرح:

اجزای دسترسی به داده در طرح پیاده‌سازی اجزای تابع باید با طرح فیزیکی داده بهینه‌شده مقایسه شوند تا «نماهای» متفاوت داده شناسایی گردند. اجزای طرح پیاده‌سازی تابع پایگاه داده را همان‌گونه می‌بینند که مدل منطقی داده سیستم موردنیاز نشان می‌دهد، اما طرح فیزیکی داده ـ برای مثال در یک DBMS سلسله‌مراتبی ـ ممکن است داده‌ها را در امتداد مسیرهای ناوبری دیگری ذخیره کند.

صفحه 217 منبع

17. مدل ساختاری

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

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

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

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

در این گام طراح ارشد برای تصمیم‌های مربوط به اجرای راهبرد طراحی برنامه، و نیز متخصصان پایگاه داده و محیط فیزیکی کاربرد مشارکت دارند.

مبانی شروع:

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

مبانی مرجع:

• مشخصات محیط فیزیکی.

صفحه 218 منبع

17. مدل ساختاری

وظایف:

10. همه تفاوت‌های میان اجزای تابعِ دسترسی به داده که مطابق مدل منطقی داده سیستم موردنیاز عمل می‌کنند و طرح فیزیکی داده بهینه‌شده شناسایی شوند. بعضی از این تفاوت‌ها در فهرست توابع اصلاح‌شده، خروجی گام 640 «بهینه‌سازی طرح فیزیکی داده»، پیشنهاد شده‌اند و ناشی از مصالحه‌های ایجادشده طی بهینه‌سازی‌اند؛ مصالحه‌هایی که ممکن است موجودیت‌ها و روابطی را ایجاد یا حذف کرده باشند.

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

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

40. همه اجزای پردازشی جدید ایجادشده مقایسه و موارد تکراری مشخص شوند.

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

60. تصمیم‌های طراحی که میزان برآورده‌شدن نیازمندی‌ها را محدود می‌کنند در فهرست نیازمندی‌ها ثبت شوند.

محصولات ایجاد/اصلاح‌شده:

• طرح پیاده‌سازی اجزای تابع؛
• شرح توابع؛
• رابط فرایند–داده؛
• فهرست نیازمندی‌ها.