Chapter 3 - The software life cycle revisited Flashcards

1
Q

Milestones in a software development project

A

The times at which certain documents become available.

  • after requirements engineering, there is a requirements specification
  • after the design phase there is a (technical) specifiaction of the system
  • after implementation there is a set of programs
  • after testing there is a test report
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
2
Q

The waterfall model

A

Slight variation on the model given in chapter 1 (all phases), adding validation and verification between each of the phases and assessing the correctness of the transition.

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

Agile methods

A

Agile methods:

  • view the world as fundamentally chaotic. They assume change is inevitable.
  • small and incremental development cycles, not extensively planned in advance.
  • review of the new situation at the end of the cycle.
  • people-oriented rather than process-oriented
  • short communication cycles between developers and users.
  • Not much energy spent on documentation. Ask person who knows.

Key values of agile development:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

Prototyping

A

A prototype is a working model of (possibly parts of) a software system, which emphasizes certain aspects.

Usually used when:

  • unclear and ambiguous user requirements
  • emphasis of system is user interface

Examples of prototypes:

  • use of a very high-level language, in which an executable version can be created quickly. Used to test the usability of the system.
  • development of a system with less functionality. Usually not focusing on speed and robustness.

In prototyping more attention is given to the quality factors flexibility and modularity

Less attention is given to the quality factors speed and robustness

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

Throwaway prototype

A

Prototype that is thrown away at the end of the prototyping phase and is not used anymore in the production phase.

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

Evolutionary prototyping

A

In agile terms called working code

Prototype may evolve to the final product:

  • User formulates the raw requirements
  • First version of the system is produced on the basis of the requirements
  • User works with the system which leads to new or changed requirements
  • Next version is developed
  • After a number of iterations, when user is satisfied, the last version developed is the product to be delivered
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
7
Q

Pros and cons of prototyping

A

Advantages:

  • Resulting system is easier to use
  • User needs are better accomodated
  • The resulting system has fewer features
  • Problems are detected earlier
  • The design is of higher quality
  • Resulting system is easier to maintain
  • The development incurs less effort

Disadvantages (more like not prototyping):

  • Resulting system has more features
  • Performance of the resulting system is worse
  • The design is of lesser quality
  • Resulting system is harder to maintain
  • Requires more experienced team members
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
8
Q

Incremental development

A

With incremental development, the functionality of the system is produced and delivered to the customer in small increments (steps). In each of these steps, the phased approach that we know from the waterfall model, is employed.

Attention is first focused on the essential features.
Additional functionality is only included if and when it is needed.

Most difficult parts are often tackled first.

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

‘Big bang’ effect

A

For a long time nothing happens and then, suddenly, there is a completely new situation.

Consequence: Instead of
building software, the software grows.

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

‘Overfunctionality’ syndrome

A

Since users find it difficult to formulate their real needs, they tend to demand too much.

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

Rapid application development

A

RAD has a lot in comon with iterative development process models.

RAD emphasizes user involvement, prototyping, reuse, the use of automated tools, and small development teams.

Employs the notion of a time box, a fixed time frame within which activities are done. The agreed
deadline is immovable.

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

Rapid application development (RAD) phases

A

Rapid application development (RAD) phases:

  • requirements planning
  • user design
  • construction
  • cutover

Requirements planning and user design phases can be combined for small projects. Main techniques used in this phases: Joint Requirements Planning (JRP) and Joint Application Design (JAD). Both these techniques make heavy use of workshops in which the developers and the prospective users work together (hence the
adjective Joint).

Joint Requirements planning: get the requirements right the first time. Requirements are prioritised. This is called triage.

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

Joint Requirements Planning prioritization (MoSCoW)

A

MoSCoW model:

  • Must haves are requirements that are definitely needed.
  • Should haves are requirements that are important, but not absolutely needed for a usable system.
  • Could haves are requirements that are only implemented if time allows so.
  • Won’t haves are requirements that will be left for the next iteration.
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
14
Q

DSDM (Dynamic Systems Development Method)

A

Dynamic Systems Development Method is a framework that builds on RAD

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

DSDM phases

A

The phases of DSDM are:

  • feasability study assesing the feasability of DSDM on current project
  • business study resulting in a high level description of the business processes relevant for the system
  • **functional model iteration **results in analysis models, prototypes, and implementation of the major functional components
  • design and build iteration assures** **the system is engineered to a sufficiently high standard
  • implementation consists of the system being carried over to the customer’s environment and user training
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
16
Q

XP (Extreme programming)

A

Extreme Programming, XP for short, is a pure agile method. XP is based on a number of best practices that have been known for long. XP takes these practices to extreme levels.

17
Q

Pair programming

A

Two programmers working together behind a computer screen. One coding one giving advice, noticing small errors, asking questions. Roles can change any time. (XP practice)

18
Q

XP principles

A

XP principles:

  • Rapid feedback: feedback is obtained quickly, within hours, or at most a few days. By testing each small piece added, developers immediately learn what works and what doesn’t.
  • Assume simplicity: don’t build in extra complexity so that a certain class becomes more flexible. If and when a feature is needed, it will be added, and code will be refactored to make it simpler.
  • Incremental change: in XP, things change in small increments. The plan changes a little at a time, the design changes a little, the team changes a little, etc.
  • Embracing change: by not planning, designing, coding more than is needed right now, the most options for the future are kept. Only the most pressing problem is tackled today. The rest is left for tomorrow.
  • **Quality work: **quality is a must. The team should find pride in delivering excellent quality.
19
Q

Refactoring

A

Restructure the system without changing its
behaviour, to improve quality. (XP practice)

20
Q

Collective ownership

A

Anyone can change any code, anywhere, at any
time. (XP practice)

21
Q

Testing

A

Programmers continuously write unit tests, cus-
tomers write acceptance tests. (XP practice)

22
Q

RUP (Rational unified process)

A

RUP is an iterative development process geared towards the building of object oriented systems.

Based on a series of practices that have evolved over the years.

Somewhere between document driven and agile methods

Complements UML.

23
Q

RUP phases

A

RUP phases:

  • inception: getting objectives clear (scope, boundaries, acceptance criteria)
  • elaboration: analyzing problem domain and getting a sound architecture
  • construction: manufacturing, building process
  • transition: system released and beta-tested
24
Q

RUP workflow

A

In a second dimension, RUP has 9 workflows, allowing the differentiation between iterations.

RUP workflows:

  • Business modeling
  • Requirements
  • Analysis and design
  • Implementation
  • Test
  • Deployment
  • Configuration and change management
  • Project management
  • Environment
25
Q

RUP practices

A

RUP practices:

  • Iterative development
  • Requirements management
  • Architecture and use of components
  • Modeling and UML
  • Quality of process and product
  • Configuration and change management
  • Use-case driven development
  • Process configuration
  • Tool support
26
Q

Laws of software evolution

A

Laws of software evolution:

  • Law of continuing change: used system undergoes continuous changed until replaced.
  • Law of increasing complexity: a program becomes less and less structured with modifications
  • Law of self-regulation: software evolution processes are self-regulating (promote smooth growth of software)
  • Law of conservation of organisational stability (invariant work rate):** **the
    global progress in software development projects is statistically invariant.
  • Law of conservation of familiarity: A system develops a constant growth increment to sustain the organization’s familiarity with the system. When this increment is exceeded, problems concerning quality and usage will result.
  • Law of continuing growth: The functionality of a system needs to continuously increase in order to maintain user satisfaction.
  • Law of declining quality: The quality of a system declines, unless it is actively maintained and adapted to its changing environment.
  • Law of system feedback: Software evolution must be seen as a feedback system in order to achieve improvements.
27
Q

Software product line

A

Software product line: set of
software systems that share elements. In a software product line, reuse is planned, not
accidental.