Systems implementation & evaluation Show
Systems implementation is the process of:
Systems design Conceptual design � what the system should do Logical design � what the system should look to the user Physical design � how the system should be built Physical system design using structured design approach: � To produce a system that is easy to read, code, and maintain 1. Factoring: decomposition��� 2. Span of control: 9 subordinate modules 3. Reasonable size: 50-100 LOC 4. Coupling: minimize inter-module dependency 5. Cohesion: single module functionality 6. Shared use: multiple calls to lower level modules from different bosses Structured design tools � Organization of programs and program modules (structure chart) � Processing logic specification in each module (pseudocode) Structure chart � to show graphically
Symbols
Converting DFDs to structure charts 1. Locate the central transform/transaction center 2. Find a coordinating module for the top of the chart 3. Identify the primary input and output data flows 4. Draw a top-level chart (consists of two hierarchical level) 5. Refine the chart until the data origin, system function, and output dispositions are defined Cap and gown ordering system example
 Pseudocode To provide programmers with a text description of the contents of each module Cap and gown ordering system example MODULE: Process_Order() Set EOF = no, VALID = 0 Get_Student DO WHILE EOF = no � IF VALID = 0 ����� Get_Order � ENDIF � IF VALID = 0 ����� Process_Valid_Order � ELSE Process_Invalid_Order(VALID) � ENDIF � Get_Student ENDDO MODULE: Get_Student() SET EOF = no, VALID = 0, TYPE="student" READ student_ID IF student_ID = null ��� THEN EOF = yes ELSE Verify_Data(TYPE) ENDIF RETURN student_ID, EOF, VALID MODULE: Get_Order() SET TYPE = "order" READ cap_size, gown_size Verify_Data(TYPE) RETURN cap_size, gown_size, VALID MODULE: Process_Invalid_Order(valid) IF VALID = 1 ���� error = "Student not found" ELSE IF VALID = 2 ��������������� error = "Student is not graduating in spring" ���������� ELSE IF VALID = 3 ����������������� ���������error = "Cap size out of stock" ��������������������� ELSE IF VALID = 4 ������������������������������������� error = "Gown size out of stock" �������������������������������� ENDIF ���������������������� ENDIF ���������� ENDIF ENDIF DISPLAY error MODULE: Verify_Data (type) IF TYPE = "student" ��� THEN OPEN Student_File ��������� FIND Student_Record USING student_ID ��������� IF Student_Record NOT_FOUND ������������� THEN VALID = 1 ��������� ELSE IF Student.graduate_date <> "Spring 1999" �������� ���������������THEN VALID = 2 ������������������� ENDIF ��������� ENDIF ELSE IF TYPE = "order" ��������� THEN OPEN Inventory_File ������������������� GET Inventory.cap_on_hand USING cap_size ������������������� GET Inventory.gown_on_hand USING gown_size � ������������������IF Inventory.cap_on_hand = 0 ����������������������� THEN VALID = 3 ������������������� ELSE IF Inventory.gown_on_hand = 0 ���������������������������������� THEN VALID = 4 ������������������������������ ENDIF ������������������� ENDIF ���������� ENDIF ENDIF RETURN VALID MODULE: Process_Valid_Order(student_ID, cap_size, gown_size) Update_Inventory(cap_size, gown_size) Generate_Receipt(student_ID, cap_size, gown_size) Record_order(student_ID, cap_size, gown_size) MODULE: Update_Inventory(cap_size, gown_size) OPEN Inventory_file GET Inventory.cap_on_hand USING cap_size REDUCE Inventory.cap_on_hand BY 1 FIND Inventory.gown_on_hand USING gown_size REDUCE Inventory.gown_on_hand BY 1 CLOSE Inventory_File MODULE: Record_Order(student_ID, cap_size, gown_size) OPEN Order_File Order.student_ID = student_ID Order.cap_size = cap_size Order.gown_size = gown_size WRITE Order_Record PRINT Order_Record AS Receipt_Report CLOSE Order_File Implementation issues 1. Testing 2. Conversion 3. Documentation 4. Training 7 types of tests
Testing process (Figure 20.27)
Testing guidelines � Test different aspects of the system, e.g., response time, response to boundary data, response to no input, response to heavy volumes of input � Test anything that could go wrong or be wrong about a system � Test the most frequently used parts of the system at a minimum � The people who create the test cases should not be the same people as those who coded and tested the system � Use debugging tools, e.g., symbolic debugger Conversion strategies (Figure 21.12)
Types of documentation System documentation �maintenance programmers Records detail information about a system's design specifications, functionality (external), and internal workings (internal), e.g., DFDs, ERDs, Structured English, Structure Chart, Pseudocode. User documentation � end-users Records information about an application system, how it works, and how to use it, e.g., user manual, procedure manual Documentation standard
Training guidelines (Figure 21.11)
Training topics 1. Use of the system 2. Computer concepts 3. IS concepts 4. Organizational concepts 5. System management 6. System installation Training methods 1. Local experts: 51% 2. Computer-aided instruction: 17% 3. On-line help: 10% 4. Course: 10% 5. Tutorial: 7% 6. External sources: 5% Why implementation fails 1. Conventional wisdom: management support and user involvement 2. Factor model: Ginzberg's 4 factors, Lucas's 6 factors Ginzberg's 4 factor model 1. Project commitment: how well understood? 2. Change commitment: how willing to change? 3. Extent of project planning and definition: how well planned? 4. User expectations: how realistic? The Lewin/Schein change model 1. Unfreezing � Establish a felt need � Create a safe atmosphere 2. Moving � Provide necessary information � Assimilate knowledge and develop skills 3. Refreezing � Integrate the new behavior into ongoing behavior � Diffuse the change throughout the system 5 areas of expectations Goals: the reasons for developing the system Importance: the importance of the problem being addressed Patterns of use: the way the system will be used Impacts: system impacts on the organization Evaluation criteria � discuss these expectations from time to time involving end users, mangers, and system developers Source: �� Ginzberg, M.J., "Early Diagnosis of MIS Implementation Failure: Promising Results and Unanswered Questions," Management Science, vol.27, no.4, April, 1981, pp.459-478 Lucas's 6 factors model 1. User's personal stake: how important? 2. System characteristics: how easy to use? 3. User demographics: how computer literate? 4. Organization support: how committed? 5. Performance: how much can be done? 6. Satisfaction: how much is used? Escalation traps
Prevent over-commitment
Source: �� Staw, B.M., and Ross, J, "Knowing When to Pull the Plug," Harvard Business Review, March-April, 1987, pp.68-74 Quality assurance � to ensure that the system actually developed meets current and projected needs of the users and the organization Total quality management approach to quality assurance:
Indicators of a quality system
Structured system = structured analysis + structured design + structured programming Structured analysis: input-process-output Structured design: modular Structured programming: sequence-selection-repetition Main causes of changes
Source: �� Fitzgerald, G., Philippides, A., and Probert, S., "Information Systems Development, Maintenance, and Enhancement: Findings from a UK study," International Journal of Information Management, vol.19, 1999, pp.319-328. Systems evaluation
Evaluation technique IS utility approach (Figure 21.14) An IS can be evaluated as successful if it possesses all six utilities:
Is that is a collection of interrelated components that collect process store and provide as the information needed to complete a business task?A system is a group of interrelated components that function together to achieve a desired result. An information system (IS) is an arrangement of people, data, processes, and information technology that interact to collect, process, store, and provide as output the information needed to support an organization.
What do you call of a group of interrelated components that function together to achieve a desired results?System. A group of interrelated components that function together to achieve a desired result. Information System(IS) An arrangement of people, data, processes and information technology that interact to collect, process, store, and provide as output the information needed to support an organization.
Is the systematic process of developing a design including all information discovery planning and communications?Design analysis is the systematic process of developing a design including all information discovery, planning and communications. This can be applied to any type of design including the design of physical things such as buildings and intangible things such as software, information and processes.
What is the role of System Analyst how collect the information of system during development?Role of System Analyst
The system analyst is a person who is thoroughly aware of the system and guides the system development project by giving proper directions. He is an expert having technical and interpersonal skills to carry out development tasks required at each phase.
|
Is the process of specifying in detail how the many components of the information system should be physically implemented requirements?
zusammenhängende Posts
Urheberrechte © © 2024 de.apacode Inc.
