Term paper system analysis and design of IS
TERM PAPER OF
SYSTEM ANALYSIS & DESIGN OFINFORMATION SYSTEM
(CAP302)
TOPIC-what different system development strategies can be
applied in the development of information system in LPU.
SUBMITTED TO: SUBMITTED BY:MRS.AVNEET KAUR KULDEEP KAUR ROLLNO-08 CLASS-BCA-MCA (D3702)
1
Term paper system analysis and design of IS
ACKNOWLEDGEMENT
With due honor, I want to thank all the personalities who make me able to
do this interesting work. First of all I would like to thank LOVELY
PROFESSIONAL UNIVERSITY for giving me opportunity to carry out
this term paper at their esteemed institution.
I am grateful to my honorable faculty who provided all the facilities.
I acknowledge the earlier suggestions given to me by Mrs. Avneet kaur
madam.
KULDEEP KAUR
ABSTRACT
2
Term paper system analysis and design of IS
A system development methodology refers to the framework that is used to structure, plan,
and control the process of developing an information system. A wide variety of such
frameworks have evolved over the years, each with its own recognized strengths and
weaknesses. One system development methodology is not necessarily suitable for use by all
projects. Each of the available methodologies is best suited to specific kinds of projects,
based on various technical, organizational, project and team considerations. CMS has
considered each of the major prescribed methodologies in context with CMS’ business,
applications, organization, and technical environments. As a result, CMS requires the use of
any of the following linear and iterative methodologies for CMS systems development, as
appropriate. In this term paper we have defined ISD, and described methods and tools.
First, for the purposes of met modeling, methods were seen to consist of different types
of method knowledge. This analysis focused on method knowledge related to modeling
techniques, i.e. on the conceptual structure and notations. Thus, we excluded other
aspects of methods and their development. Second, we have described the relationship
between modeling tools and methods: the method-tool companionship. This allowed us to
show what type of computer support is needed to develop tool support.
INTRODUCTION
In this term paper we have discussed System development strategies can be applied in the
development of information system in LPU. The analysis of method use revealed that the
applicability of existing methods is not all clear, because many ISD organizations do not
use the available standard-like methods at all, and have developed their own partially or
completely new methods. As a result, the IS research community must admit that we do
not know well enough how methods are actually used in development situations, and how
important the role of methods is in the success of ISD efforts. These paradoxes led us to
refine the currently dominating view of methods: we defined methods to be situation-
bound instead of universal and standard. We acknowledged that a method is not the sum
total of ISD knowledge, as much knowledge about ISD is tacit and can not be provided as
readily applicable routines. We emphasized expertise and learning, and viewed methods
as evolutionary.
3
Term paper system analysis and design of IS
Based on the IS research literature, there appear to be at least three possible ways to
research method use. The first is to continue the widely followed research approach to
develop new situation-independent and universal methods, compare them conceptually,
and use them in cases. However, this approach, despite its use in multiple studies, has
proven to be inadequate for resolving problems related to the wider acceptance of
methods. The second option is to pursue comprehensive empirical studies on methods in
realistic environments. Although this proposition is basically correct, it is not a realistic
approach for today’s organizations. First, they can not stop their ISD efforts and wait for
the results. Second, the results of these empirical studies can become obsolete even
before they are ready, because of the rapid evolution of the business world and
technology. For example, there is not much empirical evidence on the usefulness of
object-oriented methods, although this is one of the challenges for ISD in many
organizations today. Similarly, there is a paucity of research examining the usefulness of
Meta CASE tools.
The third option is method engineering: to focus on mechanisms that support local
method development and use. Although many companies are “rolling their own”, using
local, in-house methods, method development seems to be carried out in an ad-hoc
manner by selecting tools and methods on a trial-and-error base. Organizations do not
have any principles to guide ME efforts: selecting and constructing methods for particular
needs, checking the completeness of methods, or organizing method development efforts.
Moreover, organizations face problems in finding and developing tool support and
collecting experience of method use. All these reasons motivate the development of
systematic principles for ME. In the following chapter, we shall describe approaches or
strategies for method selection, construction, and tool adaptation
4
Term paper system analysis and design of IS
INFORMATION SYSTEM
An information system represents all the elements involved in the management,
processing, transport and distribution of information within the organization. A company
creates value by processing information, particularly in the case of service companies.
So, information has a much greater value because it contributes to achieving the
company's objectives. In practical terms the scope of the term Information System can
differ greatly from one organization to another and depending on the example may cover
all or some of the following elements:
Company databases,
Integrated management software (ERP),
Client relationship management tool (Customer Relationship Management),
Supply chain management tool (SCM - Supply Chain Management),
Application jobs,
Network infrastructure,
Data servers and storage systems,
Application servers,
Security devices.
Categories of Information System Characteristics
1. Transaction Processing System Substitutes computer-based processing for
manual procedures.
Deals with well-structured processes.
Includes record keeping applications.
2. Management information system Provides input to be used in the managerial
decision process. Deals with supporting
well structured decision situations. Typical
information requirements can be
5
Term paper system analysis and design of IS
anticipated.
3. Decision support system Provides information to managers who
must make judgments about particular
situations. Supports decision-makers in
situations that are not well structured.
INFORMATION SYSTEM COMPONENTS
Hardware
Software
o System software
o Application software
o Enterprise applications
o Horizontal system
Data
6
Term paper system analysis and design of IS
o Tables
o Linking
Processes
o Define the tasks and business functions that users, managers, and IT staff
members perform to achieve specific results
People
o Users, or end users, are the people who interact with an information
system, both inside and outside the company
How Business Uses Information Systems
o In past, IT managers divided systems into categories based on the user
group the system served
Office systems
Operational systems
Decision support systems
Executive information systems
o Today, it makes more sense to identify a system by its functions,
rather than by users
Enterprise computing systems
Transaction processing systems
Business support systems
Knowledge management systems
User productivity systems
o Enterprise computing systems
Support company-wide operations and data management
requirements
o Transaction processing systems
7
Term paper system analysis and design of IS
Efficient because they process a set of transaction-related
commands as a group rather than individually
o Business support systems
Provide job-related information to users at all levels of a company
Management information systems (MIS)
Radio frequency identification (RFID)
What-if
o Knowledge management systems
Called expert systems
Simulate human reasoning by combining a knowledge base and
inference rules
Many use fuzzy logic
o User productivity systems
Technology that improves productivity
Groupware
o Information systems integration
8
Term paper system analysis and design of IS
Most large companies require systems that combine transaction
processing, business support, knowledge management, and user
productivity features
Information Systems Development Stages
Define
In the Define stage you identify the requirements for the system. These must
acknowledge the needs of the business, the development strategy and the chosen
technology strategy and infrastructure. The deliverables of these activities are often
referred to as metadata.
Build
The Build stage is the one where you produce the system that matches the requirements.
This may include creating a new system or modifying an existing one. Commonly,
deliverables are things like run time objects, whether formally or informally specified
documentation, and tables with data.
9
Term paper system analysis and design of IS
Test
The objective of the Test stage is to verify that your system works correctly and matches
the requirements identified during the Define stage. A common deliverable of the Test
stage is a system signed off by the customer. Clearly, the Define, Build, and Test stages
can be performed either sequentially or in parallel, but are most often performed
iteratively
System development strategies can be applied in the development of
information system in LPU
System Development Process
System development process has different forms and models, it follows certain steps.
Some of them follow the standard steps in a model however; there are those that
prefer to create their own type of model. But whatever their model is, they should go
through these stages as these determine the outcome of the any SDLC model. These
steps could have the same name in one methodology but they are treated in a different
manner or could lead to something different.
Following are the system development process importance in an organization
Defects are detected rather late in the development process. High rework and
testing effort, typically under time pressure, lead to unpredictable delivery dates
and uncertain product quality. This paper presents several methods for early
defect detection and prevention that have been in existence for quite some time,
although not all of them are common practice. However, to use these methods
operationally and scale them to a particular project or environment, they have to
be positioned appropriately in the life cycle, especially in complex projects.
10
Term paper system analysis and design of IS
Modeling the development life cycle, that is the construction of a project-specific
life cycle, is an indispensable first step to recognize possible defect injection
points throughout the development project and to optimize the application of the
available methods for defect detection and prevention. This paper discusses the
importance of Life Cycle Modeling for defect detection and prevention and
presents a set of concrete, proven methods that can be used to optimize defect
detection and prevention. In particular, software inspections, static code analysis,
defect measurement and defect causal analysis are discussed. These methods
allow early, low cost detection of defects, preventing them from propagating to
later development stages and preventing the occurrence of similar defects in
future projects.
The phases of system development process an opportunity to add, improve, or
correct a system is identified and formally requested through the presentation of a
business case. The business case should, at a minimum, describe a proposal’s
purpose, identify expected benefits, and explain how the proposed system
supports one of the organization’s business strategies. The business case should
also identify alternative solutions and detail as many informational, functional,
and network requirements as possible
The planning phase is the most critical step in completing development,
acquisition, and maintenance projects. Careful planning, particularly in the early
stages of a project, is necessary to coordinate activities and manage project risks
effectively. The depth and formality of project plans should be commensurate
with the characteristics and risks of a given project.
The design phase involves converting the informational, functional, and network
requirements identified during the initiation and planning phases into unified
design specifications that developers use to script programs during the
development phase. Program designs are constructed in various ways. Using a
top-down approach, designers first identify and link major program components
and interfaces, then expand design layouts as they identify and link smaller
11
Term paper system analysis and design of IS
subsystems and connections. Using a bottom-up approach, designers first identify
and link minor program components and interfaces, then expand design layouts as
they identify and link larger systems and connections.
Application controls include policies and procedures associated with user
activities and the automated controls designed into applications. Controls should
be in place to address both batch and on-line environments. Standards should
address procedures to ensure management appropriately approves and control
overrides. Refer to the IT Handbook’s "Operations Booklet" for details relating to
operational controls.
Automated processing controls help ensure systems accurately process and record
information and either reject, or process and record, errors for later review and
correction. Processing includes merging files, modifying data, updating master
files, and performing file maintenance
The development phase involves converting design specifications into executable
programs. Effective development standards include requirements that
programmers and other project participants discuss design specifications before
programming begins. The procedures help ensure programmers clearly
understand program designs and functional requirements.
Different types of system development methodologies are used in designing information
system. Depending upon the actual requirement of the system, different approaches for
data processing are adopted. However, some system groups recommend the Centralized
data processing system while others may go in for distributed data processing system. In
a Centralized data processing, one or more centralized computers are used for processing
and the retrieval of information is done from them. The distributed processing systems
involve number of computers located remotely in the branches/departments of the
organization. The client/server technologies are also gaining popularity these days.
12
Term paper system analysis and design of IS
Objectives
Know the advantages and disadvantages of centralized/distributed data processing
system.
understand the meaning of various approaches to the information system
understand the networking environment
understand the meaning of client/server technology
Participants in system development
Stakeholders
o Individuals/organizations who are beneficiaries of the systems
development effort
Systems analyst
o Professional who specializes in analyzing and designing business systems
Users
o Individuals who interact with the system regularly
Programmer
o Individual responsible for modifying or developing programs to satisfy
user requirements
Programmer or consultant is one who designs and manages the development of business
applications. Typically, systems analysts are more involved in design issues than in day-
to-day coding. However, systems analyst is a somewhat arbitrary title, so different
companies define the role differently
13
Term paper system analysis and design of IS
TYPICAL REASONS TO INITIATE A SYSTEMS DEVELOPMENT
PROJECT
14
System stakeholders
Users
Vendors and suppliers
Technicalspecialists
Programmers
Managers
Systems analyst
Term paper system analysis and design of IS
INFORMATION SYSTEMS PLANNING (ISP)
An orderly means of assessing the information needs of an
organization and defining systems, databases, and technologies
that will best meet those needs
ISP must be done in accordance with the organization's mission,
objectives, and competitive strategy
Steps In Is Planning
15
Desire to make moreeffective use of information
Problems with existing systems
Desire to exploit new opportunities
Increasing competition
Organizational growth
Merger or acquisition
Change in market orexternal environment
Perception of potential benefit by individualcapable of initiating
change
Systems developmentprocess initiated
Term paper system analysis and design of IS
Strategic plan
Developing overall objectives
Identify IS projects
Set priorities & select projects
Analyse resource requirements
Set schedules and deadlines
Develop IS planning document
Previously unplannedsystem projects
16
Term paper system analysis and design of IS
FOLLOWING ARE SYSTEM DEVELOPMENT STRATEGIES
Systems Development Life Cycle
Structured analysis development method
System prototyping method
Systems Development Life Cycle
The systems development lifecycle (SDLC) is a type of methodology used to describe
the process for building information systems, intended to develop information
systems in a very deliberate, structured and methodical way, reiterating each stage of
the cycle. Information systems activities revolved around heavy data processing and
number crunching routines" The Systems Development Life Cycle (SDLC) is the
process of creating or altering systems, and the models and methodologies that
people use to develop these systems. The concept generally refers to computer or
information systems. System Development Life Cycle (SDLC) is any logical
process used by a systems analyst to develop an information system, including
requirements, validation, training, and user ownership. Any SDLC should result in
a high quality system that meets or exceeds customer expectations, reaches
completion within time and cost estimates, works effectively and efficiently in the
current and planned Information Technology infrastructure, and is inexpensive to
maintain and cost-effective to enhance.
17
Term paper system analysis and design of IS
Preliminary Investigation
18
Term paper system analysis and design of IS
Determination of the system requirement:
The goal of systems analysis is to determine where the problem is in an attempt to fix the
system. This step involves breaking down the system in different pieces and drawing
diagrams to analyze the situation, analyzing project goals, breaking down functions that
need to be created and attempting to engage users so that definite requirements can be
defined. Requirement Gathering sometimes require individual/team from client as well as
service provider side to get a detailed and accurate requirements.
Designing of the system
In systems design functions and operations are described in detail, including screen
layouts, business rules, process diagrams and other documentation. The output of this
stage will describe the new system as a collection of modules or subsystems. The design
stage takes as its initial input the requirements identified in the approved requirements
document. For each requirement, a set of one or more design elements will be produced
as a result of interviews, workshops, and/or prototype efforts. Design elements describe
the desired software features in detail, and generally include functional hierarchy
diagrams, screen layout diagrams, tables of business rules, business process diagrams,
pseudo code, and a complete entity-relationship diagram with a full data dictionary.
These design elements are intended to describe the software in sufficient detail that
skilled programmers may develop the software with minimal additional input.
Developing of the software:
Modular and subsystem programming code will be accomplished during this stage. Unit
testing and module testing are done in this stage by the developers. This stage is
intermingled with the next in that individual modules will need testing before integration
to the main project. Code will be test in every section.
System testing:
The code is tested at various levels in software testing. Unit, system and user acceptance
testing are often performed. This is a grey area as many different opinions exist as to
19
Term paper system analysis and design of IS
what the stages of testing are and how much if any iteration occurs. Iteration is not
generally part of the waterfall model, but usually some occurs at this stage.
Types of testing:
Unit testing
System testing
Integration testing
Implementation and evaluation:
The deployment of the system includes changes and enhancements before the
decommissioning or sunset of the system. Maintaining the system is an important aspect
of SDLC. As key personnel change positions in the organization, new changes will be
implemented, which will require system updates
The Systems Development Life Cycle (SDLC) phases serve as a programmatic guide to
project activity and provide a flexible but consistent way to conduct projects to a depth
matching the scope of the project. Each of the SDLC phase objectives are described in
this section with key deliverables, a description of recommended tasks, and a summary of
related control objectives for effective management. It is critical for the project manager
to establish and monitor control objectives during each SDLC phase while executing
projects. Control objectives help to provide a clear statement of the desired result or
purpose and should be used throughout the entire SDLC process. Control objectives can
be grouped into major categories (Domains), and relate to the SDLC phases.
Strengths and weaknesses
Few people in the modern computing world would use a strict waterfall model for their
Systems Development Life Cycle (SDLC) as many modern methodologies have
superseded this thinking. Some will argue that the SDLC no longer applies to models like
Agile computing, but it is still a term widely in use in Technology circles. The SDLC
20
Term paper system analysis and design of IS
practice has advantages in traditional models of software development, which lends itself
more to a structured environment. The disadvantages to using the SDLC methodology is
when there is need for iterative development or (i.e. web development or e-commerce)
where stakeholders need to review on a regular basis the software being designed. Instead
of viewing SDLC from a strength or weakness perspective, it is far more important to
take the best practices from the SDLC model and apply it to whatever may be most
appropriate for the software being designed.
Strengths Weaknesses
Control. Increased development time.
Monitor large projects. Increased development cost.
Detailed steps. Systems must be defined up front.
Evaluate costs and completion
targets.
Rigidity.
Documentation. Hard to estimate costs, project
overruns
Well defined user input. User input is sometimes limited.
Ease of maintenance.
Development and design standards.
Tolerates changes in MIS staffing.
Situations where most appropriate:
1. Project is for development of a mainframe-based or transaction-oriented batch
system.
2. Project is large, expensive, and complicated.
3. Project has clear objectives and solution.
4. Pressure does not exist for immediate implementation.
5. Project requirements can be stated unambiguously and comprehensively.
6. Project requirements are stable or unchanging during the system development life
cycle.
21
Term paper system analysis and design of IS
7. User community is fully knowledgeable in the business and application.
8. Team members may be inexperienced.
9. Team composition is unstable and expected to fluctuate.
10. Project manager may not be fully experienced.
11. Resources need to be conserved.
12. Strict requirement exists for formal approvals at designated milestones.
Situations where least appropriate:
1. Large projects where the requirements are not well understood or are changing for
any reasons such as external changes, changing expectations, budget changes or
rapidly changing technology.
2. Web Information Systems (WIS) primarily due to the pressure of implementing a
WIS project quickly; the continual evolution of the project requirements; the need
for experienced, flexible team members drawn from multiple disciplines; and the
inability to make assumptions regarding the users’ knowledge level.
3. Real-time systems.
4. Event-driven systems.
5. Leading-edge applications
STRUCTURED ANALYSIS DEVELOPMENT METHOD
Structured Systems Analysis and Design Method (SSADM) is a systems approach to the
analysis and design of information systems. SSADM was produced for the Central
Computer and Telecommunications Agency (now Office of Government Commerce), a
UK government office concerned with the use of technology in government, from 1980
onwards. SSADM is a waterfall method by which an Information System design can be
arrived at. SSADM can be thought to represent a pinnacle of the rigorous document-led
approach to system design, and contrasts with more contemporary Rapid Application
Development methods such as DSDM.
22
Term paper system analysis and design of IS
SSADM Techniques
Logical Data Modeling
This is the process of identifying, modeling and documenting the data
requirements of the system being designed. The data are separated into entities
(things about which a business needs to record information) and relationships (the
associations between the entities).
Data Flow Modeling
This is the process of identifying, modeling and documenting how data moves
around an information system. Data Flow Modeling examines processes
(activities that transform data from one form to another), data stores (the holding
areas for data), external entities (what sends data into a system or receives data
from a system), and data flows (routes by which data can flow).
Entity Behavior Modeling
This is the process of identifying, modeling and documenting the events that
affect each entity and the sequence in which these events occur.
STAGES
Analysis of the current system
It also known as: feasibility stage. Analyze the current situation at a high level. A Data
Flow Diagram (DFD) is used to describe how the current system works and to visualize
known problems. The following steps are part of this stage:
Develop a Business Activity Model. A model of the business activity is built.
Business events and business rules would also be investigated as an input to the
specification of the new automated system.
Investigate and define requirements. The objective of this step is to identify the
problems associated with the current environment that are to be resolved by the
new system. It also aims to identify the additional services to be provided by the
new system and users of the new system.
23
Term paper system analysis and design of IS
Investigate current processing. It investigates the information flow associated with
the services currently provided, and describes them in the form of Data Flow
Model. At this point, the Data Flow Model represents the current services with all
their deficiencies. No attempt is made to incorporate required improvement, or
new facilities.
Investigate current data. This step is to identify and describe the structure of the
system data, independently of the way the data are currently held and organized.
It produces a model of data that supports the current services.
Derive logical view of current services. The objective of this step is to develop a
logical view of the current system that can be used to understand problems with
the current system.
Outline business specification
It also known as: logical system specification stage. This stage consists of 2 parts. The
first part is researching the existing environment. In this part, system requirements are
identified and the current business environment is modeled. Modeling consists of creating
a DFD and LDS (Logical Data Structure) for processes and data structures that are part of
the system. In the second part, BSO (Business Systems Options), 6 business options are
presented. One of the options is selected and built. The following steps are part of this
stage:
Define BSOs. This step is concerned with identifying a number of possible
system solutions that meet the defined requirements from which the users can
select.
Select BSO. This step is concerned with the presentation of the BSOs to users and
the selection of the preferred option. The selected option defines the boundary of
the system to be developed in the subsequent stages.
Detailed business specification
It also known as: requirements specification stage. To assist the management to make a
sound choice, a number of business system options, each describing the scope and
24
Term paper system analysis and design of IS
functionalities provided by a particular development/implementation approach, are
prepared and presented to them. These options may be supported by technical
documentation such as Work Practice Model, LDM (Logical Data Model) and DFD.
They also require financial and risk assessments to be prepared, and need to be supported
by outline implementation descriptions.
The following steps are part of this stage:
Define required system processing. This step is to amend the requirements to
reflect the selected Business System Option, to describe the required system in
terms of system data flows and to define the user roles within the new system.
Develop required data model. This step is undertaken in parallel with the above
step. The LDM of the current environment is extended to support all the
processing in the selected business system option.
Derive system functions. During the parallel definition of data and processing,
additional events are identified, which cause existing functions to be updated and
new functions to be defined. Service level requirements for each function are also
identified in this step.
Develop user job specifications. A Work Practice Model is developed to
document the understanding of the user jobs in concern.
Enhance required data model. Its objective is to improve the quality of the
required system LDM by the application of relational data analysis (also known as
normalization).
Develop specification prototypes. It is used to describe selected parts of the
required system in an animated form, for demonstration to the users. The purpose
is to demonstrate that the requirements have been properly understood and to
establish additional requirements concerning the style of the user interface.
Develop processing specification. This step is principally concerned with defining
the detailed update and enquiry processing for the required system.
Confirm system objectives. During stage 1 and 3, the requirements will have been
recorded, as they are identified, in the user requirements. This step represents the
25
Term paper system analysis and design of IS
final review of the requirements before the completion of the Definition of
Requirements Stage.
Logical data design
It also known as: logical system specification stage. In this stage, technically feasible
options are chosen. The development/implementation environments are specified based
on this choice. The following steps are part of this stage:
Define TSOs: Up to 6 technical options (specifying the development and
implementation environments) is produced, one being selected.
Select TSOs. Select the most favorable TSO
Logical process design
It also known as: logical system specification stage. In this stage, logical designs and
processes are updated. Additionally, the dialogs are specified as well. The following steps
are part of this stage:
Define user dialogue. This step defines the structure of each dialogue required to
support the on-line functions and identifies the navigation requirements, both
within the dialogue and between dialogues.
Define update processes. This is to complete the specification of the database
updating required for each event and to define the error handling for each event.
Define inquiry processes. This is to complete the specification of the database
enquiry processing and to define the error handling for each inquiry.
Physical design
The objective of this stage is to specify the physical data and process design, using the
language and features of the chosen physical environment and incorporating installation
standards. The following activities are part of this stage:
Prepare for physical design
26
Term paper system analysis and design of IS
Learn the rules of the implementation environment
Review the precise requirements for logical to physical mapping
Plan the approach
Complete the specification of functions
Incrementally and repeatedly develop the data and process designs
FOLLOWING ARE THE TOOLS OF STRUCTURED ANALYSIS
Data flow diagram (DFD)
A data flow diagram (DFD) is a graphical representation flow of data designed by
a system analyst. It is used for the visualization of data processing for the
structured design of an information system. Data flow diagrams were invented by
Larry Constantine, developer of structured design, based on Martin and Estrin's
"data flow graph" model of computation. It is common practice for a database
designer to begin the process by drawing a context-level DFD, which shows the
interaction between the system and outside entities. This context-level DFD is
then "exploded" to show more detail of the system that is being modeled. It is also
called a bubble chart.
It has four symbols, following r the symbols
Square: - it defines sources
Arrow:- it defines data flow
circle :-it defines process
open rectangle :-it defines data store
27
Term paper system analysis and design of IS
Advantages
It represents data flows in better way.
It can be used at high or low level of analysis .Depending upon the needs
It provides good system documentation.
Disadvantages
It not able to display input and output details.
Data-flow lineProcesssymbol Data-flow line Data store
Member
Member
Member
AssignTee time
Checkmember
in
Sortscores
Calculatehandicap
Schedule
Member card
Scores
Tee time
Reservation request
Course access
Member ID
Score card
Handicap
Available times
Group information
Membertee time
Date
Score card
Tee time
28
Term paper system analysis and design of IS
Data Dictionary
A database dictionary contains a list of all files in the database, the number of records in
each file, and the names and types of each data field. This typically includes the names
and descriptions of various tables and fields in each database, plus additional details, like
the type and length of each data element. It clearly documents the list of contents of all
data flows, processes and data stores. The three classes to be defined are:
Data Elements: - it is the smallest unit of data. But it can not decompose.
The ISO-11179 Standards give rules for creating Data Element names.
Data Structure: - this is a group of Data Elements which together form as a unit
in a data structure.
Data flows and Data stores: - data flows are data structures in motion and Data
Stores are data structures in store.
Structure Chart
Structure chart shows the module hierarchy or calling sequence relationship of
modules. A Structure Chart (SC) is a chart, that shows the breakdown of the
configuration system to the lowest manageable levels. In structured analysis structure
charts are used to specify the high-level design, or architecture, of a computer program.
As a design tool, they aid the programmer in dividing and conquering a large software
problem, that is, recursively breaking a problem down into parts that are small enough to
be understood by a human brain. The process is called top-down design, or functional
decomposition. It is used to show the hierarchical arrangement of the modules in a
structured program.
Structured Design
Structured design techniques are fundamental tools of systems analysis, and developed
from classical systems analysis. Cohesion is concerned with the grouping of functionally
related processes into a particular module. Coupling addresses the flow of information, or
parameters, passed between modules. Optimal coupling reduces the interfaces of
modules, and the resulting complexity of the software
29
Term paper system analysis and design of IS
Role of various Tools used in the analysis and design of Information system of LPU
Since the 1970’s numerous attempts have been made to support methods via computer tools.
Technological developments have lead to a large number of tools that cover nearly all tasks of
ISD. At the same time the term CASE (Computer-Aided System Engineering) has been extended
to denote all types of computer tools from business modeling and requirements capture to
implementation tools.
The concept of CASE is broad and it includes compilers, project management tools, and even
editor. In this thesis we examine CASE tools in the context of modeling. These modeling tools are
usually used to support early phases of ISD. As already mentioned, the term method is restricted in
this thesis to mean that part of the method knowledge that it is possible to capture into a formalized
part of a tool. Types of methods and tools deployed during different phases of ISD are described in
Table 2-2.
As shown in the table, support for business process re-engineering and development include both
methods and tools. On the method side, process maps, workflow models, task structures and action
diagrams are applied. On the tool side, computing power is applied for example to benchmark,
compare, and simulate business processes through models. GDSS (Group Decision Support
Systems), CSCW (Computer Supported Cooperative Work) and requirements engineering tools
can be used in gathering information and organizing it into a structured format so that it can be
used in later phases of ISD. The methodical aspects of these tools rely on brain-storming,
interviews and cooperation. In the system analysis and design phases the upper-CASE tools
support methods such as conceptual data modeling and structured analysis and design (e.g. data
flow diagrams, decomposition diagrams and state transition diagrams). Most CASE products
nowadays focus on supporting object-oriented methods, and recently tool support has been
extended towards business modeling.
Table2.2
30
Term paper system analysis and design of IS
Method-tool companionship
Though the technical realization of the companionship between tools and methods can
vary, the need to integrate tools and methods is obvious (Forte and Norman 1992). On the
one hand, tools mechanize operations prescribed by methods by storing system
representations, transforming representations from one type of model to another, and
displaying representations in varying forms. On the other hand, tools empower users by
enhancing correctness checking and analytical power, by freeing them from tedious
documentation tasks, and by providing multi-user coordination (access and version
31
Term paper system analysis and design of IS
control). None of these features could be easily available in manual method use. The
companionship between tools and methods has also evolved in response to technical
innovations (Norman and Chen 1992). These require extensions to existing methods or
entirely new types of methods to support their development (e.g. to cope with distributed
systems (Olle 1994)), or then allow new types of methods because technical innovations
can be applied (e.g. simulation of state models).
CASE tools do not provide the same level of support for all types of method knowledge.
For example, there are more tools that support model building, representation and
checking than there are tools that guide processes or provide group support (Tolvanen et
al. 1993). Naturally, some aspects of methods lend themselves more easily to automation
than others (Olle et al. 1991). Nevertheless some method knowledge needs to be present
in an ISD tool. The presence of methods can also be viewed using CASE tool support
functionality, i.e. each type of functionality necessitates different method knowledge. In
the following these are discussed based on support for four different design steps (Olle et
al. 1991): abstraction, checking, form conversion and review. Olle et al. (1991) also
include a step for decision making, but since it can only be supported through other steps
and can not be automated (cf. Olle et al. 1991) we exclude it from the analysis of method-
tool companionship.
1) Abstraction deals with CASE tool support for capturing and representing aspects of
object systems. The majority of steps in design deal with abstractions, and thus it is also
the most supported step (Olle et al. 1991). On the level of method-tool companionship
this requires that a tool includes all the modeling related parts of the conceptual structure
and employs notational representations for them in modeling editors.
2) Checking of system descriptions are needed to ensure that models are syntactically
consistent with method knowledge. Hence, this design step can be carried out only after
some aspects of the object system have been abstracted into models. Checking operates
mostly on the conceptual structure and deals with constraints and rules of the method
(also called verification rules (Wijers 1991)). Although some checking activities can be
32
Term paper system analysis and design of IS
carried out by using alternative representation forms, such as matrixes for cross-checking,
checking operates mostly on the non-notational concepts. Therefore, to achieve
companionship this requires that the conceptual structure of the method includes not only
concepts related directly to representation (i.e. abstraction) but also include information
to carry out checking. For example, in most object-oriented methods, the link between a
state model and a class in a class model is vaguely defined (one good exception is
Embley et al. 1992): A state model can include states from several classes and therefore a
tool can not analyze whether all attributes of the class have values during its life-cycle.
To carry out this type of checking, the method specifications should include a reference
from each state to a corresponding class, or have state models that are used for instances
(i.e. objects) of a single class only (as in Embley et al. 1992).
These type of rules concerning the conceptual structures of methods are largely absent,
because most methods are developed from a “pen-and-paper” mindset. As a result, we do
not have many methods which are developed specially for CASE environments and take
full advantage of automation. Furthermore, in methods which apply multiple modeling
techniques, the need for checking is stressed. Also, if multiple tools are used, method
integration is a prerequisite of successful tool integration.
3) Form conversion deals with transforming results from one phase or task to another,
e.g. analysis models to design models. During a form conversion an underlying
conceptual structure, a notation, or a representation form changes. Examples of such
conversions, found in many CASE tools, are model analysis, reporting functions, and
code generation. To support these, the conceptual structure should include types and
constraints which are not necessarily required for the abstraction or checking steps. For
example, to generate program code (e.g. C++ or Java) from a class model each operation
representing a method in generated code should include return types as well as access
levels (i.e. public, private, protected). These constructs are often missing from conceptual
structures of text-book methods. As a result, CASE vendors need to extend methods in
order to provide additional tool functionality. It should be noted that not all conversions
can be fully automated, but rather often require human interaction.
33
Term paper system analysis and design of IS
4) Review deals with semantic validity of system descriptions, whereas checking focuses
on syntactic properties of the model. Because the review step is often carried out together
with the users or experts in the object system domain, the notation part of method
knowledge is emphasized here. To ensure that models describe all relevant parts of the
system, the notation should be sufficient to represent them. Naturally, the adequate
support of the notation reflects the underlying conceptual structure.
Since the effectiveness of the tool is always dependent on the method it is important how
a method or its parts are implemented in a tool. In our research, this means that the
applicability of methods is partly dictated by how well the tool supports their techniques.
Hence, method-tool companionship is based mainly on supporting the conceptual
structure and its related notation, and secondly the modeling process and design
objectives. The modeling process is relevant because the user interface (i.e. interface
structure (Wand 1996)) dictates how the tool can be used and thus affects processes
related to modeling: how models are created, how they are accessed, etc. The design
objectives are relevant to method-tool companionship because tools should also support
generation of design alternatives or produce solutions automatically.
SYSTEM PROTOTYPING METHOD
34
Term paper system analysis and design of IS
Prototyping is the process of building a model of a system. In terms of an information
system, prototypes are employed to help system designers build an information system
that intuitive and easy to manipulate for end users. Prototyping is an iterative process that
is part of the analysis phase of the systems development life cycle.
During the requirements determination portion of the systems analysis phase, system
analysts gather information about the organization's current procedures and business
processes related the proposed information system. In addition, they study the current
information system, if there is one, and conduct user interviews and collect
documentation. This helps the analysts develop an initial set of system requirements.
Prototyping can augment this process because it converts these basic, yet sometimes
intangible, specifications into a tangible but limited working model of the desired
information system. The user feedback gained from developing a physical system that the
users can touch and see facilitates an evaluative response that the analyst can employ to
modify existing requirements as well as developing new ones.
Prototyping comes in many forms - from low tech sketches or paper screens(Pictive)
from which users and developers can paste controls and objects, to high tech operational
systems using CASE (computer-aided software engineering) or fourth generation
languages and everywhere in between. Many organizations use multiple prototyping
tools. For example, some will use paper in the initial analysis to facilitate concrete user
feedback and then later develop an operational prototype using fourth generation
languages, such as Visual Basic, during the design stage
Types
Operational prototype
o Accesses real data files, edits input data, makes necessary computations
and comparisons, and produces real output
Non-operational prototype
o A mockup or model that includes output and input specifications and
formats
Rapid application development (RAD)
35
Term paper system analysis and design of IS
o Employs tools, techniques, and methodologies designed to speed
application development, automates source code generation, and
facilitates user involvement in design and development activities
Joint application development (JAD)
o Involves group meetings in which users, stakeholders, and IS
professionals work together to analyze existing systems, proposed
solutions, and define requirements for a new or modified system.
General Model of Prototyping
36
Term paper system analysis and design of IS
Prototype development :
A prototype is a pre-production model of an invention or product that is to be manufactured. The
creation of a prototype allows the inventor to discover whether his concept works or whether it
will need more engineering. It also allows a visual appraisal of the product, important if the
inventor is seeking funding for the development and manufacture or licensing of his invention.
In information system Prototypes is helpful in many ways. It makes selling the product concept
easier. Investors and potential licensees of the technology are more likely to understand its features
and benefits if there is a prototype. They also allow the inventor to perfect the concept and look of
the invention and test it for consumer acceptance, prior to manufacture.
Systems development initiated
Investigate and analyse problemsufficiently to develop
workable solution
Develop prototype
Put prototype into operation
Refine and modify prototype
Complete component or system
37
Term paper system analysis and design of IS
Following are the Reasons to develop a prototype
1. Without a virtual or tangible prototype, it will be more difficult for a buyer to understand
your invention. As discussed, the chance of success increases as you move your invention
through the development process. A prototype brings your idea to life for the person
evaluating your invention, which increases the chances of ultimately taking your invention
to market.
2. A developed prototype helps to work out the details of the invention. Identifying design
flaws and weaknesses is much easier when you can actually test the invention. Engineering
drawings and artwork alone cannot “prove” the concept in the same manner that a
prototype can – prototypes help to ensure that the invention will work the way you
intended.
3. Having a virtual or physical prototype helps to identify key details that should be included
in the provisional and/or non-provisional patent applications. Filing a patent application
before developing a prototype could lead to key details being excluded from the patent
application – details that are learned only through prototype development. For this reason, I
recommend that if you plan to develop a prototype, you do it first, before you file a patent
application.
4. Patent drawings will be much easier to complete if a model is available from which to
work.
Steps in Prototype Methods:
38
Term paper system analysis and design of IS
1. Plan
It helps you to determine prototyping needs and to plan the prototyping process accordingly. You
will decide what aspects of the software should or should not be prototyped to provide maximum
benefit to your prototyping effort
a. Verify the Requirements
The process starts with determining prototyping requirements. These requirements are not identical
to the software requirements but rather are a subset of those based on the audience of the prototype
and on your current stage in the software making process. In determining prototype requirements,
you choose a focus for the prototype that influences both the task flow and prototyping content.
b. Create a Task/Screen Flow
To effectively prototype, you must have some idea of how the user navigates from one screen/page
to the next. Likewise, it is necessary to know what happens when a user clicks on a certain widget
(or why s/he would want to). Sketching a task flow is a scalable activity: it can encompass a small
or large part of the system or it can involve just one person or the whole team. A task flow can
evolve as design and prototypes progress through iterations. Often, it is not simply enough to know
the task flow; you must also understand the context in which the task flow takes place.
c. Specifying Content and Fidelity
39
Term paper system analysis and design of IS
Most prototyping is characterized as either high or low fidelity, with a laundry list of methods or
tools thrown into one or the other category. A more comprehensive way to characterize a prototype
is by first identifying the prototyping content and then setting that information against a sliding
scale of possible fidelity levels. Far from having just one characteristic of fidelity, a prototype can
have different fidelity levels for each of the following content types: information design,
interaction design and navigation model, visual design, editorial content, branding, and system
performance/behavior.
2. Specification
The second phase of the prototyping process covers the results of decisions made in the first three
steps, in which those decisions allow you to act on the planning phases.
a. Determine the Right Prototyping Characteristics
Failing to use the appropriate prototype characteristics is a major cause of ineffective prototyping.
For example, providing your target audience with too many or too few details leads to an
ineffective use of your time—either in extra time spent prototyping or time spent on a prototype
test that is unable to receive needed feedback. It is important to distinguish between the end users
of your software and the stakeholders who will help you make the software.
b. Choose a Prototyping Method
In this step we discuss how to decide which method is right for your current situation.
c. Choose a Prototyping Tool
In this step matches your prototyping tool to the method you selected in previous step.
We encourage you to prototype with anything you desire because we believe it is more
empowering to use a skill set you already possess and a tool you’re already familiar with. You can
maximize the creative time spent prototyping rather than succumbing to the steep learning curve of
a less familiar prototyping tool.
d. Create the Prototype
40
Term paper system analysis and design of IS
In this step we discuss methods for tying together guidelines and requirements to achieve best
practice design. In the end, the quality of your prototype is based on the quality of user research,
accurate definition of requirements, and your own design exploration/iteration and analysis. Your
analysis can only be as thorough as your own well-rounded understanding of the guidelines and
requirements as well as an appreciation for the needs of your audience.
2. Design
After specifying a prototyping strategy, Phase III focuses on executing the prototype through good
design. For the accomplished prototype, good design is already part of the professional practice,
and these steps may seem naive or too simplified.
3. Results
Therefore it is also where we spend the least amount of our attention. This section is more for the
novice who:
Is not familiar with the proper way to conduct prototype reviews
Has never been involved with the activities and issues of usability testing
Has little experience creating a prototype and converting it into a product
a. Review the Prototype
In this outlines reviews with internal stakeholders and ways to ensure that an effective prototype
goes on for validation. Likewise, this chapter discusses the issues around reviews: what to look for
and what strategies to use.
b. Validate the Design
In this we discuss prototype validation through usability testing and other validation techniques
with external stakeholders.
c. Implement the Design
The last step in prototyping is taking an iterated prototype and shaping it into a product or service
concept as part of a new technology incubation process or translating it into an actual product or
41
Term paper system analysis and design of IS
service to deploy to the marketplace. Implementation involves the actions required to realize a
prototype appropriate to the goals and objectives of the creators.
Strength
Address the inability of many users to specify their information needs, and the
difficulty of the system analyst to understand the user’s environment, by
providing a tentative system for experimental purposes at the earliest possible
time.”
It can be used to realistically model important aspect of the system during each
phase of the traditional life cycle.”
Especially useful for resolving unclear objectives; developing and validating user
requirements; experimenting with or comparing various design solutions; or
investing both performance and the human computer interface.
Potential exists for exploiting knowledge gained in an early iteration as later
iterations are developed
Helps to easily identify confusing or difficult functions and missing functionality
Encourages innovation and flexible designs
It provides quick implementation of an incomplete, but functional application.
Weakness:
Requirements may frequently change significantly.
Designers may neglect documentation, resulting in insufficient justification
for the final product and inadequate records for the future.
Prototype may not have sufficient checks and balances incorporated.
Situations where most appropriate:
Project is large with many users, interrelationships, and functions, where project
risk relating to requirements definition needs to be reduced
Project objectives are unclear.
Pressure exists for immediate implementation of something
42
Term paper system analysis and design of IS
Functional requirements may change frequently and significantly.
User is not fully knowledgeable.
Team members are experienced (particularly if the prototype is not a throw-
away).
Team composition is stable.
Project manager is experienced.
Situations where least appropriate:
Web-enabled e-business systems
Project team composition is unstable.
Future scalability of design is critical
Project objectives are very clear; project risk regarding requirements definition is low.
43
Term paper system analysis and design of IS
CONCLUSION
This paper makes an initial effort at filling the gap between theory and practice in the
area of IS development strategies. By establishing the dimensions of IS development
strategies, we may provide researchers a valuable tool for subsequent empirical analysis
of other organizational and environmental variables on IS development strategy, as well
as effects of strategy on development success. It will also provide project mangers a
useful guide for assessing their IS development strategy by measuring their levels on the
demonstrated dimensions. Furthermore, by assessing the contingent effects of
organizational culture and project uncertainty, we provide academicians an initial
understanding of the complexity involved IS development strategy firmly grounded in
strategic theory. The four generic IS development strategies also provide managers a
useful guide for making choices based on their organizational culture and project
uncertainty. This study therefore makes important contributions to both theory and
practice of IS development
44
Term paper system analysis and design of IS
REFERENCE
Information Systems Development: Methodologies, Techniques and Tools -By McGraw-Hill, Berkshire
Systems Analysis and Systems Design in an Imperfect - By WorldMcGraw-Hill, Berkshire
Systems Development methodologies and Approaches, Journal of Management Information Systems, Vol 17, Issue 3
-By Winter 2000/2001, Information System Methodologies -By Wiley, Heyden, Chichester
45
