MIS (MOD 6)

SYSTEM DEVELOPMENT CYCLE FOR MIS-

Like any other product development, system development requires careful analysis and design
before implementation. System development generally has the following phases:

Planning and Requirement Analysis
The project planning part involves the following steps:
Reviewing various project requests, Prioritizing the project requests, Allocating the resources,
Identifying the project development team, Various techniques used in information system
planning are:, Critical Success Factor, Business System Planning, End/Mean Analysis
The requirement analysis part involves understanding the goals, processes and the constraints
of the system for which the information system is being designed.
It is basically an iterative process involving systematic investigation of the processes and
requirements. The analyst creates a blue print of the entire system in minute details, using
various diagramming techniques like:
Data flow diagrams, Context diagrams, Requirement analysis has the following sub-processes:,
Conducting preliminary investigation, Performing detailed analysis activities, Studying current
system, Determining user requirements, Recommending a solution
Defining Requirements
The requirement analysis stage generally completes by creation of a 'Feasibility Report'. This
report contains:
A preamble, a goal statement. A brief description of the present system, proposed alternatives
in details, The feasibility report and the proposed alternatives help in preparing the costs and
benefits study. Based on the costs and benefits, and considering all problems that may be
encountered due to human, organizational or technological bottlenecks, the best alternative is
chosen by the end-users of the system.
Designing System architecture
System design specifies how the system will accomplish this objective. System design consists
of both logical design and physical design activity, which produce 'system
specification' satisfying system requirements developed in the system analysis stage.
In this stage the following documents are prepared: Detailed specification Hardware/software
plan
Building or Developing the System
The most creative and challenging phase of the system life cycle is system design, which refers
to the technical specifications that will be applied in implementing the candidate system. It also
includes the construction of programmers and program testing.
It has the following stages: Acquiring hardware and software, if necessary Database design
Developing system processes Coding and testing each module
The final report prior to implementation phase includes procedural flowcharts, record layout,
report layout and plan for implementing the candidate system. Information on personnel,
money, hardware, facility and their estimated cost must also be available. At this point
projected cost must be close to actual cost of implementation.
Testing the System
System testing requires a test plan that consists of several key activities and steps for programs,
strings, system, and user acceptance testing. The system performance criteria deals with
turnaround time, backup, file protection and the human factors.
Testing process focuses on both: The internal logic of the system/software, ensuring that all
statements have been tested; the external functions, by conducting tests to find errors and
ensuring that the defined input will actually produce the required results.
In some cases a 'parallel run' of the new system is performed, where both the current and the
proposed system are run in parallel for a specified time period and the current system is used
to validate the proposed system.
Deployment of the System
At this stage, system is put into production to be used by the end users. Sometime, we put
system into a Beta stage where users feedback is received and based one feedback system is
corrected or improved before a final release or official release of the system.
System Evaluation & Maintenance
Maintenance is necessary to eliminate the errors in the working system during its working life
and to tune the system to any variation in its working environment. Often small system
deficiencies are found, as system is brought into operation and changes are made to remove
them. System planner must always plan for resources availability to carry on these maintenance
functions.
SYSTEM ANALYSIS:SYSTEM DESIGN(DFD AND ER DIAGRAM)
ER-D- A popular graphical notational paradigm for representing conceptual models
Has three core constructs
An entity: depicted as a rectangle, represents a collection of real-world objects
that have common properties and behaviours
A relationship: depicted as an edge between two entities, with diamond in the
middle of the edge specifying the type of relationship
An attribute: an annotation on an entity that describes data or properties
associated with the entity

ER diagrams are popular because::they provide an overview of the problem to be addressed the
view is relatively stable when changes are made to the problem's requirements ER diagram is
likely to be used to model a problem early in the requirements
DFD- ER diagram, event trace, state machines depict only lower-level behaviours
A data-flow diagram (DFD) models functionality and the flow of data from one function to
another
A bubble represents a process An arrow represents data flow A data store: a
formal repository or database of information
Rectangles represent actors: entities that provide input data or receive the
output result

Components
A large box: system boundary Stick figures outside the box: actors, both human
and systems
Each oval inside the box: a use case that represents some major required
functionality and its variant
A line between an actor and use case: the actor participates in the use case
Use cases do not model all the tasks, instead they are used to specify user views of
essential system behavior
Advantage:
Provides an intuitive model of a proposed system's high-level functionality and
of the data dependencies among various processes
Disadvantage:
Can be aggravatingly ambiguous to a software developer who is less familiar
with the problem being modelled.