• 1. Type of Information System
• 2. Explain SDLC (5)
• 3. Explain Spiral model
• 4. Explain other IS development methodology (5)
• 5. Explain Functional, Non-functional, Usability requirements
• 6. Explain Fact fiding techniques (interview, observation) (5)
• 7. Explain OOP terms
• 8. Advantages of Object-oriented development

1. Type of Information System

a. Operational Systems / Transaction Processing System (TPS)

• Automate the routine, day-to-day record keeping tasks in an organization.
• Repetitive tasks that involve little judgement in their execution are the easiest to automate.
• Organization to keep track of money
• Automates daily routine monotonous / repetitive tasks
• Not a very “intelligent” system
• Easiest to develop
• Example Accounting Systems
  • Keep track of money (the amount coming in, the amount going out, cash available to be spent, credit that is available)

b. Management Support Systems / Management Information System (MIS)

• To support management work at a much higher level of complexity.
• Much of the information used by management to make decisions.
• Crucial aspect of MSS is the feedback or feed-forward that it provides, alerting managers to problems and opportunities, and assisting them in the process of tuning the organization’s performance.
• Operational systems are located in the central box (labeled ‘what the system does?’) – supporting work of I/O.
• Management support systems are located in the lower part (labeled ‘control unit’) – support the flow of feedback to, or control information from, the control unit.
• Collects information from the operational systems and presents information in the most useful format for decision-makers
  • Example: Summarized information such as total quantity of sales
  • Which products were not selling
  • To identify and resolve problems as they occur
• More “intelligent” than the operational systems
• Have somehow become the de facto standard in most of today’s computerized information systems
• Many are built on top of operational systems
• Provides feedback/ feed-forward, control unit

c. Executive Information System (EIS) / Executive Support System

• It helps the executive to organize the interaction with the external environment by providing graphics and drilling facilities.
• It helps the users to address unstructured decision problem by creating an environment that is conductive to thinking the strategic problem.
• Structured decision
  • Made under established situations
  • Situations fully understood
  • Programmable / preplanned
  • Generally made for routine tasks
  • specialized
• Unstructured decision
  • Made under emergent situation
  • Creative
  • Not preplanned
  • Situations uncertain / unclear
  • Made for a sudden one-shot kind of situations
  • Made for general purposes

d. Real time Control systems

• Explicitly concerned with the direct control of a system’s operations, often physical in nature. e.g. lift control systems, aircraft guidance systems.
• Best considered as a control sub-system of a physical processing system.
  • Usually have human operators, but they are generally insulated from the surrounding human activity system.
• Has human operators
• Direct handling / control of a system’s operations, often physical in nature systems
• Example: lift control systems; aircraft guidance systems; manufacturing systems; robot forklifts
• Techniques used for the analysis, design and implementation of real-time systems are very similar to those used for other computer systems

2. Explain SDLC (5)

• It is a phased and systematic approach to analysis and design in order to produce a quality system.

i. System Planning

• Identify problems, opportunities and objectives
• Identify business requirements and how (conceptually) the system will address them
• Define the problem
• Confirm project feasibility
• Produce the project schedule, staff the project, launch the project
• Deliverables:
  • Preliminary Investigation Report
• Note:
  • Knowing the scope of the system is important!
  • Focus!
  • Don’t do something out of your system’s scope
  • Initial understanding of problems is essential

ii. System Analysis

• Find out more about the purpose of this system
• Analyse problem identified
• Identify the purpose of this system
• Define System requirements
• Understand interaction of system with other systems
• Identify subsystem
• Identify purpose of subsystem
• Identify improvements for current system
• Identify constraints (Problems)
• Ask users what exactly are their roles in this system
• Ask users also what are their expectations of the system
• Deliverables:
  • Data Flow Diagrams / Data Dictionary / UML Diagrams / ER Diagrams etc.
  • System Requirements Report (Functional Vs. Non-functional requirements)
• Note:
  • Clear understanding of the exact scenario is of utmost importance!
  • Tackling incorrect problems would result in wasting of good resources
  • Important to ensure that everybody has the same understanding of the scenario
  • Communication plays a major role here

iii. System Design

• Understand processes involved in each individual subsystems
• Understand the interconnectivity among the subsystems
• Know how to connect all subsystems together to form the system
• Design the interface for the subsystems (input and output)
• Deliverables:
  • Design Specifications report
  • Update the Data Flow Diagrams / Data Dictionary / UML Diagrams / ER Diagrams
• Note:
  • Get in touch with intended users frequently to ensure proposed design meet their expectations

iv. System Implementation

• Determine hardware & software requirement
• Determine the best & most appropriate programming language to use
• Plan on the best methods to train intended users
• Plan appropriate conversion strategy to migrate from existing to new system
• Deliverables:
  • Documentation of all the items mentioned above
• Note:
  • Ensure that users had been kept updated on the progress
  • Get the users to provide feedback from time to time

v. System Testing and Maintenance

• Check whether all subsystems are working “harmoniously” with one another
• Check whether the system is functioning as intended (using both test & actual data)
• Check the stability of the system
• Provide support to end users
• Are the users happy with the system?
• Are there any aspects of the system which could be improved further?
• How can the system be maintained to lengthen its life span?
• Deliverables:
  • Reports & updates based on feedback provided by intended users
• Note:
  • Important to ensure that final product matches the requirements of intended users and the right testing method is used.

3. Explain Spiral model

4. Explain other IS development methodology (5)

A) Prototyping

• A partially working system built to explore certain aspect of the system requirements (e.g. appropriateness of a certain programming language / database management system / communications)
• Not intended to be treated as the final working system (lacks full functionality, limited quality assurance)
• Prototype Objectives
  • to investigate user requirements
  • to investigate the most suitable form of interface
  • to determine whether a particular implementation platform can support certain processing requirements
  • determine the efficacy (effectiveness) of a particular language
• Major Steps:
  • Perform an initial analysis
    • prototyping is going to utilize valuable resources.
    • perform initial analysis otherwise, prototype will result in ill-focused and unstructured activity producing poorly designed software
  • Define prototype objectives
    • prototyping should have clearly stated objectives
    • it should be possible to decide if they have been achieved
  • Specify prototype
    • it will be subject to change and this will be easier if the software is built according to sound design principles
  • Construct prototype
    • in a rapid development environment
  • Evaluate prototype and recommend changes
    • it should be evaluated with respect to the objectives identified at the beginning of step 2
    • if the objectives have not been met then the evaluation should specify modifications to the prototype so that it may achieve its objectives

5. Explain Functional, Non-functional, Usability requirements

Types of Requirements:

• Functional
• Non-functional
• Usability

A. Functional Requirements

• Describe what a system must do or is expected to do - functionality
• Include:
  • descriptions of the processing that the system will be required to carry out
  • details of the inputs into the system from paper forms and documents, from interactions between people, such as telephone calls, and from other systems
  • details of the outputs that are expected from the system in the form of printed documents and reports, screen displays and transfers to other systems
  • details of data that must be held in the system

B. Non-functional Requirements

• Concerned with how well the system performs
• Include:
  • performance criteria - response times for updating data in the system or retrieving data from the system
  • anticipated volumes of data (throughput or what must be stored)
  • security considerations

C. Usability Requirements

• Concerned with matching the system to the way that people work
• Sets measurable objectives
• Include:
  • characteristics of users
  • tasks that users undertake (including the goals that they are trying to achieve)
  • situational factors that describe the situations tha could arise during system use
  • acceptance criteria by which the user will judge the - delivered system

6. Explain Fact fiding techniques (interview, observation) (5)

Fact Finding Techniques:

• Background Reading
• Interviewing
• Observation
• Document Sampling
• Questionnaires

i. Background Reading

• Aim is to understand the organization and its business objectives
• Includes:
  • company reports
  • organization charts
  • policy manuals
  • job descriptions
  • documentation of existing systems
• Advantages:
  • helps the analyst to understand the organization before meeting the people who work there
  • helps to prepare for other types of fact finding -> being aware of business objectives of the organization
  • documentation of existing system may help to identify requirements for functionality of new system
• Disadvantages:
  • written documents may be out of date or not match the way the organization really operates
• Appropriate situations:
  • analyst is not familiar with organization
  • initial stages of fact finding

ii. Interviewing

• Aim is to get an in-depth understanding of the organization’s objectives, users’ requirements and people’s roles
• Includes:
  • managers to understand objectives
  • staff to understand roles and information needs
  • customers and the public as potential users
• Advantages:
  • personal contact allows the interviewer to respond adaptively to what is said
  • it is possible to probe in greater depth
  • if the interviewee has little or nothing to say, the interview can be terminated
• Disadvantages:
  • can be time-consuming and costly
  • notes must be written up or tapes transcribed after the interview
  • can be subject to bias
  • if interviewees provide conflicting information this can be difficult to resolve later
• Appropriate situations:
  • most projects
  • at the stage in fact finding when in-depth information is required

iii. Observation

• Aim is to see what really happens, not what people say happens
• Includes:
  • seeing how people carry out processes
  • seeing what happens to documents
  • obtaining quantitative data as baseline for improvements provided by new system
  • following a process through start-to-end
• Can be open-ended or based on a schedule
• Advantages:
  • first-hand experience of how the system operates
  • high level of validity of the data can be achieved
  • verifies information from other sources
  • allows the collection of baseline data
• Disadvantages:
  • people don’t like being observed and may behave differently, distorting the findings
  • requires training and skill
  • logistical problems for the analyst with staff that work shifts or travel long distances
  • ethical problems with personal data
• Appropriate situations:
  • when quantitative data is required
  • to verify information from other sources
  • when conflicting information from other sources needs to be resolved
  • when a process needs to be understood from start to finish

iv. Document Sampling

• Aims to find out the information requirements that people have in the current system
• Also aims to provide statistical data about volumes of transactions and patterns of activity
• Includes:
  • obtaining copies of empty and completed documents
  • counting numbers of forms filled in and lines on the forms
  • screenshots of existing computer systems
• Advantages:
  • for gathering quantitative data
  • for finding out about error rates
• Disadvantages:
  • not helpful if the system is going to change dramatically
• Appropriate situations:
  • always used to understand information needs
  • where large volumes of data are processed
  • where error rates are high

v. Questionnaire

• Aims to obtain the views of a large number of people in a way that can be analysed statistically
• Includes:
  • postal, web-based and email questionnaires
  • open-ended and closed questions
  • gathering opinion as well as facts
• Advantages:
  • economical way of gathering information from a large number of people
  • effective way of gathering information from people who are geographically dispersed
  • a well designed questionnaire can be analysed by computer
• Disadvantages:
  • good questionnaire are difficult to design
  • no automatic way of following up or probing more deeply
  • postal questionnaire suffer from low response rates
• Appropriate situations:
  • when views of large numbers of people need to be obtained
  • when staff of organization are geographically dispersed
  • for systems that will be used by the general public and a profile of the users is required

7. Explain OOP terms

refer to chap05.doc

8. Advantages of Object-oriented development

What is Object-oriented Development

• Development of software using self-contained objects/modules that can be replaced, modified and reused
• Software is considered to be a collection of discrete objects
• Each object has attributes (data) and methods (functions)
• Objects are later grouped into classes
• Example:
• Each Windows application requires several Windows objects to function properly
• Basically, a common Windows object could open, resize or close any particular Windows application
• After opening the required Windows application, another object responsible for the running of that particular Windows application would take over and proceed with processing

Advantages of object-orientation development

• Higher level of abstraction
  • Traditional approach supports abstraction at the function level (low level)
  • Object-orientation approach supports abstraction at the object level (higher level)
  • Development can proceed at the object level. Only after getting most (if not all) of the objects ready, would the actual system development begin. System development here refers to the means on getting all objects to work harmoniously together.
  • This makes designing, coding, testing and maintaining the system simpler
• Seamless transition among different phases of software development
  • Traditional approach requires different styles for each step of the development process
  • This would slow down the process and also increase the size of the project (which would indirectly introduce more errors)
  • The object-orientation approach somehow uses a common style (language) for all steps in the development process (analysis, design, programming & database design)
  • The object orientation approach reduces the level of complexity and makes system development easier and more straight forward
• Encouragement of good programming techniques
  • A class in object-oriented system carefully distinguish its interface (what the class can do) and the implementation of the interface (how the class do what it is supposed to do)
  • Methods and attributes within a class are held tightly together
  • Classes would then be grouped into subsystems but would remain independent
  • By maintaining its independence, it would minimised its impact on other classes when changes are being made to any particular class
• Promotion of reusability
  • Objects are reusable because they are modelled directly out of a real world problem domain
  • Object-orientation adds inheritance which allows new classes to be build from existing classes
  • By doing so, design and coding would only be made for the differences (not for the entire class) as all previous functionality remains and could be reused without change

9.