OCR A2 ICT Unit 3 Chapter 1

Systems Life Cycle:  The stages that need to be completed to create a new or modified system. 

• It's a continuous loop with each stage leading into the next.
• All projects should follow the cycle to ensure the final product fully meets the needs of the end user.
• The most common start point is when a new software system is being considered.

Stages of the System Life Cycle:

• 1) Definition of the Problem
• 2) Investigation and Analysis
• 3) Design
• 4) Implementation
• 5) Testing
• 6) Installation
• 7) Documentation
• 8) Evaluation and Maintenance

(Tip: Remember the cycle with this acryonym "DID IT IDE")

1) Defintion of the Problem:

• Position:   It's the first stage of the system life cycle.
• Output:  Feasibility Report
• Description: 
• This is the initial look at the existing system to see how it can be improved or if it's possible to meet the needs and requirements of the end user.
• The stage begins with an initial, brief investigation that involves the system analyst to obtain info. on the system currently used and other end-user requirements of the new software system.
• Next, the analyst will identify why the current system isn't meeting the needs of the organisation, why a new system is needed and what the purpose of the software system is.

2) Investigation and Analysis:

• Position:  This stage follows the definition of the problem.
• Input:  Feasibility Report
• Output:  Requirements Specification
• Description:  
  • The full nature of the problem to be solved is investigated (using several investigation methods, where the result of the investigation forms the basis for the analysis of all the problems of the current system. 
  • Finally the user requirements are defined and agreed with the client, where they are constantly refered for the rest of the cycle in order to meet the needs of the end users.

3) Design:

• Position:  This stage follows Investigation and Analysis.
• Input:  Requirements Specification
• Output:  Design Specification
• Description:  
  • Objectives defined from investigation and analysis stage are followed to help develop the design of the system that matches the user's requirements.
  • The methods and formats of data capture, input, output, storage, strucutre of data, processing and validation routines, queries and reports are all considered and designed.
  • The project plan is developed taking into account the client-defined deadline for the installation of the system.

4) Implementation:

• Position:  This stage follows Design.
• Input:  Design Specification
• Output: Completed System
• Description:  
  • The design specification from the design stage is taken forward and is put into practice to build the system.
  • Coding, macros and queries are created with backup and storage of data being considered.
  • A decision about the software strategy, based on budget constraints set by the client, is made.
  • Off-the-shelf software is customised to meet the needs of the client.
  • Working software is created, ready to be tested.

4) Testing:

• Position:  This stage follows Implementation.
• Input:  Completed system/test plans.
• Output: Working system/test logs.
• Description:  
  • The completed system is tested against the requirements specification, to determine whether everything works.
  • Testing follows a test plan, with results being recorded, to ensure that the system is free of bugs/errors.
  • If a test fails to provide the expected result then corrective action is taken before a retest.

5) Installation:

• Position:  This stage follows Testing.
• Input:  Working System
• Output: Installed System.
• Description:  
  • The system is installed for the client using an installation strategy (parallel, phased, pilot or direct).
  • The end-users are trained using the completed and tested software code.
  • Data is then transfered into the new system.

6) Documentation:

• Position:  This stage follows Installation.
• Description:  
  • Documentation such as test plans, data and logs, user manuals, version and security details, and program specifications are created and passed to the end user of the system to allow the end-user to diagnose and solve day-to-day issues that may arise.

.

7) Evaluation and Maintenance:

• Position:  This final stage follows Documentation.
• Description:  
  • Forms the basis on which the decision is taken to begin the system life cycle again.
  • This demonstrates the iterative nature of the system life cycle.
  • The solution should be evaluated once it has been implemented with maintenance ensuring that a system continues to meet the needs of its users.

Questionnaires:

• Large no. of people can be asked the same questions > comparisions are easy to make.
• Can be structured clearly and provide opportunities for short answers.
• Response can be anonymous > can provide more honest answers.
• Cheaper than interviews for large no. of people.
• Must be designed very carefully and questions need to be unambiguous.
• Cannot guarantee 100% return.
• It's difficult to gain a realistic view of the use of a system.
• Difficult to allow people to expand on their answers.

.

Interviews:

• A rapport can be developed with the people who will use the system.
• Questions can be adjusted or added as the interviews proceed > to gather more info.
• Can be time-consuming and costly.
• It might not be possible to interview everyone in a large organisation.
• Poor interviewing > misleading or insufficient info. being gathered.

Meetings:

• A group of people can attend a meeting.
• Discussions can take place, with different views being expressed.
• Can be used to gather or give information.
• Body language can be seen.
• Discussions can lose focus resulting in the questions not being fully answered.
• Some staff may not attend because jobs still need to be completed.

.

Document Analysis:

• Good for obtaining factual information.
• Good for identifying data types and formats.
• Cannot be used when input, output and information are not document-based.
• There may be other important data that aren't actually in the documents.

Observation:

• All aspects of work loads, methods of working, delays and 'bottlenecks' can be identified.
• The effects of office layouts and conditions on the system can be assessed.
• Potential to experience all aspects of job role.
• Can be time-consuming and costly.
• Problems may not occur during observation.
• Users may put on a 'performance' when being observed.

Prototyping: A software development methodology which focuses on the early delivery to end users of an incomplete, but working, system which can then be changed following feedback from the client.

• An interative process of design and evaluation/repeated until an interface is satisfactory, it can be used to check what the designer has created is what the end users want and need.
• A prototype/model is built to enable the end users to evaluate the proposals for the design of software by trying them out, rather than having to interpret and evaluate the design based on descriptions, before enabling an approved version to be put into production.

Types of Prototyping:

• Evolutionary: 
  • An initial prototype is developed and evaluated by the end users.
  • Using this feedback, a second prototype is developed and then evaluated. This process continues with each prototype and evaluation making the system closer to what the end users require. On the last evaluation, the system should meet all the requirements.

.

• Throw-away: 
  • A working prototype of various parts of the system is developed after a short investigation. 
  • The prototype is developed and evaluated by the end users, then it's disposed to enable the end users to give/receive quick feedback, which allows any refinements to be done early in the development.
  • This is cost-effective as there is nothing to redo.

Adv. & Disadv. of Prototyping:

• Reduced time and costs - Early clarification of the user needs can result in faster development and smaller costs.
• Improved and increased user involvement > More appropriate final product.
• Earlier feedback from end users can be obtained by the designer > deadlines can be met.
• The avoidance of the expense and difficulty of changing a finished software product.
• End-user confusion between the prototype and finished system.
• Excessive development time of the prototype - developing a complex prototype will increase time and cost.

Rapid Application Development (RAD): A software development methodology based on a system life cycle that is iterative and evolutionary.

• Aim: To produce a software solution in less than 6 months. 

.

• 2 Main Features:
  • The use of joint application design (JAD) workshops - these aim to develop a set of requirements that shouldn't change before the system is implemented.
  • The use of timeboxing - the requirements of the system are defined in small 'chunks', each of which is considered using a JAD. Each 'chunk' is allocated a specified timescale which must not be exceeded. At the start of each timebox the objectives are defined and, at the end of the timebox, if not successfully completed then they may be added to another timebox or dropped.

Benefits of RAD:

• End users are involved at all stages with the system being implemented within 6 months.
• End users are involved in the evaluations so this should ensure that the final system fully meets their defined requirements.
• End users don't have to define all the requirements of the system at the beginning of the process. 

Disadvantages of RAD:

• The solution developed using RAD may, on the surface, meet the end-user requirements but the functionality may not be acceptable.
• The project manager will need to keep a very tight control over the whole development process and the team, if the system is to be developed within the 6 months required by RAD.

Testing checks that a system works as intended and is free from errors before being implemented.

Why Testing is Important:

• To make sure that the system meets the design spec.
• To make sure that the system returns the correct results and actually works.
• To give confidence to the end user - they'll have more faith and confidence in a new system if it has sucessfully completed and passed all the tests.

Test Data used for testing should cover:

• Normal Data - Data that is correct and shouldn't generate any errors on data entry.
• Extreme Data - Data that is correct but is at the upper and/or lower boundaries of tolerance. Errors shouldn't be generated on data entry.
• Erroneous Data - Data that is incorrect and will generate errors on data entry. This data may be outside of the boundaries of tolerance or of the wrong type.

Test Plan: A formal document that lists the tests that will be carried out on the system. It must be created before testing takes place.

A Test Plan Includes:

• The Requirements
• Pathways
• Validation Routines
• A Comparison of the actual performance against the design specification.

Importance of a Test Plan:

• A test plan should be sufficient in detail (e.g. input data and expected output should be clearly defined) to enable a third party to recreate the tests and results obtained, which may be passed to the end user when the system has been installed.

The test plan should be structured as below:

• Test No. - Unique identifier for each test.
• Description of Test - Description of what is being tested.
• Type of Test - Normal, extreme, erroneous (incorrect).
• Data Used - The data that'll be entered to run the test.
• Expected Result - What you expect to happen when you run the test.

There are 3 types of Specifications:

Requirements Specification:  Usually developed by the systems analyst after investgiations have been carried out. The contents include:

• What the system is to do and how this is to be achieved.
• A decription of all the interactions the end users will have with the software.
• The defined functional requirements.
• The defined non-functional requirements.
• The objectives/purpose of the system
• The scope of the system
• The proposed timescale for the project.
• End-user defined constraints  -  inc. budget, time, hardware and software choices.
• A contract

 - Functional Requirements:  What the end user wants the system to do.

 - Non-Functional Requirements:  The end-user defined limitations relating to response time, hardware, software and programming language.

System Specification:  Usually developed from the results of the investigation of the current system and defines the requirements for the new system. The contents should include:

• The facilities and outputs that the new system will provide.
• Operation Requirements - What operations the system should carry out.
• Information Requirements - What information the system should provide to the end users.
• Volume Requirements - E.g. hwo much volume of processing is to be handled.
• General System Requirements - E.g. the degree of data accuracy needed and security issues.

Design Specification:  Usually developed by the systems designer following the investigations. The contents and focus may be slightly different depending on the type of system that is being developed. The contents should include:

• The purpose of the system.
• Assumptions, limitations or contraints.
• The inputs and outputs - documents and screens/interface.
• Error messages.
• The colours/fonts/sizes, including the consideration of the corporate  image/house style to be used.
• Validation rules.
• Processing requirements/queries.
• Data structures
• Modelling diagrams.
• The hardware.
• The software/programming language to be used.
• Test Plan

Each member of the team will have different roles and responsibilities. It's possible that 1 person may take on more than 1 role.

Project Manager:

• Role:
  • (Main) To plan and control the whole project.
• Resposibilities:  
  • (Main) To identify and rectify potential problems and issues.
  • To ensure that the budget is adhered to and that any slippage in costs is notified to the end user.
  • To ensure that all the associated project reports and documentation are correctly completed during the project (through consultation between all members of the team).
  • To ensure that each stage of the life cycle is completed before the next stage is started (by setting deadlines).
  • To provide progress reports to the end user of the system after each stage is completed.

Systems Analyst:

• Role:
  • (Main) To analyse and investigate the existing system (using approp. investigative methods).
  • To assess the suitability of the current system for upgrading, using the results of the analysis.
  • To liaise with the staff in the organisation.
• Resposibilities:  
  • (Main) To develop the feasibility report, inc. the requirements specification.
  • To develop a plan for developing the proposed system. Specifying the procedures involved, how the data is captured, the software required to process the data, how the data is to be output, the hardware required and how the staff will be trained to used the new system.

Systems Designer:

• Role:
  • (Main) To central the process of designing, developing and implementing the defined requirements of the system.
  • To work with programmers and the end users.
• Resposibilities:  
  • (Main) To build on the results of the findings of the systems analyst to plan and design the new system.
  • To complete the requirements analysis.
  • Working with programmers and the end users.
  • To confirm the systems analyst's proposal.
  • To develop, document and revise design procedures, test procedures and quality standards.
  • To create an architectural design with the necessary specs. for the hardware, software, data and staff resources.

Programmer:

• Role:
  • (Main) To create software that is required for the system being developed. A programmer can be a specialist in one area of computer programming or be a generalist who writes code for many kinds of software.
• Resposibilities:  
  • (Main) To develop the applications system or to modify an existing software solution to meet the defined needs of the end user.
  • To create the technical documentation.

Tester:

• Role:
  • (Main) To find any bugs and errors in a system once it has been created, and to rectify them before the system goes live.
• Resposibilities:  
  • (Main) To develop and use test plans to test the programs and modules that are included in the system.
  • To ensure that a range of test data is used to cover all aspects of the system.
  • To record the results of the tests on a test log.

Project planning tools like the Critical Path Analysis and Gantt Charts are used by the project manager to plan a project.

Critical Path Analysis (CPA): Shows the relationship between the different parts of the project. It's a process that identifies how the tasks within a project fit together (the critical path) so that all tasks occur in a logical order with minimal delay and resourcing issues.

• It defines the critical path that should be taken to ensure the project is successful and completed on time > Enables resources to be allocated provisionally.
• It enables slack, lead and lag time to be built in to cover any slippage in the project.
• It helps identify the min. length of time needed to complete a project. If a project needs to be speeded up then the CPA diagram can identify which project tasks need to be completed more quickly to complete the project within the available time.
• However CPA diagrams are difficult to understand.

How to create a CPA diagram:

• 1) List all activites in the plan  -  Detail for each activity the earliest start date, estimated length of time it will take, and whether it's parallel or sequential. If tasks are sequential, show which stage they are dependent on.
• 2) Plot the activites as a circle and arrow diagram  -  In these, circles show events within the project, such as the start and finish of tasks.

Identifying a CPA Diagram:

• The node (the no. in the circle)  - Helps you to identify each event.
• The arc (the arrow) - Shows the activity needed to complete the task.
• A description of the task is written underneath the arrow with the length of the task shown above it.
• It runs from left to right.

Gantt Chart: A diagram that shows each task as a block of time. Each block of time is labelled with the title/description of the task and the amount of time the block represents.

• It assists the project manager by showing how long each task is expected to take and the order in which these will occur.
• It enables the modelling of how long the overall project will take and where the projected pressure points (where a no. of tasks are needed to be completed prior to moving onto the next part) are.
• Show the critical path as the longest sequence of dependent tasks.

A Gantt Chart contains:

• Milestones - Important checkpoints or interim goals for a project.
• Resources - The people/equipment needed.
• Status - The progress of each task.
• Dependencies - Activites which are dependent on other activites being completed first or at the same time.

Gantt Chart Example

How to create a Gantt Chart:

• 1) List all the tasks that need to be completed  -  For each task, show the earliest start date, the estimated time it will take to complete and if the task is dependent or non-dependent.
• 2) Set up a chart  -  With the total timescale across the top.
• 3) Plot the tasks  -  One per line, on the chart. Start each task at the earliest start and draw a solid horizontal line to show how long the task will last.
• 4) Link the dependent tasks.

Data Flow Diagram (DFD):  Shows how data moves through a system. It shows who the system interacts with in the form of external entities.

• DFD focuses on the processes that transforms incoming data flows (inputs) into outgoing data flows (outputs).
• Shows how the processes craete and use data that is held in data stores.
• Doesn't show the hardware or software required to operate the system.
• Has rules about how the components can be linked.