NAME: - TANVEER ALAM P.H.

SHAIKH

CLASS:- MBA 1ST YEAR

SUBJECT: - MIS

SUBMITTED TO: - PRITI AGERWAL MADAM

 Q1:- MIS & BUSINESS FUNCTIONAL SUB SYSTEM:-

Subsystem Owner & Business Analyst Decisions

While the Business Analyst and Subsystem Owner are two roles with distinct responsibilities, they
may be satisfied by one person. The analysis aspect is likely to involve others, e.g., a business office or
project team. The Subsystem Owner is a simpler role, in the sense that it has a clearer set of supporting
activities.

Business Analyst - Defining Privilege Data

Signet is designed to express privileges being managed in a natural language, expressing what a person can
do, e.g., "Admit Students", "Purchase equipment", etc. It separates this aspect from the internal mechanics
of enabling those functions, from the system specific language of systems that support the activities whose
privileges are being managed.

The Analyst is responsible for the definition of privileges - which options the users see, how privileges are
expressed, and the granularity required to provide sufficient granularity of control vs. unnecessary system
complexity. They must thoroughly understand the business requirements of the privileges being managed.

In addition, they must be able to provide Signet with the translation of end-user functions to the internal
"permissions" that are to be interpreted by consuming systems.

    Required reading - Signet Concepts, Glossary, & Features

Design Considerations
...Coming soon: Documentation to further develop good design in: style considerations for naming, when to
choose multiple function vs. one function with many limits, etc.

    Please contact us for more information if you are in need of assistance before this section is expanded.

Business Analyst - Subsystem Implementation

Once a set of privileges has been defined, it is expressed within Signet as a Subsystem. This information
needs to be recorded via structured information in an XML document.

A complete Sample XML document offers a useful example that may be adapted to your local data. As
Business Analyst, you will either provide the data itself, or you may consult the Subsystem Owner (if other
than yourself.) Also, refer to Phase VII: Populating with Sample Data of the System Administration
Installation & Deployment guide.

    Contact your Signet System Administrator for information on how to submit Subsystem definitions that
are to be added to Signet.

Subsystem Owner - Seeding Privileges

A chain of privilege authorizations must begin somewhere. In Signet, it begins with the Subsystem Owner. A
Subsystem Owner has the ability to "act as Signet" in the UI, switching from one's own authority to super-
delegation powers for a Subsystem. As a Subsystem Owner, when acting as Signet, you can grant any
privilege to any person with any limits.
You yourself do not actually HAVE these privileges, but as Subsystem Owner you can do all initial delegation
of powers to the real individuals who should have those powers. This could be just one person or several,
but it becomes their responsibility to grant privileges to others at their level or below, to start the chain of
distributed delegation within a project or across the enterprise.

    For more in depth coverage, please read the Roles and Internal Privileges document.

Subsystem Owner - Other Responsibilities

A Subsystem Owner retains powers over the Privileges being managed in a Subsystem. They can, again
acting as Signet, be an actor of last resort in creating privileges, or revoking them - even if granted by others.
In all such actions, Signet will record that the action was done under Signet's own authority to manage this
information, and that the Subsystem Owner was the authorized user exercising those powers.

Finally, a Subsystem Owner has the ability to grant equal powers to others to make them a Subsystem
Owner. This is desirable both for coverage, and also continuity of Subsystem ownership over time, as jobs
and roles change. Should a Subsystem be left with no active Subsystem Owner, one would then contact the
Signet System Administrator, who can designate a new Subsystem Owner.

    Note: Refer to the Supporting Your Campus document for additional reading.  

Q2:- REASONS FOR SUCCESS & FAILURE IN

ORGANIZATION IN MIS:-

MIS - The factors of Success and Failure

Many organizations use MIS successfully, others do not. Though the hardware and the software is the
latest and has appropriate technology, its use is more for the collection and storage of data and its
elementary processing. There are some factors which make the MIS a success and some others, which
make it a failure. These factors can be summarized as follows:
Factors Contributing to Success:-
If a MIS is to be success then it should have all the features listed as follows:
         The MIS is integrated into the managerial functions. It sets clear objectives to ensure that the
MIS focuses on the major issues of the business.
         An appropriate information processing technology required to meet the data processing and
analysis needs of the users of the MIS is selected.
         The MIS is oriented, defined and designed in terms of the user’s requirements and its operational
viability is ensured.
         The MIS is kept under continuous surveillance, so that its open system design is modified
according to the changing information needs.
         MIS focuses on the results and goals, and highlights the factors and reasons for non
achievement.
         MIS is not allowed to end up into an information generation mill avoiding the noise in the
information and the communication system.
         The MIS recognizes that a manager is a human being and therefore, the systems must consider
all the human behavioral factors in the process of the management.
         The MIS recognizes that the different information needs for different objectives must be met
with. The globalization of information in isolation from the different objectives leads to too much
information and information and its non-use.
         The MIS is easy to operate and, therefore, the design of the MIS has such features which make
up a user-friendly design.
         MIS recognizes that the information needs become obsolete and new needs emerge. The MIS
design, therefore, has a basic potential capability to quickly meet new needs of information.
         The MIS concentrates on developing the information support to manager critical success factors.
It concentrates on the mission critical applications serving the needs of the top management.
Factors Contributing to Failures:-
Many a times MIS is a failures. The common factors which are responsible for this are listed as
follows:
         The MIS is conceived as a data processing and not as an information processing system.
         The MIS does not provide that information which is needed by the managers but it tends to
provide the information generally the function calls for. The MIS then becomes an impersonal
system.
         Underestimating the complexity in the business systems and not recognizing it in the MIS
design leads to problems in the successful implementation.
         Adequate attention is not given to the quality control aspects of the inputs, the process and
the outputs leading to insufficient checks and controls in the MIS.
         The MIS is developed without streamlining the transaction processing systems in the
organization.
         Lack of training and appreciation that the users of the information and the generators of the
data are different, and they have to play an important responsible role in the MIS.
         The MIS does not meet certain critical and key factors of its users such as a response to the
query on the database, an inability to get the processing done in a particular manner, lack of
user-friendly system and the dependence on the system personnel.
         A belief that the computerized MIS can solve all the management problems of planning and
control of the business.
         Lack of administrative discipline in following the standardized systems and procedures,
wrong coding and deviating from the system specifications result in incomplete and incorrect
information.
         The MIS does not give perfect information to all the users in the organization.

Q3) System Development Life Cycle ?

Initial Idea

All projects must start with an initial idea. Usually this consists of a brief definition on what is
the project all about, what is its purpose and what the project aims to accomplish. How will the
success of the project be measured?

Feasibility Study

Expanding on the Initial Idea, the Feasibility Study involves drawing up the terms of reference,
which state the objectives and scope of the project, how long it should take and how the results
should be presented. The terms of reference are usually drawn up by senior management. The
feasibility study must determine if development of the project is justified in terms of economic
and organisational terms.

The main role of the analyst in the feasibility study is to analyse the current system at a high
level. Data Flow Diagrams (DFD) are used to describe how the current system performs and to
illustrate known problems.
Feasibility studies are not carried out for all projects, and smaller projects omit this stage.

Requirements Analysis

The Requirements Analysis stage defines a series of possible solutions to the problem and
presents them to management in terms of business options. These options may be supported by
technical documents such as high-level DFD's, Logical Data Models (LDM) and Work Practise
Models. The requirements analysis report must also contain financial and risk assessments to be
presented and supported by outline implementation descriptions.

The steps involved within the requirements analysis will define the flow of data in the system,
deriving system functions and to develop user role specifications, prototypes and process
specifications.

Systems Analysis and Specification

The Systems Analysis stage is an extension to the feasibility study. If the project has a feasibility
study then the bulk of the work has already been done. A terms of reference will also be required
if one does not exist. The output from this stage is the System Specification which gives precise
details of what the new system is required to do, but does not go into how it does it. It provides a
logical model of the new system.

Once agreed, the specification is the basis for the work done by the system designers.

Systems Design

This stage deals with how the requirements of the new system are carried out (how the logical
model is implemented as a physical system). The system designer will develop a number of
design options and test them against the requirements specification and design criteria. The one
that comes closest to the design brief with the most cost effective use of equipment and
personnel is selected and broken down into more detailed specs.

Because of this the design stage has two phases: produce outline designs based on requirements
specification with input from users and the detailed designs produced from the selected design.

Development

This is the only stage in the development where program code is written. The designs and
specifications provide enough detail for the programmer to code and test individual modules.
Each unit is tested to ensure that it meets the requirements of the specification.

Testing

Within the life cycle there are various levels of testing as well as the unit testing performed in
the development stage.
Link testing ensures that programs work together, e.g. the data passed from one program to
another has the correct format.

System testing ensures that the system as a whole performs according to the design
specification. Recovery procedures must be tested as well as normal operation procedures.

Finally user acceptance testing is carried out by the users in stages to ensure that the system is
usable.

Any modifications are passed back to the design stage where changes are made as necessary and
passed to the development team.

Implementation

When the testing has been carried out to the users satisfaction the system, or parts of it, are put
live. The "put live" phase can also be known as implementation, cutover or production. This is
when the users start using the system to carry out their business activities.

There are two main approaches to implementation a project:

 Phased: Stand-alone subsets of the system are implemented over a period of time.
 Big Bang: The whole system is put live in one go.

Some systems will require special programs or tasks to convert existing data to a format usable
by the new system. The process of changing data from the old system to the new is called
conversion.

Maintenance and Review

Once the system is put into place, maintenance is required to ensure satisfactory operation.

Maintenance should include regular reviews and evaluations to ensure that it is achieving its
objectives, identify any aspects that can be improved or any operational problems. Maintenance
falls into two categories, implementation of new features or elimination of errors.
  Q4 DESIGN & IMPLEMENTATION OF MIS:-

1 Information System Design & Implementation Issues

• What is MIS?
• What are MIS Design considerations
• Concepts of S/W Engineering
• Structured Methodologies of analysis & Design
• System Implementation Issues
• End User Perspective

2 Computerised MIS : Its components

• Instructions( Procedures)
(that when executed provide desired function and performance)
• Data Structures:
(that enables the programs to adequately manipulate information)
• Documents:
(that describe the operations and use of the programs)

3Overview Software Development Options

 In house Development by Computer Professionals
In house Developments by End Users By contracting to Outside Agencies
Market Survey and Purchase of Readymade Packages
Modifications in Readymade Package / already operational package

4Software Engineering
• Definition
Establishment and use of sound engineering principles in
order to obtain a quality software that is economical,
reliable, workable and acceptable.
S/W Engineering is an outgrowth of hardware & software. It has three key elements
• Methods (Technical how of building a S/W)
• Automated or semi automated support tools like
DBMS
packages and Present day Visual Tools for applications
development etc.
Procedures
(to hold the method & tools together )
10
5 User requirements Understanding of Analyst Understanding of developer
Understanding problem
11
6
1 Recognition of need
2 Feasibility Study
3 Analyses
4 Designs
5 Development Testing
6 Implementation
7 Live Running
8 Reviews

7 Feasibility Study

It comprises of initial investigations of the problem set for the

S/W project. It provides one or conceptual solutions. Each
Conceptual Solution consists of an idea about how the new system
Will look like.
• What will be done on computer and what will be done manually?
• What inputs will be needed?
• What outputs will be produced?
• Cost Benefit Analysis?
13
8 The Feasibility study is governed by constraints like
• Physical Resources
• External systems (External Environment)
• Overlapping Sub Systems (Internal Environment)
• Organizational Goals & Pollicies
For the Selected alternative, terms and conditions are set
and the project are defined in clear terms.
16
17
9 Structured System Analysis
Key Questions to be asked are:
What existing system is doing?
What are the constraints/ problems?
What are the new requirements?
What is the best way of tackling problems /new requirements by reviewing various alternatives?
- What are Security / Backup requirements?
18
10 Strategy of structured Techniques:
• Graphical
A picture is worth a thousand words
• Separation of Logical (What) and Physical (How)
Views:
• Top Down Approach:
Getting the big pictures first
• Partitioning:
It is not practical to write a single specification for a large system
19
11 Structured Analysis Tools
 Data Flow Diagram:
It It is a graphical modeling of flow of data within a system and the processing performed on that
data
Data Source Process Destination
Data Store
Data Flow Data Flow
20
12
Identify key functions, Data flows ( Inputs /Outputs) , Processes, Data stores, sources of
inputs’ and destinations of Outputs etc.
Draw Context Diagram
Draw Level 1 Data Flow Diagram
Structured Systems Analysis Steps
21
13 Technique of Existing System Study
There is a saying that
“DON’T FIX IT UNTIL YOU UNDERSTAND IT”
So, Find out exactly:
• Who does what?
• In what manner?
• Why that way?
• Where it is done?
• At what time?
• In what order?
• At what Cost?
.
14 Technique of existing system study
With the help of:
• Interviews
• Questionnaires
• Observations
• Record Inspection
• Sampling
23
25
15 Data Dictionary
Description of process
›› Names of Processes as shown in DFDs
›› Brief Description (Structured English)
›› Processing Logic (Decision tables/Trees)
›› Inputs from the Process
›› Outputs from the Process
›› Access Controls Requirements
›› Audit & Security Requirements

16 Data Dictionary
Data
Storage files/ Internal Entities
›› Detailed Data Structures
›› Volumetric Information
›› Physical Organization
›› Access Control Requirements
›› Security & Audit Requirements
27
17Data Dictionary
Input
/ Output Specifications
›› Source
›› Destination
›› List of data items along with format and Length
›› Transaction Volume
28
18 System Design
System design is equivalent to preparing blue prints of
A building to be constructed giving all details required
For the construction activity.
Design specifications consist of :
Tables
Input Forms
Output Reports
Query Designs
User Interfaces and their linkages
Flow chart of procedures etc.
29
19
What is an object?
Object is something, having certain characteristics, which can be described in real world
environment
EEg: - An Item, A Role, A Report, A Form, An Association, An Organization etc.
Any real world activity / system can be divided into inter-linked objects
30
20 More about Object
Each Each object has attributes (properties) , associated methods ( behavior) and operations,
which change the values of attributes, when certain events are triggered As object is instance of a
class. A form, A button, List box, Module etc.
31
21
Model
Module 1
Module 2 Object1 Object2
Object1
Link
Function
Module1
Procedure
32
22 System Design
Present day tools help in building prototype of the new system, which can be reviewed
by thby the end user at this stage itself. Object Oriented Technology enables further development
of programming procedures etc. from the prototype itself. Note: Forms, tables etc. are the
objects, to whom properties ( attributes) and methods /Operations can be associated
33
23 Characteristics of a Good Design
• Reliability
• Flexibility
• Cost Effectiveness
• Practicality
• Security
• Effectiveness
• Control
• Accuracy
• Documentation
• Acceptability
34
24 Types of Files
• Master
• Transaction
• Temporary
• Security
• Audit
• Reference
• Backup
35
25 Files Design Considerations
• File size
• Normalization
• File updation frequency
• Media
• Acceptable Response (Batch / Online)
• Hit rate
36
26 Input Design
Input design is the process of converting user
Originated inputs to a computer based format.
• Goal of input design is to make data entry easy
Logical and Error free
• Menu approach to data entry should be adopted
• Input screen design should be automated
• Maximum data validation checks should be
Provided at
Data entry level itself.
37
27 Output Design
Output is the most visible component of computer
Based Management Information System
Objective of an MIS design is to provide right
Information to right persons in right time. Thus
Output design needs very careful consideration
Information produced must be in a format
acceptable to the user.
39
28 Factors affecting output design
• Who need it?
• In what form?
• At what time?
• Where is its disposal?
• At what cost?
40
29Types of Reports
• Detailed Reports
• Summary Reports
• History Reports
• Job control Reports
• Audit Reports
41
30 System Implementation
It is fulfill or carrying out of the design specification
To put a new information system in operation.
Systems Analyst along with the end user is fully
Involved in this stage of system development life
cycle.
For successful implementation of the system the
following implementation strategy should be adopted.

42

31 System Implementation
• Operating staff involvement
• Incremental change
• Socio-technical approach
43
32 Stages of system Implementation
• Planning
• Installation of Equipment
• System testing with realistic data
• Training
• Files Conversion
• Changeover Strategy
• System Strategy
• System Review Plans
44
33 Who need Training
• All staff of operating Department
• Any other affected staff who either provide
Data or receive reports
• All levels of Managers
• Computer room staff
45
34 Training methods
• Lectures
• Discussion
• Meeting
• On the job training
• Training manuals
46
35 How much Training & When toTrain
• Too much?
• Too less?
• Too early?
• Too late?
47
36Change over Considerations
• Files Transfer
• New Input Forms
• New Work Procedures
• New Data Collection Methods
• New Reporting Formats
• New Backup Procedures
• New Recovery Procedures
48