Process modeling involves graphically representing the processes, or actions, that capture, manipulate, store, and distribute data between a system and its environment and among components within a system. A common form of a process model is a data-flow diagram (DFD). A data-flow diagram is a graphic that illustrates the movement of data between external entities and the processes and data stores within a system. Although several different tools have been developed for process modeling, we focus solely on data-flow diagrams because they are useful tools for process modeling. Data-flow diagramming is one of several structured analysis techniques used to increase software development productivity. Although not all organizations use each structured analysis technique, collectively, these techniques, like dataflow diagrams, have had a significant impact on the quality of the systems development process.
Modeling a System’s Process
The analysis team begins the process of structuring requirements with an abundance of information gathered during requirements determination. As part of structuring, you and the other team members must organize the information into a meaningful representation of the information system that exists and of the requirements desired in a replacement system. In addition to modeling the processing elements of an information system and transformation of data in the system, you must also model the structure of data within the system (which we review in Chapter 7). Analysts use both process and data models to establish the specification of an information system. With a supporting tool, such as a CASE tool, process and data models can also provide the basis for the automatic generation of an information system.
Deliverables and Outcomes
In structured analysis, the primary deliverables from process modeling are a set of coherent, interrelated data-flow diagrams. Table 6-1 lists the progression of deliverables that result from studying and documenting a system’s process. First, a context data-flow diagram shows the scope of the system, indicating which elements are inside and outside the system. Second, data-flow diagrams of the current system specify which people and technologies are used in which processes to move and transform data, accepting inputs and producing outputs. The detail of these diagrams allows analysts to understand the current system and eventually to determine how to convert the current system into its replacement. Third, technology-independent, or logical, data-flow diagrams show the dataflow, structure, and functional requirements of the new system. Finally, entries for all of the objects in all diagrams are included in the project dictionary or CASE repository.
TABLE 6-1: Deliverables for Process Modeling
This logical progression of deliverables helps you to understand the existing system. You can then reduce this system into its essential elements to show the way in which the new system should meet its information processing requirements, as they were identified during requirements determination. In later steps in the systems development life cycle, you and other project team members make decisions on exactly how the new system will deliver these new requirements in specific manual and automated functions. Because requirements determination and structuring are often parallel steps, data-flow diagrams evolve from the more general to the more detailed as current and replacement systems are better understood. Even though data-flow diagrams remain popular tools for process modeling and can significantly increase software development productivity, they are not used in all systems development methodologies. Some organizations, such as EDS, have developed their own type of diagrams to model processes. Some methodologies, such as rapid application development (RAD), do not model processes separately at all. Instead, RAD builds processes—the work or actions that transform data so that they can be stored or distributed—into the prototypes created as the core of its development life cycle. However, even if you never formally use data-flow diagrams in your professional career, they remain a part of systems development’s history. DFDs illustrate important concepts about the movement of data between manual and automated steps and are a way to depict work flow in an organization. DFDs continue to benefit information systems professionals as tools for both analysis and communication. For that reason, we devote this entire chapter to DFDs.
Frequently Asked Questions
- Difference Between Manual And Automated System - Manual System vs Automated System
- System definition and concepts | characteristics and types of system
- Real-life Business sub-systems -Production, Marketing, Personal, Material, Finance
- Systems models types of models - Systems environment and boundaries
- Real Time And Distributed System
- Basic Principles Of Successful System
- Role and need of systems analyst
- Qualifications and responsibilities Of System Analyst
- System Analyst As Change Of Agent , Investigator and Monitoring Guy , Architect , Psychologist , Motivator , Intermediary
- System development life cycle (SDLC)
- Various phases of development - Analysis, Design, Development, Implementation, Maintenance
- Types of documentation and their importance
- Enforcing documentation discipline in an organization
- Data and fact gathering techniques- Interviews, Group communication, Presentations, Site visits
- Feasibility study and its importance