SESI 6 TAHAPAN RINCI PROYEK SISTEM INFORMASI

Presentasi berjudul: "SESI 6 TAHAPAN RINCI PROYEK SISTEM INFORMASI"— Transcript presentasi:

1 SESI 6 TAHAPAN RINCI PROYEK SISTEM INFORMASI
MANAJEMEN PROYEK SISTEM INFORMASI PROGRAM STUDI SISTEM INFORMASI ISTA

2 FASE DEFINISI Memahami Masalah User
PENDAHULUAN Tujuan dari fase definisi adalah untuk memahami dengan baik masalah-masalah yang dihadapi oleh user dalam memperkirakan biaya dan waktu penyelesaian proyek.

3 Tiga(3) Aktifitas utama dalam Fase Definisi :
Pertama Pahami dengan baik masalah-masalah yang dihadapi oleh user dan apa saja yang dibutuhkan untuk menyelesaikan masalah tersebut (KEBUTUHAN). Kedua Putuskan apakah proyek akan dilaksanakan atau tidak. Jika keputusannnya adalah melaksanakan proyek tersebut, lakukan analisis semua risiko-risiko yang mungkin terjadi yang dapat menggagalkan proyek tersebut. Analisis ini sangat membantu dalam penulisan PROPOSAL yang berisi rincian mengenai proyek apa yang akan ditawarkan, kapan, dan berapa biayanya (termasuk biaya untuk risiko-risiko yang mungkin terjadi). Tulislah beberapa dokumen dan temukan beberapa kejadian penting pada akhir fase ini dengan cara :

4 Membuat Requirement Document (RD), yaitu dokumen yang berisi rincian kebutuhan user. Dokumen RD harus jelas dan lengkap, sehingga Tim Proyek (Project Team (PT)) dapat memahami seluruh masalah-masalah yang dihadapi oleh user dan dapat memperkirakan biaya penyelesaian proyek tersebut. Kejadian penting pertama yang akan dihadapi berupa persetujuan atau penandatanganan dokumen RD oleh User dan Tim Proyek. Selanjutnya, menulis Pendahuluan Perencanaan Proyek (Preliminary Project Plan (PPP)). PPP merupakan langkah pertama dalam merencanakan langkah-langkah berikutnya yang harus diambil untuk mengembangkan produk dan sumber-sumber apa saja yang dibutuhkan untuk setiap langkahnya. Rencana tersebut menggambarkan berapa lama sumber-sumber tersebut akan diperlukan dan berapa banyak biaya yang akan dikeluarkan. Ketiga Memberikan perkiraan-perkiraan ini kepada user dalam bentuk PROPOSAL.

5 DOKUMEN KEBUTUHAN (REQUIREMENT DOCUMENT / RD)
RD menyatakan masalah-masalah yang dihadapi user dan solusi umum yang dibutuhkan. Bahasanya berorientasi pada bahasa yang digunakan oleh user sehari-hari, dan jauh dari bahasa komputer. Kadangkala dokumen RD digunakan sebagai permohonan untuk sebuah proposal (Request for a proposal (RFP)) ketika user menawarkan proyeknya kepada kontraktor luar. Tanya jawab dengan User Proses tanya jawab dilakukan untuk mendapatkan informasi yang tepat dari user untuk memperoleh RD yang baik. User akan memberikan semua informasi yang dibutuhkan dan tidak lebih. Tim proyek interviewer berkewajiban untuk mempelajari semua bisnis user, memahami teknologi user, dan mengajukan pertanyaan-pertanyaan. Terkadang manajer merasa dilangkahi atau diremehkan jika Tim berhubungan langsung dengan pemakai akhir yang berada di departemen. Solusi dari masalah ini adalah mendidik para wakil tim proyek tersebut bagaimana pentingnya komunikasi dengan para pemakai akhir yang sebenarnya. Jika masukkan yang mereka kemukakan tidak mendapat tanggapan pada awal pendefinisian, akan sangat mungkin terjadi perubahan-perubahan di kemudian hari dan hal ini berarti akan membutuhkan biaya yang cukup mahal untuk memperbaikinya. Mintalah izin dari manajer yang berwenang pada saat akan mewawancarai orang-orang mereka.

6 Berikut ini pertanyaan yang berhubungan dengan wawancara yang akan dilakukan :
Pertama, cari tahu tentang aliran informasi yang ada dalam perusahaan tersebut. Mulailah dengan pertanyaan-pertanyaan seperti : informasi apa saja yang dibutuhkan untuk menjalankan kegiatan bisnis perusahaan ? Seberapa penting aliran data, baik antara departemen maupun antar individual ? Tentukan frekuensi, waktu dan keakuratannya. Kedua, masukkan-masukkan yang diterima diikuti dengan pertanyaan-pertanyaan sebagai berikut : Informasi apa saja yang dibutuhkan untuk menghasilkan masing-masing barang? Informasi apa yang tersedia, kapan, dimana ? Informasi-informasi baru apa saja yang harus dikumpulkan ? Ingat tentang 5 W (Who, What, Where, When, Why). Sediakan waktu untuk pertanyaan-pertanyaan di atas selama membuat.

7 Hal-hal yang terdapat dalam RD
Berikut ini adalah bagian-bagian dari RD : Pendahuluan. Identifikasi perusahaan (user) dimana RD tersebut ditujukan. Tentukan masalah yang perlu diselesaikan, latar belakang, contoh situasi yang sedang dihadapi, motivasi-motivasi untuk menanggulanginya, dll. Bagian ini digunakan untuk memperkenalkan potensi penjual kepada perusahaan user atau departemen jika diperlukan, jelaskan kultur, lingkungungan, dan bagaimana jalannya bisnis yang dilakukan. Berikan pengertian kepada Tim Proyek tentang masalah yang dihadapi user. Tujuan Proyek. Sebuah pernyataan singkat mengapa harus mengajukan proposal untuk pengembangan proyek. Batasan-batasan utama dalam penggunaan waktu dan keuangan dapat juga disebutkan. Fungsi-fungsi Utama. Pernyataan singkat mengenai bagaimana sistem berfungsi berdasarkan tujuan proyek yang telah ditetapkan. Keluaran Umum. Penjelasan secara singkat tentang informasi yang dibutuhkan dari sistem. Informasi Input secara Umum. Input data apa yang diperlukan untuk menghasilkan output. Ini adalah waktu yang tepat untuk memastikan bahwa seluruh data yang dibutuhkan dapat tersedia pada waktu yang tepat pula.

8 Lanjutan Kinerja (Performance). Berapa banyak transaksi yang akan diproses, berapa banyak data yang akan disimpan, kapan laporan harus dihasilkan, dsb. Jelaskan waktu rata-rata dan waktu maksimal proses (dalam hari atau jam). Perkembangan (Growth). Hal ini mungkin sulit untuk diramalkan, tetapi cobalah untuk menghitung kemajuan bisnis dan menetapkan berapa tahun lagi sistem masih dapat diharapkan untuk berfungsi. Kemukakan dalam bentuk persentase atau angka sebenarnya. Pengoperasian dan Lingkungan. Dimana komputer akan ditempatkan, dimana terminal-terminal yang interaktif ditempatkan, dan siapa yang akan menggunakannya. Kompatibilitas, Pengantarmukaan. Jelaskan jika fasilitas antar komputer dibutuhkan, adakah alat-alat yang harus disatukan, atau jika pengiriman akses dibutuhkan. Jika sistem hanya dapat berjalan dengan komputer yang ada, atau harus dapat diprogram dengan bahasa yang spesifik, semua dokumen dinyatakan di dalam bagian ini. Reliabilitas, Ketersediaan. Tulis penggambaran waktu diantara kegagalan-kegagalan (Meantime between Failures / MTBF), waktu untuk perbaikan (Meantime to Repair / MTTR) dan persentase tambahan yang diperlukan. Semua manufaktur menyatakan penggambaran ini untuk hardware mereka.

9 Lanjutan Antarmuka dengan Pemakai. Rincikan pengalaman-pengalaman yang dibutuhkan user dalam menggunakan komputer, jelaskan bagaimana menangani sistem kapada user yang baru. Pengaruh Organisasi. Departemen-departemen apa yang akan sangat berpengaruh dan seberapa jauh cara kerja mereka harus berubah. Bagaimana sistem yang baru dapat berkomunikasi dengan sistem manual yang ada. Pemeliharaan dan Dukungan. Jaminan-jaminan yang dibutuhkan : berapa lama, sampai kapan, bagaimana pengiriman. Dokumentasi dan Pelatihan. Rincikan semua dokumen-dokumen umum dan / atau pelatihan yang dibutuhkan. Persyaratan dan Kondisi. Menyatakan syarat untuk seleksi, kapan dan bagaimana akan dilakukan.

10 KEPUTUSAN MELAKSANAKAN / TIDAK MELAKSANAKAN PROYEK
Setelah kebutuhan-kebutuhan ditetapkan, langkah berikutnya adalah memutuskan apakah proyek bernilai untuk dikerjakan atau tidak. Untuk membantu membuat keputusan itu, suatu studi kelayakan dilakukan untuk menjawab pertanyaan : “Dengan biaya berapa sistem dapat dibangun, dan apa keuntungannya ? Dalam suatu studi kelayakan pertimbangkan semua penyelesaian masalah teknis yang mungkin, dan coba untuk memperkirakan biaya dari masing-masing penyelesaian masalah. Untuk suatu proyek yang berukuran besar, pertimbangkan keputusan utama mengenai hardware apa yang digunakan, dan apakah akan membuat atau membeli software. Untuk proyek berukuran kecil sampai menengah studi kelayakan yang formal tidak perlu ditulis. Biasanya cukup dengan mengangkat seseorang untuk mempelajari penyelesaian masalah yang mungkin dan menilai keuntungan-keuntungan.

11 Perkiraan keuntungan ini mungkin saja mudah, tetapi seharusnya tidak dipergunakan. Manajer proyek tidak hanya harus menjawab “Apakah proyek ini secara teknis dapat dikerjakan ?” tetapi juga menjawab pertanyaan yang lebih penting : “Apakah proyek ini dapat dikerjakan oleh saya sekarang ?” Manajer proyek harus bertanya pada diri sendiri apakah proyek yang ada memiliki peluang untuk sukses, atau proyek tersebut akan mengalami kegagalan disebabkan oleh terbatasnya sumber-sumber, pengetahuan, atau risiko di luar kekuasaannya. Tidak terkira proyek-proyek telah gagal secara keseluruhan maupun sebagian, karena orang mengabaikan tanda-tanda penting dan nyata yang menunjukan kegagalan. Setiap rencana dipengaruhi oleh risiko. Setiap proyek akan tepat waktu dan sesuai anggaran jika tidak ada yang salah. Penting sekali untuk berkosentrasi pada hal-hal yang akan menyebabkan salah dan coba untuk menghindari kesalahan-kesalahan tersebut. Hal ini disebut Manajemen Risiko.

12 PERENCANAAN PROYEK Setelah selesai mengevaluasi proyek dan memutuskan untuk melanjutkan. Pertama, lakukan dengan membuat proposal. Untuk sebuah proyek eksternal, proposal ditulis untuk meyakinkan klien agar membeli proyek dari tim proyek. Untuk proyek internal, manajemen sebaiknya meminta untuk membuat sebuah proposal. Hal ini untuk mendukung tim proyek untuk membuat rencana yang sederhana. Sebuah proposal adalah dokumen yang merinci biaya dan jadwal proyek, serta menjelaskan langkah-langkah yang akan diambil oleh tim proyek untuk menghasilkan produk yang diinginkan. Perencanaan adalah sebuah proses yang berulang-ulang : rencana akan ditinjau secara terus menerus sesuai dengan perkembangan proyek dan sesuai dengan bertambahnya pengetahuan dan pemahaman yang lebih baik dari anggota tim. Perencanaan memang merupakan pekerjaan yang sangat sulit, tetapi harus dilaksanakan sebagaimana mestinya. Banyak proyek menjadi kacau dikarenakan tidak adanya perencanaan.

13 Pendahuluan Perencanaan Proyek adalah langkah awal, sumber daya, biaya dan jadwal yang dibutuhkan untuk menyelesaikan proyek. PPP adalah dokumen internal, tidak perlu ditunjukkan ke user, terutama user luar. Kunci berbagai rencana adalah memecah kegiatan yang diperlukan ke dalam sebuah bagian yang lebih kecil lagi. Rincian struktur kerja (WBS) diawali dengan menyusun komponen-komponen utama proyek. Hal ini merupakan Level 1 dari WBS (Level 0 adalah judul proyek). Untuk proyek software, metode terbaik untuk pemecahan proyek menjadi bagian-bagian utama adalah diawali dengan 7 fase pengembangan software.

14 WBS & Estimation How did you feel when asked
“How long will your project take?” Not an easy answer to give right? At least not if I were are real customer on a real project How can you manage that issue?

15 Partitioning Your Project
You need to decompose your project into manageable chunks ALL projects need this step Divide & Conquer Two main causes of project failure Forgetting something critical Ballpark estimates become targets How does partitioning help this?

16 Project Elements A Project: functions, activities, tasks

17 WBS Chart Example

18 WBS Outline Example 0.0 Retail Web Site 1.0 Project Management
2.0 Requirements Gathering 3.0 Analysis & Design 4.0 Site Software Development 4.1 HTML Design and Creation 4.2 Backend Software 4.2.1 Database Implementation 4.2.2 Middleware Development 4.2.3 Security Subsystems 4.2.4 Catalog Engine 4.2.5 Transaction Processing 4.3 Graphics and Interface 4.4 Content Creation 5.0 Testing and Production

19 WBS Types Process WBS Product WBS Hybrid WBS: both above
a.k.a Activity-oriented Ex: Requirements, Analysis, Design, Testing Typically used by PM Product WBS a.k.a. Entity-oriented Ex: Financial engine, Interface system, DB Typically used by engineering manager Hybrid WBS: both above This is not unusual Ex: Lifecycle phases at high level with component or feature-specifics within phases Rationale: processes produce products

20 Product WBS

21 Process WBS

22 FASE ANALISIS Tujuan dari fase analisis adalah mendefinisikan secara tepat apa yang dapat dilakukan sistem untuk user, dan bagaimana sistem tersebut menyesuaikan dengan lingkungan user. Aktivitas utama (kejadian penting) dari fase ini adalah untuk menghasilkan dokumen yang menjelaskan arti lingkungan sistem, disebut Functional Specifications (FS) / Spesifikasi Fungsi. FS menjelaskan semua tingkah laku sistem dalam bentuk cerita dan gambar. FS juga merupakan kontrak antara User dengan Tim Proyek (PT). Sejumlah uang yang besar mungkin dipertaruhkan, dan user membutuhkan lebih rinci tantang apa yang dapat diberikan dibandingkan apa yang ada di proposal. FS mungkin akan dinegosiasikan dan ditinjau kembali, dan ketika persetujuan dicapai proposal harus ditanda tangani oleh kedua belah pihak. Garis Besar FS (Outline of the FS) Gambaran Sistem / Ikhtisar Sistem (System Overview) Menjelaskan sistem yang akan dibuat. Ingatlah bahwa FS adalah dokumen teknik yang ditujukan untuk pembaca non teknis (user). Cara terbaik untuk menjelaskannya dengan menggunakan gambar

23 Garis Besar FS (Outline of the FS)
Kebutuhan Khusus Sistem (Special System Requirements) Bagian ini menunjukkan kebutuhan-kebutuhan sistem seperti jaringan, kesesuaian, keamanan, ketahanan, dan kemudahan dalam menggunakan sistem. Persoalan yang rumit seperti respon (jumlah waktu dalam detik yang dibutuhkan komputer untuk menjawab), throughput (jumlah total pekerjaan yang diselesaikan komputer dalam jangka waktu tertentu) dan growth / perkembangan (kebutuhan sistem untuk beberapa tahun ke depan) dapat ditunjukkan disini.

24 Pelatihan. Buatlah daftar modul-modul atau topik-topik yang menjadi cover pada masing-masing kursus, dan materi pelatihan yang digunakan. Perubahan Spesifikasi (Specification Changes) Perubahan FS mungkin menyebabkan perubahan ke seluruh item-item yang lain, yang menyebabkan biaya menjadi mahal dan penundaan waktu pengiriman. Perubahan harus diminimalkan. Penerimaan (Acceptance) Salah satu masalah terbesar dalam dunia software adalah user kadang-kadang enggan untuk menerima dan membayar sistem tersebut. Oleh karena itu dalam FS harus dirinci metode penerimaan, dan mengakhirinya dengan baik.

25 RENCANA TES PENERIMAAN
Tujuan dari penerimaan adalah mendapatkan pernyataan tertulis dari user bahwa produk (dalam hal ini sistem) yang dikirim sesuai dengan yang dijanjikan. PERIODE PERCOBAAN ATAU PARALLEL RUN (THE TRIAL PERIOD OR PARALLEL RUN) Periode percobaan atau parallel run adalah pendekatan yang paling umum untuk penerimaan. Menggunakan pendekatan ‘Periode Percobaan’ tim proyek mudah memasang sistem baru untuk dicoba oleh user. Pendekatan ‘Parallel Run’ menambahkan dimensi untuk peralihan sistem lama yang sudah berjalan dengan baik sebagai perbandingan dan cadangan.

26 Dalam kasus ini klien menggunakan sistem baru selama ‘X’ hari
Dalam kasus ini klien menggunakan sistem baru selama ‘X’ hari. Jika tidak ada masalah maka user menerimanya, jika ada masalah maka tim proyek berusaha memperbaikinya dan melakukan kembali percobaan selama ‘X’ hari. PENERIMAAN YANG LENGKAP SEDIKIT DEMI SEDIKIT (SOLUTION : A THOROUGH BUT PIECEMEAL ACCEPTANCE) Pendekatan yang lebih baik adalah menemukan serangkaian tes yang mendemonstrasikan semua fungsi yang dijanjikan. Penerimaan akan dilakukan secara resmi melalui seluruh tes ini kepada pelanggan. Keberhasilan tes diakhiri satu per satu. Jika sebuah tes gagal, Tim proyek dengan penuh harapan memperbaiki masalah langsung di tempat pengujian. Jika itu masalah utama maka tes ditunda sampai masalah dapat diperbaiki. Dalam teori hanya tes yang gagal yang diulang, walaupun user memiliki hak untuk menjalankan kembali tes yang diterimanya sesudah perbaikan. Serangkaian tes dan perintah yang dijalankan sistem disebut Rencana Tes Penerimaan (Acceptance Test Plan / ATP).

27 Pendekatan ini mempunyai manfaat sebagai berikut :
Dapat mendemonstrasikan semua fungsi yang dijanjikan. Sebuah tindakan yang menyebabkan masalah selalu diketahui. User tidak merasa takut tentang semuanya. Kerugian utama dari pendekatan ini adalah memerlukan banyak pekerjaan untuk menulis ATP. Dan lagi user mungkin tidak lazim dengan pendekatan ini. Tetapi hal ini harus dibiasakan dari metode baru sebelumnya.

28 CONTOH MACAM – MACAM PROYEK IS atau IT
Proyek Analisis Kebutuhan Sistem Informasi Proyek Perancangan Sistem Data Proyek Pengembangan Software Proyek Implementasi Software Aplikasi Proyek Konstruksi Jaringan Komputer Proyek Perancangan Sistem Berbasis Internet Proyek Audit Sistem dan Teknologi Informasi…DLL

29 K a r a k t e r i s t i k S p e s i f i k PROYEK IS & IT
Memiliki atau menyelesaikan persoalan yang bersifat tak nampak secara langsung, seperti proyek rekayasa software, algorithma, file (berkas/dokumen), data dan sebagainya. Menggunakan perangkat teknologi yang mempunyai umur ekonomis pendek, akibat perkembangan yang begitu pesat seperti perkembangan processor, printer, LCD / Monitor dsb. Memerlukan Sumber Daya yang spesifik dengan kompetensi maupun keahlian yang variatif, seperti Data Base Admin, programmer, system analyst, network expert,

30 SELESAI