دوست عزیز انشا الله به زودی یک دوره آموزش کامل نرم افزار Rational Ros را برای شما و دیگر علاقمندان بر روی وبلاگ قرار می دهم امیدوارم که با نظرات خود من را در این زمینه یاری فرمائید.
مدیریت
درورد بر دوستان
مدیریت این سایت آماده است شما را در انجام پروژه های دانشجویی یاری نماید. لذا جهت ارتباط با ما از طریق ایمیل زیر تماس حاصل فرمایئد .
1.1 مدیریت بیرون دادن خروجی[1]پروژه‌های نرمافزاری متنباز بسیاری از نسخه‌های کاری خود را با توجه به اصل "زود خروجی بده، همیشه خروجی بده"[2] به عنوان خروجی بیرون می‌دهند. اگرچه به طور معمول ساده است که بین نسخه‌های مختلف با استفاده از شماره نسخه تفکیک قایل شویم اما گاهی‌اوقات درک این موضوع که یک شماره نسخه چه معنی می‌دهد بسیار مشکل است. به عنوان مثال یک بیرون دادن خروجی لینوکس اینگونه توصیف شده است که "نسخه 2.4.0-test1 که در واقع همان نسخه 2.3.99-pre10-pre3 است بیرون داده شد.". با اینکه بعضی از پروژه‌ها از شیوه غریبی برای شماره‌گذاری نسخه‌هایشان استفاده میکنند اما به طور معمول چند نکته برجسته در این کار مشخص است: · عددگذاری:اکثر پروژه‌ها از یک شیوه عدد گذاری برای شماره نسخه‌هایشان استفاده میکنند. به عنوان مثال عدد 2.3.20 به این معنی است که شماره اصلی ۲ و شاخه‌ی توسعه ۳ و نقطه بیرون دادن خروجی ۲۰. بسیاری از پروژه‌ها در یک زمان ممکن است دارای چند خط توسعه باشند که در آن صورت اعداد زوج در مکان دوم شماره نسخه به معنی شاخه پایدار میباشند و اعداد فرد به مشخص‌کننده شاخه توسعه هستند. · شاخه‌های توسعهبسیاری از پروژه‌ها شاخه‌های متفاوتی از توسعه را دارا میباشند و شاخه‌هایشان را پایدار (برای استفاده از محصول) و آزمایشی (مخصوص توسعه‌دهنده‌ها) می‌نامند. بعضی از پروژه‌ها حتی از سه شاخه استفاده میکنند مانند پروژه Debian که دارای سه شاخه پایدار، در حال آزمایش و ناپایدار میباشد. · وضعیت کارینرمافزارهای متنباز اغلب از واژه‌هایی برای مشخص کردن وضعیت کاری پروژه استفاده میکنند: آلفا (در حال توسعه)، بتا (در حال تکمیل قابلیت)، pre (نامزدهای ممکن بیرون‌داده شدن)، RC (نامزدهای بیرون‌داده شدن)، نهایی (خروجی بیرون‌داده شده رسمی). · نامهای به‌صورت کدبعضی از پروژه‌ها از نامهای به‌صورت کد برای بیرون دادنهای اصلیشان استفاده میکنند که به عنوان مثال potato به جای 2.2 نمونه‌ای از آن است. نامهای به‌صورت کد برای بسیاری از پروژه‌ها وسیله سرگرمی و یا بزرگ داشتن آن است و برای بدست آوردن این نامها تلاش زیادی صورت میگیرد. · تاریخهای بیرون دادنبعضی از پروژه‌ها از تاریخ بیرون دادن خود به عنوان شماره نسخه استفاده میکنند. · نسخه‌های دلخواهافراد اصلی دخیل در یک پروژه گاهی اوقات نسخه‌های مربوط به خود را در دسترس قرار می‌دهند و آنها را با نام ابتدایی خود مشخص میکنند. هدف از این کار این است که بتوان پروژه‌های جانبی را که ممکن است با خروجی رسمی یکپارچه نشوند را در بعضی از نقاط دنبال نمود 1.2 انتقال دادنانتقال دادن واژه‌ای است که بسته‌ای کردن نرمافزار، مدیریت وابستگیها، سیاست ارتقا و نصب را در برمی‌گیرد. بسیاری از پروژه‌های متنباز در این زمینه دارای ضعفهایی هستند که شاید دلیل آن این باشد که گرایش این پروژه‌ها بیشتر به سمت کاربران خبره است که از آنها انتظار می‌رود قادر باشند که با این موضوعات به راحتی کنار بیایند. انتقال ضعیف یک مانع بسیار بزرگ در سرراه ورود به محدوده نرم‌افزارهای متنباز است. پروژه‌هایی که تلاش اضافی صرف میکنند که کاربر به راحتی بتواند برنامه آنها را نصب کند به راحتی میتوانند کاربران و توسعه‌گران بیشتری را جذب کنند. یک نگاه تاریخی نشان می‌دهد که پروژه‌های متنباز زیاد به این قضییه توجه نداشته‌اند و برایشان مهم نبوده است که تنها یک گروه خاصی از افراد از محصولاتشان استفاده کنند. این دسته از پروژه‌ها سعی داشتند که با استفاده از یک محصول دارای ساختار مناسب و کارا باعث گسترش محصول خود شوند تا اینکه سعی کنند با استفاده از یک انتقال مناسب این جذب را فراهم سازند. اکنون مشخص شده است که اگر پروژه‌های متنباز سعی کنند این دو امر را باهم همراه سازند قطعاً کاربران بسیار زیادتری را نسبت به سایر نرم‌افزارها فراهم میکنند. مدیریت وابستگیها بین بسته‌های نرمافزاری یک موضوع بسیار مهم در پروژه‌های متنباز میباشد. با توجه به خاصیت ذاتی پروژه‌های متنباز که استفاده مجدد از دیگر کدهاست، بسیاری از بسته‌ها به ده‌ها بسته دیگر اعتماد میکنند و با فرض درست بودن آنها کار خود را انجام می‌دهند. راه‌حلهای مختلفی برای حل این مشکل توسعه داده شده است که یک نمونه آن APT است که Debian از آن استفاده میکند. APT قالبهای متعارفی تعریف میکند و با استفاده از آنها وابستگی بین بسته‌ها را تشخیص می‌دهد و قابلیت خودکار به‌روز شدن کامل سیستم را در اختیار می‌گذارد. 1.3 مستندسازیمستندات جامع و با کیفیت یک پروژه رمز استفاده دیگران از آن پروژه میباشد. یک مستندسازی خوب میتواند وسیله مناسبی برای کسانی که می‌خواهند به یک پروژه وارد شوند، باشد تا اطلاعات کافی را در آن مورد خاص کسب کنند. مستندات به صورت ساختاری رشد میکنند که مبدأ آن رشد نیز معمولا کامنت‌های گذاشته شده در کدها و یا پاسخهایی است که به سوالات مطرح شده در یک گروه نامه‌نگاری داده شده است. بسیاری از پروژه‌ها مستندات بسیار ناکافی در اختیار دارند و یا اینکه سعی نکرده‌اند مستنداتی بسازند که واقعاً کارآمد باشد. افراد غیر برنامه‌نویس انتظارات مختلفی از مستندسازی دارند: · داخلی و برخطافراد غیر برنامه‌نویس عقیده دارند که کمک حساس به متن و برخط حتماً باید همراه با برنامه کاربردی باشد. افراد غیربرنامهنویس به کمک برخط به عنوان یک مرجع سریع نگاه میکنند، برای همین اندیس‌گذاری کمک و توابع جستجو در کمک بسیار مهم هستند. اگر یک خودآموز برخط در برنامه کاربردی وجود داشته باشد، افراد غیربرنامهنویس حتماً به آن رجوع خواهندکرد. افراد غیربرنامهنویس به "Tips and Tricks"هایی که همراه با برنامه بیرون داده شده‌است رجوع میکنند. افراد غیربرنامهنویس به خودآموزهای چاپ‌شده‌ای که همراه با نرمافزار بیرون داده میشود رجوع خواهند کرد. افراد غیربرنامهنویس هیچ‌گاه یک کتاب راجع به یک برنامه کاربردی نمی‌خرند زیرا معتقدند که کتابهای فنی مختص برنامه‌نویسان است. · سادهافراد غیربرنامهنویس به هیچ‌وجه راجع به جزییات توضیح نمی‌خواهند. آنها به جوابهای ساده احتیاج دارند. این افراد از وارد شدن به جزییات بیزارند؛ دستورالعمل‌های کوتاه و باقاعده را دوست دارند؛ به اطلاعاتی علاقه دارند که جواب این سوال است: "چگونه من می‌توانم فلان کار را انجام دهم"(که فلان کار یک قابلیتی است که برنامه در اختیار شما قرار می‌دهد) و اینکه افراد غیربرنامهنویس نمی‌خواهند اطلاعاتی راجع به اینکه قابلیتهای سیستم چگونه پیادهسازی شدهاند مشاهده کنند. · کامل، درست و بهروزفرض افراد غیربرنامهنویس این است که کمک برخط در هر نسخه جدید برنامه به‌روز میشود. اگر قسمتی از کمک برخط وجود نداشته باشد و یا کهنه و از کارافتاده باشد این افراد دیگر از آن استفاده نخواهند کرد. اگر این فرد نتواند جواب یک سوال را در کمک برخط پیدا کند یا با پشتیبان فنی تماس خواهد گرفت و یا از یک برنامه‌کاربردی دیگر استفاده خواهد کرد. نوشتن مستندات میتواند یک مدل برای تجارت باشد. بسیاری از پروژه‌های متنباز از طریق فروختن مستندات، خود را تامین مالی میکنند. این مساله شاید کمی ریاکارانه و متناقض به نظر برسد، فروختن چیزی که به محصولات متنباز وابسته است و شما با استفاده از آن می‌توانید محصولات متنباز دیگری تولید کنید، ولی به هرحال این کار انجام میشود. علاوه براین لیسانس‌های خاص دیگری نیز وجود دارند که سوراخ مابین استفاده اقتصادی و به طور مجانی در اختیار گذاشتن اطلاعات را پر میکنند. |
نرم‌افزارهای متنباز روز به روز گسترش بیشتری در جامعه‌ی کامپیوتری پیدا میکنند. این گسترش مانند هر گسترش دیگری در زمینه‌های مختلف، موافقان و مخالفان خاص خود را پیدا کرده است. موافقان عقیده دارند که متنباز بودن محصولات باعث رشد هرچه بیشتر برنامههای کاربردی خواهد شد و همچنین از بسیاری از دوباره‌کاریها پرهیز خواهد شد. گروه مخالف که اکثراً کسانی هستند که منافعشان با گسترش محصولات متنباز به خطر می‌افتد، بیشتر سعی دارند که محصولات متنباز را خطری در راه گسترش نرمافزار معرفی کنند و برای نابود کردن آن نیز از هیچ‌گونه تلاشی فروگذار نمی‌کنند. زمانی نرمافزار متنباز را سرطان می‌خوانند و زمان دیگر به گونه‌ای دیگر بر آن می‌تازند.
همانگونه که در مثبت بودن اثرات محصولات متنباز در رشد نرم‌افزارها توافق اکثریتی وجود دارد، دراین مطلب نیز که محصولات متنباز معایبی هم در فرایند تولید و هم در محصولات تولیدی دارا میباشند برای هیچ‌کس شکی وجود ندارد. در این مقاله سعی شده است که فرایند تولید و همچنین محصولات تولید شده مورد بررسی قرار بگیرد و ضعفها و قوتهای آن بدون هیچ‌گونه تعصب یا غرضی بررسی شود.
در بخش اول مقاله ابتدا یک معرفی بر مهندسی نرمافزار صورت خواهدگرفت و سپس مفهوم فرایندهای مهندسی نرمافزار بررسی خواهد شد و فرایند معمول مهندسی نرمافزار بخش به بخش مورد مطالعه قرار خواهد گرفت. در ادامه این بخش سعی میشود برای مراحل ذکر شده در فرایند معمول مهندسی نرمافزار معادلی در فرایند تولید نرمافزار متنباز پیدا شود و در حقیقت مقایسه‌ای بین فرایند مهندسی نرمافزار و فرایند تولید نرم‌افزارهای متنباز صورت میگیرد. در این مقایسه بین نرم‌افزارهای متنباز بدون حمایت مالی و نرم‌افزارهای متنباز تجاری تفکیک قایل می‌شویم و به گونه‌ای بین فرایند تولید این دو نوع محصولات متنباز نیز مقایسه‌ای صورت می‌دهیم. در تمام مقایسه‌ها سعی میشود که کارهایی که اکنون انجام میشود و کارهایی که باید انجام شود به دقت بررسی شود.
در بخش دوم به تولید نرم‌افزارهای متنباز به طور دقیقتری نگاه می‌کنیم و فعالیتهای دیگری را که برای تولید نرم‌افزارهای متنباز انجام میگیرد و یا باید انجام بگیرد را مورد مطالعه و بحث قرار می‌دهیم. بخش سوم به نوعی نگاهی موشکافانه بر اساس بخشهای قبلی و به صورت موردی در مقوله‌های مختلف مهندسی نرمافزار محسوب می شود.در نهایت نیز با یک بررسی رسمی ریاضی روی یک پروژه شناخته شده متنباز بحث خاتمه داده می شود.
نرم‌افزارهای متنباز نیز مانند تمام محصولات نرم متن‌افزاری دیگر باید مراحلی را طی کنند تا ساخته شده و مورد استفاده قرار گیرند. یکی از مهمترین بحثهایی که راجع به نرم‌افزارها وجود دارد بررسی اهمیت مهندسی نرمافزار در ساخت و تولید نرم‌افزارها میباشد. در ادامه این بخش ابتدا راجع به مفهوم مهندسی نرمافزار و فرایندهای آن صحبت شده و سپس تلاش میشود که مقایسه‌ای مابین فرایندهای تولید نرم‌افزارهای متنباز با فرایندهای متداول مهندسی نرمافزار صورت گیرد.
مهندسی نرمافزار یک زمینه بسیار گسترده است که بسیار وسیع‌تر از نوشتن یک برنامه میباشد. شاید یکی از بهترین تعاریفی که برای مهندسی نرمافزار وجود دارد این مطلب است که:
مهندسی نرمافزار عبارت است از وضع اصول مهندسی بجا و مناسب و استفاده از آنها برای بدست آوردن یک نرمافزار مقرون به صرفه که قابل اطمینان بوده و روی ماشینهای واقعی به طرزی کارآمد عمل کند.
مهندسی نرمافزار یک فرایند لایه‌ای است که پایه و اساس آن لایه فرایند میباشد. فرایند مهندسی نرمافزار در حقیقت چهارچوبی برای مجموعهای از فعالیتها است که این فعالیتها بستری برای اعمال روشهای فنی، تولید محصولات کاری (مدلها، مستندات، داده‌ها، گزارشها، فرمها و ...)، اطمینان از کیفیت و مدیریت تغییرات میباشند. عناصر تشکیل دهنده فرایندهای مهندسی نرمافزار به طور معمول عبارتند از: جمع‌آوری نیازمندیها، طراحی در سطح سیستم، طراحی‌جزییات، پیادهسازی، یکپارچه‌سازی، تست کردن و پشتیبانی و نگهداری. در ادامه در مورد این عناصر توضیح داده میشود.
اولین قدم در فرایند مهندسی نرمافزار تولید یک مستند کاری است. در این مستند دلایلی که باعث شده است نیاز به این محصول حس شود و لیستی از قابلیتهای محصول که این نیازها را رفع میکند شرح داده شده است. کلیت مستند در حقیقت جواب به این سوال است که: چرا باید بسازیم و چه کسی از آن استفاده خواهد کرد؟.
این قدم اول در حقیقت گام اساسی و پایه‌ای فرایندی میباشد که اگر درست نهاده نشود با احتمال بالایی منجر به تولید محصولی ناکارآمد و بدردنخور خواهد شد.
این مرحله از فرایند مهندسی نرمافزار یک توضیح سطح بالا از محصول است که در قالب ماژولهایی که محصول را می‌سازند و ارتباط بین این ماژولها بیان میشود. هدف از این مستند ساخته شده، ابتدا بدست آوردن اطمینان از این موضوع است که محصول ساخته خواهد شد و کار نیز خواهد کرد و سپس ساختن پایه‌ای برای تخمین زدن نیرو و زمان مجموع لازم برای ساختن محصول میباشد.
طراحی جزییات در واقع طراحی جزییات ماژولهایی است که در مرحله قبل مشخص شدهاند. واسطهای این ماژولها و همچنین جزییات داده‌ساختارهایی که استفاده خواهند شد از جمله مطالبی است که در این مرحله تعیین خواهد شد. تخمین دقیقتر زمان و نیروی لازم برای ساخت ماژولهایی که در این بخش و بخش قبل مشخص شدهاند و همچنین توالی ساخت آنها از جمله دیگر کارهایی است که در این مرحله انجام میگیرد.
تمام ماژولهایی که جزییات آنها در مرحله قبل مشخص شده است، در این مرحله پیادهسازی خواهند شد. این ماژولها که در حقیقت قطعات محصول اصلی هستند، هرکدام به صورت جداگانه پیادهسازی خواهند شد.
در این مرحله تمام ماژولهای پیادهسازی شده در مرحله قبل بر اساس منطق طراحی به یکدیگر متصل شده و در قالب یک برنامه کامل در می‌آیند. این برنامه در حقیقت همان محصولی است که هدف از طی تمام این مراحل ساختن آن بود.
محصول ساخته شده در مراحل قبل را میتوان از جنبه‌های مختلفی از قبیل صحت، کارایی و ... آزمایش کرد. آزمون صحت محصول معمولا به دو شکل صورت میگیرد که به شرح زیر است:
پس از اینکه محصول به مشتری داده شد، از این پس از جمله وظایف فروشنده و تولیدکننده این است که در صورت وجود اشکالی در محصول آن را رفع نماید. همچنین ممکن است در قرارداد مشخص شده باشد که در صورت خواست مشتری برای تغییرات در محصول، این تغییرات توسط تولیدکننده صورت بگیرد.
نرم‌افزارهای متنباز از نظر مالی به دو دسته مختلف طبفه‌بندی می‌شوند. دسته اول نرم‌افزارهایی هستند که بدون هیچ‌گونه حمایت مالی تولید می‌شوند و دسته دوم نرم‌افزارهایی هستند که علاوه بر اینکه متنباز هستند دارای حمایت مالی نیز میباشند. فطعاً فرایند تولید این دو گروه نرمافزار دارای تفاوتهایی با یکدیگر میباشد. به همین دلیل فرایند تولید این دو گروه هر کدام به صورت جداگانه در ادامه بررسی خواهد شد.
نرم‌افزارهای متنباز بدون حمایت مالی برای تولید و گسترش خود مراحلی را طی میکنند. این مراحل معادل مراحل فرایندهای مهندسی نرمافزار نمی‌باشد و کارهایی که در مراحل این فرایند طی می‌شوند بعضاً با کارهای معادل خود در فرایند مهندسی نرمافزار متفاوتند و بعضی مراحل نیز که در فرایند مهندسی نرمافزار وجود دارد در این فرایند موجود نمی‌باشد. در ادامه سعی میشود که معادل مراحل فرایند مهندسی نرمافزار را در فرایند تولید نرمافزار متنباز بدون حمایت مالی بررسی شود.
نرم‌افزارهای متنباز معمولاً هنگامی نوشته می‌شوند که احتیاج به یک محصول از جانب فردی احساس میشود و یا اینکه علاقه به داشتن آن محصول وجود دارد. این موضوع غالباً در هنگام برخورد با مسایل روزانه برای شما پیش میآید و در نتیجه الزاماً افرادی که اقدام به تولید این محصولات میکنند مهندس نرمافزار نیستند. ممکن است مسولیت یک سیستم و یا کاری از این نوع را بر عهده داشته‌باشند. این محصول پس از اینکه ساخته شد به صورت متنباز در اختیار همگان قرار میگیرد. افراد مختلف نیز که این محصول را دریافت کرده و استفاده میکنند، میتوانند در مورد آن نظر بدهند.گروهی ایرادات این محصول را که هنگام کار برایشان پیش آمده است را گزارش می‌دهند و یا خود این مشکلات را رفع میکنند. گروه دیگری قابلیتهایی را که به نظرشان می‌رسد که مناسب است به این محصول اضافه شود را اعلان میکنند و یا خود اقدام به اضافه‌کردن این قابلیت به محصول میکنند. همانگونه که مشاهده می‌کنید، فرایند تولید نرمافزار متنباز یک مرحله فوق‌العاده قوی جمع‌آوری نیازمندیها را دارا میباشد زیرا که برای استفاده‌کنندگان بسیار ساده است که نظرات خود را اعلان کنند و مرحله جمع‌آوری نیازمندیها دارای افراد نظردهنده‌ای در سراسر جهان میباشد. محل اعلان این نیازمندیها نیز گروههای خبری و گروههای نامه‌نگاری میباشند. تنها مشکلی که در این بین وجود دارد این است که هنگام مطرح شدن این نیازمندیها که شاید بسیار زیاد نیز باشند به چه ترتیبی باید با آنها برخورد نمود و به چه ترتیبی باید به آنها اولویت داد. یک راه‌حل که به عنوان مثال نرمافزار Mozilla نیز از آن استفاده میکند، روش رای‌گیری برای تعیین اولویتهاست که بدین وسیله با استفاده از نظر اکثریت استفاده‌کنندگان قابلیتهای جدید اضافه می‌شوند. البته لازم به ذکر است که این شیوه جمع‌آوری نیازمندیها ممکن است به وسیله تحلیلگر سیستم انجام شود که نظرات مختلف را که داده شده است را جمع میکند و آنها را بازبینی کرده و مشخص میکند که چه قابلیتی باید به سیستم اضافه شود و در حقیقت نظرات داده شده افراد را تحلیل کرده و به‌صورت یک قابلیت لازمه سیستم در‌می‌آورد.
به طور معمول هیچ طراحی در سطح سیستمی برای یک محصول متنباز بدون حمایت مالی وجود ندارد. طراحی سیستمی در این نوع محصولات اغلب به صورت ضمنی انجام میشود و معمولاً از نسخه دو یا سه به بعد از یک محصول در واقغ یک طراحی سطح سیستمی برای محصول وجود دارد، هرچند که در جایی نوشته نشده باشد و یا عملاً این مرحله به عنوان یک مرحله جداگانه انجام نشده باشد.
در این مرحله است که این فرایند جداشدن خود را از روشهای معمول مهندسی نرمافزار نشان می‌دهد و تا حدی ضربه‌پذیر نشان می‌دهد. شما ممکن است بتوانید کمبود یک روش معمول جمع‌آوری نیازمندیها و یا تضمین کیفیت را با استفاده از برنامه‌نویسان بسیار خوبی که در اختیار دارید جبران کنید ولی هنگامی که یک طراحی سیستمی برای تولید محصول شما وجود نداشته باشد(حتی اگر این طراحی در ذهن تولید کنندگان وجود داشته باشد)، قطعاً کیفیت پروژه تحت تاثیر قرار خواهد گرفت.
همانگونه که گفته شد در فرایندهای بدون حمایت مالی معمولاً افراد سعی میکنند کاری را انجام دهند که به نظرشان جالب میآید. برای انجام این کار نیز سعی میکنند فرایندی را طی کنند که برایشان جذاب باشد. در قسمت قبل گفته شد که معمولاً طراحی سیستمی برای اینگونه فرایندها وجود ندارد که شاید یک دلیل عمده آن این باشد که برای تولیدکنندگان این گونه از محصولات متنباز جذابیت لازمه را ندارد هرچند که یک مرحله کلیدی میباشد.
مرحله طراحی جزییات برای بسیاری از تولیدکنندگان جذاب و سرگرم‌کننده است و معمولاً در این فرایندها، انجام میشود اگرچه این طراحی در واقع نقش یک اثر جانبی برای پیادهسازی را بازی میکند و مشابه طراحی جزییات فرایندهای مهندسی نرمافزار نیست.
تنها کاری که در این مرحله انجام میشود مستندسازی واسطهای برنامه‌نویسی برنامه کاربردی در قالب یک خودآموز است که معمولا در قالب manualهای موجود در لینوکس میباشد.
این مرحله از فرایند برای برنامه‌نویسان جذابترین مرحله است و شاید امید به انجام این مرحله باشد که انگیزه لازم را برای برنامه‌نویس برای تولید محصول ایجاد کرده است. این مرحله هسته اساسی این فرایند است و در حقیقت علاوه بر پیادهسازی، طراحی را نیز در بطن خود به همراه دارد البته قطعاً منظور، طراحی کامل و دقیق فرایندهای مهندسی نرمافزار نیست. البته این موضوع که برنامه‌نویسی بدون توجه به مراحل دیگر این مرحله را انجام دهد، آزادی فوق‌العاده‌ای به برنامه‌نویس می‌دهد که قابل بیان نیست. این آزادی همانگونه که میتواند مفید باشد میتواند مضر نیز باشد و در واقع باعث شود برنامه‌نویس با تولید کردن کدهایی که به خاطر نداشتن ساختار مناسب، قابلیت توسعه و استفاده مجدد را ندارند به مهمترین اهداف نرم‌افزارهای متنباز دست نیابد.
مطلب بسیار خوبی که راجع به این مرحله وجود دارد این است که برنامه‌نویسان در این مرحله سعی میکنند قالبهای جدید کاری و همچنین کارهای تازه برنامه‌نویسی آزمایش نشده خود را آزمایش کنند که این موضوع همواره باعث پیدایش قالبهای ظاهری جالبتر و همچنین شیوه‌های پویا و کاراتر در برنامه‌نویسی میشود. مثلاً یک برنامه‌نویس قالبهای ظاهری برنامه خود از قبیل شیوه نام‌گذاری متغیرها و نحوه تورفتگی کد و ... را تغییر می‌دهد و از شیوه جدیدی که ممکن است برای اولین بار توسط این برنامه‌نویس انجام شود و پس از مدتی بسیار همه‌گیر و مورد استفاده واقع شود استفاده میکند. همچنین ممکن است یک فن بسیار بدیع و جالب را که تا به حال استفاده نشده است را در کد برنامه خود به کار میگیرد و در صورت جواب دادن قطعاً از این پس بسیار مورد استفاده همگان قرار میگیرد. تفاوت بین این فرایند و فرایند مهندسی نرمافزاری که برای پروژه‌های تجاری انجام میشود نیز در واقع همین است. برنامه‌نویس موجود در یک فرایند متنباز غیر تجاری برای علاقه خود برنامه می‌نویسد و تحت فشار نیست پس به راحتی میتواند شیوه‌های بدیع و تازه‌ای را ازمایش کند بدون ترس از این مطلب که جواب نگیرد اما در یک فرایند تجاری همواره سعی میشود که بسیار محافظه‌کارانه عمل شده، روشهایی استفاده شوند که تاکنون جواب خوبی دادهاند. از طرف دیگر کلاً نرم‌افزارهای متنباز چه تجاری و چه غیرتجاری این مزیت را نسبت به سایر نرم‌افزارها دارند که هرگونه نکته بدیعی که در ساختار آنها وجود داشته‌باشد قابل مشاهده است و در حقیقت این نرم‌افزارها یک مجموعه فوق‌العاده آموزشی برای استفاده‌کنندگان میباشند اما نرم‌افزارهایی که کد آنها بیرون داده نمی‌شود حتی اگر ابتکاری نیز در آنها بکار رفته باشد معمولاً کسی از آنها مطلع نمی‌شود و در حقیقت ابتکارها نیز منحصر به مبدعشان هستند و سایر افراد نمی‌توانند از آنها استفاده کنند.
نکته منفی که در مرحله پیادهسازی این فرایند وجود دارد این است که هیچ‌گونه بازبینی کد از جانب کسی، قبل از اینکه نرمافزار بیرون داده شود صورت نمی‌گیرد احتمال اشتباهات منطقی و یا ظاهری در کد هنگامی که در اختیار همگان قرار میگیرد بسیار زیاد است. به عنوان مثال ممکن است برنامه‌نویس از سه قالب ظاهری مختلف برنامه نویسی در برنامه استفاده کرده باشد بدون اینکه متوجه این موضوع شده باشد و یا اینکه اشتباهات منطقی بسیار واضحی در برنامه وجود داشته باشد که اگر کسی کد را بازبینی می‌کرد به سادگی متوجه آن می‌شد. البته کد بعد از بیرون داده شدن بازبینانی بسیار حرفه‌ای در سراسر جهان خواهد داشت که به سادگی متوجه این موضوعات شده و میتوانند این مشکلات را رفع کنند و کد جدیدتر را بیرون دهند.
نرم‌افزارهای متنباز بدون حمایت مالی از بهترین روش تست در صنعت دنیا استفاده میکنند البته اگر تست‌های ناسا را در مجموعه مقایسه خود در نظر نگیریم. دلیل این امر این است که کاربرانی که از این نرمافزار استفاده میکنند چون پولی پرداخت نکرده‌اند بسیار دوستانه‌تر برخورد میکنند و توسعه دهندگانی که از کد استفاده میکنند نیز سعی میکنند که کمک قابل توجهی در این امر باشند برای همین یافتن ایرادات، گزارش آنها و برطرف کردن آنها بسیار دوستانه و سریع و در سطح بسیار وسیعی انجام میگیرد.
آزمون طی‌شده در فرایند مهندسی نرمافزار از کمبود یک مساله رنج می‌برد و آن قرار گرفتن نرمافزار در شرایط دنیای واقعی و کار کردن آن در شرایط غیرقابل پیش‌بینی میباشد. بسیاری از تلاشهایی که در زمینه آزمایش کردن صورت میگیرد همگی حاوی این موضوع هستند که شرایطی مشابه واقعیت فراهم شده و سپس نرمافزار آزمایش شود و این دقیقاً موضوعی است که به طور ذاتی در آزمایش نرم‌افزارهای متنباز بدون حمایت مالی وجود دارد: قرار گرفتن نرمافزار در دنیای واقعی و کارکردن آن در شرایط غیر قابل پیش‌بینی.
ضعفی که در این زمینه در نرم‌افزارهای متنباز وجود دارد این است که بدلیل وجود داشتن کد برنامه ساده‌تر میتوان به ایرادات برنامه پی برد و این خطر حضور افراد سودجو را بیشتر میکند. در صورت یافت‌شدن یک ایراد در برنامه ممکن است افرادی وجود داشته باشند که بخواهند از آن سوءاستفاده کنند. در واقع این افراد پس از پی بردن به یک ایراد موجود اقدام به خرابکاری با استفاده از این مشکل میکنند و هرچه مقدار استفاده از این نرمافزار در سطح وسیعتری انجام شود امکان گسترش بیشتر این خرابکاری نیز وجود دارد. البته همواره در مقابل افراد سودجو افراد سازنده‌ای نیز وجود دارند که پس از مشخص شدن این مشکل اقدام به رفع آن مینمایند.
“وای ببخشید‿ جمله‌ای است که هنگام گزارش یک ایراد از جانب کاربر شنیده میشود. “وای ببخشید و متشکرم‿ جمله‌ای است که اگر علاوه بر گزارش ایراد, اصلاح‌کننده ایراد نیز فرستاده شده باشد شنیده میشود. وجود نداشتن پشتیبانی و نگهداری باعث میشود که تعدادی از کاربران از استفاده از نرم‌افزارهای متنباز بدون حمایت مالی صرف نظر کنند. اما باز این امکان وجود دارد که گروهی پشتیبانی نرمافزار را بر عهده بگیرند و کاربر با مبلغی بتواند از پشتیبانی آنها استفاده کند و یا اینکه نسخه‌های تجاری یک نرمافزار متنباز بیرون داده شوند و کاربر از آنها استفاده کند.
بسیاری از نکات مربوط به این فرایند در قسمت فرایند تولید نرمافزار متنباز بدون حمایت مالی گفته شد و بسیاری از مسایل این دو فرایند نیز مشترک میباشند. مطلبی که در این راستا قابل اهمیت است این میباشد که این فرایند به دلیل حمایت مالی میتواند از هر یک از فرایندهای مهندسی نرمافزار را در رأس کار خود قراردهد و در عین حال از سایر مزیت‌های فرایندی که شامل حال نرم‌افزارهای متنباز میشود نیز استفاده نماید. تنها مسأله‌ای که وجود دارد این است که در صورت وجود خطا در این نرمافزار، مشابه نرم‌افزارهای متنباز بدون حمایت مالی همه چیز به خوبی و خوشی تمام نمی‌شود و کاربران چون پرداخت مالی داشته‌اند کاملاً انتظار محصولات بدون ایراد و خطا را دارند و پشتیبانی و نگهداری نیز جزء بدیهیات اینگونه نرم‌افزارها میباشد.
فرآیند نمونه‌سازی در بسیاری از پروژه‌های متنباز دیده میشود. بسیاری از پروژه‌ها، معمولاً به صورت ناآگاهانه، از متدولوژی برنامه‌نویسی گروهی[2] استفاده میکنند. جملات مصطلح در تولید نرمافزار متنباز مانند "زود خروجی بده، همیشه خروجی بده" و "کدت را به من نشان بده" مثال‌های خوبی در این زمینه هستند. توسعه‌دهندگان به کار کردن با روشهای آزمایشی ترغیب می‌شوند و اگر تست‌کنندگان از بازخورد مثبتی ارایه کنند، کار آنها ممکن است با خط اصلی تولید نرمافزار یکپارچه شود. نمونه‌سازی سریع، احتمالاً یک از قوی‌ترین خصوصیات پروژه های متنباز است. [7] توضیح می‌دهد:
"ما هرگز از روش XP استفاده نمی‌کنیم. کلمه XP زمانی که ما پروژه را شروع کردیم، وجود نداشت. ما بعدها در پروژه‌مان از روش XP استفاده کردیم. XP روش خوبی برای پروژه های نرمافزار است اگر:
دیگران، مانند Linus Trovalds، نگاه ریشه‌ای به قضییه دارند؛ به این شکل که "هیچ کس به اندازۀ من Linux را "طراحی" نکرد، و من شک دارم که بسیاری با من مخالف باشند. Linux رشد کرد؛ با بسیاری از تغییرات رشد کرد، و به خاطر اینکه تغییرات کمتر از اتفاقات بودند، تغییرات سریعتر و جهت‌دار تر از ذرات اولیه DNA بودند."
Trovalds معتقد است که نرم‌افزارها طراحی نمی‌شوند، بلکه متکامل می‌شوند. او می‌گوید "و حتی من جلوتر می‌روم و ادعا می‌کنم که هیچ نرمافزار بزرگی که در بازارهای عمومی موفق بوده بر پایه این چرخه عمر زیبا نوشته نشده است. آیا شما پروژهای را می‌شناسید که واقعاً با فهمیدن اینکه چه کاری باید انجام بشود، فاز طراحی موشکافانه و فاز پیادهسازی به پایان رسیده باشد...
نرمافزار متکامل میشود؛ طراحی نمی‌شود. تنها سؤال این است که شما چقدر دقیق تکامل پروژه را کنترل کنید و چقدر باز نسبت به تغییر کدهای خارجی رفتار می‌کنید.
کنترل بیش از حد فرآیند تکامل، شما را می‌کشد. قطعاً و بدون تردید. همیشه: چه در زیست‌شناسی و چه در نرمافزار."
مدیریت نسخه‌ها که مدیریت پیکربندی نیز گفته میشود تمامی تغییرات داده‌شده به داده‌های پروژه را ضبط میکند و البته این قابلیت را دارد که نرمافزار را در هر لحظه که اراده کنید به حالت پیشین خود بازگرداند.
مدیریت نسخه‌ها در پروژه‌های نرمافزاری استفاده بسیار زیادی دارد که بعضی از آنها عبارتند از:
مدیریت نسخه‌ها یکی از مهمترین فعالیتهای توسعه‌دهندگان است و ابزارهای بسیاری وجود دارد که این کارها را به کمک آنها میتوان انجام داد. مدیریت نسخه‌ها در حقیقت جزیی از محیط توسعه شده است و برروی همه بسترهای مختلف نیز وجود دارد. CVS ابزاری است که بیشترین استفاده را دارد ولی دارای محدودیتهایی برای پروژه‌های بزرگ میباشد و اکنون ابزارهایی با خصوصیات کاملتر نیز وجود دارد.
(ادامه دارد...)
منبع : FOSS_ir 11طرح ملی نرم‌افزارهای آزاد-متنباز ایران.htm
انتخاب راه حل :
هدف ، انتخاب بهترین راه حل کامپیوتری برای برآورده کردن نیازمندیهای کاربر است .
شرح نیازمندیها :
در این مرحله حاصل از مرحله شناخت ، در قالب مدلهای تحلیل و طراحی به صورت دقیق و خلاصه توسط مهندس نرم افزار مشخص میشود .
طراحی منطقی :
هدف از طراحی منطقی تعیین منطق عملیات سیستم مکانیزه بادر نظر کرفتن نیازهای کاربر است .
طراحی فیزیکی :
هدف از طراحی فیزیکی تعیین دادها ، پردازه ها ، ورودیها و بالاخره خروجیها با استفاهده از زبان و محیط فیزیکی تعیین شده است .
طراحی فیزیکی داده ها :
سه نوع عملیات برای طراحی داده ها وجود دارد . این عملیات شامل تعیین محیط فیزیکی و استراتژی طراحی ، طراحی داده های فیزیکی و بالاخره بهینه سازی حاصل از طراحی داده ها است .
طراحی رابط داده :
چنانچه دیدگاهی که از داده ها و اطلاعات ذخیره شده وجود دارد متفاوت از واقعیت فیزیکی داه ها باشد باید رابطی جهت تبدیل داده ها ایجاد شود .
طراحی پردازه های فیزیکی :
هدف ، تبدیل طرح منطقی پردازه ها به مدل فیزیکی عملیات در سیستم جدید مکانیزه است .
پنج مرحله اصلی تحلیل و طراحی سیستم عبارتند از :
|
طراحی فیزیکی |
طراحی منطقی |
شرح نیاز |
تحلیل نیاز |
امکان سنجی |
متدولوژی SSADM
SSADM یکی از متدولوژی های شناخته شده تولید سیستم های مکانیزه است .
هدف از امکان سنجی ، ارزیابی اولیه جهت قول یا رد پیشنهاد انجام پروزه نرم افزاری است . تحلیلیگر مجرب باید قادر به شناخت نیازها و ارئه راه حل های ممکن برای انجام پروژه بوده ، هزینه های سخت افزار ، نرم افزار ، زمان و افراد لازم برای اجرای پروژه را مشخص نماید .تخمین نا صحیح هزینه ها میتواند برای تحلیلگر و سازمان وی فاجعه آمیز باشد ، موفقیت در امکان سنجی مستلزم تجربه زیاد و برنامه نویسی و شناخت کافی از امکانات سخت افزاری ، ایجاد شبکه ها و ابزار های جانبی کامپیوتر و بالاخره آشنایی کامل با سیستم های عامل ، زبانهای برنامه سازی ، بسته های نرم افزاری و موارد کاربرد آن ها است .
در مرحله تحلیل نیازمندیها ، مشکلات سیستم موجود بررسی وراه حل های ممکن ارائه می شود .مسلما لازم است که قبل از ارئه هر راه حلی ، تعریف دقیقی از جزئیات مساله فراهم شود . مهندس نرم افزار با بکار گیری روش نگرش سیستمی در شناخت مسائل باید کمک کند تا افراد و مدیران بتوانند مشکلات را تعیین کنند برای این منظور در نگرش سیستمی به صورت زیر عمل می شود :
الف-تعیین عملکرد کلی : ابتدا محیط عملیاتی سیستم مشخص میشود
ب- تعیین شبکه عملیات داخلی : برای تعیین عملکرد داخلی ، معمولا هر سیستم را در قالب شبکه ای از زیر سیستم ها و واحدهای عملیاتی مشخص و سپس برای هر واحد عملیاتی خروجی ها را تعیین میکنند ارتباط بین عناصر در شبکه عملیاتی سیستم ها را در قالب دیاگرامی به نام دیاگرام گردش دادها میتوان مشخص نمود .
ج-تعیین مشکلات : اگر خروجیهای تعیین شده با استانداردهای مدیریت مطابقت نداشته یا گمتر از میزان پیش بینی شده باشند ویا اینکه خروجی پیش بینی شده در شرح وظایف واحدی ایجاد نشود ، مشکلی در انجام وظیفه آن واحد عملیاتی وجود دارد . بنابر این برای تعیین مشکلات باید معیارهای ارزیابی ، استانداردها و انتظارات مسئولان از عملکرد یک سیستم و واحدهای عملیاتی آن را شناخت .
د- یافتن منشاءمشکلات:با تعیین کمبود در خروجی حاصل از عملکرد یک واحد ، مسلما علت یا در عملکرد آن واحد است و یا اینکه اطلاعات به اندازه کافی به موقع به آن واحد نمی رسد .
ارئه راه حل : مسلما یک مهندس نرم افزار در حدی نیست که بتوتند برای حل مسائل هر سیستمی راه حل پیشنهاد نماید اما با دانشی که از سیستمهای اطلاعاتی وامکانات سخت افزاری و نرم افزاری دارد ، میتواند در موارد زیر با مدیران ومسئولان جهت تعیین راه حلی برای مشکلات مشخص شده مشاوره کند :
- ایجاد یک شبکه اطلاع رسانی کامپیوتری برای تهیه اطلاعات مورد نیاز .
- ایجاد یک سیستم اطلاعات مدیریت جهت تهیه گزارشات مورد نیاز .
- ایجاد یک سیستم مکانیزه برای پشتیبانی در تصمیم گیریها .
- ایجاد یک سیستم مکانیزه مبتنی بر پایگاه دانش به عنوان مشاور در امور .
- ایجاد یک سیستم مکانیزه خبره که بتواند مانند یک متخصص در زمینه خاص عمل نماید .
، تحلیل نیازمندیها در سه مرحله انجام می شود. مرحله اول شامل شناخت SSADMاز دیگاه
سیستم موجود ، مسائل ، مشکلات و نیازمندیهای کاربر است . در مرحله دوم راه حل ممکن مشخص می شود و با لاخره در مرحله سوم شرح نیازمندیها تهیه و به عنوان گزارش مرحله تحلیل نیازمندیها به مسئولان جهت تصمیم گیری و انتخاب راه حل بهینه ، ارئه میشود .
قبل از شناخت نیازها باید مشکل را درک کرد . تشخیص نیاز بدون شناخت سیستم موجود و مسائل آن دشوار است لذا قبل از هر چیز باید سیستم موجود ، اهداف و مسائل آن را شناخت . سپس میتوان نیازها را مشخص نمود به طور خلاصه مراحل شناخت به صورت زیر است :
تعیین چهار چوب عملیات شناخت (1
شناخت سیستم موجود (2
3) تعیین مشکلات و نیازها
4)
5) تهیه گزارش شناخت