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

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

مهندسی نرم افزار، تقریبا یک نظام جوان است. نظریه “مهندسی نرم افزار” در سال 1968 در کنفرانسی تحت عنوان “بحران نرم افزار” مطرح شد. در آن زمان بحران نرم افزار ناشی از معرفی نسل سوم سخت افزار کامپیوتر بود که قدرت فوق العاده ای داشت. قدرت آنها منجر به این شد که برنامه های کاربردی که تا آن زمان غیرممکن به نظر می رسیدند، امکان پذیر شوند. نرم افزارهای حاصل نسبت به سیستم های نرم افزاری قبلی پیچیده تر و بزرگتر بودند. تجربیات اولیه در ساخت این سیستم ها نشان داد که رهیافت غیررسمی برای توسعه نرم افزار به اندازه کافی خوب نبوده است. انجام پروژه های بزرگ، سال ها طول می کشید. هزینه آنها بیش از هزینه پیش بینی شده بود، قابل اعتماد نبودند، نگهداری آنها دشوار و کارایی آنها اندک بود. توسعه نرم افزار در بحران به سر می برد. هزینه های سخت افزار در حال کاهش و هزینه های نرم افزار به سرعت در حال افزایش بود. تکنیک ها و روش های جدیدی نیاز بود تا پیچیدگی ناشی از سیستم های نرم افزاری بزرگ را کنترل کند.
این تکنیک ها به عنوان بخشی از مهندسی نرم افزار محسوب می شدند، گرچه امروزه استفاده همگانی ندارند. به هر حال، هنوز در ساخت نرم افزارهایی که خواسته های کاربر را برآورده کند، به موقع تحویل داده شوند و با بودجه پیش بینی شده خاتمه یابند، مشکلاتی وجود دارد. بسیاری از پروژه های نرم افزاری هنوز دارای مشکلاتی هستند و این موضوع منجر به این شد که بعضی از مفسران (پرسمن 1997) گوشزد کنند که مهندسی نرم افزار در حالت وخیمی به سر می برد.
با افزایش توانایی ما در تولید نرم افزار، برپیچیدگی های نرم افزار فائق می آییم. فناوری های ناشی از همگرایی سیستم های کامپیوتری و ارتباطی، تقاضای جدیدی را در مهندسی نرم افزار مطرح کرده است. به همین دلیل و با توجه به این که اغلب موسسات تکنیک های مهندسی نرم افزار را به خوبی به کار نمی گیرند، هنوز مشکلاتی وجود دارد، اما امیدی برای بهبود این وضعیت وجود دارد.
از سال 1967 در زمینه مهندسی نرم افزار پیشرفت زیادی کردیم و از آن زمان توسعه مهندسی نرم افزار، در نرم افزارها تاثیر بسزایی داشته است. درک بهتری از فعالیت های موجود در توسعه نرم افزار پیدا کردیم. روش های موثری برای تعیین مشخصات، طراحی و پیاده سازی نرم افزار ارائه شده است. نشانه گذاری ها و ابزارهای جدید، از تلاش مورد نیاز برای تولید سیستم های نرم افزاری بزرگ و پیچیده کاسته اند.
مهندسین نرم افزار می توانند به موفقیت های خود افتخار کنند. بدون نرم افزارهای پیچیده، فضای تحقیق نخواهیم داشت، از اینترنت و ارتباطات راه دور بی بهره خواهیم بود، و تمام مسافرت ها خطرناک و گران خواهند بود. مهندسی نرم افزار در طول عمر کوتاهش اثرات زیادی روی زندگی تمام انسان ها گذاشته است.
مهندسین نرم افزار فقط با فرآیندهای تکنیکی توسعه نرم افزار سر و کار ندارند، بلکه با فعالیت هایی مثل مدیریت پروژه نرم افزاری و توسعه ابزارها، روش ها و تئوری هایی برای پشتیبانی محصول نرم افزاری سر و کار دارند. به طور کلی مهندسین نرم افزار یک روش نظام مند و سازمان یافته را در کارشان پذیرفته و این روش موثری برای تولید نرم افزار با کیفیت است. اما مهندسی به انتخاب مناسب ترین روش در مجموعه ای از پدیده ها سر و کار دارد، و در بعضی از پدیده ها نیاز به رهیافت خلاق و غیر رسمی است.

(آخرین ویرایش در این ارسال: ۲۱-۹-۱۳۸۹ ۰۱:۳۸ صبح، توسط as@l.)

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

مهندسی نرم افزار، تقریبا یک نظام جوان است. نظریه “مهندسی نرم افزار” در سال 1968 در کنفرانسی تحت عنوان “بحران نرم افزار” مطرح شد. در آن زمان بحران نرم افزار ناشی از معرفی نسل سوم سخت افزار کامپیوتر بود که قدرت فوق العاده ای داشت. قدرت آنها منجر به این شد که برنامه های کاربردی که تا آن زمان غیرممکن به نظر می رسیدند، امکان پذیر شوند. نرم افزارهای حاصل نسبت به سیستم های نرم افزاری قبلی پیچیده تر و بزرگتر بودند. تجربیات اولیه در ساخت این سیستم ها نشان داد که رهیافت غیررسمی برای توسعه نرم افزار به اندازه کافی خوب نبوده است. انجام پروژه های بزرگ، سال ها طول می کشید. هزینه آنها بیش از هزینه پیش بینی شده بود، قابل اعتماد نبودند، نگهداری آنها دشوار و کارایی آنها اندک بود. توسعه نرم افزار در بحران به سر می برد. هزینه های سخت افزار در حال کاهش و هزینه های نرم افزار به سرعت در حال افزایش بود. تکنیک ها و روش های جدیدی نیاز بود تا پیچیدگی ناشی از سیستم های نرم افزاری بزرگ را کنترل کند.
این تکنیک ها به عنوان بخشی از مهندسی نرم افزار محسوب می شدند، گرچه امروزه استفاده همگانی ندارند. به هر حال، هنوز در ساخت نرم افزارهایی که خواسته های کاربر را برآورده کند، به موقع تحویل داده شوند و با بودجه پیش بینی شده خاتمه یابند، مشکلاتی وجود دارد. بسیاری از پروژه های نرم افزاری هنوز دارای مشکلاتی هستند و این موضوع منجر به این شد که بعضی از مفسران (پرسمن 1997) گوشزد کنند که مهندسی نرم افزار در حالت وخیمی به سر می برد.
با افزایش توانایی ما در تولید نرم افزار، برپیچیدگی های نرم افزار فائق می آییم. فناوری های ناشی از همگرایی سیستم های کامپیوتری و ارتباطی، تقاضای جدیدی را در مهندسی نرم افزار مطرح کرده است. به همین دلیل و با توجه به این که اغلب موسسات تکنیک های مهندسی نرم افزار را به خوبی به کار نمی گیرند، هنوز مشکلاتی وجود دارد، اما امیدی برای بهبود این وضعیت وجود دارد.
از سال 1967 در زمینه مهندسی نرم افزار پیشرفت زیادی کردیم و از آن زمان توسعه مهندسی نرم افزار، در نرم افزارها تاثیر بسزایی داشته است. درک بهتری از فعالیت های موجود در توسعه نرم افزار پیدا کردیم. روش های موثری برای تعیین مشخصات، طراحی و پیاده سازی نرم افزار ارائه شده است. نشانه گذاری ها و ابزارهای جدید، از تلاش مورد نیاز برای تولید سیستم های نرم افزاری بزرگ و پیچیده کاسته اند.
مهندسین نرم افزار می توانند به موفقیت های خود افتخار کنند. بدون نرم افزارهای پیچیده، فضای تحقیق نخواهیم داشت، از اینترنت و ارتباطات راه دور بی بهره خواهیم بود، و تمام مسافرت ها خطرناک و گران خواهند بود. مهندسی نرم افزار در طول عمر کوتاهش اثرات زیادی روی زندگی تمام انسان ها گذاشته است.
مهندسین نرم افزار فقط با فرآیندهای تکنیکی توسعه نرم افزار سر و کار ندارند، بلکه با فعالیت هایی مثل مدیریت پروژه نرم افزاری و توسعه ابزارها، روش ها و تئوری هایی برای پشتیبانی محصول نرم افزاری سر و کار دارند. به طور کلی مهندسین نرم افزار یک روش نظام مند و سازمان یافته را در کارشان پذیرفته و این روش موثری برای تولید نرم افزار با کیفیت است. اما مهندسی به انتخاب مناسب ترین روش در مجموعه ای از پدیده ها سر و کار دارد، و در بعضی از پدیده ها نیاز به رهیافت خلاق و غیر رسمی است.

تعيين سياستها و استراتژيهاي سازمانهاي وابسته به فن آوري اطلاعات
مديريت پروژه هاي كلان نرم افزاري
• تعريف پروژه و مشخصات پروژه
• تدوين سازمان كار و پروتكل هاي ارتباطي بين اركان پروژه
برنامه ريزي و كنترل پروژه هاي كلان نرم افزاري
برآورد هزينه و تخمين هزينه در مراحل مختلف توليد نرم افزار

سيستمهاي جامع عملياتي و پشتيباني
سيستمهاي اطلاعات مديريت ( MIS )
سيستمهاي پشتيبانی تصميم گيری مديران (DSS )
سيستمهاي برنامه ريزي استراتژيك
بهبود سيستمهای موجود با توجه به تکنولوژی روز
بهبود فرآيندهای سازمان
مهندسی مجدد فرآيندهای سازمان
مهندسی و تحقيق وتوسعــــه
ارائه خدمات فني و مهندسی مرتبط با پروژه هاي نرم افزاري
• متدولوژي و استانداردهاي توليد نرم افزار
• بانکهای اطلاعاتی
• سيستمهای عامل
• زبانهای برنامه سازی
• معماري فني نرم افزار
• كتابخانه هاي نرم افزاري
• ابزارهاي نظارت برتوليد نرم افزار
ارائه آموزش هاي تخصصي و عمومي به صورت برگزاري سمينارهاي تخصصي و
كارگاه هاي توجيهي مرتبط پشتيباني فنی محصولات نرم افزاري تخصصی پايه
(Oracle, Rational, ...)
نظارت و كيفيـــــــــــت
تدوين رويه هاي نظارتي
تدوين شاخص ها و معيارهاي ارزيابي گروه هاي درگير در توليد فرآورده نرم افزاري
انجام ارزيابي هاي دوره اي ازعملكرد گروه هاي درگير در توليد نرم افزار
تعيين شاخص هاي كيفي فرآورده هاي نرم افزاري
مميزی، بازبينی و بازرسی های دوره ای در مراحل توليد نرم افزار در قالب :
• فرآيند توليد فرآورده (با ديدگاه تضمين کيفيت)
• فرآورده توليدی (با ديدگاه کنترل کيفيت)
نظارت بر اجرای کليه مصوبات پروژه در قالب استانداردها و روشها و ابلاغيه ها
تحويل فرآورده ها و اجرای آزمون پذيرش نرم افزار
برنامه ريزي و كنترل پروژه
برنامه ريزي اوليه ، كنترل و به روز رساني برنامه ها و پروژه ها
تهيه گزارشات پيشرفت و مديريتي پروژه بصورت دوره اي به كمك نرم افزار MSP
تهيه گزارشات مختلف بر پايه فعاليت ، منبع و هزينه پروژه در دوره هاي زماني مختلف
كنترل پروژه هاي داخلي
مديريت برنامه ريزي و تهيه گزارشات بهره وري و عملكردي با استفاده از نرم افزار مديريت برنامه كاري
پشتيبانی و اجـــــــرا
مديريت نصب و استقرار سيستمهای اطلاعاتی
پشتيبانی و نگهداری سيستمهای اطلاعاتی
• خطايابی و شناسايي نيازمندی جديد
• پيگيری رفع خطا و تامين نيازمندی جديد
• نصب و بروزرسانی نرم افزار
آموزش و راهبری سيستمهای اطلاعاتی حين اجرا

(آخرین ویرایش در این ارسال: ۱۲-۹-۱۳۸۹ ۰۷:۰۳ صبح، توسط as@l.)

محيط اجراي نرم افزار :
Windows،Linux

متدولوژي ايجاد نرم افزار :
CDM،RUP

بانك اطلاعاتي :
Oracle،Sql

ابزارهاي پياده سازي :
JBuilder
Developer 2000


Case Tools :
Rose
Struts
HeadStart
Designer 2000

معماري سيستمهاي جامع :
Client / Server
WebBase

در رادمان براي جلب مشتري استراتژي جالبي بکار مي بريم و آن اينست که کار ها را در زمان بسيار کوتاه تري نسبت به آنچيزي که مشتري توقع دارد پروژه را به اتمام مي رسانيم ، بدين تيب که براي يک پروژه مفروض به مشتري زمان معمول توليد سيستم را اعلام مي کنيم. مثلا براي يک پروژه کوچک يک ماه زمان در نظر مي گيريم که زمان منطقي است، اما پروژه را ظرف يک هفته تحويل مي دهيم! و مشتري را شگفت زده مي کنيم! چطور اينکار را انجام مي دهيم جزء اسرار است! هر چند در متن زير اين اسرار برملا مي شود!!

پيشتر درهنگام توسعه سيستمهاي نرم افزاري با استفاده از روشهاي ساخت يافته، مديران پروژه ها براي تخمين زمان وهزينه توليد يک سيستم قبل از آغاز آن از روشهاي مختلفي استفاده مي کردند.
از مهمترين روشهاي تخمين در آن زمان استفاده از تجربيات گذشته در سيستمهاي مشابه و يا تخمين تعداد خطوط برنامه و يا تعداد عملکردهاي متفاوت سيستم ميباشد.
بدين معني که يک برنامه ساز زماني که مي خواهد در آغاز پروژه زمان و هزينه لازم را برآورد کند براي مثال در يک جستجو در تجربيات خود يک نمونه نزديک براي سيستم جديد پيدا مي کند. براي مثال در فلان سيستم دو ماه کار توسط يک گروه 2 نفره صورت گرفته است (به عبارتي 4 نفر-ماه) و چون پروژه جديد هم شبيه اين تجربه مي باشد همين حدود زمان براي توسعه سيستم نياز است و يا چون مثلا يک کم از آن بزرگتر است يک مقدار اضافه تر. گاهي هم بر اساس تخمين تعداد خطوط عمل مي شد. براي مثال برنامه ساز محاسبه مي کرد براي ايجاد سيستم نگارش حدودا 10.000 خط برنامه لازم است پس حجم پروژه معلوم است و بر اساس اينکه يک برنامه نويس در روز چند خط برنامه توليد مي کند (انگار کار برنامه نويسي پارچه بافي است که با يک معيار کمي آن را اندازه گيري مي کنيم!) کل زمان بدست بيايد. به همين شکل براي عملکرد ها هم عمل مي شد. و با شمارش تعداد عملکرد (Function) هاي اصلي و فرعي سيستم حدود سيستم تخمين زده مي شد.
با توسعه روشهاي مهندسي نرم افزار و مطرح شدن مفاهيم شيء گرايي (Object Oriented Concept) در مهندسي نرم افزار بالطبع معيارها و متريک ها نيز متفاوت شد. در شيء گرايي با تکيه بر استفاده مجدد يا بازکارآيندگي (Reuseability) از يکسو فرآيند توليد نرم افزار سريعتر گرديد و از سوي ديگر معيارهايي نظير تعداد خطوط کارائي نداشت. چون ديگر در اينجا با نمونه سازي از اشياء و يا با استفاده از وراثت و يا چند ريختي نه تنها مي توان از يک کد نوشته شده در قالب يک شيء مي توان بارها استفاده کرد بلکه با گسترش يک کد در کلاسهاي ارث گرفته شده حجم کد نويسي مجدد را کاهش داد.
به همين منظور در روشهاي شيء گرايي با استفاده از شمارش تعداد کلاس هاي کليدي (Key Class) و کليد هاي کمکي يا پشتيبان (Support Class) يک تخمين نسبت به حجم کلي سيستم بدست مي آيد.
در روشهاي ديگر با شمارش سناريو هاي کاري و يا شمارش زيرسيستمهاي سيستم هدف و با بهره گيري از تجربيات گذشته به يک روش نيمه فرمال براي تخمين زماني و مالي پروژه استفاده مي نمايند. اين روشها تخمين بهتري براي زمان و هزينه مالي پروژه به دست مي دهند.
نکته حائز اهميت اينکه هر چند اين روشها تخمين خوبي براي روشهاي شيء گرا هستند اما با مطرح شدن روشهاي جديد مهندسي نرم افزار از جمله روش توسعه نرم افزار مبتني بر مؤلفه ها (CBSD: Component Based Software Development) بايستي در اين معيار ها اصلاحاتي به وجود بيايد و تغييرات عمدهاي صورت گيرد.
با استفاده از مؤلفه ها (Components) و چارچوب هاي (Frames) مناسب براي يک پروژه مي توان زمان توليد نرم افزار را به طور چشمگيري کاهش داد. در نتيجه در تخمين زدن مي توان با توجه به مولفه ها و چارچوب هاي موجود در کتابخانه توليدي عمل کرد. هر چقدر اجزاء سيستم جديد با استفاده از ابزارهاي موجود بيشتر قابل توسعه باشند مي توان پروژه را سريعتر توسعه داد.

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

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