Role-Based Guide to the RUP

Project Manager

Analyst

2

The Four P’s

• The scope of software development project management:

– People• Software development depends highly on the skills and

coordination of work among people• Many of the activities of a project manager will rotate around

people and are focused mainly on the development team.

– Product• Project manager has to make sure that the objectives are set

and that progress is tracked relative to these objectives.• This involves extensive communication with parties external to

the development team and with the development team.

3

The Four P’s (cont)

– Process• Project manager has to fully understand the process of

developing software• The process, supported by the right tools, is the common

roadmap, understood and used by all team members.

– Project• Project manager manages the project itself, planning,

controlling, monitoring, and correcting the trajectory as often as necessary.

4

The Role of Project Manager

• Technical Skills– To understand the issues at hand—the technologies and the

choices to be made.

• Communication Skills– To deal with many different stakeholders and have an ability to

jump from one style to another.

5

Project Management

• Meeting or exceeding stakeholders' expectations involves balancing competing demands among– Scope, time, cost, and quality.– Stakeholders, internal and external, with different needs and

expectations.– Identified requirements (needs) and unidentified requirements

(expectations).

Project management is the application of knowledge, skills, tools, and techniques to project activities in order to meet and exceed stakeholders' needs and

expectations from a project.

6

Scope of Project Management in RUP

• RUP does not cover all aspects of project management, and it remains focused on the engineering aspects.

• It doesn’t cover many aspects related to managing people– No guidance on how to hire, train, compensate, evaluate, or

discipline people.

• RUP does not deal with financial issues such as – budget, allocation, accounting, or reporting.

• The RUP does, however, concentrate on the software-specific aspects of project management,– Areas where nature of software has an impact, making it different.

7

Software Development Plan (SDP)

The best approaches for the project manager:

1. To express the project's plans in the various areas :– scope, time, cost, quality, process.

2. To understand what could adversely affect these plans over time;

– That is, what are the risks if the project does not follow these plans

3. To monitor progress according to the plan, using some objective metrics whenever possible.

4. To revise these plans if the project goes significantly off-course.

5. Finally, to learn from mistakes, so that the organization will not repeat them in the next iteration or the next project.

8

Software Development Plan (SDP)

• The key artifact a project manager will focus on is a Software Development Plan, containing many different plans:

– Project plan and iteration plans– Test plan– Configuration Management plan– Measurement plan– Risks– Documentation plan– The specific process the project will use—its development case

9

Activities of a Project Manager

• Activities to launch a new project

• Activities to define and evolve all elements of the Software Development Plan

• Activities to start, run, and close a project, a phase, or an iteration

• Activities to monitor a project

10

Summary

• The project manager is not an innocent bystander but is part of a team and works collaboratively with this team.

• The project manager is responsible for the development and modification of the Software Development Plan.

• The plan is based on a configured process, adapted to fit the context of the project.

• The project manager is responsible for making the appropriate tradeoffs to manage the scope of the project and of each iteration.

• The project manager is constantly focused on risks—any risks—and how to mitigate them, should they prove to be in the way of success.

• The project manager keeps the focus on real results, not on intermediate and sometimes abstract artifacts.

Role-Based Guide to the RUP

Analyst

12

An Analyst in RUP

• The roles include:

– Business analyst

– System analyst

– Product manager• Product management team: Product planner, Product marketer,

Sales engineer, and Marketing Communications (MarCom) manager.

– Other person involved with business modeling, requirements management, or user-interface (UI) prototyping.

13

Mission as an Analyst

• The overall objective is to define and communicate to all stakeholders what the system should do.

• This can be broken down into the following high-level tasks:– Understand the needs of the users– Understand the needs of other stakeholders– Document, prioritize, and communicate the requirements– Negotiate requirements and facilitate customer acceptance of the

application

14

Analyst's Involvement in RUP Lifecycle

• An analyst is primarily involved in the RUP disciplines of Business Modeling, Requirements, and Analysis & Design

• Analysts do most of their work in the Inception and Elaboration• Analysts also play an important role during Construction and

Transition.

15

An Analyst over Four Phases

• Analyst contributes most during the Inception and Elaboration phases– When requirements are identified and stabilized. Analyst's

responsibility here is to ensure that the right application is built.

• During the Construction and Transition phases– Analyst is less involved, but there will still be some work with

• Detailing requirements

• Analyzing the impact of any changing requirements or business models.

16

Where To Start?

• Business NOT well understood:– First, we need to understand the business before we build the

supporting software.– This is when we need to do business engineering

• Business well understood:– Most applications are developed to support an existing, and well-

understood, business.– In this case, an analyst would commence working as

• Understand Stakeholder Needs

• And develop a Vision.

17

Understand How Business Should Operate

• Business engineering is primarily done by larger projects or organizations.

• We need to understand what business processes are required to support business stakeholders.

• The processes are represented by business use cases, – They describe services that business will provide to customers.

18

An Example of Business Use Cases

• If our business is a store, the business use cases may be the following:

– Provide information about available products• Later, this can be implemented by salespersons in a store or

by a Web site.

– Accept and process order• There may be many different software use cases to support

this business use case, ranging from e-shopping to information systems supporting in-store salespersons.

The workflow of a business use case can be described textually in use-case descriptions as well as visually using UML diagrams

19

Business Use-Case Model for Product Company

A business use-case model shows which business process (business use cases) is provided for which customers/business partners (business actors).

20

Business Object Model for Order

This figure shows how the concept Order relates to other concepts, such as Customer Profile and Product. A model of concepts only is sometimes called a domain model, since it provides a good understanding of the problem domain.

A business object model captures responsibilities, organizational units, and important concepts and items within our business, and how they relate to each other.

21

Understand Stakeholder Needs

• The collected stakeholder requests ("wish list“) will be used as primary input to define high-level features of the system, as described in the Vision

• The stakeholder wish list can be gathered through interviews or by arranging and facilitating a two-to-four-hour workshop with the stakeholder team

• Eliciting stakeholder requests is primarily done in Inception, with many updates in Elaboration.

• Throughout the project, we will get useful requests from stakeholders. These are documented in Change Requests

22

Develop a Vision

• The most essential things captured in a Vision include:– Stakeholders list:

• Customers, users, investors, product managers, designers, testers, and so on.

– Constraints: • Budgetary constraints, a list of technology selections, operating

systems, and required coexistence or compatibility with existing systems.

– Problem statement: • A distinct description of the problem you are attempting to solve

(described in more detail later).

– Feature list: • A list of services provided by the system for the users of that system

(described in more detail later).

23

Problem Statement

• The problem statement forces the team to specify concretely the problem they are attempting to solve.

• The following format can be used:

The problem of <describe the problem> affects <the stakeholders affected by the problem>.

The impact of which is <what the impact of the problem is>.

A successful solution would <list some key benefits of a successful solution>.

24

Example of Problem Statement

The problem of untimely and improper resolution of customer service issuesaffects our customers, customer support reps, and service technicians.

The impact of which is customer dissatisfaction, perceived lack of quality, unhappy employees, and loss of revenue.

A successful solution would provide real-time access to a troubleshooting database by support representatives and facilitate dispatch of service technicians, in a timely manner, to only those locations in genuine need of assistance.

25

Feature List

• Each feature should have the following:– A short description– A value attribute indicating the business value the feature

provides (for example, low, medium, or high)– A cost attribute indicating how complex/costly the feature is to

implement

• By looking at value and cost, we can prioritize features. • We may choose to use priority levels of 1 through 5.

A feature is a service provided by the system that can be observed by a user of the system, and that directly fulfills a stakeholder need.

The analyst typically proposes the initial prioritization of features, reviews them with the project manager, architect, and the stakeholder team, and then modifies the list based on feedback.

26

Course Registration System

27

Structuring of Flows of Events.

28

Use-Case Descriptions

Course Registration System: Use-Case Specification for Register for Courses

1. Brief Description

This use case allows a Student to register for course offerings in the current semester. The Student can also modify or delete course selections if changes are made within the add/drop period at thebeginning of the semester. The Course Catalog System provides a list of all the course offerings for the current semester.

The main actor of this use case is the Student. The Course Catalog System is an actor within the use case.

29

Use-Case Descriptions (cont.)

2. Flow of Events The use case begins when the Student selects to Register for Courses. 2.1 Basic Flow: Register for Courses

1. The Student selects to Register for Courses.2. The system displays a blank schedule.3. The system retrieves a list of available course offerings from

the Course Catalog System.4. The Student selects one or more primary and alternate course offerings from the list of available offerings. The user can at

any time add or remove courses from the list of selected

courses. Once the selections are complete the Student

submits the schedule.

30

Use-Case Descriptions (cont.)

5. For each selected course offering, the system verifies that the Student has the necessary prerequisites and that the course offering is open.

a. If the Student has the necessary prerequisites, and the course offering is not full, the system adds the Student to the selected course offering. The course offering is marked as "enrolled in" in the schedule.b. If the Student does not have the necessary prerequisites, or if the selected course offering is full, an error message is displayed. The Student can either select a different course offering or cancel the operation, at which point the use case is restarted.

6. The system saves the schedule.

31

Use-Case Descriptions (cont.)

2.2 Alternative Flows2.2.1 Modify Course Registration

1. The Student selects to modify the current course registration schedule. 2. The system retrieves and displays the Student's current schedule (the schedule for the current semester). 3. The system retrieves a list of all the course offerings available for the current semester from the Course Catalog System. The system displays the list to the Student. 4. The Student can then modify the course selections by deleting and adding new courses. The Student selects the courses to add from the list of available courses. The Student also selects any course offerings to delete from the existing schedule. Once the edits are complete the Student submits the schedule to indicate completion with the selection of courses. 5. Subflow 2.1.5 is performed for each selected course offering.

6. The system saves the schedule.

32

Use-Case Descriptions (cont.)

2.2.2 Delete Course Registration

1. The Student selects to delete a schedule.2. The system retrieves and displays the Student's current schedule.3. The Student selects to delete the schedule.4. The system prompts the Student to verify the deletion.5. The Student verifies the deletion.6. The system deletes the schedule.

2.2.3 Save a Schedule

At any point, the Student may choose to save a schedule without submitting it. The current schedule is saved, but the student is not added to any of the selected course offerings. The course offerings are marked as "selected" in the schedule.

33

Develop User-Interface Prototypes

• Conceptual Prototype– Developed during Inception (in parallel with developing the vision)– Demonstrates key concepts and capabilities to enable

stakeholders to understand better the system being built– Contains not only UI prototypes, but also some underlying

functionality.

• Use-Case Storyboard or Use-Case Prototype.– Developed in late Inception, throughout Elaboration, and into early

Construction,– We need to develop UI prototypes in parallel with use-case

descriptions to enhance our understanding of the use cases.

34

Develop Use-Case Storyboard or Prototype

• For more technical applications with a strong focus on sequencing and interaction with other systems, – Create a use-case storyboard only for some key use cases to

showcase a few different screens.

• For database-focused applications of the Create, Read, Update, Delete (CRUD) nature – Try to do a UI prototype for each use case, not so much to

mitigate risks associated with the UI, but to increase the speed and accuracy in developing use-case descriptions

35

Capture Nonfunctional Requirements

• Quality attributes, including usability, reliability, performance, and supportability requirements.

• Legal and regulatory requirements, and application standards.

• Other requirements, such as operating systems and environments, compatibility requirements, and design constraints.

36

The Analyst's Role in the RUP

• The RUP product provides a more fine-grained representation of the analyst's role by describing its more specialized roles:

– System analyst– Business designer– Business-model reviewer– Business-process analyst– Requirements reviewer– Requirements specifier– Test analyst– User-interface designer