دستاوردها

در برخی مواردی – که البته در کشور ما در اغلب پروژه‌ها – دیده شده است که برخی از تیم‌های توسعه‌ی نرم‌افزار سعی می‌کنند که به منظور تسهیل در برنامه‌ریزی و نیز ایجاد احساس پیشرفت و موفقیت در انجام کارها، در طی یک فاز یا حتی در طی یک تکرار، به صورت یکباره‌، یک دستاوردِ (مانند یک مدل یا یک مستند) را کامل کرده و آن را غیرقابلِ تغییر تلقی نموده و بایگانی ‌نمایند. در این تیم‌ها با چنین جملاتی برخورد می‌کنیم: “اجازه بدهید نیازمندی‌های را فعلاً کامل کرده و امضاء بگیریم و بعد که خیال‌مان راحت شد، کار را از روی آن‌ها ادامه دهیم” و یا “حالا دیگر طراحی کامل شد”.

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

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

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

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

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

سند واژه‌نامه

طرح توجیهی پروژه

فهرست مخاطرات

طرح پذیرش محصول

سند معماری نرم‌افزار

سند چشم‌انداز

طرح/برنامه‌ی آزمون

سند توصیف نیازمندی‌های نرم‌افزار

طرح/برنامه‌ی توسعه‌ی نرم‌افزار

 

تماس با ما

در حال ارسال

Log in with your credentials

Forgot your details?