You are on page 1of 9

Development of MIS: Introduction The plan for the development and its implementation is a basic necessity for MIS

. In MIS the information is recognized as a major resource li e capital, time and capacity. If this resource is to be managed well, it calls upon the management t o plan for it and control it for the appropriate use in the organization. Computers are used mainly for computing and accounting the business transaction and have not been considered as a tool for information processing. However the scene has been changing since late eighties when the computers becam e more versatile, in the function of storage, communications, intelligence and l anguage. The computers have become user friendly. They can communicate to any distance and share data, information and physical resources of other computers. Computers can now be used as a tool for information processing and communication . It can be used for storing large database . In short, we need a management information system flexible enough to deal with t he changing information needs of the organization. MIS plan provide direction for the development of the systems , and provide a ba sis for achieving the specific targets or tas s against a time frame. MIs plan is lin ed to business plan MIS goals and objectives:- it is necessary to develop the goals and objectives f or the MIS which will support the business goals. MIs goals and objectives will consider management philosophy, policy constraint s, business ris s internal and external environment of the organization and the business. The example of the goals are Provide an online information on the stoc s, mar ets and the accounts balances. The query processing should not exceed more than three seconds Strategy for the plan achievement:The designer has to ta e a number of strategic decisions for the achievement of the MIS goals and objectives . a) Development strategy: an online ,a batch , a real time. b) System development strategy:- operational versus functional, accounting vs analysis ,database vs conventional, distributed versus decentralized processi ng, one database vs multiple database, SSAD vs OOT. c) Resource for system development:d) Manpower composition: analyst, programmer s ills. The architecture of the MIS:The architecture of the MIS plan provide a system and subsystem structure and th eir input , output and lin age The system development schedule :-A schedule is made for the development of the system. H/W and S/W plan :- according to technical and operational feasibility made a p lan for necessary H/W and S/W. Structured development method: Structured analysis and design method (SSADM) (originally released as methodolog y) is a systems approach to the analysis and design of information systems. SADM[system analysis and design method] techniques: The three most important techniques that are used in SADM are: Logical data modeling This is the process of identifying, modeling and documenting the data requiremen ts of the system being designed. The data are separated into entities (things ab out which a business needs to record information) and relationships (the associa tions between the entities). Data Flow Modeling

This is the process of identifying, modeling and documenting how data moves arou nd an information system. Data Flow Modeling examines processes (activities that transform data from one form to another), data stores (the holding areas for da ta), external entities (what sends data into a system or receives data from a sy stem), and data flows (routes by which data can flow). Entity Behavior Modeling This is the process of identifying, modeling and documenting the events that aff ect each entity and the sequence in which these events occur. Stage 0 Feasibility study In order to determine whether or not a given project is feasible, there must be some form of investigation into the goals and implications of the project. For v ery small scale projects this may not be necessary at all as the scope of the pr oject is easily understood. In larger projects, the feasibility may be done but in an informal sense, either because there is not time for a formal study or bec ause the project is a must-have and will have to be done one way or the other. When a feasibility study is carried out, there are four main areas of considerat ion: Technical is the project technically possible? Financial can the business afford to carry out the project? Organizational will the new system be compatible with existing practices? Ethical is the impact of the new system socially acceptable? To answer these questions, the feasibility study is effectively a condensed vers ion of a fully blown systems analysis and design. The requirements and users are analyzed to some extent, some business options are drawn up and even some detai ls of the technical implementation. The product of this stage is a formal feasibility study document. SADM specifies the sections that the study should contain including any preliminary models tha t have been constructed and also details of rejected options and the reasons for their rejection. Stage 1 Investigation of the current environment This is one of the most important stages of SADM. The developers of SADM underst ood that though the tas s and objectives of a new system may be radically differ ent from the old system, the underlying data will probably change very little. B y coming to a full understanding of the data requirements at an early stage, the remaining analysis and design stages can be built up on a firm foundation. In almost all cases there is some form of current system even if it is entirely composed of people and paper. Through a combination of interviewing employees, c irculating questionnaires, observations and existing documentation, the analyst comes to full understanding of the system as it is at the start of the project. This serves many purposes: the analyst learns the terminology of the business, what users do and how they d o it the old system provides the core requirements for the new system faults, errors and areas of inefficiency are highlighted and their correction ad ded to the requirements the data model can be constructed the users become involved and learn the techniques and models of the analyst the boundaries of the system can be defined The products of this stage are: Users Catalog describing all the users of the system and how they interact with it Requirements Catalogs detailing all the requirements of the new system Current Services Description further composed of Current environment logical data structure (ERD) Context diagram (DFD) Leveled set of DFDs for current logical system Full data dictionary including relationship between data stores and entities To produce the models, the analyst wor s through the construction of the models as we have described. However, the first set of data-flow diagrams (DFDs) are th e current physical model, that is, with full details of how the old system is im

plemented. The final version is the current logical model which is essentially t he same as the current physical but with all reference to implementation removed together with any redundancies such as repetition of process or data. In the process of preparing the models, the analyst will discover the informatio n that ma es up the users and requirements catalogs. Stage 2 Business system options Having investigated the current system, the analyst must decide on the overall d esign of the new system. To do this, he or she, using the outputs of the previou s stage, develops a set of business system options. These are different ways in which the new system could be produced varying from doing nothing to throwing ou t the old system entirely and building an entirely new one. The analyst may hold a brainstorming session so that as many and various ideas as possible are gener ated. The ideas are then collected to form a set of two or three different options whi ch are presented to the user. The options consider the following: the degree of automation the boundary between the system and the users the distribution of the system, for example, is it centralized to one office or spread out across several? cost/benefit impact of the new system Where necessary, the option will be documented with a logical data structure and a level 1 data-flow diagram. The users and analyst together choose a single business option. This may be one of the ones already defined or may be a synthesis of different aspects of the ex isting options. The output of this stage is the single selected business option together with all the outputs of stage 1. Stage 3 Requirements specification This is probably the most complex stage in SADM. Using the requirements develope d in stage 1 and wor ing within the framewor of the selected business option, t he analyst must develop a full logical specification of what the new system must do. The specification must be free from error, ambiguity and inconsistency. By logical, we mean that the specification does not say how the system will be impl emented but rather describes what the system will do. To produce the logical specification, the analyst builds the required logical mo dels for both the data-flow diagrams (DFDs) and the entity relationship diagrams (ERDs). These are used to produce function definitions of every function which the users will require of the system, entity life-histories (ELHs) and effect co rrespondence diagrams, these are models of how each event interacts with the sys tem, a complement to entity life-histories. These are continually matched agains t the requirements and where necessary, the requirements are added to and comple ted. Stage 4 Technical system options This stage is the first towards a physical implementation of the new system. Li e the Business System Options, in this stage a large number of options for the i mplementation of the new system are generated. This is honed down to two or thre e to present to the user from which the final option is chosen or synthesized. However, the considerations are quite different being: the hardware architectures the software to use the cost of the implementation the staffing required the physical limitations such as a space occupied by the system the distribution including any networ s which that may require the overall format of the human computer interface All of these aspects must also conform to any constraints imposed by the busines s such as available money and standardization of hardware and software. The output of this stage is a chosen technical system option. Stage 5 Logical design Though the previous level specifies details of the implementation, the outputs o

f this stage are implementation-independent and concentrate on the requirements for the human computer interface. The logical design specifies the main methods of interaction in terms of menu structures and command structures. One area of activity is the definition of the user dialogues. These are the main interfaces with which the users will interact with the system. Other activities are concerned with analyzing both the effects of events in updating the system and the need to ma e inquiries about the data on the system. Both of these use t he events, function descriptions and effect correspondence diagrams produced in stage 3 to determine precisely how to update and read data in a consistent and s ecure way. Stage 6 Physical design This is the final stage where all the logical specifications of the system are c onverted to descriptions of the system in terms of real hardware and software. T his is a very technical stage and a simple overview is presented here. The logical data structure is converted into a physical architecture in terms of database structures. The exact structure of the functions and how they are impl emented is specified. The physical data structure is optimized where necessary t o meet size and performance requirements. The product is a complete Physical Design which could tell software engineers ho w to build the system in specific details of hardware and software and to the ap propriate standards. Prototype Model: The Prototyping Model is a systems development method (SDM) in which a prototype (an early approximation of a final system or product) is built, tested, and the n rewor ed as necessary until an acceptable prototype is finally achieved from w hich the complete system or product can now be developed. This model wor s best in scenarios where not all of the project requirements are nown in detail ahead of time. It is an iterative, trial-and-error process that ta es place between t he developers and the users. There are several steps in the Prototyping Model: 1. The new system requirements are defined in as much detail 1. as possible. This usually involves interviewing a number of users repres enting all the departments or aspects of the existing system. 2. A preliminary design is created for the new system. 3. A first prototype of the new system is constructed from the preliminary design. This is usually a scaled-down system, and represents an approximation of the characteristics of the final product. 4. The users thoroughly evaluate the first prototype, noting its strengths and wea nesses, what needs to be added, and what should to be removed. The devel oper collects and analyzes the remar s from the users. 5. The first prototype is modified, based on the comments supplied by the u sers, and a second prototype of the new system is constructed. 6. The second prototype is evaluated in the same manner as was the first pr ototype. 7. The preceding steps are iterated as many times as necessary, until the u sers are satisfied that the prototype represents the final product desired. 8. The final system is constructed, based on the final prototype. 9. The final system is thoroughly evaluated and tested. Routine maintenance is carried out on a continuing basis to prevent large-scale failures and to min imize downtime Software Development: Software development (also nown as application development, software design, de signing software, software application development, enterprise application devel opment, or platform development) is the development of a software product. The t erm "software development" may be used to refer to the activity of computer prog ramming, which is the process of writing and maintaining the source code, but in a broader sense of the term it includes all that is involved between the concep

tion of the desired software through to the final manifestation of the software, ideally in a planned and structured process. Therefore, software development ma y include research, new development, prototyping, modification, reuse, re-engine ering, maintenance, or any other activities that result in software products. There are several different approaches to software development, much li e the va rious views of political parties toward governing a country. Some ta e a more st ructured, engineering-based approach to developing business solutions, whereas o thers may ta e a more incremental approach, where software evolves as it is deve loped piece-by-piece. Most methodologies share some combination of the following stages of software development: Mar et research Gathering requirements for the proposed business solution Analyzing the problem Devising a plan or design for the software-based solution Implementation (coding) of the software Testing the software Deployment Maintenance and bug fixing These stages are often referred to collectively as the software development life cycle, or SDLC. The General Model Software life cycle models describe phases of the software cycle and the order in which those phases are executed. There are tons of models, and many companies adopt their own, but all have very similar patterns. The general, basic model is shown below: General Life Cycle Model Each phase produces deliverables required by the next phase in the life cycle. Requirements are translated into design. Code is produced during implementation that is driven by the design. Testing verifies the deliverable of the implementation phase against requirements. Requirements Business requirements are gathered in this phase. This phase is the main focus of the project managers and sta e holders. Meetings with managers, sta e holders and users are held in order to determine the requirements. Who is going to use the system? How will they use the system? What data should be input into the system? What data should be output by the system? These are general questions that get answered during a requirements gathering phase. This produces a nice big list of functionality that the system should provide, which describes functions the system should perform, business logic that processes data, what data is stored and used by the system, and how the user interface should wor . The overall result is the system as a whole and how it performs, not how it is actually going to do it. Design The software system design is produced from the results of the requirements phase. Architects have the ball in their court during this phase and this is the phase in which their focus lies. This is where the details on how the system will wor is produced. Architecture, including hardware and software, communication, software design (UML is produced here) are all part of the deliverables of a design phase. Implementation Code is produced from the deliverables of the design phase during implementation, and this is the longest phase of the software development life cycle. For a developer, this is the main focus of the life cycle because this is where the code is produced. Implementation my overlap with both the design and testing

phases. Many tools exists (CASE tools) to actually automate the production of code using information gathered and produced during the design phase. Testing During testing, the implementation is tested against the requirements to ma e sure that the product is actually solving the needs addressed and gathered during the requirements phase. Unit tests and system/acceptance tests are done during this phase. Unit tests act on a specific component of the system, while system tests act on the system as a whole. So in a nutshell, that is a very basic overview of the general software development life cycle model. Now lets delve into some of the traditional and widely used variations. Waterfall Model This is the most common and classic of life cycle models, also referred to as a linear-sequential life cycle model. It is very simple to understand and use. In a waterfall model, each phase must be completed in its entirety before the next phase can begin. At the end of each phase, a review ta es place to determine if the project is on the right path and whether or not to continue or discard the project. Unli e what I mentioned in the general model, phases do not overlap in a waterfall model. Advantages Simple and easy to use. Easy to manage due to the rigidity of the model each phase has specific delivera bles and a review process. Phases are processed and completed one at a time. Wor s well for smaller projects where requirements are very well understood. Disadvantages Adjusting scope during the life cycle can ill a project No wor ing software is produced until late during the life cycle. High amounts of ris and uncertainty. Poor model for complex and object-oriented projects. Poor model for long and ongoing projects. Poor model where requirements are at a moderate to high ris of changing. Waterfall Model:

Incremental Model The incremental model is an intuitive approach to the waterfall model. Multiple development cycles ta e place here, ma ing the life cycle a multi-waterfall cycle. Cycles are divided up into smaller, more easily managed iterations. Each iteration passes through the requirements, design, implementation and testing phases. A wor ing version of software is produced during the first iteration, so you have wor ing software early on during the software life cycle. Subsequent iterations build on the initial software produced during the first iteration. Advantages Generates wor ing software quic ly and early during the software life cycle. More flexible less costly to change scope and requirements. Easier to test and debug during a smaller iteration. Easier to manage ris because ris y pieces are identified and handled during its

iteration. Each iteration is an easily managed milestone. Disadvantages Each phase of an iteration is rigid and do not overlap each other. Problems may arise pertaining to system architecture because not all requirements are gathered up front for the entire software life cycle. Spiral Model The spiral model is similar to the incremental model, with more emphases placed on ris analysis. The spiral model has four phases: Planning, Ris Analysis, Engineering and Evaluation. A software project repeatedly passes through these phases in iterations (called Spirals in this model). The baseline spiral, starting in the planning phase, requirements are gathered and ris is assessed. Each subsequent spirals builds on the baseline spiral. Requirements are gathered during the planning phase. In the ris analysis phase, a process is underta en to identify ris and alternate solutions. A prototype is produced at the end of the ris analysis phase. Software is produced in the engineering phase, along with testing at the end of the phase. The evaluation phase allows the customer to evaluate the output of the project to date before the project continues to the next spiral. In the spiral model, the angular component represents progress, and the radius o f the spiral represents cost. Spiral Life Cycle Model Advantages High amount of ris analysis Good for large and mission-critical projects. Software is produced early in the software life cycle. Disadvantages Can be a costly model to use. Ris analysis requires highly specific expertise. Projects success is highly dependent on the ris analysis phase. Doesnt wor well for smaller projects. Unit -4 Computers in management: CBIS consists of following applications 1) Management Information Systems. 2) Decision Support Systems. 3) The Virtual Office. 4) Knowledge Based Systems. The fundamental wor of CBIS is to manage Information in an efficient way such t hat it can Be utilized by the managers effectively to solve Problems. Information is the method of efficiently manage the Resources. There are basica lly five types of resources that need to be managed by the managers. 1. Personnel 2. Material 3. Machines (includes energy and facilities) 4. Money 5. Information (includes data) The first four resources are tangible i.e. they exist physically, they are also nown as physical resources. The fifth resource type is not tangible hence calle d as conceptual resource. Managers use conceptual resources to manage physical resources. A system is a group of elements that are integrated with a common purpose of ach ieving a common objective. An organization contains resources, they wor hard to wards achieving particular objectives that are specified by the management. System Elements. The basic elements of a system is as follows

1) 2) 3) 4) 5)

Input element. Transformation element. Output element. Control mechanism. Objectives.

Evolution of Computer Based Information Systems The Initial Focus on Data During the first half of twentieth century, when punch cards were used, firms ge nerally ignored the information needs of managers. The first computers were only used for accounting applications. The name given to these early computer based applications was Electronic Data Processing (EDP). Now a days the term Accountin g Information System (AIS) is used to describe those applications. The New Focus on Information In 1964, a new generation of computing equipment was introduced that influenced strongly on the manner in which computers were employed. They were the computers using the silicon technology. The concept of using computers as Management Info rmation System was promoted. The MIS initiated that the computers should be appl ied for the management of information. This concept was adopted slowly by larger firms. The revised focus on Decision Support A Decision Support System (DSS) is an information-producing system aimed at a pa rticular problem that a manager must solve and the decisions the manager must ta e. The manager can be located any where, at any level in the organization. Thes e DSS were used widely in the organizations. The Current Focus on Communication During the time DSS evolved, interest was focused on another computer applicatio n called Office Automation (OA) which facilitates communication and increases pr oductivity among the managers and office wor ers through the use of electronic d evices. OA got started in 1964, when IBM announced its Magnetic tape and electro nic typewriter (called Selectric typewriter). The selectric typewriter could typ e the information stored in the magnetic tapes. This lead to an OA application c alled word processing. The Office Automation grew to such levels that applicatio ns such as video conferencing, e-mail, des top publishing etc started. In a coll ective term it was given the name Virtual Office. Potential Focus on Consultation The development of computers had made it possible to perform tas s of logical re asoning just li e humans. The application called Artificial Intelligence (AI) we re developed. Now a days a subclass of AI nown as Expert Systems are growing wh ich wor s as a specialist in a particular area. To solve the problems using AI t he applications were given the name Knowledge-based Systems. From 1990s the use of nowledge-based systems were extensively used by large firms. The firms using computers realized that there was a need to form separate organ izational units of specialists who would be responsible for implementing the sys tems. These specialists were nown as Information Specialists. Information Specialists Information specialists have the complete responsibility of developing and ma naging the computer based systems in the firm.There are five main categories of information specialists. 1) System Analyst. 2) Database Administrators. 3) Networ Specialists. 4) Programmers. 5) Operators. Database Administrators (DBA s) They wor with users and system analysts to create the appropriate databases tha t would help in effectively solving the problem. Once the database is created, the DBAs frequently monitor and manage these resou

rces. Networ Specialists They wor with systems analysts and users to establish the data communication ne twor s that would connect users with the required systems that are widespread. They combine the expertise from the fields of computing and telecommunications. Another form of Networ specialists are called Web Masters who are expert on the World Wide Web. Programmers They use the documentation prepared by the System analysts to encode the instruc tions. They require to be very conversant with the software they are wor ing on. Operators They are responsible for handling the computing equipments. They are expected to be able to handle mainframes to mini computers. They monitor the consoles, manage memory libraries etc

You might also like