Information System Components (1)

Term paper

system analysis and design of IS

TERM PAPER OF SYSTEM ANALYSIS & DESIGN OF INFORMATION 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 1. Transaction Processing System

Characteristics Substitutes computer-based processing for manual procedures. Deals with well-structured processes.

2. Management information system

Includes record keeping applications. Provides input to be used in the managerial decision process. Deals with supporting well structured decision situations. Typical information requirements can be anticipated. 5

Term paper 3. Decision support system

system analysis and design of IS 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 o Tables 6

Term paper

system analysis and design of IS

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 dayto-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

Managers Programmers

Systems analyst Technical specialists

System stakeholders

Users

Vendors and suppliers

TYPICAL REASONS TO INITIATE A SYSTEMS DEVELOPMENT PROJECT

14

Term paper

system analysis and design of IS

Problems with existing systems Desire to exploit new opportunities Increasing competition Desire to make more effective use of information

Perception of potential benefit by individual capable of initiating change

Systems development process initiated

Organizational growth Merger or acquisition Change in market or external environment

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

Term paper

system analysis and design of IS

Strategic plan Previously unplanned system projects

Developing overall objectives Identify IS projects Set priorities & select projects Analyse resource requirements Set schedules and deadlines Develop IS planning document

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 • Control. • Monitor large projects. • Detailed steps. • Evaluate costs and completion • • • • •

Weaknesses • Increased development time. • Increased development cost. • Systems must be defined up front. • Rigidity.

targets. Documentation. Well defined user input. Ease of maintenance. Development and design standards. Tolerates changes in MIS staffing.

•

Hard to estimate costs, project

•

overruns User input is sometimes limited.

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. 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.

21

Term paper

system analysis and design of IS

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.

SSADM Techniques Logical Data Modeling

22

Term paper

system analysis and design of IS

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.

•

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

23

Term paper

system analysis and design of IS

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 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. 24

Term paper

system analysis and design of IS

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 final review of the requirements before the completion of the Definition of Requirements Stage.

25

Term paper

system analysis and design of IS

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

•

Learn the rules of the implementation environment

•

Review the precise requirements for logical to physical mapping

•

Plan the approach 26

Term paper

system analysis and design of IS

•

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

Data-flow line

Member

Tee time

Process symbol Assign Tee time

Reservation request

Course access

Member Member ID

Member

Score card

Handicap

Data-flow line

Data store

Available times

Schedule Group information

Check member in

Sort scores

Calculate handicap

Member tee time Date

Member card

Score card

Scores Tee time

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.

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

29

Term paper

system analysis and design of IS

parameters, passed between modules. Optimal coupling reduces the interfaces of modules, and the resulting complexity of the software 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

31

Term paper

system analysis and design of IS

documentation tasks, and by providing multi-user coordination (access and version 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

32

Term paper

system analysis and design of IS

(also called verification rules (Wijers 1991)). Although some checking activities can be carried out by using alternative representation forms, such as matrixes for crosschecking, 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

33

Term paper

system analysis and design of IS

order to provide additional tool functionality. It should be noted that not all conversions can be fully automated, but rather often require human interaction. 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 35

Term paper

system analysis and design of IS o A mockup or model that includes output and input specifications and formats

•

Rapid application development (RAD) 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

Systems development initiated Investigate and analyse problem sufficiently to develop workable solution Develop prototype Put prototype into operation Refine and modify prototype

Complete component or system

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.

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:

1. Plan 38

Term paper

system analysis and design of IS

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

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.

39

Term paper a.

system analysis and design of IS

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 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

40

Term paper

system analysis and design of IS

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 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. 41

Term paper •

system analysis and design of IS

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

•

Functional requirements may change frequently and significantly.

•

User is not fully knowledgeable.

•

Team members are experienced (particularly if the prototype is not a throwaway).

•

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

42

Term paper

system analysis and design of IS

Project objectives are very clear; project risk regarding requirements definition is low.

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

43

Term paper

system analysis and design of IS

uncertainty. This study therefore makes important contributions to both theory and practice of IS development

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

• •

44

Term paper

system analysis and design of IS

45