Pengembangan sistem informasi

18.595 visualizaciones

Publicado el

Publicado en: Tecnología
1 comentario
1 recomendación
Sin descargas
Visualizaciones totales
En SlideShare
De insertados
Número de insertados
Insertados 0
No insertados

No hay notas en la diapositiva.
  • 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.
  • Pengembangan sistem informasi

    1. 1. Minggu 3 - 4 Manajemen Sistem Informasi Rajesri Govindaraju Pengembangan Sistem Informasi
    2. 2. 1. Pendahuluan <ul><li>Pengembangan sistem informasi sering disebut sebagai proses pengembangan sistem ( System Development ) </li></ul><ul><li>Pengembangan sistem didefinisikan sebagai: </li></ul><ul><li>adalah aktivitas untuk menghasilkan sistem informasi berbasis komputer untuk menyelesaikan persoalan (problem) organisasi atau memanfaatkan kesempatan (opportunities) yang timbul. </li></ul>LSIK - TI / Rajesri
    3. 3. Pendahuluan….. (lanjutan) <ul><li>Sebenarnya untuk menghasilkan sistem informasi tersebut terdiri dari: </li></ul><ul><ul><li>System Analysis : upaya mendapatkan gambaran bagaimana sistem bekerja dan masalah-masalah apa saja yang ada pada sistem </li></ul></ul><ul><ul><li>System Development : langkah-langkah mengembangkan sistem informasi yang baru berdasarkan gambaran cara kerja sistem dan permasalahan yang ada </li></ul></ul>LSIK - TI / Rajesri
    4. 4. 2. Konteks Pengembangan Sistem LSIK - TI / Rajesri
    5. 5. 3. Metode Pengembangan Sistem <ul><li>Banyak metode pengembangan sistem yang tersedia </li></ul><ul><li>Metode yang paling dikenal disebut juga sebagai System Development Life Cycle (SDLC) atau sering juga disebut sebagai Water Fall Method </li></ul><ul><li>Metode-metode lain yang dikenal antara lain: Prototyping, Application Software, End-User Development, Outsourcing, dan lain-lain. </li></ul><ul><li>Pada bagian berikut akan dijelaskan metode-metode tersebut secara ringkas. </li></ul>LSIK - TI / Rajesri
    6. 6. 4. Metode SDLC LSIK - TI / Rajesri Typical System Development Life Cycle (SDLC) diagram.
    7. 7. SDLC (lanjutan) <ul><li>SDLC merupakan metode pengembangan sistem paling tua </li></ul><ul><li>Sangat cocok untuk pengembangan sistem yang besar </li></ul><ul><li>Tidak sesuai atau tidak terlalu disarankan untuk small scale project karena: </li></ul><ul><ul><li>Resource intensive </li></ul></ul><ul><ul><li>Tidak fleksibel </li></ul></ul><ul><ul><li>Sulit untuk aplikasi dengan perubahan cara pengambilan keputusan yang cepat </li></ul></ul>LSIK - TI / Rajesri
    8. 8. LSIK - TI / Rajesri
    9. 9. SDLC (lanjutan) LSIK - TI / Rajesri
    10. 10. SDLC (lanjutan) LSIK - TI / Rajesri Cost to make a particular change in SDLC
    11. 11. 5. Metode Prototyping LSIK - TI / Rajesri <ul><li>Pendekatan iteratif dalam pengembangan sistem </li></ul><ul><li>Dibuat prototype operasional sistem, gunakan data aktual, edit input, lakukan komputasi dan semua manipulasi sehingga dihasilkan output nyata </li></ul><ul><li>Seperti membuat mock-up, coba, perbaiki, dst. </li></ul>Prototyping Process
    12. 12. … metode prototyping <ul><li>Keuntungan: </li></ul><ul><ul><li>Komunikasi user dan pengembang intensif </li></ul></ul><ul><ul><li>User terlibat aktif dalam menentukan requirement </li></ul></ul><ul><ul><li>Waktu pengembangan relatif singkat </li></ul></ul><ul><ul><li>Implementasi mudah karena pemakai mengetahui dari awal apa yang akan diperolehnya </li></ul></ul><ul><li>Kelemahan: </li></ul><ul><ul><li>Kemungkinan terjadi shortcut dalam pendefinisian masalah </li></ul></ul><ul><ul><li>Pemakai bisa terlalu berlebih menentukan requirement sehingga sulit dipenuhi </li></ul></ul><ul><ul><li>Kemungkinan tidak dihasilkan rancangan yang baik </li></ul></ul>LSIK - TI / Rajesri
    13. 13. 6. Metode Application Software LSIK - TI / Rajesri <ul><li>Alternatif lain adalah dengan membeli software aplikasi yaitu paket software yang sudah jadi </li></ul><ul><li>Misalkan membeli SAP, MSProject, dll. </li></ul><ul><li>Digunakan untuk aplikasi yang bersifat umum, misalkan payroll, akunting, dll. Namun pada saat ini software yang berbasis enterprise secara keseluruhan banyak tersedia ( enterprise software ): Oracle, Baan, SAP, dll. </li></ul><ul><li>Sangat sesuai jika perusahaan yang mengembangkan sistem kekurangan tenaga IT </li></ul>
    14. 14. 7. Metode End-user Development <ul><li>Pengembangan dilakukan langsung oleh end-user. </li></ul><ul><li>Menjadi semakin layak dengan tersedianya bahasa pemrograman yang mudah seperti MS Access, Delphi, dll. </li></ul><ul><li>Keterlibatan langsung end-user sangat menguntungkan, karena memahami benar bagaimana sistem bekerja. Artinya tahap analisis sistem dapat dilakukan lebih cepat. </li></ul><ul><li>Kelemahan adalah pada pengendalian mutu dan kecenderungan tumbuhnya “ private ” sistem informasi. Integrasi dengan sistem yang lain menjadi sulit. </li></ul>LSIK - TI / Rajesri
    15. 15. 8. Metode Outsourcing <ul><li>Dilakukan kontrak dengan pihak luar untuk menangani baik pengembangan maupun operasi & maintenance sistem. </li></ul><ul><li>Menguntungkan dari sisi kecepatan memperoleh hasil dan biaya. </li></ul><ul><li>Ada resiko tidak dapat mengendalikan sistem secara langsung dan masalah security. </li></ul>LSIK - TI / Rajesri
    16. 16. LSIK - TI / Rajesri 9. Prinsip Dasar Pengembangan Sistem <ul><li>Prinsip 1 : Pemilik dan Pengguna Sistem Harus terlibat dalam pengembangan. </li></ul><ul><ul><li>Keterlibatan pemilik dan pengguna sistem (System Owner dan User) adalah keharusan yang mutlak untuk keberhasilan pengembangan sistem. </li></ul></ul><ul><ul><li>Pengembang sistem bertanggungjawab harus menyediakan waktu yang cukup untuk partisipasi pemilik dan pengguna sistem dan meminta persetujuannya untuk setiap langkah analisis dan pengembangan sistem. </li></ul></ul>
    17. 17. LSIK - TI / Rajesri Prinsip Dasar Pengembangan Sistem <ul><li>Prinsip 2: Gunakan Pendekatan Pemecahan Masalah </li></ul><ul><ul><li>Metodologi yang digunakan dalam pengembangan sistem berbasis pendekatan bagaimana memecahkan masalah </li></ul></ul><ul><ul><li>Langkah-langkah klasik pemecahan masalah adalah sbb: </li></ul></ul><ul><ul><ul><li>Pelajari dan pahami masalah (opportunity, dan/atau directive) dan konteks dari sistem. </li></ul></ul></ul><ul><ul><ul><li>Definisikan kriteria atau ukuran solusi yang sesuai </li></ul></ul></ul><ul><ul><ul><li>Identifikasi alternatif-alternatif solusi dan pilih solusi terbaik. </li></ul></ul></ul><ul><ul><ul><li>Disain dan atau implementasikan solusi. </li></ul></ul></ul><ul><ul><ul><li>Observasi dan evaluasi dampak dari solusi dan sesuaikan solusi jika diperlukan. </li></ul></ul></ul>
    18. 18. LSIK - TI / Rajesri Prinsip Dasar Pengembangan Sistem <ul><li>(lanjutan prinsip 2) </li></ul><ul><ul><li>Ada kecenderungan untuk melewati langkah-langkah tersebut di atas atau melakukannya dengan kurang seksama. </li></ul></ul><ul><ul><li>Akibat yang terjadi kemungkinan adalah: </li></ul></ul><ul><ul><ul><li>Memecahkan persoalan yang salah </li></ul></ul></ul><ul><ul><ul><li>Kurang tepat dalam memecahkan persoalan </li></ul></ul></ul><ul><ul><ul><li>Mengambil solusi yang salah sama sekali </li></ul></ul></ul>
    19. 19. LSIK - TI / Rajesri Prinsip Dasar Pengembangan Sistem <ul><li>Prinsip 3 : Tentukan tahapan pengembangan </li></ul><ul><ul><li>Pentahapan akan membuat proses pengembangan menjadi aktivitas-aktivitas yang lebih kecil yang lebih mudah dikelola dan diselesaikan. </li></ul></ul><ul><ul><li>Tahapan pembuatan sistem harus dilakukan dengan urutan top-to-bottom . </li></ul></ul>
    20. 20. LSIK - TI / Rajesri Prinsip Dasar Pengembangan Sistem <ul><li>Prinsip 4 : Tetapkan standard untuk pengembangan dan dokumentasi yang konsisten </li></ul><ul><ul><li>Standard pengembangan sistem umumnya menjelaskan: </li></ul></ul><ul><ul><ul><li>aktivitas </li></ul></ul></ul><ul><ul><ul><li>Tanggung jawab </li></ul></ul></ul><ul><ul><ul><li>Petunjuk dan kebutuhan pendokumentasian </li></ul></ul></ul><ul><ul><ul><li>Pemeriksaan kualitas </li></ul></ul></ul><ul><ul><li>Kegagalan pengembangan sistem akibat tidak tersedianya standard pendokumentasian merupakan hal yang banyak dijumpai dalam proyek pengembangan sistem </li></ul></ul>
    21. 21. LSIK - TI / Rajesri Prinsip Dasar Pengembangan Sistem <ul><li>Prinsip 5 : Justifikasi sistem sebagai investasi </li></ul><ul><ul><li>Sistem Informasi adalah sebuah investasi. </li></ul></ul><ul><ul><li>Pada investasi maka terdapat dua hal yang harus diperhatikan, yaitu: </li></ul></ul><ul><ul><ul><li>Untuk setiap masalah, kemungkinan ada beberapa alternatif solusi </li></ul></ul></ul><ul><ul><ul><li>Setelah alternatif-alternatif teridentifikasi, pengembang sistem haus mengevaluasi fisibilitas setiap kemungkinan alternatif solusi, terutama dikaitkan dengan cost-effectiveness . </li></ul></ul></ul><ul><ul><ul><ul><li>Cost-effectiveness artinya semua biaya yang dikeluarkan untuk mengembangkan dan mengoperasikan sistem harus sebanding atau lebih sedikit dibandingkan dengan manfaat yang diperoleh dari sistem. </li></ul></ul></ul></ul><ul><ul><ul><li>Cost-benefit analysis harus dilakukan. </li></ul></ul></ul>
    22. 22. LSIK - TI / Rajesri Prinsip Dasar Pengembangan Sistem <ul><li>Prinsip 6 : Jangan takut membatalkan atau merubah lingkup pekerjaan. </li></ul><ul><ul><li>Keuntungan yang diperoleh dengan melakukan pentahapan pekerjaan pengembangan sistem adalah diperolehnya kesempatan untuk melakukan reevaluasi fisibilitas dari proyek pengembangan tersebut. </li></ul></ul><ul><ul><li>Dalam jangka panjang membatalkan sama sekali proyek bisa lebih murah dibandingkan masalah besar pada implementasinya. </li></ul></ul><ul><ul><li>Jika hal ini tidak dilakukan dapat terjadi pembengkakan biaya (cost overruns) yang sangat merugikan. </li></ul></ul>
    23. 23. LSIK - TI / Rajesri Prinsip Dasar Pengembangan Sistem <ul><li>(lanjutan prinsip 6:) </li></ul><ul><ul><li>Pendekatan creeping commitment : </li></ul></ul><ul><ul><ul><li>Titik-titik pemeriksaan ( checkpoints ) fisibilitas harus dibuat dalam proses pengembangan sistem. </li></ul></ul></ul><ul><ul><ul><li>Pada setiap titik pemeriksaan, semua biaya dianggap sunk-cost (artinya irrecoverable ). </li></ul></ul></ul><ul><ul><ul><li>Pada titik tersebut proses re-evaluasi dilakukan untuk menentukan apakah proyek masih fisibel. </li></ul></ul></ul><ul><ul><ul><li>Dari hasil evaluasi tersebut, pengembang sistem dapat: </li></ul></ul></ul><ul><ul><ul><ul><li>Membatalkan proyek jika dinilai tidak fisibel </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Re-evaluasi biaya dan jadwal jika lingkup proyek berubah. </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Pengurangan lingkup proyek jika anggaran dan jadwal tidak dapat ditambah sedangkan yang tersedia tidak mencukupi pencapaian semua tujuan yang telah ditetapkan. </li></ul></ul></ul></ul>
    24. 24. LSIK - TI / Rajesri Prinsip Dasar Pengembangan Sistem <ul><li>Prinsip 7 : Bagi dan tundukkan </li></ul><ul><ul><li>Semua sistem merupakan bagian dari sistem yang lebih besar (disebut super-systems ). </li></ul></ul><ul><ul><li>Begitu pula semua sistem terdiri dari bagian-bagian yang lebih kecil (disebut subsystems ). </li></ul></ul><ul><ul><li>Sistem harus dibagi menjadi subsistem-subsistem yang lebih kecil untuk memudahkan menyelesaikan persoalan dan membangun sistem yang lebih. </li></ul></ul><ul><ul><ul><li>Dengan membagi persoalan besar (sistem) menjadi potongan kecil yang lebih mudah (subsstem), pengembang akan mudah menerapkan proses pemecahan masalah. </li></ul></ul></ul>
    25. 25. LSIK - TI / Rajesri Prinsip Dasar Pengembangan Sistem <ul><li>Prinsip 8 : Rancang sistem untuk pertumbuhan dan perubahan </li></ul><ul><ul><li>Banyak pengembang sistem yang terjebak dalam pengembangan sistem untuk memenuhi kebutuhan saat ini saja. </li></ul></ul><ul><ul><li>Entropy adalah pengertian yang dipakai untuk menjelaskan bahwa sistem secara alamiah akan mengalami penurunan. </li></ul></ul><ul><ul><ul><li>Sistem bisa menjadi usang ( obsolute ) dan biaya untuk mengoperasikannya menjadi sangat besar . </li></ul></ul></ul>
    26. 26. LSIK - TI / Rajesri
    27. 27. LSIK - TI / Rajesri Prinsip Dasar Pengembangan Sistem <ul><li>(lanjutan Prinsip 8:) </li></ul><ul><ul><li>Sistem yang dirancang hanya untuk memenuhi kebutuhan saat ini akan sulit disesuaikan untuk menghadapi perubahan-perubahan. </li></ul></ul><ul><ul><li>Perhatian harus sebanding antara memperhatikan sistem yang ada (sering disebut legacy systems ), dan bagaimana memperkirakan arah pengembangan sistem yang baru. </li></ul></ul><ul><ul><li>Fleksibilitas dan kemampuan beradaptasi tidak terjadi begitu saja tetapi harus dirancang secara sengaja di dalam sistem </li></ul></ul>
    28. 28. LSIK - TI / Rajesri Prinsip Dasar Pengembangan Sistem <ul><li>Libatkan pemilik dan pemakai sistem </li></ul><ul><li>Gunakan pendekatan pemecahan masalah </li></ul><ul><li>Buat pentahapan aktivitas </li></ul><ul><li>Tetapkan standar pengembangan dan </li></ul><ul><li>pendokumentasian yang konsisten </li></ul><ul><li>Justifikasi sistem sebagai investasi </li></ul><ul><li>Jangan takut membatalkan </li></ul><ul><li>Bagi dan tundukkan </li></ul><ul><li>Rancang sistem untuk pertumbuhan dan </li></ul><ul><li>perubahan </li></ul>
    29. 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. 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. 31. 12. Fact Finding Techniques for Requirement Discovery <ul><li>Effective fact finding are crucial to the development of systems projects. </li></ul><ul><li>System Requirements : specify what the information system must do or what property or quality the system must have. </li></ul><ul><ul><li>Functional Requirements: what IS must do </li></ul></ul><ul><ul><li>Nonfunctional Requirements: specify a property or quality the system must have </li></ul></ul>LSIK - TI / Rajesri
    32. 32. System Requirement Criteria: <ul><li>Consistent (not ambigous or conflicting) </li></ul><ul><li>Complete (describe all possible inputs and responses) </li></ul><ul><li>Feasible (can be satisfied based on the available resources and constraints) </li></ul><ul><li>Required (truly needed and fulfill the purpose of the system) </li></ul><ul><li>Accurate (The requirements stated correctly) </li></ul><ul><li>Traceable (directly map to the functions and features of the system) </li></ul><ul><li>Verifiable (defined so that can be demonstrated during test) </li></ul>LSIK - TI / Rajesri
    33. 33. Fact Finding Techniques <ul><li>Sampling of existing documentation, reports, forms, files, databases, and memos. </li></ul><ul><li>Research of relevant literature, benchmarking of other’s solution, and site visits. </li></ul><ul><li>Observation of the current system in action and the work environment </li></ul><ul><li>Questionnaires and surveys of the management and user community </li></ul><ul><li>Interviews of appropriate managers, users, and technical staff </li></ul><ul><li>Joint Requirement Planning </li></ul>LSIK - TI / Rajesri
    34. 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