Pearson Higher Nationals in ComputingAssignment 2: Software Development LifecycleUnit 4: ‘Crazy Fix Garage’ Requirements and DesignStudent Name/ID NumberAcademic Year 2018-2019Unit Tutor Kath LampardAssignment Title

‘Crazy Fix Garage’ Requirements and Design

Issue Date 01/04/2019Submission Date 03/06/2019IV Name & Date Malcolm Levon 17/01/2019Submission FormatThe submission is in the form of:

An individual written report using the simplified Volere Template. This should be written in a concise, formal business style using single spacing and font size 12. You are required to make use of headings, paragraphs, subsections and illustrations as appropriate, and all work must be supported with research and referenced using the Harvard referencing system.

Unit Learning OutcomesLO3 Undertake a software development lifecycleLO4 Discuss the suitability of software behavioural design techniquesAssignment Brief and GuidanceScenario

CrazyFix Garage is a medium sized business specialising in the servicing & repair of a particular make of vehicle. The garage keeps information about its customers and their vehicles and updates this information on every visit. See invoice illustrated in figure 1 for type of information.

An adhoc mixture of manual and computer-based systems currently supports CrazyFix’s business processes. However, they would like to have a more integrated Information System and this document describes how an Information System (which we’ll call simply “the system”) should be used to support their business.

CrazyFix Garage keeps a stock of original vehicle parts (produced by the vehicle manufacturer) for each of the models supported. For each part there is also a stock of substitute parts approved by the manufacturer.

On visiting the garage, the customer is met at reception by a clerk who uses the system to record their personal, vehicle and service (or repair) request details.

Service technicians use the system to obtain information about the vehicle and the work requested by the customer. The vehicle is then inspected and the name and quantity of spares required are recorded and part numbers and prices obtained.

The service technician also uses the system to determine whether an original version of each spare part is available from garage stock, and if they are not, whether non-original (i.e. substitute) parts are available.

If an original part is available then the system is used to deduct the required quantity from the stock record, and request the item from stores.

If an original part is out-of-stock, then an attempt is made to locate an equivalent substitute part from stock, and the item requested from stores.

The system also manages the stock level of all items and supports administration staff with re-ordering stock and paying suppliers. Hence, when any item is found to be unavailable, warnings are generated to prompt the re-ordering process.

If neither original or substitute parts are available, the technician puts the service or repair on-hold and the customer advised about the vehicle status by reception clerk.

During the actual servicing or repair (i.e. post-inspection) of the vehicle, service technician/s use the system to:

record the parts actually fitted - this could differ from the original list produced during the inspection of the vehicle

record the number of man-hours spent working on the vehicle. rate, price and summarise the work undertaken.

All the information gathered during the visit is used as appropriate to create an itemised invoice as illustrated in figure 1.Since, CrazyFix Garage offers a six months guarantee on each part they fit, the system checks all invoices for parts that were installed by CrazyFix less than six months ago. Any parts that were installed during the previous six months still appear on the invoice but the sub-total (price) for that part is set to zero.When all work is completed, the vehicle is formally handed-over to reception to await collection. The reception clerk is responsible for advising the customer that the vehicle is ready for collection.

Task 1 (LO3: P5, P6, P7, M3, M4, M5, D3)

Undertake a systems investigation to meet a business need: Discover, specify and document the problem and requirements specification of the

system. This should address functional and non-functional requirements of the system

Draw a context Diagram (level 0 DFD) and Level 1 DFD Draw a Level 2 DFD for one selected process from level 1

Use Case Diagram for ‘Crazy Fix Garage’ ensuring you include all actors and all significant use cases

Create documentation for the Use Case ‘Check Availability of Parts’o A Brief Descriptiono Write a specification ‘Main Success Scenario’o Identify and write associated Extension Scenarioso Identify pre-conditions and post-conditionso Write detailed description based on the modified Cockburn template given

Write a detailed description of ‘Check Availability of Parts’ in the form of a system sequence diagram

Draw an Activity diagram for ‘Check Availability of Parts’

Draw and Entity Relationship Diagram (ERD), identifying the main entities and relationships indicating the degree of the relationships and optionality.

Task 2 (LO4: P7, M5, M6, D4)Write a report which:

o Explains how user and software requirements have been addressedo Analysis how software requirements can be traced throughout the software

lifecycle

Research and write a report to:o Discuss two approaches to improve software qualityo Critically Evaluate how the use of the function design paradigm can improve

software qualityo Differentiate between a finite sate machine and an extended-FSM providing and

example of botho Justify how data driven software can improve the reliability and effectiveness of

software

Pass Merit Distinction

LO3 Undertake a software development lifecycle

D3 Critically evaluate how the use of the function design paradigm in the software development lifecycle can improve software quality.

P5 Undertake a software investigation to meet a business need.

P6 Use appropriate software analysis tools/techniques to carry out a software investigation and create supporting documentation.

M3 Analyse how software requirements can be traced throughout the software lifecycle.

M4 Discuss two approaches to improving software quality.

LO4 Discuss the suitability of software behavioural design techniques

D4 Present justifications of how data driven software can improve the reliability and effectiveness of software.

P7 Explain how user and software requirements have been addressed.

M5 Suggest two software behavioural specification methods and illustrate their use with an example.

M6 Differentiate between a finite state machine (FSM) and an extended- FSM, providing an application for both.