1.2.3

Question 1

Waterfall cycle

Answer 1

• The stages are completed in order.
• The clear structure makes this model easy to follow.
• Changes mean that all stages must be revisited.
• User involvement is low.

Question 2

Merits of waterfall

Answer 2

• Lots of documentation
• Easy to schedule and arrange tasks and judge progress
• Simple and easy to understand model
• Does not require a lot of customer involvement

Question 3

Drawbacks of waterfall

Answer 3

• Lots of documentation!
• If in testing the systems fails to meet requirements, either the requirements must be modified, or a substantial change in the design is required. “In effect the development process has returned to the origin and one can expect up to a l00-percent overrun in schedule and/or costs” (p329, Royce, 1970).
• Misunderstanding of requirements discovered too late
• No new ideas can be included during development.
• Users not involved until testing
• Cannot accommodate changing requirements
• No working software is produced until late during the life cycle.
• Efficient code is not prioritized

Question 4

When would waterfall be used?

Answer 4

• Straight forward projects where requirements are known and understood at the beginning and do not change
• When there is no benefit to the customer of having parts of the system available early.

Question 5

Agile Methodologies

Answer 5

• A collection of mythologies.
• Aimed to improve flexibility.
• Adapt quickly to changing user requirements.
• Sections of the program are developed in parallel.
• Different stages of development can be carried out simultaneously.
• A prototype is provided early and improved in an iterative manner.
• Low focus on documentation.
• High focus on user satisfaction.

Question 6

Rules of extreme programming

Answer 6

• Make frequent small releases (new software is live every week or two)
• Project is divided into iterations and each iteration is planned (an iteration is 1-3 weeks and has specific programming tasks)
• Set a sustainable pace (When your team becomes tired and demoralized they will get less work done, not more)
• A stand up meeting starts each day (everyone stands up in a circle to avoid long discussions. It is more efficient to have one short meeting that everyone is required to attend than many meetings with a few developers each.)
• The customer is always available (you need the expert)
• All production code is pair programmed (two people working at a single computer will add as much functionality as two working separately except that it will be much higher in quality)

-Code must be written to agreed standards (standards keep the code consistent and easy for the entire team to read and refactor. Code that looks the same encourages collective ownership)

• Refactor wherever and whenever possible (refactor the design and code to remove needless complexity)
• All code must have unit tests (and tests are created before the code)

Question 7

Merits of XP

Answer 7

• Quality of code should be very high
• Testing is continuous which will result in fewer bugs/issues
• Sustainable pace - less chance of tired programmers!

Question 8

Drawbacks of XP

Answer 8

• Programmers need to be based in same geographic location
• Customer needs to provide a representative to work with the development team
• Little or no documentation

Question 9

When might XP be used?

Answer 9

• Early implementation is important
• When requirements are changing
• Can’t be used on a project with a huge staff

Question 10

Rapid Application Development

Answer 10

• An iterative methodology.
• Uses partially functioning prototypes.
• Users trial a prototype.
• Focus groups gather user requirements.
• This informs the next prototype.
• This cycle repeats.
• Used where user requirements are unclear.
• Code may be inefficient.

Question 11

Merits of RAD

Answer 11

• Helpful when requirements are unclear as they do not all have to be specified at the start
• Should result in excellent usability due to feedback from customer
• Changing requirements can be accommodated
• Reduced development time due to minimising planning
• Time boxing can help keep projects on track

Question 12

Drawbacks of RAD

Answer 12

• Good code is not prioritised (focus is on accelerated development of front-end focused prototype)
• Demanding on customer’s time for feedback

Question 13

When would RAD be used?

Answer 13

• RAD should be used only when a system can be modularized to be delivered in incremental manner.
• When the customer is unsure of their requirements.
• RAD projects are typically small scale and of short duration

Question 14

Spiral

Answer 14

• Used for high risk projects.
• Has four stages:
• Analyse requirements.
• Locate and mitigate risks.
• Develop, test and implement.
• Evaluate to inform the next iteration.
• The project may be terminated if it is deemed too risky.
• Specialist risk assessors are needed.

Question 15

Merits of Spiral

Answer 15

• Ideal for risky and complex projects. If risks are too high, the project may be stopped before prototyping.
• Changing requirements can be accommodated
• Users see the system early - likely to result in a solution which better matches user’s needs
• Focus on alternatives encourages software reuse
• Focus on eliminating unattractive risky alternatives early on. Risks could be personnel shortfalls, unrealistic schedules and budgets, developing the wrong software functions eg functionality that it not needed)

Question 16

Cons of spiral

Answer 16

• Management is more complex so could be more expensive
• Process is more complex than other models
• Good risk analysts are expensive
• Efficient code is not prioritized
• No continuous customer interaction.