System information system

System: System is a collection of interrelated parts that work together to achieve one or more common goal. A system has five components:-input, process, output, feedback and control.

Feedback Feedback

Modification

Information system: includes customized hardware and software along with data that’s central to the company or organization’s mission, trained users who know how to use the system to serve customers better and produces that outline precisely how to accomplish a task without error.

TYPES OF INFORMATION SYSTEMS

An information system is a collection of hardware, software, data, people and procedures that are designed to generate information that supports the day-to-day, short-range, and long-range activities of users in an organization. Information systems generally are classified into five categories: office information systems, transaction processing systems, management information systems, decision support systems, and expert systems. The following sections present each of these information systems.

1. Office Information Systems:Anoffice information system, or OIS (pronounced oh-eye-ess), is an information system that uses hardware, software and networks to enhance work flow and facilitate communications among employees. Win an office information system, also described as office automation; employees perform tasks electronically using computers and other electronic devices, instead of manually. With an office information system, for example, a registration department might post the class schedule on the Internet and e-mail students when the schedule is updated. In a manual system, the registration department would photocopy the schedule and mail it to each student’s house.

An office information system supports a range of business office activities such as creating and distributing graphics and/or documents, sending messages, scheduling, and accounting. All levels of users from executive management to nonmanagement employees utilize and benefit from the features of an OIS.

Boundary

Components of a System

Input

Control Output Process

The software an office information system uses to support these activities include word processing, spreadsheets, databases, presentation graphics, e-mail, Web browsers, Web page authoring, personal information management, and groupware. Office information systems use communications technology such as voice mail, facsimile (fax), videoconferencing, and electronic data interchange (EDI) for the electronic exchange of text, graphics, audio, and video. An office information system also uses a variety of hardware, including computers equipped with modems, video cameras, speakers, and microphones; scanners; and fax machines.

2. Transaction Processing Systems: A transaction processing system (TPS) is an information system that captures and processes data generated during an organization’s day-to-day transactions. A transaction is a business activity such as a deposit, payment, order or reservation.

Clerical staff typically perform the activities associated with transaction processing, which include the following:

1. Recording a business activity such as a student’s registration, a customer’s order, an employee’s timecard or a client’s payment.

2. Confirming an action or triggering a response, such as printing a student’s schedule, sending a thank-you note to a customer, generating an employee’s paycheck or issuing a receipt to a client.

3. Maintaining data, which involves adding new data, changing existing data, or removing unwanted data.

Transaction processing systems were among the first computerized systems developed to process business data – a function originally called data processing. Usually, the TPS computerized an existing manual system to allow for faster processing, reduced clerical costs and improved customer service.

The first transaction processing systems usually used batch processing. With batch processing, transaction data is collected over a period of time and all transactions are processed later, as a group. As computers became more powerful, system developers built online transaction processing systems. With online transaction processing (OLTP) the computer processes transactions as they are entered. When you register for classes, your school probably uses OLTP. The registration administrative assistant enters your desired schedule and the computer immediately prints your statement of classes. The invoices, however, often are printed using batch processing, meaning all student invoices are printed and mailed at a later date.

Today, most transaction processing systems use online transaction processing. Some routine processing tasks such as calculating paychecks or printing invoices, however, are performed more effectively on a batch basis. For these activities, many organizations still use batch processing techniques.

3. Management Information Systems: While computers were ideal for routine transaction processing, managers soon realized that the computers’ capability of performing rapid calculations and data comparisons could produce meaningful information for management. Management information systems thus evolved out of transaction processing systems. A management information system, or MIS (pronounced em-eye-ess), is an information system

that generates accurate, timely and organized information so managers and other users can make decisions, solve problems, supervise activities, and track progress. Because it generates reports on a regular basis, a management information system sometimes is called a management reporting system (MRS).

Management information systems often are integrated with transaction processing systems. To process a sales order, for example, the transaction processing system records the sale, updates the customer’s account balance, and makes a deduction from inventory. Using this information, the related management information system can produce reports that recap daily sales activities; list customers with past due account balances; graph slow or fast selling products; and highlight inventory items that need reordering. A management information system focuses on generating information that management and other users need to perform their jobs.

An MIS generates three basic types of information: detailed, summary and exception. Detailed information typically confirms transaction processing activities. A Detailed Order Report is an example of a detail report. Summary information consolidates data into a format that an individual can review quickly and easily. To help synopsize information, a summary report typically contains totals, tables, or graphs. An Inventory Summary Report is an example of a summary report.

Exception information filters data to report information that is outside of a normal condition. These conditions, called the exception criteria, define the range of what is considered normal activity or status. An example of an exception report is an Inventory Exception Report is an Inventory Exception Report that notifies the purchasing department of items it needs to reorder. Exception reports help managers save time because they do not have to search through a detailed report for exceptions. Instead, an exception report brings exceptions to the manager’s attention in an easily identifiable form. Exception reports thus help them focus on situations that require immediate decisions or actions.

4. Decision Support Systems: Transaction processing and management information systems provide information on a regular basis. Frequently, however, users need information not provided in these reports to help them make decisions. A sales manager, for example, might need to determine how high to set yearly sales quotas based on increased sales and lowered product costs. Decision support systems help provide information to support such decisions.

A decision support system (DSS) is an information system designed to help users reach a decision when a decision-making situation arises. A variety of DSSs exist to help with a range of decisions.

A decision support system uses data from internal and/or external sources.

Internal sources of data might include sales, manufacturing, inventory, or financial data from an organization’s database. Data from external sources could include interest rates, population trends, and costs of new housing construction or raw material pricing. Users of a DSS, often managers, can manipulate the data used in the DSS to help with decisions.

Some decision support systems include query language, statistical analysis capabilities, spreadsheets, and graphics that help you extract data and evaluate the results. Some decision support systems also include capabilities that allow you to create a model of the factors affecting

a decision. A simple model for determining the best product price, for example, would include factors for the expected sales volume at each price level. With the model, you can ask what-if questions by changing one or more of the factors and viewing the projected results. Many people use application software packages to perform DSS functions. Using spreadsheet software, for example, you can complete simple modeling tasks or what-if scenarios.

A special type of DSS, called an executive information system (EIS), is designed to support the information needs of executive management. Information in an EIS is presented in charts and tables that show trends, ratios, and other managerial statistics. Because executives usually focus on strategic issues, EISs rely on external data sources such as the Dow Jones News/Retrieval service or the Internet. These external data sources can provide current information on interest rates, commodity prices, and other leading economic indicators.

To store all the necessary decision-making data, DSSs or EISs often use extremely large databases, called data warehouses. A data warehouse stores and manages the data required to analyze historical and current business circumstances.

5. Expert Systems: An expert system is an information system that captures and stores the knowledge of human experts and then imitates human reasoning and decision-making processes for those who have less expertise. Expert systems are composed of two main components: a knowledge base and inference rules. A knowledge base is the combined subject knowledge and experiences of the human experts. The inference rules are a set of logical judgments applied to the knowledge base each time a user describes a situation to the expert system.

Although expert systems can help decision-making at any level in an organization, non management employees are the primary users who utilize them to help with job-related decisions. Expert systems also successfully have resolved such diverse problems as diagnosing illnesses, searching for oil and making soup.

Expert systems are one part of an exciting branch of computer science called artificial intelligence. Artificial intelligence (AI) is the application of human intelligence to computers. AI technology can sense your actions and, based on logical assumptions and prior experience, will take the appropriate action to complete the task. AI has a variety of capabilities, including speech recognition, logical reasoning, and creative responses.

Experts predict that AI eventually will be incorporated into most computer systems and many individual software applications. Many word processing programs already include speech recognition.

Integrated Information Systems: With today’s sophisticated hardware, software and communications technologies, it often is difficult to classify a system as belonging uniquely to one of the five information system types discussed. Much of today’s application software supports transaction processing and generates management information. Other applications provide transaction processing, management information, and decision support. Although expert systems still operate primarily as separate systems, organizations increasingly are consolidating their information needs into a single, integrated information system.

The Systems Development Cycle:

The systems approach can be applied to the solution of many types of problems. When this involves the development of information system solutions to business problems, it is called information systems development or application development. Most computer-based information systems are conceived, designed, and implemented using some form of systematic development process. In this process, end users and information specialists design information systems based on an analysis of the information requirements of an organization. Thus, a major part of this process is known as systems analysis and design. When the systems approach is applied to the development of information system solutions, a multistep process or cycle emerges. This is frequently called the information systems development cycle, also known as the systems development life cycle (SDLC).

Steps involved and products produced in the traditional information systems development cycle:

1. Systems investigation - Product: Feasibility Study

2. Systems analysis - Product: Functional Requirements

3. Systems design - Product: Systems Specifications

4. Systems implementation - Product: Operational System

5. Systems maintenance - Product: Improved System

1. All the activities involved are highly related and interdependent. 2. Several developmental activities can occur at the same time. 3. Different parts of a development project can be at different stages of the development

cycle. 4. Analysts may recycle back at any time to repeat previous activities in order to modify and

improve a system being developed. 5. Developments such as computer-aided systems and end user development are automating

and changing some of the activities of information systems development. These developments are improving the quality of systems development and making it easier for IS professionals, while enabling more end users to develop their own systems.

Starting the Systems Development Process:

The first step in the systems development process is the systems investigation stage. This step may involve consideration of proposals generated by an information systems planning process. The investigation stage also includes the preliminary study of proposed information system solutions to end user business problems.

The three steps of the systems investigation stage involve:

1. Determine whether a business problem or opportunity exists. Defining Problems and Opportunities: To solve a problem or pursue an opportunity requires a thorough understanding of the situation at hand. This requires separating problems from symptoms, determining objectives and constraints, and, more important, viewing the problem or opportunity in a systems context.

Problem: - is a basic condition that is causing undesirable results.

Opportunity: - is a basic condition that presents the potential for desirable results. Symptoms: - are merely signals of an underlying cause or problem. 2. Conduct a feasibility study to determine whether a new or improved information

system is a feasible solution 3. Develop a project management plan and obtain management approval.

Feasibility Studies Because the process of developing a major information system can be costly, the systems investigation stage frequently requires a preliminary study called a feasibility study. A feasibility study is a preliminary study which investigates the information needs of prospective users and determine the resource requirements, cost, benefits, and feasibility of a proposed project.

Steps of a feasibility study:

1. Gather information/data for a feasibility study.

2. Formalize a written report including the preliminary specifications and a developmental plan for the proposed system.

3. Submit the report management for approval.

4. Begin system analysis (if management approves the recommendations of the feasibility study).

The goal of feasibility studies is to:

1. Evaluate alternative systems

2. Propose the most feasible and desirable systems for development.

Feasibility of a system can be evaluated in terms of four major categories:

1. Organizational Feasibility - focuses on how well a proposed information system supports the objectives of the organization and its strategic plan for information systems.

2. Economic Feasibility - focuses on whether the tangible costs and benefits of the proposed system will exceed the costs of developing and operating it.

3. Technical Feasibility - focuses on the reliable/capabilities of the hardware and software to meet the needs of the proposed system, and whether they can be acquired or developed in the required time.

4. Operation Feasibility - focuses on the willingness and ability of the management, employees, customers, suppliers, and others to operate, use, and support the proposed system.

Cost/Benefit Analysis Every legitimate solution will have some advantages or benefits, and some disadvantages or costs. These advantages and disadvantages are identified when each alternative solution is evaluated. This process is typically called cost/benefit analysis.

Tangible Costs - are costs and benefits that can be quantified (e.g., cost of hardware and software, employee salaries, and other quantifiable costs needed to develop and implement a solution).

Intangible Costs - costs and benefits that cannot be quantified (e.g., loss of customer goodwill or employee morale caused by errors and disruptions arising from the installation of a new system).

Tangible Benefits - are favourable results (e.g., decrease in payroll costs caused by a reduction in personnel or a decrease in inventory carrying costs caused by a reduction in inventory)

Intangible Benefits - are hard to estimate (e.g., better customer service or faster and more accurate information for management).

System Analysis

Systems analysis is an in-depth study of end user information needs which produces functional requirements that are used as the basis for the design of a new information system. System analysis traditionally involves a detailed study of:

1. The information needs of the organization and the end users.

2. The activities, resources, and products of any present information systems

3. The information systems capabilities required to meet the information needs of end users.

Organizational Analysis Organizational analysis involves evaluating the organizational and environmental systems and subsystems involved in any situation. Systems analysis traditionally involves a detailed study of the organizations:

1. Environment

2. Management structure

3. People

4. Business activities

5. Environmental systems it deals with

6. Current information systems

Analysis of the Present System Before designing a new system, a detailed analysis of the current system (manual or automated) must be completed. An analysis of the present system involves analysing activities, resources, and the products. You must analyse how the present system uses: 1. Hardware, software, people resources to convert data resources into information

products, such as reports and displays.

2. Document how the information activities if input, processing, output, storage, and control are being accomplished.

Functional Requirements Analysis This step of the systems analysis is one of the most difficult. Steps involve:

1. Determining specific information needs

2. Determining the information processing capabilities required for each system activity (input, processing, output, storage, and control) to meet the needs. Goal is to identify What should be done NOT how to do it.

3. Develop functional requirements (information requirements that are not tied to the hardware, software, and people resources that end users presently use or might use in the new system).

Systems Design

System analysis describes what a system should do to meet the information needs of users. System design specifies how the system will accomplish this objective. Systems design consists of design activities, which produce systems specifications satisfying the functional requirements developed in the systems analysis stage. These specifications are used as the basis for:

1. Software development

2. Hardware acquisition

3. System testing

4. Other activities of the implementation stage.

User Interface, Data, and Process Design The systems design concept focuses on three major products or deliverables, that should result from the design stage. System design consists of three activities:

1. User Interface Design

2. Data Design

3. Process Design

User Interface Design: User interface design focuses on supporting the interactions between end users and their computer-based applications. Designers concentrate on:

The design of attractive and efficient forms of user input and output, such as easy-to-use Internet or intranet web pages

Designing methods of converting human-readable documents to machine-readable input, such as optical scanning of business forms.

Design tips to keep in mind: o Keep it simple o Keep it clean o Organize logically

User interface design is frequently a prototyping process, where working models or prototypes of user interface methods are designed and modified with feedback from end users. User interface design produces detailed specifications for information products such as:

1. Display screens

2. Interactive user/computer dialogues

3. Audio responses

4. Forms

5. Documents

6. Reports.

Data Design The data design activity focuses on the design of the structure of databases and files to be used by a proposed information system. Data design frequently produces a data dictionary, which catalogues detailed descriptions of the:

1. Attributes or characteristics of the entities (objects, people, places, events) about which the proposed information system needs to maintain information.

2. Relationships these entities have to each other.

3. Specific data elements (databases, files, records, etc.) that need to be maintained for each entity tracked by the information system

4. Integrity rules that govern how each data element is specified and used in the information system.

Process Design The process design activity focuses on the design of software resources, that is, computer programs and of procedures needed by the proposed information system. It concentrates on developing detailed specifications for the program modules that will have to be purchased as software packages or developed by custom programming. Process design produces:

1. Detailed program specifications and procedures needed to meet the user interface and data design specifications that are developed.

2. Produces specifications that meet the functional control and performance requirements developed in the analysis stage.

System Specifications System specification focuses on defining the systems specifications required for the proposed information system. Typically, it specifies:

1. Hardware resources (machines and media)

2. Software resources (programs and procedures)

3. Network resources (communications media and networks) 3. People resources (end users & information systems staff).

4. How resources will be used to convert data resources (stored in files and databases they design) into information products (displays, responses, reports, and documents).

Prototyping:

Prototyping is the rapid development and testing of working models, or prototypes, of new applications in an interactive, iterative process involving both systems analysts and end users. Prototyping makes the development process faster and easier for systems analysts, especially for projects where end user requirements are hard to define. Thus, prototyping is sometimes called rapid application design (RAD). Prototyping has also opened up the application development process to end users because it simplifies and accelerates systems design. These developments are changing the roles of end users and information systems specialists in systems development.

The Prototyping Process

Prototyping can be used for both large and small applications. Typically, large systems still require using the traditional systems development approach, but parts of such systems can frequently be prototyped. Prototyping combines steps of the traditional systems development cycle, and allows the rapid development and testing of a working model. The model is then repeatedly refined until it is acceptable to an end user.

Implementing a New Information System:

Once a proposed information system has been designed, it must be implemented. The systems implementation stage involves:

1. Hardware and software acquisition

2. Software development

3. Testing of programs and procedures

4. Development of documentation

5. Installation activities

6. Education and training of end users and specialists who will operate the new system.

7. Converting from the use of the present system to the operation of a new or improved system.

Converting to a new system may involve:

Parallel System - Operating both a new system and an old system at the same time for a trial period.

Pilot System - Operate a pilot system on a trial basis at one location.

Phasing - Phasing in the new system one application or location at a time.

Plunge (Cutover) - Converting immediately to the new system.

Maintenance of Information Systems

Systems maintenance is the final stage of the systems development cycle. It involves the monitoring, evaluating, and modifying of a system to make desirable or necessary improvements. This may include:

1. Postimplementation review process to ensure that the new system meets the objectives established for it.

2. Error detected in the development or use of the system are corrected.

3. Later modifications to a system may also become necessary due to changes within the business or the business environment.

Computer-Aided Systems Engineering –

The traditional systems development life cycle process has often been too inflexible, time-consuming, and expensive for many organizations to utilize. To overcome some of the shortfalls of the SDLC, Computer-Aided Systems Engineering (CASE) process has emerged. CASE involves using software packages called CASE tools, to perform many of the activities of the systems development life cycle. CASE software packages are available to help do:

1. Business planning

2. Project management

3. User interface design

4. Database design

5. Software development.

Using CASE Tools:

Some of the capabilities of CASE tools can be found in the application development capabilities of end user software such as electronic spreadsheet and database management packages. CASE tools also help to automate the use of graphics tools such as flowcharts and data flow diagram.

CASE packages provide tools for the front end of the systems development life cycle (planning, analysis, and design) as well as the back end (implementation and maintenance). Many packages now include a system repository component that expands the role of the data dictionary as a catalogue of data definitions. A system repository provides systems analysts with computer-aided data descriptions and other cataloguing facilities, beginning with their systems planning and systems analysis activities, and continuing through the design, implementation, and maintenance of the system. Thus, the repository has become a database for all the details of a system generated with other systems development tools.

Integrated CASE tools are also available that can assist all of the stages of the systems development. Some CASE tools support joint application design (JAD), where a group of systems analysts, programmers, and end users can jointly and interactively design new applications. Finally, if the development of new systems can be called forward engineering, some CASE tools support backward engineering. That is, they allow systems analysts to inspect the logic of a program code for old applications and convert it automatically into more efficient programs that significantly improve system effectiveness.

End User Development

In end-user development, IS professionals play a consulting role while you do your own application development. Sometimes a staff of user consultants may be available to help you and other end users with your application development efforts. For instance, a user services group or information centre may provide assistance for both mainframe and microcomputer applications development.

Doing End User Development:

In end user development, you and other end users can develop new or improved ways to perform your jobs without the direct involvement of IS professionals. The application development capabilities built into a variety of end user software packages have made it easier for many users to develop their own computer-based solutions.

End user development should focus on the fundamental activities of an information system: input, processing, output, storage, and control.

Introduction to the Software Development Life Cycle (SDLC)

This section of the document will describe the Software Development Life Cycle (SDLC) for small to

medium database application development efforts. This chapter presents an overview of the SDLC,

alternate lifecycle models, and associated references. This chapter also describes the internal processes

that are common across all stages of the SDLC and describes the inputs, outputs, and processes of each

stage.

The SDLC Waterfall

Small to medium database software projects are generally broken down into six stages:

The relationship of each stage to the others can be roughly described as a waterfall, where the outputs

from a specific stage serve as the initial inputs for the following stage.

To follow the waterfall model, one proceeds from one phase to the next in a purely sequential manner.

For example,

After completing the “Project Planning” phase, one will be completing the "requirements

definitions" phase.

When and only when the requirements are fully completed, one proceeds to design. This design

should be a plan for implementing the requirements given.

When and only when the design is fully completed, an implementation of that design is made by

coders. Towards the later stages of this implementation phase, disparate software components

produced by different teams are integrated.

After the implementation and integration phases are complete, the software product is tested

and debugged; any faults introduced in earlier phases are removed here.

Then the software product is installed, and later maintained to introduce new functionality and

remove bugs.

Thus the waterfall model maintains that one should move to a phase only when it’s proceeding phase is

completed and perfected. Phases of development in the waterfall model are thus discrete, and there is no

jumping back and forth or overlap between them.

The central idea behind the waterfall model - time spent early on making sure that requirements and

design are absolutely correct is very useful in economic terms (it will save you much time and effort

later). One should also make sure that each phase is 100% complete and absolutely correct before

proceeding to the next phase of program creation.

It is argued that the waterfall model in general can be suited to software projects which are stable

(especially with unchanging requirements) and where it is possible and likely that designers will be able

to fully predict problem areas of the system and produce a correct design before implementation is

started.

The waterfall model also requires that implementers follow the well made, complete design accurately,

ensuring that the integration of the system proceeds smoothly.

The waterfall model however is argued by many to be a bad idea in practice, mainly because of their

belief that it is impossible to get one phase of a software product's lifecycle "perfected" before moving on

to the next phases and learning from them (or at least, the belief that this is impossible for any non-

trivial program). For example clients may not be aware of exactly what requirements they want before

they see a working prototype and can comment upon it - they may change their requirements constantly,

and program designers and implementers may have little control over this.

If clients change their requirements after a design is finished, that design must be modified to

accommodate the new requirements, invalidating quite a good deal of effort if overly large amounts of

time have been invested into the model.

In response to the perceived problems with the "pure" waterfall model, many modified waterfall models

have been introduced namely Royce's final model, sashimi model, and other alternative models. These

models may address some or all of the criticism of the "pure" waterfall model. There are other alternate

SDLC models such as “Spiral” and “V” which have been explained in the later part of this chapter.

After the project is completed, the Primary Developer Representative (PDR) and Primary End-User

Representative (PER), in concert with other customer and development team personnel develop a list of

recommendations for enhancement of the current software.

Data Flow Diagram (DFD) A data flow diagram (DFD) is a graphical representation of the flow of data through an information system without any indication of time. DFDs are commonly used to provide an initial top-down analysis of a system, identifying the processes to be carried out and the interactions and data exchanges between them. DFDs can be either logical, providing an implementation-independent description of the system, or physical describing the actual entities (devices, department, people, etc.) involved.

Data flow diagrams can be created in a model targeting the Data Flow Diagram process language. To create a new DFD model, select File > New Model, choose Business Process Model as the model type, Data Flow Diagram as the process language, and Business Process Diagram as the first diagram. Note: To create a DFD model from an analysis or other BPM model, select Tools > Generate Business Process Model and select Data Flow Diagram as the process language. Composite processes with start and end objects are replaced with external entity objects or process shortcuts, depending on the input and output flows of the composite process. Data items are preserved. PowerDesigner supports all the objects necessary to build data flow diagrams: Tool Symbol Description

Gane&Sarson:

Yourdon:

Process - An activity that transforms or manipulates input data to produce output data (see Processes (BPM)). Flows from processes can go to external entities, data stores, split/merges, or other processes.

The Data tab in the process property sheet displays the process CRUD accesses to data.

Note: To choose a notation, select Tools > Model Options and select the appropriate Data Flow Diagram Notation.

Flow - Oriented link that conveys data between processes, external entities, and data stores and represents data in motion. Flows are based on standard flows (see Flows (BPM )) with a Flow stereotype. Flows

Tool Symbol Description

to or from data stores are based on standard resource flows (see Resource Flows (BPM)), and must be created with the Resource Flow tool. A flow cannot directly link two data stores or two external entities.

The Data tab in the flow property sheet displays the data transported by the flow.

Gane&Sarson:

Yourdon:

Data store - Location where data resides permanently or temporarily and represents data at rest. Data stores respond to requests for storing and accessing data, but cannot initiate any actions, and are based on standard resources (see Resources (BPM)) with a Data Storestereotype.

Flows to data stores represent write, update, or delete access, and flows from data stores represent read access.

External entity - A person, organization, or system outside the system being modeled that sends data to or receives data from the system. Flows from external entities cannot directly access data and must pass through processes. External entities are based on standard organization units (Organization Units ( BPM)) with an External Entity stereotype.

Split/Merge - Splits a flow into two or more flows or merges multiple flows into a single flow. Split/merges are based on standard synchronizations (see Synchronizations (BPM )) with a Split/Merge stereotype.

A split/merge can, for example, split a complex packet of data into more elementary packets, and send them to different processes or duplicate data to send to different processes, or alternatively merge multiple data packets together for onward transmission.

None None Data - Conceptual information exchanged between the other objects (see Data (BPM))

You can associate the data analyzed in a DFD with conceptual, logical, and physical data models and object-oriented models (see Linking Data with Other Model Objects).

Analysts typically begin with a system context DFD to show the interactions between the system as a whole and external entities. In the following example, the Great Care Society process interacts with the Donors, Bank, Members, and Prospective Members external

entities:

You can decompose processes in a DFD (see Decomposing Processes), and PowerDesigner initializes the subdiagram with all the objects that link to the process being decomposed (external entities, data stores, and shortcuts to processes as necessary). Such balancing helps ensure that all the flows to and from the process being decomposed are preserved at the next level of decomposition. When the Great Care Society process is decomposed its diagram is initialized with the four external entities:

The diagram is enriched to show the sub-processes that handle donations, deposits, and correspondence, and the data stores that they interact with:

To test balancing, select Tools > Check Model, and select the balancing checks under the Flow and Resource Flow objects.

When using the default Gane&Sarson methodology, processes and data stores are automatically numbered. As you decompose your processes, child processes inherit the number ID of their parent process so that the first child of top level process 1 is numbered 1.1, and the first child of this process is numbered 1.1.1. This numbering scheme enables you to easily identify the lineage of a process at any level of decomposition and provides a convenient way to reference processes and data stores by numbers instead of sometimes long or complex names:

Note: Numbering does not indicate the order in which processes are performed. By default, numbers begin at 1, but you can enter any integer in a process or data store property sheet and all subsequent objects will be incremented from that number. To revert to numbering from one, right-click the diagram background and select renumber Process IDs or Renumber Data Store IDs.