Presentation is loading. Please wait.

Presentation is loading. Please wait.

RUP Life Cycle Software Engineering Learning Programme Software Engineering Foundation.

Similar presentations


Presentation on theme: "RUP Life Cycle Software Engineering Learning Programme Software Engineering Foundation."— Presentation transcript:

1 RUP Life Cycle Software Engineering Learning Programme Software Engineering Foundation

2 Producer/ddmmyy - Title - author / 2 Module Objectives  To understand the main concepts - RUP Fundamentals - Terminology / context / deliverables  To understand the benefits and best practices  Understand the role of the SE within RUP  Understand what input deliverables are needed and where do they come from  Which output deliverables are used as input for roles further in the process and how they are used Delivery Guidelines Format: Webcast / and intructor-intro Duration: 3 hours / 60 Minutes

3 Producer/ddmmyy - Title - author / 3 Module Topics  What about RUP  Background and why use it,  RUP  Best practices  Model Visually  Requirements management  Importance of traceability  Importance of configuration management  RUP language  Terminology and symbols  Deliverables  SE role level 1

4 Producer/ddmmyy - Title - author / 4 RUP – what about it and why use it?  The "Rational Way" is:  Iterative and incremental  Object-oriented  Managed and controlled  Highly automated  It is generic enough to be tailorable to a wide variety of software products and projects, both in size and application domain. It is centered around three poles:  People  Process  Tools and methods

5 Producer/ddmmyy - Title - author / 5 RUP – history.  1998 Rational Unified Process (RUP) released to the public.  Result of from team collaborations and three software developers. “Three Amigo’s”  RUP successor of Rational Objectory Process (ROP), includes all aspects of the software development life-cycle.  1999 OMG issues a request for proposal (RFP).  Goal to provide an industry standard for tools and technologies for the software development lifecycle.  May 2000, Rational Software Corporation, IBM, et al, submit the Unified Process Model (UPM)  And now… “Object-Oriented Modelling and Design” (1991) “Object-Oriented Software Engineering: A Use Case Driven Approach” (1992) “Object-Oriented Software Engineering: A Use Case Driven Approach” (1992) GRADY BOOCH IVAR JACOBSON IVAR JACOBSON JAMES RUMBAUGH JAMES RUMBAUGH “Object-Oriented Design with Applications” (1993) “Object-Oriented Design with Applications” (1993)

6 Producer/ddmmyy - Title - author / 6 Phases, Disciplines and Milestones Time Content

7 Producer/ddmmyy - Title - author / 7 Best practices Develop Iteratively Manage Requirements Model Visually Use Component Architectures Continuously Verify Quality Control Change Best Practices

8 Producer/ddmmyy - Title - author / 8 Best Practice 4 Model Visually  Capture the structure and behavior of architectures and components  Show how the elements of the system fit together  Hide or expose details as appropriate for the task  Maintain consistency between a design and its implementation  Promote unambiguous communication  Visual modeling improves our ability to manage software complexity The Unified Modeling Language (UML) is a language for specifying, visualizing, constructing, and documenting the artifacts of software systems.

9 Producer/ddmmyy - Title - author / 9 Diagrams are view of a Model

10 Producer/ddmmyy - Title - author / 10 Best practice 2 Manage Requirements

11 Producer/ddmmyy - Title - author / 11 Requirement and Requirements Management  A requirement describes a condition or capability to which a system must conform..  Types:  Functional requirements  Non-functional requirements  packaged Software Requirements Specification (SRS))  Requirements management is a systematic approach to finding, documenting, organizing and tracking the changing requirements of a system  White Paper: Applying Requirements Management with Use Cases White Paper: Applying Requirements Management with Use Cases

12 Producer/ddmmyy - Title - author / 12 Business Needs drive Customer Needs which drive User Needs which demand Product Features that drive Software Requirements that we developers Implement and Test E. Magaziner ‘96 What is Requirements Traceability?

13 Producer/ddmmyy - Title - author / 13 Why Use Requirements Traceability?  The purpose is to:  Verify that all requirements of the system are fulfilled by the implementation.  Verify that the application does only what it was intended to do  Help manage change  A proven technique for assuring quality  Practiced by high-reliability system developers  Mandated by standards (e.g.: DOD, FDA)  Recommended by IEEE and CMM  A proven technique for understanding the impact of changes

14 Producer/ddmmyy - Title - author / 14 Sample Queries Using Requirement Links  Show me user needs which are not linked to product features  Show me the status of tests on all use cases in iteration #3?  Show me all supplementary requirements linked to tests whose status is untested  Show me the results of all tests which failed, in order of criticality  Show me the features scheduled for this release, which user needs they satisfy, and their status

15 Producer/ddmmyy - Title - author / 15 Determine Your Requirement Traceability Strategy Stakeholder Requests Vision Design Model Supplementary Specification End-User Documentation Materials and Training Materials Use-Case Model Test Model Features Software Requirements Needs

16 Producer/ddmmyy - Title - author / 16 1.Trace top level requirements into detailed requirements 2.Trace requirements into design 3.Trace requirements into test procedures 4.Trace requirements into user documentation plan Design Software Design Descriptions Object Models Test Suites Test 2 3 Req A 1 Product Requirements (Features) Detailed Requirements (Use Cases) Req B Documentation Plan User Docs 4 Establish Traceability Paths

17 Producer/ddmmyy - Title - author / 17 Viewing Links - Traceability Matrix

18 Producer/ddmmyy - Title - author / 18 Viewing Links - Tree Report Tree reports provide the ability to trace linkages through the document hierarchy.

19 Producer/ddmmyy - Title - author / 19 What is Configuration Management?  Configuration Management is a discipline which enables you to identify the components of a system, so that you can:  Control all changes to the components  Maintain integrity and traceability through the whole application life cycle

20 Producer/ddmmyy - Title - author / 20 Why Configuration Management?  To follow the progress of developments  To follow the evolution of one particular component  To ensure the use of the right component  To allow sharing of one component between several developers without conflicts and loss of data  To ensure the safety of components  To allow regeneration of complete and up-to-date application versions  To provide visibility on the development / maintenance cycle

21 Producer/ddmmyy - Title - author / 21 Configuration Management Software  CM Software Provides the Ability to :  Maintain a single copy of system elements  Control access to data  Maintain an exhaustive inventory of software components  Maintain a history of changes  Follow and control a defined process  Manage the security of different environments (development, QA, production)

22 Producer/ddmmyy - Title - author / 22 RUP – terminology  RUP uses roles, disciplines, phases and artifacts  Some terms are new for developers;  Know the RUP language!

23 Producer/ddmmyy - Title - author / 23 Schedule oriented terms in the RUP InceptionConstruction phase Elaboration Transition proces iteration development cycle milestone release Final production release product increment = delta release Initial Operational Capability LifeCycle Architecture Milestone LifeCycle Objectives Milestone

24 Producer/ddmmyy - Title - author / 24 RUP Terminology: Discipline All activities you may go through to produce a particular set of artifacts. The contents of each discipline in RUP are organized as shown in the Environment discipline example.

25 Producer/ddmmyy - Title - author / 25 Disciplines Produce Models Use-Case Model Implementation Model implemented by realized by (Analysis) Design (Model) Model automated by Analysis & Design Requirements Implementation Test Business Modeling Business Use- Case Model Business Object Model

26 Producer/ddmmyy - Title - author / 26 RUP Terminology : Workflow Disciplines > Test > WorkflowDisciplinesTest  Workflows: Each Discipline contains one Workflow which shows a typical sequence of events when conducting the flow of work.  Workflows are expressed in terms of Workflow Details which are ordered conditionally. Workflow Details

27 Producer/ddmmyy - Title - author / 27 RUP Terminology : Workflow Details Example: Disciplines > Test > Workflow > Improve Test AssetsDisciplinesTestWorkflow  Workflow Details are groupings of activities that are done "together," presented with input and resulting artifacts.  Disciplines are explained using Workflow Details.

28 Producer/ddmmyy - Title - author / 28 RUP Terminology : Activity  A piece of work a role may be asked to perform  Granular: usually takes a few hours to a few days  Repeated, as necessary, in each iteration  Example Thinking Performing Evaluating Activity: Find use cases and actors  Step: Find Actors  Step: Find Use Cases  Step: Describe How Actors & Use Cases Interact  Step: Package Use Cases and Actors  Step: Present Use-Case Model in U-C Diagrams  Step: Develop a Survey of the Use-Case Model  Step: Evaluate Your Results

29 Producer/ddmmyy - Title - author / 29 RUP Terminology : Artifact  A piece of information that is produced, modified, or just used by a process  Defines an area of responsibility  Likely to be subject to configuration control  Kinds of artifacts:  Models  Model elements  Documents  Artifacts may contain other artifacts

30 Producer/ddmmyy - Title - author / 30 Example: Artifact Overview Diagram Example: Disciplines-> Requirements-> Artifact Overview

31 Producer/ddmmyy - Title - author / 31 RUP Terminology : Role  A role defines the behavior and responsibilities of an individual, or a set of individuals, working together as a team  Behavior: a set of cohesive activities  Responsibilities: usually defined relative to certain artifacts  A role is a “hat” worn by an individual RUP role set Analysts Developers Testers Managers Other roles

32 Producer/ddmmyy - Title - author / 32 Example: Role Responsibility Diagram Example: Systems Analyst Example: Implementor

33 Producer/ddmmyy - Title - author / 33 Guidelines  Rules, recommendations, heuristics that support artifacts and activities  Add the benefit of experience to activities  Describe well-formed artifacts, focus on qualities  Describe specific techniques  Transformations from one artifact to another  Use of UML  Used also to assess the quality of artifacts  Can be tailored by the organization  Work guidelines:  Provide work and documentation techniques, often complements to the formal artifacts defined in the RUP  Can be used as an aid in more than one of the activities  Focus on techniques that help team communication

34 Producer/ddmmyy - Title - author / 34 Tool Mentors  Similar to guidelines  Explain how to use a specific tool to perform an activity or steps in an activity  Linked by default to Rational tools:  Rational RequisitePro: requirements management  Rational Rose: visual modeling, using UML  Rational SoDA: documentation generation  Rational ClearQuest: change management, defect tracking  …. and more

35 Producer/ddmmyy - Title - author / 35 4 + 1 View Model Process View Deployment View Logical View Implementation View Programmers Software management System Integrators Performance Scalability Throughput System Engineering System topology Delivery, installation communication Use-Case View End-user Functionality Analysts/Testers Behavior

36 Producer/ddmmyy - Title - author / 36 Summary  What about RUP  Background and why use it,  RUP  Best practices  Model Visually  Requirements management  Importance of traceability  Importance of configuration management  RUP language  Terminology and symbols  Deliverables  SE role level 1

37 Producer/ddmmyy - Title - author / 37 More to know….  Sources used when developing the RUP product  Explore the RUP knowledge base.  RUP Glossary  RUP Resource Center online  Visit www.therationaledge.com and Rational developers networkwww.therationaledge.com  Books: The Rational Unified Process an Introduction Philippe Kruchten Building J2ee Applications with the Rational Unified Process Peter Eeles Building Web Applications with UML Jim Conallen  Examples white papers  Reaching CMM Levels 2 and 3  Applying Requirements Management with Use Cases  Developing Large-Scale Systems with the Rational Unified Process The Ten Essentials of RUP — The Essence of an Effective Development Process Using the Rational Unified Process for Small Projects: Expanding Upon eXtreme Programming

38 Producer/ddmmyy - Title - author / 38 Exercise 1/1 1.What’s the relationship between a Role, Artifact and Activity? 2.What are the roles the CGEY Software Engineer can realize? 3.How do Workflows, Workflow Details and Activities fit together? 4.What is the importance of the iteration plan for a SE? 5.Right or Wrong? (explain your vote !) 1.In the discipline Analyse And Design the analyst performs use case analysis. 2.The System Architect is responsible for the analysis model 3.The Designer is responsible for the activity Find Business actors and use cases 4.The Use case template should always completely been used. 5.The Designer is not responsible for the design Model. 6.The Test Designer performs Unit Tests 7.The Implementer plans and integrates subsystems 8.The Integrator is responsible for the integration build plan 9.The deployment unit is an artifact for which the deployment manager is responsible. 10.Use case realizations are realized in requirements.

39 Producer/ddmmyy - Title - author / 39 Exercise 1/2 1.What artifact the SE is responsible for contains other artifacts? 2.Are there any changes for the developer in the new version of RUP (2003) 3.Take 5 artifacts a SE will be responsible for. Describe for each artifact the RUP role responsible and in which view (of the 4 in 1 model view) this artifact is described. 4.What Tools will be used by a CGEY SE in the different roles? 5.Are all tools necessary for a development cycle? What is the minimum set? 6.How do Tool Mentors work in RUP?

40 Producer/ddmmyy - Title - author / 40 Questions


Download ppt "RUP Life Cycle Software Engineering Learning Programme Software Engineering Foundation."

Similar presentations


Ads by Google