15. System Life Cycle - Summary of IT 9626 Chapter 15 PDF

Preview

Summary

Glossary of command words This glossary should prove helpful to candidates as a guide, although it is not exhaustive and it has deliberately been kept brief. The number of marks allocated for any part of a question is a guide to the depth required for the answer. Command word What it means Analyse e...

Description

Glossary of command words This glossary should prove helpful to candidates as a guide, although it is not exhaustive and it has deliberately been kept brief. The number of marks allocated for any part of a question is a guide to the depth required for the answer.

Command word

What it means

Analyse

explain the main points or effectiveness in detail, identify their characteristics, examine closely

Annotate

add an explanatory note

Calculate

work out the value of something

Compare

identify similarities

Complete

finish a task by adding to given information

Contrast

identify differences

Create

produce

Define

specify meaning

Describe

set out characteristics

Discuss

give the important arguments for and against, often requires a conclusion; this command word requires ‘Analysis’ and ‘Evaluation’

Enter

put in information

Evaluate

discuss the importance of, weigh up the advantages and disadvantages, judge the overall effectiveness, weigh up your opinions

Examine

investigate closely

Explain

set out purposes or reasons

Export

send data file from one piece of software to another piece of software

Extract

take out

Format

determine features

Give

produce an answer from recall

Identify

name or otherwise characterise

Import

insert data file from one piece of software to another piece of software

Insert

add new data item to file

Merge

combine into single structure

Name

identify or specify

Open

access a file

Perform

carry out

Prepare

make ready

Provide

supply

Replicate

copy formula from one cell to another

Round

write a value as whole number/number of specified decimal places

Set

fix format as

Sort

put in order, including ascending or descending

State

express in clear terms

Suggest

present a possible case

15. System life cycle Candidates should be able to: 15.1 Analysis

Analyse And Evaluate Different Methods Of Researching A Situation (Including: Questionnaires, Interviews, Observation, Document Analysis) Questionnaires ● A set of printed or written multiple choice questions, opinion ratings, and open questions devised for the purposes of a survey or statistical study ● An instrument for collecting data, and almost always involve asking a given subject to respond to a set of oral or written questions. ● Asking users of the current system questions about the current system in the form of hard copy/complete form on paper/on-screen ● Collect data directly from a large number of system users Prepared questions are given to the system users and they are left with the users for the questionnaire to be completed. Questionnaires usually focus more on simple questions and are filled by ticking or circling options or shading in boxes. A mixture of multiple choice questions, opinion ratings, and open questions provide a balance of quantitative analysis of closed questions and a qualitative analysis of open questions. The purpose of the questionnaire is to extract useful information on the current and/or proposed system. For example: ● Is the current system easy to use? YES/NO ● Does the current system freeze or crash? YES/NO ● How would you describe the speed at which the current system performs? SLOW/FAST/VERY FAST Uses: Questionnaires are used… ● When information is required from a large number of users, and would be impractical to interview them all; this results in a large sample size for the results of the questionnaire to be quantified and compared

● As an alternative to interviews if it is impossible to arrange an appointment time with a user or users Advantages of Questionnaires: ● Using questionnaires made up of a standard set of questions so same/ identical questions are asked of everyone ● Can be used to collect information from a large number of users quickly/in short time ● Can be anonymous so answers may vary in truthfulness ● Quantitative analysis of the responses can be carried out to produce e.g. statistics ● Questionnaires are not time-consuming as questions can be answered quickly ● Questionnaires are practical Disadvantages of Questionnaires: ● The lack of personal contact means that answers cannot easily be clarified ● The return rate of the questionnaires may be low ● Ambiguous/vague/incomplete/inaccurate answers may invalidate the responses/information collected ● Questionnaires do not allow the analyst the opportunity to elaborate on answers without contacting the user again ● It is hard to ask very technical or specific questions on a questionnaire ● Is argued to be inadequate to understand some forms of information - i.e. changes of emotions, behaviour, feelings etc. ● The respondent may be forgetful or not thinking within the full context of the situation ● People may read differently into each question and therefore reply based on their own interpretation of the question - i.e. what is 'good' to someone may be 'poor' to someone else, therefore there is a level of subjectivity that is not acknowledged

Interviews ● A meeting of people face-to-face, especially for consultation; a conversation between a systems analyst and a client body (a user or users of the system), used as the basis of an evaluation ● Interviews take place face-to-face and usually involve more detailed questions than questionnaires. The interviewer asks questions that are tailored to people at various levels of the business (managers, directors, employees etc.). Interview questions should be planned and designed to elicit the required information from the client

● Interviewing is a face-to-face method (used to collect facts directly from the users of the system being analysed) to get more in depth answers from management/users of current system regarding the current system/eliciting answers by asking follow up questions dependent on the replies given For example: ● To the management team, questions will focus on the requirements of the organization as a whole and then information that is required for decision-making ● To end users, questions should be aimed at finding out what the users need to make their jobs more efficient Uses: Interviews are used… ● Where there is a single end user or a small group of end users ● To elicit the required information from the client Advantages of Interviews: ● Interviews allow for questions to be explained if they are misunderstood ● There is direct contact between analyst and interviewee, and the analyst/interviewer can ask specific questions in order to get useful information from the interviewee ● Questioning can be flexible so points can be clarified/followed up and expanded upon ● The confidence of the interviewee can be gained and the quality of information gathered may be increased/enhanced/improved Disadvantages of Interviews: ● Answers may not be honest due to identity disclosure ● Interviewing is not suitable for collecting information from a large number of users of a system ● It can be time-consuming and expensive to interview everyone ● Interviewees can decline to give useful information/not give all the information required ● Analyst may lack the skills to extract all the information needed from the interviewee so answers may be inaccurate and contain insufficient information

Observation ● The action or process of observing something or someone - in this case, the users of the system - carefully in order to gain information ● The analyst watches the processes that take place within an organization to find out how everyday tasks are completed using their current system. It usually involves sitting with users to understand their assigned tasks with a chance to ask questions of the users to elicit further information. Other options can include wandering around an office throughout the day to see how information is shared. By way of observation, the system analyst logs or makes notes on the facts perceived For example: ● The input, processes and outputs of the system ● What the system does well ● If there are any errors or faults within the current system Uses: ● To get a good understanding of the current system performance ● To see how information is shared amongst users Advantages of Observation: ● Analysts can see exactly what tasks of the current system performs well or doesn’t perform well ● Not expensive to carry out as the user doesn’t have to leave his/her workspace ● Observation (by the analyst of the system procedures while they are being carried out) enables the analyst to witness/see/observe directly/first-hand how the system actually works and how the users use it ● Observation provides a realistic view of the system ● The actual methods of working and the procedures can be observed ● The observed data are collected in real time and are usually more accurate than second-hand data Disadvantages of Observation: ● The system analysts mat intimidate the user being watched and may cause the user to act differently ● Observation is time-consuming and expensive as the analyst has to do it in real time ● Some procedures/events/problems may not take place at the time of observation

● Direct observation may make the observed person act in a different way than usual

Document Analysis ● Detailed examination of the elements or the structure of a piece of written, printed, or electronic matter that provides information or evidence or that serves as an official record, typically a basis for discussion, evaluation or interpretation. ● This involves evaluating paperwork for the current system. The paperwork holds information on the current system and provides information needed to develop the new system. It is highly recommended that this method is used in conjunction with other analysis methods ● Documentation reading/research/analysis is examining existing data, records, manuals used for the existing system ● Looking through technical and user documentation about the current system/documents produced by current system/two of checkout receipts/ payslips/order forms/invoices ● Find out information about transaction types and goods on sale/to study what data is collected and what information is output/to identify inputs and outputs of the system For example: ● Technical documentation helps inform the analyst on how the current system has been built. This helps developers maintain the good features of the current system for the new one. The paperwork can include: ● List of stock items that will be stored on the new system ● Employee pay scales (needed for processing in a payroll system) ● Technical documentation which contains information on the current system and helps with the development of the new system Uses: Document analysis is used… ● To obtain a lot of information about the system currently in use ● To provide an estimate of the amount of data that is likely to be required Advantages of Document Analysis:

● ● ● ●

Copies of previous analysis helps save time Analysts can see existing inputs processes and outputs The analyst can obtain actual/real/existing information about the existing system It is a quick way to gather information compared to the other methods

Disadvantages of Document Analysis: ● ● ● ●

Document analysis is unsuitable where there is insufficient/poor quality documentation Some documentation expected by analyst may not exist Very time-consuming to look through all of the existing documents Tends to be very expensive as the analyst will need to be paid for the time spent reviewing documentation

Describe The Content Of The Requirements Specification, System Specification And Design Specification Requirements Specification ●

Requirements Specification ○ - description of what the customer / (end) user wants the system to do ○ - document that defines the customer’s / (end) user’s needs ○ - so that it is possible to check if final system meets the analysis ○ - outcome of the analysis stage of systems life cycle

● A structured document that sets out the services the system is expected to provide. ● Should be precise so that it can act as a contract between the system procurer and software developer. Needs to be understandable by both. ● Describes what the system will do but not how it will do it (objectives but not how objectives will be achieved). ● To be part of the contract between the developers and the end user/purchaser/commissioning company ● To provide a mandate/terms of reference for the design and development of the software/contain all the information to define the function of the new software ● To provide a list of (testable) design criteria for the software/features to be included in the software ● To list what the user expects the new software to be able to do

● To ensure that all mandatory features (e.g. accessibility options) are included ● To rank the features (required by end user) in order of mandatory, desirable, optional and possible future developments ● To provide a set of success criteria against which the software can be tested/evaluated.

Contents of Requirements Documents: ● Introduction: Describes the need for the system and places it in context, briefly describing its functions and presenting a rationale for the software. Describes how the system fits into the overall business or strategic objectives of the organization commissioning the software. ● System Model: Shows the relationships between the system components and the system and its environment. An abstract data model should also be described if appropriate to the type of system. ● System Evolution: Fundamental assumptions on which the system is based and anticipated changes due to hardware evolution, changing user needs, etc. ● Functional Requirements: The services provided for the user. This includes timing and accuracy requirements. ● Constraints: Constraints on how the goals can be achieved (restrictions on behavior of software and freedom of designer), e.g., safety, hardware, programming languages, standards that must be followed. Includes quality requirements such as maintainability, availability, etc. ● Priorities: Guides tradeoffs and design decisions if all requirements and constraints cannot be completely achieved. ● Interfaces to the Environment: Input or output interfaces and relevant assumptions about environmental components with which the software will be interacting. ● Glossary: Definitions of technical terms used in the document.Indexes: Various types of indexes may be provided. Attributes of a good requirements document: ● Readable and understandable by customers, users, and designers. ● Specifies only external system behavior (black box) Structured to be easy to change. ● Specifies both goals and constraints. ● Able to serves as a reference for system maintainers. Consistent, complete, unambiguous, realistic, and testable Specified acceptable responses to undesired events. ● Specifies what should not do as well as what should do. ● Specified incremental subsets if desired or minimum and maximum functionality ● Specifies changes anticipated in the future (for both environment and software)

Requirements must be testable: ● An untestable requirement: ○ The system shall be easy to use by experienced controllers and shall be organized in such a way that user errors are minimized. ● A testable requirement: ○ Experienced controllers shall be able to use all the system functions after a total of two hours training. After this training, the average number of errors made by experienced users shall not exceed two per day.

System Specification ● Systems documentation.... ○ ....provides a detailed overview of the whole system. ● Test data/test plans so that systems analyst can see the results of these/test results. ● Can use this data again to check if errors have been successfully removed. ● The results of the systems analysis/DFD diagrams. ● What is expected of the system/purpose of the system. ● Overall design decisions such as the choice of hardware and software/file, input and output structures. ● Systems flowcharts.

● Program documentation.... ○ ....produced for program code that has been written. ● Description of the software/purpose of the software. ● Reasons for choosing those pieces of existing software that were used… ○ ..... instead of the programmer having to write code. ● Input and output data formats. ● Program flowcharts/algorithms. ● Program listing – this will be a complete copy of the code used… ○ … and annotation explaining what each module of code does. ● Notes that will help any future programmer to make modifications to the system.

Design Specification ●

Design Specification

○ ○ ○

- Describes how a system performs the requirements outlined in the requirements specification - May include specific details (accept examples e.g. inputs, flowcharts, screen layout, data type, validation etc.) - Defines the objectives of the system

● An abstract description of the software that serves as a basis for (or describes) detailed design and implementation ● Describes how the requirements will be achieved. ● Primary readers will be software designers and implementers rather than users or management. ● Goals and constraints specified in requirements document should be traceable to the design specification (and from there to the code).

15.2 Design

Identify A Flow Of Data Through A System And Create A Data Flow Diagram (DFD) And A System Flowchart Data Flow Diagrams (DFD) or Bubble Chart It is a technique developed by Larry Constantine to express the requirements of system in a graphical form. ● It shows the flow of data between various functions of system and specifies how the current system is implemented. ● It is an initial stage of design phase that functionally divides the requirement specifications down to the lowest level of detail. ● Its graphical nature makes it a good communication tool between user and analyst or analyst and system designer. ● It gives an overview of what data a system processes, what transformations are performed, what data are stored, what results are produced and where they flow. Basic Elements of DFD

DFD is easy to understand and quite effective when the required design is not clear and the user wants a notational language for communication. However, it requires a large number of iterations for obtaining the most accurate and complete solution. The following table shows the symbols used in designing a DFD and their significance − Symbol Name

Symbol

Meaning

Square

Source or Destination of Data

Arrow

Data flow

Circle

Process transforming data flow

Open Rectangle

Data Store

Types of DFD DFDs are of two types: Physical DFD and Logical DFD. The following table lists the points that differentiate a physical DFD from a logical DFD. Physical DFD

Logical DFD

It is implementation dependent. It shows which functions are performed.

It is implementation independent. It focuses only on the flow of data between processes.

It provides low level details of hardware, software, files, and people.

It explains events of systems and data required by each event.

It depicts how the current system operates and how a system will be implemented.

It shows how business operates; not how the system c...