در ادامه آشنايي با حوزه‌ها و فعاليتهاي مختلف در فرآيند توليد نرم افزار كه اميدوارم با توجه به اصول مهندسي نرم افزار باشد، به "طراحي نرم افزار" مي‌رسيم.

طراحي نرم افزار (Software Design)

مقدمه
بعد از فعاليتهاي مربوط به حوزهً نيازمنديها نوبت به طراحي يا Design مي‌رسد. در واقع طراحي مانند پلي است كه نيازمنديهاي تهيه شده را به پياده سازي متصل مي‌سازد و نقش بسيار مهمي را در فرآيند توليد نرم افزار بازي مي‌كند. اگر نرم افزار به درستي طراحي گردد، در هنگام پياده سازي برنامه نويسان دربارة چيزي كه بايد پياده سازي شود سردرگمي ندارند و فقط به مسائل مربوط به پياده سازي مي‌پردازند.
طراحي نرم افزار مقولة بسيار گسترده‌اي است و ادبيات آن به تنهايي شامل چندين هزار صفحه مطلب است. از معماري نرم افزار بگيريد تا رويكردهاي طراحي مانند شئي گرايي تا طراحي واسط كاربر. در ادامه با عنوانهاي متعدد ولي كوتاه سعي به معرفي كليات آن مي‌كنم.

به چه كاري طراحي مي‌گويند؟

ابتدا تعريف برگرفته از چند منبع معتبر:

فرآيند مشخص سازي معماري، مؤلفه‌ها (Components)، واسطها (Interfaces) و ديگر خصوصيات سيستم يا مؤلفه را "طراحي" گويند. به محصول اين فرآيند نيز "طراحي" گفته مي‌شود.[IEE04]

يا

طراحي نرم افزار شرحي بر ساختار، داده، واسطهاي بين مؤلفه‌هاي سيستم، و گاهي الگوريتمهاي مورد استفادة نرم افزار قرار به پياده سازي مي‌باشد. [Som06]

تعريف من از طراحي ملموس‌تر است:

تهيه هرآنچه برنامه نويسان از نيازمنديهاي نرم افزار براي پياده سازي نرم افزار نياز دارند.

براي روشن شدن چهارچوبه مبحثي كه در ادامه به آن خواهيم پرداخت شكلي از اجزاي كلي طراحي و ارتباط آن با حوزه تحليل نيازمنديها از [Pre04] آورده ‌ام.

قوائد طراحي

براي طراحي صحيح و خلق طراحي مناسب، لازم است يك سري قوائد رعايت شود، اين قوائد كه در طول ساليان توسط فعالان اين حوزه بدست آمده است، ما را در انجام درست طراحي ياري دهد. به عنوان كسي كه قصد طراحي نرم افزار داريد آشنايي با اين اصطلاحات لازم است.

انتزاع/تجرد/چكيدگي (Abstraction):
ترجمه‌هاي متعددي براي اين اصطلاح آورده شده كه من در اينجا از "انتزاع" استفاده مي‌كنم. در كل طراحي نرم افزار از "انتزاع"كم كردن جزئيات را مد نظر دارد. مثل هميشه ذكر يك مثال بهتر از توضيحات گيج كننده است: براي چاپ يك صفحه شما امكان دارد بگوييد: "اين صفحه را چاپ كنيد!" يا دقيقتر حرف بزنيد و بگوييد: "به منوي فايل رفته، گزينة چاپ را انتخاب كرده، سپس... و كليد تأييد را فشار دهيد." در جمله اول روال چاپ با سطح بالاتري از انتزاع نسبت به روال توصيف شده در جمله دوم بيان شده است و جزئيات كمتري دارد. مي‌توان جمله سومي نوشت و روال كار را جزئي‌تر هم تصور كرد."
انتزاع" در طراحي روشي براي كاهش پيچيدگي محسوب مي‌شود و داراي سه نوع است: "انتزاع رويه‌اي" (Procedural Abstraction)، "انتزاع داده" (Data Abstraction) و "انتزاع كنترل" (Control Abstraction).

وابستگي ( Coupling)
كوپلينگ بيان كننده شدت ارتباط بين دو ماژول [عنصر] است [IEE04]. كه من آن را "وابستگي" ترجمه كرده‌ام. وابستگي در طراحي بايد حداقل ممكن باشد كه بدان Low Coupling گويند. با اين كار تغييرات روي ماژالها راحت تر و كم هزينه‌تر خواهد بود و استفاده مجدد به راحتي صورت مي‌پذيرد [Lar04].
اصطلاحي كه براي ماژولهايي با وابستگي كم بكار برده مي‌شود "loosely Coupled" است كه به همين مفهوم اشاره داد.

پيوستگي (Cohesion)
به شدت ارتباط عناصر تشكليل دهندة يك ماژول Cohesion گفته مي‌شود [IEE04]. وابستگي عناصر تشكيل دهنده يك ماژول بايد حداكثر ممكن باشد كه بدان High Cohesion مي‌گويند و باعث مي‌شود ماژولها متمركزتر، قابل فهم ‌تر باشند و به راحتي مديريت شوند [Lar04].

تفكيك يا ماژول بندي (Decomposition/Modularization)
در عمل تفكيك، نرم افزار به قسمتهايي مشخص و آدرس پذيري به نام "ماژول" تقسيم مي‌شود. ماژول بندي تنها خصوصيت نرم افزار است كه باعث مي‌شود برنامه به صورت عاقلانه‌اي اداره شود [IEE04]. مديريت يك نرم افزار بزرگ و يك تكه كار دشواري است و با شكستن آن به بخشهاي كوچكتر (براي مثال با EJB يا COM ) مديريت آن راحت‌تر صورت مي‌پذيرد.

كپسوله سازي/پنهان سازي اطلاعات ( Encapsulation/Information Hiding)
بطور خلاصه پنهان سازي اطلاعات يا كپسوله سازي به اين مطلب اشاره دارد كه پيمانه‌هاي مختلف نرم افزار به اطلاعات (داده و الگوريتم) يكديگر [در صورت صلاح ديد] دسترسي نداشته باشند. اين مفهوم كه بعدها در شئي گرايي به عنوان ويژگي شاخص مطرح شد، از دسترسي و دستكاريهاي ناخواسته ماژولها به هم جلوگيري مي‌كند.

مواردي كه به نظرم مهم بود ذكر كردم، البته اين ليست طولاني‌تر است و براي مثال Sufficiency, completeness and primitiveness توصيه مي‌كند خصوصيات هر مؤلفه نرم افزار به حد كفايت (نه كم به زياد) باشد، در صورت تمايل به SWEBOK بخش طراحي براي مشاهده منابع مربوط به اين موارد رجوع كنيد.

طراحي شامل چه فعاليتهايي مي‌شود؟

براساس استانداردهاي چرخه توليد نرم افزار از جمله IEEE/EIA 12207 طراحي نرم افزار شامل دو فعاليت عمده است:
طراحي معماري نرم افزار
در اين طراحي كه طراحي "سطح بالا" نيز گفته مي‌شود، به توصيف سطح بالا و كلي ساختار و سازمان نرم افزار پرداخته مي‌شود و مؤلفه‌هاي مختلف آن شناسايي مي‌گردند. [IEE04]
براي هر پروژه‌اي معماري لازم است ولي براي يك پروژه لازم است از ديدگاه‌هاي مختلف بدان پرداخته شود ولي براي پروژه‌هاي كوچكتر فقط يك تصميم براي انتخاب معماري كافي است. يك مثال از معماري نرم افزار در ادامه آورده شده. توضيحات تكميلي در مورد "معماري" بعداً ارائه خواهد شد.

توضيح: اين دياگرام Component با استفاده از UML 2.0 توسط آقاي Scott Ambler كشيده شده و بيان كننده معماري يك سيستم دانشگاهي مي‌باشد. همانگونه كه مشاهده مي‌شود مؤلفه‌هاي اين سيستم و ارتباط آنها با يكديگر به خوبي با اين دياگرام بيان شده است.

طراحي تفصيلي نرم افزار
همانگونه كه اشاره شد در معماري نرم افزار، نرم افزار به بخشها و مؤلفه‌هاي مختلف تفكيك مي‌شود. در طراحي تفصيلي نرم افزار اين مؤلفه‌ها و اجزا با جزئيات كامل بايد تشريح شوند. براي مثال طراحي فيلدهاي جدول بانك اطلاعاتي، طراحي توابع يا كلاسهاي نرم افزار و مشخص كردن ورودي و خروجي آنها، طراحي جزئيات واسط كاربر و اجزاي فرم يا صفحه وب، مثالهايي از طراحي تفصيلي نرم افزار است.

روشهاي كلي طراحي

در طراحي مي‌توان رويكردهاي مختلفي اتخاذ نمود. هر روش خصوصيات مخصوصي دارد كه طراح با توجه به نوع سيستمي كه پيش رو دارد بايد روش صحيح را انتخاب كند. در ادامه به معرفي روشهاي مطرح مي‌پردازم:

طراحي ساخت يافته (Structured Design)
اين روش طراحي سنتي كه حداقل در ايران پركاربردترين روش طراحي است، مبتني بر شناسايي عمكلردهاي اصلي (Major Functions) نرم افزار و سپس شكستن و ريز كردن آنها بصورت بالا به پايين (Top-down) مي‌باشد. لازم به ذكر است در اين روش معمولاً از Data Flow Diagram براي انتساب داده‌ به فرآيند استفاده مي‌شود. [IEE04]

طراحي شئي گرا (Object Oriented)
در اين روش سيستم در دنياي واقعي بصورت اشيائي كه داراي خصوصيت و رفتار هستند،‌ در نرم افزار نمود پيدا مي‌كند. اين اشياء بوسيله Message‌ با هم ارتباط برقرار مي‌كنند و در كلاسها و زير كلاسها دسته بندي مي‌شوند [Pre01]. بطور خلاصه هر شئي داراي نام، يكسري خصوصيت (Attribute) و متد (Method) مي‌باشد كه در ارتباط با هم نرم افزار را تشكيل مي‌دهند. يكي از محاسن استفاده از روش شئي گرايي اين است كه شكاف مفهومي تحليل، طراحي و پياده سازي را به حداقل رسانده است، به بيان ديگر شما در هر سه اين فعاليتها با مفهوم كلاس، شئي، متد و... سروكار داريد. حسني كه در روشهاي ساخت يافته غايب است. [Lar04]

طراحي متمركز بر ساختار داده (Data-Structure-Centered Design)
اين روش همانند "ساخت يافته" است با اين تفاوت كه پايه طراحي "داده" است و نه "عمليات". در اين روش طراح در ابتدا ساختار داده ورودي خروجي را مشخص كرده (مثلاً با دياگرام جكسون) و سپس ساختار كنترل را براساس ساختار داده مشخص مي‌نمايد.

طراحي مبتني بر مؤلفه(Component Based Design )
ابتدا مؤلفه را تعريف مي‌كنم: مؤلفه يك واحد مستقل مي‌باشد كه از واسطها (Interface‌) و وابستگيهايي كه بطور شايسته‌اي تعريف شده، برخوردار مي‌باشد. مؤلفه بصورت مستقل و مجزا قابل انتشار است [IEE04]. از اين تعريف خشك بگذريم، بطور ساده مؤلفه يك مجموعه عملكرد (معمولاً شئي) است كه با استفاده از كپسوله سازي و انتزاع به يك واحد مستقل و قابل استفاده مجدد تبديل شده است. طراحي با استفاده از مؤلفه و قرار دادن آنها كنار هم براي رسيدن به يك كل كه نرم افزار هدف ماست را طراحي مبتني بر مؤلفه
گويند[Pre01].
براي مطالعه بيشتر در مورد موارد مطرح شده به فصول 11، 14، 15 و 16 اين كتاب مراجعه نماييد.

خصوصيات كيفي طراحي (Quality Attributes)

يكي از بحثهاي مهم كه كمتر از آنچه بايد و شايد مورد توجه قرار مي‌گيرد، درنظرگرفتن معياريهاي كيفي طراحي است. طراحان نرم افزار عادت دارند برروي حل مسئله تمركز كنند و فراموش مي‌كنند كه خصوصيات كيفي هميشه جزئي از مسئله است و بايد مد نظر قرار بگيرد[Pre01]. در ادامه به برخي از خصوصيات كيفي كه تحت عنوان FURPS مشهور هستند، مي‌پردازم:

• عملكرد (Functionality): اين خصوصيت با توجه به امكانات و توانايي نرم افزار طراحي شده و همچينين امنيت (Security) مربوط به آنها ارزيابي مي‌شود.
• قابليت استفاده (Usability): اين خصوصيت با در نظر گرفتن معياريهاي انساني (Human Factos)، راهنماي نرم افزار و مستندات آن ارزيابي مي‌شود.
• قابلبت اطمينان (Reliability): اين خصوصيت با توجه به تعدد و شدت خطا، صحت خروجي، توانايي پوشش خطا و پيش بيني پذيربودن (Predictability) نرم افزار ارزيابي مي‌شود.
• كارايي (Performance): اين خصوصيت كيفي با توجه به سرعت پردازش، زمان پاسخگويي، مصرف منابع، توان و كارايي سنجيده ميشود.
• قابليت پشتيباني (Supportability): اين مورد شامل خصوصيت مختلفي از جمله: امكان توسعه قابليتهاي برنامه(Extensibility)، قابليت تست برنامه (Testability)، وجود امكان پيكربندي (Configurability) و بومي سازي (Internationalization) مي‌شود.

هر برنامه‌اي كه طراحي مي‌شود ممكن است برروي يكي از موارد ذكر شده تمركز بيشتري داشته باشد و لزوماً اهميت مساوي برخوردار نيستند. براي اطلاعات بيشتر به فصل 9 كتاب [Pre01] رجوع كنيد.

ثبت طراحي

براي مستند سازي يا بيان طراحي لازم است از نمادهايي استفاده شود. اين نمادها بايد آنقدر جامع باشد كه تمام جوانب طراحي را پشتيباني نمايند و مرسوم هم باشد تا براي ديگران نيز قابل فهم باشد.
مهمترين كاربرد ثبت طراحي (و ديگر مراحل توليد) بيشتر برقراري ارتباط با ديگران است تا مستندسازي آن براي مراجعات بعدي، واين نكته‌اي است كه كمتر به آن توجه مي‌شود!
نمادها و زبانهاي وجود دارد كه به دو دسته كلي تقسيم مي‌شود، دسته اول نمايي ايستا (Static) از ساختار سيستم نمايش مي‌دهند مانند "دياگرام كلاسهاي نرم افزار" و دسته دومي نمايي پويا (Dynamic) از رفتار سيستم ارائه مي‌دهند، مانند "Data Flow Diagram". در ادامه نگاهي دقيقتر به تعدادي از آنها مي‌اندازيم:

توصيف ساختاري (نماي ايستا)
بطور كلي نماي ايستا از يك سري عنصر نرم افزاري و رابطة بين آنها تشكيل شده است.

• Class & Object Diagrams: براي نمايش كلاسهاي (اشياء) طراحي شده و همچنين رابطه بين آنها مورد استفاده قرار مي‌گيرد. اين دياگرام از خانواده UML است.
• Component Diagrams: مؤلفه‌هاي سيستم و رابطه بين آنها را نمايش مي‌دهد و بيشتر در سطح معماري سيستم كاربرد دارد و از خانواده UML است.
• Deployment Diagrams: جهت مدلسازي جنبه‌هاي فيزيكي سيستم مورد استفاده قرارمي‌گيرد و شامل گره‌هاي (Node) سخت افزاري و رابطة بين آنهاست و از خانواده UML است.
• Entity-relationship diagrams يا ERD: يك مدل مفهومي از داده‌هايي كه در سيستم اطلاعاتي ذخيره مي‌شوند.
• Jackson structure diagrams: جهت توصيف ساختار داده مورد استفاده قرار مي‌گيرد.

توصيف رفتاري (نماي پويا)
اين نمادها جهت ثبت رفتار و تراكنش اجزاي سيستم بكار مي‌آيند كه به برخي از آنها اشاره مي‌كنم:

• Activity diagrams: اين دياگرام منطق رويه‌اي عمليات را نمايش مي‌دهد. اين دياگرام از خانواده UML است.
• Collaboration diagrams: كه در UML 1.x با نام Communication Diagrams شناخته مي‌شود. فعل و انفعال بين گروهي از اشياء را به نمايش مي‌گذارد و تمركز آن بر اشياء و پيغامهاي تبادل شده بين آنهاست.
• Data flow diagrams يا DFD: جهت نمايش روند چرخش داده در طول مجموعه‌اي از فرآيند، استفاده مي‌شود.
• Flowcharts: روند انجام يك فرآيند را نمايش مي‌دهد.
• Sequence diagrams: فعل و انفعال بين گروهي از اشياء را به نمايش مي‌گذارد و تمركز آن بر اشياء و ترتيب پيغامهاي تبادل شده بين آنهاست.

براي مطالعه موارد مربوط به UML به كتاب معروف UML Distilled مراجعه كرده و موارد غير UML را در اين كتاب جستجو كنيد.

مواري كه از قلم افتاد:

به نظر مي‌آيد سه مورد مهم ديگر را بايد اشاره مي‌كردم كه در دسته بندي‌هاي بالا غايب است:

• الگوهاي طراحي (Design Patterns): الگوهاي طراحي براي مسائلي كه طراح در طراحي زياد با آن مواجه مي‌شود، يك راه حل كلي ارائه مي‌دهند. براي مثال ثبت خطا (Error Logging) در نرم افزار مسئله معمولي است كه طراح بايد به آن بپردازد، با استفاده از الگوهاي طراحي بهترين روش براي انجام اين كار توسط طراحان زبده ارائه شده است و طراح فقط بايد آن را با مسئله خود تطبيق دهد. اصطلاح الگوهاي طراحي بيشتر در طراحي شئي گرا كاربرد دارد و اولين بار توسط Kent Beck مطرح شد و پس از آن با كتاب معروف Design Patterns‌ به بلوغ خود رسيد.
• طراحي واسط كاربر (User Inerface): طراحي واسط كاربر كه زير مجموعه حوزة Usability قرار ميگيرد، به طراحي ظاهر قابل رويت نرم افزار اشاره دارد. كتاب About Face كتاب مناسبي براي آشنايي با مباني اين مقوله است.
  
• طراحي بانك اطلاعاتي (Database Design): بيشتر نرم افزارهاي بزرگي كه در ايران توليد مي‌شوند به Data Model نياز دارند، چون به احتمال قوي به سيستم اطلاعاتي يك سازمان مربوط مي‌شود. طراحي بانك اطلاعاتي يكي ديگر از مقوله‌هاي طراحي نرم افزار است كه درنوع خود گسترده است. مخصوصاً اگر Data Warehouse و Data Mining هم به ميان بيايد. جهت مطالعه اين مبحث، اين كتاب توصيه مي‌شود.
  

در پايان

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

مقدمه
به نظر من يكي از مشكلات دانشجويان و تازه واردهاي توليد نرم افزار، نبود ديد كلي نسبت به بخشهاي مختلف مهندسي نرم افزار است. قبلاً اشاره‌اي به SWEBOK كردم، حال برپاية آن به معرفي حوزه‌هاي دانش مهندسي نرم افزار مي‌پردازم. بي شك خوانندگان مي‌توانند با رجوع به سندSWEBOK با منابع تشريح كننده هر حوزه آشنا شوند.
در كل 12 حوزه وجود دارد كه در ابتدا به اولين حوزه در چرخة توليد نرم افزار مي‌پردازم.

نيازمنديهاي نرم افزار (Software Requirements)

بررسيهاي مختلفي در مورد عوامل شكست پروژه‌هاي نرم افزار صورت پذيرفته است. عدم توجه به نيازمنديهاي پروژه و استخراج ناقص آنها يكي از عوامل اصلي شكست پروژه‌هاي نرم افزار شناخته شده است.
نيازمنديهاي نرم افزار مبحث مهم و گسترده‌اي است كه سعي ميكنم در چند پاراگراف كليات آن را بيان كنم.

تعريف چند اصطلاح
تعاريف مختلفي براي نيازمندي نرم افزار ارائه شده است، بنا به تعريف IEEE:

نيازمندي خصوصيت يا ملاكي است كه در راستاي حل مشكل در دنياي حقيقي، بيان مي‌شود.

بر اين پايه:

نيازمندي نرم افزاري، خصوصيت يا ملاكي است كه با هدف حل مشكل در دنياي حقيقي، پايه پياده سازي نرم افزار مي‌شود. كه IEEE به آن "نيازمندي محصول" (Product Requirement) مي‌گويد.

و در مقابل

"نيازمندي فرآيند" (Process Requiremnt) به نيازمنديهاي خوده توسعه نرم افزار مي‌پردازد مانند: "نرم افزار بايد با زبان #C‌ نوشته شود".

تمركز از اينجا به بعد بر "نيازمندي محصول" است و به مفاهيم مرتبط با آن اشاره مي‌كنم.

اجزا و عوامل تأثيرگذار بر"نيازمنديهاي نرم افزاري"

شكلي كه در ادامه آمده است به نحو جالبي اجزا و عوامل تأثيرگذار بر "نيازمنديهاي نرم افزار" را نمايش مي‌دهد [Kar03]:


نيازمنديها به دو دسته كلي تقسيم مي‌شوند:

1. نيازمنديهاي عملياتي (Functional) يا رفتاري (Behavioral): به زبان ساده اين نوع نيازمندي ارتباط مستقيم با فعاليتهاي تجاري كاربر دارد و توسعه دهنده بايد آنها را پياده سازي كند تا كاربر بتواند از نرم افزار استفاده نمايد. به عنوان مثال "نرم افزار بايد امكان ايجاد طرف حساب جديد را داشته باشد" يك نيازمندي عملياتي است. بصورت سنتي نيازمنديهاي عملياتي بصورت ليستي از امكانات (مانند مثالي كه زده شد) بيان مي‌شدند ولي امروزه روشهاي مؤثرتري مانند Usecase يا استفاده از UML در حال گسترش است.
2. نيازمنديهاي غير عملياتي (Nonfunctional): اين نوع نيازمندي به عنوان محدوديت براي سرويس يا عملكردي كه سيستم ارائه مي‌دهند، در نظر گرفته مي‌شوند. آنها شامل محدوديتهاي زماني، محدوديت براي فرآيند يا استاندارهاي توسعه مي‌باشند. آنها معمولاً به كليت سيستم اعمال مي‌شوند و مربوط به سرويس يا امكان خاصي نيستند [Som06]. به موارد ذكر شده مي‌توانيد نيازمنديهاي كيفي نرم افزار مانند Usability يا كاربري، Reliability يا قابليت اطمينان، Performance‌ يا كارايي، Supportability را نيز اضافه كنيد. در آينده با بررسي مدل +FURPS بيشتر به اين مقوله مي‌پردازم.

موارد ديگري كه ذكر توضيح كوتاهي در مورد آنها خالي از لطف نيست:

• نيازمندي تجاري (Business Requirement): بالاترين سطح نيازمندي است كه بدون توجه به سيستم نرم افزاري كه قرار به توليد است به سازمان و كسب و كار مربوط به آن مي‌پردازد.
• نيازمنديهاي كاربر (User Requirement) و بقيه زير مجموعه Functional: از اين به بعد وارد چرخه توليد نرم افزار شده‌ايم و با توجه به سيستمي كه قرار به تهيه است، نيازمنديها جمع آوري و منعكس مي‌شوند.
• Use case Document: يكي از منعطف ترين و قدرتمندترين ابزاري كه بشر براي جمع آوري و تكميل نيازمنديهاي عملياتي شناخته است. در آينده بصورت مبسوط به آن مي‌پردازم.
• Business Rules يا قوانين تجاري: معمولاً به قوانين خارج از سازمان اشاره دارد مانند قوانين مالياتي يا استاندارهاي اجباري. اين قوانين برروي توسعه سيستم شما تأثير دارند.
• خصوصيات و پارامترهاي كيفي (Quality Attributes): در نيازمنديهاي غير عملياتي به آنها اشاره كردم Usability يا كاربري، Reliability يا قابليت اطمينان، Performance‌ يا كارايي، Supportability. آنها به "ility-" هم معروف هستند، چون بيشتر آنها با همين 5 حرف پايان مي‌يابند.

تا اينجا به نظر من پرداختن به مفاهيم كافي است، اگر سئوالي در ذهن شما هست كه هنوز پاسخ داده نشده، با من در ميان بگذاريد.

فعاليتها در حوزة "نيازمنديهاي نرم افزاري"

چهار فعاليت عمده در حوزة "نيامنديهاي نرم افزار" وجود دارد كه ذكر آنها لازم به نظر مي‌رسد:

1. استخراج (Elicitation): فعاليتي است كه در آن فرد مسئول با ذي نفعان پروژه ارتباط برقرار مي‌كند و نياز و انتظار آنان از نرم افزار كه قرار است توليد شود را كشف مي‌نمايد. اين فعاليت از طريق مصاحبه، مشاهده و ساير تكنيكهاي ممكنه صورت مي‌پذيرد.
2. تجزيه و تحليل (Analysis): در اين مرحله با تجزيه و تحليل خروجي مرحله قبل تضادهاي احتمالي بين نيازمنديهاي استخراج شده از بين مي‌رود، مرز نيازمنديهايي كه بايد پياده سازي شود پرنگ شده و نيازمنديها دسته بندي مي‌شوند.
3. تهيه مشخصات (Specification): اين فعاليت به زبان ساده به مستندسازي و مكتوب كردن نيازمنديها اشاره دارد با اين توضيح كه بصورت نظامند قابل بازبيني، ارزيابي و تصديق باشند.
4. تصديق (Validation): در اين فعاليت نيازمنديهاي مستند شده با هدف تصديق صحت آنها بررسي مي‌شوند. اين صحت شامل تطابق با استاندارهاي شركت، قابل فهم بودن، سازگاري و كامل بودن آنان مي‌باشد.

عدم توجه به هر كدام از موارد بالا سلامت پروژه را با خطر مواجه مي‌كند.

سخن پاياني
اميدوارم با همين مقدمه كوتاه ديد بازتري نسبت به "نيازمنديهاي نرم افزار" پيدا كرده باشيد. سعي مي‌كنم در آينده نكات عملي بيشتري در مورد اين حوزة مهم از مهندسي نرم افزار بيان كنم.

معرفي پيكرة دانش مهندسي نرم افزار (SWEBOK)

مقدمه

هر رشته‌اي براي خود مفاهيمي دارد كه بايد توسط افرادي كه قصد فعاليت در آن حوزه را دارند فرا گرفته شود. براي مثال مهندسين عمران بايد در زمينه نقشه كشي، تأسيسات و شناخت مواد مطالبي مختلفي را مطالعه كرده و به خاطر بسپارد. شكي نيست كه در مورد رشته مهندسي نرم افزار هم اين چنين است. اشكالي كه برخي به اين موضوع وارد مي‌دانند اين است كه نرم افزار به حدي متغير و وابسته به فن آوري (تكنولوژي) است كه پاية با ثباتي نمي‌توان براي آن بنا نمود.
حال سئوال اينجاست كه به بهانة متغير بودن نرم افزار مي‌توان از تدوين و مطالعة اصول توليد (مهندسي) نرم افزار سرباز زد؟ نگاهي به اتفاقاتي كه تا كنون افتاده مي‌اندازيم:
در سال 1968 در همايش معروف NATO اولين هستة با ثبات براي مهندسي نرم افزار تدوين شد. سال 1968 چه مباحثي در حوزة نرم افزار وجود داشت؟

• اولين الگوريتم جستجوي صحيح دودويي در سال 1962 منتشر شده بود.
• در سال 1968 در مورد مضر بودن Goto بحثهاي داغي در جريان بود.
• اولين كتاب در زمينه تحليل نيازمنديهاي نرم افزار در سال 1979 منتشر شد. يعني 11 سال بعد از همايش NATO

با اين حال 10 تا 20 درصد دانش مهندسي نرم افزار آن موقع هنوز استفاده مي‌شود. [McC03]

همانگونه كه در شكل مي‌بينيد، هستة دروني تا كنون ثابت بوده و بخش خاكستري نشان دهنده كل دانش مهندسي نرم افزار فرض شده كه از سال 1968 تا كنون افزوده شده يا تغيير كرده است.
در حال حاضر در مقايسه با سال 1968 هزاران عنوان كتاب و مقاله در زمينه مهندسي نرم افزار نگاشته شده و بيش از 2000 صفحه استاندارد مهندسي نرم افزار در IEEE دسته بندي شده است. شكل زير نشان دهنده وضع در سال 2003 است.

50 درصد دانش مهندسي نرم افزار به ثبات رسيده است و انتظار مي‌رود تا 30 سال آينده اطلاعات موجود در هسته اعتبار خود را حفظ كنند. [McC03] و اين نشان مي‌دهد يك فعال در اين حوزه براي فراگيري آنها مي‌تواند برنامه ريزي كند. به هر حال تغيير در همه رشته‌ها وجود دارد هر روز خبر از كشف شيوه‌هاي جديد و تغيير در نظريه‌هاي رشته‌هاي مختلف شنيده مي‌شود و نمي‌توان از نرم افزار انتظار داشت براي هميشه ثابت بماند تا ما انگيزه پيدا كنيم و به مطالعة دانش مهندسي نرم افزار بپردازيم. واقعيت اين است كه فن آوري زير ساختهاي توليد نرم افزار را بيشتر تحت تأثير قرار مي‌دهند و دانش توليد نرم افزار در كل تغييرات كمتري را به خود مي‌بينند.

پيكرة دانش مهندسي نرم افزار (Software Engineering Body of Knowledge)

حال كه بيان شد دانش مهندسي نرم افزار وجود دارد و به اندازه كافي با ثبات است، نوبت معرفي آن ميرسد. ارائه تمام دانش در اين نوشتار ممكن نيست، به همين دليل به معرفي و ارائه منبع براي مطالعه بيشتر اكتفا مي‌كنم.
بانيان تهيه SWEBOK گروهي از شركتها، دانشگاه‌ها و فعالان حوزه نرم افزار زير چتر IEEE مي‌باشند كه من در اين نوشتار از آخرين نسخه آن يعني 2004 با عنوان "راهنماي پيكرة دانش مهندسي نرم افزار" به عنوان مرجع استفاده كرده‌ام. در وب سايت مربوطه راهنما براي دانلود وجود دارد و اطلاعات تكميلي براي علاقمندان موجود است. توضيح اين نكته لازم است كه دانش مهندسي نرم افزار چندين هزار صفحه مطلب است و راهنماي آن صرفاً به معرفي چهارچوب و منابع مستندات آن در ادبيات مهندسي نرم افزار مي‌پردازد.
حوزه‌هاي مرتبط با مهندسي نرم افزار در ادامه آمده است:

همانگونه كه در شكل نمايش داده شده است، مهندسي نرم افزار از علوم كامپيوتر، رياضيات، علوم شناختي (روانشناسي و جامعه شناسي)، مديريت پروژه، و نظامهاي مختلف مهندسي الهام گرفته است.
با توجه به همين نقطه آغازين، SWEBOK حوزه‌هاي دانش تشكيل دهندة توانايي‌هاي پايه‌اي براي يك مهندس نرم افزار حرفه‌اي را شناسايي كرده است.

1. نيازمنديهاي نرم افزاري: كشف، مستندسازي، و تحليل عملياتي كه بايد در نرم افزار پياده سازي شود.
2. طراحي نرم افزار: تعريف ساختار اصلي سيستم در سطوح معماري و جزئي، تقسيم بندي در ماژولها، تعريف واسطهاي ماژولها، و انتخاب الگوريتمهاي دروني ماژولها.
3. ساخت نرم افزار: پياده سازي نرم افزار شامل طراحي تفصيلي، كد نويسي، خطايابي، تست يونيتها، بازبيني فني، و بهينه سازي كارايي. اين ناحيه بعضاً با طراحي نرم افزار و تست نرم افزار هم پوشاني دارد.
4. تست نرم افزار: شامل تمام فعاليتهاي مرتبط با اجراي نرم افزار كه با هدف پي بردن به نقايص و ارزيابي خصيصه‌هاي نرم افزار صورت مي‌پذيرد. تست كردن شامل برنامه ريزي تست، طراحي حالت آزمون (Test Case)، و انواع خاصي از تست شامل تستهاي توسعه، تست يونيت، تست مؤلفه، تست سيستم، تستهاي استرس، و تستهاي پذيرش مي‌باشد.
5. نگهداري نرم افزار: بازنگري و بهبود نرم افزار، مستندات و تستهاي موجود.
6. مديريت پيكربندي نرم افزار: شناسايي، مستندسازي، و كنترل تغيير تمام دارايي هاي منطقي پروژة نرم افزاري شامل كد منبع، محتوا (موارد ترسيمي، صدا، متن و ويدئو)، نيازمنديها، طراحي، تداركات تست، تخمينها، برنامه‌ها، و مستندات مربوط به كاربر.
7. كيفيت نرم افزار: كليه عمليات مربوط به حصول اطمينان از سازگاري نرم افزار با نيازمنديهاي فني را شامل مي‌شود. مهندسي كيفيت شامل برنامه تضمين كيفيت، سنجش كيفيت، قابليت اطمينان (Reliability)، تست، بازبيني فني، مميزي، تحقيق و تأييد صحت برنامه.
8. مديريت مهندسي نرم افزار: برنامه ريزي، پيگيري، و كنترل پروژه، شغل، يا تشكيلات نرم افزاري.
9. ابزارها و روشهاي مهندسي نرم افزار: حمايت از ابزار و روش‌شناسيها (Methodology)، مانند ابزارهاي CASE، كتابخانه‌هاي كد قابل استفاده مجدد، و روشهاي قراردادي، شامل ممارست در جهت تعميم و گسترش ابزار و روش‌شناسيها در درون سازمان.
10. فرآيند مهندسي نرم افزار: فعاليتهايي در رابطه با بهبود كيفيت در توسعة نرم افزار، دقت، بهره‌وري، و ديگر مشخصات پروژه و محصول.

تا اينجا دليل تدوين SWEBOK بيان شد و بصورت خلاصه كليات آن را مطرح كردم. دو نكته را در پايان متذكر مي‌شوم:

• SWEBOK تهيه شده، فقط شامل مواردي است كه توسط بيشتر فعالان حوزه نرم افزار پذيرفته شده و از ذكر مباحث بحث برانگيز و در حال بررسي اجتناب شده است.
• در هر پروژه‌اي نياز به استفاده از تمام حوزه‌هاي مطرح شده نمي باشد، ولي در صورت كاربردي بودن (با توجه به بند بالا) قابل استفاده است.

شما هم مي‌توانيد با مطالعه راهنماي تهيه شده توسط IEEE اطلاعات زيادي را بدست آوريد و با آگاهي بيشتري نرم افزار توليد كنيد.

دروس كارشناسي مهندسي نرم افزار

همانگونه كه قرار بود، قصد بررسي دروس ارائه شده در مقطع كارشناسي مهندسي نرم افزار در ايران را داريم. بي شك مرتبط بودن و كيفيت ارائه، عامل مهمي در تربيت مناسب نيروهاي فعال در حوزة مهندسي نرم افزار مي‌باشد.

كارشناسي مهندسي نرم افزار- آنچه هست
طبق مصوبة شوراي عالي برنامه ريزي وزارت فرهنگ و آموزش عالي مورخه 1377/8/24، ليست دروس اصلي و تخصصي دورة كارشناسي مهندسي كامپيوتر، گرايش نرم افزار به شرح ذيل است:

رديف	نام درس
1	آزمايشگاه كامپيوتر
2	مباني كامپيوتر و برنامه سازي
3	برنامه سازي پيشرفته
4	ساختمانهاي گسسته
5	زبان ماشين و برنامه سازي سيستم
6	ساختمان داده ها
7	زبان تخصصي
8	مدار الكتريكي 1
9	آزمايشگاه مدار الكتريكي 1
10	مدار منطقي
11	آزمايشگاه مدار منطقي
12	رياضي مهندسي
13	طراحي الگوريتم
14	معماري كامپيوتر
15	آزمايشگاه معماري كامپيوتر
16	سيستمهاي عامل
17	نظريه زبانها و ماشينها
18	طراحي و پياده سازي زبانهاي برنامه سازي
19	ريز پردازنده
20	آزمايشگاه ريز پردازنده
21	مدارهاي الكترونيكي
22	آزمايشگاه مدارهاي الكترونيكي
23	شبكه‌هاي كامپيوتري
24	شيوه ارائه مطالب علمي و فني
25	ذخيره و بازيابي اطلاعات
26	هوش مصنوعي
27	اصول طراحي كامپايلر
28	مهندسي نرم افزار 1 و 2
29	اصول طراحي پايگاه داده
30	آزمايشگاه سيستم عامل
31	آزمايشگاه پايگاه داده
32	پروژه
33	كارآموزي

و به استناد همان مصوبه، قابليت و مهارتهاي زير از فارغ التحصيلان رشته كامپيوتر انتظار مي‌رود:

1. بررسي و شناسايي سيستمهاي كامپيوتري به منظور انتخاب و سفارش سخت افزار، نرم افزار بهينه، هدايت و نظارت در نصب و بهره برداري ازآنها.
   
2. ارائه روشهاي عيب يابي، اصلاح و تكميل سيستمهاي سخت افزاري ويا نرم افزاري موجود و نظارت بر اين امور.
   
3. طراحي، ساخت و راه انداري سيستمهاي جديد سخت افزاري و نرم افزاري.
   
4. تشخيص لزوم استفاده از كامپيوتر در كنترل عمليات در محيطهاي مختلف.
   
5. شناسايي تكنيكهاي جديد طراحي وساخت كامپيوتر، ارزيابي و بكارگيري آنها.

به نظر مي رسد:

1. ليست دروس تصويب شده بيشتر براي تربيت دانشجوي مسلح به علم كامپيوتر مناسب به نظر مي‌رسد تا مهندسي نرم افزار موارد 8، 9،10، 11،12، 14، 15، 19، 20، 21، 22 دروس مرتبط با Computer science است.
2. دروسي كه مستقيماً به مهندسي نرم افزار مرتبط مي‌شوند اندك است.
   
3. غير از مورد 31 هيچ آزمايشگاه ديگري مرتبط با مهندسي نرم افزار وجود ندارد در حالي 7 مورد آزمايشگاه متفرقه وجود دارد.
4. مهارتهاي مديريتي جايگاهي در ليست ندارد.
5. به نظر مي‌رسد مسئولين مربوطه بيشتر به "كامپيوتر" پرداخته‌اند تا "نرم افزار".

در كل اهداف ودروس ارائه شده نشان از ديدگاه قديمي (حدود دهه 70 ميلادي) نسبت به مهندسي نرم افزار دارد. حال اينكه توليد نرم افزار فرآيندي به نسبت پيچيده و حتي متفاوت با ديگر رشته‌هاي مهندسي است. مهندسي نرم افزار تغييرات بسياري از آن زمان تا كنون كرده است و به مقوله‌اي جدي و مستقل تبديل شده است.

آنچه بايد بشود
تلاشهاي ثمر بخشي در زمينه تعريف بدنة دانش مهندسي نرم افزار (Software Engineering Body of Knowledge) و تعيين دروس اساسي دوره كارشناسي مهندسي نرم افزار شده است، نظر شما را به دروس الزامي مهندسي نرم افزار، كار مشتركي از ACM و IEEE (نسخه 2004) جلب مي‌نمايم:

رديف	عنوان لاتين	توضيح فارسي
1	Introduction to Software Engineering and Computing	مقدمات مهندسي نرم افزار و كامپيوتر
2	Software Engineering and Computing II	مهندسي نرم افزار و كاميپوتر 2
3	Software Engineering and Computing III	مهندسي نرم افزار و كاميپوتر 3
4	Data Structures and Algorithms	الگوريتم و ساختمان داده
5	Programming Fundamentals	مقدمات برنامه نويسي
6	The Object-Oriented Paradigm	مدل شئي گرا
7	Introduction to Software Engineering	مقدمات مهندس نرم افزار
8	Discrete Structures I	ساختمانهاي گسسته 1
9	Discrete Structures II	ساختمانهاي گسسته 2
10	Statistics and Empirical Methods	آمار و روشهاي تجربي
11	Software Construction	ساخت (پياده سازي) نرم افزار
12	Software Engineering Approach to Human Computer Interaction	مباحث مربوط به طراحي واسط كاربر
13	Software Design and Architecture	معماري و طراحي نرم افزار
14	Software Quality Assurance and Testing	تضمين كيفيت و تست نرم افزار
15	Software Requirements Analysis	تجزيه و تحليل نيازمنديهاي نرم افزاري
16	Software Project Management	مديريت پروژه‌هاي نرم افزار
17	Design and Architecture of Large Software Systems	معماري و طراحي و سيستمهاي بزرگ نرم افزاري
18	Software Testing	تست نرم افزار
19	Low-Level Design of Software	طراحي سطح پايين سيستم
20	Software Process and Management	فرآيند توليد و مديريت نرم افزار
21	Formal Methods in Software Engineering	روشهاي رسمي در مهندسي نرم افزار
22	Software Engineering Capstone Project	پروژه

اين ليست شامل موارد ديگري مانند دوره‌هاي عملي و اقتصاد در مديريت نيز مي‌شود.
لازم به ياددآوري است كه اين ليست شامل موارد الزامي مي‌باشد و هر دوره‌اي مي‌تواند دروس ديگري را نيز به صلاح ديد خود ارائه دهد.

نتيجه
همانگونه كه مشهود است دروسي كه در حال حاضر در ايران ارائه مي‌شود نياز به بازبيني جدي دارد تا خروجي دانشگاه‌هاي كشورمان بتواند گره‌اي از كلاف بهم پيچيدة توليد نرم افزار بگشايد.

مهندسي نرم افزار - هزار راه نرفته

به عقيده من مشكلات مهندسي شدن نرم افزار را در دو حوزه مي‌توان دسته بندي نمود:

1. درك مفهوم و لزوم "مهندسي نرم افزار"
2. ضعف آموزش در مراكز دانشگاهي و علمي

باز هم يادآور مي‌شوم اين موضوع با مشكلات پروژه‌هاي نرم افزاري متفاوت است، كه آن هم در جاي خود بررسي خواهد شد.

درك مفهوم و لزوم "مهندسي نرم افزار"

با توجه به اينكه بيشتر افرادي كه در حوزه توليد نرم افزار فعاليت مي‌كنند، مدركي غير از "مهندسي نرم افزار" (Software Engineering) دارند، نبايد از وجود اختلاف نظر در زمينه مفهوم مهندسي نرم افزار تعجب كرد.[McC03]
نويسنده‌اي مي‌گويد:
ديدگاه ماشيني [رويكرد قائده‌مند، منظم و قابل سنجش] اين واقعيت را كه توسعه دهندگان ماهرتر خطاي كمتري مرتكب مي‌شوند و بهتر عيب يابي مي‌كنند را در نظر نمي‌گيرد. مهندسي نرم افزار باعث مي‌شود فراموش كنيم كه چيزي كه در پروژه اهميت دارد مهارت، دانش و تجربة توسعه دهندگان نرم افزار است. [McB01]
ديدگاهاي مشابه‌اي وجود دارند كه معتفد هستند كه تعريف IEEE از مهندسي نرم افزار براي پروژه‌هاي بزرگ مناسب است. عده‌اي هم در مقابل به شيوه‌هاي رسمي (Formal) اعتقاد دارند.
به نظر مي‌آيد با تعديل تعريف "مهندسي نرم افزار" و در نظر گرفتن اندازه و شرايط پروژه بتوان به نقطه مشتركي رسيد.

بدون شك تعريف مهندسي نرم افزار هرچه باشد، نهادينه كردن استفاده از روشهاي تست شده و استفاده از تجربه چند ميليون نفر ساعته ديگر فعالان عرصه مهندسي نرم افزار كار عاقلانه‌اي است. عدم رعايت اين مسئله مشكلي است كه به وضوح در بين توسعه دهندگان نرم افزار مخصوصاً در ايران ديده مي‌شود و ريشه در درك مفهموم و كاربرد مهندسي دارد.
آموزش آكادميك مي‌تواند نقش اساسي در اصلاح ديدگاه توليد كنندگان نرم افزار در مورد مهندسي نرم افزار داشته باشد.

ضعف آموزش در مراكز دانشگاهي و علمي
تصور كنيد كه دبيرستاني هستيد و تمايل داريد در آينده "مهندس نرم افزار" شويد. خوب بايد درس بخوانيد و در دانشگاه رشتة "مهندسي كامپيوتر" گرايش نرم افزار قبول شويد و بعد از چهار سال شما مهندس نرم افزار...
آرزو داشتم كه بگويم "مي‌شويد" ولي متأسفانه واقعيت چيز ديگريست. با كمال تأسف به رشتة مهندسي نرم افزار آنگونه كه بايد در دانشگاه‌ها (منظورم بيشتر كشور خودمان ايران است) پرداخته نشده است.
همانگونه كه مشاهده خواهيد كرد، دانشجو در رشتة مهندسي نرم افزار بيشتر با "علوم كامپيوتر" (Computer Science) آشنا مي‌شود تا مهندسي نرم افزار. آيا مي‌شود از اين فرد انتظار داشت با تمام شاخه‌هاي مهندسي نرم افزار آشنايي داشته باشد و آنها را بكار برد؟ اجازه دهيد كمي دقيقتر مشكلات اين رشته را در ايران مطرح كنم.

• دروس ارائه شده ديدگاه مهندسي ندارد و بيشتر به دنبال علم توليد نرم افزار است.
• واحدهاي درسي مهندسي نرم 1 و 2 در بهترين حالت مي‌تواند نمايي از مهندسي نرم افزار را ارائه دهد. بقيه درسهاي مرتبط فقط به بخش ساخت (Construction) ارتباط دارند.
• منابع درسي مهندسي نرم افزار بسيار محدود است و بيشتر كتابهاي مهندسي نرم افزار Pressman و Sommerville استفاده مي‌شوند كه كلي و غير كاربردي هستند.
• در كلاسهايي كه سعي به ارائه مطالب بروز مي‌كنند بيشتر به مباحث "مد" پرداخته مي‌شود. مانند UML و شئي گرايي يا روش شناسيهاي (Methodology) معروف، كه تنها بخش كوچكي از دانش مهندسي نرم افزار است.
• كارگاه مشخص و هدفمندي براي مهندسي نرم افزار تعريف نشده است.
  
• با احترام به تمام اساتيد محترم، متأسفانه كمتر استاد مسلط به اين حوزه وجود دارد.
  

بي شك اين نقصان با عنايت بانيان امور بايد مرتفع گردد. در آينده با ارائه سرفصلهاي مهندسي نرم افزار بيشتر در اين مورد صحبت خواهم كرد.

نتيجه؟
فقط بايد صبر كرد تا صنعت نرم افزار مانند ديگر صنايع به بلوغ برسد. از سال 1968 تا كنون پيشرفتهاي زيادي حاصل شده است ولي هنوز راه بس درازي پيش روست.

مهندسي نرم افزار؟

يك مكالمه فرضي:

- شغل شما چيست؟
- جواب: من در زمينه توليد نرم افزار فعاليت ميكنم.
- چه خوب، پس برنامه نويسي مي‌كنيد!

احتمالاً اين مكالمه براي شما نيز آشناست. عوام و بعضاً توسعه دهندگان نرم افزار نيز از توليد نرم افزار فقط برنامه نويسي آن را ميشناسند. هدف از اين مقدمه معرفي توليد نرم افزار بصورت "مهندسي نرم افزار" است.
در ادامه نيم نگاهي خواهيم داشت كه چرا هنوز براي توليد نرم افزار بصورت مهندسي دچار مشكل هستيم. توجه داشته باشيد كه بحث ما با دلايل "شكست" يا "موفقيت" پروژه‌هاي نرم افزاري متفاوت است.

بحثهاي اساسي
يكي از جدي ترين افراد در زمينة فلسفه مهندسي نرم افزار بي شك Steven McConnell است. او در كتاب متفاوت خود "Professional Software Develompment" مي‌گويد:

بهترين تصور از توسعه نرم افزار چيست؟ آيا علم است؟ يا هنر است؟ يا شايد هم يكجور مهارت باشد؟ شايد هم كلاً مقوله ديگريست؟
افرادي كه از هنري بودن برنامه نويسي دفاع مي‌كنند به جنبه‌هاي زيبايي شناسي توسعه نرم افزار اشاره مي‌نمايند و استدلال مي‌كنند كه علم، الهام و خلاقيت را به بند مي‌كشد.
كساني كه از جنبه علمي بودن دفاع مي‌كنند اشاره به ميزان بالاي خطاي برنامه‌ها دارند و ادعا مي‌كنند قابليت اطمينان تا اين حد پايين غير قابل تحمل است. هر دوي اين ديدگاها ناقصند و پرسشهاي ناسزايي مطرح مي‌كنند. توسعه نرم افزار هنر است و علم است. مهارت، باستان شناسي، آتشنشاني، روانشناسي و ديگر فعاليتها را نيز در خود جاي مي‌دهد. به تعداد افرادي كه برنامه نويسي مي‌كنند ماهيت دارد.
پرسش صحيح اين نيست كه "توسعه نرم افزار در حال حاضر چه چيزي است؟" بلكه سئوال درست اين است كه : "توسعه نرم افزار چه بايد بشود؟" به عقيده من، جواب سئوال مشخص است: توسعة حرفه‌اي نرم افزار بايد مهندسي باشد. آيا اكنون اين گونه است؟ خير ولي بي شك بايد بشود.[McC03]

هدف از نقل قول اين مطالب اين بود كه نشان دهم Steven McConnell به عنوان يكي از تأثيرگذارترين افراد در تاريخ نرم افزار به همراه تعداد كثيري از افرادي كه درحوزه ادبيات مهندسي نرم افزار فعال هستند، رأي به "مهندسي" بودن فرآيند توليد نرم افزار داده‌اند.
فكر نمي‌كنم صحبت در زمينه اثبات مناسب بودن ديدگاه "مهندسي" براي نرم افزار لازم باشد، بحثهاي مهمتري وجود دارد...

در جستجوي تعريف مناسب
حال كه پذيرفتيم "مهندسي" راه چاره توليد نرم افزار است، بهتراست تعريفي از "مهندسي نرم افزار" نيز ارائه شود.
ابتدا بهتر است به مفهوم واژه "مهندسي" اشاره كنيم:

مهندسي عبارتست از بكارگيري اصول علمي و رياضي براي مقاصد عملي[منبع ندارد]

منابع متعددي اقدام به تعريف مهندسي نرم افزار كرده اند، اجازه بدهيد تعريف IEEE كه بيشتر از بقيه مورد تأييد است[PRE01] را ذكر كنم:

اعمال يك رويكرد قائده‌مند، منظم و قابل سنجش در زمينة توسعه، بهره برداري و نگهداري نرم افزار، كه به آن كاربرد مهندسي در نرم افزار گفته ميشود.[IEE04]

اين تعريف شايد شما را از مهندسي نرم افزار فراري دهد يا اين فكر را در ذهن بياورد كه مهندسي نرم افزار منابع زيادي را بيهوده هدر مي‌دهد.
در اين زمينه Steven McConnell به صراحت بيان مي‌كند كه:

برخي تصور مي‌كنند ديدگاه مهندسي نسبت به توسعة نرم افزار به منزله استفاده از روشهاي سختگيرانه – نوشتن برنامه همانند اثبات رياضي – مي‌باشد. عقل و تجربه نشان داده است كه انجام اين كار براي اكثر پروژه‌ها، زياده روي است. برخي نيز برخلاف گروه اول اعتقاد دارند كه نرم افزار تجاري آنقدر از تغيير شرايط بازار تحت تأثير قرار مي‌گيرد كه نمي‌توان مهندسي دقيق و زمانبري بر روي آن اجرا نمود.
اين استدلالهاي متناقض، بر اساس ديد محدود و اشتباه از مهندسي بنا نهاده شده است. مهندسي كاربرد قوانين علمي در راستاي اهداف عملي است. اگر مهندسي كاربردي نباشد، مهندسي خوبي نيست. ايدة اعمال روشهاي سختگيرانه به همه پروژه‌هاي نرم افزاري به اندازه استفاده از روش ساخت و ترميم (Build and Fix) مضر است. [McC03]

در واقع پروژه شما در هر ابعاد و اندازه‌اي كه باشد مي‌تواند از "مهندسي" سود ببرد، به اين شرط كه روشهاي موجود را شناخته و از آنها با توجه به مشخصات پروژه سود ببريد.

در بخش بعدي مشكلات مهندسي شدن نرم افزار را بررسي مي‌كنيم.

مشاهير

در اين قسمت به معرفي افرادي كه در مطالب وبلاگ نام برده مي‌شوند، مي‌پردازم. اين فهرست نيز به مرور تكميل مي‌شود.

Steven McConnell - نويسنده و مؤلف كتابهاي متعددي از جمله Code Complete, Rapid Development و Software Estimation مي‌باشد. در مورد اين كارشناس ارشد مهندسي نرم افزار از دانشگاه سياتل همين بس كه در كنار Bill Gates و Linus Torvalds به عنوان تأثيرگذارترين افراد در صنعت نرم افزار ياد مي‌شود [Software Development magazine]. اكنون او مدير عامل و مهندس ارشد در شركت Construx Software مي‌باشد. براي اطلاعات بيشتر به سايت شخصي او مراجعه كنيد.