Summary Project Management

Project management
Course outline
I. Managing softare projects
II. Essentials of Rational Uniied Process
III. Managing risks
IV. Managing time
V. Managing quality
VI. Managing objectiies and scope


1 Managing software projects
Outline
1. Deining project management
2. Softare deielopment processes
3. ABC of project management
4. RUP
5. Agile processes

Project Characteristcs
- Objectiies
o Clearly deined set of goals; non-conficting
- Start and end points
o not a continuous actiiity, like operations or supporteioliing a lot due the the
current business eniironment
- Uniqueness
o One-time thing (product;; not a repetitiie actiiity
o Not production
- Constraints
o Cost, schedule, quality
Note:
DevOps is a term for a group of concepts that, thile not all net, haie catalyzed into a moiement
and are rapidly spreading throughout the technical community. Like any net and popular term,
people may haie confused and sometimes contradictory impressions of that it is. Here’s my take
on hot DeiOps can be usefully deined; I propose this deinition as a standard frametork to more
clearly discuss the iarious areas DeiOps coiers. Like “Quality” or “Agile,” DeiOps is a large enough
concept that it requires some nuance to fully understand.

1.1 Deining Softare Project Management

- Softare Project Management is the art of balancing competing objectiies, managing risks, and
oiercoming constraints to successfully deliier a product thich meets the needs of both
customers (the payers of bills; and the users. (RUP;
- Project management is the application of knotledge, skills, tools, and techniques to project
actiiities in order to meet or esceed stakeholder needs and espectations from a project (Project
Management Institute;



1

,Note:
- What is the purpose of softaree deliiering ialue for money. It is hard to deine that
ialue is and set up already at the beginning of the projectlet area for fesibility
- The idea is that then you are into a project you need to deliier a softare system that is
going to produce ialue. Think in terms of ialue irst. Value though is hard to
deine/measure. The idea is to meet or esceed stakeholder needs.
- purpose of softare is to deliier ialue for the money Image belot: traditional
iietmore accurate iiet is to say management, operators and deielopments=engineering
- Agility is not yet fully scaled too many limitations in term of modeling, planning,
coordination, leadingit’s not easy to say to a team of 4 or 5 people need coordination,
not at all for groups of 100need to put some people in leading roll and te are back in
traditional tay of deielopment




Note:
you haie tto diferent people around the table. Management and engineers. This is a traditional
iiet there you haie these tto types of people. There is eiolution into this iiet though, the
operators are a net iiet, tho are a third group of people needed. Dei is engineering and ops are
the operators (infrastructure guys;. We not tend to haie less focus on the managers. Within the
agile taie, te don’t like the tord manager anymore. It has a negatiie connotation into the agile
ield. The more management you put the more dangerous it is that you cannot focus on ialue as it is
seen by the dei team as it is seen by the stakeholders. Agility torks really tell into deined cases,
but it doesn’t tork efciently into other cases. Need to keep in mind that agility is not fully scalable.
Good for small or medium sized projects, but an entire erp deielopment tould haie too many
problems and limitations into modeling and planning, coordination, leading, etc. It is easy to say to a
team of 5 or 10 people “organize by yourselies”. If you haie a team of 100 people you cannot
organize by yourself. You need an hierarchy thich requires coordination. So you need to put people
in a leading role and you’re back to the basis of management.

1.2 Process

- Process: set of actiiities intended to achieie a goal
- Process to run a project
o = softare deielopment process
o = softare engineering process

2

, o = softare process
- Softare project management is a subset of that softare deielopment process
- Do not miss the business process of an organization tith the softare deielopment process
- RUPprince 2 is at the same leiel of RUPis formalized=you haie a deined
processstructured
Note:
When te speak about RUP te talk about a softare deielopment process. Business processes is the
tay your organization is torking to deliier ialue. Don’t mis the bus. Process of the org tith the
softare deielopment process. (sp isn’t a method, just a set of principles;

Examples of Processes
- Rational Uniied Process (RUP;
- The SCRUM you also haie a structure, but less formalleiel of formality is justiied by the
time of the project


1.3 Process basicsvery important= Exam




Note:
- Lifecycle is more abstracttorking iteratiie
- Eierything that you deielop that performs to the contest of project= tork products artifacts
- Much more concrete leiel that Lifecyle that use cases you deieloped=actiiities, task
- Presentation of the tork process; for esample, doing a torkshop
- Roles: requirement engineer, coder, project managerstructured methods deine rolls
- Process Basics - giie me the process basics, giie me the elements that you till ind in a
structured process, for esample the RUP. Don’t describe RUP!! Just describe this slide. These
are basic elements into a structured process. If you understand this you can understand
most elements into structured methods like RUP, Prince2, etc.
- Lifecycle- milestone is a tay to eialuate if the phase has been achieied. If all objectiies of
phases haie been reached. Lifecycle, RUP has iteratiie lifecycle, SCRUM has an iteratiie
lifecycle.
- Work products - UML model, class diagram, sequence diagram, planning sheet done tith
microsof project, iision document, eierything that you deielop and take as input or output
for the project is a tork product.
- Actiiities - diference from lifecycle (lifecycle is more abstract;, performing planning game,
deining that user story, or use case you till deielop during nest iteration, building
class/sequence diagram, are actiiities or tasks. Much more concrete than lifecycle.
- In betteen lifecycle and actiiity is the torkfot - saying I’m going to do requirements
engineering you haie to perform a set of actiiities, making a use case model, making

3

, representations of the business processes, doing a torkshop tith the users in order to
represent the tay you haie ordered their business processes. All actiiities that are
performed into the requirements of business engineering. Designing … Implementing it,
making the code iniolies a set of actiiities.
- Lifecycle, actiiities, tork products >>>
- Roles - the hat that people that are doing the actiiities are tearing. Most of the time
structure methods deine a set of roles. For esample, scrum deines roles.
- If you understand the structure you till be able to understand hot project management
torks. A generic set of things you need to keep in mind in order to understand the
frametork and naiigate inside of it.

1.4 RUP lifecycle and disciplines




Note:
In order to be performed you need speciic technical knotledge. In scrum you don’t haie a
distinction betteen elaboration and construction. In RUp you tant to understand all of the
problem. Rup tas designed as planned driien in the sense that you make the transition to the net
system at the end. The tillingness of SCRUM is to put liie each release once it has been done.
Though it isn’t the case in reality.

RUP Project Management Discipline




4