مقدمه

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

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

خب، مشکل چیه؟

مشکل هرچه که باشد، چیزی است که اغلب شرکت‌ها با آن دست‌به‌گریبان‌اند. بر اساس تحقیقات گروه استاندیش (2001)، در سال 200 تنها 20 درصد از پروژه‌های نرم‌افزاری موفقیت‌آمیز بوده‌اند. (شکل 1-1). حدود 23 درصد کنسل شده‌اند و مابقی تأخیر داشته‌اند (حدود 63 درصد)، با کسری بودجه مواجه شده‌اند (حدود 45 درصد)، فاقد برخی ویژگی‌ها بوده‌اند (حدود 33 درصد) و در بسیاری از موارد همه این مشکلات باهم وجود داشته است. در وزارت دادگستری نیوزیلند، از میان 42 میلیون دلار پرونده سیستم مدیریت، 8 میلیون دلار کسری بودجه داشته‌اند و در هنگام اجرا در سال 2003، بیش از یک سال تأخیر داشته‌اند. از بین 27 مزیت برشمرده شده برای سیستم، تنها 16 مورد برآورده شده بود. به‌جای بهبود بهره‌وری، سیستم، با دو برابر کردن میزان داده‌های ورودی، درواقع موجب افزایش زمان موردنیاز برای مدیریت پرونده‌های دادگاهی شده است. یک بررسی پس از اجرا، بیش از 1400 مسئله برجسته را مشخص نموده است؛ اما تنها چالش‌های پیش روی توسعه‌دهندگان، همان‌هایی بودند که به سیستم‌های پیچیده و بزرگ مربوط می‌شدند (بل، 2004).

شکل 1-1 موفقیت و شکست پروژه‌های نرم‌افزاری در سال 2000

در مقابل، در صنعت ساخت‌وساز و مهندسی، اوضاع کاملاً متفاوت است. بر اساس گزارش اخبار مهندسی،94 درصد از مشتریان پروژه‌های آن‌ها، از نتایج پروژه‌ها راضی بودند که این امر نشان می‌دهد پروژه‌های ساخت ساز، از نرخ شکست بسیار پایین‌تری نسبت به پروژه‌های نرم‌افزاری برخوردار بوده‌اند؛ و به همین دلیل است که تخریب سقف لوله‌ای شکل ترمینال نوساز 2E در فرودگاه چارلز دگال (پاریس) در سال 2004، خبر شماره یک سراسر جهان بود و درواقع چنین غیرمعمولی به نظر می‌رسید. پروژه‌های نرم‌افزاری شکست‌خورده، بسیار بیش از این شایسته جلب‌توجه هستند. دلیل این امر می‌توان با بررسی توسعه نرم‌افزارهای تجاری و غیرتجاری متوجه شویم. نرم‌افزارهای تجاری به‌منظور کسب سود توسط شرکت‌ها تولید می‌شوند. برخی از این نرم‌افزارها برای مشتریان خاص، شخص سازی شده‌اند، مثل سیستم صدور صورتحساب شما، اما محصولات عمومی، مانند مایکروسافت ورد نیز وجود دارند. تقریباً همه آن‌ها در داخل یک پروژه و یا مجموعه‌ای از پروژه‌ها ساخته می‌شوند.

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

نرم‌افزار اپن سورس، یک موفقیت بزرگ است. تیم اوریلی، رئیس هیئت‌مدیره شرکت اوریلی و همکاران، یکی از بزرگ‌ترین شرکت‌های تولیدکننده کتاب‌های کامپیوتری، می‌گوید "اینترنت بر روی نرم‌افزار اپن سورس اجرا می‌شود. نرم‌افزارهای اپن سورس، نسبت به نرم‌افزارهای تجاری، از مشکلات اعتباری و اجرایی بسیار کمتری برخوردار هستند؛ اما آیا این نرم‌افزارها، بر اساس معیارهایی که برای سنجش نرم‌افزارهای تجاری استفاده می‌شوند، نیز موفقیت‌آمیز هستند؟ قبل از هر چیز باید گفت با زمان نامحدود، هیچ پروژه‌ای موفقیت‌آمیز نیست. درست از که زمان نامحدود، بهره‌وری ضعیف را جبران می‌کند. بااین‌وجود، بهره‌وری توسعه‌دهندگان اپن سورس، افسانه‌ای است. در سال 1991 لینوس توروالدز، یک سیستم‌عامل کامل، پایدار و هسته‌ای (لینوکس) را در کمتر از یک سال نوشت و کمتر از یک سال بعد، یک گروه هشت‌نفره گرد هم آمدند تا گروه آپاچی را تشکیل دهند. آن‌ها آپاچی 1,0 را، به‌عنوان یک قطعه نرم‌افزاری کامل، به‌گونه‌ای ساخته بودند که به یکی از گسترده‌ترین سرورهای صفحات وب در اینترنت تبدیل شد.

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

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

فصل 2

چرا نرم‌افزار مشکل است

 

چرا نرم‌افزار مشکل است

هنگامی‌که می‌کوشیم تا تفاوت میان نرم‌افزار و توسعه نرم‌افزار را بررسی کنیم، اولین سؤالی که به ذهن می‌رسد این است که " تفاوت از چه نظر؟". خب، حالا بیایید توسعه نرم‌افزار را با راه‌سازی مقایسه کنیم. ما همه از راه‌ها استفاده می‌کنیم، همه می‌دانیم که کاربرد آن‌ها چیست و چگونه کار می‌کنند. راه‌های خیلی با نرم‌افزارها فرق می‌کنند. ازنظر بی‌تحرکی و حجم تا جایی که ممکن است با نرم‌افزارها متفاوت می‌باشند.

تفاوت‌های زیادی بن راه‌سازی و توسعه نرم‌افزار وجود دارد. به‌عنوان‌مثال، توسعه نرم‌افزار به‌شدت تحت تأثیر آب‌وهوا است، مثلاً، اگر لبه جاده مرطوب و مستعد فروریزی باشد، نباید عملیات حفاری را شروع کنید؛ اما آیا این واقعاً یک تفاوت بنیادین است؟ نه پروژه‌های نرم‌افزاری نیز تحت تأثیر عوامل بیرونی قرار می‌گیرند. اگر یک جزء ثالث نرم‌افزاری به‌موقع آماده نشود، همان تأخیر رخ خواهد داد. بخش بعدی، 12 تفاوت متمایز ولی مرتبط رابین توسعه نرم‌افزار و سایر تلاش‌های کسب‌وکار نشان می‌دهد (شکل 2-1). راه‌سازی ازآن‌جهت برای مقایسه انتخاب‌شده است که این صنعت هیچ‌یک از این ویژگی‌ها را نشان نمی‌دهد، بنابراین تمایز را با دقت کامل می‌توان مشاهده نمود. بااین‌وجود، این موضوع برای سایر فعالیت‌های که به ذهن می‌رسد، ممکن است مصداق نداشته باشد و ممکن است فقط یک یا دو و یا فقط چند مورد از این ویژگی‌ها را نشان دهند... آنچه توسعه نرم‌افزار را در این میان منحصربه‌فرد می‌کند، این است که تمامی این ویژگی‌ها را در برمی‌گیرد.

1- نرم‌افزار پیچیده است

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

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

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

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

شکل 2-2 چگونگی کار کردن را نشان می‌دهد. این سیستم از 12 آیتم تشکیل‌شده است که با یکدیگر در تعامل می‌باشند. با تقسیم نمودن این آیتم‌ها به 4 دسته کوچک‌تر، تعداد کلی تعامل‌ها، از 66 مورد به 18 مورد کاهش می‌یابد؛ و بدین‌صورت، سیستم از پیچیدگی بسیار کمتری برخوردار است.

برنامه‌های کامپیوتری، پیچیده‌ترین، ظریف‌ترین و درهم‌آمیخته ترین محصولات بشری تا به امروز هستند. آن‌ها مکانیسم‌هایی هستند با تعداد قطعات متحرکی به‌مراتب بیشتر از همه موتورهای دیگر: اجزاء فرسوده نمی‌شوند، اما به‌گونه‌ای با یکدیگر در تعامل می‌باشند که خود برنامه نویسان نیز نمی‌توانند آن را پیش‌بینی کنند (گلیک، 1992).

نکته: نرم‌افزار ازآن‌جهت منحصربه‌فرد است که مهم‌ترین موضوع آن پیچیدگی آن است.

2- نرم‌افزار انتزاعی است

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

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

حتی کپسوله کردن که می‌تواند از میزان پیچیدگی یک سیستم بکاهد، نمی‌تواند به ما کمک کند تا بتوانیم به‌تنهایی از پس تعریف نمودن هر یک از این دستورالعمل‌ها براییم؛ تنها به ما کمک می‌کند تا آن‌ها را بهتر سازمان‌دهی کنیم.

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

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

3- ملزومات ناقص هستند

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

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

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

آیا این موضوع مهم است؟ گروه استاندیش (2001) مشکلات موجود در خصوص الزامات و مشخصات را تحت عنوان "چالش‌های پیش روی پروژه" برای پروژه‌های نرم‌افزاری شناسایی نموده‌اند. این مواد، مهم‌ترین موارد برای بیش از 42 درصد از پروژه‌ها بوده‌اند.

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

نکته: قبل از شروع توسعه، تعیین مجموعه کاملی از الزامات برای نرم‌افزار، بسیار مشکل است.

4- تغییرات سریع فنّاوری

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

امروزه، تقریباً هر نرم‌افزار جدیدی با یک چهارچوب برنامه شرکتی ساخته می‌شود، مانند نسخه شرکتی سیستم جاوا 2(J2EE) و یا میکروسافت NET. اینکه بدانیم این عبارت به چه معناست، حائز اهمیت زیادی است. چراکه این فنّاوری‌ها، چشم‌انداز توسعه نرم‌افزار را مشخص می‌سازند.

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

 

با توجه به اینکه بسیاری از نرم‌افزارهای دولتی و تجاری بزرگ هم‌اکنون با این چهارچوب اپلیکیشن شرکتی ساخته‌شده‌اند، حتماً فکر می‌کنید که آن‌ها تاریخچه‌ای طولانی و متمایز دارند و اینکه آن‌ها محصولاتی پایدار و کامل هستند؛ اما این درست نیست. Sun’s J2EE که شاید اولین چهارچوب اپلیکیشن شرکتی بود که مورداستفاده قرار گفت، در سال 1998، ظهور کرد و از آن زمان تاکنون دستخوش تغییرات بسیاری شده است. مایکروسافت تنها فناوری رقیب آن (NET) را در سال 2002، منتشر نمود و هیچ‌کس تجربه‌ای طولانی‌تر از دو دهه را با آن نداشته است. در مقابل، ما هزاران سال است که جاده می‌سازیم، حتی از زمان زوم باستان و تمدن چین. مشکلات به‌خوبی شناسایی شدند و فنّاوری‌های آن به‌آرامی تغییر یافتند. آسفالت گرم، در سال 1903 به بازار عرضه شد و این فنّاوری پایه، همان چیزی است که ما امروز هم به کار می‌بریم.

نکته: فنّاوری‌های توسعه نرم‌افزار بسیار سریع‌تر از سایر فنّاوری‌های ساخت‌وساز تغییر می‌کنند.

 

5- بهترین روش‌ها هنوز بالغ نشده‌اند

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

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

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

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

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

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

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

اما چقدر ما باید منتظر این بهترین روش‌ها شویم؟ برنامه‌نویسی شئ محور از سال 1980 مورداستفاده قرار می‌گرفته است، اما در سال 1995 بود که باند چهار نفر (اریک گاما، ریچارد هلم، رالف جانسون و جان ولیسیدس) کتاب اثرگذار خود با عنوان "الگوهای طراحی" را منتشر نمودند، این کتاب انقلابی درزمینه برنامه‌نویسی شئ محور بود و راه‌حل‌هایی را در زمینه "ضد الگوهایی مانند دکمه شستی جادویی، ارائه نمود. پانزده سال، در صنعت IT، زمان طولانی است: فنّاوری‌های بسیار دیگری در این زمان می‌آیند و می‌روند. چهارچوب‌های اپلیکیشن شرکتی که پیش‌ازاین درباره‌اش صحبت کردیم، فقط در کسری از این زمان بوده‌اند. در حال حاضر کتاب‌های کمی در خصوص معماری وجود دارند، اما هیچ‌یک از آن‌ها به‌اندازه"طراحی الگوها " حائز اهمیت نمی‌باشند. این موضوع نشان می‌دهد که بهترین روش‌های چهارچوب‌های اپلیکیشن شرکتی هنوز به بلوغ کامل نرسیده‌اند؛ بنابراین، آیا می‌توان گفت که نرم‌افزارهای مبتنی بر فنّاوری‌های جدید لزوماً ضعیف هستند؟ خوشبختانه، نه. فصل بعدی در این بخش نشان می‌دهد که حتی در این شرایط چقدر نرم‌افزارهای می‌توانند مستحکم باشند، اما این امر به‌سادگی راه‌سازی نیست، جایی که فنّاوری پایه چیزی حدود چهار برابر این طولانی است و درنتیجه بهترین روش‌ها مدت‌هاست که نهادینه‌شده‌اند و در تمام جهان مورداستفاده قرار می‌گیرند.

نکته: اغلب فنّاوری‌های توسعه نرم‌افزار هنوز به بلوغ نرسیده‌اند تا مجموعه‌ای از بهترین روش‌ها را دارا باشند.