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

[Admin]

<b>

مفاهيم مديريت پروژه
Project Management Concepts

فهرست:

مقدمه ای بر مديريت پروژه نرم افزار

مولفه های مديريت پروژه در نرم افزار

اصل WWWWWHH

-----------------------------------------------

مقدمه ای بر مديريت پروژه نرم افزاری:

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

تعريف مديريت پروژه (Pressman) :
مديريت پروژه شامل برنامه ريزی ، نظارت وکنترل افراد ، فرايند و رخدادهايي می باشد که در طول تکامل نرم افزار از مفهومی اوليه به يک پياده سازی عملياتی منجر می گردد.


تعريف مديريت پروژه (Rational) :
مديريت پروژه نرم افزاری هنر برقراری موازنه ميان اهداف گوناگون ، مديريت ريسک و غلبه بر محدوديتها برای تحويل موفقيت آميز محصولی می باشد که نيازمنديهای مشتريان (حاميان مالی پروژه) و کاربران را برآورده نمايد.

مولفه های مديريت پروژه نرم افزاری:

افراد ---- People

محصول ---- Product

فرايند ---- Process

پروژه ---- Project

افراد:

در مطالعه ای که توسط IEEE انجام پذيرفت ، مهمترين عامل موفقيت پروژه نرم افزاری افراد حاضر در پروژه می باشند.

افراد حاضر در پروژه به پنج دسته تقسيم بندی می گردند:
مديران ارشد
مديران پروژه (فنی)
مجريان
مشتری ها
کاربران نهايي

چگونگی تعامل افراد در تيمهای مهندسی نرم افزاری:

چهار روش سازمانی توسط Constantine جهت تيمهای مهندسی نرم افزار پيشنهاد گرديده است :

روش بسته

روش تصادفی

روش باز

روش همزمان

محصول:

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

تجزيه مسئله : با تشخيص محدوده نرم افزار جهت سهولت در ايجاد محصول اقدام به تجزيه آن می نماييم.

پروژه:

ده عامل مخاطره آميز در پروژه های نرم افزاری از ديدگاه John Reel عبارتند از :

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

اصل WWWWWHH:

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

Why is the system being developed?

چه چيزی در چه موقع انجام شود؟

What will be done, by When?

چه شخصی مسئول چه کاری می باشد؟

Who is responsible for a function?

از لحاظ سازمانی در کجا قرار دارند؟

Where are they organizationally located?

از لحاظ تکنيکی و مديريتی کار چگونه انجام می شود؟

How will the job be done technically and managerially?

از هر منبع چه ميزان مورد نياز است؟

How much of each resource is needed?

</b>

[Admin]

مهندسی سيستم

System Engineering

فهرست:

تعريف سيستم
سلسله مراتب مهندسی سيستم
مهندسی فرايند کاری
مهندسی و مديريت نيازها
مدلسازی سيستم
معماری سازمانی و متدولوژی سازمانی

[Admin]

مقدمه:

مهندسی نرم افزار در نتيجه فرايندی بنام مهندسی سيستم ايجاد می گردد.

مهندسی سيستم(ديدگاه پرسمن) :
مهندسی فرايند کاری (Business Process Engineering) :
چنانچه محدوده کار مهندسی تمرکز بر روی کار و تجارت داشته باشد ، مهندسی سيستم را مهندسی فرايند کاری می نامند.
مهندسی محصول ( Product Engineering) :
زمانی که محصولی ايجاد می گردد، فرايند مهندسی سيستم را مهندسی محصول می ناميم .

پيش از آنکه فرايند مهندسی جهت نرم افزار انجام گردد ، سيستمی که نرم افزار در آن قرار دارد بايستی درک شود .

سيستم چيست؟
فرهنگ لغت Webster's سيستم را اينچنين تعريف می نمايد (دو تعريف از نه تعريف)
مجموعه يا ترتيبی از عناصر مرتبط جهت تشکيل يک واحد يکپارچه يا متحد
مجموعه ای از حقايق ، اصول ، قوانين و موارد نظير آن که دسته بندی و مرتب گرديده اند تا طرحی منطقی جهت اتصال اجزا گوناگون را نمايش دهد.


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

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

سلسله مراتب مهندسی سيستم

همانگونه که ملاحظه می شود مهندسی سيستم هرچه به سمت پائين سلسله مراتب حرکت می نمايد ، تمرکز کاری باريکتر می گردد.

[Admin]

مهندسی فرايند کاری (BPE):

هدف از اين مهندسی تعريف معماريهايي می باشد که باعث می گردد، يک حرفه از اطلاعات بصورت کارآمد استفاده نمايد.

جهت حصول ديدگاه کلی از نيازهای تکنولوژی يک شرکت، از مهندسی سيستم استفاده می نماييم. برای اين منظور سه معماری مختلف می بايست در حيطه اهداف کاری تحليل و طراحی گردد:
معماری داده (Data Architecture)

معماری کاربردها (Applications Architecture)

زيربنای تکنولوژی (Technology Infrastructure)

توصيه پرسمن : مهندس نرم افزار در مباحث ISP و BAA وارد نمی گردد ، ليکن در صورت عدم انجام چنين فعاليتهائی ، مسئولان را از بالا بودن ريسک پروژه آگاه نماييد.

BAA همانند ISP ، اشيا داده ، روابط ميان آنها و چگونگی جريان داده را تعريف می نمايد . ليکن در چنين سطحی اين خصوصيات همگی در چارچوب زمينه کاری تحليل شده محدود می گردند.

خروجی BAA جدا نمودن زمينه هايي است که سيستم های اطلاعاتی در آنها می توانند زمينه کاری را حمايت نمايند.

مهندسی نيازها:

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

فرايند مهندسی نيازها شامل شش مرحله می باشد :
بيان نيازمنديها
تحليل نيازها و انجام مذاکره
مشخصه نيازها
مدلسازی سيستم
تصديق نيازها
مديريت نيازها

مديريت نيازها :

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

مثال: F09 مبين نياز تابعی با شماره 9
توسعه جداول رديابی پس از مشخص شدن نيازها صورت می پذيرد . اين جداول نيازهای مشخص گرديده را با يک يا چند جنبه از محيط يا سيستم ارتباط می دهد :

[Admin]

جداول رديابی:

جدول رديابی ويژگيها : مبين آن است که چگونه نيازها با ويژگيهای قابل اهميت از لحاظ مشتری يا محصول در ارتباط است .

جدول رديابی مبدا : مبدا هر نياز را تعيين می نمايد .

جدول رديابی وابستگی : چگونگی ارتباط نيازها به يکديگر را بيان می نمايد.

جدول رديابی زيرسيستم : نيازها را با توجه به زير سيستمهای مختلف دسته بندی می نمايد .

مدلسازی سيستم:

نمودار زمينه سيستم (System Context Diagram)

نمودار جريان سيستم (System Flow Diagram)

نمودار زمينه سيستم :

اين نمودار مرز اطلاعات ميان سيستم در حال ساخت و محيطی که سيستم در آن عمل می نمايد را مشخص می نمايد.

نمودار جريان سيستم:

نمودار جريان سيستم ، زيرسيستمهای اصلی و خطوط جريانهای اطلاعاتی مهم ( کنترل و داده) را نمايش می دهد .

در SFD اصلی هر کدام از چهار ضلعيها با گوشه های گردشده می تواند به الگوی معماری ديگری توسعه يابد.

[Admin]

معماری سازمانی و متدلوژی سازمانی

چارچوبهاي معماري سازمان:

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

- معمولا هر چارچوب مدلهاي مناسب براي توصيفهاي هر سلول را نيز پيشنهاد مي كند.

لینک تصویر



چارچوبهاي معماري در مقايسه با متدولوژي ها:

* متدلوژي ها نشان دهنده يك حركت در روي چارچوب هستند ، بعنوان مثال :
- خط پررنگ يك متدولوژي فرايند محور نظير روش Clive Finkelstein را نشان مي دهد .
- خط نقطه چين يك متدلوژي داده محور نظير جيمز مارتين را نشان مي دهد .
* سيستمهای اطلاعاتی خروجی متدلوژی های سازمانی می باشند.

[Admin]

مدلسازی تحليل

Analysis Modeling

فهرست:

- مقدمه
- اهداف مدل تحليل
- ساختار مدل تحليل
- مدل نمودن نيازهای داده ای
- مدل نمودن نيازهای عملياتی

-------------------------------------------------------------------------------

انواع مدلسازی تحليلی:


- تحليل ساخت يافته

- تحليل شی گرا

مدلسازی تحليل:



مزايا :
فهم آسانتر نيازها + تسريع در بازنگری نيازها جهت کامل بودن ، سازگاری و درستی آنها

اهداف مدل تحليل:

- توصيف نيازهای مشتری

- خلق مبنايي جهت ايجاد طراحی نرم افزار

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

ساختار مدل تحليل:



فرهنگ داده ها:

فرهنگ داده ها شامل توصيفی از کليه اشيای داده ای است که توسط نرم افزار توليد يا مصرف می گردد.

مدلسازی داده ها:

* روشهای متعددی جهت مدلسازی داده ها تاکنون مطرح گرديده است :

- نمودار موجوديت- رابطه ERD

- نمودار NIAM

- مدلسازی توسط UML (استفاده از نمودار کلاس)

* در تحليل ساخت يافته عموما از روشERD استفاده می گردد.

* مدلسازی داده برخلاف DFD، داده ها را مستقل از پردازشی که آنها را تغيير می دهد در نظر می گيرد.

مرورری بر مدلسازی داده ها توسط ERD:

عناصر ERD :
- موجوديت
- روابط

[Admin]

کارديناليتی(cardinality):


کارديناليتی : حداکثر تعداد روابط اشيائی است که می توانند در يک رابطه شرکت نمايند.

انواع کارديناليتی :
يک به يک (1:1)
يک به چند (N : 1)
چند به چند (N : N)

مداليتی (modality) :

مداليتی مبين اجباری يا اختياری بودن رابطه است.



نمودار جريان داده(DFD):

دو هدف اصلی DFD عبارتند از :

ايجاد نمايشی از چگونگی تبديل داده ها در طول حرکت در سيستم

نمايش عملياتی که جريان داده ها را متحول می سازد

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

DFD سطح صفر که به آن ” مدل بنيادی سيستم“ نيز گفته می شود ، نرم افزار را با يک حباب مشخص نموده و دارای دوپيکان جهت ورودی و خروجی می باشد. با افراز حبابهای سطوح بالاتر ، می توان جزييات بيشتری را به تصوير کشيد.



افراز جريان داده:



مشخصات پردازش:

جهت مشخص نمودن جزييات پردازش مربوط به يک حباب از PSpec. استفاده می نماييم.

[Admin]

اصول و مفاهيم طراحی

Design Concepts and Principles

فهرست:

مقدمه

اهميت طراحی

روشهای طراحی

مفاهيم طراحی

------------------------------------------------------------

اصول و مفاهيم طراحی:

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

اهميت طراحی:

امروزه سخت افزار سريعتر ، ارزانتر و قابل اطمينان تر در دسترس می باشد



افزايش تقاضا برای نرم افزارهای پيچيده



احساس نياز به روشهای تحليل و طراحی





درصد هزينه های نرم افزار در مقابل هزينه های سخت افزار از سال 1955 الی 1985

[Admin]

فرايند طراحی:

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


کيفيت نرم افزار و طراحی:

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

مروری بر روشهای اصلی طراحی:

طراحی مبتنی بر فرايند (Process Driven Design)
تمرکز بر روی فرايندهای سيستم
سيستم نرم افزاری بصورت مجموعه ای متوالی از توابع ترسيم می گردد.
طراحی مبتنی بر داده ها (Data Driven Design)
تمرکز بر روی داده ها
Input Output
مناسب جهت سيستمهای اطلاعاتی
طراحی شی گرا (Object Oriented Design)

اصول طراحی:


* طراحی نرم افزار:

1. فرايند : يک سری از مراحل که طراح را قادر به توصيف تمام جنبه های نرم افزار می نمايد.
2. مدل : از کلان آغاز گرديده و به مرور پس از پالايش به سطوح پائين تر تجريد می پردازد. مدل طراحی چند ديدگاه متفاوت از نرم افزار را نمايش می دهد.

* کيفيت نرم افزار:

1. عوامل خارجی : کاربران به راحتی امکان مشاهده آن را دارند (مانند قابليت اعتماد، سرعت ، قابليت استفاده ، صحت و موارد نظير آن)
2. عوامل داخلی : عاملهائی که باعث افزايش کيفيت طراحی می گردند (مفاهيم طراحی)

مفاهيم طراحی:

تجريد --- Abstraction
پالايش --- Refinement
واحدبندی --- Modularity
معماری نرم افزار --- Software Architecture
سلسله مراتب کنترلی --- Control Hierarchy
ساختمان داده --- Data Structure
پنهان سازی اطلاعات --- Information Hiding
روند نرم افزار --- Software Procedure