Systems Analysis and Desgin Notes

Systems Analysis and Design
Instructor: Balirwa Moses Email: dbalirwa@yahoo.com
System Analysis and design by Balirwa Moses 2010
Introduction
The Systems Development Process (Overview) Project Selection and sources of Projects
Course Overview
Business and government rely heavily on information systems to support their missions and goals. In fact it is almost impossible to conduct substantial business these days without 'computers''. Many people use the word "computers" as a surrogate for the information system on which they are relying. This is an introductory resource for systems analysis, design, and implementation of information systems. Systems analysis, design, and implementation are, in the broadest sense, the processes used by professionals to develop or maintain information systems.
System Analysis and design by Balirwa Moses 2010 3
Objective
To give an understanding of the methodologies and the applicability of the steps involved in analysing, designing, testing and implementing a computer / information system. Why? Projects do not succeed by chance Successful IT projects follow systematic analysis and design process
Introduction
Earlier applications that used computers were business applications, such as
keeping records of transactions, Airline reservations etc.
Computers are now becoming part of virtually every activity in an organization.

What Information Systems Can Do

PORT OF ROTTERDAM
Largest commercial port

30,000 ocean going vessels & 150,000 river boats per year
300 million tons of cargo per year

$35 billion in revenue per year Fierce competition from other ports Develop plan 2010 - $23 billion to be spent on developing IS
Port business is very dependent on quick information exchange between the companies involved Large oil companies, freight forwarders, custom brokers need to get there IS connected with that of the port for fast exchange of cargo manifests, import permits etc. All such documents in digital form Similar methods adopted by Port of Singapore
Processing time reduced from 2-4 days to 15 minutes

Keeping a ship in dock for an extra day costs its owners dearly, amounting to millions of dollars Singapore port has cut down its processing staff by 75% Volume of shipment has doubled Economies of EDI benefits both customers & the port Container handling companies can prepare the appropriate freight just in time for truck arrival The times that trucks spend in the port has been cut down to 15 to 20 minutes from a previous 1-2 hours
Even a small company now stops at the port 50-55 times a day Vessel Traffic Management System provides traffic controllers with a complete overview of traffic in the port 24 hrs. a day Maintains historic data too for seagoing ships Helps managers to control current operations as well as plan for the future Gets help from Rotterdams Erasmus University Will create many job opportunities in the IT sector
Definition
SA & D covers the entire systems development process from planning all the way through implementation, maintenance, and evolution. It is a process that includes all activities performed to produce an automated IS.
10
Justification of SA & D
What an organization needs to do in order to computerize.
11
What is a System?
A System is set of interrelated components, working together for a common purpose. A generic systems model consists of six components inputs, outputs, controls, feedback, and boundary. Using predetermined controls, a system accepts inputs at its boundary, processes them into outputs, and provides a feedback mechanism for taking any necessary corrective action.
Cont
The internal control subsystem either directly implements change to the IS or notifies the enduser that the system is not functioning properly. Controls ensure that input data is valid before its processed, that file and database data are protected against unauthorised access and update, that recovery procedures are available for a system catastrophe, that output information is disseminated to proper end-users, and that other relevant conditions are met.
System Boundary
A boundary (scope) is the perimeter or border of the system elements, features, options, that will be included in the system. Systems Model with six components
Boundary
System
Processing Inputs Controls Feedback Outputs
14
Components of an Automated Information System

An IS is an arrangement of interdependent human and machine components that interact to support the operational, managerial, and decision-making information needs of the businesss end-users. An IS is made up of: Hardware Software People Data procedures
An Automated Information System
Data
People
Software
Procedures Hardware
16
Characteristics of an Information System

Data are either (I) input via some data entry device, (II) already in the system and stored on a storage device, or (III) displayed or printed on an output medium. Function (process, method) is a transformation or action taken by the IS. Functions carry out and enforce business policies, rules, and procedures. Behaviour is the observable effects of a request.
Basic Characteristics of an IS
Data Functions
Behaviour
Data: input, stored, or output Function: business activity performed Behaviour: the observable effects of a request
Systems Development Process (Overview)

SA & D takes a much broader perspective and focuses on: Systems Planning performing planning and initial feasibility activities to determine which IS projects take priority over others. Systems Analysis understanding and documenting the requirements of a specific problem domain. A problem domain refers to the business problem or function being planned, analysed, designed, and ultimately implemented as an automated IS.
Cont
Systems design designing an appropriate solution for the problem domain based on the documented requirements from SA. Systems Implementation constructing, testing and installing the information system and having the users use the IS. Systems Evolution maintaining and enhancing an IS so that it continues to meet the needs of the business.
What does a Systems Analyst Do?

A systems analyst studies the problems and needs of an organisation to determine how people, methods, and computer technology can best accomplish improvements for the business. Duties of a Systems Analyst Look at how information is used, handled and manipulated in an organization.
21
Cont
Identifying inefficiencies in the current system that the organization is using e.g. delays, high operating costs, huge clerical effort. Analyze the results of the investigation that will lead to designing the system. Design and specification of a new system which overcomes the inefficiencies and meets organization objectives. Oversees the process of testing during the testing of the system.
Qualifications of SA Very wide and deep understanding of the concepts of IT. Ongoing interest in updating ones knowledge in IT. Qualities of a SA
Working knowledge of IS Techniques and Technology Computer Programming Knowledge Problem-solving skills (creativity) Interpersonal Relations skills (confidence, persistent, patience) Interpersonal communication skills
Stakeholders of an Information System Users Steering Committee
Managers
Systems Analyst
Database Administrators Programmers & Technical Staff
Vendors
Cont
NB. These teams will be created and disbanded as projects
are started and completed or cancelled.
What is the analysts role in the systems project? The analyst may be viewed as a facilitator. The analyst acts as the interface among many different types of people and facilitates the development of computer applications through these people. The analyst may well be the only individual who sees the big picture of the system.
Steering Committee
Role of the Steering Committee This committee is formulated in the organization to oversee the Systems Study and thereafter. Steering Committee is usually composed of cross functional, senior managers within a business: Personnel from IT department Vice presidents / directors Accounts department Administration
Cont
Data processing department SA team (if its from outside) Senior Information Systems Manager
Functions of the Steering Committee: The main role of this group is to conduct highlevel reviews and evaluations of proposed IS development projects and make recommendations for prioritization and resources for the projects.
Cont
Study, determine and maintain an IT policy for the organization. Get views and requirements of the user dept to be represented as they try to look for solutions for the entire organization. Initiating IT systems development projects. Interviewing and appointment of IT personnel. Selecting suppliers and negotiating supply contracts with them and include penalty clauses.
Cont
Vendors are those businesses which support the IS development effort, such as consultants, hardware, software companies, training companies, telecommunication companies, documentation companies, and so on.
29
General model of Systems Analysis, Design & Implementation
Stakeholder
Requirements (1)
Information System (6)
Continued Involvement (5)

Requirement Specification (3) Design & Implementation Problem Solution Skills (4)
Analysis
Problem Definition Skills (2)
Information Technology staff

30
Where do Systems Projects Originate?

New or changed IS development projects come from problems, opportunities, and directives and are always subject to one or more constraints. Most maintenance of existing IS projects come from users discovering real problems with existing IS. Problems may either be current, suspected, or anticipated. Problems are undesirable situations that prevent the business from fully achieving its purpose, goals, and objectives.
Cont
An Opportunity is a chance to improve the business even in the absence of specific problems. This means that the business is hoping to create a system that will help it with increasing its revenue, profit, or services, or decreasing its costs. A Directive is a new requirement that is imposed by management, government, or some external influence. I.e. are mandates that come from either an internal or external source of the business.
Constraints are limitations and compromises that come with the soon to be developed IS.
Systems Development Life Cycle

The Systems development life cycle (SDLC) is the process by which an IS comes to life and maintains its usefulness to a business as it moves from inception to replacement. Phases include: Systems planning planning for the new system. Feasibility study (optional) determines whether or not significant resources should be committed to the other phases of the life cycle. Systems study and Analysis requirements determination.
Cont
Conceptual (logical) define the inputs, files, processing, and outputs for the new system. Physical design outputs, inputs, files, methods, and procedures, internal controls, (these can be done by prototyping). Construction, and testing, or purchase, testing, and integration. Implementation Conversion from current system to new or changed system; Training. Evolution for enhancements and maintenance continuous systems support.
Principles to guide Systems Development

The system is for the end-user. Get the end-user involved through out the systems development. Establish phases and tasks to better manage systems development projects. Systems development tasks aren't strictly sequential. They can overlap. Also, you may need to backtrack / revisit to correct mistakes. Systems are capital investments. They should be economically justified as such. Establish checkpoints to re-evaluate feasibility, and dont be afraid to cancel infeasible projects despite sunk costs. Documentation should be the natural, working byproduct of systems development. Dont post document phases or tasks.
Feasibility Analysis and Requirements Determination

Feasibility Types Technical, Operational and Economic, and others Requirements Determination Sub activities Fact gathering techniques
36
How to Survey Feasibility of the project and study the current System
Purpose and objectives of the Survey and Study: To understand the current system and its problems and to determine if solving the problems would be beneficial. NB: The Survey phase is a preliminary investigation of the system, whereas the study phase is a much more detailed investigation.
37
Feasibility Study
Feasibility study:
Is the measure of how beneficial the development or enhancement of an IS would be to the business. A preliminary investigation is done at this stage. Purpose of the feasibility study: Define the problem it provides a broad statement of user requirements in users terms, or what the users expect the system to do (project goals)
Cont
This phase also sets project bounds, or scope of the system which defines what part of the system can be changed by the project and what parts are to remain unchanged. Document flow diagrams & a context diagram may help at this stage. Identify the users of the system. Specify the resources to be made available for the project (resource limits).
Cont
Propose general Hardware/systems software options in broad terms (client-server configuration), which is necessary to size the project. Perform a value assessment, such as the costbenefit analysis, based on the project size. Assess the project risks. Recommend whether to proceed with the project or abandon the project
Cont
project goals, project bounds and resource limits are some times called a projects terms of reference and set by the management of the organization. a) Feasibility Types Operational feasibility is the measure of how well a particular IS will work in a given environment. I.e. will the solution fulfil the endusers requirements? Will the organizational change result in an acceptable quality of working life for those affected by the system?
Technical feasibility is the measure of the practicality of a specific technical IS solution and the availability of technical resources. I.e. Do we have the technology & skills needed to develop & operate the system? Economic feasibility is the measure of the cost-effectiveness of an IS solution. I.e. Will the system result in competitive advantage to the enterprise? Legal Will the proposed system conform to laws & regulations? Ethical Will the proposed system conform to the norms of ethics?
b) Other aspects of feasibility study: What volumes of data will be handled, what numbers of users in various categories will be supported and with what levels of service, what file & database capacities the system will need to maintain, and other quantitative estimates of this type. What interface will be provided for the users to interact with the system, based on the skills & computer proficiency of the intended users. What control measures will be undertaken in the system.
Requirements Determination
It addresses the gathering and documenting of the true and real requirements for the IS being developed. A Problem Domain refers to the business problem, area, or function being investigated and analysed. The purpose of the investigation and analysis is to determine the need to purchase, make, or revise an IS to enhance the business activity of the problem domain.
Requirements is the wants and /or needs of the user within a problem domain.
Frameworks for understanding and doing Requirements Determination

1. Requirements Determination Sub activities Requirements determination is the general datagathering activity done during analysis. It has 4 sub activities: Requirements anticipation the SA hypothesizes that particular requirements are relevant based on his or her previous experience with other similar systems and knowledge about the problem domain. Requirements Elicitation the SA uses this activity to gather the essential requirements from the stakeholders employing a variety of techniques, such as interviews, questionnaires.
Cont
Requirements Assurance the SA uses this activity of requirements assurance to validate and verify the requirements with the user as being the real and essential requirements. Requirements Specification this is the activity that the SA uses to explicitly catalo and document the requirements either during or after the elicitation and assurance activities. This is a doc that outlines all the requirements that the proposed system must address. It forms a contract btn the system analyst and the customer the specification document further provides a basis for system testing and validation. It also helps in system in trouble shooting.
Cont
2. The PIECES Framework - Focuses on the actual work of doing requirements determination. The model is used to classify identified requirements into one of six subject areas:- Performance, Information, Economy, Control, Efficiency, and Services.
Performance questions address how the system needs to perform for the user. Issues of throughput and response time are considered. The Information category provides the basis for the information or data model that the system needs to maintain. Issues dealing with input data, output data, and stored data are considered.
Cont
Economy addresses project development and operational cost information along with any objectives that may relate to economy or savings associated with the system. The Control category is closely associated with system security issues as well as the editing required on the incoming data. Any issues related to controlling the use of the system, its outputs and inputs, or required controls over the data can be included in this category. Efficiency is a measure of method correctness. I.e. are things being done right? Services are functional requirements of the system.
Cont
3. Object-oriented Requirements Determination Modelling Activities emphasizes objects, patterns, responsibilities, and scenarios.
An object is a person, place, or thing, such as student, faculty, sales clerk, city hall, ATM machine. A pattern is a template of objects with stereotypical responsibilities and interactions; the template may be applied again and again, by analogy. Pattern instances are building blocks used to assemble effective object models. Responsibility is associated with objects and has three aspects to it: What I know, who I know, and what I do.
What the object knows about itself the things that an object knows about itself are called attributes. An attribute is a characteristic associated with a person, place, or thing object. Each characteristic has a state or value. Who the object knows a problem domain has many objects within it. Who the objects knows identifies relationships between objects. What the object does this translates into a list of services for each object. A service is some functionality that an object is responsible for performing. A scenario is a time-ordered sequence of object interactions to fulfil a specific responsibility. A scenario would be developed for each of the preceding services.
Cont
Coads object-oriented requirements determination modelling approach would involve the following four major activities: Identify purpose and features of the IS. Identify objects and patterns. Establish object responsibilities: What I know, who I know, and what I do. Work out the systems dynamics using scenarios.
Methods Used to gather an IS Requirements

Information Gathering Techniques
Asking the users

Interviewing Questionnaires Group Decision Making Process
Deriving from an Existing System
Deriving from the Analysis of the Business Area
Experimenting with the system under development
Data analysis Document analysis Observation Participation
Business Systems Planning Critical success Factors Decision analysis
Throwaway prototyping Evolutionary prototyping

52
Information Gathering Techniques

1. Asking the users
a) Interviews - Is a planned meeting during which you obtain information from users of the existing system. Advantages of interviews An opportunity to gather information from respondents who are knowledgeable about the system under study.
Cont
Best source of qualitative information I.e. opinions of people, policies, and subjective description of activities and problems. Useful for respondents who do not communicate properly in writing or are lazy to complete questionnaires. Allow SA to discover areas of misunderstanding unrealistic expectations and indications of resistance to the proposed system.
Cont
Disadvantages
Subjective and sometimes irrelevant. Communication problems Misunderstandings can rise from different user values, or technical jargons by the SA. Guidelines to interviewing The interviewer should acquaint him/herself with the work of the person he/she is going to interview.
Cont
Prepare before hand. Make an appointment, and the interview takes place away from the interviewees place of work to avoid interruptions. The interviewer should do little talking, let the interviewee do more talking, and make sure the discussion stays on truck. Be able to separate his/her opinion from facts and fictions from facts. Interview one person at a time.
Cont
Avoid the temptation to try and cover too much ground. End with a brief statement of what has been discussed. I.e. give a summary to the interviewee to cross-check with what been discussed, and if there are any misconceptions, corrections are made.
57
Cont
b) Questionnaires is a document containing a number of standard questions that you ask of a large number of people. Advantages Can be filled by a large number of respondents. Can get reliable information. Allow collection of data and can be filled in at leisure.
Cont
Use of standardized formats yield more and reliable data. It also ensures anonymity of respondents which can lead to more honest responses. Disadvantages Misinterpretation of the question. Does not lead to further/deep probing. They dont allow analysts the opportunity of observing and sensing reactions.
Guidelines to Questionnaire design Should begin with a preamble Bear in mind the level of intellect and the level of interests of the respondents Keep questions short, unambiguous and unbiased, and where possible have multianswers. If possible avoid too much branching. If the survey is extensive, you may consider use of automated means of reading responses. Pretest the questionnaire before using it for the purpose of checking whether all the questions will be easily understood.
c) Group Decision-making process/Formal Sessions Workshops and Brainstorming sessions are increasingly being used to draw out new ideas for systems. Get people who are familiar with the issues together to spontaneously explore ways of improving a system. Delphi technique, group members may be scattered around the world. A questionnaire may be circulated.
Cont
Important factors:
No criticism Anything goes The more the better Build on the ideas of others
62
Cont
2. Deriving from an existing system
Possibilities here are: The system that will be replaced by the proposed system A system similar to the proposed one that has been installed elsewhere & is accessible to the analyst A proprietary package, whose functionality may be analyzed.
Cont
a) Data analysis: The requirements for the proposed system are derived from the data contained in inputs (orders, invoices, time cards etc.) or data contained in the outputs (reports, worksheets) of the existing system b) Sampling of existing Documentation when you are studying an existing system, you can get a good idea by studying existing: documentation, forms, and files
Cont
First document that analyst should seek out is the organizational chart
Be sure that they are relevant and up-to-date
Document analysis usually accompanies the asking methods, as documents are difficult to be interpreted independently.
65
c) Observational Studies Systems Analyst participates in or watches a person perform activities to learn about the system. often used when validity of data collected through other methods is in question or when the complexity of certain aspects of the system prevents a clear explanation by the end users.
People usually feel uncomfortable when being watched.

Cont
Advantages of Observations Permits correction of any misconceptions or erroneous impressions made before. Permits verification of statements made in interviews as well as determine if procedures operate as specified in the system documentation. You become better acquainted with the operating personnel who will be implementing the new or changed system.
d) Measuring It is important in systems investigation, analysis and design in terms of: Magnitude of the exercises Processes Quantity of work Time taken to accomplish work (time frame works) Rates of doing work Intervals These help to determine the systems requirements, e.g. s/w, h/w e.t.c
3.
Deriving the requirements from the analysis of the business area

Using Business Systems Planning (BSP)
Define Business Processes
Define Business Data
Define IS Architecture
Analyze Current System support
Interview Executives
Define findings & conclusions
Determine Architecture priorities
Review information resource management
Develop recommendations
Report results
69
b)
Critical Success Factors methodology Those few critical areas where things must go right for the business to flourish
Obtain CSF of
Manager B
Obtain CSF of Manager A
Obtain CSF of Manager C
Combine individual CSFs

into Organizational CSFs Derive Informational requirements to support CSFs Use CSFs to redesign the organization and use informational requirements to plan IS
c) Establish informational needs of an individual manager by decision analysis Identify the key decisions that a manager makes Define the process by which the manager makes these decisions
Define the information needed for the decision process

Establish what components of this information will be delivered by the information system and what data will be needed to do so.
Cont
4. Prototyping
A method used to test or illustrate an idea and build a system in an explorative way.
Used to discover user requirements

Allows analyst to quickly create mock forms and tables to simulate the implemented system.
Identify basic User requirements
Rapidly develop prototype
Enable users to work with the prototype

Throwaway Perform further System devt With life Cycle, discard prototype
Evolutionary Development
complete document the final version, field it as the operational system
Obtain user feedback Modify the prototype

73
Advantages of a Prototype Valuable for the design of the end user interface of an IS. Users needs and behavior are not entirely predictable and are strongly dependent on the context of the situation. So it enables users to react immediately to the parts of the system they will be dealing with. It is more likely to produce a system that will fulfill user requirements, especially when it is used for decision-support applications.
Cont
It promises to eliminate excess development costs and design flows that occur when requirements are not fully captured the first time round. User satisfaction and morale are usually heightened because users can be presented with an actual working system, preliminary though it may be in a very short period of time.
Cont
Disadvantages
Prototyped systems still need to be fully documented and tested, but often these steps are shortened. The final step to convert the prototype into a polished production system may not be carried out. I.e. if it works reasonably, management does not / may not see the need for reprogramming and redesigning.
Systems Analysis Tools and techniques:

Users Requirement Document Decision Tables, Decision Trees, Structured English Process Modeling with Data flow diagrams (DFDs). Data Modelling with Entity Relationship Diagrams (ERDs).
Requirements Analysis
This process is usually characterized by the following activities: What outputs the system will produce, what inputs will be needed, what processing steps will be necessary to transform inputs into outputs, and what data stores (files or databases) will have to be maintained by the system.
78
Types of Requirements
User Requirements
Statements in natural language plus diagrams of the services the system provides and its operational constraints. Written for customers.
System Requirements
A structured document setting out detailed descriptions of the system services. Written as a contract between client and contractor.
User Requirement Document

User Requirement Document (URD) What the system should do (user requirement analysis).
Systems Analysts have to work out between themselves on what the system should do. They are guided by the URD. The URD has 4 categories of information:
80
Functional Requirements these describe the desired functionality of the new system I.e. what is expected of the system in behavior terms e.g. outputs and inputs of the system. Examples of Functional Requirements: The user shall be able to search either all of the initial set of databases or select a subset from it. The system shall provide appropriate viewers for the user to read documents in the document store. The system shall be designed in a way that makes it easy to update and easy to use.
Non-Functional Requirements these have the effect of limiting the choice so that if there many possible designs can be eliminated and dont have to be assessed. Theyre sometimes referred to as constraints. Usually concerned with the h/w, s/w, time and money constraints. Examples of NFR: The system shall not disclose any personal information about customers apart from their name and reference number to the operators of the system. The product shall use the company colors. Only direct managers can see the personnel records of their staff.
Design Objectives these are attributes of s/w that would enable comparison. Once the designer appreciates the relative importance that the user attaches to a certain property then that would be the most outstanding design objective e.g. should be user friendly, maintainable, easy to develop. Design Decisions these are premature statements usually requested by experienced users e.g. how the behavior is to be achieved rather than what behavior is required.
Such statements should be withdrawn or interpreted as non-functional requirements.
URD Diagram
URD
Analysis
NFR
FR RA SOR
DO
D
Example of A Decision Tree for a Discount Authorization process
Condition 1
Pay within 10 days Pay within 10 days
Condition 2
Action
Size of order over Take 3% discount 10.000/= from invoice total 5000 10000/= Take 2% discount from invoice total
Pay within 10 days
< 5000/=
Pay full invoice amount
85
Example - Discount Authorization Process

Over 10.000 --- 3%Discount
Discount Authorization Process
Pay within 10 days
5.000 10.000 --- 2%Discount
<5.000 --- pay full amount Pay after 10 days ----- No discount, pay Invoice amount
86
Cont
Decision Tables It is a tabular description of a selection structure. I.e. It is a graphic method for describing the logic of decisions. It provides a means of documenting procedures in which several complex decisions have to be made.
87
Decision Table diagram

1
Condition Statement
Action Statement
Condition Entries Action Entries
88
Cont Decision Tables

Condition Statement identify relevant items Condition Entry identify which value if any apply a particular condition. Action Statement will list all the steps that can be taken when a certain condition occurs. Action Entry identifies what specific actions in the set to take when selected conditions or combinations of conditions are taken.
Example: Insurance Application Process

Instructions to an insurance clerk reads as follows: Policy type 22 may be issued if the applicant has been issued with policy type 19 and is a married male or has been issued with policy type 19 and is married and under 25years. Alternatively if the applicant has not been issued with policy type 19 and is married female, policy 22 may be issued. Then a policy may also be issued to a male under 25 years, or married person who is 25 years or over. All other applicants are refused.
Insurance Application Process

Condition Stub Has policy type 19? Married? Male? Under 25? Action Stub Issue policy type 22 Reject 1 Y Y Y . X 2 Y Y . Y X Rule 3 4 N . Y . N Y . Y X X
Else
5 . Y . N X X
91
Cont
Advantages of Decision Tables
Is concise, unambiguous, clearly conveying the logic involved, hence less danger of omitting a logical possibility. Enhanced communication with action separated from conditions. Easier to draw and theyre easily understood. Produces an automatic compact program documentation.
Cont
Its format is highly standardized. Can be checked mathematically for completeness and that all test combinations have been considered. Disadvantage however, they dont show the sequence of decisions.
93
Structured English - It is based on structured logic, or instructions organized into nested and grouped procedures and simple English statements such as add, multiply, move e.t.c.. I.e. it describes logical processes precisely and concisely. I.e. it uses narrative statements to describe a procedure. Developing Structures which express problem solutions:
Sequence Structures Is a single step or action included in a process. I.e. the completion of one process step in sequence after another process step. It doesnt depend on the existence of any conditions, so when encountered, it is always taken.
Cont
Decision Structures Occurs when two or more actions can be taken. I.e. the completion of one or two process steps based on the results of a test or condition. One must assess the condition and then make a decision to take the stated actions. E.g. the If statement. Iteration Structures the completion of a process step repeated until the results of a condition terminates this repetition. e.g. Loops Discussion Question When should a Systems Analyst choose a particular process description tool / technique to use? (Guidelines for choosing a technique to use).
Structured Analysis
It deals more with the logic of the system requires the analyst to define what the system should do. I.e. breaking down the system into manageable subsystems method for defining systems inputs, processes, and outputs, and for partitioning systems into subsystems or modules that show a logical graphic model of information flow. Objective of Structured Analysis - Is to document all the end user requirements for the proposed IS and present these requirements in the systems requirement document.
Structured Analysis accomplishes the following: Views the system from the top to down. Specifies the interfaces that exist between modules. Rigorously specifies the processes or transformations that occur within each module. Components of Structured Analysis Data Dictionary description of all the data used in the system.
Cont
Graphic Symbols icons and conventions for identifying and describing the components of a system and relationship among these components. Procedure and Process description formal statements using techniques and languages that enable systems analysts to describe important activities that make up a system.
Cont
Rules standards for describing and documenting the system correctly and completely. Data Flow Diagrams show how data moves and changes through an IS in a graphical top-down fashion. I.e. a graphic representation of a systems components processes and the interfaces between them.
99
Process Modeling with Data flow diagrams (DFDs)

DFDs are useful for modelling the scope of a systems project in terms of its interfaces with other systems, the business as a whole, and the outside world. DFDs show how data flow to, from and within an IS and the processes that transform data. They also show where the data are stored. Symbols for drawing DFDs
100
Cont
DFDs are constructed using 4 symbols: Data flows ( ) - these show the movement of data between processes, external entities, and data stores in a DFD. Processes ( ) they portray the transformation of input data flows to output data flows in DFDs.
101
Cont
Data Store ( ) are either manual or automated inventories of data. E.g. computer files or databases, file cabinets, card files, microfiche e.t.c External Entity ( ) are originators or receivers of information outside the scope of the IS portrayed in the data flowing.
102
Cont
General rules for drawing DFDs
Any data flow leaving a process must be based on data that is input to the process. All data flows are named and the name reflects the data flowing between the processes, sources, and data stores. All the data needed to perform the process should be input to that process. The process should be independent of any other in the system each process has its own input and output.
Data Flow Diagram

GENERATE BALANCE
GENERATE BILL
CUSTOMER FILE GENERATE REPORT CUSTOMER PAYMENT FILE
MANAGER
104
Order
Invoice
Customer
Order processing system
Warehouse
Picking-labels
Order-rejectionnotice
Out-of-stocknotice
Context diagram of an order processing system

Context diagram - It is a simple DFD that depicts the system being studied as it relates to other systems, the business, and the outside world the interfaces flowing to or from external entities. DFDs can be drawn in various levels of details using a technique known as levelling, ranging from depicting an entire systems big picture to showing the detailed processing of a single transaction. The entire collection of DFDs is called a levelled set.
106
Document Flow Diagram

A diagramming technique which is used to identify physical movement of documents. It shows where the document comes from, where it goes to , and what it is called. The source and destination of the document are usually shown using an elliptical shape. For each document or communication that occurs in the system, identify the source and the target. This will help in developing a context diagram during analysis.
Document Flow Diagram of a Purchasing System

Order
Supplier Invoice Delivery notes
Purchasing Dept
Stores
Data Modelling using Entity Relationship Diagrams

Order No One
Customer
Customer No.
Name Address Balance due
Places
Many
Order
Many
Order Date Order Price Shipping Cost
Contains
Many
Product
Product No.
Product Name Price
109
Data Modelling using Entity Relationship Diagrams

A data Entity is anything, real, or abstract about which we want to store data. Most entities correspond to persons, objects, events or locations in the business environment. A data Relationship is a natural association between entities. All relationships are further described by words or symbols that indicate the number of occurrences of one entity that can exist for a single occurrence of the related entity.
In the definition phase, we look at requirements independently. I this phase, data modelling is performed. Entities, data elements and relationships are identified. Data models complement process models. In the selection phase, the following are addressed: The new files and databases to be designed are identified. How much data should be automated? Should it be central or distributed data storage? How relationships between data entities be stored?
Systems Design
Architectural design process Output design, input design, User interface design, file & database design, program specification design Prototyping
Systems Design
Systems Design details how a system will meet the information requirements as determined by systems analysis. Note that the primary input to design is the requirements specification document, which is the output from analysis. This document is critical to the success of the system because it represents the users requirements for the system.
Cont
Much of the contents of this document get transformed into design equivalents as the systems analysts begin to customize the proposed IS for the specific h/w and s/w platforms to be used for its creation and ultimate operation in some production environment within an organization. These specifications should be detailed enough to become inputs to the programming stage that follows the design. The design process is usually broken down into two parts.
Cont
Logical design produces the general specification of the resources that will make up the system - lays out the components of the IS and their relationship to each other as they would appear to users. Physical design produces a complete, detailed specification of the named program components and of the databases to be maintained by the system - the process of translating the abstract logical model into the specific technical design for the new system.
Cont
This activity addresses all of the environment, platform, and human-computer interface specifics for the proposed information system. Issues to be discussed and decided here include all aspects of the five components of an information system such as: hardware, software, data, people, procedures.
116
Objectives of Systems Design

Specify logical design elements detailed design specifications that describe the features of an IS: I/P,O/P, files, databases, and procedures. Support business activities results of using the system help business performance. Design fits the way the firm conducts its business.
117
Cont
Meet user requirements in terms of:performing appropriate procedures correctly; presenting proper form of information; providing accurate results; using appropriate methods of interaction; providing overall reliability. Easy to use favorable human engineering; ergonomic design that is physically comfortable and contributes to user effectiveness and efficiency.
Cont
Provide software specifications specific components and functions with adequate detail to construct application software. Confirm to design standards design and specification of the design in accordance with prescribed rules and practices of the organization.
119
Architectural Design
- The design process of identifying subsystems of a large system and establishing a frame work for sub-system control and communication. - It involves identifying major system components and their communications.
A sub-system is a system in its own right whose operation is independent of the services provided by other sub-systems. A module is a system component that provides services to other components but would not normally be considered as a separate system
120
Architectural design process

System structuring
The system is decomposed into several principal sub-systems and communications between these sub-systems are identified
Control modelling
A model of the control relationships between the different parts of the system is established
Modular decomposition
The identified sub-systems are decomposed into modules
What features must be designed Logical Design

Design specifications describe the features of a system. These are the elements of the system and their appearance to the users. These include: Data Flows the movement of data into, around, and out of the system are specified. Data Stores temporary or permanent collections of data are specified
122
Cont
Processes activities to accept, manipulate, and deliver data and information, may be manual or computer-based are specified. Procedures methods and routines for using the IS to achieve the intended results are specified. Roles the responsibilities of all persons involved with the new system, including endusers, computer operators, and support personnel are specified.
Cont
Controls standards and guidelines for determining whether activities are occurring in the anticipated or accepted manner I.e. under control. It also specifies actions to take when problems or unexpected circumstances are detected. May include the reporting of exceptions or procedures for correcting problems.
124
Physical design
When physical design is completed, the following aspects of the system will have to be specified: System outputs report layouts, document designs, screen designs System inputs data inputs & their validation procedures User-system interface exact protocols of usersystem interaction (menu trees, icons for graphic interfaces etc.) Platforms H/W & S/W platform (s) Acquisition method the way each component of the application will be acquired
Modular design of the programs that will be

developed for the application, interfaces between the modules, and the specification of the logic of the individual modules. The algorithms to be implemented in each module will be selected.
Detailed test plan the plan for various levels of

testing to be conducted during the later stages of development & a test suite containing the sets of tests for these levels.
Database logical & physical designs. Needed

capacities of files & databases have been estimated.
Controls application-specific controls, as well as the

necessary general controls.
Cont
Documentation a full set of documentation to be delivered with the system is specified. The documentation will include the user manual, systems & operation documentation, maintenance documentation. The requirement specification & the system design documentation will also be included in the documentation package. Conversion plan the plan for converting the present way of doing things to the new system
Techniques & Tools used in design

Structured design - The principal product of logical design are structure charts of the programs that need to be coded & tested. They are of 2 kinds: Modular structure Hierarchical design
128
Sales
COMPUTE-SALESTOTAL Sales Transaction Sales Total ADD-TOTOTAL
Transaction
Modular Design Sales Total
READ-SALESTRANSACTION
OUTPUTTOTAL
A B C
Hierarchical Design
129
PROCESS A
Program Flowchart
SEQUENCE
PROCESS B
TRUE
PROCESS E
PROCESS D
PROCESS C S
TRUE
SELECTION
ITERATION
System Flowchart
HUMAN RESOURCES DATA TIME CARDS PAYROLL MASTER
LOAD & VALIDATE
PAYROLL SYSTEM
VALID TRANSACTIONS PAYROLL MASTER
COMPARE &
UPDATE
PAYROLL REPORTS & CHECKS
DIRECT DEPOSITS
GENERAL LEDGER
UPDATED PAYROLL MASTER
131
System Flowchart Symbols

INPUT/OUTPUT PROCESS MAGNETIC TAPE
PUNCHED CARD
MANUAL OPERATION
ON-LINE STORAGE
DOCUMENT DATABASE ON-LINE INPUT
ON-LINE DISPLAY
TELECOMMUNICATIONS LINK
Program Flowchart Symbols

BEGIN OR END DIRECTION SUBROUTINE PROCESS MANUAL OPERATION INPUT OR OUTPUT
DECISION CONNECTOR
Cont
After the logical design stage, the processing steps to be carried out by individual modules are specified in physical design. Prototyping 4GLs, AG
Joint application development (JAD) participative development

Rapid application development (RAD) Object oriented design (OOD)
USER INTERFACE DESIGN

User interacts with the computer system through a combination of means User Interface User Interface is the yardstick by which the system is judged by the user Difficult to use Interface will cause errors, the system may be discarded, meaning of information may be misunderstood, may corrupt data, may cause system failure Text based interfaces were used in the early days Replaced by Graphical User Interfaces (GUI)
Cont
Windows Several windows on the screen enable the user to work with several programs, either simultaneously (multitasking) or on one Icons little pictures which may represent files or processes Menus Commands selected from a menu rather than typed in a command language Pointing Pointing devices such as a mouse to point at a selection from a menu or point at an icon & then click to issue the command
Cont
Graphics Graphical elements mixed with text in the same display User Interface design must take into consideration the capabilities of the user Prototyping may be helpful Short-term memory of humans is limited, do not overload with information Consistency in the Interface helps to reduce errors, comparable operations should be activated in the same manner
Cont
Use terms & concepts familiar to the user
Recoverability Confirmation of destructive actions, Undo facility

Help facilities Structured help facility at different levels, Context sensitive help User-System Interaction is two ways: Information from the user to be given to the Computer system Information from the Computer system to be presented to the user
Direct manipulation ( as in word processing, screen editors, form-based interfaces) Interface Models Desktop metaphor Screen is used as a Desktop System entities are represented as icons In addition the use of a control panel with buttons, switches, menus, indicators, displays, sliders
Cont
Menu Systems May type the name of the command Point with a mouse May use cursor moving keys On touch-sensitive screens use the finger or pen Do not need to remember commands
140
Typing effort is minimal User errors of a certain type can be avoided Most frequent operations at the top of a menu Most destructive operations at the bottom Command-line Interfaces Allow faster interaction Command language has to be learnt Command language programs can be written Cause more errors Interface cannot use pointing devices, interaction is through the keyboard only
Out put design

Characteristics of good output there are several characteristics that make information a candidate to be considered both highly quality and usable:
Accessibility This characteristic refers to how easy it is to use the information when a person gets it. Timeliness This characteristic refers to the amount of elapsed time it takes to obtain specific information that is needed
Cont
Relevancy this characteristic refers to whether the information as presented is free from trivial or superfluous details or lacking in sufficient details. Accuracy This characteristic addresses the issue of error-free information. Usability This characteristic refers primarily to the presentation style of the information, I.e. its format. E.g. text, numbers, graphics, graphs e.t.c
Cont
Output types
Internal, External, and Turnarounds Outputs Internal outputs are intended to be used by people or other information systems within a business. External outputs are intended to be used by people or other information systems outside the business. Turnaround outputs this type of output is generally external and people oriented and has the dual purpose of serving as output to the user and input to the information system from the user.
Cont
Static and Dynamic outputs Static outputs are those that can be predetermined and planned for. Dynamic Outputs are those that cannot be easily predetermined or planned for during information systems development. Output devices and media
Plotters are most often used to draw maps, architectural drawings, and blueprints, graphs, and pictures.
Cont
Computer output on Microfilm or microfiche are devices that, as their name implies, produce microfilm or microfiche output.
146
Interface Evaluation
Usability of the Interface Meets the user requirements Learn ability - How long it takes a new user to become productive with the system? Speed of Operation How well does the system response match the users work practice? Robustness How tolerant is the system of user error? Recoverability How good is the system at recovering from user errors? Adaptability How close is the system tied to a single model of work?
Cont
Methods of Evaluation
Questionnaires, Observation of users at work, Inclusion of SW in the code to collect information about most-used facilities and most common errors. Specific questions must be asked from users for evaluation (e.g. Error messages)
148
Files and Database Designs

Files for data storage Files are generally used to store sequences or lists of data in a format that has been optimized for some particular type(s) of transaction, and require routines specifically written for those formats and transactions. Generally these are organized sequentially, adding new data records to the end of the file. They are often arranged in a linked-list format for ease of manipulation.
File types by their area of application

Master files: are files used to record key business information which is maintained over a long period of time. Typical examples include order information, customer and account information, etc. Lookup files: are files containing static values, generally used for validation. Common examples are postal codes, province, state, and city names, etc.
Cont
Transaction files: are files which hold information used to update the master files. For instance, we might have a transaction file which records all the orders placed today and is used to periodically update the master file. Thus the "current" state of the system is maintained in memory, but in the event of a discrepancy or system failure we can check the master file against the day's transactions to determine where the failure occurred and how to correct it.
Cont
Audit files: audit files are used to record key information immediately before and after a transaction is applied. For instance, we could take a snapshot of an account immediately before applying a withdrawal transaction, and another immediately afterwards. Again, in the event of an error or system failure during the transaction the combination of master file, transaction file, and audit file allow us to pinpoint exactly what went wrong and how to correct it.
Cont
History files: many such systems collect vast amounts of data over time, and much of that data is rarely required. As such, it is common to create an archive of old data - data moved into a more compact and/or cheaper storage mechanism so that the overall system is more efficient but the data is still recoverable if necessary.
153
File Access and Organisation

File Access: refers to the method of reading or writing records within a file. File Organisation: refers to the method of storing records within a file. Two methods for accessing records in a file: sequentially and directly Four ways of storing data in files: serial, sequential,direct, and indexed.
Methods for accessing records in a file

Sequential access: is access by physical record location or position within a file (i.e. Starting at record one and sequentially reading or writing every record to the end of the file). Direct access: is access by physical address (i.e. ability to go directly to certain records within files without having to sequentially scan from the first record in the file).
Methods of File Organisation

Sequential file organisation: a method of storing data records in which the records must be retrieved in the same physical sequence in which they are stored (e.g. batch processing applications such as a payroll). Direct/ Random file organisation: a method of storing data records in a file so that they can be accessed in any sequence without regard to their actual physical order on the storage media.
Cont
Serial file organisation: is the storing of records in a file in chronological order (e.g. Recording of a banks ATM transactions as they occur). Indexed file organisation: uses and maintains a sorted index in key order, which stores the record location of the actual data file record as part of the index.
157
Cont
Databases for data storage Databases are used to store logical data groupings and their relationships, and require a database management system (DBMS) to maintain and access the data. Databases come in a vast range of sizes and complexity, from small scale systems such as Microsoft Access to full-fledged business or enterprise DBMSs such as Oracle.
158
General categories of database systems

Legacy databases: are databases using older, outdated technologies. They are frequently encountered in large organizations where the cost of replacing the database is prohibitive. Relational databases: are the most common/popular current form of database, primarily because they are much easier systems to perform development and maintenance on. These databases are composed of a set of tables, composed of a fixed number of rows (records) and columns (fields within each record). System Analysis and design by 159
Balirwa Moses 2010
Cont
Each table has a primary key (uniquely identifying each record in the table) and which may have one or more foreign keys. These foreign keys define the relationship to another table, and would be the primary key of the other table. Some of the most common RDBMSs include Access, Oracle, DB2, and Microsoft SQL Server.
Cont
Object databases: are databases which try to encapsulate logical data entities and their associated processes as separate objects. This makes it easier to alter portions of the database, since changes within one object do not impact other objects. Object-oriented data base management systems (OODBMSs) are primarily used in supporting multimedia applications, but they are also becoming more common in large scale electronic commerce systems.
Software Construction and Testing

General software design principles Construction strategies Testing principles Testing strategies The Generic software testing methodology
General software design principles

The software must conform to the requirements specification document created during the analysis portion of the project and any modifications added later during design with time the original specification requirement document becomes obsolete, hence changes may not be reflected. The software must be reliable over time while processing a potentially limitless combination and types of data, as well as user keystrokes and pointing device (mouse clicks).
Cont
The software must be maintainable and evolutionary over time upgradeable to accommodate changes. The software must be easy to use (user friendly). The software should be easy to test and implement using the test plans. The software should use computer resources efficiently minimize computer resources e.g. memory, processing power. The software should work correctly should avoid errors.
Software Construction Strategies

Top-Down software construction follows the functional decomposition approach to problem solving. It starts with the design overview or highlevel view (control or management oriented e.g. menus & calling modules) of the system and then creation of the program code for it. Next the details of the system are written for the program code, layer by layer, until the bottommost modules are programmed (operational or worker oriented e.g. modules which calculate results, update databases, print lines on a report).
Cont
Bottom-up software construction starts with writing the program code for the lowest-level details of the system and proceeds to higher levels by a progressive aggregation of details until they collectively fit the requirements for the system. Next is the construction of the code for the modules or modules that calls these bottommost modules.
166
Cont
Middle-out software construction starts somewhere in the middle of the system that seems convenient, and proceeds both upward to higher levels and downward to the lower levels as appropriate (e.g. coding a low-level module that opens a file, or calculates sales tax (bottommost modules)). The Hybrid combination of top-down, bottom-up, and middle-out software construction may be suitable for certain environments or projects.
Software Testing Principles

It should conform to at least three principles: First principle is that Software testing begins with plans for the tests and ends with the user accepting the tested software. Software test plans should be developed at the same time the requirements specification document is being developed and can be refined and updated during design as well. The plans for the user acceptance test should conform to the user requirements as documented in the requirements specification document.
Cont
By doing so, the development loop is completed, and the software is certified to be in compliance with the requirements specification document. User acceptance test plans include more than just the software; they include the other four IS components-hardware, procedures, people, and data. The second software testing principle is that testings intent is to cause and discover errors testing should be done with as little pride of ownership as possible.
Cont
The third software testing principle is that rules of reasonableness should prevail testing should follow commonly accepted testing techniques designed to provide a certain threshold of statistical confidence in the tests (e.g. rather than testing every record in a large database for a certain sequential processing situation, one commonly accepted testing technique is to test the first record, a few records in the middle of the database, and the last record I.e. test the huge actual database).
Software testing strategies

Top-down testing follows the functional decomposition approach to problem solving. It starts at an overview or high-level view of the system to be tested, then works its way down into details of the system, layer by layer until reaching the bottommost programmed modules. Bottom-up testing starts with details of the system and proceeds to higher levels by a progressive aggregation of details until they collectively fit the requirements for the system.
Cont
Middle-out testing starts somewhere in the middle of the system that seems convenient, and tests both upward to higher levels and downward to lower levels as appropriate. Hybrid is a combination of the three above. Regardless of which testing strategy is chosen, software testers view portions of the system, subsystem, programs and modules as either a white box or a black box as they test.
White box is the portion of the system that we are testing from an inside perspective. I.e. there is the ability to actually look at the code statements within the white box portion being tested and make changes to them should they not work correctly. Black box is the portion of the system that we are testing from an outside perspective. I.e. the tester doesnt have the ability to look at the code statements and change them. (Usually done when programmers need to integrate that part of the system with the part of the system they are creating and testing). Usually done on software wrote by someone else.
Cont
Alpha testing is testing done in-house by testers such as programmers, software engineers and internal users. I.e. a first cut at the acceptance tests is done in-house by in-house staff. Beta testing usually involves a select group of customers to perform tests on the software as they would use it in their normal environment. In exchange, the customers get an advance copy of the soon to be released software, which usually has new features in it.
A Generic Software Testing Methodology

Software Testing Methodology Showing Feedback/fallback loop
User Acceptance Testing System Testing Function Testing Integration Testing Unit Testing
175
A Generic Software Testing Methodology

The above generic testing methodology can be utilized regardless of whether the resulting software is to be used in house or is to be available for public sale at computer stores. Note the feedback or fall back arrows in the diagram. Whenever testing discovers errors at any level of the methodology, the programming staff will need to make coding changes followed by a trip back through the layers to ensure defect-free code in all test levels.
As testing takes place, keep in mind that code changes made by programmers in one module or section of a program may fix the identified bug but may cause an error in some other seemingly unrelated section of the program when it is tested again. Large systems are built of sub-systems which are built out of modules which are composed of procedures & functions. The testing process should be carried out in stages: Unit/ Module testing individual components are tested. I.e. Individual program modules are tested by their developers.
Cont
Integration Testing is the combining of several units or modules for the purpose of testing them as a whole. As software is being constructed and simultaneously being tested for integration with other software modules by the programmer, a technique known as stub testing is often used. Stub testing is a test performed on individual modules as they are being integrated in a topdown, bottom-up, or middle-out manner.
LEVEL 1
Testing sequence
LEVEL 1
LEVEL 2
LEVEL 2
LEVEL 2
LEVEL 2
Level 2 stubs
Level 3 stubs
TOP-DOWN TESTING
Function testing is the combining of one or more integration tested groups of modules that collectively perform a user identified function, as documented in the requirements specification document. System testing combines all of the user-defined functions together to form the subsystem or system. Acceptance testing is similar to system testing. However the user is the one who usually does the testing. These tests are most often conducted with well-defined test data, as well as the actual, real data.
The diagram below represents a framework for the methodology and how it interrelates with the other activities and deliverables of IS development.
Systems Analysis Systems Design Systems Design Program Design Module Design User Specification System Specification Software Specification Program Specification Module Specification Programming Acceptance Testing System Testing Function Testing Integration Testing Unit Testing
Framework for Information Systems Testing

System Development and Implementation Individual system components are built and tested User interfaces are developed and tried by users Database is initialized with data At the end of this phase : Users are provided with a working system (programs and database) System documentation describing the programs is also completed. All users are trained and can use the new system.
Systems Implementation; Evaluation & Review

Installation conversion strategies; Activate; Institutionalization Implementation Critical success factors Evaluation and review
183
Implementation - is the conversion of data to the new systems files, final training of the end users, and transition from the old system to the new system. Marks the end of development for now, and begins the users realization of the new or changed information system. Implementation is a critical time for users because the user must switch from the old to the new system, and the user must take responsibility for the successful utilization of the new system.
Cont
The IS development team must anticipate, even expect, problems during implementation. Hopefully, the problems can be turned into opportunities. Implementing a system consists of 3 phases : Install, Activate, Institutionalization. Install Is putting the new IS in place. I.e. physically install all of the five components: h/w, s/w, people, procedures, data, of an IS. People are trained or prepared as part of the install phase.
Install Phase
A very significant part of the install phase has to do with conversion. Conversion is the switching from one thing to another. I.e. a new IS is replacing an obsolete manual or automated IS. NB. Conversion affects each of the components of an IS. There are three Conversion strategies of :-
186
Old System
Parallel Operation
New System Old System
Direct Conversion Phased Conversion Old System
New System
New System
Conversion with a pilot Version
Old System
New System
187
Conversion
Cutover/Abrupt/Direct Conversion is one in which the user uses the old system up to a specific point in time after which the user starts using the new system. Advantages No duplication of effort for users. No transition costs with the old system. Learning advantage for groups converted later, if Cutover is done by groups. The costs of running parallel systems.
Cont
Disadvantages of Cutover Conversion High risk I.e. It may disrupt operations if it fails. Cannot compare results. Sense of user insecurity I.e. no period of adjustment could lead to resistance to change.
189
Cont
Parallel Conversion is one that allows the user to continue use the old system and the new system simultaneously for a period of time, eventually discarding the old system. Advantages Low risk I.e. it guarantees continuing incase the new system fails. Sense of user security Ability to compare results with old system.
Cont
Disadvantages of Parallel Conversion Duplication of effort for users Transition costs I.e. Expensive Additional processing strain on the computer.
191
Cont
Pilot Conversion is one in which the new system is implemented in one part of the organization such as a single department, and eventually extended to other departments. Advantages Incase of failure, the rest of the organization is not affected.
192
Cont
Based on feed-back, changes are made and the system is installed in the rest of the organization by one of the other methods. It provides experience and live tests for implementation. Gives an opportunity to the implementers to display the advantages of the new system.
193
Cont
Disadvantages of Pilot
May give the impression that the new system is un-reliable and not error-free, depending on the effectiveness of the implementers. May give the impression that the old system is un-reliable and not error-free because staff may loose confidence in the old system.
194
Cont
What do Software Engineers base their conversion strategy decision on?
The design of the information system. User needs and preferences. Risk factors. (Give your understanding of what we mean by each of the above.)
Activate Phase
The second phase of Implementation, the Activate phase, deals with getting the user to use the new or changed IS. Once the IS has been installed and the conversion performed, the implementation moves naturally into the activate phase as the predetermined users begin exercising and using the new system.
196
Cont
During this critical phase the development team may continue training the users on an as-needed basis. The team should also anticipate and expect problems and be prepared to correct them. The team should also monitor the users usage of the IS, taking note of what the users like and dislike, patterns of user usage, shortcut opportunities to improve the IS effectiveness, e.t.c.
Cont
In short, the development team needs to pay serious attention to the IS and its use by the users during this phase and be prepared to maintain, fix, and enhance it as the need and opportunity to do so become available. Maintenance and Review changes in h/w, s/w, documentation or procedures to a production system to correct errors, meet new requirements, or improve processing efficiency.
Cont
Evaluation this is to determine whether the IS operates as expected, and if the costs and benefits are as anticipated. I.e. identify the strengths and weaknesses of the IS. Why Maintenance is important?
Necessary to eliminate errors in the system during its working life (corrective maintenance) Enhancing & modifying the system to respond to changing user environment & organizational needs, improving system efficiency, & enhancing documentation (perfective maintenance)
Cont
Changing the application to adapt it to a new H/W or S/W environment (adaptive maintenance) Information system planners must always plan for resource availability to carry out these maintenance functions. Institutionalization phase means that the new or changed IS becomes the new status quo within the business.
Cont
Status quo doesn't guarantee 100% use by the users, but it does imply that the new IS is now the standard for the business and that a certain percent of user critical mass has adopted and is using the new IS. What are some of the reasons that lead to resistance of a new Information System by the users? Discuss in class.
Implementation Critical Success Factors

From an Organizational change perspective, successful IS implementation depends on the following critical success factors: User Commitment the user must be the champion or advocate for the new IS. I.e. the user should take ownership and responsibility for the new system. Organizational trust management and staff within the business, both IS types and user types, must have a high degree of trust in one another.
Open communication between IS management and staff and user management and staff communication problems and breakdowns can cause significant harm to an IS development project and the IS implementation. Financial commitment from user management lack of or limited funding for the new system can cause significant problems during the development process and during the system's implementation. Common view of the IS development and implementation strategy between management and staff.
Project Management
The project management causes of failed projects The basic functions of the project manager Project management tools and techniques
What is Project Management

The purpose of this module is to introduce you to project management. Why? Project Management is applied during Systems Analysis, Systems Design and Systems Implementation. Information Systems development is almost always done under the auspices of a project.
Definition of Project Management

Definition: Information Systems Project Management is a process of directing the development of an acceptable Information Systems at a minimum cost within a specified time frame. NB: The acceptability, deadline and budget criteria must all be for a project to be considered completely successful. The role of Project Management is to recognize such factors to eliminate or minimize their negative effects.
Sources of Systems Development Projects

Systems Development Projects come from one of three sources: A directive or mandate from some person, such as a president, vice president, or senior Manager, or an organization such as a labor Union or Uganda Revenue Authority. An opportunity to exploit. The opportunity usually results in increased revenues and/ or profits reduced costs, or increased or improved services. A problem to solve. Something usually isnt working correctly and needs fixing.
Systems Development Failures

Use of undisciplined development methodologies or approaches. Inadequate or not understood or appreciated Systems Development tools. Project Scope was not clearly defined in the beginning. Use of no or poor estimating techniques. Schedule delays.
Cont
Beliefs in the mythical person- month syndrome. E.g. a Manager with this mindset thinks that if two developers can do or finish up a project in six weeks, then simply adding a third developer to the project will allow it to be completed in 4 weeks. The reality is much different than this.
209
What constitutes a Systems Development project failure

The organization completely abandons the project at some point prior to its implementation. The organization must rework a significant amount of the project, so much so that they deem it a failure but do go ahead and initiate the network. The delivered Information Systems is okay, but the project was way over time and budget, therefore, it is defined a failure. The delivered Information Systems doesnt meet the user requirement or expectations, therefore; it is deemed a failure.
Functions of the Project Manager

Planning Project tasks and staffing the project team a good manager always has a plan. The manager estimates resource requirements and formulates a plan to deliver the target system. Each task required to complete the project must be planned. Some of the planning issues include: How much time will be required? How many people will be needed? How much will the task cost? What tasks must be completed before other tasks are started? Can some of the tasks overlap?
Organizing and scheduling the project effort

members of the project team should understand their own individual roles and responsibilities as well as their reporting relationship to the project manager. The project schedule should be developed with an understanding of task time requirements, personnel assignments, and interties dependencies.
Directing and controlling the project once the

project has begun the project manager becomes the project leader. As a leader the project manager directs the teams activities and evaluates progress. The manager must frequently report progress to superiors. The managers job is to monitor tasks, schedules, and costs in order to control those elements.
Project Management Tools and Techniques

PERT Network and Gantt chart There are 2 commonly used Project Management tools: Programmed Evaluation and Review Techniques (PERT) charts which are most useful for project planning and modification. Gantt charts which are for project scheduling and progress reporting.
Cont of Tools
A PERT network is A graphical representation of project tasks laid out in the form of a critical path network A Gantt chart shows Project tasks and their deviations in a bar chart format in the planning and estimating of a project prior to its inception.
214
Steps to Create a PERT Chart Determine the duration time for each task Assign a task identification letter to each task Draw the PERT network, number each node. Label each task with its task identification letter. Connect each node from start to finish And put each tasks duration on the network Determine the need for any dummy tasks Determine the earliest completion time for each task node Verify the PERT network for correctness.
PERT Chart
PERT Network Strengths Determine task dependencies PERT network is continuously useful to project managers prior to and during a project. PERT network is straightforward in its concept and is supported by soft war. PERT network can be a valuable tool for project managers, but the tool is only as good as the data that are input to it. Its strengths include:
Cont
The PERT networks graphical representation of the projects critical path and task slack time allows the project manager to focus more attention on the critical aspects of the project-time, costs, and people. The project management software that creates the PERT network usually provides excellent project tracking documentation. The use of the PERT network is applicable in a wide variety of projects.
Weaknesses of the PERT network: In order for the PERT network to be useful, project tasks have to be clearly defined as well as their relationships to each other. The PERT network does not deal very well with task overlap. PERT assumes that following tasks after their preceding tasks end. The PERT network is only good as the time estimates that are entered by the project manager. By design, the project manager will normally focus more attention on the critical path tasks than other tasks, which could be problematic for nearcritical path tasks if overlooked.
The Gantt chart

The Gantt chart is based on a two-dimensional graph scale. Each of the significant project tasks is listed along the vertical axis of the graph, and the estimated elapsed calendar time to complete the entire project is listed along the horizontal axis. An appropriate calendar time interval, such as days, weeks, or months is selected for the horizontal axis.
The Gantt chart is at its best for visually showing each of the projects task status at any moment in time simply by drawing a vertical bar from top to bottom on the chart at the calendar time you are interested in. Once drawn, a visual inspection of the shading within each of the bars on the chart gives you an indication of project task status for each task. It is also useful for showing any overlapping or parallel tasks. It does not clearly show task dependence, even though it does show task start and stop times, and you can clearly see that tasks start after others have already begun or are already finished.
Gantt chart strengths & weaknesses Gantt Chart Strengths Being able to see overlapping or parallel tasks. Being able to see the status of each project System Analysis and design by task at any point Balirwa Moses 2010 in time.
221
Dfgasdfawdw tyhtrftgsw
222
Characteristics of good information
Accurate Concise Complete Understandable Relevant Authoritative Timely Ease of use


Systems Analysis and Desgin Notes

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Systems Analysis and Desgin Notes

Uploaded by

Copyright:

Available Formats

Systems Analysis and Design

Instructor: Balirwa Moses Email: dbalirwa@yahoo.com

System Analysis and design by Balirwa Moses 2010

System Analysis and design by Balirwa Moses 2010

keeping records of transactions, Airline reservations etc.

Computers are now becoming part of virtually every activity in an organization.

What Information Systems Can Do

Largest commercial port

300 million tons of cargo per year

Processing time reduced from 2-4 days to 15 minutes

System Analysis and design by Balirwa Moses 2010

What an organization needs to do in order to computerize.

System Analysis and design by Balirwa Moses 2010

System Analysis and design by Balirwa Moses 2010

Components of an Automated Information System

An Automated Information System

System Analysis and design by Balirwa Moses 2010

Characteristics of an Information System

Systems Development Process (Overview)

What does a Systems Analyst Do?

System Analysis and design by Balirwa Moses 2010

Stakeholders of an Information System Users Steering Committee

System Analysis and design by Balirwa Moses 2010

General model of Systems Analysis, Design & Implementation

Information System (6)

Continued Involvement (5)

Problem Definition Skills (2)

Information Technology staff

Where do Systems Projects Originate?

Systems Development Life Cycle

Principles to guide Systems Development

Feasibility Analysis and Requirements Determination

System Analysis and design by Balirwa Moses 2010

System Analysis and design by Balirwa Moses 2010

Frameworks for understanding and doing Requirements Determination

Methods Used to gather an IS Requirements

Asking the users

Deriving from an Existing System

Deriving from the Analysis of the Business Area

Experimenting with the system under development

Data analysis Document analysis Observation Participation

Business Systems Planning Critical success Factors Decision analysis

Throwaway prototyping Evolutionary prototyping

System Analysis and design by Balirwa Moses 2010

Information Gathering Techniques

System Analysis and design by Balirwa Moses 2010

System Analysis and design by Balirwa Moses 2010

System Analysis and design by Balirwa Moses 2010

People usually feel uncomfortable when being watched.

Deriving the requirements from the analysis of the business area

Define Business Processes

Define Business Data

Analyze Current System support

Define findings & conclusions

Determine Architecture priorities

Review information resource management

Obtain CSF of Manager A

Obtain CSF of Manager C

Combine individual CSFs

Define the information needed for the decision process

Used to discover user requirements

Identify basic User requirements

Rapidly develop prototype