1. 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
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
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.
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).

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:
To express the project's plans in the various areas :
scope, time, cost, quality, process.
To understand what could adversely affect these plans over time;
That is, what are the risks if the project does not follow these plans
To monitor progress according to the plan, using some objective metrics whenever possible.
To revise these plans if the project goes significantly off-course.
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.

11. 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
A business object model captures responsibilities, organizational units, and important concepts and items within our business, and how they relate to each other.
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.

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 issues
affects 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. A feature is a service provided by the system that can be observed
Feature List
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.
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.
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 the
beginning 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 Flows
2.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 is performed for each selected course offering 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