X
|
محمدرضا جواهری دانشجو کارشناسی ارشد واحد تهران شمال 87999003
|
 |
 |
||||
|
محمدرضا جواهری ( ارشد تهران شمال ) عناوین تکالیف مباحث پیشرفته در مهندسی نرم افزار --------------------------------------------------------------------------------------- برای دیدن متن هریک از عناوین زیر بر روی آن کلیک کنید ض- استاندارد های مهندسی نرم افزار چیست؟ ض- چه تعداد محصولات نرم افزاری داریم؟ درباره یکی از محصولات نرم افزاری دو صفحه بنویسید! (ERP) ض- جهت طراحی یک فرم برای شناسایی و کنترل و ردیابی ریسک ها چه فرمی را پیشنهاد می دهید؟ ض- نمودارهای چرخه حیات تغییر و چرخه حیات نگهداری را جهت طراحی محصول جدید را شرح دهید. ض- در یک جدول متدلوژی ها را با هم مقایسه کرده و در هر متدلوژی درصد اهمیت هر فاز را بنویسید. ض- SCM و ERP و C4I و Platforms و OS از چه بخش هایی تشکیل شده اند؟ (SCM) ض- جهت شناخت، تولید و اجرایی نمودن یک سیستم یکپارچه چه روشهایی را پیشنهاد می کنید؟ ض- اجزاء تشکیل دهنده ERP و SCM را با رسم شکل نشان دهید.
· موضوع تحقیق: نرم افزارهای توزیع شده · آدرس ایمیل: reza.java@yahoo.com · آدرس سایت: http://www.rezajava.blogfa.com · تلفن: 09126838345
آذر 88
|
|||||
|
|||||
|
|
|
||||
|
افزايش و فشردگي رقابت در عرصههاي مختلف کسبوکار، توليدکنندگان و ارايه دهندگان خدمات را مجبور کرده تا با بهکارگيري روشها و استفاده از فناوريهاي نوين، از يکسو به افزايش کيفيت و کميت محصولات و از سوي ديگر به کاهش قيمت و زمان عرضه آنها بپردازند و در نهايت، حداکثر رضايت مشتريان در بازار را بهدست آورند. به همين منظور، بسياري از سازمان ها و توليدکنندگان تمايل زيادي نسبت به بکارگيري نرم افزارهاي جامع يکپارچه و برنامهريزي منابع سازماني (ERP) پيدا کردهاند. در اين راستا، بعضي از سازمانهاي پيشرو موفق بوده و اکثر آنها در استقرار چنين سيستمهايي با شکست مواجه شدهاند. در مورد فرصتها و تهديدها، نقاط قوت و ضعف توسعه و استقرار سيستمهاي يکپارچه برنامهريزي منابع سازماني و معيارهاي موفقيت و شکست پيادهسازي اين سيستمها در سازمانها و به طور خاص در واحدهاي صنعتي ايران ميپردازيم. موفقيت يک سيستم برنامهريزي منابع سازمان به مديريت موثر پروژه، امکان انجام تغييرات سازماني و استفاده از فناوريهاي پيشرفته بستگي دارد. اجراي موفق سيستم برنامهريزي منابع سازمان نيازمند وجود مجموعهاي از مهارتها و دانش ميباشد. بسياري از پروژههاي سيستم برنامهريزي منابع سازمان طولانيتر و با هزينهي بيشتر از مقادير پيشبيني شده انجام شدهاند. در برخي ديگر از پروژهها به جاي استدلال و دلايل سازماني بيشتر انگيزههاي فني در اجراي پروژههاي ERP مورد توجه قرار گرفته است. همچنين برخي سازمانها در دستيابي به پتانسيلهاي بالقوه سيستم برنامهريزي منابع سازمان با شکست مواجه شدهاند. بعضا هم شرکتها نتوانستهاند نتايج حاصل از سرمايهگذاري و اثربخشي اجراي ERP را اندازهگيري کنند. پروژههاي ERP در بسياري از شرکتها، به منزله يک پروژه سرمايهگذاري کلان در زمينه سيستمهاي اطلاعاتي است. در بسياري موارد اين پروژه به تنهايي بزرگترين پروژه سرمايهگذاري در سطح شرکت است. عظمت و پيچيدگي اين پروژه بيانگر ريسکهاي قابل توجهي است که چالشهاي زيادي در پيادهسازي سيستمهاي ERP ايجاد ميکنند. شرکتهايي که پياده سازي موفق سيستمهاي ERP را داشتهاند، احساس ميکنند که به بيش از 65% از اهداف کسب و کار دست يافتهاند. شرکتهايي که قادر بودند سيستم ERP را با بودجه در نظر گرفته شده يا کمتر از آن پيادهسازي کنند، حدود 11% بيشتر از ساير شرکتها به اهداف کسب و کار دست يافتهاند. هرچند که 70% از شرکتها احساس ميکنند که پيادهسازي سيستم ERP آنها پروژه موفقي بوده است، اکثر شرکتها اعلام کردهاند که هزينه واقعي پيادهسازي سيستم ERP حدود 60% بيشتر از بودجه تخميني براي آن بوده است. انجام پروژه مطابق بودجه درنظر گرفتهشده يا بيشتر از آن تحت تاثير عوامل معيني قرار دارند. اولا، شرکتهايي که مطابق بودجه يا پايينتر از آن پروژه را اجرا کردهاند اصلاحات کمتري در نرمافزار نسبت به شرکتهاي ديگر انجام دادهاند. طبق تحقيقات انجام اصلاحات باعث افزايش 50% مدت زمان پروژه ميشود. بهعلاوه، شرکتهاي موفق اختيارات بيشتري به مجريان پروژه ميدهند و بين مجريان، کارکنان و ذينفعان ارتباط موثرتري برقرار ميسازند. شرکتهاي موفق، پروژه پيادهسازي و کسبوکارشان را بهتر مديريت ميکنند، اين امر آنها را قادر ميسازد که به منافع بيشتري دست يابند تا هزينههاي پيادهسازي ERP برگشت داده شود. مطالب بسياري درمورد عوامل شکست پروژههاي سيستمهاي اطلاعاتي نوشته شدهاست. روشهاي تکنيکي ضعيف تنها يکي از علتها است. اين علت در مقايسه با مشکلات بزرگتري نظير شکست در برقراري ارتباطات و رهبري ضعيف از اهميت نسبي کمتري برخوردار است. در يک تجزيه و تحليل، زمينههاي شکست و علل پيادهسازي ناموفق سيستمهاي برنامهريزي منابع سازماني صورت زير طبقهبندي شدهاند: · منابع- تعارض افراد ، زمان و دامنه پروژه و به خاطر کافي نبودن پرسنل، سيستمها داراي خطا و قابليت اطمينان کم ميشوند و مشکلات نگهداري و کاربران ناراضي نيز به آن اضافه ميشود. · احتياجات- مشخص کردن احتياجات به شکل ضعيف منجر به توسعه سيستم اشتباه و همراه با تغييرات فراوان در احتياجات پاييندستي ميشود. · اهداف- اهداف سيستم توسط مديريت به صورت نامناسب بيان شود، به خاطر هدايت به سمت احتياجات نامشخص منجر به توسعه سيستم اشتباه ميشود. · تکنيکها- عدم استفاده از رويکردهاي موثر توسعه نرمافزار مانند تجزيه و تحليل و طراحي ساختيافته، باعث تشخيص نامناسب احتياجات، قابليت اطمينان کم و هزينههاي نگهداري بالا ميشود. · ارتباط با کاربر- عدم توانايي در برقراري ارتباط با کاربران سيستم، باعث تشخيص نامناسب احتياجات و آمادگي ضعيف براي پذيرش و استفاده از سيستم اطلاعاتي ميشود. · سازماني- ساختار سازماني ضعيف، نبود رهبري سازماني يا گستردگي محدوده کنترلي آن، منجر به هماهنگي ضعيف بين فعاليتها، تاخير در زمانبندي و کيفيت ناسازگار ميشود. · تکنولوژي- شکست در مطابقت سختافزاري و نرمافزاري با خصوصيات سازمان و ناکارآمدي فروشنده در تحويل بهموقع، تاخير در سيستم، قابليت اطمينان کم، مشکلات نگهداري و کاربران ناراضي سيستم را بوجود ميآورد. · اندازه- وقتي که پروژهها بسيار بزرگ باشند، پيچيدگي پروژه قابليت سازمان در توسعه سيستمها را محدود ميسازد. موجب ناکافي بودن منابع، تشخيص نامناسب احتياجات، سادهانگاري پروژه و استفاده ضعيف از متودولوژي ميشود. · مديريت- فقدان تلاش و کوشش، سرکوب خلاقيت و بروز گرايشهاي ستيزهجويانه، به وقوع تاخيرات زماني و بيشتر شدن بودجه ميانجامد و باعث تشخيص ضعيف خصوصيات پروژه و مشکل شدن نگهداري سيستم ميشود. · متودولوژي- عدم اجراي فعاليتهاي ضروري در حالي که فعاليتهاي غير ضروري انجام شدهاند. اين نوع شکست ميتواند منجر به هر نوع شکست سيستم گردد. · برنامهريزي و کنترل- تخصيصهاي مبهم، مديريت پروژه نامناسب و ابزارها پيگيري ناکارآمد، باعث همپوشاني کارهاي تخصيصيافته، تعاريف نامشخص کارهاي قابل تحويل و رخداد ارتباطات ضعيف ميشود. · شخصيتي- برخوردها و مشکلات فردي، موجب همکاري غير فعال و مقاومت پنهان ميشود و امکان بروز عمليات انتقامجويانه را ايجاد ميکند که باعث شکست پروژه مي شود. به طور خلاصه ميتوان خاطر نشان کرد که پروژههاي موفق به موقع، با بودجه درنظر گرفتهشده، قابل اطمينان، قابل نگهداري و مطابق اهداف و نيازمنديهاي کاربران هستند. مديران موفق يک ارزيابي اوليه از پروژه انجام دادهاند. آنها دستورات، مجريان، اهداف، محدوديتها، مسؤليت و اختيار مدير پروژه و امکان موفقيت در اجراي پروژه را ارزيابي ميکنند. |
|||||
|
|||||
|
|
|
||||
|
معماريهاي متفاوتي بمنطور طراحي و پياده سازِي متناسب با رشد فن آوري در بخش نرمافزار ارائه شده است اين معماريها از يکطرف برخاسته از امکانات و ماهيت معماري سخت افزارها در زمان خود و از طرف ديگر بسته به نوع و نگرش در تکنولوژيهاي ساخت نرمافزاري و انتظارات طرح شده توسط کاربران است هر معمارِي داراي شاخصها و ويژگيهاي منحصر بفرد خود بوده و نرمافزارهائِي که با اتکاء بر هريک از معماريهاي فوق پياده سازي مي گردنند ، خصايص خود را از معماري بکارگرفته شده به ارث خواهند برد. در معمارِي فوق از سرويس دهند گان و سرويس گيرند گان با خصايص متفاوت استفاده مِي شود.اصل تقسيم کار دنبال و سرويس دهنده عمليات سنگين با پردازش بالا و سرويس گيرنده عمليات سبک را انجام خواهند داد. دو بخش متفاوت يک برنامه ، در جهت انجام عمليات با يکديگر تشريک مساعِي مِي نمايند.سرويس گيرنده با ارسال درخواست و سرويس دهنده با پاسخ به درخواست جلوه اِي از هميارِي در پردازش عمليات را بنمايش مِي گذارند.پلات فورم و سيستمهاي عامل سرويس دهنده و سرويس گيرنده مِي تواند متفاوت باشد.عملياتِي را که يک برنامه انجام مِي دهد بين سرويس دهنده و سرويس گيرنده تقسيم مِي گردد. مزايا اِين معمارِي بهره گيرِي مناسب از پتانسيلهاي سخت افزارِي موجود با توه به اصل تقسيم عملياتهابهينه سازِي استفاده و بکارگيرِي منابع اشتراکِي. بهينه سازِي توانائِي کاربران از بعد انجام فعاليتهاي متفاوت. معايب عدم وجود امکانات لازم براِي کپسوله نمودن سياستهاي راهبردِي نرمافزارکاهش کارائِي برنامه همزمان با افزايش تعداد کاربران همزمان تاکنون مدلهاي متفاوتي از معماري فوق پياده سازي شده است پردازشهاي مبتني بر ميزبان مدل فوق بمنزله يک مدل سرويس دهنده / سرويس گيرنده تلقي نشده و مشابه مدل MainFarme است . پردازشهاي مبتني بر سرويس دهنده در اين مدل سرويس دهنده تمامي پردازشهاي مربوطه را انجام و سرويس گيرنده مسئوليت ايجاد بخش رابط کاربر را برعهده خواهد د اشت. پردازشهاي مبتني بر سرويس گيرنده تمامي عمليات بر روي سرويس گيرنده انجام خواهد شدعمليات مربوط به بررسي صحت دادهها و ساير عمليات مربوط به منطق بانکهاي اطلاعاتي بر روي سرويس دهنده انجام خواهد شد. پردازشهاي مبتني بر همياري .در اين مدل سرويس دهنده و سرويس گيرنده بمنظور انجام يک فعاليت با يکديگر تشريک مساعي خواهند کرد. ويژگيهاي معماري Client Server Two Tier مشابه مدل Client Server مي باشد. در اين مدل از يک سرويس دهنده و يک سرويس گيرنده در شبکه استفاده مي گردد. مدل فوق از سه بخش که در دو لايه سرويس دهنده و سرويس گيرنده قرار خواهند گرفت، تشکيل مي گردد. بخشهاي رابط کاربر ، مديريت پردازشها و مديريت بانکهاي اطلاعاتي بخشهاي سه گانه مدل فوق مي باشند. منطق برنامه بين دو محل فيزيکي توزيع مي گردد. مناسب ترين روش براي پردازشهاي توزيع شده در يک شبکه با حداکثر يکصد کاربر ميباشد. سهولت در امر پياده سازي و نسبت دهي مستقيم رابط کاربر با منابع تامين دادهها را دارد. معايب عمده آن عدم وجود امکاناتي براي کپسوله نمودن سياستهاي راهبردي نرم افزار. کاهش کارائي برنامه همزمان با افزايش تعداد کاربران همزمان و عدم وچود انعطاف لازم از بعد انتقال يک برنامه از سرويس دهنده اي به سرويس دهنده ديگر بدون انجام تغييرات اساسي. معماري Client Server Three Tier در سال 1990 عرضه شده است .در اين مدل از يک Tier مياني ديگر بين سرويس گيرنده (رابط کاربر) و سرويس دهنده بانک اطلاعاتي استفاده مي شود. لايه مياني شامل مجموعه اي از ابزارها براي دستيابي به منابع سيستم ، صرفنظر از نوع پلات فورم است . لايه مياني مسئوليت مديريت پردازشها را برعهده خواهد گرفت . لايه مياني مسئوليت تجزيه و يا ترکيب نتايج حاصله از منابع داده ئي نظير بانکهاي اطلاعاتي را برعهده دارد. بخشهاي رابط کاربر ، مديريت پردازشها و مديريت بانکهاي اطلاعاتي بخشهاي سه گانه مدل فوق مي باشند. لايه مياني خود مي تواند به دو و يا بيش از دو بخش با عملکردهاي متمايز تقسيم گردد (Multi-Tier) مدل فوق گزينه اي مناسب براي پياده سازي نرم افزار بر روي اينترنت است. مزايا آن افزايش کارآئي ، انعطاف پذيري ، قابليت استفاده مجدد و توان پشتيباني ارتقاء کارآئي همزمان با افزايش تعداد کاربران، مخفي نمودن پيچيدگيها ي موجود با توجه به ماهيت پردازشهاي توزيع شده از ديد کاربران، ارائه امکانات لازم به برنامه نويسان بمنظور طراحي و پياده سازي نرم افزارها با يک رويکرد مشابه، ارائه امکانات لازم به برنامه نويسان بمنظور تبعيت از روشهاي يکسان براي دستيابي به دادهها ميباشد. از ديد مهندسي نرم افزار ، معماري سيستم شامل کليه موارد لازم براي توسعه نرم افزار مي باشد، نوع متدلوژي ميزان پرداختن به جزئيات را مشخص مي کند. مثلا جزئياتي که در روشهاي agile بکار ميرود بسيار کمتر از متدلوژيها سنگين وزن مي باشد. اگر بر اساس متدلوژي RUP مي خواهيم يک سند معماری نرم افزار را براي نرم افزار خود تهيه کنيم. بايد ديدگاههايمان را پيادهسازي نمائيم و سپس بر اساسCustomization که انجام داده ايم نيازهاي غير وظيفه اي را در آن بگنجانيم ، در متدلوژي اين قسمت را ممکن است حذف کنيم يا ديدگاهها را خيلي خلاصه تر ترسيم نمائيم. در متدلوژي ssadm اصلا نيازي نداريم که وارد جزئيات پياده سازي بصورتي که معين کنيم هر مولفه بر روي چه سخت افزاري نصب مي شود شويم. بر اساس متدلوژيهاي مختلف جزئيات مختلفي را براي تهيه معماري نرم افزار خواهيم داشت. |
|||||
|
|||||
|
|
|
||||
|
A) Product Specification Document
1. Document status sheet Issue Date Modified Items 2. Product description Material Specification Summary 3. Product Properties Parameters Accuracy Availability Tolerances 4. Product Process Properties Method Algorithm 5. Quality standards Properties Production Validation 6. Other specific properties Historical archive Visualization standards 7. Product format specification Dataset name Data type Position Unit Description 8. Software release history 9. Implementation details 10. List of known issues
B) Architectural Specification Document 1. Architecture Overview Identification 2. Goals and Objectives Compatibility and Interoperability Extensibility Portability Platform Independence 3. The Architectural Model Architectural Concepts and Representations 4. Architecture Block Diagram 5. Architecture Block Diagram Description 6. Relationship between modules 7. System levels view (Upper-level / Mid-layer / Low level) 8. System Structural Overview Software Component View Architectural component block diagram 9. Functionality and Interfaces and other specific properties
C) Module Specification Document
To reduce the complexity of the system, a system can be decomposed into a set of modules, each of which performs a certain task in the system. 1. Module Specification Module title / Module level Purpose: The Module Specification is a markup language for defining the modules of a modular synthesizer. Comparison: Differences / Planned improvements 2. Describing Module Document The root element always contains a version attribute used to determine the version of this Specification 3. Interface Module Specifications Interface Modules (IM) are modules that communicate between the application software and the environment in which it operates 4. Module Hierarchy To the definition of a module also belongs their relation to each other.
D) HIGH-LEVEL DESIGN SPECIFICATION DOCUMENT
1. DETAILED DESCRIPTION OF COMPONENTS NOTE: This section is the main focus, the detailed design. This section will provide most of the basis for implementing the product. 2. REUSE AND RELATIONSHIPS TO OTHER PRODUCTS 3. PERIPHERAL INTERFACES PERIPHERAL INTERFACES FLOW MAIN PROCESS FLOW INTERRUPT SERVICE ROUTINE CALCULATION ROUTINE FRAME ROUTINE (EACH FUNCTION) 4. PSEUDO CODE FOR COMPONENT 5. APPENDICES
E) LOW-LEVEL DESIGN SPECIFICATION DOCUMENT
Low-Level Overview: This is the most important section of this document. Follow the template instructions closely with regard to formatting and content. 1. Low level software specifications To facilitate the implementation of the services software, the hardware has to be augmented with low level software like Operating System, device drivers, supporting applications and a software development environment. This section describes the specifications for these lower level software components. The specifications for the higher level software, used for development of the actual connectivity, services and application are described in the following chapter. 2. Application specifications Programming Language Target Platform Data to voice Video 3. Low-Level Component Design Description Data Public Operations |
|||||
|
|||||
 |
 |
||||
|
نوشته های پیشین آذر 1388 اردیبهشت 1388 |
|||||
|
|||||
