Project Management Flashcards

1
Q

What is a customer?

A
  • Person who commisions a system; so system must meet their objectives
  • Not necessarily the end-user
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
2
Q

What is a stake-holder?

A
  • Person with a vested interest in a project
  • Potential for conflicts of interest between stakeholders which must be balanced
  • Need to manage a stakeholders expectations
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
3
Q

What is a developer?

A
  • Required skills: technical, communication and cohesion skills
  • Need to manage a fair distribution of the workload
  • Need to coordinate workload increments
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

What needs to be considered when identifying the scope of a project?

A
  • Business context of the project
  • System requirements vs Performance constraints
  • New build VS Extension
  • One off system VS Product line
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
5
Q

How do we break down a problem? (Project decomposition)

A
  • Divide & Conquer

- Consider project architecture (its distribution over different systems

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
6
Q

When looking at a project, what needs estimating? How?

A
  • [EXACT] costing & time info
  • rigourous costing model: COCOMOII
  • lightweight costing model: function point analysis
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
7
Q

What is the basic idea behind Function Point Analysis?

What are it’s difficulties?

A
  • identify main business functions
  • score each function on difficulty of implementation (1 - 3, easy - hard)
  • sum function points
  • multiply by some constant to determine project size
  • hard to pick an accurate constant for projetc size
  • developers tend to under-estimate difficulty
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
8
Q

How do we select a process model?

A
  • needs to fit the product
  • needs to match customer availability
  • needs to fit the project environment
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
9
Q

How do we follow/use the chosen process model?

A
  • plan a set of stages/deliverables
  • modify the process to suit any project constraints
  • adapt & improve the process based on experience of past projects
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
10
Q

Describe each of the 5 levels of the Capability Maturity Model

A
  • Initial: not much of a process model is used
  • Repeatable: basic management control, can repeat a level of delivery again
  • Defined: process defintion, written guidelines on how to use a process
  • Managed: process measurement, measure effectiveness of software engineering process
  • Optimising: feedback driven process control
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
11
Q

What are the (10) main risks of Project Management?

A
  1. Failure to understand the customers needs
  2. Poorly defined project scope
  3. Changes poorly managed
  4. Supporting technology changes
  5. Changes to the business goals
  6. Setting unrealisitc deadlines
  7. Users resistant to the new system
  8. Losing sponsorship (funding)
  9. Lack of skilled people in the software team
  10. Managers & developers don’t use the best practices
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
12
Q

What may you have to do if requirements analysis is incorrect? (6 things)

A
  1. Modify software specification
  2. Adapt software design
  3. Repair the software implementation
  4. Generate & apply new software tests
  5. Update the documentation
  6. Recall the product
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
13
Q

Describe a system in terms of subsystems

A
  • System is a complex whole consisting of many subsystems
  • Work together to acheive some goal
  • Emergent properties of all components working together
  • Some form of self-regulating control
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
14
Q

What is meant by a system operating in a context?

A
  • Systems are separted from the environment by some boundary

- Has inputs/outputs from/to the environment

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
15
Q

Describe a software system in a business context

A
  • Goal is to support a business
    • either support core or subsidiary activity
  • Need to interact with other physcial or legacy (outdated) systems
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
16
Q

What are the 3 main questions in systems development?

A
  • Will the new system bring a real benefit?
  • How will the new system be integrated with physical and legacy systems?
  • Should the existing physical/legacy systems be replaced?
17
Q

What are the 3 types of System Requirement? Brief description of each

A
  • Functional; what will the system do? What must the users accomplish?
  • Non-functional; performance goals and physical constraints
  • Usability; how easy must the system be to use; anticipated styles of user interaction
18
Q

What are the functional requirements of a system?

A

Description of the processing to be done by a system, describes all input/output relationships and describes behaviour for each possible input.
Describes the main functions of a system, and describes each as essential or desirable.

19
Q

What are the non-functional requirements of a system?

A
  • Product requirements: performance, reliabilty and portabilty requirements
  • Organistation requirements; conforming to policies and procedures of a business
  • External requirements; legal and ethical requirements, how the system will interact with other systems.
20
Q

What are the usabilty requirements of a system?

A

User centred design: has the skill level of the user been considered
Is the system ergonomic? Does it fit with existing workplace practices? Is it robust to incorrect data entry?

How do we test if the system is a success?

21
Q

What are the starting points of gathering requirements? What are the issues with this? What are the solutions?

A
  • Customers business vision (opportunity or necessity driven)
  • Cutomer may define initial requirements: can be too abstract, high-level, biased, make too many assumption, narrow focus on one issue
  • Developer must compensate; look at wider scope of project, analysis must include whole business context
22
Q

Different ways of fact-finding for requirements gathering (5) Brief description

A
  • Background reading: gain contextual info
  • Interviews/Workshops: requires skills & sensitivity
  • Observation: useful to see how business deals with exceptional situations
  • Document sampling; illustrate information flow
  • Questionnaires: economical but hard to do well
23
Q

Describe how to conduct interviews/workshops effectively to gain requirements

A

Non-directive interview style: brief prompts, no forced-choice questions, reflect back on answers for confirmation; let stakeholders lead

Workshops; want to balance and resolve conflicts. Identify stakeholders exterme viewpoints to try and find a balance of interests

24
Q

How do we maintain focus when capturing requirements? (4)

A
  • Dont impose a structure on the customer
  • short prompts
  • active listening
  • capture breadth of business; not just one aspect
25
Q

What is requirements drift? How do we minimise its effect?

A

Requirements changing during the capture process

Identify stable vs volatile requirements, prioritise according to essential, necessary, desirable, or optional. Agree on a staged delivery schedule, doing essential reqs first

26
Q

What do we look at when we review requirements? (6)

A
  • Validity - does system still meet customer needs
  • Consistency - no contradictions
  • Complete - no missing requirements
  • Coherent - no conflict between functional and non-functional reqs
  • Feasible - can deliver on time within budget
  • Verifiable - test system against requirements