system analysis first edition design · 2017. 6. 15. · data flow diagram (dfd) process...
TRANSCRIPT
SYSTEM ANALYSIS DESIGN
AND
First Edition
OLARIK SURINTA FACULTY OF INFORMATICS Department of
Management Information System Computer Science
Olarik Surinta CS/MIS: [System Analysis in Information Center] 1/2
Course Syllabus รหัสวิชา 1202324 ชื่อวิชา การวิเคราะหระบบในศนูยสารสนเทศ
System Analysis in Information Center หนวยกิต 3(3-0-0) ภาคเรียน 1/2548 ผูสอน อาจารยโอฬารกิ สุรินตะ E-mail [email protected], [email protected] Web site http://www.it.msu.ac.th/kong โทรศัพท 0-4375-4333 ตอ 2497, 0-1992-3518 เนื้อหารายวิชา
1. Introduction to Systems Analysis 2. Systems Development Life Cycle 3. Managing the Information Systems Project 4. System Analysis 5. System Design 6. System Implementation 7. System Maintenance
การวัดผล
1. โครงงาน (Project) 40 % 1.1 โปรแกรม 15 % 1.2 เอกสาร 15 % 1.3 เสนอผลงาน (Present) 10 %
2. สอบระหวางภาค (Midterm) 20 % 3. สอบปลายภาค (Final) 30 % 4. เขาหองเรียน (Class) 10 % นิสิตจะตองไดคะแนน ไมนอยกวา 40 คะแนน จึงจะถือวาผาน
Olarik Surinta CS/MIS: [System Analysis in Information Center] 2/2
เอกสารประกอบการเรียน [1] Modern Systems Analysis & Design. Jeffery A. Hoffer, Joey F. George, Joseph S. Valacich [2] Systems Analysis and Design. Alan Dennis, Barbara Haley Wixom [3] Systems Analysis and Design. Shelly Cashman Rosenblatt [4] Systems Analysis and Design Methods. Jeffrey L. Whitten, Lonnie D. Bentley [5] การวิเคราะหและออกแบบระบบ. โอภาส เอี่ยมสิริวงศ [6] การวิเคราะหและออกแบบระบบ. ดร.อําไพ พรประเสริฐกุล
การวิเคราะหระบบในศนูยสารสนเทศSystem Analysis in Information Center(1202324)โอฬาริก สุรินตะCS/MIS/ICT
System Analysis in Information Center 2
Course Outline
1. Introduction to systems analysis and design
2. Systems Development Life Cycle3. Managing the Information System
Project4. System Analysis5. System Design
System Analysis in Information Center 3
Course Outline
6. System Implementation7. System Maintenance
System Analysis in Information Center 4
Chapter 1: Introduction to systems analysis and design
Information technologyBusiness process modelingInformation system componentType of business information systemsOrganizational structure
System Analysis in Information Center 5
Chapter 2: Systems Development Life Cycle
Project identification and selectionProject initiation and planningAnalysisDesignImplementationMaintenance
System Analysis in Information Center 6
Chapter 3: Managing the Information System Project
Managing the information systems projectInitiating the projectPlanning the projectExecuting the projectClosing down the project
Constructing a PERT diagram
System Analysis in Information Center 7
Chapter 4: System Analysis
Systems analysis phase overviewSystem development methodsSystem requirementInterviewsData Flow Diagram (DFD)Process descriptionData dictionary
System Analysis in Information Center 8
Chapter 5: System Design
Systems design phase overviewUser interface designInput designOutput designData design concept
Overview of file processingOverview of database systemsData relationship
System Analysis in Information Center 9
Chapter 6: System Implementation
Quality AssuranceOverview of Application DevelopmentStructured Application DevelopmentOther Application Development ToolsCodingTesting the Application
System Analysis in Information Center 10
Chapter 6: System Implementation
DocumentationFlowchart
System Analysis in Information Center 11
Chapter 7: System Maintenance
Maintaining Information SystemType of MaintenanceMaintenance TeamManaging Maintenance Requests
Project Form Description
Olarik Surinta CS/MIS
1/6
สาขาวิชาสารสนเทศศาสตร
คณะวิทยาการสารสนเทศ มหาวิทยาลัยมหาสารคาม
แบบเสนอเคาโครง
1. นิสิตผูจัดทําโครงงาน 1.1 ช่ือนิสิต (นาย/นางสาว) _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ รหัสประจําตัว _ _ _ _ _ _ _ _ _ _ 1.2 ช่ือนิสิต (นาย/นางสาว) _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ รหัสประจําตัว _ _ _ _ _ _ _ _ _ _
2. หลักสูตร _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 3. ช่ือเรื่อง (ภาษาไทย) _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
(ภาษาอังกฤษ) _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ ขอสงเคาโครงโครงงานจํานวน 1 ฉบับ เพื่อใหอาจารยประจําวิชาการวิเคราะหระบบในศูนยสารสนเทศ พิจารณาเคาโครง ทั้งนี้ไดรับความเห็นชอบจากอาจารยผูควบคุมโครงงานเรียบรอยแลว ลงชื่อ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ (อาจารยที่ปรึกษา) ( )
ลงชื่อ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ (นิสิต) ( )
ลงชื่อ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ (นิสิต)
( ) วันที่ _ _ _ เดือน _ _ _ _ _ _ _ _ _ พ.ศ. _ _ _ _
Project Form Description
Olarik Surinta CS/MIS
2/6
เคาโครงการจัดทําโครงงาน
ผูจัดทํา 1. _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 2. _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ ปริญญา _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ อาจารยโอฬารกิ สุรินตะ ที่ปรึกษา สาขาวิชา _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ ปการศึกษา _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ ชื่อเร่ือง (ภาษาไทย) _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ (ภาษาอังกฤษ) _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Project Form Description
Olarik Surinta CS/MIS
3/6
แบบเสนอเคาโครง (Proposal) ประกอบดวยหัวขอตาง ๆ ดงันี้ 1. หลักการและเหตุผล 2. วัตถุประสงคของโครงงาน 3. ขอบเขตของโครงงาน 4. งานวิจยัและทฤษฎีที่เกี่ยวของ 5. ประโยชนที่คาดวาจะไดรับ 6. อุปกรณและเครื่องมือที่ใชในการดําเนนิงาน 7. วิธีการดําเนนิการโดยสังเขป 8. สถานที่และระยะเวลาจัดทําโครงงาน ระยะเวลาจดัทาํโครงงาน ระหวางเดือน มิถุนายน พ.ศ. 2548 ถึงเดือนตุลาคม พ.ศ. 2548
พ.ศ. 2548 กิจกรรม มิ.ย. ก.ค. ส.ค. ก.ย. ต.ค.
1. ศึกษาระบบงาน 2. ออกแบบสอบถาม 3. สอบถามขอมูล 4. เก็บรวบรวมขอมูล 3. วิเคราะหและออกแบบระบบ 4. พัฒนาโปรแกรม 5. ทดสอบโปรแกรม 6. จัดทําเอกสาร 7. นําเสนอผลงาน
Project Form Description
Olarik Surinta CS/MIS
4/6
ชื่อเรื่อง ภาษาไทย
ชื่อเรื่อง ภาษาอังกฤษ
ชื่อนิสิต
นําเสนอ อาจารยโอฬาริก สุรินตะ
โครงงานนี้เปนสวนหนึ่งของวิชาการวเิคราะหระบบในศูนยสารสนเทศ สาขาวิชาสารสนเทศศาสตร คณะวิทยาการสารสนเทศ
มหาวิทยาลัยมหาสารคาม พ.ศ. 2548
ตัวอยาง หนาปกเอกสารฉบับสมบูรณ
Project Form Description
Olarik Surinta CS/MIS
5/6
เอกสารฉบับสมบูรณ
เอกสารฉบับสมบูรณ ประกอบดวย บทท่ี 1 บทนํา บทท่ี 2 งานวิจยัและทฤษฎีที่เกี่ยวของ บทท่ี 3 ขั้นตอนการดําเนินงาน ประกอบดวย
1. Service System Requirement 2. Project Planning
2.1 Gantt Chart 2.2 PERT Diagram 2.3 Statement of Work 2.4 Baseline Project Planning Report
3. Context Diagram 4. Data Flow Diagram 5. Data Dictionary
5.1 Data Flow 5.1.1 Data Flow Description 5.1.2 Data Structure of Data Flow 5.1.3 Data Element of Data Flow
5.2 Data Store 5.2.1 Data Store Description 5.2.2 Data Structure of Data Store 5.2.3 Data Element of Data Store 5.3 External Entity Description 5.4 Process Description
6. E-R Diagram 7. Database 8. Flow Chart 9. Structure Chart
บทท่ี 4 การพัฒนาและการทดสอบระบบ บทท่ี 5 สรุปผลการดําเนินงานและขอเสนอแนะ
Project Form Description
Olarik Surinta CS/MIS
6/6
บรรณานุกรม ภาคผนวก ก คูมือการใชโปรแกรม CD-ROM ฯลฯ
Introduction to Systems Analysis and Designโอฬาริก สุรินตะCS/ICT
Chapter 1 - Introduction to Systems Analysis and Design 2
Information Technology (IT)
Information Technology is a combination of hardware, software, and telecommunication system.That support business operations, improve productivity, and help managers make decisions.A key part of IT involves systems analysis and design.
Chapter 1 - Introduction to Systems Analysis and Design 3
Information Technology (IT)
Which is the process of developing information systems.That effectively us hardware, software, data, process, and people to support the company’s business objectives.A System Analysis working in the IT department plans, analyzes, and implements information systems.
Chapter 1 - Introduction to Systems Analysis and Design 4
BUSINESS PROCESS MODELING
IT professionals must understand a company’s business operations in order to design successful system.Each business situation is differentFor Example, a retail store, and Internet auction site, and hotel chain all have unique information systems requirements.
Chapter 1 - Introduction to Systems Analysis and Design 5
BUSINESS PROCESS MODELING
Systems analysis use a process called business process modeling to represent a company’s operations and information needs.
Chapter 1 - Introduction to Systems Analysis and Design 6
Business Profiles, Models, and Processes
A business profile defines a company’s overall function, processes, organization, products, services, customers, suppliers, competitors, constraints, and future direction.To understand a company’s operations, systems analysis first develop a business profile and then create a series of business models.
Chapter 1 - Introduction to Systems Analysis and Design 7
Business Profiles, Models, and Processes
A business model graphically represents business functions that consist of business processes.Such as sales, accounting, and purchasing, which perform specific tasks.
Chapter 1 - Introduction to Systems Analysis and Design 8
Business Profiles, Models, and Processes
A business process describes specific events, tasks, and desired results
Chapter 1 - Introduction to Systems Analysis and Design 9
Sub processes:Enter Customer Order Data
Sub processes:Verify Customer Credit
Sub processes:Check Customer Status
Event:Receive Sales Order
Result:Completed Sales Order
Process: Handle Sales Order
FIGURE 1 A business model might consist of an event, three sub processes, and a result.
Chapter 1 - Introduction to Systems Analysis and Design 10
Business Profiles, Models, and Processes
Figure 1 shows a business process called HANDLE SALES ORDER that includes an event, three sub processes, and a result.When companies attempt to simplify operations or reduce costs, they engage in business process reengineering.
Chapter 1 - Introduction to Systems Analysis and Design 11
INFORMATION SYSTEM COMPONENTS
A system is a set of related components that produces specific results.Every system requires some form of input data.In an information system, data consist of basic facts that are the system’s raw material.
Chapter 1 - Introduction to Systems Analysis and Design 12
FIGURE 2 After a customer representative enters input data, the envisionSBS creates a sales order.
Chapter 1 - Introduction to Systems Analysis and Design 13
INFORMATION SYSTEM COMPONENTS
Figure 2 shows a shopping system. After customer input data (Product and Quantity), the order system creates a customer order that contains the required information.
Chapter 1 - Introduction to Systems Analysis and Design 14
INFORMATION SYSTEM COMPONENTS
Information is data that has been changed into a useful form of output. The task of changing data into information is called processing.an information system has five key components: hardware, software, data, processes, and people.
Chapter 1 - Introduction to Systems Analysis and Design 15
Hardware
Hardware refers to the physical layer of the information system. Hardware includes computers, networks, communications equipment, scanners, digital capture devices, and other technology-based infrastructure.
Chapter 1 - Introduction to Systems Analysis and Design 16
Software
Software consists of system software and application softwareSystem software controls the computer and includes the operating system, device drivers that communicate with hardware, and utilities that handle tasks such converting data into a different format
Chapter 1 - Introduction to Systems Analysis and Design 17
Software
Application software consists of programs that support users and enable companies to carry out business functions.Users increase their productivity with tools such as spreadsheets, word processors, and database management systems.
Chapter 1 - Introduction to Systems Analysis and Design 18
Data
An information system transforms data into useful information.
FIGURE 3 An information system uses data storedIn two tables to produce a paycheck.
Chapter 1 - Introduction to Systems Analysis and Design 19
Data
As shown in Figure 3, the information system uses data from both tables to calculate the employee’s gross pay and to produce a paycheck that subtracts taxes and deductions from total earnings.
Chapter 1 - Introduction to Systems Analysis and Design 20
Processes
Processes, or procedures, describe the tasks that users, managers, and IT staff members perform.Processes necessary to support a specific business model are described in written documentation manuals and online reference materials.
Chapter 1 - Introduction to Systems Analysis and Design 21
People
The primary purpose of an information system is to provide valuable information to managers and users within and outside the company.Users, sometimes called end users, include employees, customers, vendors, and others who interact with an information system.
Chapter 1 - Introduction to Systems Analysis and Design 22
People
Internal users include managers, technicians, sales, and corporate officers.External users include customers who track their orders on the company’s Web site, suppliers who use a customer’s system to plan their manufacturing schedules, and employees who log on to the company’s intranet from home to check their e-mail messages.
Chapter 1 - Introduction to Systems Analysis and Design 23
Successful information system
Successful information systems also require the efforts of skilled professionals, such as systems analysis, programmers, and IT managers.Information systems must fulfill business needs and support company objectives.
Chapter 1 - Introduction to Systems Analysis and Design 24
TYPE OF BUSINESS INFORMATION SYSTEMS
Large companies require many different types of information systems.Systems include enterprise computing systems, transaction processing systems, business support systems, knowledge management systems, and user productivity systems.
Chapter 1 - Introduction to Systems Analysis and Design 25
Enterprise Computing Systems
Enterprise Computing refers to information systems that support company wide data management requirements.Airline reservation and credit card billing systems are examples of enterprise computing systemsEnterprise computing also can improve data security and reliability by imposing a company-wide framework for data access and storage.
Chapter 1 - Introduction to Systems Analysis and Design 26
Enterprise Computing Systems
In many large companies, applications called enterprise resource planning (ERP) systems provide cost-effective data access for users and managers throughout the companyFor example, a car rental company can use ERP to forecast customer demand for rental cars at hundreds of locations.
Chapter 1 - Introduction to Systems Analysis and Design 27
Transaction Processing Systems
Transaction processing (TP) systems and Online transaction processing (OLTP) systems are called operational systems because they process data generated by day-by-day business operations.Examples of TP systems include customer billing, accounts receivable, and warranty claim processing.
Chapter 1 - Introduction to Systems Analysis and Design 28
Adjust Inventory Data
Update Sales Activity file
Sale Transaction
Check In-StockStatus
Post to Accounts Receivable
Check Credit Status
Verify Customer Data
FIGURE 4 A Single sales transactionConsists of six separate tasks.
Chapter 1 - Introduction to Systems Analysis and Design 29
Transaction Processing Systems
TP systems also ensure that if any one element of a transaction fails, the system cannot process the rest of the transaction. This feature is known as data integrity. Most transaction processing systems are mission-critical systems that cannot be interrupted without severe disruption to the business.
Chapter 1 - Introduction to Systems Analysis and Design 30
Business Support Systems
Business support systems (BSS) andManagement information systems (MIS)provide job-related information support to users at all levels of a company. These systems can analyze transactional data, generate information needed to manage and control business processes, and provide information that leads to better decision making.
Chapter 1 - Introduction to Systems Analysis and Design 31
Business Support Systems
Today, employees at all levels need information to perform their job, and they rely on information systems for that support.An information system must generate timely and accurate records.
Chapter 1 - Introduction to Systems Analysis and Design 32
ORGANIZATIONAL STRUCTURE
Many companies reduced the number of management levels and delegated responsibility to operational personnel.Although the organization chart tends to be somewhat flatter, a traditional hierarchy still exists in most companies.In the typical organizational model shown in Figure 5
Chapter 1 - Introduction to Systems Analysis and Design 33
TopManagement
MiddleManagement
LowerManagementOperational
Employees
CEO,
President,
Vice President
Sales Representative, Retail Associate,
Production Worker, Team Member,
Administrative Assistant, Tech Support
Representative, accounting Clerk, Financial Analyst
Supervisor,
Team Leader,
Coordinator
Director,
Manager
FIGURE 5 Organizational model of a typical company.
Chapter 1 - Introduction to Systems Analysis and Design 34
Top Management
Top managers develop long-range plans, called strategic plans that define the company’s overall mission and goals. Top managers ask questions such as “How much should the company invest in information technology”, or “How much will Internet sales grow in the next five years”.
Chapter 1 - Introduction to Systems Analysis and Design 35
Top Management
Strategic planning focuses on issues that affect the company’s future survival and growth, including long-term plans. Top managers focus on the entire business enterprise and use information systems to set the company’s course and direction. To develop a strategic plan, top managers also need information from outside the company.
Chapter 1 - Introduction to Systems Analysis and Design 36
Middle Management
Middle managers focus their goals on a shorter time frame, usually ranging from one month to one year.They develop plans to achieve business objectives in a process called tactical planning.Middle managers delegate authority and responsibility to team leaders and then provide direction, necessary resources, and feedback on performance as tasks are completed.
Chapter 1 - Introduction to Systems Analysis and Design 37
Middle Management
Middle managers need more detailed information than top managers.For example, a middle manager might review a weekly sales summary for a geographic region, whereas a sales team leader would need a daily report on customer activity.Middle managers also use business support systems, knowledge management systems, and user productivity systems to perform their jobs.
Chapter 1 - Introduction to Systems Analysis and Design 38
Lower Management
Supervisors and team leaders oversee operational employees and carry out day-to-day operational plans.They coordinate operational tasks, make necessary decision, and ensure that the right tools, materials, and training are available.
Chapter 1 - Introduction to Systems Analysis and Design 39
Lower Management
This group often needs decision support information, consults knowledge management systems, and relies on user productivity systems to carry out their day-to-day responsibilities.
Chapter 1 - Introduction to Systems Analysis and Design 40
Operational Employees
Operational employees primarily use TP systems to enter and receive data they need to perform their jobs.In many companies, operational employees also need information to handle tasks and make decisions that were assigned previously to supervisors.
Chapter 1 - Introduction to Systems Analysis and Design 41
Operational Employees
This trend, called empowerment, gives employees more responsibility and accountability.Many companies find that empowerment leads to better employee motivation and increased customer satisfaction.
Systems Development Life Cycleโอฬาริก สุรินตะCS/ICT
Chapter 2 - SDLC 2
SYSTEMS DEVELOPMENT LIFE CYCLE
Systems Development Life Cycle (SDLC) is the overall process of developing information systems through a multi step process from investigation of initial requirements through analysis, design, implementation, and maintenance. They are many different models and methodologies, but each generally consist of a series of defined steps or stages.
Chapter 2 - SDLC 3
Project Identificationand Selection
Project Initiation
and Planning
Analysis
Design
Implementation
MaintenanceFIGURE 1 The systems development life cycle
Chapter 2 - SDLC 4
Project Identification and selection
Two Main ActivityIdentification of needPrioritization and translation of need into a development schedule
Helps organization to determine whether or not resources should be dedicated to a project.
Chapter 2 - SDLC 5
Project Identificationand Selection
• Identifying Potential Development Projects
• Classifying and Ranking Projects• Selecting Projects for Development
FIGURE 2 SDLC with project identification and selection
Chapter 2 - SDLC 6
Project Initiation and Planning
Two ActivitiesFormal preliminary investigation of the problem at handPresentation of reasons why system should or should not be developed by the organization
Chapter 2 - SDLC 7
Project Initiation
and Planning
• Project Initiation• Project Planning
FIGURE 3 SDLC with project initiation and planning highlighted
Chapter 2 - SDLC 8
Analysis
Study of current procedures and information systems
Determine requirementsStudy current systemStructure requirements and eliminate redundancies
Generate alternative designsCompare alternativesRecommend best alternative
Chapter 2 - SDLC 9
Analysis
• Requirements Determination• Requirements Structuring• Alternative Generation and
Selection
FIGURE 4 SDLC with analysis phase highlighted
Chapter 2 - SDLC 10
Design
Logical DesignConcentrates on business aspects of the system
Physical DesignTechnical specifications
Chapter 2 - SDLC 11
Design
• Files and Databases• Forms and Reports• Dialogues and Interfaces• System and Program Structure• Distributed Systems
FIGURE 5 SDLC with logical design phase highlighted
Chapter 2 - SDLC 12
Implementation
Hardware and software installationProgrammingUser TrainingDocumentation
Chapter 2 - SDLC 13
Implementation
• Coding• Testing• Installation• Documentation• Training• Support
FIGURE 6 SDLC with the implementation phase highlighted
Chapter 2 - SDLC 14
Maintenance
System changed to reflect changing conditionsSystem obsolescence
Chapter 2 - SDLC 15
Maintenance
• Obtaining Maintenance Requests
• Transforming Requests into Changes
• Designing Changes• Implementing Changes
FIGURE 7 SDLC with maintenance phase highlighted
Chapter 2 - SDLC 16
Project Identificationand Selection
Project Initiation
and Planning
Analysis
Design
Implementation
Maintenance
FIGURE 8 Maintenance phase makes the systems development process a life cycle.
Maintenance
Managing the Information Systems Projectโอฬาริก สุรินตะCS/ICT
Chapter 3 - Managing the Information Systems Project 2
MANAGING THE INFORMATION SYSTEMS PROJECT
Project management is an important aspect of the development of information systems and a critical skill for a system analyst.The focus of project management is to assure that system development projects meet customer expectations and are delivered within budget and time constraints.
Chapter 3 - Managing the Information Systems Project 3
MANAGING THE INFORMATION SYSTEMS PROJECT
The Project manager is a systems analyst with a diverse set of skills – management, leadership, technical, conflict management, and customer relationship.Creating and implementing successful projects require managing resources, activities, and tasks needed to complete the information systems project.
Chapter 3 - Managing the Information Systems Project 4
MANAGING THE INFORMATION SYSTEMS PROJECT
Once a potential project has been identified, and organization must determine the resources required for its completion.After getting this information, the organization can then determine whether taking advantage of an opportunity or solving a particular problem is feasible within time and resource constraints.
Chapter 3 - Managing the Information Systems Project 5
MANAGING THE INFORMATION SYSTEMS PROJECT
As you will see, determining the size, scope, and resource requirements for a project are just a few of the many skills that a project manager must possess.A project manager is often referred to as a juggler keeping aloft many balls, which reflect the various aspects of a project’s development.
Chapter 3 - Managing the Information Systems Project 6
FIGURE 1 A project manager juggles numerous activities
Chapter 3 - Managing the Information Systems Project 7
MANAGING THE INFORMATION SYSTEMS PROJECT
The remainder of this chapter will focus on the project management process, which involves four phases:
Initiating the projectPlanning the projectExecuting the projectClosing down the project
Chapter 3 - Managing the Information Systems Project 8
Initiating a Project
During project initiation the project manager performs several activities that assess the size, scope, and complexity of the project. The types of activities have five project initiation activities.
Chapter 3 - Managing the Information Systems Project 9
Initiating a Project
1. Establishing the project initiation teamThis activity involves organizing an initial core of project team member to assist in accomplishing the project initiation activities.
Chapter 3 - Managing the Information Systems Project 10
Initiating a Project
2. Establishing a Relationship with the Customer
A thorough understanding of your customer builds stronger partnerships and higher levels of trust.Many organizations use a similar mechanism for establishing relationships with customers.
Chapter 3 - Managing the Information Systems Project 11
Initiating a Project
3. Establishing the Project Initiation PlanThis step defines the activities required to organize the initiation team while it is working to define the goals and scope of the project.Their initiation plan included agendas for several meetings. These steps eventually led to the creation of their System Service Request (SSR) form.
Chapter 3 - Managing the Information Systems Project 12
FIGURE 2 System Service Request for Purchasing Fulfillment System with name and contact information of the person requesting the system, a statement of the problem, and the name and contact information of the liaison and sponsor
Chapter 3 - Managing the Information Systems Project 13
Initiating a Project
4. Establishing Management ProceduresSuccessful projects require the development of effective management procedures.Many of these management procedures had been established as standard operating procedures by the System Priority Board and the IS development group.
Chapter 3 - Managing the Information Systems Project 14
Initiating a Project
5. Establishing the Project Management Environment and Project Workbook.
The focus of this activity is to collect and organize the tools that you will use while managing the project and to construct the project workbook.The project workbook can be stored as an on-line electronic document or hard-copy document
Chapter 3 - Managing the Information Systems Project 15
Initiating a Project
Project Workbook: an on-line or hard-copy repository for all project correspondence, inputs, outputs, deliverables, procedures, and standards that is used for performing project audits, orientating new team members, communicating with management and customers, identifying future projects, and performing post project reviews.
Chapter 3 - Managing the Information Systems Project 16
FIGURE 3 The project workbook for the Purchase Fulfillment System project contains nine key documents in both hard-copy and electronic form
Chapter 3 - Managing the Information Systems Project 17
Planning the Project
The next step in the project management process is project planning where prior research has found a positive relationship between effective project planning and positive project outcomes.Project planning involves defining clear, discrete activities and the work needed to complete each activity within a single project.
Chapter 3 - Managing the Information Systems Project 18
Planning the Project
As with the project initiation process, varied and numerous activities must be performed during project planning.The type of activities that you can perform during project planning are described :
Chapter 3 - Managing the Information Systems Project 19
Planning the Project
1. Describing Project Scope, Alternatives, and Feasibility.
The purpose of this activity is to understand the content and complexity of the project.
Chapter 3 - Managing the Information Systems Project 20
Planning the Project
During this activity, you should reach agreement on the following questions:
What problem or opportunity does the project address?What are the quantifiable results to be achieved?What needs to be done?How will success be measured?How will we know when we are finished?
Chapter 3 - Managing the Information Systems Project 21
Planning the Project
2. Dividing the Project into Manageable Tasks.
This is a critical activity during the project planning process.You must divide the entire project into manageable tasks and then logically order them to ensure a smooth evolution between tasks.
Chapter 3 - Managing the Information Systems Project 22
Planning the Project
Gantt chart is a graphical representation of a project that shows each task as a horizontal bar whose length is proportional to its time for completion.Different colors, shades, or shapes can be used to highlight each kind of task.
Chapter 3 - Managing the Information Systems Project 23
Planning the Project
Useful for depicting simple projects or parts of large projectsShow start and completion dates for individual tasks
FIGURE 4 Gantt chart showing project tasks, duration times for those tasks, and predecessors.
Chapter 3 - Managing the Information Systems Project 24
Planning the Project
3. Estimating Resources and Creating a Resource Plan.
The goal of this activity is to estimate resource requirements for each project activity and use this information to create a project resource plan.The resource plan helps assemble and deploy resources in the most effective manner.
Chapter 3 - Managing the Information Systems Project 25
Planning the Project
People are the most important, and expensive, part of project resource planning.Project time estimates for task completion and overall system quality are significantly influenced by the assignment of people to tasks.It is important to give people tasks that allow them to learn new skills.
Chapter 3 - Managing the Information Systems Project 26
Planning the Project
4. Developing a Preliminary Schedule.During this activity, you use the information on tasks and resource availability to assign time estimates to each activity in the work breakdown structure.This time estimates will allow you to create target starting and ending dates for the project.
Chapter 3 - Managing the Information Systems Project 27
Planning the Project
The schedule may be represented as a Gantt chart, or PERT (Program Evaluation Review Technique) diagramPERT diagram is a graphical depiction of project tasks and their interrelationships.
shows dependencies between tasksshows which tasks can be done in parallel
Chapter 3 - Managing the Information Systems Project 28
FIGURE 5 PERT diagram showing activities (represented by circles) and sequence of those activities (represented by arrows).
Chapter 3 - Managing the Information Systems Project 29
Planning the Project
5. Developing a Communication Plan.The goal of this activity is to outline the communication procedures among management, project team members, and the customer.The communication plan includes when and how written and oral reports will be provided by the team, how team members will coordinate work.
Chapter 3 - Managing the Information Systems Project 30
Planning the Project
6. Determining Project Standards and Procedures.
During this activity, you will specify how various deliverables are produced and tested by you and your project team.the team must decide on which tools to use, how the standard SDLC might be modified, how team members will report the status of their assigned activities.
Chapter 3 - Managing the Information Systems Project 31
Planning the Project
7. Identifying and Assessing Risk.The goal of this activity is to identify sources of project risk and to estimate the consequences of those risks.Risks might arise from the use of new technology, prospective users’ resistance to change, availability of critical resources, or team member inexperience with technology or the business area.
Chapter 3 - Managing the Information Systems Project 32
Planning the Project
8. Creating a Preliminary Budget.During this phase, you need to create a preliminary budget that outlines the planned expenses and revenues associated with your project.The project justification will demonstrate that the benefits are worth these costs.
Chapter 3 - Managing the Information Systems Project 33
FIGURE 6 A financial cost and benefit analysis for a systems development project
Chapter 3 - Managing the Information Systems Project 34
Planning the Project
Figure 6 shows a cost-benefit analysis for a new development project.This analysis shows net present value calculations of the project’s benefits and costs as well as a return on investment and cash flow analysis.
Chapter 3 - Managing the Information Systems Project 35
Planning the Project
9. Developing a Statement of Work.An important activity that occurs near the end of the project planning phase is the development of the Statement of Work (SOW).Developed primarily for the customer, this document outlines work that will be done and clearly describes what the project will deliver.
Chapter 3 - Managing the Information Systems Project 36
Planning the Project
The statement of work is useful to make sure that you, the customer, and other project team members have a clear understanding of the intended project size, duration, and outcomes.
Chapter 3 - Managing the Information Systems Project 37
FIGURE 7 Statement of Work
Chapter 3 - Managing the Information Systems Project 38
Planning the Project
10. Setting a Baseline Project Plan.Once all of the prior project planning activities have been completed, you will be able to develop a Baseline Project Plan.This baseline plan provides an estimate of the project’s tasks and resource requirements and is used to guide the next project’s tasks and resource requirements and is used to guide the next project phase-execution.
Chapter 3 - Managing the Information Systems Project 39
FIGURE 8 An outline of Baseline Project Plan contains four major sections: introduction, system description, feasibility assessment, and management issues.
Chapter 3 - Managing the Information Systems Project 40
Executing the Project
Project execution puts the Baseline Project Plan into action. Within the context of the SDLC, project execution occurs primarily during the analysis, design, and implementation phases.These activities are summarized and described in the remainder of this section:
Chapter 3 - Managing the Information Systems Project 41
Executing the Project
1. Executing the Baseline Project Plan.As project manage, you oversee the execution of the baseline plan.This means that you initiate the execution of project activities, acquire and assign resources, orient and train new team members, keep the project on schedule, and assure the quality of project deliverables.
Chapter 3 - Managing the Information Systems Project 42
Executing the Project
2. Monitoring project progress against the Baseline Project Plan.
While you execute the Baseline Project Plan, you should monitor your progress. If the project gets ahead of schedule, you may have to adjust resources, activities, and budgets.
Chapter 3 - Managing the Information Systems Project 43
Executing the Project
Monitoring project activities can result in modifications to the current plan.Measuring the time and effort expended on each activity will help you improve the accuracy of estimations for future projects.
Chapter 3 - Managing the Information Systems Project 44
Executing the Project
3. Managing changes to the Baseline Project Plan.
You will encounter pressure to make changes to the baseline plan.Policies dictate that only approved changes to the project specification can be made and all changes must be reflected in the baseline plan and project workbook, including all charts.
Chapter 3 - Managing the Information Systems Project 45
Executing the Project
4. Maintaining the project workbook.As in all project phases, maintaining complete records of all project events is necessary.The workbook provides the documentation new team members require to assimilate project tasks quickly.
Chapter 3 - Managing the Information Systems Project 46
Executing the Project
5. Communicating the project status.The project manager is responsible for keeping all team members – system developers, managers, and customers.Clear communication is required to create a shared understanding of the activities and goals of the project; such an understanding assures better coordination of activities.
Chapter 3 - Managing the Information Systems Project 47
Closing Down the Project
The focus of project closedown is to bring the project to an end. Projects can conclude with a natural or unnatural termination.A natural termination occurs when the requirements of the project have been met.An unnatural termination occurs when the project is stopped before completion.
Chapter 3 - Managing the Information Systems Project 48
Closing Down the Project
1. Closing down the project.During closedown, you perform several diverse activities.The goal is to celebrate the team’s effort to bring a difficult task to a successful conclusion.
Chapter 3 - Managing the Information Systems Project 49
Closing Down the Project
2. Conducting post project reviews.Once you have closed down the project, final reviews of the project should be conducted with management and customers.The objective of these reviews is to determine the strengths and weaknesses of project deliverables, the processes used to create them, and the project management process.
Chapter 3 - Managing the Information Systems Project 50
Closing Down the Project
3. Closing the customer contract.The focus of this activity is to ensure that all contractual terms of the project have been met.A project governed by a contractual agreement is typically not completed until agreed to by both parties, often in writing.
Chapter 3 - Managing the Information Systems Project 51
Closing Down the Project
Closedown is a very important activity. A project is not complete until it is closed, and it is at closedown that projects are deemed a success or failure.Completion also signifies the chance to begin a new project and apply what you have learned.
Chapter 3 - Managing the Information Systems Project 52
CONSTRCUTING A PERT DIAGRAM1. Identity each activity to be completed in
the project.For example, the project identified the following major activities:
1. Requirements collection 5. User documentation creation2. Screen design 6. Software programming3. Report design 7. System testing4. Database construction 8. System installation
Chapter 3 - Managing the Information Systems Project 53
CONSTRCUTING A PERT DIAGRAM2. Determine time estimates and calculate
the expected completion time for each activity.
Three estimates are used to determine the expected completion time for an activity:
Chapter 3 - Managing the Information Systems Project 54
CONSTRCUTING A PERT DIAGRAM
64 proET ++
=
ET expected time for the completion for an activityo optimistic completion time for an activityr most likely completion time for an activityp pessimistic completion time for an activity
Chapter 3 - Managing the Information Systems Project 55
FIGURE 9 Estimated time calculations for the project.
Chapter 3 - Managing the Information Systems Project 56
CONSTRCUTING A PERT DIAGRAM3. Determine the sequence of the activities
and precedence relationships among all activities by constructing PERT diagram.
This step helps you understand how various activities are related.
Chapter 3 - Managing the Information Systems Project 57
FIGURE 10 Sequence of Activities within the project.
Chapter 3 - Managing the Information Systems Project 58
FIGURE 11 PERT diagram that illustrates the activities (circles) and the sequence (arrows) of those activities.
Chapter 3 - Managing the Information Systems Project 59
CONSTRCUTING A PERT DIAGRAM
Determine the critical pathThe critical path of a PERT diagram is represented by the sequence of connected activities that produce the longest overall time period.All nodes and activities within this sequence are referred to as being “on” the critical path
Chapter 3 - Managing the Information Systems Project 60
CONSTRCUTING A PERT DIAGRAM
the critical path represents the shortest time in which a project can be completed.In other words, any activity on the critical path that is delayed in completion delays the entire project.Critical path: The shortest time in which a project can be completed.
Chapter 3 - Managing the Information Systems Project 61
FIGURE 12 PERT diagram for the project showing estimated times for each activity and the earliest and latest expected completion time for each activity.
Chapter 3 - Managing the Information Systems Project 62
FIGURE 13 Activity slack time calculations for the project; all activities except number 5 are on the critical path
Chapter 3 - Managing the Information Systems Project 63
CONSTRCUTING A PERT DIAGRAM
Figure 13 shows the slack time calculations for all activities of project.All activities with a slack time equal to zero are on the critical path.Thus, all activities except 5 are on the critical path. Part of the diagram in Figure 12 shows two critical paths, between activities 1-2-4 and 1-3-4, because both of these parallel activities have zero slack.
SYSTEM ANALYSIS
โอฬาริก สุรินตะCS/ICT
Chapter 4 - System analysis 2
SYSTEMS ANALYSIS PHASE OVERVIEW
The overall objective is to understand the proposed project, ensure that it will support business requirements, and build a solid foundation for the systems design phase.During systems analysis, you use models and other documentation tools to visualize and describe the proposed system.
Chapter 4 - System analysis 3
SYSTEMS DEVELOPMENT METHODS
The traditional model for systems development was an IT department that used structured analysis and consulted users when their input or approval was needed.Although the IT staff still has a central role and structured analysis remains a common method of systems development.
Chapter 4 - System analysis 4
SYSTEMS DEVELOPMENT METHODS
Joint Application Development (JAD) is a group-oriented technique for fact-finding and requirements modeling.Because it is not linked to a specific development methodology, systems developers use JAD when group input and interaction is desired.
Chapter 4 - System analysis 5
Joint Application Development
JAD is a systems development technique. In a structured analysis process, the IT staff collects information from users and managers and develops the requirements for a new system.The company creates a task force of users, managers, and IT professional that works together to gather information, discuss business needs, and define the new system requirements.
Chapter 4 - System analysis 6
Documents results of JAD sessions and works with systems analysts to build system models and develop CASE tool documentation.
Recorder
Provide technical assistance and resources for JAD team members on issues such as security, backup, hardware, software, and network capability.
Systems analysts and other IT staff members
Provide operational-level input on current operations, desired changes, input and output requirements, user interface issues, and how the project will support day-to-day tasks.
Users
Provide department-level authorization and understand how the project must support business functions and requirements.
Managers
Provides enterprise-level authorization and support for the project.
Top management
Develops and agenda, acts as a facilitator, and leads the JAD session
JAD project leader
RoleJAD ParticipantTypical JAD Participants and Roles
FIGURE 1 Typical JAD participants and roles.
Chapter 4 - System analysis 7
-Review the main business processes, tasks, user roles, input and output- Identify specific areas of agreement of disagreement
Open discussion session, moderated by project leader
- Provide overview of the current system and proposed project scope and constraints- Present outline of specific topics and issues to be investigated
Project leader
- Explain the reason for the project and express top management authorization and support
Top management
- Introduce all JAD Team members- Discuss group rules, goals, and objectives for the JAD sessions- Explain methods of documentation and use of CASE tools, if any
Project leader
Typical JAD Agenda
FIGURE 2 Typical agenda for a JAD session.
Chapter 4 - System analysis 8
Typical JAD Agenda (Continue)
- Present recap of JAD session- Prepare report that will be sent to JAD team members
Project leader
- Review reports from small group sessions- Reach consensus on main issues- Document all topics
Open discussion session, moderated by project leader
- Report on results and assigned tasks and topics- Present issues that should be addressed by the overall JAD team
Group leaders
- Discuss and document all system requirements- Develop models and prototypes
JAD team members working in smaller group sessions, supported by IT staff
FIGURE 2 Typical agenda for a JAD session (cont).
Chapter 4 - System analysis 9
Joint Application Development
A typical JAD session agenda is shown in Figure 2.The JAD process involves intensive effort by all team members.Because of the wide range of input and constant interaction among the participants, many companies believe that a JAD group produces the best possible definition of the new system.
Chapter 4 - System analysis 10
SYSTEM REQUIREMENT
Systems developers must identify and describe all system requirements.A system requirement is a characteristic or feature that must be included in an information system to satisfy business requirements and be acceptable to users.System requirements fall into five general categories:
Chapter 4 - System analysis 11
SYSTEM REQUIREMENT
OutputsThe web site must report online volume statistics every four hours, and hourly during peak periods.The contact management system must generate a daily reminder list for all sales reps.The purchasing system must provide suppliers with up-to-date specifications.
Chapter 4 - System analysis 12
SYSTEM REQUIREMENT
InputsThe department head must enter overtime hours on a separate screen.Student grades must be entered on machine-scannable forms prepared by the instructor.Each input form must include date, time, product code, customer number, and quantity.
Chapter 4 - System analysis 13
SYSTEM REQUIREMENT
ProcessesThe student records system must allow record access by either the student name or the student number.The human resources system must interface properly with the existing payroll system.The video rental system must not execute new rental transactions for customers who have overdue tapes.
Chapter 4 - System analysis 14
SYSTEM REQUIREMENT
PerformanceThe system must support 25 users online simultaneously.Response time must not exceed four seconds.The system must be operational 7 days a week, 365 days a year.
Chapter 4 - System analysis 15
SYSTEM REQUIREMENT
ControlsThe system must provide log-on security at the operating system level and at the application level.The system must maintain separate levels of security for users and the system administrator.The system must create an error log file that includes the error type, description, and time.
Chapter 4 - System analysis 16
INTERVIEWS
Systems analysts spend a great deal of time talking with people, both inside and outside the information technology department.An interview is a planned meeting during which you obtain information from another person.
Chapter 4 - System analysis 17
INTERVIEWS
You must have the skills needed to plan, conduct, and document interviews successfully.The interviewing process consists of these seven steps:
Chapter 4 - System analysis 18
Determine the people to interview
To get an accurate picture of the system, you must select the right people to interview and ask them the right questions.During the preliminary investigation, you talked mainly to middle managers or department heads.Now, during the systems analysis phase, you might need to interview people from all levels of the organization.
Chapter 4 - System analysis 19
Determine the people to interview
Should you interview several people at the same time? Group interviews can save time and provide an opportunity to observe interaction among the participants.Group interviews also can present problems.
Chapter 4 - System analysis 20
Establish objectives for the interview
After deciding on the people to interview, you must establish objectives for the session.First, you should determine the general areas to be discussed, and then list the facts you want to gather.You also should try to solicit ideas, suggestions, and opinions during the interview.
Chapter 4 - System analysis 21
Establish objectives for the interview
The objectives of an interview depend on the role of the person being interviewed.Upper-level managers can provide the big picture and help you to understand the system as a whole.Specific details about operations and business processes are best learned from people who actually work with the system on a daily basis.
Chapter 4 - System analysis 22
Establish objectives for the interview
The interviews focus more on specific topics.Interview objectives also vary at different stages of the investigation.By setting specific objectives, you create a framework that helps you decide what questions to ask and how to phrase the questions.
Chapter 4 - System analysis 23
Develop interview Questions
Creating a standard list of interview questions helps keep you on track and avoid unnecessary tangents.Also, if you interview several people who perform the same job, a standard question list allows you to compare their answers to the same questions.
Chapter 4 - System analysis 24
Develop interview Questions
Although you have a list of specific questions, you might decide to depart from it because an answer to one question leads to another topic that you want to pursue.That question or topic then should be included in a revised set of questions used to conduct future interview.
Chapter 4 - System analysis 25
Develop interview Questions
The interview should consist of several different kinds of question: open-ended, closed-ended, or questions with a range of responses.When you phrase your questions, you should avoid leading questions that suggest or favor a particular reply.
Chapter 4 - System analysis 26
Develop interview Questions
Open-ended questions encourage spontaneous and unstructured responses.Such questions are useful when you want to understand a larger process or draw out the interviewee’s opinions, attitudes, or suggestions.
Chapter 4 - System analysis 27
Develop interview Questions
Closed-ended questions limit or restrict the response.You use closed-ended questions when you want information that is more specific or when you need to verify facts.
Chapter 4 - System analysis 28
Develop interview Questions
Range-of-response questions are closed-ended questions that ask the person to evaluate something by providing limited answers to specific responses or on a numeric scale.
Chapter 4 - System analysis 29
Develop interview Questions
This method makes it easier to tabulate the answers and interpret the results.Range-of-response questions might include these: On a scale of 1 to 10, with 1 the lowest and 10 the highest
Chapter 4 - System analysis 30
Prepare for the interview
After setting the objectives and developing the questions, you must prepare for the interview.Careful preparation is essential because this is an important meeting and just a casual chat.Schedule a specific day and time for the meeting and place a reminder call to confirm the meeting.Remember that the interview is an interruption of the other person’s routine.
Chapter 4 - System analysis 31
Prepare for the interview
Sending a message to each department manager listing your planned appointments is a good way to keep them informed.You should send a list of essential questions to an interviewee several days before the meeting, especially when detailed information is needed, so the person can prepare for the interview and minimize the need for a follow-up meeting.
Chapter 4 - System analysis 32
Conduct the interview
After determining the people to interview, setting your objectives, and preparing the questions, you should develop a specific plan for the meeting.When conducting an interview, you should begin by introducing yourself, describing the project, and explaining your interview objectives.
Chapter 4 - System analysis 33
Conduct the interview
During the interview, ask questions in the order in which you prepared them, and give the interviewee sufficient time to provide thoughtful answers.After asking a question, allow the person enough time to think about the question and arrive at an answer.When you finish asking your questions, summarize the main points covered in the interview and explain the next course of action.
Chapter 4 - System analysis 34
Document the interview
Although taking notes during an interview has both advantages and disadvantages, the accepted view is that note taking should be kept to a minimum.After conducting the interview, you must record the information quickly. You should set aside time right after the meeting to record the fasts and evaluate the information.
Chapter 4 - System analysis 35
Document the interview
After the interview, send a memo to the interviewee expressing your appreciation for his or her time and cooperation.In the memo, you should note the date, time, location, purpose of the interview, and the main points you discussed so the interviewee has a written summary and can offer additions or corrections.
Chapter 4 - System analysis 36
Evaluate the interview
In addition to recording the facts obtained in an interview, try to identify any possible biases.Some interviewees might answer your questions in an attempt to be helpful although they do not have the necessary experience to provide accurate information.
Chapter 4 - System analysis 37
DATA FLOW DIAGRAMS
A data flow diagrams (DFD) shows how data moves through an information system but does not show program logic or processing steps.DFDs represent a logical model that shows whatthe system does, not how it does it.That distinction is important because focusing on implementation issues at this point would restrict your search for the most effective system design.
Chapter 4 - System analysis 38
DFD Symbols
DFDs use four basic symbols that represent processes, data flows, data stores, and external entities.Several different versions of DFD symbols exist, but they all serve the same purpose.This course uses a popular version called the Gane and Sarson symbol set for all of its examples.
Chapter 4 - System analysis 39
DFD Symbols
Chapter 4 - System analysis 40
Process
A process receives input data and produces output that has a different content, form, or both.The process name identifies a specific function and consists of a verb (and an adjective, if necessary) followed by a singular noun.Example of process names are APPLY RENT PAYMENT, CALCULATE COMMISSION, ASSIGN FINAL GRADE, VERIGY ORDER and FILL ORDER.
Chapter 4 - System analysis 41
Data Flow
A data flow is a path for data to move from one part of the information system to another.A data flow in a DFD represents one or more data items.A data flow name consists of a singular nounand an adjective, if needed.Examples of data flow names are DEPOSIT, INVOICE PAYMENT, STUDENT GRADE, ORDER, and COMMISSION
Chapter 4 - System analysis 42
Data Store
A data store is used to represent a situation in which the system must retain data.The DFD does not show the detailed contents of a data store; the specific structure and data elements are defined in the data dictionary.A data store name is a plural name consisting of a noun and adjectives, if needed.Example of data store names are STUDENTS, ACCOUNTS RECEIVABLE, PRODUCTS, DAILY PAYMENTS, and EMPLOYEES.
Chapter 4 - System analysis 43
External Entity
An external entity is a person, department, outside organization or other information system that provides data to the system or receives output from the system.Systems analysts call an external entity that supplies data to the system a source, and external entity that receives data from the system a sink.
Chapter 4 - System analysis 44
External Entity
An external entity might be a source or a sink or both.Examples of external entity names are CUSTOMER, STUDENT, EMPLOYEE, MEMBER SALES REP, WAREHOUSE, ACCOUNTING, BANK, PAYROLL, and SYSTEM.
Chapter 4 - System analysis 45
DFD Rules: Process
A. No process can have only outputs (a miracle)
B. No process can have only inputs (black hole)
C. A process has a verb phrase label (except for context diagram)
Chapter 4 - System analysis 46
DFD Rules: Data Store
D. Data cannot be moved from one store to another.
G. Data store has a noun phrase label
F. Data cannot move directly from a data store to a data sink
E. Data cannot move from an outside source to a data store
Chapter 4 - System analysis 47
Data Flow Diagramming Rules: External Entity
H. Data cannot move directly from a source to a sink
I. A source/sink has a noun phrase label
Chapter 4 - System analysis 48
DFD Rules: Data Flow
J. A data flow has only one direction of flow between symbols.
K. A fork means that exactly the same data go from a common location to two or more processes, data stores or sources/sinks
Chapter 4 - System analysis 49
DFD Rules: Data FlowL. A join means that
exactly the same data come from any two or more different processes, data stores or sources/sinks to a common location
M. A data flow cannot go directly back to the same process it leaves
N. A data flow to a data store means update (delete or change)
O. A data flow from a data store means retrieve or use
P. Data flow has a noun phrase labelChapter 4 - System analysis 50
FIGURE 3 DFD hierarchy.
DFD Level 1
DFD Level 2 for Process 2
DFD Level 3 for Process 2.2
Context Diagram
Chapter 4 - System analysis 51
FIGURE 4 Context Diagram of Hoosier Burger’s food ordering system.
Chapter 4 - System analysis 52
FIGURE 5 DFD Level 1 of Hoosier Burger’s food ordering system.
Chapter 4 - System analysis 53
FIGURE 6 Context Diagram.
Chapter 4 - System analysis 54
FIGURE 7 DFD Level 1.
Chapter 4 - System analysis 55
Information Display (minor/ no precesses)Customer Comments
6.0 Order Status Request Order Status/History
5.0 Add/Modify Account Profile Account Profile
4.0 Check Out Process Order Checkout
3.0 Display Shopping Cart Shopping Cart
1.0 Browser Catalog 2.0 Select Item for Purchase
Product Line (Catalog)
Information Display (minor/ no processes)Main Page
ProcessesWebStore System
Figure 8 System structure of the WebStore and corresponding level 1 processes.Chapter 4 - System analysis 56FIGURE 9 DFD Level 1 for the WebStore.
Chapter 4 - System analysis 57
FIGURE 10 DFD Level 2 for Process 3.0
Chapter 4 - System analysis 58
DATA DICTIONARY
A set of DFD produces a logical model of the system, but the details within those DFD are documented separately in a data dictionary, which is the second component of structured analysis.
Chapter 4 - System analysis 59
FIGURE 11 Content of the data dictionary.
โอฬาริก สุรินตะ CS/MIS: System Analysis in Information System 1 / 7
DATA DICTIONARY FORM: DATA FLOW DESCRIPTION
NAME ___________________ ALIAS ___________________
DESCRIPTION __________________________________________ _______________________________________________________ _______________________________________________________ SOURCE _______________________________________________ DESTINATION __________________________________________
DATA DICTIONARY FORM: DATA STORE DESCRIPTION
ID ______________________ NAME ___________________ ALIAS ___________________
DESCRIPTION __________________________________________ _______________________________________________________ _______________________________________________________ ATTRIBUTES
________________________________________________ ________________________________________________ ________________________________________________ ________________________________________________ ________________________________________________ ________________________________________________
โอฬาริก สุรินตะ CS/MIS: System Analysis in Information System 2 / 7
DATA DICTIONARY FORM: EXTERNAL ENTITY DESCRIPTION
NAME ___________________ ALIAS ___________________
DESCRIPTION __________________________________________ _______________________________________________________ _______________________________________________________ INPUT DATA FLOWS
________________________________________________ ________________________________________________ ________________________________________________ ________________________________________________
OUTPUT DATA FLOWS
________________________________________________ ________________________________________________ ________________________________________________ ________________________________________________
โอฬาริก สุรินตะ CS/MIS: System Analysis in Information System 3 / 7
DATA DICTIONARY FORM: PROCESS DESCRIPTION
ID ______________________ NAME ___________________ ALIAS ___________________
DESCRIPTION __________________________________________ _______________________________________________________ _______________________________________________________ INPUT DATA FLOWS
________________________________________________ ________________________________________________ ________________________________________________ ________________________________________________
OUTPUT DATA FLOWS
________________________________________________ ________________________________________________ ________________________________________________ ________________________________________________
PROCESS DESCRIPTION _______________________________________________________ _______________________________________________________ _______________________________________________________ _______________________________________________________ _______________________________________________________ _______________________________________________________
โอฬาริก สุรินตะ CS/MIS: System Analysis in Information System 4 / 7
DATA DICTIONARY FORM: DATA ELEMENT OF DATA FLOW
DESCRIPTION __________________________________________ _______________________________________________________ _______________________________________________________ ELEMENT CHARACTERISTICS
Type ____________________ Length __________________ Input Format _____________ Output Format ____________
NAME ___________________ ALIAS ___________________
DATA DICTIONARY FORM: DATA ELEMENT OF DATA STORE
DESCRIPTION __________________________________________ _______________________________________________________ _______________________________________________________ ELEMENT CHARACTERISTICS
Type ____________________ Length __________________ Input Format _____________ Output Format ____________
NAME ___________________ ALIAS ___________________
โอฬาริก สุรินตะ CS/MIS: System Analysis in Information System 5 / 7
Data Structure of Data Flow
ในการเขียนอธิบายโครงสรางขอมูล มักจะใชสัญลักษณทางคณิตศาสตรเขาชวย มีดังนี้ = ความหมายคือ ประกอบดวย หรือเทากับ (Definition) + ความหมายคือ และ ( ) ความหมายคือ ขอความในวงเล็บจะมี หรือไมมีก็ได (Optional) { } max
min ความหมายคือ ใหกระทําตามขอมูลในวงเล็บซ้ํา ๆ (Iteration) จากจํานวนต่ําสุดจนถึงสูงสุด [ ] ความหมายคือ ใหเราเลือกขอมูลพื้นฐาน (Data Element) ตัวใดตัวหนึ่งในวงเล็บ (Selection case) *…* ความหมายคือ ขอความตอไปนี้คือคําอธิบาย (Comment) / , : ใชเปนตัวแยกขอมูลที่ใหเลือกใน [ ] (Separator) ซ่ึงจะเลือกใชสัญลักษณตัวไหนก็ไดจากสามตัวนี้ รูปแสดงความสัมพันธระหวาง Data Flow Diagram กับ Data Structure
Data Flow Data Structure
ProduceEmployeePaycheck
5
Employee
D1 Employee Master EmployeeRecord
Employee Paycheck
D2 Employee Timefile
Timefile Record
Employee = Employee Number +Record Personal Information +
Wage Information +Current Pay Information +Year-To-Date Information
Timefile = Employee Number +Record Employee Name +
Hours WorkedEmployee = Employee Number +Paycheck Employee Name +
Address +Current Pay Amounts +Year - To - Date Figures
ComputeCurrent Pay
Amounts
5.3
Hours Worked
WageInformation
Current PayAmounts
Wage = Rate of Pay +Information Number of DependentsCurrent = Gross Pay +Pay Federal Withholding +Amounts State Withholding +
Social Security Withholding +NetPay
โอฬาริก สุรินตะ CS/MIS: System Analysis in Information System 6 / 7
ขอกําหนดอื่น ๆ ในการใชสัญลักษณเพื่อเขียน Data structure เคร่ืองหมายเทากับใชเขียนอธิบายวาขอมูลที่อยูทางซายมือแยกยอยลงไดเปนขอมูลยอย ๆ ทางขวามือ โดยที่เครื่องหมาย “+” หมายถึง “และ” ตัวอยางเชน
ที่อยูผูขาย = ถนน + จังหวัด + รหัสไปรษณีย ซ่ึงหมายความวาที่อยูผูขายประกอบดวยถนน, จังหวัด และรหัสไปรษณีย
เครื่องหมาย “+” ในที่นี้ไมไดหมายถึงการรวมกันทางคณิตศาสตร (2 + 3 = 5) ดังนั้น จํานวนเงินในใบทวงหนี้ = ราคาสินคา + คาขนสง จึงไมใชพจนานุกรมที่ถูกตอง ถึงแมวาการคํานวณจะถูกตองก็ตาม
เคร่ืองหมาย [ ] หมายถึงใหเลือกหนึ่งจากตัวเลือกที่มีมากกวาหนึ่งตัวเลือก เชน ไฟลผูขายอาจจะแกไขโดยการเพิ่มผูขาย หรือลบผูขาย หรือแกไขขอมูลบางฟลด แลวเขียนทับอีกครั้ง ซ่ึงวิธีเขียนใหครอบคลุมทั้ง 3 วิธี อาจจะเขียนอยูในรูปพจนานุกรมขอมูลไดดังนี้
⎥⎥⎥
⎦
⎤
⎢⎢⎢
⎣
⎡
=
เกา-ผูขาย-แกไขเกา-ผูขาย-ลบใหม-ผูขาย-เพิ่ม
ไฟลผูขาย-แกไข-ไหวการเคลื่อน
ส่ิงที่ใหเลือกแตละอันเปนอิสระซ่ึงกันและกัน เชน การลบขอมูลผูขายจากไฟลไมสามารถจะใชแกไขขอมูลผูขายเกา ทั้งนี้เพราะทางเลือกแตละทางนั้นไมเกี่ยวของกัน เคร่ืองหมาย { } หมายถึงการทําซ้ําสําหรับขอมูลตัวหนึ่ง หรือกลุมของขอมูลชุดหนึ่งนอกจากนั้นจะมีขอความกํากับวา “max” และ “min” หมายความวาทําซ้ําจากจํานวนนอยที่สุด (min) ไปถึง จํานวนมากที่สุด (max) คร้ัง ทําไมเราตองเขียนสิ่งซ้ํา ๆ ในพจนานุกรมขอมูล สมมติวาใบทวงหนี้จากเจาหนี้มีรายละเอียดของชื่อ ที่อยูผูขาย จํานวนเงินทั้งหมด และวันชําระเงิน ตามดวยรายละเอียดสินคาที่ส่ังซื้อทั้งหมด รายละเอียดของสินคา 1 อยางใชเนื้อที่หนึ่งบรรทัดถามีสินคาที่ส่ังซื้อประมาณ 20 รายการ ก็จะมีรายละเอียดสินคา 20 บรรทัด หมายความวารายละเอียดของสินคาอยางนอยจะมีหนึ่งรายการ และมากที่สุดไมเกิน 20 รายการ ซ่ึงเราจะเขียนพจนานุกรมไดดังนี้ ใบทวงหนี้ผูขาย = เลขที่ใบสั่งซื้อ + ช่ือผูขาย + ที่อยูผูขาย + จํานวนเงินทั้งหมด + วันชําระเงิน+ { } ะอยางสินคาแตลรายละเอียด20
1 ถาคาต่ําสุด (min) ไมไดเขียนกํากับไวก็หมายความวา จะเริ่มนับตั้งแต 0 และถาคาสูงสุด (max) ไมปรากฏอีกดวยแสดงวาทําซ้ําจํานวนไมจํากัด แตถารายละเอียดขอมูลใน { } ไมมีคาของ “min” และ “max” กํากับอยูเลย แสดงวาทําซ้ํากี่คร้ังก็ได หรือ ไมทําเลยก็ได
โอฬาริก สุรินตะ CS/MIS: System Analysis in Information System 7 / 7
เคร่ืองหมาย ( ) ใชกํากับขอมูลที่อาจจะปรากฏหรือไมก็ได สมมติวา ใบทวงหนี้บางใบบางครั้งตองการกําหนดวันสงของดวย เราอาจจะแกไขพจนานุกรมอันเดิมโดยใชเครื่องหมายวงเล็บมาชวยไดดังนี้ ใบทวงหนี้ผูขาย = เลขที่ใบสั่งซื้อ + ช่ือผูขาย + ที่อยูผูขาย + จํานวนเงินทั้งหมด + วันชําระเงิน+(วันที่สงของ) + { }ะอยางสินคาแตลรายละเอียด20
1 ถาเราตองการเขียนคําอธิบายบางอยางอาจจะเขียนเปนขอคิดเห็น โดยใสไวในเคร่ืองหมาย *...*สมมติวาใบทวงหนี้แตละใบจากผูขาย เราไดสําเนาอยางนอย 2 ฉบับ เราอาจจะเขียนกํากับไวภายในเครื่องหมาย *...* ดังนี้ ใบทวงหนี้ผูขาย = เลขที่ใบสั่งซื้อ + ช่ือผูขาย + ที่อยูผูขาย + จํานวนเงินทั้งหมด + วันชําระเงนิ + (วันที่สงของ) + { }ะอยางสินคาแตลรายละเอียด20
1 *ไดรับสําเนาใบทวงหนี้แตละใบอยางนอย 2 ฉบับ*
Data Structure of Data Store
การเก็บขอมูลในที่นี้ไมไดเฉพาะเจาะจงถึงไฟลในคอมพิวเตอรเทานั้น แตรวมถึงเอกสารที่เก็บในแฟม หรือในสมุดก็ได ปกติแหลงเก็บขอมูลจะเก็บขอมูลหลายตัวดวยกัน เชนไฟลผูขาย ประกอบดวยเรคอรดหลาย ๆ เรคอรด ซ่ึงแตละเรคอรดประกอบดวยเลขที่ผูขาย ช่ือ ที่อยู และเบอรโทรศัพท ดังนั้นเรานิยามไฟลตามสวนประกอบนั้น ซ่ึงแตละตัวก็ถูกใชและมีการเคลื่อนไหวในระบบ ในการเขียนอธิบายโครงสรางขอมูลของ Data Store ก็ใชสัญลักษณเหมือนกันกับการเขียนอธิบายโครงสรางขอมูลของ Data flow ซ่ึงไฟลอาจจะเขียนไดดังนี้ ไฟลผูขาย = {เรคอรดผูขาย} เรคอรดผูขาย = เลขที่ผูขาย+ช่ือผูขาย+ที่อยูผูขาย+เบอรโทรศัพทผูขาย
โอฬาริก สุรินตะ CS/MIS: System Analysis in Information System 1 / 5
คําอธิบายการประมวลผล (Process Description)
Process Description หรือเรียกอีกอยางหนึ่งวา “Mini-Specification” ใชสําหรับอธิบายรายละเอียดการทํางานภายใน process เพื่อใหเห็นถึงการเปลี่ยนแปลงจาก Input ไปสู Output วิธีการประมวลผลที่จะกลาวถึงมีอยูดวยกนั 3 วิธีคือ
1. ประโยคโครงสราง (Structure Sentences) เปนประโยคทีใ่ชภาษาปกติในการเขียน แตมีลักษณะเปนโครงสรางคลาย ๆ การเขียน
โปรแกรมโครงสราง (Structure Programming) เพื่อใชสําหรับอธิบายถึงการทํางาน และความสัมพันธระหวางเงื่อนไขที่ใชในการตัดสินใจ การเขียนประโยคโครงสรางสามารถใชคําศัพทตาง ๆ กันซึ่งจะใช คาํกริยา ที่เมื่อทําแลวมีความหมายวาไดผลลัพธบางอยางออกมา เชน “คํานวณ” หรือ “เปรียบเทียบ” ซ่ึงคํากริยาที่อาจเลือกใช มีดังนี ้
GET COMPUTE PUT DELETE FIND VALIDATE ADD MOVE SUBTRACT REPLACE MULTIPLY SET DIVIDE SORT เปนตน
ซ่ึงลักษณะโครงสรางของประโยคสามารถแบงออกไดดังนี ้1.1 โครงสรางแบบตามลําดบั (Sequential Structures) โครงสรางแบบนี้คําสั่งหรือ
ขั้นตอนการทาํงานจะเรียงลําดับกันไปทีละคําสั่งหรือขั้นตอน โดยการทํางานกอนหลังจะเรยีงลําดับจากบนลงลาง
ตัวอยาง การรับสมัครงาน มีขั้นตอน 3 ขั้นตอนตามลําดบัดังนี ้ขั้นตอน 1 รับใบสมัคร ขั้นตอน 2 ตรวจสอบหลักฐานการสมัคร ขั้นตอน 3 จัดเก็บเอกสารการสมัคร
1.2 โครงสรางแบบการตัดสินใจ (Decision Structures) โครงสรางแบบนี้จะมีเงื่อนไขที่ตองตัดสินใจในการดําเนินงานคาํสั่งหรือขั้นตอนตอไป โดยใชคําในการกําหนดเงื่อนไข เชน ถา....มิฉะนั้น / If…Else หรือ กรณี / Case
ตัวอยาง การลดยอดชําระเงนิซื้อสินคา ถา ชําระดวยเงินสด กรณี ยอดเงิน >= 20000 ลด 15 %
โอฬาริก สุรินตะ CS/MIS: System Analysis in Information System 2 / 5
กรณี 10000 =< ยอดเงิน < 20000 ลด 10 %
กรณี 5000 =< ยอดเงิน < 10000 ลด 5 %
กรณี ยอดเงิน < 5000 ไมมีสวนลด มิฉะนั้น ไมมสีวนลด
1.3 โครงสรางแบบทําซ้ํา (Iteration Structures) โครงสรางแบบนี้จะมีการดําเนินงานคําสั่งหรือขั้นตอนเดิมซ้ํากันหลาย ๆ รอบ โดยอาศัยคําในการทําซ้ํา เชน ทําซ้ํา…..จนกระทั้ง / Do……Loop ตัวอยาง การรับสมัครงาน ทําซ้ํา
ขั้นตอน 1 รับใบสมัคร ขั้นตอน 2 ตรวจสอบหลักฐานการสมัคร ขั้นตอน 3 ถา เอกสารครบถวน แลว จัดเก็บเอกสารการสมัคร
มิฉะนั้น ใหไปนําหลักฐานมาใหครบ จนกระทั้ง หมดเวลารับสมัคร ขั้นตอน 4 จัดเก็บเอกสารการสมัคร
2. การตัดสินใจแบบตาราง (Decision Tables) การตัดสินใจแบบตารางจะอยูในลักษณะ 2 มิติ ประกอบดวย แถว (เงื่อนไข) และคอลัมน
(การตัดสินใจ) ตัวอยาง
สมมติวาบริษัทของเราจํากัดเปนบริษัทประกอบเครื่องคอมพิวเตอรขาย ซ่ึงจะตองสั่งซื้อวัสดุและครุภัณฑจากหลาย ๆ บริษัทที่เปนผูจําหนายวัสดุ-ครุภัณฑเหลานั้น (Vendor) เมื่อเราไดรับสินคาแลวบริษัทผูขายจะสงใบทวงหนี้ (Invoice) เพื่อขอรับเงินจากเรา กอนที่เราจะจายเงินสําหรับใบทวงหนี้ที่ถูกตอง จะตองไดรับการอนุมัติการจายเงินเสียกอน ซ่ึงการอนุมัติจะขึ้นกับจํานวนเงินในใบทวงหนี้ ถาจํานวนเงินนอยกวา 25,000 บาท สั่งจายเงินไดทันที ถาอยูระหวาง 25,000 บาท และ 250,000 และมีสวนลด หรือใบทวงหนี้คางมากกวา 10 วันแลว ใหจายเงินไดทันทีเหมือนกัน ถาใบทวงหนี้อันใดไมเปนไปตามเงื่อนไขท้ัง 2 ขอ ใหลองใหมอีกคร้ังในวันถัดไป ถาใบทวงหนี้มีมูลคามากกวา 250,000 บาท จะตองพิมพรายงานเพื่อเตรียมเงินสด (Cash Requirement Report) และ
โอฬาริก สุรินตะ CS/MIS: System Analysis in Information System 3 / 5
สงไปยังผูบริหารเพื่อรอการอนุมัติ เมื่อผูบริหารอนุมัติแลว จะถูกสงกลับมายังฝายบัญชีเจาหนี้ทันที เพื่อรอการจายเงินตอไป ตารางที่ 1 ตัวอยางเงื่อนไขตารางตัดสินใจของการทวงหนี้
เงื่อนไข คาท่ีเปนไปได 1. จํานวนเงินในใบทวงหนี ้ a. นอยกวา 25000
b. ระหวาง 25000 ถึง 250000 c. มากกวา 250000
2. วันคางจาย a. นอยกวาหรือเทากับ 10 วนั b. มากกวา 10 วัน
3. สวนลดถาจายเรว็ a. มี b. ไมมี
จากตารางที่ 1 เราจะนํา คาท่ีเปนไปได ของแตละเงื่อนไขมาคํานวณเพื่อสรางตารางการตัดสินใจ (3x2x2 = 12) และใหบวกเพิ่มอกีดานละ 1 ชอง จากตัวอยางเราจะไดตารางการตัดสินใจดังตารางที่ 2 ตารางที่ 2 ตารางการตัดสินใจของการทางหนี ้ 1 2 3 4 5 6 7 8 9 10 11 12 จํานวนเงินในใบทวงหนี ้ จํานวนวนัคางจาย สวนลด
เมื่อไดตารางที ่2 จากนั้นใหนําคาที่เปนไปไดทั้งหมดหารดวยคาที่เปนไปไดของเงื่อนไขที่หนึ่ง ดังนั้น
เงื่อนไขแรก จาํนวนเงินในใบทวงหนี้ ผลลัพธเทากับ (12/3 = 4) 4 เงื่อนไขท่ีสอง นําผลลัพธจากเงื่อนไขแรกหารดวยคาที่เปนไปไดของเงือ่นไขที่สอง จํานวน
วันคางจาย (4/2 = 2) ผลลัพธเทากับ 2 เงื่อนไขท่ีสาม นําผลลัพธจากเงื่อนไขที่สองหารดวยคาที่เปนไปไดของเงื่อนไขที่สาม
สวนลด (2/2 = 1) ผลลัพธเทากับ 1
คาที่เปนไปได
เงื่อนไข
โอฬาริก สุรินตะ CS/MIS: System Analysis in Information System 4 / 5
1 2 3 4 5 6 7 8 9 10 11 12 จํานวนเงินในใบทวงหนี้
< 25000
< 25000
< 25000
< 25000
25000 -
250000
25000 -
250000
25000 -
250000
25000 -
250000
> 250000
> 250000
> 250000
> 250000
จํานวนวันคางจาย
<= 10 <= 10 > 10 > 10 <= 10 <= 10 > 10 > 10 <= 10 <= 10 > 10 > 10
สวนลด Y N Y N Y N Y N Y N Y N
จากนั้น มาถึงขั้นตอนการตดัสินใจ ใหเพิม่ทางเลือกในการตัดสินใจทีเ่ปนไปได ในกรณีนี้ ไดกําหนดไวใหมี 3 ทางเลือกคือ จายเงนิไดทันที, เก็บใบทวงหนีไ้ว หรือพิมพรายงานเพื่อเตรียมเงนิสด 1 2 3 4 5 6 7 8 9 10 11 12 จํานวนเงินในใบทวงหนี้
< 25000
< 25000
< 25000
< 25000
25000 -
250000
25000 -
250000
25000 -
250000
25000 -
250000
> 250000
> 250000
> 250000
> 250000
จํานวนวันคางจาย
<= 10 <= 10 > 10 > 10 <= 10 <= 10 > 10 > 10 <= 10 <= 10 > 10 > 10
สวนลด Y N Y N Y N Y N Y N Y N
จายเงิน x x x x x x x
เก็บไว x
พิมพรายงาน
x x x x
ตัดสินใจ A A A A A S A A P P P P
A = จายเงิน S = เก็บใบทวงหนี้ไวรอการตัดสินใจ P = พิมพรายงานเพื่อเตรียมเงินสด
โอฬาริก สุรินตะ CS/MIS: System Analysis in Information System 5 / 5
ขั้นตอนสุดทายของการสรางตารางตัดสินใจ คือทําใหตารางมีความกะทัดรัด 1 2 3 4 5 จํานวนเงินในใบทวงหนี ้
< 25000 25000 – 250000
25000 – 250000
25000 – 250000
> 250000
วันคางจาย - <= 10 <= 10 > 10 - สวนลด - Y N - -
ตัดสินใจ A A S A P
3. การตัดสินใจแบบตนไม (Decision Trees) เปนแผนภาพที่แสดงความสัมพันธระหวางเงื่อนไข และลําดับของการกระทําในแตละเงื่อนไข (จากซายไปขวา) เร่ิมจากราก (node) ซ่ึงเปนจดุเริ่มตนของการตัดสินใจ และมีกิ่งกานสาขาแตกเปนเงื่อนไขหรือการกระทําไปเรื่อย ๆ เหมือนตนไม ปลายสุดของกิ่งกานสาขาจะเปนการกระทํา ซ่ึงจะขึ้นอยูกับผลที่ไดจากการตรวจสอบเงื่อนไข สัญลักษณรูปวงกลมหมายถึงเงื่อนไข รูปสี่เหล่ียมหมายถึงการกระทําที่จะเกดิขึ้นตามเงื่อนไขนั้น ๆ และหมายเลขกํากบัสัญลักษณทาํใหเห็นถึงลําดับของการดําเนินการ
ภาพประกอบ 1 สวนประกอบของ Decision Tree
2
15
6
3
4
8
7
เงื่อนไข 1
เงื่อนไข 2
เงื่อนไข 3
เงื่อนไข 4
เงื่อนไข 5
เงื่อนไข 6
การกระทํา 1
การกระทํา 4
การกระทํา 3
การกระทํา 5
การกระทํา 2
เงินสด
บัตรเครดิต วงเงิน < 10000
วงเงิน >= 20000
ชําระเต็ม
ลด 15 %
ลด 10 %
ลด 5 % 1
3
9
2
4วงเงิน < 20000 วงเงิน >= 10000 5
7 6
8
วงเงิน >= 5000
ชําระเต็ม วงเงิน < 5000
ภาพประกอบ 2 Decision Tree สําหรับการลดยอดชําระเงนิซื้อสินคา
System Design
โอฬาริก สุรินตะCS/ICT
Chapter 5 - System Design 2
SYSTEM DESIGN PHASE OVERVIEW
User interface, input, and output design begins the systems design phase of the SDLC.This chapter begins with user interface design concepts, including functions, layout, and usability.
Chapter 5 - System Design 3
SYSTEM DESIGN PHASE OVERVIEW
Today, the main focus is on users within and outside the company, How they communicate with the information system,And how the system supports the firm’s business operations.
Chapter 5 - System Design 4
SYSTEM DESIGN PHASE OVERVIEW
FIGURE 1 Model of a traditional, processing-centered information system.
FIGURE 2 Model of a modem, user-centered information system.
Chapter 5 - System Design 5
USER INTERFACE DESIGN
User interface design requires an understanding of human-computer interaction and user-centered design principles.
Chapter 5 - System Design 6
Human-Computer Interaction
A user interface is based on basic principles of human-computer interaction.Human-computer interaction (HCI) describes the relationship between computers and people who use them to perform business-related tasks.HCI concepts apply to every thing from a PC to the main menu for a global network.
Chapter 5 - System Design 7
User-Centered Design Principle
Understand the underlying business functionMaximize graphical effectiveness
A graphical user interface (GUI) uses graphical objects and techniques that allow users to communicate with the system.
Profile the system’s users
Chapter 5 - System Design 8
User-Centered Design Principle
Think like a userUse prototypingDesign a comprehensive interfaceContinue the feedback processDocument the interface design
Chapter 5 - System Design 9
User Interface Design Guidelines
Good user interface design is based on a combination of ergonomics, aesthetics, and interface technology.Ergonomics describes how people work, learn, and interact with computers;Aesthetics focuses on how an interface can be made attractive and easy to use;Interface technology provides the operational structure required to carry out the design objectives.
Chapter 5 - System Design 10
User Interface Design Guidelines
Build an interface that is easy to learn and use
Label clearly all controls, buttons, and icons.Select only those images that users can understand easily.Provide on-screen instructions that are logical, concise, and clear.
Chapter 5 - System Design 11
User Interface Design Guidelines
Show all commands in a list of menu items.Make it easy to return to one or more levels in the menu structure.
FIGURE 3 In the example shown, only one of the control buttons has an obvious meaning.
FIGURE 4 The top message is hard to understand. Notice that the bottom message is clear.
Chapter 5 - System Design 12
User Interface Design Guidelines
Provide features that promote efficiencyOrganize tasks, commands and functions in groups that resemble actual business operation.Create alphabetical menu lists or place the selections used frequently at the top of the menu list.Provide shortcuts so experienced users can avoid multiple menu levels.
Chapter 5 - System Design 13
User Interface Design Guidelines
Use default values if the majority of values in a field are the same.Provide a fast-find feature that displays a list of possible values.Use a natural language feature that allow users to type commands or requests in normal English phrases.
Chapter 5 - System Design 14
FIGURE 5 Tasks, commands, and functions should be organized in logical group.
Chapter 5 - System Design 15
User Interface Design Guidelines
Make it easy for users to obtain help or correct errors
Ensure that HELP is always available.Provide user-selected Help and context-sensitive HELP.
FIGURE 7 The main Help screen.
FIGURE 6 A context-sensitive Help screen.
Chapter 5 - System Design 16
User Interface Design Guidelines
Provide a direct route for users to return to the point from where Help was requested.Include contact information, such as a telephone or e-mail.Require user confirmation before data deletion and provide a method of recovering data that is deleted inadvertently.Provide an Undo key.
Chapter 5 - System Design 17
User Interface Design Guidelines
Minimize input data problemsProvide data validation checks.Display event-driven messages and reminder.Establish a list of predefined values that users can click to select.Build in rules that enforce data integrity.Use Input masks.
Chapter 5 - System Design 18
User Interface Design Guidelines
Provide feedback to usersDisplay messages at a logical place on the screen.Alert users to lengthy processing times or delays.Allow messages to remain on the screen long enough for users to read them.
Chapter 5 - System Design 19
User Interface Design Guidelines
Let the user know whether the task or operation was successful or not.Provide a text explanation if you use an icon or image on a control button.Use messages that are specific, understandable, and professional.
Chapter 5 - System Design 20
User Interface Design Guidelines
Create an attractive layout and designUse appropriate colors to highlight different areas of the screen.Use special effects sparingly.Use hyperlinks that allow users to jump to related topics.Group related objects and information.Screen density is important.
Chapter 5 - System Design 21
User Interface Design Guidelines
Display titles, messages, and instructions.Use consistent terminology.Ensure that commands will always have the same effect.Ensure that similar mouse actions will produce the same results throughout the application.Require the user to confirm data entry.
Chapter 5 - System Design 22
User Interface Design Guidelines
Use familiar terms and imagesRemember that users are accustomed to a pattern.Provide a keystroke alternative for each menu command, with easy-to-remember letters.Use familiar commands if possible.Avoid complex terms and technical.
Chapter 5 - System Design 23
User Interface Controls
Menu barToolbarDialog boxText boxToggle buttonList boxEtc.
FIGURE 8 A data screen. This screen uses several design features.
Chapter 5 - System Design 24
INPUT DESIGN
Input technology has changed dramatically in recent years.During input design, you determine how data will be captured and entered into the system.Input design has six main objectives:
Chapter 5 - System Design 25
FIGURE 9 Common types of input devices.
Chapter 5 - System Design 26
INPUT DESIGN
Input design has six main objectives:To select a suitable input and data entry methodTo reduce input volumeTo design attractive data entry screensTo use validation checks to reduce input errorTo design required source documentsTo develop effective input controls
Chapter 5 - System Design 27
Input and Data Entry Methods
BATCH INPUT data entry is performed on a specified time schedule, such as daily, weekly, monthly, or longer.Batch input occurs when a payroll department collects time cards at the end of the week and enters the data as a batch
Chapter 5 - System Design 28
Input and Data Entry Methods
ONLINE INPUT the online method offers major advantages, including the immediate validation and availability of data.Source data automation
Automatic teller machines (ATM)Libraries that use handheld bar code scanner to read the code on books.
Chapter 5 - System Design 29
Input Volume
To reduce input volume, you must reduce the number of data items required for each transaction.
Input necessary data only.Do not input data that the user can retrieve from system file or calculate from other data.Do not input constant data.Use codes.
Chapter 5 - System Design 30
FIGURE 10 In this data screen for customer orders.
Chapter 5 - System Design 31
Designing Data Entry Screens
Restrict user access to screen locations where data is entered.Provide a descriptive caption for every field.Display a sample format.Require an ending keystroke for every field.
Chapter 5 - System Design 32
Designing Data Entry Screens
Use a default value when a field value will be constant for successive records or through out the data entry session.Display a list of acceptable values for fields.Allow users to add, change, delete, and view records.Provide a method to allow users to search for specific information.
Chapter 5 - System Design 33
Input Errors
Reducing the number of input errors improves data quality.You can design at least eight types of data validation checks into the input process
Sequence checksExistence checksData type checks
Chapter 5 - System Design 34
Input Errors
Range checksReasonableness checksValidity checksCombination checksBatch controls
Chapter 5 - System Design 35
Source Documents
A source documents is a form used to request and collect input data, trigger or authorize and input action, and provide a record of the original transaction.
Chapter 5 - System Design 36
FIGURE 11 Example of caption techniques for source documents.
Chapter 5 - System Design 37
FIGURE 12 Source document zones.
Chapter 5 - System Design 38
Source Documents
Information should flow left to right and top to bottomLayout and design also is important on Web-based forms
FIGURE 13 Source document for a video club membership application.
Chapter 5 - System Design 39FIGURE 14 Paper-based FIGURE 15 Web-based
Chapter 5 - System Design 40
Input Control
Input control includes the necessary measures to ensure that input data is correct, complete, and secure.You must focus on input control during every phase of input design, starting with source documents that promote data accuracy and quality.
Chapter 5 - System Design 41
OUTPUT DESGIN
Before designing output, ask yourself several questions:
What is the purpose of the output?Who wants the information, why it is it needed, and how will it be used?What specific information will be included?
Chapter 5 - System Design 42
OUTPUT DESGIN
Will the output be printed, viewed on-screen, or both?When will the information be provided, and how often must it be updated?Do security or confidentiality issues exist?
Chapter 5 - System Design 43
Type of Output
Although most system output is printed in reports or displayed on screens.The change especially is true in business information systems that require significant user interaction.
Chapter 5 - System Design 44
FIGURE 16 Common information delivery methods.
Chapter 5 - System Design 45
Printed Output
Printed reports are convenient and sometimes necessaryUsed as turnaround documents
Output documents that are later entered back into the same or another information system
Printed output is highly visibleShould be attractive, professional, and easy to use
Chapter 5 - System Design 46
Types of Reports
Detail reports produces one or more lines of output for each record processed. Each line of output printed is called a detail line
FIGURE 17 A detail report, with one printed line per employee.
Chapter 5 - System Design 47
Types of Reports
Control break report usually causes specific actions, such as printing subtotals for a group of records.To produce a control break report, the records must be arranged, or sorted, in control field order.The sorting can be done by the report program itself.
Chapter 5 - System Design 48
FIGURE 18 Control breaks are used to separate the data for each shop, with subtotals and grand totals for numeric fields.
Chapter 5 - System Design 49
Types of Reports
Exception report displays only those records that meet a specific condition or conditions.Exception reports are useful when the user wants information only on records that might require action, but does not need to know the details.
Chapter 5 - System Design 50
FIGURE 19 An exception report that shows information only for the employees who worked overtime.
Chapter 5 - System Design 51
Types of Reports
Summary reports upper-level managers often want to see total figures and do not need supporting details.
FIGURE 20 A summary report lists subtotals and grand totals.
Chapter 5 - System Design 52
Report Design Principles
Printed reports must be attractive, professional, and easy to read.Good report design, like any other aspect of the user interface,Requires effort and attention to detail.
Chapter 5 - System Design 53
Report Design Principles
Report headers and footersThe report headers, which appears at the beginning of the report, identifies the report, and contains the report title, date, and other necessary information.The report footers, which appears at the end of the report, can include grand totals and other end-of-report information
Chapter 5 - System Design 54FIGURE 21 The Employee Hours report is a detail report with control breaks.
Chapter 5 - System Design 55
Report Design Principles
Page headers and footersA page header, which appears at the top of the page that includes the column headings that identify the data. The headings should be short but descriptive.A page footer, which appears at the bottom of the page, is used to display the name of the report and the page number.
Chapter 5 - System Design 56
Report Design Principles
Column heading alignmentColumn spacing you should space columns of information carefully.Field order fields should be displayed and grouped in a logical order. Grouping detail lines it is meaningful to arrange detail lines in groups, based on a control field.
Chapter 5 - System Design 57
FIGURE 22 The report analysis form for the Employee Hours report shown in Figure 21
System Design -Cont
โอฬาริก สุรินตะCS/ICT
Chapter 5 - System Design - Cont 2
DATA DESIGN CONCEPTS
Before constructing an information system, a systems analyst must understand basic data design concepts.Data design concepts Including how data is structured and the characteristics of file-oriented and database systems.
Chapter 5 - System Design - Cont 3
Data Structure
A file contains data about people, places, things, or events that interact with the information system.A database consists of linked data files, also call tables, that form an overall data structure.
Chapter 5 - System Design - Cont 4
Data Structure
A database management system (DBMS) is a collection of tools, features, and interfaces that enables users to add, update, manage, access, and analyze data in a database.
Chapter 5 - System Design - Cont 5
FIGURE 2 A database design for the auto repair shop links the two data files and avoids duplication.
FIGURE 1 An auto repair shop maintains a JOB data file for its Work Records system and a MECHANIC data file for its Employee Records system.
Chapter 5 - System Design - Cont 6
Overview of File Processing
Some systems use file processing to handle large volumes of structured data on a regular basic.Many older systems utilized file-processing designs because that approach was well suited to mainframe hardware and batch input.
Chapter 5 - System Design - Cont 7
Overview of File Processing
Fill processing can be more efficient and cost less than a DBMS is certain situations.For example, consider a credit card company that posts thousands of daily transactions form a TRANSACTION file to customer balances stored in a CUSTOMER file, as shown in figure 3.For that relatively simple process, file processing is highly effective.
Chapter 5 - System Design - Cont 8
Customer No
Date
Charge/Payment Code
Amount
TRANSACTION FILE
Customer No
Customer Name
Address
Other data…
Balance Due
CUSTOMER FILE
FIGURE 3 A credit card company might use a file processing system to post daily sales transactions from a TRANSACTION file to the CUSTOMER file.
Chapter 5 - System Design - Cont 9
Overview of File Processing
Several potential problems exist in a file-processing environment.
Data redundancy – which means that data common to two or more information systems is stored in several places.Data redundancy requires more storage space, and maintaining and updating data in several locations is expensive.
Chapter 5 - System Design - Cont 10
Overview of File Processing
Data integrity problems can occur if updates are not applied in every file.Changing the data in only one of the systems will cause inconsistent data and result in incorrect information in the second system.
Chapter 5 - System Design - Cont 11
Overview of File Processing
Rigid data structure of a typical file-processing environment.Businesses must make decisions based on company-wide data, and managers often require information from multiple business units and departments.In a file-processing environment, that means retrieving information from independent, file-based systems, which is slow and inefficient.
Chapter 5 - System Design - Cont 12
Overview of File Processing
a file-oriented information system uses various types of files, includingMASTER FILES stores relatively permanent data about an entity.For example, a PRODUCT master file contains one logical record for each product the company sells.
Chapter 5 - System Design - Cont 13
Overview of File Processing
The quantity-on-hand field in each record might change daily, but the number of file records does not change unless the company adds a new product or discontinues and old one.Master files might include data for customers, sales representatives, students employees, or patients.
Chapter 5 - System Design - Cont 14
Overview of File Processing
TABLE FILES contains reference data used by the information system. As with master files, table files are relatively permanent and are not updated by the information system.Examples of table files include tax tables and postage rate tables.
Chapter 5 - System Design - Cont 15
Overview of File Processing
TRANSACTION FILES stores records that contain day-to-day business and operational data.A transaction files is an input file that updates a master file.Transaction file are temporary files.An example of a transaction file is a charges and payments file that updates a customer balance file.
Chapter 5 - System Design - Cont 16
Overview of File Processing
WORK FILES is a temporary file created by an information system for a single task.Most often a work file is created by one process in the information system and used by another process within the same system.
Chapter 5 - System Design - Cont 17
Overview of File Processing
Work files can contain copies of master files records or various other records that are needed temporarily.An example of work files include sorted files and report files that hold output reports until they are printed.
Chapter 5 - System Design - Cont 18
Overview of File Processing
SECURITY FILES is created and saved for backup and recovery purposes.Examples of security files include audit trail files and backups of master, table, and transaction files.New security files must be created regularly to replaced outdated files.
Chapter 5 - System Design - Cont 19
Overview of File Processing
HISTORY FILES is a file copy created and saved for historical or archiving purposes.New history files, unlike new security files, do not replace the old files.In some cases, inactive master file records are deleted periodically and added to a special history file.
Chapter 5 - System Design - Cont 20
Overview of Database Systems
A properly designed database offers a solution to the problems of file processing.A database provides an overall framework that avoids data redundancy and supports a real-time, dynamic environment.In a file-processing environment, data files are designed to fit individual business systems.In a database environment, several systems can be built around a single database.
Chapter 5 - System Design - Cont 21
FIGURE 4 A typical database environment might consist of a database serving five separate business systems.
Chapter 5 - System Design - Cont 22
Overview of Database Systems
Specific DBMS advantages include the following.Scalability. means that a system can be expanded, modified, or downsized easily to meet the rapidly changing needs of a business enterprise.Better support for client/server systems. processing is distributed throughout the organization. Client/server systems require the power and flexibility of a database design.
Chapter 5 - System Design - Cont 23
Overview of Database Systems
Economy of scale. database designs allows better utilization of hardware. Sharing of data. data can be shared across the enterprise, allowing more users to access more data.Balancing conflicting requirements. DBMS is managed by a person called a database administrator (DBA), who assesses overall requirements and maintains the database for the benefit of the entire organization rather than a single department or user.
Chapter 5 - System Design - Cont 24
Overview of Database Systems
Enforcement of standards. Effective database administration ensures that standards for data names, formats, and documentation are followed uniformly throughout the organization.Controlled redundancy. Because the data is stored in a single database, data items do not need to be duplicated in separate files for various systems.
Chapter 5 - System Design - Cont 25
Overview of Database Systems
Security. The DBA can define authorization procedures to ensure that only legitimate users can access the database and can allow different users to have different levels of access.Increased programmer productivity. A new database application can be developed more quickly than a file-oriented system.Data independence. Systems that interact with a DBMS are relatively independent of how the physical data is maintained.
Chapter 5 - System Design - Cont 26
DBMS Components
A DBMS provides an interface between a database and users who need to access the data.A DBMS also has a data manipulation language, a schema, and physical data repository.
Chapter 5 - System Design - Cont 27
FIGURE 5 In addition to interfaces for users, database administrators, and related information systems.
Chapter 5 - System Design - Cont 28
DBMS Components
Interfaces for users.Users typically work with predefined queries and switchboard commands, but also use query languages to access stored data.A query language allows a user to specify a task without specifying how the task will be accomplished.
Chapter 5 - System Design - Cont 29
DBMS Components
Some query languages use natural language commands that resemble ordinary English sentences. With a query-by-example (QBE)language.Many database programs also generate SQL (Structured Query Language), which is a query language that allows PC users to communicate with servers and mainframe computers.
Chapter 5 - System Design - Cont 30
FIGURE 6 Using QBE, a user can request a list of all data. The QBE request generates the SQL commands shown
Chapter 5 - System Design - Cont 31
DBMS Components
Database administrators.A DBA is responsible for DBMS management and support. DBAs are concerned with data security and integrity, preventing unauthorized access, providing backup and recovery, audit trails, maintaining the database, and supporting user needs.
Chapter 5 - System Design - Cont 32
DBMS Components
Related information systems.A DBMS might support several related information systems that provide input to, and require specific data from, the DBMS.
Chapter 5 - System Design - Cont 33
DBMS Components
Data manipulation language.A data manipulation language (DML) controls database operations, including storing, retrieving, updating, and deleting data.Most commercial DBMSs, such as Oracle and IBM’s DB/2 use a DMLSome database products, such as Microsoft Access, also provide an easy-to-use graphical environment that enables users to control operations with menu-driven commands
Chapter 5 - System Design - Cont 34
DBMS Components
Schema.The complete definition of a database, including descriptions of all fields, records, and relationships, is called a schema.You also can define one or more subschemas. A subschema is a view of the database used by one or more systems or users.
Chapter 5 - System Design - Cont 35
DBMS Components
Physical data repository.In chapter 4, you learned about a data dictionary, which describes all data elements included in the logical design. At this stage of the systems development process, the data dictionary is transformed into a physical data repository, which also contains the schema and subschemas.
Chapter 5 - System Design - Cont 36
Definitions
FIGURE 7 A file or table for an entity named CUSTOMER includes records, fields, and a primary key.
Chapter 5 - System Design - Cont 37
Definitions
ENTITY is a person, place, thing, or event for which data is collected and maintained.For example, an online sales system includes entities named CUSTOMER, ORDER, PRODUCT, and SUPPLIER.When you prepared DFD during the systems analysis phase, you identified various entities and data stores. Now you will consider the relationships among the entities.
Chapter 5 - System Design - Cont 38
Definitions
FIELD, also called an attribute, is a single characteristic or fact about an entity.In the example shown in figure 7, the entity named CUSTOMER has fields to store data about each customer, such as First Name, Last Name, and Address.A Common field is an attribute that appears in more than one entity. Common fields can be used to link entities in various types of relationships.
Chapter 5 - System Design - Cont 39
Definitions
RECORD, also called a tuple, is a set of related fields that describes one instance, or member of an entity, such as one customer, one order, or one product.A record might have one or dozens of fields, depending on what information is needed.
Chapter 5 - System Design - Cont 40
Definitions
FILE AND TABLE records are grouped into files or tables, depending on the data design model.In a database environment, a set of related records is grouped into a table that stores data about a specific entity.
Chapter 5 - System Design - Cont 41
Key Fields
During the systems design phase, you use key fields to organize, access, and maintain data structures.The four types of keys are primary keys, candidate keys, foreign keys, and secondary keys.
Chapter 5 - System Design - Cont 42
FIGURE 8 Example of common fields, primary keys, candidate keys, foreign keys, and secondary.
Chapter 5 - System Design - Cont 43
Key Fields
PRIMARY KEYS is a field or combination of fields that uniquely and minimally identifies a particular member of an entity.For example, in a customer table the customer number is a unique primary key because no two customers can have the same customer number.In figure 7, Customer ID is an example of a primary key based on a single field.
Chapter 5 - System Design - Cont 44
Key Fields
In the registration file, neither the student number nor the course ID is unique, so neither field can be a primary key.To identify a specific student in a specific course, the primary key must be a combination of student number and course ID. In that case, the primary key is a combination key, or a multivalued key.
Chapter 5 - System Design - Cont 45
Key Fields
CANDIDATE KEYSSometimes you have a choice of fields or field combinations to use as the primary key.Any field that could serve as a primary key is called a candidate key.Any field that is not a primary key or a candidate key is called a nonkey field.
Chapter 5 - System Design - Cont 46
Key Fields
FOREIGN KEYS Recall that a common field exists in more than one table and can be used to form a relationship, or link, between the tables.Unlike a primary key, a foreign key need not be unique.
Chapter 5 - System Design - Cont 47
Key Fields
SECONDARY KEYSA secondary key is a field or combination of fields that can be used to access or retrieve records.Secondary key values are not unique.For example, if you need to access records for only those customers in a specific ZIP code, you would use the ZIP code field as a secondary key.Secondary keys also can be used to sort or display records in a certain order.
Chapter 5 - System Design - Cont 48
DATA RELATIONSHIPS
Recall that an entity is a person, place, thing, or event for which data is collected.A relationship is a logical link between entities based on how they interact.For example, a relationship exists between the entities PRODUCT and WAREHOUSE because products are stored in warehouses
Chapter 5 - System Design - Cont 49
Entity-Relationship Diagrams
An entity-relationship diagram (ERD) is a graphical model of the information system that depicts the relationships among system entities.Three main types of relationships can exist between entities,
Chapter 5 - System Design - Cont 50
FIGURE 9 In an entity-relationship diagram, entities are labeled with singular nouns and relationships are labeled with verbs.
Chapter 5 - System Design - Cont 51
Entity-Relationship Diagrams
A one-to-one relationship, abbreviated 1:1Exists when exactly one of the second entity occurs for each instance of the first entity.A number 1 is placed alongside each of the two lines connecting a rectangle to the diamond to indicate the 1:1 relationship.
Chapter 5 - System Design - Cont 52
FIGURE 10 One-to-one (1:1) relationships.
Chapter 5 - System Design - Cont 53
Entity-Relationship Diagrams
A one-to-many relationship, abbreviated 1:MExists when one occurrence of the first entity can be related to many occurrences of the second entity, but each occurrence of the second entity can be associated with only one occurrence of the first entity.
Chapter 5 - System Design - Cont 54
FIGURE 11 One-to-many (1:M) relationships.
Chapter 5 - System Design - Cont 55
Entity-Relationship Diagrams
A many-to-many relationship, abbreviated M:NExists when one instance of the first entity can be related to many instances of the second entity, and one instance of the second entity can be related to many instances of the first entity.
Chapter 5 - System Design - Cont 56
FIGURE 12 Many-to-many (1:M) relationships.
Chapter 5 - System Design - Cont 57
Entity-Relationship Diagrams
A complete ERD shows all system entities and relationships.Figure 12 has five entities: SALES REP, CUSTOMER, ORDER, PRODUCT, and WAREHOUSE and the relationship between SALES REP and CUSTOMER is one-to-many.The relationship between WAREHOUSE and PEODUCT is one-to-many, but the relationship is many-to-many if the company stores multiple products in multiple warehouses.
Chapter 5 - System Design - Cont 58
FIGURE 13 An entity-relationship diagram for SALES REP, CUSTOMER, ORDER, PEODUCT, and WAREHOUSE.
Chapter 5 - System Design - Cont 59
Cardinality
Figure 10 – 13 describe various relationships among entities: one-to-one, one-to-many, and many-to-many.The nature of those relations also is called cardinality.As an analyst, you must understand cardinality in order to design files and databases that accurately reflect all relationships among entities.
Chapter 5 - System Design - Cont 60
Cardinality
Cardinality describes how instances of one entity relate to instances of another entity.In a specific relationship, an entity can be mandatory, which means that it always is required, or optional. If an entity is mandatory, only one instance might be allowed in a relationship, or many instances might be permitted.
Chapter 5 - System Design - Cont 61
Cardinality
For example, consider the relationship between two entities: CUSTOMER and ORDER.One customer can have one order, many orders, or none, but each order must have one and only one customer.
Chapter 5 - System Design - Cont 62
Creating an ERD
Entity-relationship diagrams are easy to construct if you use the follow four steps.
1. Identify the entities.Review your DFDs and list the people, places, things, or events for which data is collected.Ensure that you identify all data stores.
Chapter 5 - System Design - Cont 63
Creating an ERD
2. Determine all significant events, transactions, or activities that occur between two or more entities.
The task requires you to analyze the business operations and identify the entities and the nature of the relationship between them.
Chapter 5 - System Design - Cont 64
Creating an ERD
3. Analyze the nature of the interaction.Does the interaction involve one instance of the entity or many?Is the pattern always the same or does it depend on some factor?
Chapter 5 - System Design - Cont 65
Creating an ERD
4. Draw the ERD.You can draw the ERD manually or by using a CASE Tool.Study the diagram carefully to ensure that all entities and relationships are shown accurately.
Entity-Relationship Diagram
โอฬาริก สุรินตะ
Entity-Relationship Diagram 2
Entity-Relationship Diagram
E-R Diagram เปนแผนภาพที่แสดงความสัมพันธของ Entity ที่แทนกลุมของสิ่งตาง ๆ ที่สามารถระบุไดในความเปนจริง ซึ่งอาจเปนสิ่งที่จับตองได หรือจับตองไมได
Entity-Relationship Diagram 3
สัญลักษณของ E-R DIAGRAM
Entity แบงออกเปน 2 ประเภทRegular Entity (Strong Entity)
Entity ที่ประกอบดวยสมาชิกที่มีคุณสมบตัิซึง่บงบอกถึงเอกลักษณของแตละสมาชิกได
Weak EntityEntity ที่คุณสมบัติของตัวมันเองไมสามารถบงบอกถึงเอกลักษณของแตละสมาชกิใน Entity ได ตองอาศัยคุณสมบัติของ Regular Entity มาประกอบ
Student
StudentEntity-Relationship Diagram 4
Attribute
Attribute ใชแทนคุณสมบัติตาง ๆ ของ Entity หรือ Relationship แบงเปน 5 ประเภทSimple Attribute
Attribute ที่คาไมสามารถแบงยอยได
ชื่อนิสิต
Entity-Relationship Diagram 5
Attribute
Composite AttributeAttribute ทีป่ระกอบดวย attribute ยอยหลาย ๆ ตัว
Entity-Relationship Diagram 6
Attribute
Multi-value AttributeAttribute ที่มีคาไดหลายคา
Identifier หรือ KeyAttribute ที่คาไมซ้ํากันและจะใชเปนคียหลัก
หมายเลขโทรศัพท
รหัสนิสติ
Entity-Relationship Diagram 7
Attribute
Derived AttributeAttribute ที่เกิดจากการคํานวณของ attribute อื่น
อายุ
Entity-Relationship Diagram 8
Relationship
Relationship ใชแทนความสัมพันธระหวางสมาชิกของ Entity เรียกสมาชิกที่มีความสัมพันธวา Participant
เรียน ซื้อ
ความสมัพันธของ Regular Entity ความสมัพันธของ Weak Entity
Entity-Relationship Diagram 9
Relationship
รูปแบบของความสัมพันธสามารถแบงออกเปน 3 แบบดังนี้1:1
Entity-Relationship Diagram 10
Relationship
1:M
Entity-Relationship Diagram 11
Relationship
M:N
Entity-Relationship Diagram 12E-R Diagram ระบบการซื้อสินคา
Entity-Relationship Diagram 13
การแปลง E-R Diagram เปนตารางความสัมพันธ
การแปลง Entity ใหเปนตาราง ฟลดของตารางไดจาก Attribute ของ Entity และกําหนดคียหลักของตารางโดยตารางทีแ่ปลงจาก Regular Entity คยีหลักคือ Identifier Attribute
Entity-Relationship Diagram 14
การแปลง E-R Diagram เปนตารางความสัมพันธ
ตารางที่ไดจาก Week Entity คียหลักคือ Identifier Attribute ของ Regular Entity และ Identifier Attribute ของ Weak Entity
Entity-Relationship Diagram 15
การแปลง E-R Diagram เปนตารางความสัมพันธ
การแปลง Attribute เนื่องจาก Attribute มีหลายชนิดถาเปน Simple Attribute, Identifier Attribute และ Derived Attribute ใหแปลงไปเปนฟลดในตารางที่แปลงจาก Entity นั้นเลยComposite Attribute ใหแปลง Attribute ยอยไปเปนฟลดในตาราง
Entity-Relationship Diagram 16
การแปลง E-R Diagram เปนตารางความสัมพันธ
Entity-Relationship Diagram 17
การแปลง E-R Diagram เปนตารางความสัมพันธ
Multi-Value Attribute ใหสรางเปนตารางใหมโดยมีฟลดคือ Multi-value Attribute และ Identifier Attribute ของ Entity นั้น พรอมกับเปนคียหลักรวมกัน
Entity-Relationship Diagram 18
การแปลง E-R Diagram เปนตารางความสัมพันธ
การแปลง Relationship จะทําหลังจากที่เราทําการแปลง Entity และ Attribute ตาง ๆ เปนตารางเสร็จเรียบรอยแลว
1:1 เลือกเอาคียหลักของตารางใดก็ไดมาเปน Foreign Key ของอีกตารางหนึ่ง
Entity-Relationship Diagram 19 Entity-Relationship Diagram 20
การแปลง E-R Diagram เปนตารางความสัมพันธ
1:M เลือกเอาคียหลักของตารางที่มีความสัมพันธในฝง 1 มาเปน Foreign Key ของตารางฝงที่มีความสัมพันธแบบ M
Entity-Relationship Diagram 21
การแปลง E-R Diagram เปนตารางความสัมพันธ
M:N ทําการสรางเปนตารางใหม ฟลดของตารางไดจาก Attribute ของ Relation และคียหลักไดจากคียหลักของสองตารางนํามาเปนคียหลักรวมกัน
Entity-Relationship Diagram 22
Entity-Relationship Diagram 23
การแปลง E-R Diagram เปนตารางความสัมพันธ
N-ary Relationship ทําการสรางเปนตารางใหม ฟลดของตารางไดจาก Attribute ของ Relationship และคียหลักไดจากคียหลักของทุกตารางนํามาเปนคียหลักรวมกันหลักการคลายแบบ M:N
Entity-Relationship Diagram 24
Entity-Relationship Diagram 25
การแปลง E-R Diagram เปนตารางความสัมพันธ
Recursive Relationship อาศัยหลักการคลาย 1:1, 1:M, M:N ขึ้นอยูกับวาเปนความสัมพันธแบบใด เพียงแตแตกตางกันในเรื่องของคียหลัก
Entity-Relationship Diagram 26
Entity-Relationship Diagram 27 Entity-Relationship Diagram 28
Entity-Relationship Diagram 29 Entity-Relationship Diagram 30
1 / 16
ฐานขอมูลเชงิสัมพนัธ ฐานขอมูลเชงิสัมพันธ เปนรูปแบบหนึง่ของฐานขอมูลในการประมวลผลที่นยิมใชใน
ปจจุบัน มีรูปแบบขอมูลเปนตารางเหมือนกับแฟมขอมลู ซึ่งประกอบดวย แถว (Row) เหมือนกบัเขตขอมูลในรูปแบบของแฟมขอมูล และคอลัมน (Column) เหมือนกับระเบยีนขอมูลในรูปแบบของแฟมขอมลู ดังตัวอยาง
รหัสนักศึกษา ช่ือนักศึกษา คณะ 43110001 จงดี ใจกลา วิทยาศาสตร 43110002 อรวรรณ คงดี วิทยาศาสตร 43110201 สมศรี พลมา มนุษยศาสตร
แตละตารางจะตองมีคียหลกั (Primary Key) ซึ่งหมายถงึคอลัมนในตารางที่มคีาขอมูล
ไมซ้ํากนั เพื่อใชสําหรับการเขาถึงแถวขอมลูในตาราง จากตารางตัวอยางขางบนม ี รหัสนักศึกษา เปนคียหลัก ฐานขอมูลหนึง่ ๆ อาจจะประกอบดวยตารางขอมูลหนึ่งตารางหรือหลายตารางกไ็ด ซึ่งจะมกีารสรางความสัมพนัธในแตละตารางโดยอาศัยการจัดเก็บขอมูลคียหลักของอีกตารางเพือ่เชื่อมความสมัพันธกัน
ภาพประกอบ 1 โครงสรางของฐานขอมลูเชิงสัมพันธ
ฐานขอมูล
ตาราง ตาราง ตาราง
แถว
คอลัมน
Column
Row
2 / 16
ความสัมพันธระหวางตารางของฐานขอมลูเชิงสัมพันธนัน้ถือไดวามีความสําคัญตอการเรียกใชขอมูลรวมกัน เพราะแทนที่จะจัดเก็บขอมูลที่เหมือนกนัในทุกตาราง จะทําการจัดเก็บขอมูลแยกเปนตารางที่มีขอมูลไมซ้ํากนั และเมือ่ตองการใชขอมูลในตารางอื่นก็จะอาศัยความสัมพันธในการดึงขอมูลจากตารางนั้นมาใชงานแทน ดังตัวอยาง ตาราง เจาของบัญช ี ตาราง บัญชเีงนิฝาก
ช่ือ ที่อยู เลขที่บัญชี เลขที่บัญชี ยอดเงิน แพง ดีจริง 51 บางพลัด กทม. 111111 111111 8,000 จิราพร ดาหา 21 บางบอน กทม. 222222 222222 15,000 กิตติ ดีจริง 51 บางพลัด กทม. 333333 333333 7,000 สมชาย บุญยืน 35 บางรัก กทม. 444444 444444 20,000
จากตัวอยางตารางขางบน ตารางทั้งสองมีความสมัพันธกนั โดยตารางเจาของบัญชี
จัดเก็บขอมูลเลขที่บัญชีเพื่อจะอางไปยงัขอมูลในตารางบัญชีเงินฝาก ซึ่งเลขที่บัญชีใน ตารางบัญชีเงินฝากถือเปนคียหลกัในตาราง สวนเลขที่บัญชีในตารางเจาของบัญชีเราจะเรียกวาเปน คียอางอิง (Foreign Key) จะเหน็วาการเชื่อมความสัมพนัธของสองตาราง ทาํใหในตาราง เจาของบัญชีไมจําเปนตองจดัเก็บขอมูลยอดเงินของบญัชีเงินฝากไว แตเมื่อตองการใชขอมูล ก็แคอาศัยเลขที่บัญชีในการอางไปยงัขอมลูในตารางบญัชีเงินฝากดงัตัวอยาง เชน ถาตองการทราบวาบัญชเีงินฝากของ จิราพร ดาหา เหลือยอดเงินในบัญชีเทาไร ทําไดโดยใช เลขที่บัญชี 222222 ไปดึงขอมูลจากตารางบัญชีเงินฝากก็จะไดยอดเงินเหลือ 15,000 บาท ในทํานองกลับกนัถาเราตองการทราบที่อยูของเจาของบัญชีเลขที่ 333333 ก็สามารถทราบไดโดยใชเลขที่บัญชีนัน้ เพื่อดึงขอมูลทีอ่ยูในตารางเจาของบัญช ี ทําใหในตารางบัญชีเงนิฝากไมจําเปนตองจัดเก็บขอมูลของเจาของบญัชีไวเชนกนั
3 / 16
ความสมัพันธระหวางตาราง หมายถึง ความสัมพันธของรายการขอมูลในตารางหนึง่กับรายการขอมูลในอีกตารางหนึ่ง ไมไดหมายความถงึความสัมพนัธทางกายภาพใด ๆ เชน ความสัมพันธระหวางพอ และลูก ความสมัพันธของตารางสามารถแบงออกไดเปน 3 แบบ ดังนี ้
- ความสัมพนัธแบบหนึง่ตอหนึ่ง (1:1) คือรายการขอมูล 1 รายการในตารางหนึง่มีความสมัพันธหรืออางไปยังรายการขอมูลเพียง 1 รายการในอีกตารางหนึง่
ตาราง เจาของบัญช ี ตาราง บัญชีเงนิฝาก
ช่ือ ที่อยู เลขที่บัญชี เลขที่บัญชี ยอดเงิน แพง ดีจริง 51 บางพลัด กทม. 111111 111111 8,000 จิราพร ดาหา 21 บางบอน กทม. 222222 222222 15,000 กิตติ ดีจริง 51 บางพลัด กทม. 333333 333333 7,000 สมชาย บุญยืน 35 บางรัก กทม. 444444 444444 20,000
ตารางสองตารางมีความสัมพันธกันแบบหนึ่งตอหนึง่ คือรายการขอมูลหนึง่รายการใน
ตารางเจาของบัญชี สามารถอางไปยงัรายการขอมูลในตารางบัญชีเงนิฝากไดหนึง่รายการ เชน รายการขอมูลเจาของบัญช ี ชื่อ สมชาย บุญยืน สามารถอางไปยังรายการขอมูลบัญชีเงินฝากไดหนึง่รายการ คือ 444444 เปนตน ในทาํนองเดียวกัน รายการขอมูลหนึ่งรายการในตารางบัญชี เงินฝากก็สามารถอางไปยงัรายการขอมูลในตารางเจาของบญัชีไดหนึ่งรายการเหมือนกนั
เชน รายการขอมูลเลขที่บัญชี 111111 สามารถอางไปยังรายการขอมูลเจาของบัญชีไดหนึง่รายการ คือ แพง ดีจริง เปนตน
ภาพประกอบ 2 ความสัมพันธแบบหนึ่งตอหนึง่ (1:1)
ตารางบัญชีเงินฝาก ตารางเจาของ บัญชี แพง ดีจริง
จิราพร ดาหา กิตติ ดีจริง
สมชาย บุญยืน
111111 222222 333333 444444
4 / 16
- ความสัมพนัธแบบหนึง่ตอกลุมหรือแบบกลุมตอหนึ่ง (1:M) คือรายการขอมูล 1 รายการในตารางหนึ่งมีความสมัพันธหรืออางไปยังรายการขอมูลไดหลายรายการในอีกตารางหนึง่ ดังตัวอยาง
ตาราง นกัศึกษา ตาราง อาจารยที่ปรึกษา รหัสนักศึกษา ช่ือนักศึกษา อาจารยที่ปรึกษา ช่ืออาจารย หมายเลขโทรศัพท
43110001 จงดี ใจกลา อาภรณ คํากอน อาภรณ คํากอน 01-7852123 43110002 กรวรรณ คงดี สุภาพร เอื้ออารี สุภาพร เอื้ออารี 01-5884661 43110003 สมศรี พลมา อาภรณ คํากอน ศิริวรรณ ประเสริฐ 01-2444369 43110004 สมชาย บุญยืน ศิริวรรณ ประเสริฐ วัชระ ถาวรดี 01-3388765 43110005 สมหญิง งามตา สุภาพร เอื้ออารี
ตารางสองตารางมีความสัมพันธกันแบบหนึ่งตอกลุม คือรายการขอมูลหนึ่งรายการ ในตารางอาจารยสามารถอางไปยงัรายการขอมูลในตารางนกัศึกษาไดหลายรายการ
เชน รายการขอมูลอาจารยชื่อ อาภรณ คํากอน สามารถอางไปยังรายการขอมูลนักศึกษาได 2 รายการคือ นกัศึกษาที่มีรหสั 43110001 และรหัส 43110201 เปนตน
ภาพประกอบ 3 ความสัมพันธแบบหนึ่งตอกลุม (1:M)
ตารางอาจารย ที่ปรึกษา
ตารางนักศึกษา อาภรณ คํากอน
สุภาพร เอื้ออารี
ศิริวรรณ ประเสริฐ
43110001 43110002 43110003 43110004 43110005
5 / 16
- ความสมัพันธแบบกลุมตอกลุม (M:N) คือรายการขอมูลหลายรายการในตารางหนึง่มีความสัมพนัธ หรืออางไปยังรายการขอมูลไดหลายรายการในอกีตารางหนึง่ ดังตัวอยาง
ตาราง นักศกึษา ตาราง รายวิชา
รหัสนักศึกษา ช่ือนักศึกษา รหัสวิชา ช่ือวิชา หนวยกิต 43110001 จงดี ใจกลา 122 100 คอมพิวเตอรเบื้องตน 3 43110002 กรวรรณ คงดี 122 130 การจัดการเทคโนโลยีสารสนเทศ 3 43110003 สมศรี พลมา 122 230 การสื่อสารขอมูล 3 43110004 สมชาย บุญยืน 122 108 การใชเทคโนโลยีสารสนเทศ 2
ตาราง ลงทะเบียน รหัสวิชา รหัสนิสิต ปการศึกษา ภาคเรียน เกรด
122 108 43110004 2543 1 A 122 130 43110004 2544 2 B 122 130 43110001 2544 2 A 122 108 43110001 2545 1 C 122 108 43110003 2545 1 A
ตารางนักศึกษามีความสัมพันธกับตารางรายวิชาแบบกลุมตอกลุม คือ รายการขอมูลหนึง่
รายการในตารางนกัศึกษาสามารถอางไปยังรายการขอมูลในตารางรายวิชาไดหลายรายการ เชน รายการขอมูลนักศึกษาที่มีรหัส 43110004 สามารถอางไปยงัรายการขอมูลรายวิชา
ได 2 รายการ คือ รหัสวิชา 122 108 และรหัสวิชา 122 130 เปนตน ในทาํนองเดียวกัน รายการขอมูลหนึ่งรายการในตารางรายวิชาก็สามารถอางไปยัง
รายการขอมูลในตารางนกัศึกษาไดหลายรายการ เชน รายการขอมูลรายวิชา ทีม่ีรหัสวิชา 122 108 สามารถอางไปยงัรายการขอมูลนักศึกษาได 2 รายการคือ รหัสนักศึกษา 43110001 และรหัสนักศึกษา 43110003 เปนตน แตความสมัพันธของทั้งสองตารางจะอาศัยตารางลงทะเบียนในการเชื่อมโยง
6 / 16
ภาพประกอบ 4 ความสัมพันธแบบกลุมตอกลุม (M:N) Entity-Relationship Diagram (E-R Diagram)
E-R Diagram เปนแผนภาพที่แสดงความสัมพันธของ Entity ที่แทนกลุมของสิง่ตาง ๆ ที่สามารถระบุไดในความเปนจริง ซึ่งอาจเปนสิ่งที่จับตองได หรือจับตองไมได
เชน นิสิตภาควิชาและตองมีนัยสาํคัญตอระบบ แตละ Entity จะประกอบดวยสมาชิก (Entity Set) ที่มีคุณสมบัติเหมือนกัน เชน Entity นิสิต ก็จะประกอบดวยกลุมของนิสิตหลาย ๆ คน ที่มีคุณสมบัติของความเปนนิสิตเหมือนกนั เชน รหัสนิสิต ชื่อนิสิต สาขาวิชา เปนตน
สัญลกัษณของ E-R - Entity สัญลักษณที่ใชคือ ส่ีเหลี่ยมผนืผา และแบงไดเปน 2 ประเภท คือ Regular Entity หรือ Strong Entity ไดแก Entity ทีป่ระกอบดวยสมาชิกที่มีคุณสมบัติ
ซ่ึงบงบอกถึงเอกลักษณของแตละสมาชิก เชน นิสิตที่มีรหัสประจําตวันิสิตที่ไมซํ้ากนั
Weak Entity ไดแก Entity ที่คุณสมบัตขิองมันไมสามารถบงบอกถึงเอกลักษณของแตละสมาชิกใน Entity ได ตองอาศัยคุณสมบัตขิอง Regular Entity มาประกอบ เชน รายการสั่งซื้อตองอาศัยเลขที่ใบสั่งซื้อ จาก Entity ใบสั่งซื้อ
ตารางนักศึกษา ตารางรายวิชา
122 108
122 130
43110001
43110003
43110004
รายการสั่งซื้อ
นิสิต
7 / 16
- Attribute ใชแทนคุณสมบัติตาง ๆ ของ Entity หรือ Relationship เชน หมายเลขบัตรประชาชน ชื่อ-สกุล วนัเดือนปเกิด ที่เปนคุณสมบัติของ Entity คนไทย เปนตน สัญลักษณที่ใชคือวงรี และแบงประเภทไดดังนี้ Simple Attribute หมายถงึ attribute ทีค่าไมสามารถแบงยอยได เชน ชื่อนิสิต ทีน่ิสิตแต
ละคนจะมีไดคาเดียว และไมสามารถแตกยอยคาได
Composite Attribute หมายถึง attribute ที่ประกอบดวย attribute ยอยหลาย ๆ ตัว เชน ที่อยู
Multi-valued Attribute หมายถงึ attribute ที่มีคาไดหลายคา เชน หมายเลขโทรศัพทที่นิสิตแตละคนสามารถมีไดหลายหมายเลข
Identifier หรือ Key หมายถึง attribute ที่คาไมซ้ํากันและจะใชเปนคียหลัก เชน รหัสนิสิต ที่แตละคนจะมีคาไมซ้ํากนั
Derived Attribute หมายถึง attribute ที่คาไดจากการคํานวณมาจากคาของ attribute อ่ืน เชน อาย ุไดจากการคํานวณจากขอมูลวันเกิด
ชื่อนิสิต
ที่อยู จังหวัด
อําเภอ
บานเลขที่
ถนน
หมายเลขโทรศัพท
ชื่อนิสิต
อายุ
8 / 16
- Relationship ใชแทนความสัมพันธระหวางสมาชกิของ Entity เรียกสมาชิกที่มีความสัมพันธวา Participant และ relationship ที่เกิดขึ้นอาจจะมีคุณสมบัติ (Attribute) ดวยก็ไดสัญลักษณที่ใชคือ ส่ีเหลี่ยมขนมเปยกปูน
รูปแบบของความสัมพนัธสามารถแบงโดยการพิจารณาจํานวนสมาชิกของ entity ที่มีความสัมพันธ หรือพิจารณาจํานวน entity ที่มีความสมัพันธกนั ซึ่งถาพจิารณาจาํนวนสมาชิกของ entity ทีม่ีความสัมพนัธกนั ทําใหแบงความสัมพนัธไดเปน 3 แบบ ดังนี ้
- one-to-one relationship (1:1) เปนความสัมพนัธระหวางสมาชกิหนึง่ตัวของ entity หนึง่ กบัสมาชิกอกีหนึ่งตัวของ entity อ่ืน
- one-to-many relationship (1:M) เปนความสัมพนัธระหวางสมาชกิหนึง่ตัวของ entity หนึง่ กบัสมาชิกอกีหนึ่งหรือหลายตัวของ entity อ่ืน
- many-to-many relationship (M:N) เปนความสัมพนัธระหวางสมาชิกหนึ่งหรือหลายตวัของ entity หนึง่ กบัสมาชิกอกีหนึ่งหรือหลายตัวของ entity อ่ืน
ใบสงของ ใบเสร็จ ของ 1 1
อาจารยที่ปรึกษา นิสิต ดูแล 1 M
นิสิต รหัสวิชา เรียน M N
ความสัมพันธของ Regular Entity ความสัมพันธของ Weak Entity
เรียน ซื้อ
9 / 16
ภาพประกอบ 5 E-R Diagram ระบบการซื้อสินคา การแปลง E-R diagram เปนตารางความสัมพันธ
จากขั้นตอนการออกแบบเมือ่เราเขียน E-R diagram เสร็จเรียบรอยแลว เราจะนาํ E-R Diagram ที่ไดมาทาํการแปลงใหอยูในรูปแบบของตารางความสมัพันธ (เพราะเราใชรูปแบบ ฐานขอมูลเชงิสัมพันธ) หลักในการแปลง คือ เราจะทาํการแปลงสวนประกอบแตละสวนของ E-R diagram สรุปไดดังนี้
- การแปลง entity ใหแปลงเปน ตาราง (Relation) ฟลดของตารางไดจาก attribute ของ entity และกาํหนดคียหลัก (Primary Key) ของตาราง โดย
M 1
M
N
M 1 ลูกคา
ชนิดสินคา สินคา
ใบส่ังซื้อ
ชื่อลูกคา
รหัสลูกคา
หมายเลขโทรศัพท
รหัสไปรษณีย ที่อยูลกูคา
สั่งซื้อ
วันที่สั่งซื้อ
วันที่สงสินคา รหัสใบสั่งซื้อ
รายละเอยีด ชนิดสินคา
รหัสชนิดสินคา ชื่อชนิดสินคา
รหัสสินคา
ชื่อสินคา
ราคาตอหนวย จํานวนสินคาในคลัง
รายการ
มี
จํานวนสินคาที่สั่ง
10 / 16
ตารางที่แปลงจาก regular entity คียหลกั คือ identifier attribute
จากภาพ entity ลูกคา เปน regular entity มี 3 attribute ดังนัน้เมื่อแปลงแลวจะไดตารางลูกคาที่ประกอบดวย 3 ฟลดและมีรหัสลูกคาเปนคยีหลัก
ตารางที่ไดจาก weak entity คียหลัก คือ identifier attribute ของ regular entity และ identifier attribute ของ weak entity
จากภาพขางบน entity รายการสงของ เปน weak entity ของ entity ใบสงของม ี
4 attribute มีรหัสสินคาเปน identifier ดังนัน้เมื่อแปลงแลวจะไดตารางรายการสงของที่ประกอบดวย 5 ฟลด โดยเพิม่ฟลดรหัสใบสงของซึ่งเปน identifier ของ entity ใบสงของ นาํมาเปนคียหลักรวมกบัรหัสสินคา ดังนัน้ตารางรายการสงของจงึมีรหัสใบสงของและรหัสสินคาเปนคียหลกั
ลูกคา รหัสลูกคา
ชื่อลูกคา ที่อยูลูกคา
รหัสลูกคา ชื่อลูกคา ที่อยูลูกคา
แปลงเปนตารางลูกคามีรหัสลูกคาเปนคียหลัก
ของ 1 M ใบสงของ
รหัสใบสงของ
วันที่สงของ
รายการสงของ
รหัสสินคา จํานวน
ราคา ชื่อสินคา
รหัสใบสงของ รหัสสินคา ชื่อสินคา ราคา จํานวน
แปลงเปนตารางรายการสงของ มีรหัสใบสงของและรหัสสินคา เปนคียหลัก
11 / 16
- การแปลง attribute เนื่องจาก attribute มีหลายชนิดจงึมีวธิีการแปลงที่แตกตางกนั - ถาเปน simple attribute, identifier attribute และ derived attribute ใหแปลง
ไปเปนฟลดในตารางที่แปลงจาก entity นัน้เลย - composite attribute ใหแปลง attribute ยอยไปเปนฟลดในตารางดงัตัวอยาง
- multi-value attribute ใหสรางเปนตารางใหมโดยมีฟลดคือ multivalue attribute และ identifier attribute ของ entity นั้น พรอมกับเปนคียหลกัรวมกนั ดังตวัอยาง
ลูกคา รหัสลูกคา
ชื่อลูกคา ที่อยูลูกคา
รหัสลูกคา ชื่อลูกคา บานเลขที่ ถนน อําเภอ จังหวัด
บานเลขที่ ถนน
อําเภอ
จังหวัด
ลูกคา รหัสลูกคา
ชื่อลูกคา เบอรโทรศัพท
รหัสลูกคา ชื่อลูกคา รหัสลูกคา เบอรโทรศัพท
12 / 16
- การแปลง relationship จะทําหลังจากที่เราทําการแปลง entity และ attribute ตาง ๆ เปนตารางเสรจ็เรียบรอยแลว
one-to-one relationship เลือกเอาคียหลกัของตารางใดก็ไดมาเปน foreign key ของอีกตารางหนึง่ ดังตัวอยาง
หรือ
one-to-many relationship เลือกเอาคียหลักของตารางที่มีความสัมพนัธในฝง one มาเปน foreign key ของตารางฝงทีม่ีความสมัพนัธแบบ many ดังตัวอยาง
พนักงาน โครงการ หัวหนา 1 1
รหัสพนักงาน
ชื่อ ที่อยู
รหัสโครงการ
ชื่อโครงการ
รายละเอียด
รหัสพนักงาน ชื่อ ที่อยู รหัสโครงการ รหัสโครงการ ชื่อโครงการ รายละเอียด ตารางพนักงาน ตารางโครงการ
รหัสพนักงาน ชื่อ ที่อยู รหัสโครงการ ชื่อโครงการ รายละเอียด รหัสพนักงาน
ตารางพนักงาน ตารางโครงการ
อาจารยที่ปรึกษา นิสิต ดูแล 1 M
ชื่ออาจารย
โทรศัพท วุฒิการศึกษา
รหัสนิสิต
ชื่อ
สาขาวิชา
ชื่ออาจารย โทรศัพท วุฒิการศึกษา รหัสนิสิต ชื่อ สาขาวิชา ชื่ออาจารย ตารางอาจารยที่ปรึกษา ตารางนิสิต
13 / 16
many-to-many relationship ทาํการสรางเปนตารางใหม ฟลดของตารางไดจาก attribute ของ relationship และคียหลัก ไดจากคียหลักของ 2 ตารางนํามาเปนคียหลักรวมกัน
N-ary relationship ทําการสรางเปนตารางใหม ฟลดของตารางไดจาก attribute ของ relationship และคียหลัก ไดจากคียหลักของทุกตารางนํามาเปนคียหลกัรวมกัน หลักการคลายแบบ many-to-many
นิสิต วิชา เรียน M N
รหัสนิสิต
ชื่อ สาขาวิชา รหัสวิชา
ชื่อวิชา
หนวยกิต
รหัสวิชา ชื่อวิชา หนวยกิต รหัสนิสิต ชื่อ สาขาวิชา ตารางวิชา ตารางนิสิต
ปการศึกษา เกรด
รหัสนิสิต รหัสวิชา ปการศึกษา เกรด ตารางเรียน
14 / 16
recursive relationship อาศัยหลักการคลาย one-to-one, one-to-many, many-to-many ข้ึนอยูกับวาเปน ความสัมพนัธแบบใด เพียงแตแตกตางกนัในเรื่องของคียหลักดังตัวอยาง
รหัสนิสิต ชื่อ สาขาวิชา รหัสพี่รหัส
ตารางนิสิต
นิสิต
พี่รหัส
1 1
รหัสนิสิต
ชื่อ
สาขาวิชา
รหัสนิสิต ชื่อ สาขาวิชา รหัสนองรหัส
ตารางนิสิต
ตารางลูกคา
สินคา คลังสินคา ซื้อ
ลูกคา
รหัสสินคา ชื่อสินคา
รหัสลูกคา
ชื่อลูกคา
ที่อย
ชื่อคลังสินคา ที่ตั้ง
รหัสลูกคา ชื่อลูกคา ที่อยู รหัสสินคา ชื่อสินคา ราคา ตารางสินคา
รหัสลูกคา รหัสคลังสินคา รหัสสินคา จํานวน ตารางซื้อ
ราคา
ชื่อคลังสินคา ที่ตั้ง ตารางคลังสินคา
จํานวน
15 / 16
รหัสพนักงาน ชื่อ แผนก รหัสหัวหนาพนักงาน ตารางพนักงาน
พนักงาน
หัวหนา
1 M
รหัสพนักงาน
ชื่อ
แผนก
รหัสนิสิต รหัสเพื่อนนิสิต ตารางเพื่อน
นิสิต
เพื่อน
M N
รหัสนิสิต
ชื่อ
สาขาวิชา
รหัสนิสิต ชื่อ สาขาวิชา ตารางนิสิต
16 / 16
ตัวอยาง ตารางที่แปลงไดจาก ภาพประกอบ 5 E-R diagram การซื้อสินคา
รหัสลูกคา ชื่อลูกคา หมายเลขโทรศัพท ที่อยูลูกคา รหัสไปรษณีย ตารางลูกคา
รหัสใบส่ังซื้อ วันที่สงสินคา รหัสลูกคา ตารางใบสั่งซื้อ
รหัสชนิดสินคา ชื่อชนิดสินคา รายละเอียดชนิดสินคา ตารางชนิดสินคา
รหัสสินคา ชื่อสินคา ราคาตอหนวย จํานวนสินคาในคลัง รหัสชนิดสินคา ตารางสินคา
รหัสใบส่ังซื้อ รหัสสินคา จํานวนสินคาที่ส่ัง ตารางรายการ
System Implementation
โอฬาริก สุรินตะCS/ICT
Chapter 6 - System Implementation 2
INTRODUCTION
At the conclusion of the systems design phase, you prepared a system design specification that outlined the physical design for the new information system.Now, in the systems implementation phase, the system design specification serves as a blueprint for constructing the new system.
Chapter 6 - System Implementation 3
INTRODUCTION
During this phase, the IT department plans, develops, documents, integrates, and tests all new programs and code modules.
Chapter 6 - System Implementation 4
QUALITY ASSURANCE
In today’s competitive business environment, companies are intensely concerned with the quality of their products and services.A successful organization constantly must improve quality in every area, include its information systems.Top management must provide the leadership, encouragement, and support needed for high quality IT resources.
Chapter 6 - System Implementation 5
QUALITY ASSURANCE
The main objective of quality assurance is to avoid problems, or to detect them as soon as possible.Poor quality can result from inaccurate requirements, design problems, coding errors, faulty documentation, and ineffective testing.
Chapter 6 - System Implementation 6
Software Engineering
Because quality is so important, you can use an approach called software engineering to manage and improve the quality of the finished system.Software engineering is a software development process that stresses solid design, effective structure, accurate documentation, and careful testing.
Chapter 6 - System Implementation 7
Software Engineering
To achieve that goal, Software Engineering Institute (SEI) designed Capability Maturity Models (CMM), which improve quality, reduce development time, and cut costs.A CMM tracks an organizations software development goals and practices, using five maturity levels, shown in Figure 1.
Chapter 6 - System Implementation 8
Software Engineering
Figure 1 A CMM Uses five maturity levels, from Level 1 to Level 5
Chapter 6 - System Implementation 9
Software Engineering
The CMM is organized into five maturity levels.1. Initial. The software process is characterized as
ad hoc, and occasionally even chaotic. Few processes are defined, and success depends on individual effort and heroics.
2. Repeatable. Basic project management processes are established to track cost, schedule, and functionality. The necessary process discipline is in place to repeat earlier successes on projects with similar applications.
Chapter 6 - System Implementation 10
Software Engineering
3. Defined. The software process for both management and engineering activities is documented, standardized, and integrated into a standard software process for the organization.
4. Managed. Detailed measures of the software process and product quality are collected, both the software process and products are quantitatively understood and controlled.
5. Optimizing. Continuous process improvement is enabled by quantitative feedback from the process and from piloting innovative ideas and technologies.
Chapter 6 - System Implementation 11
International Organization for Standardization (ISO)
ISO is a world wide body that establishes quality standards for products and services.ISO Seeks to offer global consensus of what constitutes good management practicesPractices that can help firms deliver consistently high-quality products and services.
Chapter 6 - System Implementation 12
International Organization for Standardization (ISO)
Because software is so important to a company’s success, many firms seek assurances that software systems.In 1991, ISO established a set of guidelines called ISO 9000-3, which provided a quality assurance framework for developing and maintaining software.
Chapter 6 - System Implementation 13
OVERVIEW OF APPLICATION DEVELOPMENT
A new system requires planning, construction, and testing. After an overall strategy is established, programs and modules must be designed, coded, tested, and documented, as shown in Figure 2.
Chapter 6 - System Implementation 14
OVERVIEW OF APPLICATION DEVELOPMENT
Figure 2 The main steps in application development.
Chapter 6 - System Implementation 15
OVERVIEW OF APPLICATION DEVELOPMENT
After developing and testing all programs and code modules, systems analysts and programmers ensure that modules will interact properly, test the overall system, and complete all documentation.
Chapter 6 - System Implementation 16
STRUCTURED APPLICATION DEVELOPMENT
During structured application development, a programmer creates modules that perform specific tasks or functions.A Modules consists of related program code organized into small units that are easy to understand and maintain.
Chapter 6 - System Implementation 17
STRUCTURED APPLICATION DEVELOPMENT
When planning a system, most analysts use a top-down approach, which proceeds from a general design to a detailed structure in a series of logical steps.Top-down, the systems analyst defines the overall objectives of the system, and then breaks them down into subsystems and modules in a process called partitioning.
Chapter 6 - System Implementation 18
Structure Charts
Structure charts show the relationships among program modules.A structure chart consists of rectangles that represent the program modules, with arrows and other symbols that provide additional information.A higher-level module, called a control module,directs lower-level modules, called subordinate modules.
Chapter 6 - System Implementation 19
Structure Charts
In a structure chart, symbols represent various actions or conditions. Structure chart symbols represent modules, data couples, control couples, conditions, and loops.
Chapter 6 - System Implementation 20
Structure Charts
MODULE A rectangle represents a module, vertical lines at the edges of a rectangle indicate that module 1.3 is a library module.A library module is reusable and can be invoked from more than one point in the chart Figure 3 An example of
structure chart modules.
Chapter 6 - System Implementation 21
Structure Charts
DATA COUPLE An arrow with an empty circle represents a data couple.A data couple shows data that one module passes to another.In the data couple example shown in Figure 4, the Look Up Customer Name module exchanges data with the Maintain Customer Data module. Figure 4 An example of
structure chart data couple.
Chapter 6 - System Implementation 22
Structure ChartsCONTROL COUPLE An arrow with a filled circle represents a control couple.A control couple shows a message, also called a flag,Which one module sends to another.The Update Customer File module sends an Account Overdue flag back to the Maintain Customer Data module.A module uses a flag to signal a specific condition or action to another module.
Figure 5 An example of structure chart control couple.
Chapter 6 - System Implementation 23
Structure ChartsCONDITION A line with a diamond on one end represents a condition.A condition line indicates that a control module determines which subordinate modules will be invoked, depending on a specific condition.Sort Inventory Parts is a control module with a condition line that triggers one of the three subordinate modules.
Figure 6 An example of structure chart condition and condition lines.
Chapter 6 - System Implementation 24
Structure ChartsLOOP A curved arrow represents a loop.A loop indicates that one or more modules are repeated.The Get Student Grades and Calculate GPA modules are repeated.
Figure 7 An example of structure chart loop.
Chapter 6 - System Implementation 25
Cohesion and Coupling
Cohesion measures a module’s scope and processing characteristic.A module that performs a single function or task has a high degree of cohesion, which is desirableBecause it focuses on a single task, a cohesive module is much easier to code and reuse.
Chapter 6 - System Implementation 26
Cohesion and Coupling
For example, a process named Verify Customer Number is more cohesion than a process named Calculate And Print statements.If you notice the word and in a module name, you know that more than one task is involved.
Chapter 6 - System Implementation 27
Cohesion and Coupling
If a module must perform multiple tasks, more complex coding is required and the module will be more difficult to create and maintain.
Figure 8 An example of structure chart cohesion.
Chapter 6 - System Implementation 28
Cohesion and Coupling
Coupling measures relationships and interdependence among modules. Modules that are relatively independent are loosely coupled, which is desirable.Loosely coupled modules are easier to maintain and modify, because the logic in one module does not affect other modules.
Chapter 6 - System Implementation 29
Cohesion and Coupling
If a programmer needs to update a loosely coupled module, he or she can accomplish the task in a single location.If modules are tightly coupled, one module refers to internal logic contained in another module.
Chapter 6 - System Implementation 30
Cohesion and Coupling
For example, a Calculate GPA module might refer to an internal variable, such as Student Status, contained in another module called Update Student Status.In that case, a logic error in the second module affects the first module’s processing sequence.
Chapter 6 - System Implementation 31
Cohesion and Coupling
Figure 9 An example of loosely coupled and tightly coupled structure charts.
Chapter 6 - System Implementation 32
Steps in Drawing a Structure Chart
Structure charts are based on the DFDsyou constructed during data and process modeling, and object models that you developed.Typically, you follow four steps when you create a structure chart.
Chapter 6 - System Implementation 33
Steps in Drawing a Structure Chart
REVIEW THE DFDS AND OBJECT MODELSThe first step is to review the DFDs to ensure that you have a leveled, balanced set to diagrams.You should check for accuracy and completeness, especially if changes have occurred since the system analysis phase.
Chapter 6 - System Implementation 34
Figure 10 DFDs for the Order System.
Chapter 6 - System Implementation 35
Steps in Drawing a Structure Chart
IDENTIFY MODULES AND RELATIONSHIPSWorking from the logical model, you transform functional primitives and object methods into program modules.When analyzing a set of DFDs, remember that each DFD level represents a processing level.
Chapter 6 - System Implementation 36
Steps in Drawing a Structure Chart
You work your way down from the context diagram to the lower-level diagrams, identifying control modules and subordinate modules, until you reach functional primitives.If more cohesion is desired, you can divide processes into smaller modules that handle a single task.
Chapter 6 - System Implementation 37
Figure 11 A Structure chart based on the Order System.
Chapter 6 - System Implementation 38
Steps in Drawing a Structure Chart
ANALYZE THE STRUCTURE CHART, THE DFDs, AND THE DATA DICTIONARYAt this point, the structure chart is ready for careful analysis.You should check each process and data element to ensure that the chart reflects all previous documentation, and that the logic is correct.
Chapter 6 - System Implementation 39
OTHER APPLICATION DEVELOPMENT TOOLS
Program Flow ChartsProgram flow charts graphically represent the logic and interaction between program modules, using a series of symbols connected by arrows.
Chapter 6 - System Implementation 40
Figure 12 A program flowchart shows the logic needed to calculate commissions and perform related tasks.
Chapter 6 - System Implementation 41
OTHER APPLICATION DEVELOPMENT TOOLS
PseudocodePseudocode is a technique for representing program logic.Pseudocode is similar to structured English.Pseudocode is not language-specific, so you can use it to describe a software module in plain English without requiring strict syntax rules.
Chapter 6 - System Implementation 42
Figure 13 An example of pseudocode that documents the logical steps in the Sales commission.
Chapter 6 - System Implementation 43
CODING
Coding is the process of turning program logic into specific instructions that the computer system can execute.Working from a specific design, a programmer uses a programming language to transform program logic into code statements.
Chapter 6 - System Implementation 44
CODING
Many programming language exist
C, C++HTML, ASP PHPJavaSQLVisual Basic, Visual C++ Figure 14 An example of
Programming tool.
Chapter 6 - System Implementation 45
TESTING THE APPLICATION
After coding, a programmer must test the program to make sure that it functions correctly.First Step, programs are tested in groups, and finally the programmer must test the entire system.This process detects syntax errors.
Chapter 6 - System Implementation 46
TESTING THE APPLICATION
Second Step, the programmer desk checks the program. Desk checking is the process of reviewing the program code to spot logic errors, which produce incorrect results.This process can be performed by the person who wrote the program or by other programmers.
Chapter 6 - System Implementation 47
TESTING THE APPLICATION
Third Step in application development is to initiate a sequence of
unit testingintegration testingsystem testing
Figure 15 Unit testing.
Chapter 6 - System Implementation 48
Unit Testing
The testing of an individual program or module is called unit testing.The objective is to identify and eliminate execution errors that could cause the program to terminate abnormally, and logic errors that could have been missed during desk checking.
Chapter 6 - System Implementation 49
Unit Testing
Test data should contain both correct data and erroneous data and should test all possible situations that could occur.During testing, programmers can use software tools to determine the location and potential causes of program errors.
Chapter 6 - System Implementation 50
Unit Testing
Programmers must test programs that interact with other programs and files individually, before they are integrated into the system.This requires a technique called stub testing.Each stub represents an entry or exit point that will be linked later to another program or data file
Chapter 6 - System Implementation 51
Integration Testing
Testing two or more programs that depend on each other is called integration testing, or link testing.Testing the programs independently does not guarantee that the data passed between them is correct.Only by performing integration testing for this pair of programs can you make sure that the programs work together properly.
Chapter 6 - System Implementation 52
System Testing
After completing integration testing, you must perform system testing, which involves the entire information system.A system test includes all typical processing situations.During a system test , users enter data, including samples of actual, or live data, perform queries, and produce reports to simulate actual operating conditions.
Chapter 6 - System Implementation 53
System Testing
System testing has the following major objectives
Perform a final test of all programs.Ensure that the IT staff has the documentation and instructions needed to operate the system properly.Demonstrate that users can interact with the system successfully.
Chapter 6 - System Implementation 54
System Testing
Verify that all system components are integrated properly and that actual processing situations will be handled correctly.Confirm that the information system can handle predicted volumes of data in a timely and efficient manner.
Chapter 6 - System Implementation 55
DOCUMENTATION
Documentation is essential for successful system operation and maintenance.Accurate documentation helps a programmer who needs to carry out a future program change and makes maintenance easier, faster, and less expensive.Documentation explains the system, helps people interact with it.
Chapter 6 - System Implementation 56
Program Documentation
Program documentation starts in the systems analysis phase and continues during systems implementation.System analysts prepare overall documentation, such as process descriptions and report layouts.System analysts usually verifies that program documentation is complete and accurate.
Chapter 6 - System Implementation 57
System Documentation
System documentation describes the system’s functions and how they are implemented. The analyst prepares most of the system documentation during the systems analysis and systems design phases.
Chapter 6 - System Implementation 58
System Documentation
System documentation includes data dictionary, DFD, screen layouts, source documents, and the systems request that initiated the project.During systems implementation, an analyst must review system documentation to verify that is complete, accurate, and up-to-date.
Chapter 6 - System Implementation 59
Operations Documentation
Operations documentation contains all the information needed for processing and distributing printed output. Typical operations documentation includes the following information.
Program, systems analyst, programmer, and system identificationScheduling information, such as report run frequency and deadlines
Chapter 6 - System Implementation 60
Operations Documentation
Input files and where they originate; and output files and destinationsReport distributionSpecial forms requiredError and informational messages to operators and restart proceduresSpecial instructions, such as security requirements.
Chapter 6 - System Implementation 61
User Documentation
User documentation consists of instructions and information to users who will interact with the system and includes user manuals, help screens, and tutorials.User documentation includes the following;
System overviewSource document content
Chapter 6 - System Implementation 62
User Documentation
Menu and data entry screen optionsReportsSecurity and audit trail informationResponsibility for specific input, output, or processing requirements.Procedures for requesting changes and reporting problems.Examples of exceptions and error situations
Chapter 6 - System Implementation 63
User Documentation
Examples of exceptions and error situationsFrequently asked questions (FAQs)Explanations of how to get Help and procedures for updating the manual
ผังงาน (Flowchart)
Olarik Surinta Lecturer of Management Information System Department
1 / 9
ผังงาน (Flowchart) ผังงาน หรือที่นิยมเรียกกนัวา Flowchart เปนแผนภาพทีใ่ชอธิบายขั้นตอน และลําดบัการ
ทํางานของโปรแกรมโดยอาศัยสัญลักษณ และขอความสัน้ ๆ ในการสื่อความหมาย
รูปแบบของผงังาน สามารถแบงได 2 ลักษณะดังนี ้ 1. ผังงานระบบ (System Flowchart) จะแสดงภาพรวมในการประมวลผลทั้งระบบวามีขั้นตอนหรือกระบวนการอะไรบาง ดังภาพประกอบ 1
ภาพประกอบ 1 ผังงานระบบ เงินเดือนพนักงาน
2. ผงังานโปรแกรม (Program Flowchart) จะแสดงขั้นตอนคําสั่งงานอยางละเอียดในแตละโปรแกรมยอยหรือโมดูล ดังภาพประกอบ 2
ภาพประกอบ 2 ผังงานโปรแกรมคํานวณเงนิเดือน
ขอมูล พนักงาน
ขอมูล การทํางาน
โปรแกรม คํานวณเงินเดือน
ขอมูล เงินเดือน
โปรแกรมพิมพ สลิปเงินเดือน
ใบสลิปเงินเดือน
เร่ิมตน
เงินเดือน = จํานวนชั่วโมงทํางาน * อัตราคาจาง
สิ้นสุด
ชื่อพนักงาน, จํานวนชั่วโมงทํางาน
เงินเดือน
ผังงาน (Flowchart)
Olarik Surinta Lecturer of Management Information System Department
2 / 9
สัญลักษณของผังงาน การเขียนผังงานตองใชภาพสัญลักษณตาง ๆ นํามาจัดเรียงลําดับเพื่อแสดงขั้นตอนการทํางานโดยมีลูกศรเชื่อมระหวางภาพ
ภาพ ความหมาย การเริ่มตน หรือการสิ้นสุด
รับขอมูล หรือแสดงขอมูลโดยไมระบุชนดิของอุปกรณ
บัตรเจาะขอมลู ใชรับขอมูลหรือแสดงขอมูล
การรับขอมูลเขาทางแปนพมิพ
การประมวลผล หรือการคํานวณ
การเปรียบเทยีบ หรือจุดในการตัดสินใจ
การกําหนดคาลวงหนา หรือกําหนดคาเปนชุดตัวเลข
การแสดงผลทางจอภาพ
การแสดงผลทางเครื่องพิมพ
เทปแมเหล็ก
จานแมเหล็ก
การทํางานยอย
เสนแสดงทิศทาง
ผังงาน (Flowchart)
Olarik Surinta Lecturer of Management Information System Department
3 / 9
ภาพ ความหมาย
จุดตอเนื่องในหนาเดยีวกัน
จุดตอเนื่องคนละหนา
คําอธิบาย
ภาพผังงานที่ดีควรมีลักษณะดังนี ้1. หนึ่งผังงานมีจดุเริ่มตนและจดุสิ้นสุดเพียงทางเดียวเทานัน้ 2. ลําดับขั้นตอนเริ่มจากบนลงลาง 3. ในสัญลักษณใด ๆ มีทางออกเพียงทางเดยีว ยกเวนสัญลักษณการตัดสนิใจ หรือทางเลือก
ซ่ึงตองมีอยางนอยสองทาง 4. เสนทางเดินในผังงานควรชดัเจน เปนระเบียบ 5. ขอความหรือคําสั่งใด ๆ ท่ีอยูในสัญลักษณควรสั้น กระชบั ไดใจความเขาใจงาย 6. ใชสัญลักษณที่เหมาะสมกบัคําสั่ง
1. การจัดภาพแบบตามลําดบั (Sequence)
เปนสวนงานที่ตองทําตามลําดับ กอน-หลัง
Function A
Function B
Function C
ผังงาน (Flowchart)
Olarik Surinta Lecturer of Management Information System Department
4 / 9
2. การจัดภาพแบบการเลือก (Selection) 2.1 เปนการเลอืกระหวางรายการสองทางเลือก เรียกวา IF-THEN-ELSE 2.2 การเลือกจากกลุมรายการที่มีจํานวนมากกวาสอง เรียกวา CASE 3. การจัดภาพแบบการทํางานซ้ํา (Iteration) 3.1 การทํางานซ้ําเมื่อเงื่อนไขเกิดขึ้นเรยีกวา WHILE
Condition A
Function B Function C
A = True A = False
Case: X
Function A Function C
X = a
Function B
X = b X = c
Condition A Function B
Function C
A = True
A = False
ผังงาน (Flowchart)
Olarik Surinta Lecturer of Management Information System Department
5 / 9
3.2 การทํางานซ้ําจนกระทั่งเงื่อนไขที่ระบุเกิดขึ้น เรียกวา REPEAT UNTIL
ตัวอยางการเขยีนผงังาน 1. จงเขียนผังงานสําหรับการอานขอมูล คือเลขประจําตวั ช่ือ อายุ และความสูงนสิิตหนึ่งคน และพิมพขอมูลเหลานั้นทางจอภาพ
START
Input Id, Name, Age, Height
Print Id, Name, Age, Height
STOP
Condition A
Function B
A = False
A = True
Function C
ผังงาน (Flowchart)
Olarik Surinta Lecturer of Management Information System Department
6 / 9
2. จงเขียนผังงานสําหรับอานขอมูลที่ประกอบดวย ความยาวดานของสี่เหล่ียมผืนผา และทําการคํานวณหาพื้นที่ของสีเ่หล่ียมนัน้พรอมทั้งแสดงผลลัพธทางจอภาพ 3. จงเขียนผังงานสําหรับอานคะแนนสอบของนิสิต 10 คน พรอมทั้งแสดงผลลัพธทางจอภาพ
START
Input H, W
Print Area
STOP
Area = H * W
I <= 10
True
START
STOP
I =
Read Score
I = I+1
Print Score False
ผังงาน (Flowchart)
Olarik Surinta Lecturer of Management Information System Department
7 / 9
4. จงเขียนผังงานสําหรับอานคะแนนสอบของนิสิต 10 คน และคํานวณหาคาเฉลี่ย พรอมทั้งแสดงผลลัพธทางจอภาพ
5. จงเขียนผังงานเพื่อทําการอานคะแนนสอบของนิสิต และใหรับคาทางคียบอรด โดยถา
ผูใช กด 1 ใหโปรแกรมทําการแสดงผลลัพธทางจอภาพ ถาผูใชกด 2 ใหโปรแกรมทาํการแสดงผลลัพธทางเครื่องพิมพ
I < 10
True
START
STOP
I = 0 Sum = 0
Read Score
Sum = Sum + Score I = I+1
Print Score
False Mean = sum / I
Case: X X = 1 X = 2
START
Read Score
Input X
Print Score Print Score
STOP
ผังงาน (Flowchart)
Olarik Surinta Lecturer of Management Information System Department
8 / 9
6. จงเขียนผังงานสําหรับอานคะแนนสอบของนิสิต และคํานวณเกรดของนิสิต ถานิสิตไดคะแนนนอยกวา 40 ไดเกรด F มากกวาหรือเทากับ 40 ไดเกรด D มากกวาหรือเทากบั 60 ไดเกรด C มากกวาหรือเทากับ 70 ไดเกรด B มากกวาหรือเทากับ 80 ไดเกรด A พรอมทั้งแสดงผลลัพธทางจอภาพ
Score >= 80
START
Read Score
Print Grade
STOP
Grade = ‘A’
Score >= 70 Grade = ‘B’
Score >= 60 Grade = ‘C’
Score >= 40 Grade = ‘D’
Grade = ‘F’
True
True
True
True
False
False
False
False
ผังงาน (Flowchart)
Olarik Surinta Lecturer of Management Information System Department
9 / 9
โจทยการเขียนผงังาน 1. จงเขียนผังงานสําหรับอานคะแนนสอบของนิสิต 10 คน และคํานวณเกรดของนิสิต ถานิสิต
ไดคะแนนนอยกวา 40 ไดเกรด F มากกวาหรือเทากับ 40 ไดเกรด D มากกวาหรือเทากับ 60 ไดเกรด C มากกวาหรือเทากับ 70 ไดเกรด B มากกวาหรือเทากับ 80 ไดเกรด A พรอมทั้งแสดงผลลัพธทางจอภาพ
2. จงเขียนผังงานสําหรับอานขอมูลที่ประกอบดวย ความยาวฐาน, ความสูงของสามเหลี่ยม และทําการคํานวณหาพืน้ทีข่องสามเหลี่ยมนั้นพรอมทั้งแสดงผลลัพธทางรายงาน
3. จงเขียนผังงานสําหรับอานขอมูลที่ประกอบดวย ความยาวฐาน, ความสูงของสามเหลี่ยม และทําการคํานวณหาพืน้ทีข่องสามเหลี่ยม และใหผูใชปอนขอมูลทางคียบอรดเพื่อเลือกแสดงผลลัพธ โดยกด 1 แสดงจากจอภาพ กด 2 แสดงทางรายงาน
System Maintenance
โอฬาริก สุรินตะCS-ICT
Chapter 7 - System Maintenance 2
MAINTAINING INFORMATION SYSTEM
Once an information system is stalled, the system is essentially in the maintenance phase of SDLC.When a system is in the maintenance phase, some person within the systems development group is responsible for collecting maintenance requests from system users and other interested parties.
Chapter 7 - System Maintenance 3
MAINTAINING INFORMATION SYSTEM
Once collected, each request is analyzed to better understand how it will alter the system and what business benefits and necessities will result from such a change.If the change request is approved, a system change is designed and then implemented.
Chapter 7 - System Maintenance 4
The Process of Maintaining Information Systems
The process of maintaining an information system is the process of returning to the beginning of the SDLC and repeating development steps until the change is implemented.
Chapter 7 - System Maintenance 5
The Process of Maintaining Information Systems
Four major activities occur within maintenance
1. Obtaining Maintenance Requests2. Transforming Requests into Changes3. Designing Changes4. Implementing Changes
Chapter 7 - System Maintenance 6
TYPE OF MAINTENANCE
There are several types of maintenance that you can perform on an information system.By maintenance, we mean the fixing or enhancing of an information system.Maintenance expenses usually are high when a system is implemented because problems must be detected, investigated, and corrected.
Chapter 7 - System Maintenance 7
Corrective Maintenance
Corrective maintenance diagnoses and corrects errors in an operational system.Corrective maintenance often is needed to resolve issues created by previous maintenance changes.To avoid introducing new problems, all maintenance work requires careful analysis before making changes.
Chapter 7 - System Maintenance 8
Adaptive Maintenance
Adaptive maintenance adds enhancements to an operational system and makes the system easier to use.An enhancement is a new feature or capability.The need for adaptive maintenance usually arises from business environment changes such as new products or services, or support for a new Web-based operation.
Chapter 7 - System Maintenance 9
Perfective Maintenance
Perfective maintenance involves changing an operational system to make it more efficient, reliable, or maintainable.Requests for corrective and adaptive maintenance normally come from users, while the IT department usually initiates perfective maintenance.
Chapter 7 - System Maintenance 10
Perfective Maintenance
Perfective maintenance also can improve system reliability.For example, input problems might cause a program to terminate abnormally.By modifying the data entry process, you can highlight errors and notify the user that they must enter proper data.When a system is easier to maintain, support is less costly and less risky. In many cases, you can simplify a complex program to improve maintainability.
Chapter 7 - System Maintenance 11
Preventive Maintenance
Reverse engineering includes changes to an operational system that reduce the possibility of future problems.To avoid problems before they happen, preventive maintenance requires analysis of areas where trouble is likely to occur.Like perfective maintenance, the IT department normally initiates preventive maintenance.
Chapter 7 - System Maintenance 12
Preventive Maintenance
Preventive maintenance often results in increased user satisfaction, decreased downtime.Preventive maintenance competes for IT resources along with other projects, and sometimes does not receive the high priority that it deserves.
Chapter 7 - System Maintenance 13
MAINTENANCE TEAM
A maintenance team consists of one or more systems analysts and programmers.The analysts must have a solid background in information technology, strong analytical abilities, and a solid understanding of business operations and management functions.
Chapter 7 - System Maintenance 14
MAINTENANCE TEAM
Maintenance systems analysts are like skilled detectives who investigate and rapidly locate the source of problem by using analysis and synthesis skills.Some organizations that have separate maintenance and new systems groups rotate people from one area to the other.When analysts learn different skills, the organization is more versatile and people can shift to meet changing business needs.
Chapter 7 - System Maintenance 15
MANAGING MAINTENANCE REQUESTS1. Maintenance request.
Users submit most requests for corrective and adaptive maintenance when the system is not performing properly or if they want new features.To keep a complete maintenance log, all work must be covered by a specific request that users submit in writing or by e-mail.
Chapter 7 - System Maintenance 16
MANAGING MAINTENANCE REQUESTS2. Initial determination.
Most organizations designate a system administrator with responsibility for configuration management on specific systems.When a user submits a maintenance request, the administrator makes an initial decision.
Chapter 7 - System Maintenance 17
MANAGING MAINTENANCE REQUESTS
If the request involves a severe problem, a team is assigned immediately to perform corrective maintenance.The administrator notifies the requester and the systems review committee of the decision and the reasons for the determination.
Chapter 7 - System Maintenance 18
MANAGING MAINTENANCE REQUESTS3. Final disposition of the request.
The systems review committee evaluates the request and either rejects it or assigns it a priority and schedules the maintenance work.To reduce paperwork and unnecessary effort, the committee often delegates final authority to the system administrator for requests that fall within a certain cost range.