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
System Analysis and design by Balirwa Moses 2010 4
Introduction
Earlier applications that used computers were business applications, such as
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
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
System Analysis and design by Balirwa Moses 2010 8
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
System Analysis and design by Balirwa Moses 2010 9
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
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.
System Analysis and design by Balirwa Moses 2010 12
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 Analysis and design by Balirwa Moses 2010 13
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
Data
People
Software
Procedures Hardware
16
Basic Characteristics of an IS
Data Functions
Behaviour
Data: input, stored, or output Function: business activity performed Behaviour: the observable effects of a request
System Analysis and design by Balirwa Moses 2010 18
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.
System Analysis and design by Balirwa Moses 2010 20
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.
System Analysis and design by Balirwa Moses 2010 22
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
System Analysis and design by Balirwa Moses 2010 23
Managers
Systems Analyst
Database Administrators Programmers & Technical Staff
System Analysis and design by Balirwa Moses 2010 24
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.
System Analysis and design by Balirwa Moses 2010 25
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
System Analysis and design by Balirwa Moses 2010 26
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.
System Analysis and design by Balirwa Moses 2010 27
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.
System Analysis and design by Balirwa Moses 2010 28
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
Stakeholder
Requirements (1)
Analysis
30
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.
System Analysis and design by Balirwa Moses 2010 32
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.
System Analysis and design by Balirwa Moses 2010 34
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)
System Analysis and design by Balirwa Moses 2010 38
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).
System Analysis and design by Balirwa Moses 2010 39
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
System Analysis and design by Balirwa Moses 2010 40
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?
System Analysis and design by Balirwa Moses 2010 41
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?
System Analysis and design by Balirwa Moses 2010 42
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.
System Analysis and design by Balirwa Moses 2010 43
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.
System Analysis and design by Balirwa Moses 2010 44
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.
System Analysis and design by Balirwa Moses 2010 46
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.
System Analysis and design by Balirwa Moses 2010 47
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.
System Analysis and design by Balirwa Moses 2010 48
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.
System Analysis and design by Balirwa Moses 2010 49
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.
System Analysis and design by Balirwa Moses 2010 50
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.
System Analysis and design by Balirwa Moses 2010 51
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.
System Analysis and design by Balirwa Moses 2010 54
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.
System Analysis and design by Balirwa Moses 2010 55
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.
System Analysis and design by Balirwa Moses 2010 56
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.
System Analysis and design by Balirwa Moses 2010 58
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.
System Analysis and design by Balirwa Moses 2010 59
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.
System Analysis and design by Balirwa Moses 2010 60
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.
System Analysis and design by Balirwa Moses 2010 61
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.
System Analysis and design by Balirwa Moses 2010 63
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
System Analysis and design by Balirwa Moses 2010 64
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.
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.
System Analysis and design by Balirwa Moses 2010 67
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
System Analysis and design by Balirwa Moses 2010 68
3.
Define IS Architecture
Interview Executives
Develop recommendations
System Analysis and design by Balirwa Moses 2010
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
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
Cont
4. Prototyping
A method used to test or illustrate an idea and build a system in an explorative way.
Evolutionary Development
complete document the final version, field it as the operational system
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.
System Analysis and design by Balirwa Moses 2010 74
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.
System Analysis and design by Balirwa Moses 2010 75
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.
System Analysis and design by Balirwa Moses 2010 76
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.
System Analysis and design by Balirwa Moses 2010 79
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.
System Analysis and design by Balirwa Moses 2010 81
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.
System Analysis and design by Balirwa Moses 2010 82
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.
System Analysis and design by Balirwa Moses 2010 83
URD Diagram
URD
Analysis
NFR
FR RA SOR
DO
D
System Analysis and design by Balirwa Moses 2010 84
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
< 5000/=
85
<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
Condition Statement
Action Statement
88
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.
System Analysis and design by Balirwa Moses 2010 92
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.
System Analysis and design by Balirwa Moses 2010 94
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).
System Analysis and design by Balirwa Moses 2010 95
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.
System Analysis and design by Balirwa Moses 2010 96
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.
System Analysis and design by Balirwa Moses 2010 97
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.
System Analysis and design by Balirwa Moses 2010 98
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
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.
System Analysis and design by Balirwa Moses 2010 103
GENERATE BILL
CUSTOMER FILE GENERATE REPORT CUSTOMER PAYMENT FILE
MANAGER
104
Order
Invoice
Customer
Warehouse
Picking-labels
Order-rejectionnotice
Out-of-stocknotice
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
Purchasing Dept
Stores
System Analysis and design by Balirwa Moses 2010 108
Customer
Customer No.
Name Address Balance due
Places
Many
Order
Many
Contains
Many
Product
Product No.
Product Name Price
109
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?
System Analysis and design by Balirwa Moses 2010 111
Systems Design
Architectural design process Output design, input design, User interface design, file & database design, program specification design Prototyping
System Analysis and design by Balirwa Moses 2010 112
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.
System Analysis and design by Balirwa Moses 2010 113
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.
System Analysis and design by Balirwa Moses 2010 114
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.
System Analysis and design by Balirwa Moses 2010 115
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
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.
System Analysis and design by Balirwa Moses 2010 118
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
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
System Analysis and design by Balirwa Moses 2010 121
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.
System Analysis and design by Balirwa Moses 2010 123
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
System Analysis and design by Balirwa Moses 2010 125
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
System Analysis and design by Balirwa Moses 2010 127
128
Sales
Transaction
READ-SALESTRANSACTION
OUTPUTTOTAL
A B C
System Analysis and design by Balirwa Moses 2010
Hierarchical Design
129
PROCESS A
Program Flowchart
SEQUENCE
PROCESS B
TRUE
PROCESS E
PROCESS D
PROCESS C S
TRUE
SELECTION
ITERATION
System Analysis and design by Balirwa Moses 2010 130
System Flowchart
HUMAN RESOURCES DATA TIME CARDS PAYROLL MASTER
PAYROLL SYSTEM
VALID TRANSACTIONS PAYROLL MASTER
COMPARE &
UPDATE
DIRECT DEPOSITS
GENERAL LEDGER
131
PUNCHED CARD
MANUAL OPERATION
ON-LINE STORAGE
ON-LINE DISPLAY
TELECOMMUNICATIONS LINK
System Analysis and design by Balirwa Moses 2010 132
DECISION CONNECTOR
System Analysis and design by Balirwa Moses 2010 133
Cont
After the logical design stage, the processing steps to be carried out by individual modules are specified in physical design. Prototyping 4GLs, AG
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
System Analysis and design by Balirwa Moses 2010 136
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
System Analysis and design by Balirwa Moses 2010 137
Cont
Use terms & concepts familiar 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
System Analysis and design by Balirwa Moses 2010 139
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
System Analysis and design by Balirwa Moses 2010 141
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
System Analysis and design by Balirwa Moses 2010 143
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.
System Analysis and design by Balirwa Moses 2010 144
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.
System Analysis and design by Balirwa Moses 2010 145
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?
System Analysis and design by Balirwa Moses 2010 147
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
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.
System Analysis and design by Balirwa Moses 2010 151
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.
System Analysis and design by Balirwa Moses 2010 152
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
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
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.
System Analysis and design by Balirwa Moses 2010 160
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.
System Analysis and design by Balirwa Moses 2010 161
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.
System Analysis and design by Balirwa Moses 2010 164
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.
System Analysis and design by Balirwa Moses 2010 167
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.
System Analysis and design by Balirwa Moses 2010 169
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).
System Analysis and design by Balirwa Moses 2010 170
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.
System Analysis and design by Balirwa Moses 2010 172
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.
System Analysis and design by Balirwa Moses 2010 173
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.
System Analysis and design by Balirwa Moses 2010 174
175
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.
System Analysis and design by Balirwa Moses 2010 177
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.
System Analysis and design by Balirwa Moses 2010 178
LEVEL 1
Testing sequence
LEVEL 1
LEVEL 2
LEVEL 2
LEVEL 2
LEVEL 2
Level 2 stubs
Level 3 stubs
TOP-DOWN TESTING
System Analysis and design by Balirwa Moses 2010 179
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.
System Analysis and design by Balirwa Moses 2010 180
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
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.
System Analysis and design by Balirwa Moses 2010 182
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.
System Analysis and design by Balirwa Moses 2010 184
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.
System Analysis and design by Balirwa Moses 2010 185
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
New System
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.
System Analysis and design by Balirwa Moses 2010 188
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.
System Analysis and design by Balirwa Moses 2010 190
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.)
System Analysis and design by Balirwa Moses 2010 195
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.
System Analysis and design by Balirwa Moses 2010 197
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.
System Analysis and design by Balirwa Moses 2010 198
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)
System Analysis and design by Balirwa Moses 2010 199
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.
System Analysis and design by Balirwa Moses 2010 200
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.
System Analysis and design by Balirwa Moses 2010 201
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.
System Analysis and design by Balirwa Moses 2010 203
Project Management
The project management causes of failed projects The basic functions of the project manager Project management tools and techniques
System Analysis and design by Balirwa Moses 2010 204
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
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.
System Analysis and design by Balirwa Moses 2010 215
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:
System Analysis and design by Balirwa Moses 2010 216
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.
System Analysis and design by Balirwa Moses 2010 217
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.
System Analysis and design by Balirwa Moses 2010 218
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.
System Analysis and design by Balirwa Moses 2010 220
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