Brainscape's Knowledge GenomeTM

Browse over 1 million classes created by top students, professors, publishers, and experts.


See full index

Project Management: People and Technology > Week 2 - Sheets & Articles > Flashcards

Week 2 - Sheets & Articles Flashcards

You may prefer our related Brainscape-certified flashcards:
People You Should Know flashcards
1
Q

What is a use case?

A

A collection of related scenarios or user stories for one stakeholder.
Also, a way of using a system.

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

What is the purpose of a use case?

A
  • Generate new requirements as the design takes shape
  • Communicate with stakeholders
  • Generate test cases
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
3
Q

What are functional requirements?

A

Actions the system should perform, can be assigned to individual components of a system.

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

What are non-functional requirements?

A

General properties the system should have.
E.g., performance, security, usability etc.
Applies to the system as a whole

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

What are constraints?

A

Necessary conditions on the context.

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

What are some of the Elias committee’s recommendations to improve ICT projects for Government?

A
  • Demonstrate added value for end users and society (no value, no support)
  • Create support among all parties involved and test for feasibility
  • Make use of a transparent bid-for-tender strategy in the justification of a project (PID)
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
7
Q

What is the PID?

A

Project Initiation Documentation - one of the most significant artifacts in project management, which provides the foundation for the business project.

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

What is the difference between configuration and design?

A
  • Configuration has a closed problem, principles are known and the parts are standard
  • Design has an open problem, principles are unknown and parts are to be developed
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
9
Q

What is the principle-agent theory, applied to (software) design?

A 
Information asymmetry (Eisenhardt, 1989). We can see design as dialogue: an exchange of ideas.
Developer knows the domain but not the needs, customers has needs but doesn't know what system they want.
New components trigger new requirements (causation).
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
10
Q

What are the 2 types of complexity (Brooks, 1987)?

A
  • Essence: difficulties inherent in the nature of the problem to be solved
  • Accidents: difficulties we have created (e.g. by rules/regulations, lack of standards etc.)
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
11
Q

What are the 4 properties of a software problem (Brooks, 1987)?

A

Complexity, conformity, changeability, invisibility

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

What is complexity according to Brooks (1987)?

A

The function of the:

  • number of components (volume)
  • number of types of components (variety)
  • number of attributes (depth)
  • number of relations (dependencies)

These are essential properties of a problem.

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

What is the goal of function points (FP) (Brooks, 1987)?

A

To assess complexity of specification, before building.

Use it as a metric for predicting effort, duration and errors

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

What is conformity according to Brooks (1987)?

A

Software has to conform to external expectations and norms, which differ between contexts (there are no laws of nature)

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

What is changeability according to Brooks (1987)?

A

Software can and must be changed after production, with updates. Otherwise you risk falling behind and increasing security flaws.

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

Where does the pressure of change often come from (Brooks, 1987)?

A

From people who invent new uses for the system, and software survives beyond the machine for which it is first written.
Could also come from uncertainty.

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

What is invisibility according to Brooks (1987)?

A

Software is abstract, intangible, not imbedded in space and time. There are several representations of structure.
There is no single way to visualize software, which makes communication hard.

18
Q

What did Brooks (1987) suggest for addressing the issues discussed in his article?

A

At the time:

  • Remove accidental difficulties, by high-level programming languages, OOP…..
  • Address conceptual essence (some agile principles); buy vs build, requirements refinement
19
Q

How would you currently solve the issues discussed in Brook’s article (1987)?

A

Implementing agile to remove accidental difficulties and address essential complexity. Removing communication issues with a Kanban board.

20
Q

How could one address complexity, according to Brooks (1987)?

A
  • Little by little (iterative, feedback)
  • Less dependencies & local decision making
  • Centralize (data)
  • Standardization
  • Re-use, buy vs. build, share knowledge
21
Q

What is Brook’s law (1983)?

A

“Adding manpower to a late software project makes it later”.
This is because new project members need to learn; takes existing resources away from the project. Increases communication (channels).

22
Q

What is the Spiral model (Boehm, 1988)?

A

A systems development lifecycle (SDLC) method used for risk management, that combines iterative development with waterfall.

23
Q

For which type of projects is the Spiral model a favorite?

A

Large, expansive and complicated projects.

24
Q

What does a loop represent in the spiral model (Boehm, 1988)?

A

A phase in the software development process.

The number of loops is often determined by the project manager.

25
Q

What is the most important feature of the spiral model (Boehm, 1988)?

A

The ability to manage unknown risks after the project has commenced; creating a prototype makes this feasible.

26
Q

What do the 4 quadrants represent in the spiral model (Boehm, 1988)?

A
  1. Objectives determination and identify alternative solutions
  2. Identify and resolve risk.
  3. Develop next version (prototype) of the product.
  4. Review the new prototype results and plan for the next phase.
27
Q

Why is the spiral model (Boehm, 1988) called a Meta Model?

A

Because is subsumes all the other SDLC models.
For example, one loop represents the iterative waterfall model, but the entire model incorporates the stepwise approach of the traditional waterfall model. The spiral model also uses the Prototyping model by building a prototype at the start of each phase as a risk handling technique.

28
Q

What are some of the advantages of the spiral model (Boehm, 1988)?

A
  • Risk handling at every phase
  • Good for large projects
  • Flexibility in requirements
  • Customer satisfaction (using prototypes before the final product)
29
Q

What are some of the disadvantages of the spiral model (Boehm, 1988)?

A
  • Complex (more than other SDLC models)
  • Expensive (not suited for small projects)
  • Too dependent on Risk Analysis (skills/expertise)
30
Q

Name 4 main characteristics of the spiral model (Boehm, 1988).

A
  • Iterative: timebox periods
  • Risk management: drives decision making
  • Various cycles: learn and improve
  • Importance of validation and testing
31
Q

What is the main difference between the spiral model and Agile models?

A

The spiral model uses Timeboxing.
Better answer:
spiral model builds prototypes before the final product;
agile releases a usable version of the product and incrementally builds on this.

32
Q

What is the difference between verification and validation?

A
  • Verification: test if the system was built right (according to reqs, do we follow the right procedures & processes)
  • Validation: test if the right system was built (according to stakeholder needs & environment)

Validation is performed after the product has been developed, unlike verification.

33
Q

What is traceability in reqs engineering (design)?

A

Given all features in the design, I should be able to trace FROM which req they originated.
Vice versa: from every req, I should be able to find out what part of the design makes that true (realization).

34
Q

What is Boehm’s conclusion (1979) on errors and their relative cost?

A

Errors detected in later stages are more expensive to repair.

35
Q

What is requirements engineering (Jarke et al., 2011)?

A

The discipline to capture, share, represent, analyze, negotiate and prioritize reqs for design decisions and interventions.

36
Q

Why did the environment in which RE is practiced change over the years (Jarke et al., 2011)?

A
  • Partly due to advances in hardware & telecoms that has radically lowered computing costs and extended functionality
  • Partly due to changes in task- and organizational environments where software is either produced or deployed
37
Q

What are the 3 facets of the reqs categorization by Jarke et al (2011)?

A
  1. Discovery (elicitation) of the reqs
  2. Specification (make them concise/measurable)
  3. Validation and verification
38
Q

Specification can be both a noun and a verb in RE. Explain both.

A

Noun: the specification is a document in which the reqs are articulated; the agreement between the stakeholders and the design team.
Verb: process of developing & managing the document.

39
Q

What are the challenges in RE, according to Jarke et al (2011)?

A
  • Multiple concepts of design, and its intertwining with reqs
  • Evolution & management of reqs under growing complexity
  • Architectural implications and platform strategies
  • Identification of changing stakeholder roles & management challenges in handling stakeholder arguments about RE (in short: changing roles, more demanding stakeholders)
40
Q

Mention at least five critical issues and challenges for requirements engineering.

A

Change, complexity, architectural challenges, integration, user interface / UX.
but also:
- Distributed reqs / diverse stakeholders
- Multiple abstraction layers
- Interdependent complexity
…

41
Q

What are the 4 req principles by Jarke et al (2011) that underlie successful design in RE in the new world of reqs?

A
  • Intertwine reqs with organizational/business contexts
  • Evolution of reqs (evolve incomplete designs; allow flexibility)
  • Architectures as a critical, stabilizing force (they are both enablers and constraints)
  • Recognize complexity

Project Management: People and Technology (6 decks)

Brainscape helps you reach your goals faster, through stronger study habits.
© 2024 Bold Learning Solutions. Terms and Conditions