Dokumen tersebut membahas tentang pengembangan sistem informasi, yang meliputi konsep dasar pengembangan sistem, metode-metode pengembangan sistem seperti SDLC dan prototyping, serta prinsip-prinsip dasar pengembangan sistem seperti keterlibatan pemakai sistem dan justifikasi sistem sebagai investasi.
29. LSIK - TI / Rajesri 10. Pendekatan Sistem dalam Pengembangan Solution Effort 6. Identify alternative solutions 7. Evaluate the alternative solutions 8. Select the best solution 9. Implement the solution 10. Follow-up to ensure that the solution is effective Definition Effort 4. Proceed from a system to a subsystem level 5. Analyze system parts in a certain sequence
30. 11. Metode Konversi LSIK - TI / Rajesri Old System New System Old System New System Old System Old System New System New System Parallel Pilot Phased Plunge
31.
32.
33.
34. 13. Capability Maturity Model Initial Inconsistent Methods Repeatable Consistent Project Management Defined Process is stable, predicable, and repeatable Managed Process Managed and Measured Optimized Continuous Process Improvement LSIK - TI / Rajesri
Editor's Notes
Figure 3.6 System Development Phases The figure above depicts a simplified phase diagram of the FAST methodology. 82-83
Analysts, programmers, and other information technology specialists frequently refer to ``my system.'' This attitude has, in part, created an ``us-versus-them'' attitude between technical staff and their users. Although analysts and programmers work hard to create technologically impressive solutions, those solutions often backfire because they don't address the real organization problems or they introduce new organization or technical problems. Miscommunication and misunderstandings continue to be a significant problem in systems development. However, owner and user involvement and education minimizes such problems and helps to win acceptance of new ideas and technological change. Because people tend to resist change, the computer is often viewed as a threat. Through education, information systems and computers can be properly viewed by users as tools that will make their jobs less mundane and more enjoyable. 73-74
The notion here is that systems analysts should approach all projects using some sort of problem-solving approach. 74
The problem-solving orientation of a methodology, when correctly applied, can reduce or eliminate the above risks. 74
At any given time, you may be performing tasks in more than one phase simultaneously. Furthermore, you may have to backtrack to previous phases and activities to make corrections or to respond to new requirements. Obviously, you can't get carried away with this type of backtracking or you might never implement the new system. 74
An organization has many information systems that may include thousands of programs and software packages. If each analyst and programmer were to adopt their own preferred methodology, and use their own tools and techniques to develop and document systems, a state of chaos would quickly result. In order to promote good communication between this constantly changing base of users and information systems professionals you must develop standards to ensure consistent systems development. Documentation should be a working by-product of the entire systems development effort. Documentation reveals strengths and weaknesses of the system to others – before the system is built. It stimulates user involvement and reassures management about progress. 75-76
No additional notes provided. 76
There is often a temptation to continue with a project only because of the investment already made. Many analysts allow project scope to increase during a project. Sometimes this is inevitable because the analyst learns more about the system as the project progresses. 76
The concept of sunk costs is more or less familiar to some financial analysts and managers, but it is frequently forgotten or not used by the majority of practicing analysts and users. 76
Systems analysts must be mindful that any system they are working on interacts with its super-system. If the super-system is constantly changing, so might the scope of any given project. Most systems analysts can still be faulted for underestimating the size of projects. Most of the fault lies with not properly studying the implications of a given system relative to its larger whole – its super-system. 76-77
There is a critical shortage of information systems professionals needed to develop systems. 77
Figure 3.2 Systems Support and Entropy Entropy is illustrated in the context of the system development life cycle in the figure above. Notice that, after a system is implemented, it enters the support phase of the life cycle. During the support phase, the analyst encounters the need for changes that range from correcting simple mistakes, to redesigning the system to accommodate changing technology, to making modifications to support changing user requirements. As indicated by the blue arrows, many of these changes direct the analyst and programmer to rework former phases of the life cycle. Eventually, the cost of maintenance exceeds the costs of starting over – the system has become obsolete. This is indicated by the red arrow in the figure. 77
The systems analyst is frequently forced to duplicate files and ``patch'' programs in ways that make the system very costly to support over the long run. Even if you design the system to easily adapt to change (our last principle), at some point in time, it will become too costly to simply support the existing system. Why? Perhaps the organization itself has changed too dramatically to be supported by the system. Or perhaps the requirements have become too complex to be integrated into the current system. In either case it is time to start over! This situation puts the term cycle into the term systems development life cycle. No system lasts forever (although many do last for a decade or longer). 77-78
Figure 3.3 Principles of Systems Development 78
This slide corresponds to Figure 10.38 on pp. 414 and relates to the material on pp. 412-414. Four major forms of system conversion are common: Parallel . This involves operating both the old and the new system at the same time for some period until the project development team and end user management agree to switch over completely to the new system. Teaching Tip: Some PC operating systems allow for this type of conversion, on a smaller scale, by using a dual-boot procedure. Pilot . Here one department or often an off-site office gives the new system a trial run to see how it works and to catch any problems before the system is implemented company-wide. Phased . Here the new system is implemented gradually throughout the organization according to some diffusion plan, such as department by department, section by section, or even floor by floor. Plunge . This "cold turkey" approach ends use of the old system and begins use of the new system all at once. Teaching Tip: For example, a law firm may close on Friday, install a new computer-based information system based on networked PCs, and open for business on Monday. Such conversions are more likely if the hardware and software changes are not too drastic and end users are already familiar with the new system operation procedures.
![1. Pendahuluan ,[object Object],[object Object],[object Object],LSIK - TI / Rajesri](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)