توسعه نرم‌افزارهای متن باز (چرخه حیات نرم افزار)

چرخه حیات نرم افزار
پس از فراهم کردن زیربنای مورد نیاز برای توسعه نرم افزارهای متن باز، در این قسمت فعالیتهایی که برای پیشرفت پروژه متن باز نیاز است، می پردازیم:
تصمیم گیری و برنامه ریزی
تصمیم گیری و برنامه ریزیها باید در Mailing list عمومی و یا جلسه عمومی که همه حضور دارند انجام شوند. تصمیم گیری در یک جلسه عمومی، خیلی زمان گیرتر از تصمیم گیری در یک مجمع خصوصی توسعه دهندگان است، اما تنوع و تعداد زیاد نظرات، تصمیم گیری با کیفیت بهتری انجام خواهد شد. معمولا بحث و گفتگوها درمجامع عمومی به بلندا کشیده می شود بدون اینکه طولانی شدن بحث سودی در بهبود آن داشته باشد. بنابراین در این ساختار باید شخصی وجود داشته باشد که در صورتی که بحث به نتایج مطلوبی رسید آنرا خاتمه دهد و مانع از طولانی شدن بی نتیجه بحث شود، و نتایجی که افراد بر روی آن به تفاهم رسیده اند را استخراج کند. یکی از دلایل رایج شکست پروژه های نرم افزاری این است که به ملاقاتهای موردنیاز پروژه اهمیتی داده نمیشود. برای مثال به ندرت اتفاق می افتد که یک کاربر عادی بتواند در زمان تعریف ساختار پروژه به بحث وارد شود، اما به منظور دستیابی به یک موفقیت واقعی در پروژه های متن باز، ضروری است که یک کاربر عادی، بحث را آغاز کند و پس از آنکه نیازمندی های پروژه به صورت کامل تعریف شد، راه حلهایی برای پیاده سازی آنها تعیین شود و اگر چندین راه حل پیشنهاد شده بود، توسعه دهندگان باید بر اساس تجربه و آزمایش، بهترین را انتخاب کنند. به این ساختار، ساختار مبتنی بر کاربر(User – Centered) گویند، که متن باز برای موفقیت پروژه ها، به شدت این روش را پیشنهاد می کند.
تصمیمات مربوط به طراحی و اصولی که تصمیمات بر اساس آنها اتخاذ شده اند، باید در مستندات طراحی پروژه ثبت شوند، همچنین باید شخصی برای به روز نگه داشتن آنها مشخص شود.
تصمیمات زمان بندی پروژه باید در نقشه مسیر (road map) ثبت شوند. همانطور که گفته شد، توسعه دهندگان و کاربران براساس نقشه مسیر، از تغییرات و زمان اعمال آنها بر روی پروژه اطلاع کسب می کنند. زمان بندی، از ابعاد مختلف برای پروژه های متن باز با ارزش است زیرا بسیاری از افراد پروژه به صورت داوطلب با پروژه همکاری می کنند. توسعه دهندگان داخلی می توانند به یک کار خاص در بازه های زمانی مختلف گماشته شوند اما توسعه دهندگان خارجی انتخاب می کنند که چه کاری می توانند انجام دهند و برنامه ریزی خودشان را بر آن اساس تنظیم می کنند. در مورد نحوه release نرم افزار در ادامه توضیح داده می شود اما ۲ روش در مورد release نرم افزارها مورد توجه است:
۱/ برای یک شرکت که پروژه ای را آغاز می کند باید خصیصه هایی که می خواهند در release بعدی قرار داده شوند تعریف شده باشند و زمان بندی تعیین شده باشد سپس ویژگی های پیاده سازی شوند. اما برای پروژه های متن باز این ساختار بر عکس است، ابتدا یک ویژگی پیاده سازی میشود، سپس پس از آنکه تعداد این ویژگی ها زیاد شد، تاریخی برای release بعدی مشخص می گردد.
۲/ تنظیم زمان برای release بعدی موجب می شود که افراد پیمانه هایشان را تا آن زمان به پایان برسانند. در این ساختار، نرم افزار در تاریخ تعیین شده برای release، منتشر می شود و پیمانه هایی که آماده باشند در آن قرار می گیرند اما در صورتی که کار پیمانه ای به پایان نرسیده باشد باید تا release بعدی صبر کند.
Integrating Contribution
در یک پروژه متن باز موفق، تولید بسیاری از خصیصه های جدید و اصلاح اشکالات، توسط توسعه دهندگان همکار انجام می شود. با اینکه همه اشخاص می توانند کد منبع را بخوانند اما فقط تعداد کمی از گروه های توسعه دهنده، اجازه نوشتن مستقیم در کد منبع را دارند. در پروژه هایی مانند Mozilla وLinux، هر پیمانه یک یا چند مالک دارد. مالک پیمانه کسی که حق دارد در کد منبع پیمانه بنویسد یا در آن تغییرات اعمال کند، سایر کسانی که تمایل به این کار داشته باشند باید از مالک پیمانه اجازه کسب کنند. در پروژه ای مانند Apache یک هسته مرکزی از توسعه دهندگان بر روی کل پروژه، مدیریت می کردند که به آنها Committers گفته می شد. هر یک از آنها می توانستند بر روی هر یک از پیمانه های پروژه تغییرات اعمال کنند، هرچند اغلب، انجام تغییرات بزرگ به رای گذاشته می شد. در مورد پروژه های کوچک معمولا یک شخص خاص چنین مدیریتی را انجام می دهد و می تواند اجازه اعمال تغییرات در پروژه را به دیگران بدهد. اگر توسعه دهندگان خارجی یک اشکال را حل و آن را اعلام کنند، وظیفه مالک پیمانه است که آن را بررسی کند و در صورت تایید، آن را در کد منبع پیمانه اعمال کند.
How Decision Get Made Varies Among Open Source Projects
نقشهای تعیین شده در توسعه نرم افزارهای متن باز عبارتند از:
۱/ معماران
۲/ طراحان
۳/ پیاده سازان (کد نویس)
۴/ افراد کنترل کننده کیفیت (تسترها)
۵/ مدیرهای release
تعدادی از این نقشها باید در زمان مدیریت و اجرای فرآیند توسعه فعالیت داشته باشند (پیاده سازی، مدیریت، releaseها و کنترل کیفیت)، در حالی که سایر نقشها باید به عنوان نقشهای مورد نیاز، در کلیه مراحل تولید و ایجاد محصول نرم افزار، مورد توجه قرار گیرند) معماران و طراحان. (از دیدگاه توسعه نرم افزار به روش سنتی، نیازمندیها، خصیصه ها، معماری و طراحی باید قبل از پیاده سازی محصول مشخص شده باشند، البته در این سا

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