1.2 - Software and software development

All programs that run on a computer. e.g. Applications software = Outlook. e.g. Systems software = operating systems, windows.

Going from the initial idea to the final product.

• Analysis. • Design. • Implementation. • Evaluation. • Maintenence.

• System analyst gets info about what current system dows + what new system needs to do. • Done by intervieweing users, questionaires from large groups of people, observing current system + look at documentation. • Output = ‘system specification’ or ‘user requiremnts’. Defines what the system will do but not how.

• Description of the data: data type, format + validations. • Database design (If needed). • Input screens, output screens + reports. • How the data will be processed. • How the software will be tested. Algroithm -> Pseudocode/flowchart.

• Code + test the software. • ** Writing user + technical documentation.** • Installing the software for the user.

• Black box. • White box. • Alpha. • Beta.

INDEPENDENT of the code used in the program. looks at program specification + creates set of test data that covers all the inputs/outputs/program functions.

Depends on code logic, tests, test each path through the code at least once.

Done by software devel;opers in-house team by the user, reveals errors + ommisons in the definition of the system requiremnets. User may discover that the system does not do exactly what they wanted.

When commercial software is being developed. (Given to potential users, use the software + report any faults. e.g. MS windows, MS word, Sage accounts etc).

• Does it all work? • Test every aspect of the software to make sure it does what it is meant to. • Evaluated against original specification.

• Corrective. • Adaptive. • Perfective.

Bugs usually found when software put into action, no matter how thoroughly it was tested.

Over time user requirements will change +{ software is adapted to meet new requirements.

Even if software works well, it’s improved so its faster, easier to use + has more functionality.

• Each stage is completed + documented before moving on. • End product not seen until completed. - any changes made means project has to be started again.

• Requiremnets = clear + fixed. • No ambiguous requirements. • Technology is well understood. • Project = short.

• Simple to understand + use. • Every stage is seperate + self contained with well defined outcomes + written documentation. • Relatively straightfoward to manage. • Works well with smaller projects where requiremnets are very well understoord.

• NOT MUCH USER INVOLVEMENT after the analysis stage when specification document is achived. • No working software is produced until late in the cycle. • User presented with the FINAL PRODUCT + if not quite what required, TOO LATE to make changes.

• The 1st 4 basic steps (Analysis, design, implementation, evaluation) are followed + software project pases through the phases repeatedly. • Each succesive loop round the spiral generated a now, more refined prototype until the software meets all the requirements.

• Medium to high risk projects. • When users unsure of their needs and what the possibilities are. • When the requirements are complex. • Large projects, may take years to develop, so new technologies may develop + significant changes occur.

• Well defined steps = easy to manage. • Software produced at early stage so problems + issues are indentified early. • User gives feedback on each new prototype + any required changes can be made early in the process. • Added functionality can be added during the process. • End result is more likely to be what the user wants.

• time consuming - longer development time. • System more costly to develop because of the time involved. • Not suitable for smaller models.