Más contenido relacionado


  1. RUP RATIONAL UNIFIED PROCESS Behnam Akbari 06 Oct 2014 1
  2. Topics  What is RUP?  RUP Overview.  RUP phases & Disciplines.  RUP good practice. 2
  3. What is the Rational Unified Process? 3
  4. What is the Rational Unified Process?  The Rational Unified Process® or RUP® is a software engineering process developed by Rational Software, IBM  It provides a disciplined approach to assigning tasks and responsibilities within a development organization.  Its goal is to ensure the production of high-quality software that meets the needs of its end-users, within a predictable schedule and budget.  It is a guide for how to effectively use the Unified Modeling Language(UML).  The Rational Unified Process is a configurable process. No single process is suitable for all software development.  The Unified Process fits small development teams as well as large development organizations. 4
  5. RUP Overview:  described from 2 perspectives  A dynamic perspective that shows phases over time;  A static perspective that shows process activities; 5
  6. RUP Overview:  The first dimension represents time and shows the lifecycle aspects of the process as it unfolds. – it is enacted, and it is expressed in terms of phases, iterations, and milestones.  The second dimension represents the static aspect of the process. – how it is described in terms of process components, disciplines, activities,workflows, artifacts, and roles.  The graph shows how the emphasis varies over time. – For example, in early iterations, spend more time on requirements, and in later iterations, spend more time on implementation. 6
  7. RUP Phases:  TheRational Unified Process divides one development cycle in four consecutive phases. The software lifecycle is broken into cycles, each cycle working on a new generation of the product. • Inception phase • Elaboration phase • Construction phase • Transition phase  Each phase is concluded with a well-defined milestone ,a point in time at which certain critical decisions must be made, and therefore key goals must have been achieved 7
  8. Inception Phase:  During the inception phase, you establish the business case for the system and delimit the project scope. To accomplish this you must identify all external entities with which the system will interact (actors) and define the nature of this interaction at a high-level. This involves identifying all use cases.  Milestone: • Stakeholder concurrence on scope definition and cost/schedule estimates. • Requirements understanding as evidenced by the fidelity of the primary use cases. • Credibility of the cost/schedule estimates, priorities, risks, and development process. • Depth and breadth of any architectural prototype that was developed. • Actual expenditures versus planned expenditures.  The project may be cancelled or considerably re-thought if it fails to pass this milestone. 8
  9. Elaboration Phase:  Elaboration is the second of the four phases in the RUP approach. The goal of the Elaboration phase is to define and baseline the architecture of the system in order to provide a stable basis for the bulk of the design and implementation effort in the Construction phase. The architecture evolves out of a consideration of the most significant requirements (those that have a great impact on the architecture of the system) and an assessment of risks.  ?  Is vision Stable?  Is architecture stable?  Does executable show true risk management?  Is next phase (Construction) plane is accurate?  Does current vision could be achieved?  Is the actual resource expenditure versus planned expenditure acceptable? 9
  10. Construction Phase:  During the construction phase, all remaining components and application features are developed and integrated into the product, and all features are thoroughly tested.  System design, programming and testing.  The Construction phase ends with an important project milestone, which is used to determine whether the product is ready to be deployed into a beta test environment by answering (among others) the following questions • Is this product release stable and mature enough to be deployed in the user community? • Are all stakeholders ready for the transition into the user community? • Are the actual resource expenditures versus planned expenditures still acceptable? 10
  11. Transition Phase:  The transition phase is entered when a baseline is mature enough to be deployed in the end-user domain.  Once the product has been given to the end user, issues usually arise that require you to develop new releases, correct some problems, or finish the features that were postponed. • “beta testing” to validate the new system against user expectations • conversion of operational databases • training of users and maintainers • roll-out the product to the marketing, distribution, and sales teams 11
  12. Iterations:  Each phase in the Rational Unified Process can be further broken down into iterations. An iteration is a complete development loop resulting in a release (internal or external) of an executable product, a subset of the final product under development, which grows incrementally from iteration to iteration to become the final system. • Risks are mitigated earlier • Change is more manageable • The project team can learn along the way • Better overall quality 12
  13. Static Aspect of RUP:  Static dimension of RUP consist of Some Roles ,Activities , Artifacts and workflows. Workflow is a way to describe meaningful sequences of activities that produce some valuable result and to show interactions between roles.Roles in RUP are assigned to Workers , and preparing an artifact assign to Roles . Activities shows how a Role will do an assignment.  Static Elements • Worker (Who) • Activity (How) • Artifact (What) • Workflows or Disciplines (when) 13
  14. Worker,Activity ,Artifact: 14
  15. workflows in the RUP:  Business modelling: The business processes are modelled using business use cases.  Requirements :Actors who interact with the system are identified and use cases are developed to model the system requirements.  Analysis and design: A design model is created and documented using architectural models, component models, object models and sequence models.  Implementation: The components in the system are implemented and structured into implementation sub-systems. Automatic code generation from design models helps accelerate this process.  Testing: Testing is an iterative process that is carried out in conjunction with implementation. System testing follows the completion of the implementation. 15
  16. workflows in the RUP:  Deployment:A product release is created, distributed to users and installed in their workplace.  Configuration and change management:This supporting workflow managed changes to the system  Project management:This supporting workflow manages the system development  Environment:This workflow is concerned with making appropriate software tools available to the software development team. 16
  17. RUP Good Practice:  Develop software iteratively Plan increments based on customer priorities and deliver highest priority increments first.  Manage requirements Explicitly document customer requirements and keep track of changes to these requirements.  Use component-based architectures Organize the system architecture as a set of reusable components.  Visually model software Use graphical UML models to present static and dynamic views of the software. 17
  18. RUP Good Practice:  Verify software quality Ensure that the software meet’s organizational quality standards.  Control changes to software Manage software changes using a change management system and configuration management tools. 18
  19. END 19

Hinweis der Redaktion

  1. یک فرآیند مهندسی نرم افزار است که یک روش منظم برای تعیین وظایف و مسؤولیت ها در یک سازمان تولید کننده نرم افزار ارائه می دهد. هدف آن، اطمینان از تولید نرم افزار با کیفیت بالاست که نیازهای کاربران نهایی را با زمان بندی و بودجه ی قابل پیش بینی برآورده سازد. همانطور که از این تعریف پیداست، پروسه تولید نرم افزار روشی است که برای بهتر انجام شدن روند انجام پروژه های نرم افزاری از آن استفاده می شود . تا کنون در صنعت نرم افزار Rapid Prototyping ،Waterfall : روشهای گوناگونی برای تولید نرم افزار ارائه شده اند مانند برای هر نوع از این فرآیند ها .Object Oriented و Iterative & Incremental ،Spiral ،(RAD1) Oracle ،SSADM هم تا کنون گروه ها و شرکت های مختلف فرآیندهایی معرفی کرده اند، مانند در زیر چند روش تولید . RUP و Uinfied Process ،Booch ،Oracle CDM ،Case * Method نرم افزار که شناخته شده تر هستند بصورت مختصر معرفی شده اند. پرکاربردترین فرآیند تولید و توسعه ،Rational متدولوژی ارائه شده توسط شرکت ،RUP پذیرفته شده IT نرم افزاری در دنیای کنونی است و به عنوان یک استاندارد صنعتی بالفعل در دنیای است. مزیت بزرگ این متدولوژی، استفاده از روش تکرار در تولید و مدیریت تولید نرم افزار است که این امر، امکان تولید مبتنی بر کاهش ریسک و مواجه با مشکلات اصلی در ابتدای کار و در نتیجه احتمال موفقیت بیشتر را فراهم می کند.
  2. • محور افقی نمایانگر زمان است و با پیشرفت خود جنبه های چرخه ی حیات فرآیند را نشان می دهد. (بعد اول) • محور عمودی نشان دهنده ی دیسیپلین ها است که فعالیت ها را با استفاده از ماهیتشان به صورت منطقی دسته بندی می کند. (بعد دوم) در سطرهای افقی نمایش داده شده اند و فازها در ستون های عمودی . RUP دیسیپلین های همانگونه که مشاهده می شود وزن فعالیت های دیسیپلین های مختلف با توجه به تکرارها و فازها متغییر است . و همانگونه که پیش از این گفته شد در هر فاز ممکن است یک یا چند تکرار وجود داشته باشد و در هر تکرار عملیات دیسپیلین های مختلف انجام می گیرند.
  3. انجام هر پروژه به چند قسمت تقسیم می شود که به هر کدام از این قسمت ها فاز گفته م ی شود. فازهای یک پروژه نشان دهنده تاکید بیشتر بر روی زمین ه های ک اری مختلف یک پروژه می باشند.
  4. Milestoneمجموعه ای از دست آوردها –با ویژگی های مشخص - که رسیدن به آنها مجوزی برای رفتن به مرحله بعدی انجام پروژه می باشد. هدف اصلی این فاز دستیابی به توافق میان کلیه ی ذینفعان بر روی اهداف چرخه ی حیات پروژه است. اهداف اصلی فاز آغازین شامل موارد زیر است : • بدست آوردن محدوده نرم افزاری پروژه و محدودیت های آن که شامل یک دید عملیاتی، معیار پذیرش و اینکه چه چیز باید در محصول باشد و چه چیز نباید باشد، می شود. مشخص کردن Use-Caseهای اساسی سیستم، سناریوهای اصلی عملیات که مسائل مربوط به طراحی اصلی را ایجاد می کند. • نمایش و شاید توضیح حداقل یک معماری کاندیدا برای بعضی سناریوهای اصلی • برآورد هزینه و زمان کلی برای کل پروژه
  5. هدف فاز جزئیات تعیین معماری کلی سیستم به منظور فراهم آوردن یک زمینه ی مناسب برای قسمت عمده ی طراحی و پیاده سازی در فاز ساخت است. • اطمینان از اینکه معماری، نیازمندی ها و طرح ها به اندازه ی کافی پایدارند و ریسک ها به اندازه ی کافی کاهش یافته اند بطوریکه بتوان هزینه و زمان بندی لازم برای تکمیل تولید را پیش بینی کرد . برای اکثر پروژه ها، گذر از این مرحله ی مهم مانند انتقال از یک عملیات سبک و سریع و با ریسک پایین به یک عملیات با هزینه و ریسک بالا همراه با اجبار سازمانی است. • بیان همه ی ریسک های پروژه که از نظر ساختاری اهمیت دارند. • ایجاد یک معماری پایه، مشتق شده از سناریوهای مهم که از لحاظ ساختاری اهمیت دارند، که این معماری ریسک های فنی عمده پروژه را نیز مشخص می کند. • تولید یک نمونه ی اولیه ی تکاملی از مولفه های با کیفیت تولیدی خوب، و همچنین یک یا چند نمونه ی اولیه ی اکتشافی و نمونه های اولیه ی غیر قابل استف اده
  6. هدف این فاز واضح سازی نیازمندی های باقیمانده و تکمیل تولید سیس تم بر اساس معماری مبنا می باشد. فاز ساخت به نوعی یک فرآیند ساخت 1 است که در آن تأکید بر مدیریت منابع و کنترل عملیات به منظور بهینه سازی هزینه ها، زمان بندی ها و کیفیت است. اهداف اصلی فاز ساخت شامل موارد زیر می باشد : • کمینه کردن هزینه های تولید با بهینه سازی منابع و پرهیز از دور انداختن و دوباره کاری غیر ضروری • دستیابی هرچه سریعتر به کیفیت کافی • دستیابی هر جه سریعتر به ویرایش های مفید (آلفا، بتا و سایر نسخه های تست) • کامل کردن تحلیل، طراحی، تولید و تست کارآیی مورد نیاز • تولید تکراری و گام به گام یک محصول کامل که آماده ی انتقال به محیط کاربران باشد • تصمیم در مورد اینکه آیا نرم افزار، سایت ها و کاربران همه برای استقرار طرح آمادگی دارند
  7. تمرکز این فاز بر این است که تضمین نماید نرم افزار برای کاربران نهایی آماده می باشد. فاز انتقال می تواند به چندین تکرار تقسیم شود، و شامل تست کردن محصول برای آماده سازی جهت انتشار و ایجاد تنظیم ات کوچک بر اساس بازخورد کاربر می باشد. اهداف مهم فاز انتقال عبارتند از : • تست بتا برای تشخیص اعتبار سیستم جدید با توجه به انتظارات کاربر • تست بتا و عملیات موازی همراه با یک سیستم قدیمی که در حال جایگزینی می باشد. • تبدیل پایگاه های داده ی عملیاتی • آموزش کاربران و نگهداری کنندگان • بازاریابی، توزیع و فروش برای نخستین انتشار محصول • تنظیم فعالیت ها از قبیل رفع اشکال، افزایش کارایی و قابلیت استفاده • ارزیابی خط مبناهای استقرار در مقایسه با تصویر کلی و معیار قابلیت قابل قبول برای محصول • دستیابی به موافقت ذینفع در مورد اینکه خط مبناهای استقرار کامل می باشند • دستیابی به موافقع ذینفع در مور ای نکه خط مبناهای استقرار با معیار ارزیابی تصویر کلی سازگارند.
  8. متدولوژی از یک روند تکراری و تکاملی پیروی می کند . بدین معنی که در طی چرخه ی عمر تولید یک محصول، تعدادی تکرار 1 در نظر گرفته شده است بگونه ای که در هر تکرار با انجام فعالیت های مربوط به دیسیپلین های مختلف، سعی می شود یکی از ریسک های مهم پروژه رفع شود، در انتهای تکرار یک محصول ارائه خواهد شد
  9. (Role) به هر نقش در rupگفته می شود . نقش نمایشگر مجموعه ای از رفتارها و مسئولیتهای یک فرد یا چند نفر از یک تیم توسعه می باشد . توجه شود که نقش با شخصی که آن نقش را بازی می ک ند تفاوت دارد عبارتند از : مدیر پروژه، برنامه نویس، تحلیلگر RUP. مثالهایی از نقش های سیستم، تست کننده و ... Activityکاری که هر نقش باید انجام بدهد و این کار نتیجه ای با ارزش برای پروژه دارد. فعالیت ها ورودی و خروجی هایی دارند که با نام دست آورد شناخته می شوند. Artifactدست آوردها لزوماً یک مستند کاغذی مثل نیستند و می توانند یک قطعه برنامه، UML Diagram یک ، Database وغیره باشند. Dicsiplinesدیسیپلین مجموعه ای از کارهای به هم مرتبطی است که برای انجام جنبه خاصی. از یک پروژه انجام می شوند Workflowsهر جریان کار مجموعه ای از فعالیت های مربوط به یک دیسیپلین است که با ترتیب خاصی انجام می شوند و در نهایت به تولید نتایج قابل مشاهده ای (دست آورد) منجر گردند.
  10. دیسیپلین مدل سازی کسب و کار توضیح می دهد که برای رسیدن به این هدف چگونه می توان یک تصویر کلی از سازمان را تو لید نمود، و براساس این تصویر کلی فرآیندها، نقش ها ومسؤولیت های آن سازمان را در یک مدل use-case کسب وکار و یک مدل شیء کسب و کار تعریف کرد. اهداف دیسیپلین نیازمندی ها عبارتند از : • تشخیص و نگهداری موارد توافق با مشتری ها و سایر ذینفعان در مورد کارهایی که سیستم باید انجام دهد. • فرآهم آوردن شناخت بهتر از نیازمندی های سیستم برای تولید کنندگان سیستم • تعریف مرزها و حدود سیستم اهداف تحلیل و طراحی عبارتند از: • تبدیل نیازمندی ها به طراحی سیستم که قرار است بوجود آید. • پیدایش یک معماری مستحکم برای سیستم • سازگار ساختن طراحی برای هماهنگ شدن با محیط پیاده سازی و طراحی آن برای کارایی بهتر اهداف پیاده سازی عبارتند از : • تعریف سازمان کد، برحسب زیر مجموعه ای از مجموعه های پیاده سازی سازمان یافته در لایه ها • پیاده سازی کلاس ها و اشیاء بوسیله مؤلفه ها (فایل های منبع، باینری ها، فایل هایاجرایی و ...) • تست اجزاء تولید شده به عنوان واحد ها Test: • یافتن و مستند کردن نقایص در کیفیت نرم افزار • آگاهی دادن در مورد کیفیت نرم افزار بررسی شده • اثبات اعتبار فرضیاتی که در طراحی و مشخصات نیازمندی ها ساخته شدند، ازطریق نمایش های واقعی • تصدیق عملکردهای محصول نرم افزار همانطور که طراحی شده است. • تصدیق اینکه نیازمندی ها بدرستی پیاده سازی شده اند.
  11. دیسیپلین استقرار فعالیت هایی را توضیح می دهد که تضمین می کنند محصول نرم افزاری برای کاربران نهایی اش در دسترس می باشد. دیسیپلین استقرار سه حالت استقرار محصول را توضیح می دهد : • نصب اختصاصی • آماده فروش کردن محصول نهایی • دستیابی به نرم افزار از طریق اینترنت دیسیپلین محیط بر فعالیت هایی که برای پیکربندی فرآیند برای یک پروژه لازم و ضروری اند، متمرکز می شود. این دیسیپلین فعالیت های مورد نیاز برای تولید رهنمودهایی که در جهت پشتیبانی از یک پروژه لازم می باشند را توضیح می دهد مدیریت پروژه نرم افزاری، هنر متوازن ساختن اهداف متقابل، مدیریت ریسک و غلبه بر محدودیت ها برای تحویل موفقیت آمیز محصولی است که هم نیازهای مشتریان ( کسانی که برای سیستم پول می پردازند) و هم نیازهای کاربران را برآورده کند پیکربندی و درخواست تغییر 2، تغییرات را به سمت خروجی های یک پروژه کنترل می کند و همچنین صحت و تمامیت خروجی های پروژه را حفظ می کند.