Chapter 3 - The software life cycle revisited Flashcards
Milestones in a software development project
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
The waterfall model
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.
Agile methods
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
Prototyping
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
Throwaway prototype
Prototype that is thrown away at the end of the prototyping phase and is not used anymore in the production phase.
Evolutionary prototyping
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
Pros and cons of prototyping
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
Incremental development
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.
‘Big bang’ effect
For a long time nothing happens and then, suddenly, there is a completely new situation.
Consequence: Instead of
building software, the software grows.
‘Overfunctionality’ syndrome
Since users find it difficult to formulate their real needs, they tend to demand too much.
Rapid application development
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.
Rapid application development (RAD) phases
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.
Joint Requirements Planning prioritization (MoSCoW)
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.
DSDM (Dynamic Systems Development Method)
Dynamic Systems Development Method is a framework that builds on RAD
DSDM phases
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
XP (Extreme programming)
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.
Pair programming
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)
XP principles
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.
Refactoring
Restructure the system without changing its
behaviour, to improve quality. (XP practice)
Collective ownership
Anyone can change any code, anywhere, at any
time. (XP practice)
Testing
Programmers continuously write unit tests, cus-
tomers write acceptance tests. (XP practice)
RUP (Rational unified process)
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.
RUP phases
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
RUP workflow
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
