Skip to main content

System Analysis Lecture notes

Systems Analysis
Systems analysis includes a review of the present information system to assess its capabilities and shortcomings; specification of system goals, objectives, and constraints; a survey of potential system users to assess their information needs; identification and analysis of alternative system concepts; specification a system concept; and system requirements analysis and specification.This phase includes an analysis of major system functions and the development of a system
architecture (identification of the major system components and their interrelationships). Heavy emphasis is placed on end-user requirements. It is essential to involve the end-user in the system requirements activity, to insure the development of a system that is fully responsive the user's needs. The review of the current system and survey of potential users can be done by a
variety of means, including review of documentation, site visits, questionnaire surveys, interviews, and focus-group discussions.
Systems Design
The systems design phase is generally broken into two subphases, top-level design and detailed
design. Top-level design consists of the identification of the major system components and their
functions. In order to specify the top-level design, a number of alternative system design concepts
are synthesized and evaluated in terms of a variety of selection criteria, which include cost
(implementation, operation and maintenance), performance, satisfaction of requirements,
development risk, flexibility for expansion/upgrading, and political acceptability. The important
aspect of top-level design is to present several feasible solutions to the system managers and
users, to describe their advantages and disadvantages, and to obtain a consensus on a preferred
design concept. An example of a design decision is the decision concerning which functions
should be implemented using computers and which should be manual (e.g., should data collected
at a regional level and needed at a central level be transmitted via the Internet (e.g., virtual private
network or e-mail) or hand-carried on a memory stick).
Systems Implementation
Systems implementation consists of developing all of the system components -- data collection
forms; data collection, transfer and processing procedures; data entry procedures and screens
(including on-line edit checking); software; report forms; report distribution; quality control
procedures. As mentioned, we recommend the use of an iterative, rapid-prototyping approach to
the software implementation. It is highly recommended to field-test major systems in a single
geographic area before going full scale. This field testing involves not only software, but all
aspects of the system (e.g., data collection procedures, training, quality control).
Detailed design consists of specifying all of the system components and functions in detail. In the
detailed design phase, decisions are made concerning what data elements are to be collected,
how they are to be coded, how frequently they are to be collected, and at what levels of detail they
are to be aggregated. A critical design decision concerns the "units of analysis" -- the item on
which the data are to be measured, such as an individual, a household, a school, a clinic, a farm, a
village, or a region. The decision on the unit of analysis has a significant impact on both the cost
of the system operation (especially the data collection burden) and on the flexibility of ad-hoc
reporting. This design decision is particularly important. While it is an easy matter to revise a data
entry screen or report format, it is not possible to produce a desired report about a particular type
of unit if data on that unit are not included in the data base. For example, if it is desired to produce
3
a report about the frequency distribution of villages by some characteristic, village-level data must
be included in the data base (or capable of being constructed by aggregation of lower-level units).
If it is desired to produce a frequency distribution of facilities by size, facility data must be included.
If it is desired to produce distributions of families with particular characteristics, data on families
must be included in the data base.

Comments

Popular posts from this blog

Advantages and Disadvantages of EIS Advantages of EIS Easy for upper-level executives to use, extensive computer experience is not required in operations Provides timely delivery of company summary information Information that is provided is better understood Filters data for management Improves to tracking information Offers efficiency to decision makers Disadvantages of EIS System dependent Limited functionality, by design Information overload for some managers Benefits hard to quantify High implementation costs System may become slow, large, and hard to manage Need good internal processes for data management May lead to less reliable and less secure data

Inter-Organizational Value Chain

The value chain of   a company is part of over all value chain. The over all competitive advantage of an organization is not just dependent on the quality and efficiency of the company and quality of products but also upon the that of its suppliers and wholesalers and retailers it may use. The analysis of overall supply chain is called the value system. Different parts of the value chain 1.  Supplier     2.  Firm       3.   Channel 4 .   Buyer

Big-M Method and Two-Phase Method

Big-M Method The Big-M method of handling instances with artificial  variables is the “commonsense approach”. Essentially, the notion is to make the artificial variables, through their coefficients in the objective function, so costly or unprofitable that any feasible solution to the real problem would be preferred, unless the original instance possessed no feasible solutions at all. But this means that we need to assign, in the objective function, coefficients to the artificial variables that are either very small (maximization problem) or very large (minimization problem); whatever this value,let us call it Big M . In fact, this notion is an old trick in optimization in general; we  simply associate a penalty value with variables that we do not want to be part of an ultimate solution(unless such an outcome is unavoidable). Indeed, the penalty is so costly that unless any of the  respective variables' inclusion is warranted algorithmically, such variables will never be p