در 4 ژوئن ۱۹۹۶، نخستین پرواز پرتاب کننده پروژه آریان 5 با شکست خاتمه پذیرفت. چون در حدود ۴۰ثانیه پس از پرتاب در ارتفاعی در حدود ۳۷۰۰ متر (۱۲۱۳۹ فوت)، این دستگاه از مسیر پرواز خود منحرف و منفجر و متلاشی گردید. گزارش های رسانه ای آن موقع نشان داد که نیم میلیارد دلار خسارت ایجاد شد که کلا بیمه نشده بود. بررسی مقدماتی داده های پرواز توسط مرکز ملی مطالعات فضایی فرانسه CNES و آژانس فضایی اروپا مدتی کوتاه پس از حادثه انجام گرفت تا علت احتمالی شکست تعیین گردد. این بررسی نشان داد که سیستم ارجاع اینرسی پشتیبان(IRS ) بلافاصله پس از خرابی IRS فعال، خراب شده بوده و منجر شد بررسی ها بر روی سیستم کنترل پرواز و به ویژه IRS به عنوان منبع خرابی متمرکز شود.
به طور ساده،IRS رفتار پرتاب کننده و حرکات آن در فضا را اندازه گیری می کند. هر IRS یک رایانه داخلی مخصوص به خود دارد که برای محاسبه زوایا و سرعت ها به کار می رود که این داده ها سپس به رایانه اصلی پرتاب کننده فرستاده می شود. بنابراین IRS دارای ماموریتی بحرانی است.
به منظور تداوم کارIRS در موقع خرابی، در حقیقت دو سیستم IRS که هر دو سخت افزار و نرم افزار یکسان داشتند در سیستم در نظر گرفته شده بود که به طور موازی کار می کردند. بنابراین IRS حساس(سریع، فوری) خود محافظت شده و پیوسته به وسیله IRS فعال موقع بروز مشکل، کنترل از IRS فعال بهIRS پشتیبان انتقال داده می شد تا کارکرد صحیح این واحد فراهم شود.
این مطالعه موردی به ویژه برای روشن تر کردن نیاز به آزمایش کامل مفید است؛ جزیی که خراب بود در حقیقت در آن موقع مورد استفاده قرار نگرفته بود. تقریبا ۳۶ ثانیه پس از پرتاب، رایانه IRS فعال به علت آن که با اشکالی در محاسبات ریاضی مواجه شد از کار افتاد. چون انتظار این خطا نمی رفت، هیچ برنامه رفع خطایی برای به دام انداختن آن نیز تعبیه نشده بود. مشخصات سیستم IRS این گونه بود که در هنگام بروز چنین رویدادی، شرح خرابی در حافظه پردازنده ذخیره گردد و سیستم IRS خاموش شود.
برنامه های ایمن کننده درون رایانه اصلی به طور خودکار سعی در فعال کردن IRS پشتیبان کردند ولی با شکست مواجه شدند چون این واحد قبلا در طی چرخه قبلی داده ها (۷۲ میلی ثانیه) دقیقا به همان دلیل از کار افتاده بود. بررسی بیشتر نشان داد خطایی که موجب از کار افتادگی سیستم هایIRS شده بود چیزی بیشتر از یک خطای استثنایی نبود که ناشی از تبدیل عدد اعشاری متغیر ۶۴ بیتی به عدد صحیح ثابت ۱۶ بیتی بود. یکی از این اعداد در محاسباتی که سبب بروز خطا در مسیر پرتاب کننده می شد، مورد استفاده قرار گرفته بود؛ این مقدار به طور غیر منتظره ای بالا بود چون مسیر پروژه آریان 5 از مسیر مدل قبلیش یعنی آریان ۴، منبع مدول نرم افزار، تفاوت داشت. آنچه برای کارشناسان امور مالی پروژه باید مأیوس کننده تر بوده باشد، این حقیقت است که این خطا در مدولی رخ داد که پس از جدا شدن پرتاب کننده، استفاده دیگری نداشت. در شرایط عادی، تابع همترازی درون IRS درست قبل از جدا شدن پرتاب کننده متوقف می شد، ولی در پیشامد بعید توقف شمارش معکوس پرتاب، تنظیم مجدد IRS در مدل های قبلی آریان، می توانست ساعت ها به طول بیانجامد. تنها به همین دلیل این برنامه فقط تا حدود ۴۰ ثانیه پس از جدا شدن کار می کرد. این توالی زمانی برای آریان ۴ لازم بود ولی برای آریان ۵ ضرورتی نداشت.
علل شکست توسعه نرم افزار
شکست پروژه هایIS نظیر سیستم رایانه ای ارسال خدمات آمبولانس لندن و پروژه TAURUS بازار بورس لندن به خاطر بی لیاقتی مدیریت آنها به شدت مورد انتقاد قرار گرفت. ولی این مورد برای پروژه آریان 5 وجود نداشت. از محتوای این گزارش کامل، مشخص است که فرآیند توسعه نرم افزار به دقت مدیریت شده و استانداردهای صنعتی در سرتاسر پروژه رعایت شده است.
این گزارش همچنین این حقیقت را آشکار می سازد که فرآیند مستندسازی سیستماتیک، تعیین اعتبار و مدیریت وجود داشته، ولی واضح است که در این پروژه، رویه های تعیین اعتبار و تأیید توافقی بوده است. البته، هیئت تحقیق چند توصیه برای بهبود این فرآیند ارائه کرد. یکی از این توصیه ها، لزوم آزمایش کل سیستم به جای بخش هایی از آن بود (IRS مستقل از نرم افزار پرواز آزمایش شده بود).
این مطالعه موردی، مهمتر از همه، ریسک ناتوانی در آزمایش همه چیز را روشن تر می نماید. این مطالعه همچنین ریسک های مرتبط با قصور در مدیریت استفاده مجدد از اجزای نرم افزاری در محیط توسعه سیستم های نرم افزاری پیچیده را نشان می دهد.
در طی آزمایش سیستم IRS، تا اندازه ای مشخص شد که تبدیل های حسابی اشتباه، علت احتمالی خطاست. بنابراین برای تعیین آسیب پذیری کد “حفاظت نشده” (کدی که می توانست اشکالی ایجاد کند)، تمام عملیات هایی که می توانستند یک خطای عملوندی ایجاد کنند مورد تجزیه و تحلیل قرار گرفتند. این فرآیند چنان که باید چهار متغیر از هفت متغیری که ریسک بالایی داشتند را “مصون” نمود.
به خاطر تصمیمی که قبلا گرفته شده بود، شرایطی که نمی توانست رخ دهد، آزمایش نمی شد و از این رو، سه متغیر بدون بررسی رها شد. متأسفانه، این استثنای زیانبار در سیستم های IRS به خاطر همان سه متغیری که بررسی نشده بود، رخ داد، نه به خاطر چهار متغیری که مورد بررسی قرار گرفته بودند.
تصمیم به استفاده مجدد از نرم افزار ۱۰ ساله پرتاب کننده آریان ۴ در پروژه آریان 5 فی نفسه تصمیم ضعیفی نبود. آنچه از آن نمی توان گذشت اینست که فرآیند تضمین کیفیت در پروژه مشخص نکرده بود که نرم افزار آریان ۵ به برخی از برنامه های آریان ۴ احتیاج ندارد.
تصمیم تیم توسعه برای استفاده از نرم افزار، تصمیم پسندیده ای است؛ روش های توسعه شی گرا و جزء گرایی که امروزه مورد استفاده قرار می گیرند به شدت متکی بر همان مفاهیم گذشته اند. ولی استفاده مجدد از نرم افزار ریسک های خودش را دارد، حتی اگر خود نرم افزار برای استفاده مجدد طراحی شده باشد. تصور این که یک جزء نرم افزاری که در یک سیستم به طور عادی کار می کند می تواند به سیستم دیگری (با کمی تفاوت) انتقال داده شود معمولا سیستم و عملیات را دچار مشکل می کند. هدف از آزمایش یکپارچگی و رگرسیون، این است که تضمین شود چنین رویدادهایی مشکلی ایجاد نمی کند، ولی معلوم نیست که در این پروژه تا چه اندازه این فعالیت برای اجزای نرم افزاری گوناگون انجام گرفته است.
منبع: کتاب مدیریت موفق پروژه های IT
