mamizadeh
سه شنبه 05 آبان 1388, 13:22 عصر
متدولوژی Ideal Mix
با سلام در ابتدا خدمت دوستان عرض کنم که این متدولوژی شاید نباشه چون از ادغام متدولوژی های Scrum, Iterative process, Personal software process and team software process, XP و تا حدودی تجربیات شخصی خودم به وجود آمده است. که به مشکلاتی در ارائه نرم افزار بر خورده و سعی کرده ام که درست کنم و نتیجه چنین چیزی شده است.
در متدولوژی Iterative process ، دو نوع محصول داریم Actual و by-product ، محصولاتی که باعث موفقیت پروژه می شود Actual و آن عامل هایی که باعث به وجود آمدن Actual ها می شود by-product ها هستند.
در حالی که در متدولوژی Personal software process, Tame Software process موفقیت پروژه بستگی به فیش هایی دارد که هر تیم کاری باید به عنوان گزارش کاری برای خود بنویسند و در آخر هر دوره مدیر آن پروژه فیش ها را بررسی و برای بهینه سازی روند پیشرفت پروژه مورد نقدو بررسی قرار می دهد.
و از طرفی در متدلوژی Scrum پروژه به Sprint های مختلف تجزیه می شود (به شرطی که هر sprint يك معماري قابل تغيير و قابل پیش برد به وجود آورند) و فهرست تكاليف در هر Sprint به Backlog مشهور است كه تكاليف تيم عملياتي در هر Sprint را مشخص مي كند.
توجه:
در این روش برگه هایی با عنوان موارد اجرایی به هر مجری Sprint اعلان می شود که این برگه ها شامل مواردی هستند که مجریان Sprint ها باید انجام بدهند.
حال چنانچه اگر ما متدولوژی Scrum را با متدولوژی PSP مقایسه و ادغام کنیم باید به متدولوژی Scrum این مطلب را از PSP اضافه کنیم که هر مجری Sprint باید دقیقا عمکلرد خود را هر روز کاری نوشته و دقیقا مستند کند و در آخر کار هر دوره از Sprint ها (که هر Sprint تقریبا زمانی در حدود یک تا یک ماه است) یک گزارش گیری دقیق باید از مقایسه Backlog ها و مستندات کاری خود داشته باشد. و نام آن را Progress انتخاب کند.
در متدولوژی Scrum برنامه تحلیل شده و به Sprint ها تقسیم می شود و در هر بار تکرار، Sprint ها بهینه تر می شوند و از طرفی در متدولوژی Iterative process روند تولید نرم افزار در 8 فاز صورت می گیرد که هشت فاز متدولوژی iterative process عبارتند از:
1) اولين مرحله اين رويه جمع آوري اطلاعات از كاربر است. (جمع آوری اطلاعات)
2) در مرحله بعدي سيستم به صورت جامع تحليل و آناليز ميگردد تا اعضاي تيم با مدل كلي سيستم آشنا گردند. (تحلیل نیاز ها)
3) در مرحله تحليل، نرم افزار به صورت كلي مورد بررسي قرار مي گيرد . (تحلیل سیستم)
4) در مرحله معماری سیستم، اجزاي تشكيل دهنده سيستم مشخص مي شوند و كارايي هاي سيستم مشخص مي گردند. (معماری سیستم)
5) در مرحله طراحي تمامي اجزاي سيستم طراحي مي شوند. (طراحی)
6) در مرحله بعد كدهاي سيستم نوشته مي شود. (پیاده سازی هر بخش)
7) وقتي اين مرحله تمام شد و كدهاي سيستم نوشته شد، اعضاي تيم در فاز جمع بندي كدهاي سيستم را با توجه به مراحل اول تا پنج مرور مي كنند. (جمه بندی بخش ها و یکپارچه سازی سیستم)
8) در مرحله آخر نيز اعضاي گروه آن را امتحان مي كنند تا اولاً نيازهاي كاربران را تأمين كرده باشد و ثانياً فاقد هرگونه اشكال باشد. (تست سیستم)
سیستم زمانی به پایان می رسد که فاقد هر گونه عیب و ایرادی باشد.
از فاز ها تکرار پذیر هستند حال اگر ما نه از ابتدای پروژه بلکه در فاز معماری سیستم تقسیمات پروژه را انجام دهیم و نام هر بخش را Part نام گذاری کنیم و دوباره این 8 فاز را برای هر Part در نظر بگیریم به شرطی که دیگر هر بخش را تقسیم نکنیم. نتیجه بهتری می توان مشاهده کرد که هم قابل استناد است و هم قابل تکرار و اگر چهار فاز اول Iterative process با نماد های UML استفاده کنیم حتی می توان قابیلت اطمینان از پیشرفت و Upgrade نرم افزار را نیز داشت و همچنین این امکان را به گروه (Sprint ها) می دهد که با یک زبان مشخص با همدیگر ارتباط داشته باشند. که این امکان در Scrum به سختی دیده می شود.
حال چه باید بکنیم:
فرض کنید پروژه ای سفارش شده است حال
1) نیاز های پروژه یافت شوند
2) نیاز ها بررسی می شوند که آیا امکان مکانیزه شدن وجود دارد یا نه و سپس این نیاز ها تحلیل شده و در فایل Visio با عنوان نیاز های اصلی سیستم ذخیره سازی گردد.
3) این فایل توسط تیم تحلیل گر پروژه تحلیل و بررسی می گردد و در فایل Visio با عنوان تحلیل کلی سیستم ذخیره سازی می شوند.
4) در معماری سیستم بر اساس مستندات فاز قبلی سیستم به اجزایی برای ساده سازی پروژه تجزیه می شوند که هز جزء را Part می نامیم (Part ها همان ادغام شده حالت Sprint ها با متدولوژی Iterative process هستند) و تکالیف هر Part را در قالب یک سناریو و Visio Diagram مشتند می کنیم که این مستندات را Progress Element می نامیم.
5) هر پارت توسط گروه های مجزایی طبق مستندات ارائه شده طراحی می شوند. و پایان هر روز کاری باید مدیران گذارش کاری خود را تهیه کنند.
6) هر Part پیاده سازی می شود و در پایان هر روز کاری گزارش کاری نوشته می شود.
7) در پایان دوره Part ها یکپارچه سازی انجام می گیرد و فیش های گزارش کاری با تکالیف هر Part مقایسه و بررسی می شود و نقاط ضعف و قوت ثبت می گردد تا در دور بعد از نقاط ضعف بر طرف و نقاط قوت تقویت شوند.
8) سیستم تست می شود و نقصان های پروژه بررسی گردیده و این نقص ها در قالب نیازهای جدید به فاز دوم ارسال می گردد و حلقه تکرار می شود.
نکاتی درباره این حلقه:
این روند تا زمانی ادامه دارد که نرم افزار بدون ایراد ظاهر گردد و نیاز های مشتری را تماما بر طرف کند.
در پروژه های کوچک که نیاز به طراحی زیادی نمی خواهد می توان دو فاز 5 و 6 را ادغام کرد.
فیش گزارش کاری روزانه به شرح ذیل متن می باشد:
مورخه روز
5/08/88 سه شنبه
از ساعت تا ساعت خلاصه کار های انجام شده مشکلات
حال
دوستان و اساتید محترم اگر نظر و پیشنهادی برای این متدولوژی دارند بهتر است بیان کنند تا من و دیگران نیز از تجربیات شما استفاده کرده و برای پیشبرد این متدولوژی قدم برداریم. باشد که پروژه های ایرانیان بهترین شوند.
با تشکر
ممی زاده
www.mamizadeh.com
با سلام در ابتدا خدمت دوستان عرض کنم که این متدولوژی شاید نباشه چون از ادغام متدولوژی های Scrum, Iterative process, Personal software process and team software process, XP و تا حدودی تجربیات شخصی خودم به وجود آمده است. که به مشکلاتی در ارائه نرم افزار بر خورده و سعی کرده ام که درست کنم و نتیجه چنین چیزی شده است.
در متدولوژی Iterative process ، دو نوع محصول داریم Actual و by-product ، محصولاتی که باعث موفقیت پروژه می شود Actual و آن عامل هایی که باعث به وجود آمدن Actual ها می شود by-product ها هستند.
در حالی که در متدولوژی Personal software process, Tame Software process موفقیت پروژه بستگی به فیش هایی دارد که هر تیم کاری باید به عنوان گزارش کاری برای خود بنویسند و در آخر هر دوره مدیر آن پروژه فیش ها را بررسی و برای بهینه سازی روند پیشرفت پروژه مورد نقدو بررسی قرار می دهد.
و از طرفی در متدلوژی Scrum پروژه به Sprint های مختلف تجزیه می شود (به شرطی که هر sprint يك معماري قابل تغيير و قابل پیش برد به وجود آورند) و فهرست تكاليف در هر Sprint به Backlog مشهور است كه تكاليف تيم عملياتي در هر Sprint را مشخص مي كند.
توجه:
در این روش برگه هایی با عنوان موارد اجرایی به هر مجری Sprint اعلان می شود که این برگه ها شامل مواردی هستند که مجریان Sprint ها باید انجام بدهند.
حال چنانچه اگر ما متدولوژی Scrum را با متدولوژی PSP مقایسه و ادغام کنیم باید به متدولوژی Scrum این مطلب را از PSP اضافه کنیم که هر مجری Sprint باید دقیقا عمکلرد خود را هر روز کاری نوشته و دقیقا مستند کند و در آخر کار هر دوره از Sprint ها (که هر Sprint تقریبا زمانی در حدود یک تا یک ماه است) یک گزارش گیری دقیق باید از مقایسه Backlog ها و مستندات کاری خود داشته باشد. و نام آن را Progress انتخاب کند.
در متدولوژی Scrum برنامه تحلیل شده و به Sprint ها تقسیم می شود و در هر بار تکرار، Sprint ها بهینه تر می شوند و از طرفی در متدولوژی Iterative process روند تولید نرم افزار در 8 فاز صورت می گیرد که هشت فاز متدولوژی iterative process عبارتند از:
1) اولين مرحله اين رويه جمع آوري اطلاعات از كاربر است. (جمع آوری اطلاعات)
2) در مرحله بعدي سيستم به صورت جامع تحليل و آناليز ميگردد تا اعضاي تيم با مدل كلي سيستم آشنا گردند. (تحلیل نیاز ها)
3) در مرحله تحليل، نرم افزار به صورت كلي مورد بررسي قرار مي گيرد . (تحلیل سیستم)
4) در مرحله معماری سیستم، اجزاي تشكيل دهنده سيستم مشخص مي شوند و كارايي هاي سيستم مشخص مي گردند. (معماری سیستم)
5) در مرحله طراحي تمامي اجزاي سيستم طراحي مي شوند. (طراحی)
6) در مرحله بعد كدهاي سيستم نوشته مي شود. (پیاده سازی هر بخش)
7) وقتي اين مرحله تمام شد و كدهاي سيستم نوشته شد، اعضاي تيم در فاز جمع بندي كدهاي سيستم را با توجه به مراحل اول تا پنج مرور مي كنند. (جمه بندی بخش ها و یکپارچه سازی سیستم)
8) در مرحله آخر نيز اعضاي گروه آن را امتحان مي كنند تا اولاً نيازهاي كاربران را تأمين كرده باشد و ثانياً فاقد هرگونه اشكال باشد. (تست سیستم)
سیستم زمانی به پایان می رسد که فاقد هر گونه عیب و ایرادی باشد.
از فاز ها تکرار پذیر هستند حال اگر ما نه از ابتدای پروژه بلکه در فاز معماری سیستم تقسیمات پروژه را انجام دهیم و نام هر بخش را Part نام گذاری کنیم و دوباره این 8 فاز را برای هر Part در نظر بگیریم به شرطی که دیگر هر بخش را تقسیم نکنیم. نتیجه بهتری می توان مشاهده کرد که هم قابل استناد است و هم قابل تکرار و اگر چهار فاز اول Iterative process با نماد های UML استفاده کنیم حتی می توان قابیلت اطمینان از پیشرفت و Upgrade نرم افزار را نیز داشت و همچنین این امکان را به گروه (Sprint ها) می دهد که با یک زبان مشخص با همدیگر ارتباط داشته باشند. که این امکان در Scrum به سختی دیده می شود.
حال چه باید بکنیم:
فرض کنید پروژه ای سفارش شده است حال
1) نیاز های پروژه یافت شوند
2) نیاز ها بررسی می شوند که آیا امکان مکانیزه شدن وجود دارد یا نه و سپس این نیاز ها تحلیل شده و در فایل Visio با عنوان نیاز های اصلی سیستم ذخیره سازی گردد.
3) این فایل توسط تیم تحلیل گر پروژه تحلیل و بررسی می گردد و در فایل Visio با عنوان تحلیل کلی سیستم ذخیره سازی می شوند.
4) در معماری سیستم بر اساس مستندات فاز قبلی سیستم به اجزایی برای ساده سازی پروژه تجزیه می شوند که هز جزء را Part می نامیم (Part ها همان ادغام شده حالت Sprint ها با متدولوژی Iterative process هستند) و تکالیف هر Part را در قالب یک سناریو و Visio Diagram مشتند می کنیم که این مستندات را Progress Element می نامیم.
5) هر پارت توسط گروه های مجزایی طبق مستندات ارائه شده طراحی می شوند. و پایان هر روز کاری باید مدیران گذارش کاری خود را تهیه کنند.
6) هر Part پیاده سازی می شود و در پایان هر روز کاری گزارش کاری نوشته می شود.
7) در پایان دوره Part ها یکپارچه سازی انجام می گیرد و فیش های گزارش کاری با تکالیف هر Part مقایسه و بررسی می شود و نقاط ضعف و قوت ثبت می گردد تا در دور بعد از نقاط ضعف بر طرف و نقاط قوت تقویت شوند.
8) سیستم تست می شود و نقصان های پروژه بررسی گردیده و این نقص ها در قالب نیازهای جدید به فاز دوم ارسال می گردد و حلقه تکرار می شود.
نکاتی درباره این حلقه:
این روند تا زمانی ادامه دارد که نرم افزار بدون ایراد ظاهر گردد و نیاز های مشتری را تماما بر طرف کند.
در پروژه های کوچک که نیاز به طراحی زیادی نمی خواهد می توان دو فاز 5 و 6 را ادغام کرد.
فیش گزارش کاری روزانه به شرح ذیل متن می باشد:
مورخه روز
5/08/88 سه شنبه
از ساعت تا ساعت خلاصه کار های انجام شده مشکلات
حال
دوستان و اساتید محترم اگر نظر و پیشنهادی برای این متدولوژی دارند بهتر است بیان کنند تا من و دیگران نیز از تجربیات شما استفاده کرده و برای پیشبرد این متدولوژی قدم برداریم. باشد که پروژه های ایرانیان بهترین شوند.
با تشکر
ممی زاده
www.mamizadeh.com