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

هدف ما از این نوشته‌علمی و سلسله مقاله‌ها بعدی درباره ی با مهندسی نرم افزار که در بعدی به آن‌ها خواهیم پرداخت. مشاجره پیرامون ارائه یک چارچوبی می‌باشد که سازندگان نرم افزارهای کامپیوتری بتوانند از آن برای ساخت نرم افزارهای خود به کارگیری کنند. این چارچوب مشمول یک فرایند، مهندسی نرم افزار گروه ای از روش ها و آرایه ای از ابزارها می‌گردد که آن‌ها را مهندسی اپ می نامند. منبع اصلی ما در این مقالات ویراست هفتم کتاب مهندسی نرم افزار تایپ کردن راجر اس پرسمن (Rojer S .Pressman) میباشد.
اپ
بحث را با تعریف نرم‌افزار و برشمردن خصوصیات آن آغاز میکنیم. پرسمن در کتاب خود نرم‌افزار را به گونه پایین تعریف‌و‌تمجید می کند:
اپ عبارت هست از: (۱) دستور کار هایی که هنگام اعمال، ویژگی، همت و سعی مطلوب را آماده میسازند؛ (۲) ساختمان داده هایی که اپلیکیشن ها را کارکشته به پردازش مناسب داده ها کنند و (۳) اطلاعات توصیفی در هر دو قالب اسکن دشوار و مجازی که راه اندازی و استفاده از برنامه ها را شرح دهند.
از‌آن‌جا‌که برنامه، یک عنصر منطقی است تا یک عنصر فیزیکی، دارای ویژگی هایی هست که تفاوت زیادی با سخت افزار داراست:
اپ، مهندسی و توسعه و گسترش داده می‌شود و چیزی نیست که به معنای کلاسیک واژه و کلمه، ساخته خواهد شد.
نرم افزار فرسوده نمی‌شود.
شکل ۱-۱ نمودار نوا شکست را به صورت تابعی از زمان برای سخت افزار نماد میدهد. این رابطه که اکثر وقت ها منحنی وانی نامیده میشود، علامت می‌دهد که سخت افزار در اولیهِ عمر خود آهنگ ناکامی نسبتاً شدیدی دارااست (این ناکامی را غالباً می توان به عیوب طراحی و ایجاد نسبت داد)، این عیوب تصحیح می‌شوند و آهنگ باخت برای یک فرصت زمانی به مقداری ثابت نزول می کند. با گذشت زمان، سخت افزار شروع به فرسایش کرده و دوباره نوا باخت شدت می گیرد.
شکل ۱-۱
نرم افزار نسبت به ناملایمات محیطی که منجر فرسایش آن میشود، نفوذ پذیر نیست. براین اساس، در تئوری، منحنی شکست برای برنامه بایستی شکل منحنی ایده آل شکل ۲-۱ را به خود بگیرد. عیوب کشف نشده باعث آهنگ شکست شدید، در نخستینِ عمر نرم افزار می شود، البته این عیوب برطرف می‌شوند و منحنی به طوری که علامت داده گردیده‌است، هموار می‌گردد. منحنی ایده آل نسبت به منحنی حقیقی وواقعی مدل های ناکامی نرم افزار بسیار بی آلایش تر است. البته معنای آن بسیار اشکار است، نرم افزار هیچوقت دچار فرسایش نمیشود بلکه زوال مییابد.
شکل ۲-۱
این تناقض ظاهری را می قدرت با در نظر گرفتن (منحنی حقیقی وواقعی) به بهترین وجه توضیح بخشید. برنامه در روزگار حیات خود دستخوش تغییر‌و تحول می شود(حفظ). با انجام این تغییرات، احتمال داراست که بعضا عیوب نو وارد شوند و باعث خیز منحنی آهنگ شکست شوند. پیش از آنکه منحنی بتواند به آوا باخت منظم اول خود برسد، تغییر تحول دیگری درخواست می گردد که باعث خیز دوباره منحنی میشود. دست‌کم معیار باخت به آهستگی ارتقاء مییابد- نرم افزار در اثر تغییر و تحول فاسد می گردد.
گر چه صنعت در درحال حاضر حرکت به سوی مونتاژ قطعات هست، اکثر نرم افزارها همچنان به صورت سفارشی ساخته می‌شوند. در جهان سخت افزار، به کار گیری مجدد از قطعات، بخشی از فرایند مهندسی هست. در مهندسی اپلیکیشن این فرمان اخیرا مورد توجه قرار گرفته می باشد. در واقع یک مولفه نرم افزاری می بایست چنان طراحی و پیاده سازی شود که بتوان در اپلیکیشن های گوناگون از آن استفاده کرد.

برای مهندسی نرم افزار تعارف متفاوتی ارائه شد‌ه‌است، IEEE مهندسی اپلیکیشن را اینگونه شرح می دهد: کاربرد یک روش سیستماتیک، علمی و کمیت پذیر در بسط، فعال سازی و حفظ برنامه، یعنی به کارگیری از مهندسی نرم افزار.
مهندسی نرم افزار یک رشته آوری لایه ای هست. با تمرکز به طور ۳-۱، هر طرز مهندسی (برای مثال مهندسی نرم افزار) می بایست متکی به تعهد سازمانی به کیفیت باشد. در واقع سنگ بنای نگهدارنده مهندسی نرم افزار، اعتنا به کیفیت است.
شکل ۳-۱
بنیاد مهندسی نرم‌افزار، لایه فرایند می باشد. روند چارچوبی را تعریف و تمجید می کند که بایستی برای تحویل موثر فناوری مهندسی نرم افزار وضع و اوضاع خواهد شد. فرایند اپلیکیشن، اساس ای برای کنترل مدیریتی پروژه های نرم افزاری تشکیل داده، بستری برای جاری ساختن طرز های فنی، تشکیل داد تولیدها کاری (مدل ها، مستندات، داده ها، گزارشات، فرم ها و غیره)، گزینش روند، دستیابی اعتقاد از کیفیت و رئیس مناسب تغییرات ساخت‌و‌ساز می کند.
شیوه های مهندسی اپلیکیشن، راه‌های فنی برای ساخت نرم افزار را مهیا می آورند. این شیوه ها دربرگیرنده آرایه وسیعی از وظایف به عنوان مثال: محاسبه آمال، طراحی، ساخت برنامه ها، آزمایش و هواخواهی میشود.
ابزارهای مهندسی نرم افزار، متضمن امان اتومات یا نیمه اتومات برای پروسه و نحوه هایی می باشند. هنگامی که ابزارها گرد هم آیند به طوری که اطلاعات تشکیل داد شده توسط یک ابزار، توسط ابزارهای دیگر قابل استعمال باشند، سیستمی برای پناه اپ شکل می گیرد که مهندسی برنامه به امداد کامپیوتر (Computer Aided Software Engineering ) نام دارد.
فرآیند مهندسی اپلیکیشن
چارچوب پروسه با گزینش تعداد کوچکی از شغل های چارچوبی که برای کلیه پروژه های نرم افزاری قابل استعمال باشند، صرف نظر از اندازه و پیچیدگی آنها، مبنا ای برای یک فرآیند مهندسی اپ بدون نقص پی ریزی می کند. یک چارچوب مراحل کلی برای مهندسی نرم افزار مشتمل بر پنج عمل می‌گردد.
ارتباطات(Communication): پیش از اینکه هرگونه کار فنی شروع خواهد شد، برقراری ارتباط و همکاری با مشتری بسیار اساسی است. مقصود، شعور اهداف طرف های ذی نفع برای پروژه و توده مراد هایی می‌باشد که می توانند خصوصیات و قابلیت های عملیاتی نرم افزار را تعیین کنند.
برنامه ریزی(Planning): یک پروژه نرم افزاری، سفری بغرنج می‌باشد و شغل طراحی برنامه، نقشه ای ساخت‌و‌ساز می کند که به موعظه تیم در انجام این مهاجرت کمک می کند. این نقشه با تمجید وظایف فنی که قرار می‌باشد انجام شوند، مخاطرات احتمالی، منابعی که لازم خواهند بود، محصولات کاری ای که باید تولید شوند و زمانبندی کاری، مهندسی اپلیکیشن را مشخص و معلوم می کند.
مدل سازی(Modeling): یک معمار، هر روز با مدل ها کار می کند، اِتودی میزند تا تصویر بزرگ را ادراک کند، اینکه از حیث معماری چه ظاهری دارد، بخش های خالق اش چه گونه با هم جور در خواهند آمد، و بخش اعظمی خصوصیات دیگر. مهندسی اپلیکیشن با ایجاد کرد مدل هایی جهت درک بهتر خواسته ها و طراحی که به‌این خواسته ها برسد، همین عمل را می کند.
ساخت(Construction): این کار، تولید کدها و آزمون ما یحتاج برای آشکار کردن خطاهای مو جود در کدها را با هم تلفیق می کند.
استقرار(Deployment): نرم افزار به مشتری تحویل داده می گردد تا محصول تحویل داده شده را محاسبه کرده و بر طبق این پژوهش، بازخوردی ارائه دهد.
برای بخش اعظمی از پروژه های نرم افزاری، شغل های چارچوبی به موازات گسترش پروژه به صورت تکراری به شغل برده میشوند. در هر دور از تکرار پروژه، یک نسخه از نرم افزار ساخت می‌گردد که ذیل دسته ای از قابلیت های عملیاتی و ویژگی های برنامه کامل را در اختیار افراد ذی نفع قرار می دهد. با ساخت هر نمو، برنامه بی نقص و کامل تر می‌شود.
فعالیت های چارچوبی فرایند مهندسی اپلیکیشن توسط تعدادی از فعالیت های چتری تکمیل میشوند که عبارتند از:
در اختیار گرفتن و پیگیری پروژه های نرم افزاری: به تیم نرم افزاری قابلیت می‌دهد تا توسعه را در مقایسه با نقشه پروژه بسنجد و هر گونه کنش موردنیاز را برای حفظ مجال بندی به عمل آورد.
مدیریت ریسک: خطراتی را آنالیز می کند که ممکن می باشد بر سود پروژه یا کیفیت مال تاثیر بگذارند.
تضمین کیفیت نرم افزار: کارهای مورد نیاز برای استحصال باور از کیفیت نرم افزار را معین می کند.
بازبینی فنی: محصولات کاری مهندسی اپ را در همت برای آشکار کردن مشکلات قبل از انتشار آنها در عمل بعدی و برطرف کردن آن ها پژوهش می کند.
اندازه گیری: موازینی از فرایند، پروژه و مال را تمجید می کند که نیازهای طرف های ذی نفع را برطرف می‌سازند.
مدیریت پیکربندی اپلیکیشن: اثرات تغییرات را در سراسر فرآیند نرم افزار مدیر می کند.
مدیریت امکان استعمال مجدد: ملاک های مربوط به استفاده مجدد (برای مثال قطعات نرم افزاری) را تعریف‌و‌تمجید می کند و سازوکارهایی برای حصول به قطعات قابل استعمال مجدد برقرار می سازد.
تهیه و ساخت مال کاری: دربرگیرنده کارهای مورد نیاز برای ساخت‌و‌ساز محصول ها کاری از قبیل مدل ها، مستندات، وقایع نگارها(کارنامه ها)، فرم ها و فهرست ها میشود.
توجه به‌این نکته ضروری هست که فرایند مهندسی نرم افزار یک راهبرد نهایی و غیر قابل تغییر نیست که مجموعه نرم افزاری می بایست با تعصب از آن پیروی کند بلکه بایستی سریع الانتقال و انطباق پذیر باشد(برای مساله، برای پروژه، برای دسته و برای فرهنگ سازمانی). براین اساس فرایندی که برای یک پروژه پذیرفته می شود، ممکن می باشد با مراحل پذیرفته شده برای پروژه های دیگر تفاوتی چشمگیر داشته باشد. در مقاله‌ها بعدی مدل های مختلف فرایندها را شرح خواهیم بخشید.
مهندسی برنامه در کار
جورج پولیا در یک کتاب کلاسیک با عنوان (چگونگی حل مساله) که قبل از وجود کامپیوترهای مدرن نوشته شده هست، جوهر حل مساله و در منفعت (جوهر کار) در مهندسی برنامه را چنین مطرح می کند:
شناخت مساله (برقراری ارتباط و بررسی)
طرح ریزی برای یک حل (مدل سازی و طراحی نرم افزار)
اجرای برنامه ریزی (تولید کد)
بررسی سود برای درستی (آزمایش و تضمیین کیفیت)
اصول کلییوید هوکر هفت اصل را مطرح نموده است که توجه به آن ها در مهندسی نرم افزار بسیار ضروری به لحاظ می رسد:
اصل یکم) برهان وجود سیستم: هر سیستم به یک وجود نیاز دارااست: این که برای کاربرانش بها آماده سازد. همه تصمیم گیری ها می بایست با مد نظر داشتن این نکته صورت بپذیرد.
اصل دوم) ساده نگه داشتن: کلیه طراحی ها باید تا حد امکان معمولی باشند. این باعث میگردد که یک سیستم قابل فهم و شعور تر با قابلیت مراقبت بالاتر را داشته باشید.
اصل سوم) محافظت چشم انداز: برای موفقیت یک پروژه نرم افزاری، چشم اندازی روشن، ضروری می باشد و بدون آن پروژه تقریبا همواره به جایی می‌رسد که دو یا یکسری ایده بر آن حکم کننده شود. یک سیستم فارغ از یکپارچگی مفهومی، به دسته ی ناجوری از طراحی های ناسازگار تبدیل میشود که به یکدیگر وصله-پینه شده اند. مسامحه در خصوص خصوص چشم انداز معماری یک سیستم نرم افزاری سبب تضعیف سیستمی با طراحی بهتر و عاقبت از فعالیت افتادن آن می گردد.
اصل چهارم) آنچه که شما تولید می کنید، سایر افراد مصرف می کنند: همواره گزینش مختصات، طراحی و پیاده سازی را طوری انجام دهید که دیگرافراد نیز قدرتمند به شعور عمل شما باشند.
اصل پنجم) آجل نگری: سیستمی با طول عمر بالا از بها بیشتری برخوردار است. سیستم ها می بایست شایستگی انطباق بر تغییرات را داشته باشند. سیستم هایی که این مختصات را با موفقیت ارائه می دهند، از شروع با این خصوصیات طراحی میشوند.
اصل ششم) برنامه ریزی پیشاپیش برای به کارگیری مجدد: استفاده مجدد باعث صرفه جویی در طی و کار می‌گردد. استعمال مجدد از کد ها و طراحی ها به عنوان مزیت مهم حرفه آوری های شیئ گرا مطرح گردیده‌است ولی این قابلیت در برنامه نویسی شیئ گرا نیازمند برنامه ریزی قبلی می باشد.
اصل هفتم) نفکر: این آخرین اصل احتمالاً بیشتراز بقیه مورد بی مهری قرار میگیرد. تاخیر و تامل بی نقص و روشن قبل از اقدام به شغل، همواره نتایج بهتری به بار می آورد. با تفکر روشن درباره سیستم، ارزش آن بالا می رود. به کارگیری شش اصل نخست نیاز به تامل عمیق دارد و در این حالت، منفعت بسیاری از آن عاید گردد.
در دو نوشته‌ی‌علمی آینده به ترتیب به گستردن مدل های متعدد فرایند های برنامه و توسعه چابک میپردازیم و عملکرد می‌کنیم که این مفاد را با جزئیات کامل تحقیق نمائیم.