نرم افزار فروش

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

2. روشهای تهیه نرم افزارهای سازمانی

3. تغییر رویه‌ها بومی سازی پکیج برپاسازی سیستم جدید انتخاب جایگزینها خرید بسته نرم افزاری آماده

4. مزایا: • بسته‌ها عموماً تست خود را پس داده اند. • تجارب استفاده از آنها در شرکتهایی که قبلاً نصب شده اند قابل ارزیابی است. • خریدار دغدغه دانش مورد استفاده از آنرا نخواهد داشت و صرفاً قابلیتها و میزان کارایی خروجی آنرا ارزیابی خواهند نمود. • فروشنده صحت کارکرد و عاری بودن از خطای آنرا تضمین نموده و معمولاً تا چندین سال پشتیبانی آنرا به عهده خواهد گرفت. • ... • معایب: • قابلیت بومی سازی آنها محدود می‌باشد. • قابلیت توسعه آنها در آینده محدود و پرهزینه است. • ممکن است سیستمها بصورت جزیره ای عمل نموده و یکپارچگی آنها کاهش یابد. • .... خرید بسته نرم افزاری آماده

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

6. نرم‌افزار عموماً تركيبي از محصولات و موقعيتهايی شناخته می‌شود که حتی در شرايط بسيار بحراني و طاقت فرسا، قابليت اطمينان زيادی از آن انتظار می‌رود. چنين برنامه‌هايی شامل هزاران خط کد هستند، که از نظر پيچيدگی با پيچيده‌ترين ماشينهای مدرن قابل مقايسه‌اند. به‌عنوان مثال يک هواپيمای مسافربری چند ميليون قطعه فيزيکی دارد (و يک شاتل فضايی حدود ده ميليون بخش دارد)، در حالی که نرم‌افزار هدايت چنين هواپيمايی می‌تواند تا ۴ ميليون خط کد داشته باشد. مهندسی نرم افزار

7. وابستگي شديد توسعه و تغيير نرم‌افزار به فرد يا افراد تيم توليدكننده • صف انتظارات و نيازهاي تغيير و عدم توان پاسخگويي موثر تيم توسعه به اين نيازها با گذشت زمان • احساس نياز به توسعه و گسترش دائمي امكانات و عمليات نرم‌افزار • به خطر افتادن آينده يكپارچگي سيستم‌ها • عدم امكان مستندسازي دانش پنهان شده در ميان كدهاي نرم‌افزار • بروز خطاهاي پي‌درپي بدليل فراموش شدن طراحي‌هاي گذشته • کاهش اطمينان و اعتماد کارفرما نرم افزار بدون مهندسی نرم افزار

8. عدم درک صحيح نيازهای کاربران ومنسوخ شدن سريع آنها • تحميل هزينه‌های بالای نگهداری و ارتقاء نرم افزار به سازمان • عدم عملکرد صحيح نرم‌افزارها در شرايط بحرانی • قالب اشتباه صفحات که ظاهر آنها را بسيار ناخوشايند کرده باعث سردرگمی کاربران می‌شود • آموزش ناقص كاربران و عدم شفافيت فرآيندهاي پس زمينه نرم‌افزار • عدم اطلاع مديران از امكاناتي كه در نرم‌افزار در اختيار كاربران قرار مي‌گيرد • بروز مشكلات امنيتي و فقدان طرح امنيت اطلاعات در نرم‌افزار • عدم وجود زبان مشترك بين اعضاي تيم و ذي‌نفعان پروژه نرم افزار بدون مهندسی نرم افزار

9. فرآیند عمومی مهندسی نرم افزار

10. ? کجای فرآیند تولید نرم افزار هستیم؟

11. مستندات تحویلی به دفتر تحليل سيستم معاونت فروش

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

13. عدم ارائه مستندات نرم افزار جديد كه سيستم را به سمت قائم بفرد شدن پيش خواهد برد • جلسات پرزنت نرم افزار به جلساتي جهت گرفتن درخواست ازكاربران، و Confirm درك از فرآيند و در جاهائي به ارائه پيشنهاد جهت بهبود وضعيت جاري، بيشتر شبيه بود • عملكرد طراحي انجام شده ، هنوز تست نگرديده و زير بار اطلاعات واقعي نرفته • روشها و متد هاي كد نويسي استفاده شده در نرم افزار جديد ، جهت تست و اظهار نظر ارائه نشده • در يك سري از موارد كاملا“ جزئي كه بصورت تكنيكي مطرح شده، تجربه خلاف آنرا ثابت كرده نگاه ICT به نرم افزار جديد

14. فاز 1 : تحلیل: Vision، طرح تجاري، تنظيم قلمرو پروژه، فهرست ريسك‌ها، طرح توليد نرم‌افزار، طرح تكرار، ریسکها، زمانبندی، هزینه، پروپوزال، طرح تضمین کیفیت، مدل سازمانی، فرهنگ لغات سازمانی، ... • فاز 2 : طراحی:سند معماري نرم‌افزار (SAD)، مدل پياده سازی، پروتوتايپ، پلن طرح تكرار براي فاز ساخت، استاندارها، مدل طراحي و مدل داده، سناريوها، اولویتها، Use Caseها، عاملين (Actors)، نمودارهاي UML، ... • فاز 3 : پیاده سازی:طرح استقرار، سيستم قابل اجرا آماده تست بتا، طرح تكرار فاز انتقال، ... • فاز 4 : استقرار:محصول نهايي، پلن نهايي استقرار، مواد آموزشي و مستندات و خروجي هاي لازم براي نگهداري و كاربري، طرح مدیریت تغییرات، ... محصولات فازهای توسعه نرم افزار؟

15. متدولوژی‌های توسعه نرم افزار

16. طول عمر کامل توسعه تک منظوره چشم انداز وسیع متدولوژی‌های توسعه نرم افزار متدولوژی مقطعی

17. متدولوژی EUP

18. متدولوژی EUP

19. متدولوژی EUP

20. Vision • Glossary • Use-Case Model • UML Models • Supplementary Specifications • Test Plan • Test Case • Test Suite (including Test Script, Test Data) • Test Log • Test Evaluation Summary • Implementation Model • Product (Deployment Unit) • Release Notes مستندات متدولوژی RUP

21. متدولوژيXP استفاده از ابزارهاي ساده را براي توليد نرم­افزار، توصيه مي­كند. • متدولوژي XP براي پروژه­هاي بزرگ ناموفق است و فقط براي پروژه­هاي كوچك كاربرد دارد. • در متدولوژي XP، حدوداً 20 تا 40 درصد اشكالات ساختاري پيدا مي­شود. • در ابتداي كار اعضاي گروه حتي كاربران نهايي، جلسه­اي را تشكيل داده و اولويتهاي پروژه را مشخص مي­كنند. • در صورت بروز مشكل براي يكي از برنامه­نويسان، زمان تحويل پروژه به تاخير ميفتد. • در متدولوژیXP مرحله­اي بنام طراحي وجود ندارد و نرم­افزار توليد­شده فاقد طراحي سازمان­يافته است و قطعا بروز مشكل پس از تحويل نرم­افزار پيش خواهد آمد. • در متدولوژيXP مستندات مناسبي ايجاد نمي­شود. • در متدولوژيXP هزينه توليد نرم­افزار پايين است. • متدولوژي XP داراي چهار فاز اصلي است كه عبارتند از : • زمانبندي پروژه • طرح ابتدايي • برنامه­نويسي و توليد كد • تست كدهاي نوشته­شده برنامه ویژگی‌های متدولوژی XP

22. تحلیل: Vision، طرح تجاري، تنظيم قلمرو پروژه، فهرست ريسك‌ها، طرح توليد نرم‌افزار، طرح تكرار، ریسکها، زمانبندی، هزینه، پروپوزال، طرح تضمین کیفیت، مدل سازمانی، فرهنگ لغات سازمانی، ... • طراحی:سند معماري نرم‌افزار (SAD)، مدل پياده سازی، پروتوتايپ، پلن طرح تكرار براي فاز ساخت، استاندارها، مدل طراحي و مدل داده، سناريوها، اولویتها، Use Caseها، عاملين (Actors)، نمودارهاي UML، ... محصولات فازهای توسعه نرم افزار؟

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

24. اگر فاز شناخت به اتمام رسیده است، چگونه در این تاریخ نیاز به اطلاعات پایه ای مطرح می شود که راه اندازی سیستم موکول به تحویل آن می‌شود؟ اگر واقعاً این نیاز آنقدر اساسی است که بایستی در کدنویسی لحاظ شود چرا تاکنون مطرح نشده است و چرا در زمان شناخت سیستم و طی مصاحبه ها و بررسی سیستم قبلی این شناخت حاصل نشده است؟ • در صورت اعلام نیاز به اطلاعات چرا هیچگونه روش مستند و فرم مورد توافق و استانداردی برای این نوع درخواستها طراحی نشده است؟ • تا این لحظه برای پروژه ای در این سطح و اندازه و با این حساسیت خاصی که برای سازمان دارد چه مستنداتی تهیه شده است؟ دانش تولید آن کجا ذخیره شده است؟ به تایید چه افرادی رسیده است؟ • آیا مدیریت و کاربران مجموعه فروش خروجی‌ها و مستندات فاز شناخت تیم توسعه و صحت و کمال آنرا تایید نموده اند؟ پرسشهای اساسی؟

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