صفحه 1 منبع

1. مقدمه‌ای بر روش‌شناسی تحلیل و طراحی SSADM

مالک و متولی SSADM (Structured Systems Analysis and Design Method؛ روش ساخت‌یافته تحلیل و طراحی سیستم‌ها)، سازمان CCTA (Central Computer and Telecommunications Agency؛ آژانس مرکزی رایانه و مخابرات) است که زیرمجموعه وزارت خزانه‌داری بریتانیا به‌شمار می‌آید و بر تهیه و ایجاد سیستم‌های اطلاعاتی دولتی نظارت می‌کند و در حوزه سیستم‌های اطلاعاتی و فناوری اطلاعات، سیاست‌های دولت را شکل می‌دهد. توسعه بعدی این روش تحت نظارت گروه بین‌المللی کاربران SSADM (International SSADM User's Group یا ISUG) و نهاد صلاحیت‌دار آن انجام می‌شود. در انجمن رایانه بریتانیا (British Computer Society یا BCS) نیز نهادی وجود دارد که از طریق ایجاد نظام آزمون، اجرای ضوابط حرفه‌ای و کنترل رعایت آن‌ها را پیگیری می‌کند.

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

SSADM یک سیستم باز است؛ به این معنا که عمومی است، همه می‌توانند به آن دسترسی داشته باشند و بدون پرداخت هزینه مجوز یا دریافت اجازه از CCTA از آن استفاده کنند.

این راهبردِ سیستم باز با رویه دولت بریتانیا در مورد دیگر استانداردهای باز دولتی، مانند OSI و POSIX، هماهنگ است. SSADM عمداً به‌گونه‌ای طراحی شد که ورود آن، بازار را دوباره تنظیم کند، رقابت میان محصولات و خدمات - برای مثال خدمات مشاوره - را افزایش دهد و بازار را از محدودیت‌های ناشی از پرداخت حق امتیاز به مالک روش آزاد کند. یکی از اهداف اساسی راهبرد SSADM تضمین عملکرد مؤثر بازار خدمات و تأمین نیازهای کاربران تا بیشترین حدی است که ظرفیت بازار اجازه می‌دهد. به این ترتیب مدیر مسئول توسعه، در برابر مشاوران، مدرسان یا مجریان پیاده‌سازی به وضعیت وابسته و آسیب‌پذیر گرفتار نمی‌شود؛ اگر پس از مدتی آن‌ها را مناسب‌ترین افراد برای انجام کار نداند، می‌تواند شریک قراردادی را بدون از بین رفتن سرمایه‌گذاری‌های قبلی - پول، زمان و غیره - جایگزین کند.

در نسخه‌های 4.0 و 4.2 SSADM راهنمای دقیق وجود دارد که استانداردهای تضمین کیفیت و رویه‌های مرتبط، به‌ویژه ISO 9001، در کجا و چگونه باید به‌کار روند. این راهنماها تا حد زیادی شیوه استقرار رویه‌های کنترل کیفیت ISO 9001 را برای کسانی که قصد استفاده از آن را دارند مشخص می‌کنند.

مدیریت و راهبری پروژه از طریق روش‌شناسی PRINCE انجام می‌شود که سازگاری خوبی با SSADM دارد.

صفحه 2 منبع

1. مقدمه‌ای بر روش‌شناسی تحلیل و طراحی SSADM

فلسفه:

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

مدل‌ها:

نمودار موجودیت-رابطه، جریان داده، تاریخچه حیات موجودیت و رویداد-اثر (نمودارهای شبیه Jackson)، همراه با تکنیک رابطه‌ای، مهم‌ترین ابزارهایی هستند که SSADM به کمک آن‌ها سیستم را مدل و توصیف می‌کند.

پوشش چرخه حیات:

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

محصولات تحویلی:

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

متن‌های شکل 1: برنامه‌ریزی راهبردی؛ مدیریت پروژه؛ SSADM؛ مطالعه جامع؛ نیازمندی؛ تحلیل؛ مشخصات منطقی سیستم؛ طراحی؛ پیاده‌سازی/اجرای فیزیکی؛ آزمون؛ سیستم مؤثر؛ محصول عملیاتی؛ توسعه.

شکل 1 - SSADM و چرخه پروژه.

صفحه 3 منبع

1. مقدمه‌ای بر روش‌شناسی تحلیل و طراحی SSADM

پیش‌فرض‌ها:

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

1.1 نقاط تصمیم‌گیری در SSADM

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

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

• مطالعه امکان‌سنجی: دامنه، مرزها و مهم‌ترین پارامترهای سیستم و راهبرد توسعه سیستم متناسب با نیاز کاربران نهایی و با موافقت آنان تعیین می‌شود.
• گزینه‌های سازمان‌دهی سیستم (Business System Options): در اصل مشخص می‌کنند سیستم دقیقاً «چه کاری» باید انجام دهد.
• گزینه‌های پیاده‌سازی فنی: کاربران نهایی از میان راه‌حل‌های فنی/تکنیکی ممکن برای گزینه سازمان‌دهی منتخب انتخاب می‌کنند. این راه‌حل‌ها معمولاً دامنه وسیعی از گزینه‌های فنی قابل‌تصور را نشان می‌دهند. پس از انتخاب مشخص می‌شود سیستم «چگونه» آنچه را باید ارائه دهد محقق خواهد کرد.

1.2 دیگر ویژگی‌های SSADM

نسخه جاری با نام SSADM 4.2 یا SSADM4+ شناخته می‌شود و شامل موارد زیر است:

• هسته روش‌شناسی، یعنی SSADM 4.2؛
• راهنماهایی برای تطبیق SSADM با شرایط مختلف؛
• کتابخانه مهندسی سیستم‌های اطلاعاتی (Information System Engineering Library یا ISE).

صفحه 4 منبع

1. مقدمه‌ای بر روش‌شناسی تحلیل و طراحی SSADM

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

خود SSADM تکنیک‌های لازم برای انجام یک تحلیل کامل سیستم و نیز تعیین مشخصات و طراحی مؤلفه‌های فناوری اطلاعات یک سیستم اطلاعاتی را دربر دارد. همچنین تکنیک‌هایی برای ترسیم رابط کاربر و ارتباط انسان-ماشین ارائه می‌کند که به بیان فعالیت‌های دستی کمک می‌کنند تا سازمان بتواند ظرفیت‌های سیستم فناوری اطلاعات را به‌طور کامل به‌کار گیرد.

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

برچسب‌های شکل 2: مفاهیم و رویه‌ها؛ مدل فعالیت سازمانی؛ LDS فعلی؛ فهرست نیازمندی‌ها؛ LDM فعلی؛ DFM منطقی فعلی؛ DFD فعلی؛ DFM فعلی؛ بررسی/ارزیابی وضعیت؛ ساختار تصمیم؛ گزینه‌های سازمان‌دهی سیستم؛ گزینه‌های فناوری سیستم؛ ساخت سیستم؛ مشخصات؛ سازمان کاربران؛ راهنمای محیط کاربرد؛ فهرست کاربران؛ نقش‌های کاربری؛ مدل سازمان‌دهی کار؛ مدل مفهومی؛ طراحی داخلی؛ طراحی رابط سیستم؛ DFM موردنیاز؛ تعریف عملکرد؛ طراحی گفت‌وگو؛ عملکرد فیزیکی؛ پایگاه‌داده فیزیکی؛ رابط فرایند-داده؛ پردازش پرس‌وجو؛ LDM موردنیاز؛ تاریخچه‌های حیات موجودیت؛ نمودار تعامل؛ پردازش به‌روزرسانی؛ روابط 3NF؛ پرس‌وجوی رویداد؛ مسیرهای پرس‌وجو؛ راهنمای محیط سازمانی؛ گزینه‌های امکان‌سنجی.

شکل 2 - الگوی پایه توسعه سیستم و تکنیک‌ها.

صفحه 5 منبع

1. مقدمه‌ای بر روش‌شناسی تحلیل و طراحی SSADM

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

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

1.3 پیش‌زمینه مفاهیم کلیدی SSADM

دو مفهوم کلیدی SSADM4+ عبارت‌اند از الگوی پایه توسعه و معماری سه‌شِمایی (3-schema architecture). SSADM در آغاز بر بررسی نحوه عملکرد سازمان - محیط کسب‌وکار - تمرکز می‌کند تا نیازمندی‌های سیستم آینده را تا حد ممکن دقیق تعیین کند. سپس سیستم فناوری اطلاعات، مشخصات آن و رابط‌های اتصال به فرایندهای واقعی سازمانی را تعریف می‌کند. محصولات تحلیل و طراحی را می‌توان بر این الگوی پایه نگاشت کرد. حوزه‌های اصلی توسعه سیستم در این الگو عبارت‌اند از:

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

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

صفحه 6 منبع

1. مقدمه‌ای بر روش‌شناسی تحلیل و طراحی SSADM

I. مدل مفهومی:

A. قواعد سازمانی و عملیاتی؛

B. مدل منطقی داده (Logical Data Model)؛

C. مدل رفتار موجودیت (Entity Behaviour Model)؛

D. مدل فرایندهای پردازش داده در سطح مفهومی.

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

II. طراحی رابط سیستم (طرح خارجی):

A. رابط کاربر و گفت‌وگوی انسان-ماشین؛

B. داده‌ها و فایل‌های ورودی و خروجی؛

C. صفحه‌نمایش‌ها و گزارش‌ها؛

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

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

شکل 3 - معماری سه‌شِمایی.

صفحه 7 منبع

1. مقدمه‌ای بر روش‌شناسی تحلیل و طراحی SSADM

E. طراحی رابط سیستم حاصل یک سازش میان عوامل زیر است:

1. ساختار سازمان؛

2. کارایی و عملکرد سیستم؛

3. فناوری پیاده‌سازی رابط کاربر نهایی؛

4. خواسته‌های اختصاصی کاربران مختلف؛

5. الزامات امنیتی، حسابرسی و مانند آن.

III. طرح داخلی:

A. طراحی فیزیکی داده - در صورت نیاز با بهینه‌سازی برای نیازمندی‌های کارایی؛

B. رابط میان فرایندهای پردازش داده و داده‌های فیزیکی، یعنی رابط فرایند-داده؛

C. طرح فیزیکی نیز حاصل سازش میان عواملی مانند موارد زیر است:

1. زمان پاسخ، زمان‌بندی و محدودیت‌های زمانی؛

2. ذخیره‌سازی جانبی؛

3. قابلیت نگهداری.

1.4 معماری سه‌شِمایی پایگاه‌داده‌ها

در میانه دهه 1970 کمیته ANSI/SPARC [Tsichritzis78] معماری‌ای برای پایگاه‌داده ایجاد کرد. این معماری پیشنهادی جایگزین تقسیم‌بندی اولیه نگرش داده به «منطقی» و «فیزیکی» شد. مفهوم داده‌های «فیزیکی» - یعنی داده‌هایی که واقعاً ذخیره می‌شوند - در این معماری به‌صورت «شِمای داخلی» (Internal Schema) بیان می‌شود. آنچه پیش‌تر داده‌های منطقی نامیده می‌شد اکنون در قالب «شِمای خارجی» (External Schema) و «شِمای مفهومی» (Conceptual Schema) ظاهر می‌شود.

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

متن‌های شکل 4:

شِمای داخلی: رکوردها، ایندکس‌ها، زنجیره‌های اشاره‌گر، گروه‌های تکرارشونده و غیره.

شِمای مفهومی: موجودیت‌ها، روابط، زنجیره‌های اشاره‌گر، ویژگی‌ها.

شِمای خارجی: Viewها، زیرشِماها/پایگاه‌های داده و غیره.

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

شکل 4 - معماری پایگاه‌داده ANSI/SPARC.

صفحه 8 منبع

1. مقدمه‌ای بر روش‌شناسی تحلیل و طراحی SSADM

علاوه بر این، موارد زیر نیز به پذیرش حرفه‌ای عمومی رسیده‌اند:

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

1.5 تقسیم‌بندی مسئله توسعه سیستم

معماری سه‌شِمایی در واقع توسعه سیستم را به سه جریان عمده و موازی تقسیم می‌کند.

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

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

«طراحی رابط سیستم» یا طرح خارجی، طرح رابط کاربر را دربر می‌گیرد: تعریف فایل‌های داده ورودی/خروجی، صفحه‌ها و گزارش‌ها، شرح فرایند گفت‌وگو از طریق صفحه‌نمایش و تعیین فایل‌های ورودی/خروجی برنامه‌های پردازش دسته‌ای. طراحی رابط سیستم حاصل مصالحه میان عوامل متعدد است: ساختار سازمانی، ترجیح‌های فردی کاربران، الزامات حسابرسی، مسائل امنیتی، اهداف و سیاست‌های کاربران و غیره. بنابراین هر روش طراحی در این حوزه - یعنی طراحی فرایندهای ورودی و خروجی - به خلاقیت، ایده مستقل و توان نوآوری نیاز دارد. به همین دلیل رویکردهای اکتشافی/ابتکاری (heuristic)، از جمله رویکردهای مبتنی بر نمونه‌سازی، در این حوزه بسیار سودمندند.

«طرح داخلی» طراحی پایگاه‌داده فیزیکی را، در صورت نیاز تنظیم‌شده برای الزامات کارایی، و نیز رابطه داده-فرایند (PDI؛ Process-Data Interface) را مشخص می‌کند. رابط داده-فرایند شامل توصیف ذخیره‌سازی داخلی پایگاه‌داده و مشخصات رویه‌های بازیابی داده‌ای است که رکوردها را از پایگاه‌داده فیزیکی بازمی‌گردانند.

صفحه 9 منبع

1. مقدمه‌ای بر روش‌شناسی تحلیل و طراحی SSADM

وظیفه رابط داده-فرایند در اصل پنهان کردن جزئیات ذخیره‌سازی فیزیکی داده از فرایندهای منطقی پردازش داده است؛ زیرا این فرایندها موجودیت‌های مدل منطقی داده را می‌خوانند و می‌نویسند. ممکن است یک فرایند پردازش داده که بخشی از طرح داخلی است، ساختار داده مفهومی را از یک پایگاه‌داده فیزیکی با ساختاری کاملاً متفاوت گردآوری کند. طرح داخلی نیز طبیعتاً حاصل سازش میان ملاحظات مختلف است و ترتیب اهمیت آن‌ها به‌صورت ذهنی تعیین می‌شود: زمان، نیاز به فضای ذخیره‌سازی جانبی و قابلیت نگهداری. این امر دوباره نشان می‌دهد که یک «پاسخ کاملاً درست» و مطلق وجود ندارد و به رویکردهای اکتشافی و مبتنی بر نمونه‌سازی نیاز است.

1.6 تحلیل در برابر طراحی

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

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

1.7 جایگاه نمونه‌سازی

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

روش‌های نمونه‌سازی و روش‌های مبتنی بر heuristic - یعنی متکی به قواعد تجربی - در توسعه سیستم لازم‌اند؛ اما مفید بودن آن‌ها در برخی حوزه‌ها به این معنا نیست که باید در همه حوزه‌ها فقط به آن‌ها تکیه کرد. تجربه نشان می‌دهد رویکردهای نمونه‌سازی برای روشن کردن مسائل طراحی مناسب‌تر از فعالیت‌های اکتشافی مربوط به کشف «مدل مفهومی» هستند و حتی در حوزه دوم ممکن است نتیجه‌ای خلاف انتظار ایجاد کنند.

متن‌های شکل 5:

تحلیل: استخراج اطلاعات؛ کشف و آشکارسازی واقعیت‌ها؛ نتیجه‌گیری از واقعیت‌های شناخته‌شده.

طراحی: طراحی مهندسی؛ قواعد ابتکاری؛ قضاوت؛ تصمیم‌ها.

تبدیل: تبدیل مکانیکی؛ ترجمه؛ کامپایل/تدوین.

شکل 5 - تکنیک‌های مورد استفاده با تأکیدهای متفاوت در طراحی سیستم.

صفحه 10 منبع

1. مقدمه‌ای بر روش‌شناسی تحلیل و طراحی SSADM

یک روش‌شناسی دیگر وجود دارد که از مدل توسعه تکاملی یا افزایشی پیروی می‌کند و توسعه بسیار سریع سیستم را برای مسائل دقیقاً محدود و نه‌چندان بزرگ هدف قرار می‌دهد: DSDM (Dynamic System Development Method؛ روش توسعه پویای سیستم). ویژگی‌های آن عبارت‌اند از:

• نمونه‌سازی پیش‌نیاز فناورانه دارد؛ یعنی گام‌های تحلیل، طراحی و ساخت سیستم به‌صورت یکپارچه توسط ابزار انتخاب‌شده پشتیبانی می‌شوند. مهم‌ترین اسناد و محصولات تحلیل و طراحی در همان ابزار تولید می‌شوند و ابزار، ساخت سیستم/برنامه را به‌طور خودکار پشتیبانی می‌کند؛
• به مدیریت پروژه قاطع و سخت‌گیرانه در قالب یک سازمان پروژه خوب‌ساخت نیاز است که بسیار شبیه ساختاری است که PRINCE پیشنهاد می‌کند؛
• در دسترس بودن فشرده کاربران ضروری است. در بازه زمانی تعریف‌شده توسط پروژه تقریباً به حضور صددرصدی آنان نیاز است، وگرنه برنامه زمانی قابل حفظ نیست؛
• این رویکرد توسعه سریع (RAD؛ Rapid Application Development) فقط جایی قابل استفاده است که برای سیستم مورد نظر، در خود سازمان یا در سازمانی با فعالیت مشابه، نمونه یا سابقه‌ای وجود داشته باشد. برای سرمایه‌گذاری‌های فناوری اطلاعات کاملاً «سبز» مناسب نیست. برای نمونه، در یک بانک می‌توان خدمت جدید حساب جاری یا کارت بانکی را در کنار خدمات موجود راه‌اندازی کرد، یا در یک شرکت بیمه نوع جدید بیمه عمر یا نوع جدید بیمه‌نامه و زیرساخت رایانه‌ای و اطلاعاتی لازم برای آن را ایجاد کرد.

1.8 تقسیم‌بندی مسئله ساخت/پیاده‌سازی سیستم

معماری سه‌شِمایی تنها یک دیدگاه برای تحلیل سیستم نیست؛ در پایان توسعه، بخش‌های مختلف آن به‌صورت کد برنامه‌های گوناگون سیستم پیاده‌سازی‌شده ظاهر می‌شوند. در وضعیت نهایی سیستم، کد برنامه از سه عنصر تشکیل می‌شود:

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

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

صفحه 11 منبع

1. مقدمه‌ای بر روش‌شناسی تحلیل و طراحی SSADM

«مدل مفهومی» می‌تواند پشت چند «طراحی رابط سیستم» مختلف دوباره استفاده شود. برای کاربران با نیازهای متفاوت یا برای سیستم‌های متفاوت مدیریت رابط کاربر، رابط‌های کاربری گوناگون می‌توان ایجاد کرد. کد «مدل مفهومی» همچنین میان پیاده‌سازی‌های مختلف ذخیره‌سازی فیزیکی - «طرح داخلی» - قابل استفاده مجدد است؛ می‌توان برای نسخه‌های متفاوت و بهینه‌شده مدل داده، یا متناسب با ویژگی‌های سیستم‌های مدیریت پایگاه‌داده مختلف، رابط‌های داده-فرایند گوناگونی ساخت.

1.9 دیدگاه‌های مرتبط

گروه Object Management Group یا OMG، که یک گروه حرفه‌ای مرتبط با سیستم‌های شیءگراست، تقسیم‌بندی سه‌گانه‌ای مشابه معماری سه‌شِمایی دارد. نگاشت میان این دو به‌شکل زیر است:

• مدل مفهومی - تحلیل؛
• طراحی رابط سیستم - طراحی؛
• طرح داخلی - نگاشت/تطبیق.

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

متن‌های شکل 6:

راهبرد: روش «نرم»، مدل سازمانی، مطالعه راهبردی.

منطقی: کشف و مدل‌سازی «جهان».

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

دقیق/«سخت»: بخش بزرگ‌تر تلاش، پیاده‌سازی با نرم‌افزار، و کاربر در صورت اشتباه آن را مشاهده می‌کند.

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

شکل 6 - معماری کاربرد.

صفحه 12 منبع

1. مقدمه‌ای بر روش‌شناسی تحلیل و طراحی SSADM

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

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