بررسی روند تکاملی متدولوژی های توسعه سیستم های اطلاعاتی در موقعیت های مختلف سازمانی

واژگان کلیدی: سیستم های اطلاعاتی، توسعه، متدولوژی توسعه سیستم های اطلاعاتی، سازمان

چکیده

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

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

مقدمه

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

با توجه به پیچیدگی سیستم ها ، نیاز شدیدی به توسعه بود ، در حالی که وضعیت ، روز به روز بحرانی تر می شد. به همین دلیل رویکردهای متدولوژی به توسعه سیستم ها پدیدار گشت. توجه به متدولوژی در دهه 70 تا 80 بسیار زیاد بود. در این دهه ها بحث ، بیشتر روی دو رویکرد سخت و نرم از توسعه سیستم های اطلاعاتی قرار داشت. در این دوران سازمان های بزرگ و دولت ها از متدولوژی های خاصی برای مدیریت پروژه های IT خود استفاده کردند. مثلا SSADM توسط دولت UK و IDEF توسط US بکار گرفته شد. این دو متدولوژی مبتنی بر رویکرد سخت بودند.

استفاده از این متدولوژی ها با مشکلاتی همراه شد. مثلا اینکه آن ها هرگز کار نمی کردند یا با تاخیر طولانی کار می کردند و یا با عملکرد پایین خود انتظارات کاربران را برآورده نمی نمودند. در اواخر دهه 80 انتقادات نسبت به متدولوژی افزایش یافت و در دهه 90 مطالعات روی این موضوع کاهش یافت و آن هم به دلیل مخالفت با مکتب متدولوژی و شکست های پی در پی آن و مورد دیگر تغییر الزامات و نیازمندی های سازمان ها بود. تحول در تکنولوژی و ساختار سازمان ها عللی دیگر بر عدم پذیرش متدولوژی ها بود[8].

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

تعریف متدولوژی توسعه سیستم های اطلاعاتی

در ارتباط با تعریف متدولوژی دیدگاه ها و نظرات متفاوتی موجود است. همین طور از نگاه ها ومنظرهای متنوعی به متدولوژی نگریسته شده است. Olerup در سال 1991 متدولوژی را اینگونه تعریف می کند: یک استراتژی که دلالت بر زیربخش های فرایند توسعه دارد. اصل تقسیم و تسخیر ، یک رویکرد مهندسی و ریاضی برای حل مسائل پیچیده می باشد[3]. متدولوژی های اولیه خیلی تحت تاثیر رشته های فنی و مهندسی بودند. شخصی به نام Langefors در سال 1973 توسعه سیستم ها را به عنوان یک فرایند علمی و عقلایی در نظر گرفت. متدولوژی در دو موضوع زیر تصمیم گیری می کند یک سیستم اطلاعاتی چه کاری را باید انجام دهد و یک سیستم اطلاعاتی بهتر است چگونه آن کار را انجام دهد[3].

Olerup در 1991 با پذیرفتن این نگرش علمی عقلایی ، فرایند پیچیده توسعه را به مراحل زیر تقسیم کرد: تجزیه و تحلیل نیازمندی ها ، طراحی راه حل ، و اجرای راه حل. افراد دیگری مثل Downs در 1992 فازهای دیگری را به این مراحل افزودند. مثل تحقیق و بررسی مقدماتی و نگهداری[3].

یک تعریف قدیمی تر از متدولوژی توسعه سیستم های اطلاعاتی توسط 1987 ، Checkland ، 1995 ، Hirschheim ، 1990 ، R.J Boland وجود دارد و عبارت است از: یک مجموعه ای از مفاهیم ، عقاید ، ارزش ها و اصول هنجاری که توسط منابع مورد حمایت قرار می گیرند[2].

در زمینه متدولوژی ، دو نقطه نظر وجود دارد: 1 – تعریف خاصی از متدولوژی وجود ندارد و این تعاریف موجود ممکن است با هم سازگاری نداشته باشند. 2 – ویژگی های متدولوژی که تقریبا در همه یا بخش کثیری از تعاریف مشترک است. بعضی از اندیشمندان مثل ، 1981 Chechland ، 1995 Hirschheim و 1990 Vonkبین متد و متدولوژی تفاوت قائل شدند. متدولوژی جامع تر از متد است. متدولوژی برای ارزیابی میزان منطقی و سیستماتیک بودن یک متد معین بکار می رود. در حالی که متد ، روشی برای اجرای فعالیت در حالت ساخت یافته می باشد[8].

ویژگی های متدولوژی ها و اجزای آن ها

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

متدولوژی از سه بخش اصلی تشکیل شده است[8] : 1 – ساختار شکست کار : توسط این بخش می توان فهمید که چه کاری باید انجام داد و همچنین زمان انجام این کار مشخص می شود. 2 – تکنیک های چگونگی انجام کارها و ابزار مورد نیاز 3 – چگونگی مدیریت کیفیت نتایج.

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

برای نائل شدن به اهداف و وظایف ، متدولوژی ها باید مکتوب بوده ، مورد تفکر قرار گیرند و یادگیری و انتقال آن ها با مشکل مواجه نشود ، مورد پذیرش اعضای سازمان بوده ، اجرای آن ها همراه با پاداش و ضمانت اجرایی باشد. متدولوژی ها باید قانونی بوده و منابع مورد استفاده در آن ها مورد تایید و پذیرش تصمیم گیرندگان و مسئولان پروژه ها قرار گیرد و باید به این نکته توجه کرد که آن ها نیاز به سرمایه گذاری در نیروی انسانی و مواد دارند.

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

در سال 1984 ، شخصی به نام Ahituv ، ابعاد توسعه را شامل بعد فعالیت ، بعد کنترل و بعد نیروی انسانی ، تعریف کرد و این در حالی است که متدولوژی توسعه می تواند با ایجاد یک چارچوب ، ابعاد ذکر شده را بهینه کند[3]. نکته آخر در این بخش این است ، فرایند توسعه از یک سری فازها تشکیل شده که حاکی از اصل تقسیم نیروی کار است. هر فاز تعدادی فعالیت را شامل می شود و افراد متنوعی روی آن ها کار می کنند.

مزایای متدولوژی ها

متدولوژی ها در ابتدا توسط تجربه و تمرین روی پروژه های موفق ایجاد شده اند و سپس به صورت رویه ها و فرمول هایی مکتوب شده و به عنوان اصول راهنما در فرایند توسعه مورد استفاده قرار گرفته اند. Ward در 1992 گفت : قبل از اینکه یک متدولوژی در توسعه سیستم مورد استفاده قرار گیرد ، بهتر است از لحاظ اصول مفهومی ، اجتماعی ، فیزیکی و تئوریکی ، درجه قابلیت استفاده از آن ، مورد بررسی و تحلیل قرار گیرد[3].

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

Stage در 1991 اذعان کرد که متدولوژی ها باعث ذخیره دانش به طور سیستماتیک می شوند و انتشار و مبادله آنرا تسهیل می کنند[3]. این موضوع باعث می شود دانش و مهارت از افراد ماهر به افراد نیمه ماهر ، انتقال یابد. یکی از نتایج ذخیره دانش ، استانداردسازی فرایند توسعه است. Avison و Fitzgerald در 1988عقیده داشتند استاندارد توسعه باعث بوجود آمدن زبان مشترک برای برقراری یک ارتباط آسان در میان افراد مشارکت کننده در فرایند توسعه می شود و در نتیجه ، همکاری و مشارکت بیشتر و وفاداری آن ها به حرفه و شغل خود افزایش و نهایتا حفظ و نگهداری فرایند توسعه میسر می گردد[3].

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

مشکلات متدولوژی ها

علی رغم مزایای فراوان و توصیه های اکید در اجرای متدولوژی ها ، تجربیات توسعه دهندگان و مطالعات و تحقیقات دانشمندان نشان داده است که اجرای متدولوژی ها با چالش هایی روبرو می شود. به طور مثال Paul در 1993 ابراز کرد که مشکلات اجرای متدولوژی ها مربوط به ماهیت و ساختار بنیادی خود آن ها است. و Fitzgerald در 1999 گفت ، تغییرات سریع در محیط تجارت و کسب و کار عامل اصلی در عدم اجرای موفق پروژه های توسعه سیستم های اطلاعاتی با استفاده از متدولوژی ها است[8].

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

متدولوژی های فرموله شده

همان طور که قبلا اشاره کردیم در گذشته متدولوژی ها از نتایج و تجربه اجرای پروژه های موفق ، ایجاد می شدند. یعنی اصول، رویه ها و فرایندهای موفقیت آمیز این پروژه ها به صورت مکتوب در آمده و در موارد بعدی از آن ها استفاده می شد. اما امروزه نمی توان به راحتی از این استراتژی استفاده کرد. دلایل متفاوتی برای این موضوع وجود دارد که قبلا به آن ها اشاره گردید. ولی در سال 1989 شخصی به نام Constantine رویکردهای توسعه را از سه منظر نگریست[3] : تمایز محصول ، سن کارمندان و ضرورت موقعیت و محل در اجرای فرایند توسعه. Fitzgerald و Avison در 1988 تفاوت بین متدولوژی ها را در فلسفه ، اهداف و تکنیک های آن ها ، دانستند [3]. متدولوژی ها را می توان به دو نوع سخت مثل SSADM و نرم و مبتنی بر نیروی انسانی ، تقسیم کرد. نوع تمرکز آن ها نیز می تواند متفاوت باشد. مثلا بعضی از آن ها بیشتر متمرکز بر فاز تجزیه و تحلیل هستند در حالی که برخی دیگر به اجرا تاکید دارند.

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

متدولوژی های فرموله شده ، پشتوانه سال ها تحقیق هستند. بسیاری از افراد که در توسعه سیستم ها تخصص دارند ، معتقدند که برای حل مشکلات اساسی سیستم ها در سازمان خود ، بهتر است از متدولوژی های فرموله شده همان سازمان استفاده کرد. Chapin در 1980 گفت: اگر در توسعه سیستم ها از استانداردهای محلی و فرموله شده استفاده شود ، کارمندان احساس راحتی بیشتری می کنند[3]. مثال هایی از متدولوژی های فرموله شده در گذشته موجود است. یکی از آن ها SSADM می باشد که توسط دولت UK برای اجرای پروژه های توسعه سیستم های اطلاعاتی ایجاد گردید و در حال حاضر بسیاری از کشورها نیز از این متدولوژی استفاده می کنند. ولی از طرفی می توان گفت که کشورهای فرانسه ، هلند و ایتالیا هر یک متدولوژی خاص خودشان را دارند. در نهایت اینکه Jayava در 1994 ابراز کرد که بیش از 1000 متدولوژی فرموله شده در سازمان ها وجود دارد[3].

طبقه بندی متدولوژی های توسعه سیستم های اطلاعاتی

متدولوژی ها را می توان به روش های مختلفی همان طور که در قبل ذکر شد ، طبقه بندی کرد. یکی از طبقه بندی های جامع را در این بخش می خواهیم بررسی کنیم. این طبقه بندی بر اساس وضعیت های مختلفی صورت می گیرد که سازمان ها با آن مواجه می شوند. 5 کلاس برای طبقه بندی متدولوژی ها وجود دارد که در زیر به آن ها اشاره شده است[1]:

1. وضعیت ها و مسائل ساخت یافته همراه با الزامات و نیازمندی های تعریف شده به صورت واضح
2. مسائل ساخت یافته با اهداف واضح و الزامات و نیازمندی های نامعین کاربران
3. مسائل غیرساخت یافته همراه با اهداف نامشخص
4. مسائل و وضعیت هایی که در آن ها نیاز به تعامل زیادی بین کاربر و سیستم است.
5. مسائل و وضعیت های پیچیده ، یعنی ترکیب چهار کلاس بالا که احتیاج به یک رویکرد اقتضایی در توسعه است.

اینک به توضیح مختصری از هر یک و متدولوژی های آن ها می پردازیم.

1 – مسائل ساخت یافته همراه با نیازمندی های تعریف شده به صورت واضح

در اینجا از متدولوژی های توسعه سیستم های اطلاعاتی سنتی مبتنی بر رویکردهای سخت استفاده می شود. متدولوژی های توسعه سیستم های کامپیوتری اولیه ، در این طبقه یا کلاس هستند. رویکرد SDLC سنتی را که مرکز محاسبات ملی UK ارائه داده است ، می توان در اینجا قرار داد که دارای فازها و مراحل زیر است : مطالعه امکان سنجی ، بررسی و تحقیق سیستم ، تحلیل سیستم ، طراحی سیستم ، اجرا ، بازنگری و نگهداری. این متدولوژی در جایی کاربرد دارد که افراد در آن سازمان خواستار تغییرات بنیادی نیستند. این متدولوژی در سازمان هایی با عملیات روتین ، فرایندهای ایستا ، قابل اجرا بوده و اصولا در سازمان های کوچک یا دپارتمان های سازمان های بزرگ می توان از آن استفاده کرد. کاربران در این متدولوژی به صورت خیلی محدود دخالت داده می شوند و این متدولوژی از تصمیمات مدیریتی کمتر حمایت می کند.

2 – مسائل ساخت یافته با اهداف واضح و نیازمندی های نا معین کاربران

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

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

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

اگر چه طرفداران زیادی برای متدولوژی مبتنی بر داده وجود دارند ، اما اشخاصی مثل Benyon ، Skidmore در سال 1987 ابراز کردند که تاکید بر داده ها و تکنیک های مرتبط با آن ، ممکن است منجر به نادیده گرفتن واقعیات شود[1]. این متدولوژی ها در جایی که درجه تعارض بالا است کاربرد آنچنانی ندارد. به همین دلیل دو متدولوژی ساخت یافته و تحلیل داده با هم ترکیب شدند و از تکنیک هایی مثل DFD و ERD استفاده گردید. SSADM بر طبق این منطق توسعه داده شد. با اینکه ترکیب دو متدولوژی قبل باعث پوشش بعضی نقاط ضعف آن ها گردید ، ولی باز هم نمی شد از آن ها در محیط های با تعارض بالا استفاده کرد. به همین دلیل متدولوژی نمونه سازی بوجود آمد.

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

3 – مسائل غیرساخت یافته همراه با اهداف نا مشخص

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

یکی از معروف ترین متدولوژی هایی که در این دسته قرار می گیرد ، متدولوژی سیستم های نرم است که توسط Checkland ارائه شد[1]. او معتقد بود که سیستم های فعالیت های انسانی تنها در ذهن افراد وجود دارند و بنابراین چشم انداز افراد است که بر روی نگرش آن ها از وضعیت مساله و اهداف سیستم ، اثر می گذارد. تکنیک دیاگرام تصویر غنی ، با مدلسازی تمام ابعاد وضعیت مساله باعث ایجاد یک تصویر غنی می شود که توسط آن مباحث ، مشکلات و تعارضات را می توان تشخیص داد.

4 – مسائل و وضعیت هایی که در آن ها نیاز به تعامل زیادی بین کاربر و سیستم است.

در بسیاری از سیستم های اطلاعاتی ، مشارکت کارکنان و کاربران تاثیر زیادی روی اجرای آن ها می گذارد. در چنین پروژه هایی باید از متدولوژی استفاده کرد که علاوه بر توجه به مسائل ایستایی فنی ، مشارکت و درگیری کاربران را نیز در نظر بگیرد. یکی از متدولوژی های مهم در این طبقه ، متدولوژی ETHICS است که توسط Mumford در سال 1995 پایه گذاری گردید.

این متدولوژی به معنی سیستم های اجرایی انسانی و فنی و کامپیوتر محور است که به تشویق مشارکت کاربران می پردازد و باعث تعهد بیشتر آن ها به پروژه می شود[1]. ETHICS مبتنی بر رویکرد فنی و اجتماعی است. به تامین ابزارها برای تحلیل و هدفگذاری با مشارکت کاربران ، متمرکز است. نکته مهم اینجاست که رویکرد مشارکتی در مسائلی که کاربران و افراد تمایل به درگیری در پروژه ندارند و یا مجبور باشند با استفاده از زور در پروژه دخیل شوند ، کارساز نخواهد بود ، بلکه سازمان باید در این زمینه فرهنگ سازی کرده و سیاست ها و نگرش های خود و افراد سازمان را تغییر دهد. سازمان باید سطوح سلسله مراتبی بوروکراتیک خود را تغییر دهد و درجه انعطاف پذیری را بالا برد.

5 – مسائل و وضعیت های پیچیده

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

در این کلاس ، رویکرد Multiview یا نگرش چندگانه مورد بررسی قرار می گیرد. به جای انتخاب هر یک از متدولوژی ها ، در هنگام مواجه شدن با مسائل بهتر است از رویکرد مقتضیانه در فرایند توسعه استفاده نمود. رویکرد چند نگرشی دارای یک ساختار منعطف است و با توجه به وضعیت های خاص یک مساله ، تکنیک ها و ابزارهای مرتبط را پیشنهاد می دهد. این متدولوژی دارای 5 فاز می باشد که عبارتند از : تحلیل سیستم های فعالیت انسانی ، تحلیل اطلاعات ، تحلیل و طراحی سیستم های اجتماعی – فنی ، طراحی روابط متعامل انسان با کامپیوتر و طراحی جنبه های فنی. در ارتباط با این رویکرد باید به سوالات زیر پاسخ داد تا بعد از تحلیل پاسخ ها ، اقدامات مناسب را به عمل آورد[1].

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

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

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

متدهای چابک و پویا در توسعه سیستم های اطلاعاتی

در این اواخر، کاربرد متدولوژی چابک ، طرفدار زیادی پیدا کرده است که یکی از دلایل آن ، قابلیت انعطاف پذیری بالا در پروژه های مختلف است. متدولوژی چابک ، بسیار سریع تر از متدولوژی های سنتی به جواب می رسد. یکی از انواع متدولوژی های چابک ، DSDM یا متدولوژی توسعه سیستم های پویا است[2]. تمرکز این متد بیشتر بر روی پذیرش آن توسط افراد و درجه مناسب بودن آن در پروژه های توسعه است. در این رویکرد ، ابتدا هر یک از پروژه ها بررسی می شوند که آیا آن ها معیارهای متدولوژی DSDM را دارند یا خیر. دو نقش مهم در پذیرش DSDM حیاتی است. یکی نقش هدایت کننده پروژه و دیگری مدیر پروژه. مربیان و هدایت کنندگان پروژه به مدیران پروژه در اجرای این متدولوژی کمک می کندد. مربیان ابتدا پروژه ها را از لحاظ ویژگی های آن ها ، روش های مدیریت پروژه ، ارزیابی قابلیت و ریسک ، مورد بررسی قرار داده و سپس آن ها را به مربیان پروژه پیشنهاد می دهند[2].

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

از ترکیب این دو استراتژی ، پنج استراتژی شکل می گیرد که عبارتند از[2]:

1. DSDM خطی: که در آن تنها یک بار از استراتژی تکاملی استفاده می شود.
2. One – pass DSDM: این استراتژی با ترکیب یک رویکرد تکاملی و چند رویکرد تکرار ، بوجود می آید.
3. Hybrid DSDM: به معنی استراتژی است که شامل چند رویکرد تکاملی بوده در بعضی از این رویکردها چند بار از رویکرد تکرار استفاده می شود.
4. Full DSDM : ترکیبی از رویکردهای تکاملی و تکرار و از هر کدام چند بار
5. Phased DSDM : استفاده از رویکردهای تکاملی در چندین مرحله و بدون بهره بردن از رویکرد تکرار

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

متدولوژی Fujitsu در توسعه سیستم های اطلاعاتی

شخصی به نام Fujitsu به توسعه یک سیستم اطلاعاتی پرداخته است که معماری و پشتیبانی توسعه سیستم (SDAS) نام دارد[7]. این متدولوژی برای تکنولوژی های جدید کاربرد زیادی دارد. استفاده از این متدولوژی باعث بهبود کیفیت و کاهش زمان توسعه سیستم می گردد. به تعریف دقیق الزامات و نیازمندی ها می پردازد. قابلیت های توسعه و نگهداری فرایند توسعه در این متدولوژی ، بالاست و از ابزارهای موثری برای اتومات کردن تست و مستندسازی استفاده می کند.

SDAS یک متدولوژی جامع توسعه سیستم است که نخستین نسخه آن در سال 1980 توسط Fujitsu برای حمایت از زیرساخت های COBOL ایجاد گردید. سپس در سال 1990 ، این متدولوژی برای پشتیبانی از سیستم های Client – Server ، مورد تجدید نظر قرار گرفت. در نهایت نسخه جدید آن برای بهبود کیفیت و کاهش زمان توسعه در سیستم های مبتنی بر وب و در کل چرخه تکاملی سیستم ، ساخته شد.

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

اهداف SDAS شامل بهبود کیفیت توسعه سیستم و کاهش دوره زمانی آن با استفاده از تکنیک ها و فنون زیر است[7].

1 – تعریف دقیق نیازمندی ها و الزامات و به اشتراک گذاشتن اطلاعات با مشتریان : یکی از مشکلات توسعه سیستم های اطلاعاتی ، وجود ابهام در اطلاعات است. حتی در بعضی مواقع مشتریان فرایند توسعه سیستم نیز نمی دانند که واقعا چه می خواهند. عدم وضوح اطلاعات باعث ایجاد تغییرات در طراحی می گردد که این موضوع به نوبه خود تاخیراتی را در تحویل پروژه توسعه سیستم به مشتری ، دارد. در نتیجه شناسایی الزامات دقیق مشتری مهم و حیاتی است. SDAS ابزارهایی را برای افزایش فهم و تفسیر در الزامات و نیازمندی های مشتریان فراهم می کند. یکی از این ابزارها ، جریانات کاری است ، تا عملیات و فرایندهای تجاری در سیستم به طور استاندارد تعریف گردد.

2 – ابزارهای بهبود کیفیت و اثربخشی : Fujitsu از ابزارهای تست و توسعه برای پشتیبانی تست و مستندسازی زیرساختارهای سیستم استفاده کرده است. ابزارهای تست باعث کاهش هزینه و زمان مورد نیاز برای تست ، می شوند. ابزارهای پشتیبانی مستندات ، باعث بهبود کیفیت و اثربخشی توسعه فرایندها می شوند. کلیه این کارها توسط اتومات کردن فرایندها صورت می گیرد.

جنبه های فرهنگی و اجتماعی متدولوژی های توسعه سیستم های اطلاعاتی

اکثر متدولوژی های توسعه سیستم های اطلاعاتی در سال های 1967 تا 1977 ظهور کرده اند. فنونی مثل دیاگرام جریان داده، مدل روابط موجودیت و مفاهیمی مثل شی گرایی و چرخه زندگی توسعه سیستم در مراحل بعدی پا به عرصه وجود گذاشتند. در این دهه بیشتر محققین با رویکرد مهندسی و ریاضی به توسعه سیستم ها می پرداختند. به عنوان مثال Davis در 1988 و Orr در 1989 اعتقاد داشتند که SDLC پایه ای برای متدولوژی های دیگر در توسعه سیستم ها است[4].

این واژه در بسیاری از رشته های مهندسی وجود دارد. Friedman در 1989 و Kraft در 1977 اشاره کرده اند که معرفی این مفهوم در توسعه سیستم همزمان با تمایل به برقراری یک رویکرد مهندسی در توسعه سیستم بود.[4]از طرفی در چهل سال گذشته رویکردهای سخت نسبت به توسعه سیستم وجود داشتند؛ سپس متدهای نرم جای آن ها را گرفتند. SDLC به توسعه سیستم نگاهی سخت داشت. Laudon در 1995 ضعف های اصلی SDLC را این گونه برشمرد[6]: هزینه زیاد سیکل توسعه، زمانبر بودن چرخه، عدم انعطاف پذیری و سستی در تغییرات ایجاد شده توسط SDLC.

نکته اساسی این است که استفاده از متدولوژی های مرسوم، ضامن موفقیت اجرای سیستم های اطلاعاتی نیست. بعضی از متدها تنها بخشی از نیازهای سیستم را برطرف می کنند. به عنوان مثال مرکز محاسبات ملی در UK، فرایند توسعه سیستم را اینگونه تعریف می کند[6]: مطالعه امکان سنجی، تحلیل و بررسی سیستم، توسعه سیستم، اجرا، بازنگری و نگهداری. این تعریف، بیشتر جنبه تکنیکی دارد. متدولوژی هایی که این تعریف را انتخاب کرده اند به متدولوژی سخت معروف اند. چنین رویکردی نیازهای فنی کارکنان را در توسعه برطرف می سازد ولی تضمین کننده الزامات غیرفنی نمی باشد. Sawyer در سال 1994 اذعان کرد که SDLC یک اکسیر نیست بلکه هنوز هم می توان پروژه هایی را پیدا کرد که هنگام اجرای این متد در توسعه با شکست مواجه می شوند. این نگرش که تنها بعد فنی و کاربردی در توسعه سیستم مطرح است، به شکست توسعه منجر می شود[6]. شکل زیر نشانگر این است که چگونه مباحث فنی در فرایند توسعه سیستم غالب شده اند.

اگر چه اندیشمندانی مثل Klein و Hirschheim در سال 1987 به توسعه سیستم نگاهی فنی و تکنیکی داشتند، Land در سال 1985 اعتقاد داشت که سیستم های اطلاعاتی، سیستم هایی اجتماعی هستند که فناوری اطلاعات در آن قرار گرفته است[6] ؛ Lyytinen در 1987 اشاره کرد که در طراحی سیستم ها باید به ابعاد فرهنگی، اجتماعی و سیاسی نیز همانند تکنیکی توجه گردد. بدین ترتیب مشارکت کارکنان در توسعه سیستم امری الزامی و حیاتی است. می توان توسعه سیستم های اطلاعاتی را از دو بعد نگریست: 1- بعد تکنیکی 2- بعد رفتاری،فرهنگی،اقتصادی،اجتماعی و سیاسی. نکته مهم اینکه درنظر گرفتن تنها جنبه های تکنیکی در توسعه، مباحثی مثل پیچیدگی و تغییرات محیطی را لحاظ نمی کند. اگر کارمندان در توسعه سیستم مرتبا به سمت ابعاد تکنیکی روی آورند، شاید یک موفقیت فنی حاصل شود ولی سازمان با شکست مواجه می گردد. پس بهتر است در توسعه به مشکلات و مسائل رویکردی کل نگر داشته باشیم. شکل زیر از جنبه ای دیگر به توسعه سیستم های اطلاعاتی می نگرد[6]. یعنی فرض می کند که ابتدا سیستم اطلاعاتی وارد سازمان می شود، سپس با مباحثی روبرو می گردد که برای موفقیت توسعه الزامی و حیاتی است.

Avison در 1995 متدولوژی های توسعه مثل SSADM را مورد نقد قرار داد[9] او معتقد بود که این روش ها تنها بر ابعاد رسمی و فنی متکی هستند و اینکه توسعه سیستم بهتر است از جنبه تکنیکی به نگرش های رفتاری و اجتماعی انتقال یابد. همچنین Wood Harper در سال 1996 اذعان کرد که در توسعه سیستم های اطلاعاتی بهتر است موارد زیر نیز در نظر گرفته شود[9]: میزان اثرگذاری جنبه های رفتاری در توسعه سیستم، تعیین نوع متدولوژی متناسب با نوع رفتار در سازمان، اتخاذ رویکردی مناسب در توسعه در هنگام مواجه شدن با تعارضات سازمانی.

فرهنگ نیز یکی از مهم ترین مباحث در سازمان های امروزی می باشد. سیستم های اطلاعاتی به عنوان یکی از رویکردهای نوین در سازمان ها از این قاعده مستثنی نیستند. به محض ورود یک سیستم اطلاعاتی جدید در سازمان نیاز به تغییر فرهنگ است. Boynton در سال 1987 اعتقاد داشت که توسعه سیستم های اطلاعاتی نیاز به موارد زیر دارد[5]: تحلیل فرهنگ درون سازمانی، ارزیابی سیاست و توزیع قدرت در سازمان، تعیین میزان پذیرش سیستم های اطلاعاتی توسط کارکنان، ارزیابی ریسک، اطمینان از مشارکت اعضای سازمان در توسعه و شناسایی موارد بحرانی اجرای سیستم های اطلاعاتی در سازمان.

نتیجه

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

مراجع

[1] Avison D.E.; Taylor V.,”Information Systems Development Methodologies: A Classification According To Problem Situation”,Journal of Information Technology,1997,73-81.

[2] Aydin Mehmet Naflz; Harmsen Frank; Slooten Kees Van;Stegwee Robert A,”An Agile Information Systems Development Method in Use”,Turk J Elec,Vol.12,No.2, 2004.

[3] Fitzgerald Brian, “Formalised Systems Development Methodologies: A Critical Perspective”,forthcoming in Information Systems Journal,1996.

[4] Fitzgerald Brian,”Systems development methodologies: the problem of tenses”,http://WWW.emerald-library.com,Information Technology & People, Vol.13 No.3,2000, pp.174-185.

[5] Maguire Stuart;Redman Tom,”The role of human resource management in information systems development”,http://WWW.emerald-library.com,Management Decision Vol.45 No.2,2007,pp.252-264.

[6] Maguire Stuart,”Towards a business-led approach to information systems development”,http://WWW.emerald-library.com,Information Management & Computer Security, 8/5 [2000],230-238.

[7] Oshima Takeshi;Kashiwagi Masayuki;Fukao Hiroshi,“Fujitsus System Development Methdologies: SDAS”FUJITSU Sci.Tech.J.,42,3,2006,p.277-285.

[8] Papatsoutsos Dimitrios,“Information Systems Development Methodologies in the Age of Digital Economy”,University of Athens Department of Informatics University Campus TYPA Buildings, 2005.

[9] Rogerson Simon; Weckert John; Simpson Chris,”An ethical review of information systems development”,http://WWW.emerald-library.com,Information Technology & People, Vol.13 No.2, 2000, pp, 121-136.