Temp 2 and 3

Analysis Design Implementation Evaluation Maintenance

What the current system does What the new system needs to do

Interview people who will use new software Use questionnaires to gain large amounts of information Observe what the current system does Look at existing documentation

A system documentation used to evaluate the final product.

A description of the data (data types, format and validations), Database design and management (if appropriate), Input/output screens and reports, How the data will be processed, How the software will be tested Hardware requirements/configuration System Security

Coding and testing the software (while tracing and correcting errors), Writing user and technician documentation, Installing software for the user

Black box (functional) and white box (structural)

Testing the code logic by using test data to test all the possible paths within a program at least once.

In-house testing that is closed from the public and can reveal many bugs or problems

When (often) commercial software is distributed to potential users to be tested and where the user agrees to the testing.

It gains lots of real world info and experience for the developers since people often do things that the original developers didn’t anticipate.

Around 6 months after distribution, people critically evaluate if the system works and that all aspects of the software are tested. This is evaluated against the original specification document to compare performance, the systems criteria, any errors made and any unexpected benefits/problems

Testing every aspect of a software then evaluating it against the original specification document to accept that it now works/performs as intended.

Corrective maintenance, Adaptive maintenance, Perfective maintenance

Similar to the lifecycle model except it doesn’t loop, when you get to the end, you can’t go back upwithout re-completing the previous stages in the model.

Simple to understand each stage is separate with good documentation, Projects are straightforward to manage, model works well for smaller projects too

Not much user involvement after the analysis stage. Working software not produced until late in the project, User is given the finished product which doesn’t leave much room for improvement

The product has a clear outcome No ambiguous requirements The project is short, The technology is well understood

Analysis, design, implementation, evaluation

Well defined steps Software is produced at an early stage in development. User can give feedback during the iterative process End result more likely to be what the user wants.

Iterative process is very time-consuming, More costly to develop with the time needed, Not suitable for smaller projects

For medium to high-risk projects, When users aren’t sure of needs or technological possibilities, When requirements are complex, For projects which may take a long time to develop and may need to take advantage of recent/future technological advancements.

Software is rapidly developed in an iterative process in so-called development cycles with individually implemented features where each version improves on previous functionality and is thoroughly tested

Software is quickly and continuously developed which leads to good client satisfaction, Working software is frequently published and developed. Good for small, time-critical projects, Limited planning to get started.