طراحان آینده

این وبلاگ جهت نمابش پروژه های درس مهندسی نرم افزار طراحی شده است.

به وبلاگ ما خوش آمدید!

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

بنابراین با توجه به ارزش روزافزون زمان و زمانبندی بر آن شدیم تا با ارائه نرم افزاری کاربردی نقشی ارزنده در عرصه تکنولوژی ایفا نماییم.

 

نویسندگان: زینب بذر افکن، الهام راسخ، معصومه رشیدی، فاطمه تلگردی

+ نوشته شده در  ساعت   توسط الهام راسخ  | 

استراتژی های آزمایش نرم افزار

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

  1. تست واحد (Unit testing)
  2. تست مجتمع سازی  (Integration Testing)
  3. تست سیستم (System Testing)
  4. تست پذیرش (Acceptance Testing)

تست واحد:

 

تست واحد (Unit testing) :

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

 

هدف و فلسفه تست واحد:

ما از تست واحد استفاده می کنیم تا نشان دهیم که واحد مورد نظر کاری را که ما فکر می کنم انجام می دهد یا نه.

 

مزایا و منافع:

1- تست های واحد همانند یک سند اجرایی هستند که نشان می دهند شما انتظار دارید که کد نوشته شده در شرایط مختلف چگونه عمل کند. اعضای تیم می توانند برای درک عملکرد کد و اینکه چگونه آن را بکار ببرند به تست های واحد مراجعه کنند.

تست های واحد مستنداتی هستند که با تغییر و اصلاح کد بروز رسانی می شوند.

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

2- به اشتراک گذاری کد با دیگران راحتتر است، چون اگر عضوی از تیم کد را طوری دستکاری کنید که درست کار نکند، اجرای تست ها با شکست روبرو می شود.

3- با انجام تست های واحد، زمان انجام تست ها در سایر فازها کاهش می یابد.

4- تست ها، انتظارات برنامه نویس را در مورد چگونگی عمل کردن یک قطعه کد، ارزیابی می کنند.

 

تست مجتمع سازی  (Integration Testing) :

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

تست سیستم (System Testing) :

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

 

تست امنیت (Security Testing):

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

 

تست بازیابی (Recovery Testing):

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

و ...

 

تست پذیرش:

Unit تست‌ها در حقيقت ابزاري ضروري براي تست كردن سيستم به شمار مي‌روند، ولي كارايي خوبي ندارند؛ زيرا نمي‌توانند صحت كارايي كل سيستم را تضمين نمايند. Unit Testها در واقع تست‌هاي جعبه سفيد (White box)  هستند كه در آن تنها مكانيزمي خاص در سيستم چك مي‌گردد. براي اين‌كه بتوانيم نيازهاي كاربران سيستم خود را چك كنيم، به تست Black box يا Acceptance Test نياز داريم. اين تست‌ها نيازهاي كاربران را در قسمت‌هايي از برنامه چك مي‌كنند و ما را از اين‌كه نياز كاربران از سيستم بر آورده شده است يا خير، مطلع مي‌كنند. اين تست‌ها معمولاً توسط كساني نوشته مي‌شوند كه هيچ اطلاعاتي از مكانيزم سيستم و اجزاي داخلي آن ندارند و معمولاً توسط كاربران سيستم تهيه مي‌شوند Acceptance Testها برنامه‌هايي هستند كه حتي مي‌توان آن‌ها را اجرا نمود و اغلب با استفاده از Scripting Languageها نوشته مي‌شوند. 

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

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

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

 

+ نوشته شده در  ساعت   توسط الهام راسخ  | 

تکنیک های آزمایش نرم افزار

خروجی این مرحله، مشخصه تست است.

در پیاده سازی باید به گونه ای عمل کنیم که کد به راحتی قابل تست باشد، برای این منظور باید:

1) کدها عملیاتی باشند.

2) هیچ اشکالی اجرای آزمایش را قطع نکند.

3) در هر مرحله خروجی قابل مشاهده وجود داشته باشد.

4) قابلیت مشاهده حالت های مختلف سیستم.

5) تشخیص خطاهای داخلی.

 

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

ویژگی های تست خوب

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

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

2) تست بیش از حد انجام  نشود.

3) آزمایش ها هوشمندانه باشند.

 

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

اصول آزمایش

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

در هر گام می توان تست آن مرحله را انجام داد، لازم نیست حتما پس از مرحله پیاده سازی تست را انجام دهیم.

تست کامل هیچگاه انجام نمی شود.

آزمایش همیشه از جزئیات (مؤلفه ها) آغاز و به کلیات می انجامد.

 

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

انواع روش های تست

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

1) جعبه سفید: تست رویه برنامه

2) جعبه سیاه: تست  نرم افزار بدون توجه به کد آن

 

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

 استراتژی تست نرم افزار

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

1) تست مؤلفه: در این گام با استفاده از تست جعبه سفید پیاده سازی را تست می کنیم.  

2) تست مجتمع سازی: در این گام با استفاده از تست جعبه سفید و جعبه سیاه طراحی نرم افزار را تست می کنیم.  

3) تست اعتبار سنجی: در این گام با استفاده از تست جعبه سیاه تحلیل نرم افزار را تست می کنیم.  

 با توجه به نیاز ها و محدودیت های تعیین شده در گام  تحلیل ( عملکرد، کارایی، رفتار و محدودیت ) هریک را تست می کنیم .

4) تست سیستم: در سطح مهندسی سیستم از تست جعبه سیاه استفاده می شود.

 

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

 تست جعبه سفید

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

1) بررسی  ساختمان داده محلی

2) بررسی شرط های موجود

3) بررسی مسیر های کنترل

 

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

آزمایش شرط ها

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

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

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

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

برای تعیین تعداد مسیر های مبنا 4 روش مختلف وجود دارد:

1) محاسبه پیچیدگی دورانی: تعداد ناحیه های گراف جریان را محاسبه می کنیم.

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

 3) استفاده از فرمول E-N+2  که (E تعداد یال ها و N تعداد گره ها)

 ۴) ایجاد ماتریس گراف

 

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

 آزمایش ساختار های کنترل

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

 ساختار های کنترلی، پرانتز گذاری ها، عملگر های محاسباتی و ... را بررسی می کنیم.

 

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

 آزمایش جریان داده ها

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

Define use تعیین می کند که یک منغیر خاص در چه شماره دستوری تعریف و در چه شماره دستوری استفاده شده است.

 

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

آزمایش حلقه ها

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

حلقه ها را بررسی می کنیم.

شرایط ممکن و قابل بررسی برای حلقه:

1) اجرا نشدن

2) فقط یک گذر در حلقه

3) دو گذر

4) N-1 گذر

5) N  گذر

6) N/2  گذر

7) N+1 گذر

 

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

انواع تست

-----------

تست آلفا، تست بتا، تست سیستم، تست فشار، تست احیا، تست حفاظت، تست کارایی، تست رابط گرافیکی

 

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

 خطایابی

----------

روشهای خطایابی:

1) تصادفی

2) عقب گرد

3) حذف علت

 

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

نمودار جریان Login و انتخاب عملکرد برای اولین بار

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

 

 

 پیچیدگی دوره ای:     ۶ = ۱ + ۵
  

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

گراف جریان Login و انتخاب عملکرد برای اولین بار

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

 

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

مسیرهای مبنای Login و انتخاب عملکرد برای اولین بار

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

 

 

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

زبان طراحی Login و انتخاب عملکرد برای اولین بار

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

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

ماتریس گراف Login و انتخاب عملکرد برای اولین بار

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

 

 

 

 

+ نوشته شده در  ساعت   توسط الهام راسخ  | 

طراحی در سطح مولفه

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

 

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

نشان گذاري طراحي گرافيكي

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

براي اينكه طراح از تاثير منفي بر خوانايي نرم افزار كم كند دو امكان دارد:

۱- نمايش رويه اي دوباره طراحي به گونه اي كه انشعاب خروجي ،در داخل ساختار متداخل كنترل جريان مورد نياز نباشد.

۲- واحد هاي ساختاري به روش كنترل شده اي نقض شوند. يعني انشعاب محدود شده اي براي خروج از جريان متداخل حلقه ها طراحي شود.

نمودار جعبه اي، از تمايل براي نمايش توسعه طراحي رويه اي تكامل يافته است كه اجازه نقض واحدهاي ساختاری نمي دهد. اين نمودار كه توسط Nassi,Shneiderman توسعه داده شد كه داراي اين خصوصيات است.

۱-دامنه عملياتي به خوبي تعريف مي شود.

۲-انتقال كنترل دلخواه غير ممكن است.

۳-محدوده داده هاي محلي و سراسري به راحتي تعيين مي شود.

۴-نمايش به راحتي امكان پذير است.

مانند فلوچارت، نمودار جعبهاي در چندين صفحه به صورت لايه اي، با پالايش اجزا پردازش پيمانه تعريف مي شود.

 

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

زبان طراحي برنامهPDL

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

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

 

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

در سیستم ما

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

Login و تعیین عملکرد(نخستین login – قبل از انتخاب عملکرد سیستم):

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

نمودار جعبه اي Nassi ,Shneiderman:

 

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

جدول تصمیم گیری:

 

 ******************************

******************

******

Login در دفعات بعدی:

 

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

 نمودار جعبه اي Nassi ,Shneiderman :

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

 جدول تصمیم گیری:

+ نوشته شده در  ساعت   توسط الهام راسخ  | 

طراحی رابط کاربر

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

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

نكات طراحي مانند زمان پاسخ، ساختار فرمانو عمل، اداره خطا، و امكانات كمك، در ضمن پالايش مدل طراحي در نظر گرفته مي شوند. ابزارهاي گوناگون پياده سازي براي ايجاد نمونه اي به منظور ارزيابي توسط كاربر استفاده مي شود.

 واسط ها  تأثیر زیادی روی مشتری دارند تا جایی که ممکن است یک نرم افزار خوب با نداشتن واسطه مناسب از طرف مشتری مورد قبول واقع نشود.

 

طراح باید مراحل تحلیل، طراحی، ساخت و ارزیابی را برای تولید یک واسط مناسب طی کند.

 

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

اصول کلی طراحی واسطه ها

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

1) کنترل را به کاربر دهید.

2) بار فکری کاربر را کم کنید.

3) سازگاری واسطه ها

 

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

رابط ها در سیستم ما

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

رابط های کاربر در نرم افزار "زمانبندی فعالیتهای شخصی" بدین صورت می باشد:

 

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

 ورود داده - اطلاعات مربوط به فعالیت

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

 

 

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

 یادآوری زمان انجام فعالیت

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

 

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

 نمودار ارزیابی عملکرد

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

 

 

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

 پیگیری انجام فعالیت

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

+ نوشته شده در  ساعت   توسط الهام راسخ  | 

طراحی معماری

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

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

 

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

شيوه هاي متفاوت معماري

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

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

 

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

انواع معماری ها

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

1) Data Center

2) شی گرا

3) جریان داده

4) لایه ای

3) Call return

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

 

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

مراحل ایجاد معماری

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

1) بررسی مشخصه سیستم و DFD

2) تشخیص جریان تبدیل یا جریان تراکنش

3) تعیین مرز ورودی و خروجی

4) تبدیل DFD ها به معماری

5) پالایش معماری

6) مرور و مستند سازی

 

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

معماری سیستم ما  

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

 

+ نوشته شده در  ساعت   توسط الهام راسخ  | 

اصول طراحی

اصول اولیه ای که باید در طراحی در نظر گرفته شود، بدین شرح است:

      فرایند طراحی نباید دیدگاهی تونلی داشته باشد.

      طراحی باید قابل پیگیری بر اساس مدل تحلیل باشد.

      طراحی نباید چیزی را دوباره ایجاد کند.

      طراحی باید فاصله ادراکی بین نرم افزار و مساله را همانگونه که در دنیای واقعی وجود دارد به حداقل

       برساند.

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

      طراحی باید ساخت یافته باشد تا تغییر را سازماندهی نماید.

      طراحی باید ساخت یافته باشد تا تغییر را سازماندهی نماید.

      طراحی کدنویسی نیست،کدنویسی نیز طراحی نیست.

      طراحی باید در زمان ایجاد به کیفیت توجه داشته باشد نه بعد از آن.

 

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

مفاهیم طراحی

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

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

 

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

مجرد سازی

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

 

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

     مجرد سازی داده: مجموعه ای دارای نام از داده هاست که یک شیء داده را توصیف می کنند.

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

 

--------

پالایش

--------

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

 

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

تقسیم بندی ساختاری

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

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

تقسیم بندی افقی: شاخه های مجزایی از سلسله مراتب پیمانه ای را باری هر تابع عمده ی برنامه تعریف می کند.

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

 

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

 استقلال تابعی

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

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

وحدت معیاری است از ارتباط تابعی نسبی پیمانه ها.

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

 

+ نوشته شده در  ساعت   توسط الهام راسخ  | 

فرهنگ داده ها (DD) - پایگاه داده ها

فرهنگ داده ها به عنوان گرامري رسمي براي توصيف محتويات اشيا تعريف شده در ضمن تحليل ساختيافته پيشنهاد شده است. اين نشان گذاري مهم مدلسازي به صورت زير تعريف مي شود.

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

جداول موجود، در شکل های زیر نشان داده شده است:

 

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

جدول فعالیت ها

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

 

 

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

جدول اهداف

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

 

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

جدول قرار ملاقات

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

 

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

جدول درس

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

 

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

جدول زمان کار

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

 

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

جدول پروفایل

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

 

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

جدول پیغام ها

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

+ نوشته شده در  ساعت   توسط الهام راسخ  | 

نمودار حالت (STD)

این نمودار حالت های مختلف نرم افزار را نشان می دهد.

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

 

+ نوشته شده در  ساعت   توسط الهام راسخ  | 

نمودار جریان کنترل (CFD) و CSPEC

دو روش برای رسم این نمودار وجود دارد:

1) در مدل DFD کنترل یا رخدادها را با خط چین نشان دهیم.

2) روش مرسوم آن است که DFD  را رسم کنیم سپس تمام داده های ورودی را حذف کنیم و دوباره روی کنترل هایی که در سیستم وجود دارد فکر کنیم.

در این حالت Event های خروجی به هیچ فرآیندی متصل نمی شوند و آن را به Cspec  متصل می کنیم.

در Cspec  جدولی به نام Pat وجود دارد که حاوی توضیحات مربوط به کنترل هاست و مشخص می کند که هر کنترل به کدام فرآیند وارد می شود.

توجه کنید که رویداد موجب فعال سازی فرایند نمی شود و مثل داده عمل می کند.

 

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

نمودارهای جریان کنترل در سیستم ما

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

 

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

 

 

+ نوشته شده در  ساعت   توسط الهام راسخ  | 

نمودار جریان داده (DFD) و PSPEC

پیش از آنکه فناوری شیءگرا (Object Oriented) بر فرایندهای تحلیل و طراحی مسلط شود، طراحان و تحلیل‌گران سیستم از روشی به نام «تحلیل و طراحی ساخت‌یافته (SAD) استفاده می‌کردند و برای کار خود ابزارهایی در اختیار داشتند که یکی از آنها نمودار جریان داده است. نمودار جریان داده (Data Flow Diagram) یا (DFD) تلاش می‌کند تا جریان گذر داده‌ها در سیستم را به صورت یک نمودار تصویری نمایش دهد. منظور از جریان گذر داده (Data Flow) مسیری است که یک داده ورودی طی می‌کند تا به یک داده خروجی تبدیل شود. به عبارتی می‌توان گفت که پردازشهایی را که بر روی داده انجام میشود و مسیری که داده از یک پروسه به پروسه دیگر طی می‌کند را نمایش می‌دهد. نمودار جریان داده برای سیستمهایی که پردازشهای سنگین و پیچیده دارند مفید است و به طراح کمک می‌کند تا بدون در نظر گرفتن جزئیات پیاده سازی هریک از زیرفرایند‌ها (یا همان ایستگاههای میانی)، فرایند بزرگتر را به اجزای سازنده و مسیر بین آنها تجزیه کند. وی سپس می‌تواند هر یک از این «فرایند های میانی» را به صورت یک مسئله طراحی جدید حل کند. میزان جزیئات بیان شده در نمودار جریان داده را با سطح (Level) آن نمایش می‌دهند. نمودار سطح صفر تشکیل شده از یک یا چند منبع داده ورودی، یک (یا چند) مسیر داده خروجی و تنهایک تابع (یا همان فرایند) که آن را دایره و مسیر های ورودی و خروجی را با خط نمایش میدهند. نمودار سطح یک این تابع را به اجزای درونیش تفکیک می‌کند و مسیر داخلی داده را نمایش می‌دهد (که یک مرحله به حل مسئله اصلی نزدیک تر است) و فرایند همینگونه ادامه دارد تا انجایی که تابعهای ترسیم شده براحتی قابل نوشتن باشند.

تفاوت عمده نمودار جریان داده با فلوچارت این است که نمودار جریان داده کل مسئله را از زاویه دید دیگری می‌نگرد. هدف از رسم فلوچارت نمایش گرافیکی یک الگوریتم است که نسبت به یک تابع در نمودار جریان داده ها حوزه کارکردی کوچکتری دارد و هدف جزئی‌تری را دنبال می‌کند. نمودار جریان داده‌ها (بر خلاف فلوچارت) بر روی فرایند‌ هایی که «جریان های داده‌ها» می‌پیمایند تمرکز دارد در حالی که فلوچارت بدنبال ارائه دنباله‌ای از قدمهای ساده است که در پایان نتیجه‌ای را بدست میدهند. البته اگر که جریان داده‌ها را به اندازه کافی خرد کنیم در پایان به الگوریتم‌ها میرسیم و اگر کل سیستم را یک «ابر الگوریتم» در نظر بیاوریم (که براستی همینگونه هم هست) آنگاه الگوریتم به جریان داده‌ها بدل میشود. از نتایج مهم این تفاوت در دیدگاه‌ها آن است که جریان داده‌ها به «شرایطی» که باعث چند شاخه شدن مسیر خروجی توابع میشوند توجهی ندارد و تنها این مسیرها را (بدون ذکر علت) نمایش می‌دهد در حالی که مراحل شرطی و شاخه‌بندی مسیر اجرا توسط شرط‌هایکی از پایه‌های جدا نشدنی فلوچارت است.

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

 

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

سطوح مختلف DFD

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

1) DFD سطح صفر:  بهDFD  سطح صفر Contex Diagram گفته می شود و یک نمای کلی از سیستم را نشان می دهد . در این سطح موجودیت های داخلی و خارجی را به همراه ورودی و خروجی آورده و از قراردادن مکان ذخیره سازی اجتناب می کنیم

2) DFD سطح 1 : در این سطح می توان در صورت نیاز مکان ذخیره سازی را در دیاگرام رسم کرد. در این سطح سیستم به اجزای کوچکتری شکسته می شود.

 نکته: تعداد ورودی و خروجی ها در هر سطح باید با هم تطابق داشته باشد.

3) DFD سطح 2 : در این سطح خود زیرسیستم ها نیز به اجزای کوچکتر شکسته می شوند .

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

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

DFD سطح 0  ==> نرم افزار

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

 

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

DFD سطح 1 ==> نرم افزار

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

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

DFD سطح 2 ==> Login

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

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

DFD سطح 2 ==> پردازش اطلاعات و زمانبندی

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

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

DFD سطح 2 ==> پیام

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

 

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

DFD سطح 2 ==> دریافت اطلاعات

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

 

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

DFD سطح 2 ==> تولید Reminder

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

 

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

DFD سطح ۳ ==> تحلیل اطلاعات

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

 

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

مشخصه فرایند (PSPEC)

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

 دکمه  Login: سیستم ابتدا user و Password را از کاربر دریافت کرده ، با مراجعه به بانک اطلاعاتی و خواندن اطلاعات مربوط به جدول profile، صحت user و Password کاربر را بررسی می کند. در صورت درستی، وارد به مرحله بعد می شود. در غیر این صورت پیغامی مبنی بر نادرست بودن user و Password نشان داده می شود.

دکمه Scheduler: با فشردن این دکمه، چک می شود که آیا اولین login این کاربر است و یا اینکه درخواست برنامه ریزی مجدد دارد؟! درصورتی که اولین login باشد ، باید ورود اطلاعات نمایش داده شود و کاربر، جداول را پر کند. درغیر این صورت فرم تغییر اطلاعات لود شده و پس از ثبت تغییرات، برنامه ریزی در قسمت های تغییر یافته، تغییر می کند و جدول زمانبندی به روز می شود.

دکمه Data Entry: با ردن این دکمه فرم ورود اطلاعات به کاربر نمایش داده می شود و کاربر جداول را پر می کند و در نهایت بانک به روز می شود

دکمه Show Message: با زدن این دکمه، تابع انتخاب پیام اجرا می شود و پیام انتخاب شده بر اساس اهداف اولویت دار به نمایش در می آید.

دکمه Show schedule: اطلاعات از جدول برنامه ریزی بانک اطلاعاتی خوانده شده و در قالب جدولی نمایش می یابد.

دکمه "ارزیابی": عملکرد کاربر را بر اساس نوع درخواست کاربر (روزانه – هفتگی – ماهانه) بررسی کرده و نمایش می دهد.

دکمه "خروج": خروج از سیستم را به همراه دارد.

 

+ نوشته شده در  ساعت   توسط الهام راسخ  | 

نمودار رابطه موجودیت ها (ERD)

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

رسم نمودار ERD نرم افزار "برنامه ریزی فعالیت های شخصی" بدين ترتيب است:

 ---------

فرضیات

---------

1)      در این سیستم اینکونه فرض شده است که حتی ممکن است با تعریف نکردن هدف از سوی کاربر نیز برای فعالیت های روزانه برنامه ریزی کنیم. پس وجود هدف برای وجود برنامه الزامی نیست. البته به منظور هدف مند بودن برنامه بهتر است اهداف از سوی کاربر تعریف شود.

2)      ساده ترین کاربرد این برنامه تنها نمایش پیام هاست. بدون وجود برنامه ریزی. بنابراین وجود برنامه برای وجود پیام الزامی نیست.

+ نوشته شده در  ساعت   توسط الهام راسخ  | 

مدیریت پیکربندی پروژه

 مخزن پروژه برای سیستم"برنامه ریزی فعالیت های شخصی" به این صورت است:

(بارگذاری جدول، مدتی طول می کشد. لطفا کمی صبر نمایید... )

 

  ادامه مخزن پروژه

+ نوشته شده در  ساعت   توسط الهام راسخ  | 

اصول و مفاهیم تحلیل

مهندسي نرم افزار و مشتري نقش فعالي در مهندسي نيازها بر عهده دارند.

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

تحليل نيازها(مهندس نرم افزار) پلي بين شكاف مهندسي نيازها در سطح سيستم و طراحي نرم افزار است.

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

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

 

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

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

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

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

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

 

تكنيكهاي ساده تعيين مشخصه كاربرد:

تكنيك هايي مانند جلسه FAST جلسات اوليه بين توسع دهنده و مشتري انجام مي شود كه مسائل اساسي و پاسخها به ايجاد محدوده مسئله و درك كلي مسئله كمك مي كندتوسعه دهنده و مشتري درخواست محصول خود را تهيه مي كنند.وسپس با شروع جلسه در مورد اين مسائل با يكديگر بحث مي كنند.

+ نوشته شده در  ساعت   توسط الهام راسخ  | 

تضمین کیفیت نرم افزار

SQA شامل این موارد است :

1) روش مدیریت کیفیت

2 ) تکنولوژی موثر مهندسی نرم افزار (متدها و روش ها)

3) مرورهای تکنیکی رسمی که در طول فرایند نرم افزار بکار گرفته می شوند.

4) استراتژی آزمایش چند بخشی 

5) کنترل مستندات نرم افزار و تغییرات انجام شده بر روی آن

6) رویه ای برای اطمینان از انطباق با استاندارد های توسعه ی نرم افزار

7) مکانیزم های اندازه گیری و گزارش

 

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

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

کیفیت تطابق درجه ای است که مشخصات طراحی در ضمن ساخت دنبال می شوند. هر چه درجه تطابق بیشتر باشد کیفیت تطابق بالاتر است.

 

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

کنترل کیفیت

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

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

 

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

تضمین کیفیت

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

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

 

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

هزینه کیفیت

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

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

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

در نرم افزار گروههای متفاوتی مسئولیت تضمین کیفیت نرم افزار را بر عهده دارند، مهندسین نرم افزار، مدیران پروژه، مشتری ها، فروشنده ها افرادی هستند که در گروه SQA  قرار دارند .

گروه SQA به عنوان نمایندگان خانگی مشتری به حساب می آیند .یعنی افرادی که SQA را انجام می دهند باید به نرم افزار از دیدگاه مشتری نگاه کنند .

 

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

فعالیت های SQA  

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

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

این فعالیت های شامل : 1) طرحی از SQA را برای پروژه آماده می نمایند . 2) در توسعه توصیف فرایند پروژه نرم افزاری شرکت می کند . 3)  فعالیت های مهندسی نرم افزار را مرور می کند تا تطابق آنها با فرایند تعریف شده نرم افزار بازبینی نماید . 4) محصولات کاری نرم افزاری مشخص شده را بررسی می نماید تا تطابق آنها را با مواردی که به عنوان بخشی از فرایند نرم افزار تعریف شده اند مورد بازبینی قرار دهد . 5) اطمینان می دهد که انحرافات در کار نرم افزار و محصولات کاری مستند شوند و بر طبق روش مستند شده ای اداره گردند . 6) هر عدم تطابق را ثبت نموده و به مدیر ارشد گزارش می دهد .

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

 

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

اهداف FTR  

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

 1) کشف خطاها در عملکرد، منطق، یا پیاده سازی، برای هر نمایش نرم افزار

2) بازبینی بر آورده ساختن نیازهای نرم افزار در حال مرور

3) اطمینان از اینکه این نرم افزار بر طبق استانداردهای از پیش تعریف شده نمایش داده شده است.

4) بدست آوردن نرم افزاری که به شکل یکنواختی توسعه یافته است.

 ) ایجاد پروژه ای با قابلیت مدیریت بالاتر.

 

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

قالب جلسه مرور

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

علیرغم قالب انتخاب شده برای  FTR، هر جلسه مرور باید محدویت های زیر را رعایت کند:

         معمولا بین سه تا پنج نفر باید در جلسه حضور داشته باشند.

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

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

با این محدویت ها، واضح است که FTR بریک بخش کوچک از کل نرم افزار تاکید دارد.

 

-----------

طرح SQA

-----------

طرح SQA راهی را برای ایجاد تضمین کیفیت نرم افزار فراهم می کند . این طرح که توسط گروه SQA توسعه داده شده است، الگویی را برای فعالیت های  SQA ارائه می دهد که برای هر پروژه نرم افزار بکر گرفته می شود.

 

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

 (SW-CMM) معرفی مدل بلوغ قابلیت برای شرکت های نرم افزاری

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

 

شرکت های نرم افزاری برای اثبات کیفیت و قابلیت های خود نیاز به ارایه برخی شواهد و مدارک دارند. مدل بلوغ ظرفیت برای ارزشیابی فرایندهای نرم افزاری شرکت ها به کار می رود. می توان گفت که این استاندارد معتبرترین مدرک در سطح جهانی برای اثبات قابلیت های یک شرکت برای دریافت و انجام پروژهای نرم افزاری می باشد . SW-CMM در حقیقت مدلی است برای تعیین میزان بلوغ فرایندهای یک شرکت نرم افزاری و تعیین فعالیت های کلیدهای مورد نیاز برای افزایش میزان ظرفیت و کیفیت این فرایندها . این استاندارد توسط موسسه مهندسی نرم افزار (SEI) تدوین شده است .  موسسه مهندسی نرم افزار یکی از مراکز برتر تحقیق و توسعه در آمریکا می باشد که با حمایت وزارت دفاع این کشور با بودجه فدرال و تحت پوشش بهبود فرایند های شرکت های نرم افزاری دانشگاه کارنه گی مه لون فعالیت می نماید. هدف اصلی SW-CMM بهبود فرایندهای شرکت های نرم افزاری و ارتقای فرایندهای ابداعی و سامان نیافته به فرایندهای جا افتاده و سامان یافته است . SW-CMM یک استاندارد سطح مند است . این استاندارد فرایند های مورد استفاده در شرکت های نرم افزاری را در یک نظام پنج سطحی قرار می دهد . با ارتقای شرکت به سطوح بالاتر، پیش بینی پذیری، کارایی و کنترل فرایندهای  نرم افزاری شرکت بهبود می یابد .

 

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

سطوح بلوغ شرکت های نرم افزاری

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

سطوح بلوغ شرکت های نرم افزاری SW-CMM عبارتند از :

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

2. سطح مدیریت شده: در این سطح فرایندهای پایه برنامه ریزی و مدیریت هزینه، زمانبدی و کار کرد پروژه ها وجود دارد. در صورت موفقیت آمیزبودن فرایندها، می توان آن ها را برای پروژه های دیگر نیز به کار برد .

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

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

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

 

+ نوشته شده در  ساعت   توسط الهام راسخ  | 

زمانبندی و پیگیری پروژه

شبكه كاري

كارهاي نرم افزار براساس مدل فرايندي ديكته مي شودبه منظور عملكردي كه بايد ايجاد شود پالايش مي شود. ميزان فعاليت و مدت ،به هر يك از كارهايي تخصيص ميابد و شبكه اي از كارها(شبكه فعاليت) به روشي ايجاد مي گردد كه باعث شود تيم نرم افزار به مهلت تحليل تعيين شده دست يابد.

مجموعه كاري براي پروژه نرم افزار

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

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

زمانبندی ماکروسکوپی

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

 

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

زمانبندی میکروسکوپی

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

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

ادامه زمانبندی میکروسکوپی

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

 

+ نوشته شده در  ساعت   توسط الهام راسخ  | 

مدیریت ریسک

انواع ریسک‌ها:

         مديريت ريسک غير فعال :که در آن تيم نرم افزاري کاري در رابطه با ريسکها انجام نمي دهد تا زماني که عملي درست انجام نشود سپس اين تيم براي رفع سريع مشکل وارد عمل مي شود.

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

 

انواع ریسک‌های نرم‌افزاری:

         ریسک‌های پروژه‌

         ریسک‌های فنی

         ریسک‌های تجاری

         ریسک‌های بازاریابی

         ریسک‌های استراتژیک

         ریسک‌های حمایت مدیران ارشد

         ریسک‌های تکنیکی

         ریسک‌های محیط توسعه نرم‌افزار

         قابل پیش‌بینی: ریسک‌هایی که می‌توان آن‌ها را نام برد, تعیین می‌شوند.

         غیر قابل پیش‌بینی: بستگی به مدیر یا فردی که ریسک‌ها را تحلیل می‌کند دارد. آنچه که اصلا به  آن فکر نکردیم.

 

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

جدول مديريت ريسك بر حسب استراتژي مديريت فعال را در پروژه برنامه ریزی "فعالیت های شخصی"  را نشان مي دهد:

 تأثیر ریسک:

فاجعه آمیز ==>   ۱

بحرانی ====>   ۲

مرزی =====>   ۳

کم اهمیت ==>   ۴

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

طرح RMMM

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

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

اجتناب : برای جلوگیری از وقوع ریسک چه کار باید کرد

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

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

طرح RMMM تعدادي از ريسكهاي با احتمال بالا به صورت زير است:

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

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

 

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

نرم افزارهاي مرتبط با مديريت ريسك

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

۱)  Risk Man
پس از آنكه شروع عمليات يك پروژه كه اقتصادي بودن آن به تأييد مي‌رسد به سازمان ذيربط ابلاغ مي‌گردد مديريت سازمان با محدوديت‌هاي اساسي روبرو مي‌شود مانند زمان، هزينه، كيفيت. سازمان موظف مي‌شود تا پروژه را در زمانبندي با بودجه تعيين شده و برطبق كيفيت تعريف شده به اجرا درآورد تا پيش‌بيني‌ها و برآوردهاي اوليه تحقق يابد و از عملكرد توليد اطمينان لازم حاصل شود. اما معمولاَ اين برآوردها و پيش‌بيني‌ها به دليل عدم قطعيت و وجود احتمال در آن‌ها، با خطا مواجه مي‌شود. وجود عدم قطعيت و احتمال، همواره مخاطراتي را متوجه پروژه مي‌نمايد. خطراتي از قبيل طولاني شدن زمان ساخت، افزايش هزينه‌هاي ساخت و يا كاهش كيفيت توليد. در زمان عمليات و توليد نيز همواره اين چالش و خطرات وجود دارد. به طور كلي هر امري كه با پيش‌بيني و عدم قطعيت شروع به اجرا مي‌شود اينگونه خطرات را به همراه دارد. در اين حالت مديريت بايستي قادر باشد خطرات را شناسايي نمايد، روش‌ها و راهكارهاي مقابله با خطرات را انتخاب كند تا بتواند بر مشكلات ناخواسته فائق آيد. براي انجام چنين امري مديريت پروژه و مديريت عمليات مي‌بايستي تمامي پارامترها و متغيرها و ارتباط بين آن‌ها را با هم تركيب نمايد. در بسياري اوقات تعدد علل بروز خطرات به حدي بالاست كه تصميم‌گيري را به شدت مشكل مي‌سازد و در بعضي مواقع امكان تصميم‌گيري درست را از مديران و مهندسين سلب مي‌نمايد.
Risk Man نرم‌افزاري است كه با استفاده از متدولوژي”علت و معلولي“ كمك مؤثري به مديران و گردانندگان عمليات اجرايي مي‌نمايد. اين نرم‌افزار به عنوان يك ابزار با شبيه‌سازي‌هايي كه با استفاده از اطلاعات اوليه انجام مي‌دهد كاربر را قادر مي‌سازد با ارتباط دادن مخاطرات(ريسك‌ها) با فعاليت‌هاي اصلي و با لحاظ نمودن درجه احتمال وقوع، امكان‌ پيش‌بيني مقابله با ريسك را فراهم مي‌سازد.
Risk Man در زمينه مخاطراتي كه زمان، هزينه، كيفيت، تغييرات در حوزه كار، استراتژي، مهارت و مانند آن را تهديد مي‌نمايد كاربرد مؤثري دارد و توان مديريت ريسك را افزايش مي‌دهد. اين نرم‌افزار با ايجاد بانك اطلاعاتي اين امكان را براي كاربران فراهم مي‌نمايد تا بتوانند در آينده در مورد پروژه‌هاي مشابه از تجارب گذشتگان بهره بگيرند و از تكرار خطاها و اشتباهات جلوگيري نمايند.

۲)  Risk

نرم‌افزاري بسيار قوي در زمينه شبيه‌سازي ريسك‌ها و مخاطرات با استفاده ازMonteCarlo مي‌باشد. تمركز عمده اين نرم‌افزار بر روي مسائل مالي بوده و قادر است كاربراني كه در زمينه مديريت سرمايه علاقمند به شناسايي و تجزيه و تحليل ريسك هستند حمايت نمايد. اين نرم‌افزار قابليت سوار شدن بر روي نرم‌افزارهايي مانندMSP را دارد و مي‌تواند به تنهايي با استفاده از يكسري از داده‌ها، گزارشات مربوط را براي تجزيه و تحليل آماده نمايد.
استفاده از @Risk و Risk Man نيازمند داشتن دانش كافي در زمينه مديريت پروژه، مديريت عمليات، مديريت سرمايه، مديريت بازار و مديريت بازرگاني مي‌باشد.

 

+ نوشته شده در  ساعت   توسط الهام راسخ  | 

فرایند نرم افزار و معیارهای پروژه

اهداف جزئی

 

 

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

نمودار ماهی

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

 

 

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

مهندسي = اندازه گيري

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

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

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

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

همانطور كه گفته شد اندازه گيري در 2 سطح انجام مي شود؛ در سطح اول توسط مجريان فني پروژه و در سطح دوم توسط مدير پروژه.

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

معيارها به دو دسته زير تقسيم مي شوند :

  • اندازه گرا
  • عملكردگرا

 

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

 معيارهاي اندازه گرا

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

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

به عبارت ديگر معيارهاي LOC به زبان برنامه نويسي وابسته اند و قابليتهاي برنامه هاي با LOC كمتر و داراي طراحي خوب را ضعيف ارزيابي مي كنند و همچنين پيش بيني LOC در مرحله تخمين پروژه مشكل مي باشد.

 

 

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

  معيارهاي عملكردگرا

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

معيارهاي عملكردگرا به جاي اندازه گيري تعداد خطوط برنامه، صفات خاصه ديگري مانند تعداد وروديها و خروجي هاي نرم افزار، تعداد درخواستهاي كاربر، تعداد فايلها و تعداد رابط هاي خارجي كاربر.

سوالات:

 

   FP تخميني=[(count total*[0.65+0.01*∑Fi)]

 

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

تخمین بر مبنای فرایند

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

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

 

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

نتیجه گیری

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

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

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

+ نوشته شده در  ساعت   توسط الهام راسخ  | 

مدیریت پروژه

مدیریت موثر پروژه نرم افزار بر چهار مولفه تاکید دارد.: افراد، محصول، فرایند و پروژه که در ادامه به شرح هریک می پردازیم:

 

-------

افراد

-------

روش تیم بندی در گروه، غیرمتمرکز کنترل کننده(DD)  است. از آنجا که سطح آزادی همه افراد گروه در زمینه مهندس نرم افزار یکسان است و همچنین به دلیل فقدان تجربه کافی در این زمینه، رأی گیری و تبادل نظر در تمامی مسائل الزامی است.

 

روش هماهنگی و ارتباط

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

 

---------

محصول

---------

عملکرد:

برنامه ریزی درسی و قرارهای ملاقات

یادآوری و پیگیری

نمایش میزان پیشرفت

ارزیابی عملکرد

نمایش پیام های موفقیت جهت آماده سازی روحی و روانی کاربر

 

محدودیت ها:

1- زبان برنامه نویسی: می بایست مطابق با سیستم عامل گوشی باشد. ما Cymbian  را انتخاب نموده ایم.

2- مدل گوشی: سیستم عامل گوشی Cymbian  بوده و حافظه ۲GB می باشد.

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

4- بنا به دلیل ذکر شده در مورد 3، محدودیت نیروی انسانی نیز وجود دارد، گروه کنونی از 4 نفر تشکیل شده است.

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

6- قیمت نرم افزار ۵.۶۰۰.۰۰۰ تومان تمام شده است.

7- حجم فایل کم باشد (چون بر روی گوشی اجرا می شود) در نتیجه برای این نرم افزار سرعت بالا مورد نیاز است.

( اکثر این محدودیت ها در نسخه اول نرم افزار وجود دارد. امید است در نسخه های تکمیلی، این محدودیت ها به قابلیت نرم افزار تبدیل شوند.)

 

تجزیه محصول:

 
------
فرآيند
------
 
مدلسازي محصول و فرآيند

برنامه ريزي پروژه با مدلسازي محصول و فرايند شروع مي شود .هر تابعي كه توسط تيم نرم افزار بايد ايجاد شود، بايد شامل مجموعه اي از فعاليت هاي زمينه كاري تعريف شده براي سازمان نرم افزار باشد.

 این جدول در پست "فرایند نرم افزار و معیارهای پروژه" رسم شده است.

-------

پروژه

------

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

 

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

اصل W5HH

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

چرا اين پروژه بايد انجام شود؟

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

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

 

چه كار هايي بايد انجام شود؟

1. ثبت اطلاعات مشخصات فرد

2. ثبت اطلاعات مربوط به فعالیت ها و دروس و قرارهای ملاقات

3. ثبت اطلاعات مربوط به اهدف و پیامها

4. حذف، ويرايش، به روز رساني و جستجوي اطلاعات

5. برنامه ریزی

۶. ارزیابی عملکرد

۷. نمایش پیام های موفقیت

 

در چه بازه اي از زمان كار بايد انجام گيرد؟

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

 

چه كسي اجراي پروژه را به عهده مي گيرد؟

مدير ارشد نقش حمايتي و تصميم گيري هاي كلان مانند بستن قرار داد و غيره را به عهده دارد ولي  در اصل اين مدير پروژه مي باشد كه اجرا و هدايت  پروژه (انجام كار هاي مديريتي پروژه) را به عهده دارد و تصميم هاي مديريتي پروژه را مي گيرد.

در اين پروژه با توجه به عدم تجربه كافي افراد تمام كارها با هم فكري تمام افراد گروه انجام گرفته است.

 

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

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

+ نوشته شده در  ساعت   توسط الهام راسخ  | 

چکیده

عنوان پروژه: نرم افزار برنامه ریزی اعمال شخصی

مدل فرآیند:  نمونه اولیه سازی(Prototype)، اجزای قابل استفاده مجدد، تکاملی

 

--------

مقدمه

--------

نرم افزار کاربردی پیشنهادی، ارائه دهنده بهترین شیوه برنامه ریزی و زمان بندی فعالیت ها ی روزانه می باشد که با در نظر گرفتن زمان، تمایلات، علایق و اهداف فردی ، بهترین برنامه را در اختیار کاربر قرار می دهد.

موارد ضرورت پروژه:

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

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

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

 

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

فرآیند انتخابی

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

نمونه اولیه سازی:

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

 

 قابل استفاده مجدد:

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

 

تکاملی:

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

+ نوشته شده در  ساعت   توسط الهام راسخ  |