مقایسه SQL server 2000 و Oracel 9i

دوستان عزیز در رابطه با امکان سنجی مربوط به مهندسی نرم افزار در بخش پایگاه داده من قسمتی از مطالبی که تازه ترجمش کردم ( دست و پا شکسته ) برای بالا بردن اطلاعات شما عزیزان قرار می دهیم اگه تمامی مطالب را خواستین بگین تا بزارم . با تشکر مدیریت 

مقایسه SQL server 2000 و Oracel 9i

در این قسمت به مقایسه دو پایگاه داده SQL server 2000 و Oracel 9i از نظر قیمت ، اجرا ، پشتیبانی توسط سیستمها می پردازیم .

1)    مقایسه از نظر پشتیبانی توسط سیستمهای عامل : SQL server 2000 فقط بر روی سیستم عاملهای ویندوز شامل  Windows 9x, Windows NT, Windows 2000  و Windows CE اجرا می شوند . در مقابل SQL server 2000 پایگاه داده Oracel 9i بر روی تمامی سیستم های عامل که شامل Windows-based platforms, AIX-Based Systems, Compaq Tru64 UNIX, HP 9000 Series HP-UX, Linux Intel, Sun Solaris  و so اجرا می شوند .

2)    سخت افزار مورد نیاز : برای نصب SQL server 2000 شما باید پردازنده Intel یا سازگار با آن و همچنین سخت افزارهای زیر را داشته باشید .

Hardware	Requirements
Processor	Pentium 166 MHz or higher
Memory	32 MB RAM (minimum for Desktop Engine), 64 MB RAM (minimum for all other editions), 128 MB RAM or more recommended
Hard disk space	270 MB (full installation), 250 MB (typical), 95 MB (minimum), Desktop Engine: 44 MB Analysis Services: 50 MB minimum and 130 MB typical English Query: 80 MB

    Oracel 9i از پردازنده های اینتل و پردازنده های سازگار با Windows-based platforms, AIX-Based Systems, Compaq Tru64 UNIX, HP 9000 Series HP-UX, Linux Intel, Sun Solaris  و so پشتیبانی می کند.

برای نصب اراکل بر روی پردازنده های اینتل و سازگار با آن به سخت افزارهای زیر نیاز است .

Hardware	Requirements
Processor	Pentium 166 MHz or higher
Memory	RAM: 128 MB (256 MB recommended) Virtual Memory: Initial Size 200 MB, Maximum Size 400 MB
Hard disk space	140 MB on the System Drive plus 4.5 GB for the Oracle Home Drive (FAT) or 2.8 GB for the Oracle Home Drive (NTFS)

برای نصب اراکل بر روی پردازنده های زیر سیستم Unix ازقبیل Windows-based platforms, AIX-Based Systems, Compaq Tru64 UNIX, HP 9000 Series HP-UX, Linux Intel, Sun Solaris  و so به سخت افزارهای زیر نیاز است .

Hardware	Requirements
Memory	A minimum of 512 MB RAM
Swap Space	A minimum of 2 x RAM or 400 MB, whichever is greater
Hard disk space	4.5 GB

منبع :

http://www.technology-updates.com/

درس اول ( سناریو )

تهیه سناریو اولین قدمی است که برای انجام تجزیه و تحلیل سیستم برداشته می شود . در سناریو ما شمای کلی سیستم و نحوه کار را توضیح می دهیم 

دوستان عزیز این سناریو از مجموعه دروس آموزش رشنال روز می باشد که در آن به این نکته اشاره شده که یک سناریو دارای چه بخشهایی باید باشد

Precondition : ( شرایطی که باید ایجاد شود تا Use case فعال شود )

هنگامی که پرسنل جهت مراجعه یا ترک محل کار ورود و خروج می نمایند .

Postcondition : ( شرایطی که بعد از اتمام کار Use case ایجاد می شود )

باید میزان حضور پرسنل در محل کار محاسبه شود .

Goal : ( هدف )

محاسبه میزان عملکرد پرسنل در شرکت پاسارگاد .

Description : ( شرح مختصری از فعالیتهای سیستم )

پرسنل جهت محاسبه میزان عملکرد ، ساعت ورود و خروج خود را ثبت می کنند تا بر اساس آن حقوق و مزایا دریافت کنند .

Main Flow : ( جریان اصلی کار Use case )

1)     پرسنل هنگام مراجعه به محل کار کد پرسنلی خود را در اختیار مسئول قسمت اداری قرار می دهند .

2)     مسئول قسمت اداری به منوی برنامه رفته و ورود پرسنل مورد نظر را ثبت می کند .

3)     پرسنل هنگام ترک محل کار کد پرسنلی خود را دوباره در اختیار مسئول قسمت اداری قرار می دهند .

4)     مسئول قسمت اداری به منوی برنامه رفته و با ورود کد پرسنلی مشخصات + ساعت ورود پرسنل مورد نظر را مشاهده می کنند .

5)     مسئول قسمت اداری ساعت خروج را ثبت و سیستم میزان عملکرد پرسنل در آن روز را محاسبه می نماید .

Altrnative Flow : ( جریان فرعی کار Use case )

1)     امکان دارد پرسنل در یک روز مرخصی ساعتی یا در ماموریت باشد آنگاه دیر تر در محل کار حاضر شود یا اینکه زودتر محل کار را ترک کند

2)     امکان دارد پرسنل در یک روز مرخصی یا در ماموریت روزانه بوده و آن روز به محل کار مراجعه نکند .

فایل PDF در تاریخ 1390/03/14 دوباره آپلود شده

  درس اولpdf فایل

زبان مدلسازی یکنواخت (بخش دوم)

نمودارهای UML :

در این بخش به معرفی نمودارهای UML می‌پردازیم وعلاقمندان به آشنایی بیشتر را، دعوت به مطالعه مراجع معرفی شده، می‌نماییم:

نمودار کلاس (Class Diagram):

این نمودار،کلاسها، واسطها و همکاری و روابط بین آنها را نمایش می‌دهد. و نمودار اصلی و مرکزی UML می‌باشد. که بیان‌کننده ساختار ایستای سیستم نرم‌افزاری می‌باشد.

نمودار اشیاء (Object Diagram):

این نمودار، اشیاء سیستم و روابط بین آنها را نمایش می‌دهد. در واقع یک تصویر لحظه‌ای از نمودار کلاس می‌باشد.

نمودار موردکاربرد (Usercase Diagram):

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

نمودارهای تعامل (Interaction Diagram):

این نمودارها، بیان کننده تعامل هستند که شامل اشیاء مختلف و روابط بین آنها و همچنین پیغامهایی که بینشان رد و بدل می‌شود می‌باشند. این نمودارها جنبه‌های پویای یک سیستم را مدل می‌کنند و خود بر دو نوعند: نمودار توالی(Sequence Diagram) که ترتیب زمانی تعامل‌ها را نشان می‌دهد و نمودار همکاری(Collaboration Diagram) که تاکید بر نمایش ساختاری تعامل‌ها دارد.

نمودارحالت (Statechart Diagram):

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

نمودار فعالیت(Activity Diagram):

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

نمودار اجزاء(Component Diagram):

از جمله نمودارهای پیاده‌سازی می‌باشد و سازماندهی و روابط بین مجموعه‌ای از اجزاء را نمایش می‌دهد. این نمودار، جنبه های ایستای پیاده‌سازی یک سیستم را مدل می‌کند.

نمودار به‌کارگماری(Deployment Diagram):

پیکربندی گره‌های پردازشی زمان اجرا را نمایش می‌دهد. که برای مدل کردن جنبه‌های ایستای به‌کار‌گماری یک معماری بکار می‌رود. همچنین نمایش‌دهندة اجزای استفاده‌شده زمان اجرا مثل کتابخانه‌های DLL، فایل‌های اجرایی، کدهای مبدا و روابط بین آنها می‌باشد.

البته این نمودارها تمام نمودارهای UML نیستند بلکه بسته به نیاز و با کمک ابزارهای Case میتوان نمودارهای دیگری نیز تعریف و استفاده کرد.

روند حرکت به سمت UML در جهان:

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

OMG که کنسرسیومی است متشکل از 700 شرکت معتبر آمریکا، از UML حمایت کرد و آن را به عنوان زبان مدلسازی استاندارد خود اعلام کرد. البته علاوه بر استاندارد شدن، حمایت جداگانه شرکت‌های بزرگ دنیا مثل Hewlett-Packard، I-Logix، Microsoft، IBM، Oracle و بسیاری دیگر، خود سبب افزایش کاربرد آن در محافل صنعتی و نرم‌افزاری دنیا گردید. امروزه نیز با ارائه نسخه 1.3 و رفع مشکلات گذشته، روز به روز بر کاربران آن افزوده می‌شود.

روند حرکت به سمت UML در ایران:

در ایران حرکت برخی شرکتها به سمت UML سریعتر انجام شد؛ بطوریکه در همان زمان استاندارد شدن UML در سال 1997، شرکتهایی در ایران، این ابزار را به عنوان استاندارد خود پذیرفتند و از آن در تولید محصولات خود استفاده کردند.

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

با توجه به روند حرکت شتابان به سمت UML در دنیا و با توجه به اهمیت استانداردسازی برای صنعت نرم‌افزار کشور، حرکت هرچه‌سریعتر به سوی این فناوری در کشور توصیه می‌شود.

اهمیت ترویج UML در کشور:

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

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

زبان مدلسازی یکنواخت

زبان مدلسازی یکنواخت:

زبان مدلسازی یکنواخت یا Unified Modeling Language (UML)، یک زبان مدلسازی است که برای تحلیل وطراحی سیستمهای شی‌گرا بکار می‌رود. UML اولین بار توسط شرکت Rational ارائه شد و پس از آن از طرف بسیاری از شرکت‌های کامپیوتری و مجامع صنعتی و نرم‌افزاری دنیا مورد حمایت قرار گرفت؛ به طوریکه تنها پس از یک سال، توسط گروه Object Management Group، به عنوان زبان مدلسازی استاندارد پذیرفته شد. UML تواناییها و خصوصیات بارز فراوانی دارد که می‌تواند به طور گسترده‌ای در تولید نرم‌افزار استفاده گردد. در ادامة این مقاله ابتدا به تاریخچة UML و در ادامه به معرفی، ویژگیها و نمودارهای آن پرداخته می‌شود و در پایان، روند حرکت به سمت UML و اهمیت آن برای ایران، بررسی خواهد شد.

تاریخچة UML :

دیدگاه شی‌گرایی (Object Oriented) از اواسط دهه 1970 تا اواخر دهه 1980 در حال مطرح شدن بود. در این دوران تلاشهای زیادی برای ایجاد روشهای تحلیل و طراحی شی‌گرا صورت پذیرفت. در نتیجة این تلاشها بود که در طول 5 سال یعنی 1989 تا 1994، تعداد متدولوژیهای شی‌گرا از کمتر از 10 متدولوژی به بیش از 50 متدولوژی رسید. تکثر متدولوژیها و زبانهای شی‌گرایی و رقابت بین اینها به حدی بود که این دوران به عنوان "جنگ متدولوژیها" لقب گرفت. از جمله متدولوژیهای پرکاربرد آن زمان می‌توان از Booch، OOSE، OMT، Fusion، Coad-Yourdan، Shlayer-Mellor وغیره نام برد. فراوانی و اشباع متدولوژیها و روشهای شی‌گرایی و نیز نبودن یک زبان مدلسازی استاندارد، باعث مشکلات فراوانی شده بود. از یک طرف کاربران از متدولوژیهای موجود خسته شده بودند، زیرا مجبور بودند از میان روشهای مختلف شبیه به هم که تفاوت کمی در قدرت و قابلیت داشتند یکی را انتخاب کنند. بسیاری از این روشها، مفاهیم مشترک شی‌گرایی را در قالبهای مختلف بیان می‌کردند که این واگرایی و نبودن توافق میان این زبانها، کاربران تازه‌کار را از دنیای شی‌گرایی زده می‌کرد و آنها را از این حیطه دور می‌ساخت. عدم وجود یک زبان استاندارد، برای فروشندگان محصولات نرم‌افزاری نیز مشکلات زیادی ایجاد کرده بود.

اولین تلاشهای استانداردسازی از اکتبر 1994 آغاز شد، زمانی که آقای Rumbaurgh صاحب متدولوژی OMT به آقای Booch در شرکت Rational پیوست و این دو با ترکیب متدولوژیهای خود، اولین محصول ترکیبی خود به نام "روش یکنواخت" را ارائه دادند. در سال 1995 بود که با اضافه شدن آقای Jacobson به این دو، روش یکنواخت ارائه شده با روش OOSE نیز ترکیب شد واین خود سبب ارائة UML نسخة 0.9 در سال 1996 گردید. سپس این محصول به شرکتهای مختلفی در سراسر جهان به صورت رایگان ارائه شد و استقبال شدید شرکت‌ها از این محصول و تبلیغات گسترده شرکت Rational، سبب آن شد که گروه OMG، نسخة 1.0 UML را به عنوان زبان مدلسازی استاندارد خود بپذیرد. تلاشهای تکمیلی UML استاندارد ادامه پیدا کرد و نسخة 1.1 آن در سال 1997 و نسخه 1.3 آن در سال 1999 ارائه گردید.

UML چیست؟

UML یا زبان مدلسازی یکنواخت، زبانی است برای مشخص کردن (Specify)، مصورسازی (Visualize)، ساخت (Construction) و مستندسازی (Documenting) سیستمهای نرم‌افزاری و غیر نرم‌افزاری و نیز برای مدلسازی سیستمهای تجاری. اما چرا مدل و مدلسازی؟

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

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

فرهنگ واژگان و قواعد زبانی مثل UML به شما می‌گویند که چگونه یک مدل را بسازید و یا چگونه یک مدل را بخوانید. اما به شما نمی‌گویند که در چه زمانی، چه مدلی را ایجاد کنید. یعنی UML فقط یک زبان نمادگذاری (Notation) است نه یک متدولوژی. یک زبان نمادگذاری شامل نحوة ایجاد و نحوة خواندن یک مدل می‌باشد، اما یک متدولوژی بیان می‌کند که چه محصولاتی باید در چه زمانی تولید شوند و چه کارهایی با چه ترتیبی توسط چه کسانی، با چه هزینه‌ای، در چه مدتی و با چه ریسکی انجام شوند.

ویژگیهای UML :

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

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

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

مساله دیگر اینکه، UML یک زبان برنامه‌نویسی بصری (visual) نیست، اما مدلهای آن را می‌توان مستقیماً به انواع زبانهای مختلف ارتباط داد. یعنی امکان نگاشت از مدلهای UML به کد زبانهای برنامه‌نویسی مثل Java و VC++ وجود دارد که به این عمل "مهندسی روبه‌جلو" می‌گویند. عکس این عمل نیز ممکن است؛ یعنی این امکان وجود دارد که شما بتوانید از کد یک برنامه زبانی شی‌گرا، مدلهای UML معادل آن را بدست آورید. به این عمل "مهندسی معکوس" می‌گویند. مهندسی روبه‌جلو و معکوس از مهمترین قابلیتهای UML به شمار می‌روند، البته نیاز به ابزار Case مناسبی دارید که از این مفاهیم پشتیبانی‌کنند.

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

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

از دیگر ویژگیهای UML می‌توان به پشتیبانی از مفاهیم سطح بالای شی‌گرایی مثل Collaboration، Framework، Pattern و Component اشاره کرد. همچنین UML با استفاده از یک سری مکانیزمهای گسترش‌پذیر امکان می‌دهد که بتوان زبانهای مدلسازی جدیدتری (با گسترش مفاهیم پایه‌ای موجود) ایجادکرد.

دوره آموزش Rational Ros

دوست عزیز انشا الله به زودی یک دوره آموزش کامل نرم افزار Rational Ros را برای شما و دیگر علاقمندان بر روی وبلاگ قرار می دهم امیدوارم که با نظرات خود من را در این زمینه یاری فرمائید.

مدیریت

کمک در انجام پروژهای دانشجویی

درورد بر دوستان

مدیریت این سایت آماده است شما را در انجام پروژه های دانشجویی یاری نماید. لذا جهت ارتباط با ما از طریق ایمیل زیر تماس حاصل فرمایئد .

mailto:[e-mail]

مهندسی نرم افزار در سیستمهای متن باز (بخش دوم)

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"هایی که همراه با برنامه بیرون داده شده‌است رجوع می‌کنند. افراد غیربرنامه‌نویس به خودآموزهای چاپ‌شده‌ای که همراه با نرم‌افزار بیرون داده می‌شود رجوع خواهند کرد. افراد غیر‌برنامه‌نویس هیچ‌گاه یک کتاب راجع به یک برنامه کاربردی نمی‌خرند زیرا معتقدند که کتابهای فنی مختص برنامه‌نویسان است. · ساده افراد غیربرنامه‌نویس به هیچ‌وجه راجع به جزییات توضیح نمی‌خواهند. آنها به جوابهای ساده احتیاج دارند. این افراد از وارد شدن به جزییات بیزارند؛ دستورالعمل‌های کوتاه و باقاعده را دوست دارند؛ به اطلاعاتی علاقه دارند که جواب این سوال است: "چگونه من می‌توانم فلان کار را انجام دهم"(که فلان کار یک قابلیتی است که برنامه در اختیار شما قرار می‌دهد) و اینکه افراد غیربرنامه‌نویس نمی‌خواهند اطلاعاتی راجع به اینکه قابلیت‌های سیستم چگونه پیاده‌سازی شده‌اند مشاهده کنند. · کامل، درست و به‌روز فرض افراد غیربرنامه‌نویس این است که کمک برخط در هر نسخه جدید برنامه به‌روز می‌شود. اگر قسمتی از کمک برخط وجود نداشته باشد و یا کهنه و از کارافتاده باشد این افراد دیگر از آن استفاده نخواهند کرد. اگر این فرد نتواند جواب یک سوال را در کمک برخط پیدا کند یا با پشتیبان فنی تماس خواهد گرفت و یا از یک برنامه‌کاربردی دیگر استفاده خواهد کرد. نوشتن مستندات می‌تواند یک مدل برای تجارت باشد. بسیاری از پروژه‌های متن‌باز از طریق فروختن مستندات، خود را تامین مالی می‌کنند. این مساله شاید کمی ریاکارانه و متناقض به نظر برسد، فروختن چیزی که به محصولات متن‌باز وابسته است و شما با استفاده از آن می‌توانید محصولات متن‌باز دیگری تولید کنید، ولی به هرحال این کار انجام می‌شود. علاوه براین لیسانس‌های خاص دیگری نیز وجود دارند که سوراخ مابین استفاده اقتصادی و به طور مجانی در اختیار گذاشتن اطلاعات را پر می‌کنند.

مهندسی نرم افزار در سیستمهای متن باز

مهندسی نرم‌افزار در سیستم‌های متن‌باز (قسمت اول)

1 مقدمه

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

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

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

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

2 فرایندهای مهندسی نرم‌افزار در نرم‌افزارهای متن‌باز

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

2.1 مهندسی نرم‌افزار و فرایندهای آن

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

مهندسی نرم‌افزار عبارت است از وضع اصول مهندسی بجا و مناسب و استفاده از آنها برای بدست آوردن یک نرم‌افزار مقرون به صرفه که قابل اطمینان بوده و روی ماشینهای واقعی به طرزی کارآمد عمل کند.

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

2.1.1 جمع‌آوری نیازمندیها

اولین قدم در فرایند مهندسی نرم‌افزار تولید یک مستند کاری است. در این مستند دلایلی که باعث شده است نیاز به این محصول حس شود و لیستی از قابلیتهای محصول که این نیازها را رفع می‌کند شرح داده شده است. کلیت مستند در حقیقت جواب به این سوال است که: چرا باید بسازیم و چه کسی از آن استفاده خواهد کرد؟.

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

2.1.2 طراحی در سطح سیستم

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

2.1.3 طراحی جزییات

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

2.1.4 پیاده سازی

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

2.1.5 یکپارچه سازی

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

2.1.6 آزمون

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

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

2.1.7 پشتیبانی و نگهداری

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

2.2 فرایند تولید نرم‌افزار متن‌باز

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

2.2.1 فرایند تولید نرم‌افزار متن‌باز بدون حمایت مالی

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

2.2.1.1 جمع‌آوری نیازمندیها

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

2.2.1.2 طراحی در سطح سیستم

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

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

2.2.1.3 طراحی جزییات

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

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

تنها کاری که در این مرحله انجام می‌شود مستندسازی واسطهای برنامه‌نویسی برنامه کاربردی در قالب یک خودآموز است که معمولا در قالب manualهای موجود در لینوکس می‌باشد.

2.2.1.4 پیاده‌سازی

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

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

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

2.2.1.5 آزمون

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

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

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

2.2.1.6 پشتیبانی و نگهداری

“وای ببخشید‿ جمله‌ای است که هنگام گزارش یک ایراد از جانب کاربر شنیده می‌شود. “وای ببخشید و متشکرم‿ جمله‌ای است که اگر علاوه بر گزارش ایراد, اصلاح‌کننده ایراد نیز فرستاده شده باشد شنیده می‌شود. وجود نداشتن پشتیبانی و نگهداری باعث می‌شود که تعدادی از کاربران از استفاده از نرم‌افزارهای متن‌باز بدون حمایت مالی صرف نظر کنند. اما باز این امکان وجود دارد که گروهی پشتیبانی نرم‌افزار را بر عهده بگیرند و کاربر با مبلغی بتواند از پشتیبانی آنها استفاده کند و یا اینکه نسخه‌های تجاری یک نرم‌افزار متن‌باز بیرون داده شوند و کاربر از آنها استفاده کند.

2.2.2 فرایند تولید نرم‌افزار متن‌باز تجاری

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

3 نگاه عمیق‌تر به فرایند تولید نرم‌افزار متن‌باز

3.1 نمونه‌سازی[1]

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

"ما هرگز از روش XP استفاده نمی‌کنیم. کلمه XP زمانی که ما پروژه را شروع کردیم، وجود نداشت. ما بعدها در پروژه‌مان از روش XP استفاده کردیم. XP روش خوبی برای پروژه های نرم‌افزار است اگر:

· پروژه بزرگ نباشد.
· یک یا چند عضو اساسی در تیم وجود داشته باشند.
· چند همکار و کمک کننده در پروژه وجود داشته باشد.
· پروژه برای سود نباشد.
· پروژه برای مشتری خاصی نباشد."

دیگران، مانند Linus Trovalds، نگاه ریشه‌ای به قضییه دارند؛ به این شکل که "هیچ کس به اندازۀ من Linux را "طراحی" نکرد، و من شک دارم که بسیاری با من مخالف باشند. Linux رشد کرد؛ با بسیاری از تغییرات رشد کرد، و به خاطر اینکه تغییرات کمتر از اتفاقات بودند، تغییرات سریعتر و جهت‌دار تر از ذرات اولیه DNA بودند."

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

3.2 مدیریت نسخه‌ها

مدیریت نسخه‌ها که مدیریت پیکربندی نیز گفته می‌شود تمامی تغییرات داده‌شده به داده‌های پروژه را ضبط می‌کند و البته این قابلیت را دارد که نرم‌افزار را در هر لحظه که اراده کنید به حالت پیشین خود بازگرداند.

مدیریت نسخه‌ها در پروژه‌های نرم‌افزاری استفاده بسیار زیادی دارد که بعضی از آنها عبارتند از:

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

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

(ادامه دارد...)

منبع : FOSS_ir  11طرح ملی نرم‌افزارهای آزاد-متن‌باز ایران.htm 

متدلوژی SSADM (بخش دوم)

انتخاب راه حل :

هدف ، انتخاب بهترین راه حل کامپیوتری برای برآورده کردن نیازمندیهای کاربر است .

شرح نیازمندیها :

در این مرحله حاصل از مرحله شناخت ، در قالب مدلهای تحلیل و طراحی به صورت دقیق و خلاصه توسط مهندس نرم افزار مشخص میشود .

طراحی منطقی :

 هدف از طراحی منطقی تعیین منطق عملیات سیستم مکانیزه بادر نظر کرفتن نیازهای کاربر است .

 طراحی فیزیکی :

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

طراحی فیزیکی داده ها :

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

 طراحی رابط داده :

چنانچه دیدگاهی که از داده ها و اطلاعات ذخیره شده وجود دارد متفاوت از واقعیت فیزیکی داه ها باشد باید رابطی جهت تبدیل داده ها ایجاد شود .

 طراحی پردازه های فیزیکی :  

هدف ، تبدیل طرح منطقی پردازه ها به مدل فیزیکی عملیات در سیستم جدید مکانیزه است .

       پنج مرحله اصلی تحلیل و طراحی  سیستم عبارتند از :

طراحی فیزیکی

طراحی منطقی

شرح نیاز

تحلیل نیاز

امکان سنجی

متدولوژی SSADM(بخش اول)

متدولوژی SSADM

SSADM یکی از متدولوژی های شناخته شده تولید سیستم های مکانیزه است .

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

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

الف-تعیین عملکرد کلی : ابتدا محیط عملیاتی سیستم مشخص میشود 

ب- تعیین شبکه عملیات داخلی : برای تعیین عملکرد داخلی ، معمولا هر سیستم را در قالب شبکه ای از زیر سیستم ها و واحدهای عملیاتی مشخص و سپس برای هر واحد عملیاتی خروجی ها را تعیین میکنند ارتباط بین عناصر در شبکه عملیاتی سیستم ها را در قالب دیاگرامی به نام دیاگرام گردش دادها میتوان مشخص نمود .

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

د- یافتن منشاءمشکلات:با تعیین کمبود در خروجی حاصل از عملکرد یک واحد ، مسلما علت یا در عملکرد آن واحد است و یا اینکه اطلاعات به اندازه کافی به موقع به آن واحد نمی رسد .

 ارئه راه حل : مسلما یک مهندس نرم افزار در حدی نیست که بتوتند برای حل مسائل هر سیستمی راه حل پیشنهاد نماید اما با دانشی که از سیستمهای اطلاعاتی وامکانات سخت افزاری و نرم افزاری دارد ، میتواند در موارد زیر با مدیران ومسئولان جهت تعیین راه حلی برای مشکلات مشخص شده مشاوره کند :

- ایجاد یک شبکه اطلاع رسانی کامپیوتری برای تهیه اطلاعات مورد نیاز .

- ایجاد یک سیستم اطلاعات مدیریت جهت تهیه گزارشات مورد نیاز .

- ایجاد یک سیستم مکانیزه برای پشتیبانی در تصمیم گیریها .

- ایجاد یک سیستم مکانیزه مبتنی بر پایگاه دانش به عنوان مشاور در امور .

- ایجاد یک سیستم مکانیزه خبره که بتواند مانند یک متخصص در زمینه خاص عمل نماید .

، تحلیل نیازمندیها در سه مرحله انجام می شود. مرحله اول شامل شناخت  SSADMاز دیگاه

سیستم موجود ، مسائل ، مشکلات و نیازمندیهای کاربر است . در مرحله دوم راه حل ممکن مشخص می شود و با لاخره در مرحله سوم شرح نیازمندیها تهیه و به عنوان گزارش مرحله تحلیل نیازمندیها به مسئولان جهت تصمیم گیری و انتخاب راه حل بهینه ، ارئه میشود .

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

 تعیین چهار چوب عملیات شناخت (1

 شناخت سیستم موجود (2

3) تعیین مشکلات و نیازها

4) تعیین منطق عملیات

5) تهیه گزارش شناخت