Mutiara Adi Saputri: Fase Pengelolaan Proyek Sistem Informasi

Pengembangan Sistem : Enam Fase Analisis dan Desain Sistem
*Apa saja fase siklus hidup pengembangan system?
Tidak semua kesalahan sama besarnya. Tingkat kesalahan computer bisa beragam dari kecil hingga yang paling menyedihkan. Contoh ini menunjukkan betapa pentingnya perencanaan, khususnya ketika organisasi mencoba meluncurkan system baru. Cara terbaik untuk menghindari kesalahan tertentu adalah dengan menerapkan analisis dan desain system.
*Tujuan Sistem
Bagaimana seharusnya mendefenisikan sebuah system dan apa tujuannya??
Sistem ialah kumpulan dari komponen-komponen yang berhubungan yang berinteraksi untuk melakukan suatu tugas guna mencapai suatu tujuan. Sekalipun tidak bekerja dengan sangat baik, tetap saja merupakan suatu system.
Tujuan analisis dan desain system adalah untuk memastikan bagaimana suatu system bekerja dan kemudian mengambiltindakan untuk menjadikannya lebih baik.
*Membuat Proyek Berjalan: Bagaimana Memulainya dan siapa saja yang terlibat?
Keyakinan bahwa sesuatu yang buruk harus diubah merupakan awal untuk melakukan sebuah proyek. Ada 3 jenis partisipan dalam proyek :
• Pengguna : Sistem yang seadang dibahas harus selalu dikembangkan dengan banyak berkonsultasi dengan pengguna atau pelanggan. Jika keterlibatan pengguna tidak memadai makas system akan gagal Karen kurangnya penerimaan.
• Manajemen : Manager dalam organisasi juga harus diajak berkonsultasi mengenai system.
• Staf Teknis : Anggota Departemen Sitem Informasi (SI) perusahaan, yang terdiri tas analisis dan programmer system harus dilibatkan. Alasanya, karena merekalah yang mengeksekusi proyek.
Proyek yang rumit memerlukan satu atau beberapa analisis sitem. Analisis system ialah seorang spesialis informasi yang melakukan analisis , desain, dan implementasi sitem. Tugas analisis ialah mempelajari kebutuhan komunikasi dan informasi dan menentukan perubahan apa yang diperlukan untuk mengirimkan informasi yang lebih baik kepada yang memerlukan.
*Enam Fase Analisis dan Desain Sistem
Apa saja enam fase siklus hidup pengembangan system??
Analisis dan desain system merupakan prosedur pemecahan maslah yang terdiri dari enam fase untuk meneliti system informasi dan meningkatkannya.Keenam fase tersebut membentuk apa yang disebut siklus hidup pengembangan system. Siklus hidup pengembangan system (SDLC) adalah proses langkah demi langkah yang diikuti oleh banyak organisasi selama analisis dan desain system.
Fase Pertama : Melakukan Investigasi Awal
Empat langkah yang ada pada fase pertama?
Tujuan dari fase pertama ini adalah melakukan analisis awal, mencari alternative solusi, mendeskripsikan biaya dan keuntungn, dan menyerahkan rencana awal dengan beberapa rekomendasi. Empat langkah fase pertama ialah:
1. Melakukan analisis awal, anda perlu mencari apa yang menjadi tujuan organisasi dan sifat serta cakupan masalah, selanjutnya melihat apakah masalah yang dipelajari cocok dengan tujuan tersebut.
2. Mengajukan solusi-solusi alternative, Solusi-solusi alternative bisa diperoleh dengan mewawancarai orang dalm organisasi, klien ayau pelanggan yang terpengaruh oleh system, pemasok dan konsultan.
3. Mendeskripsikan biaya dan keuntungan , anda perlu mendaftarkan biaya maupun keuntungan secara terperinci. Biaya akan tergantung dari keuntungan yang bisa menawarkan penghematan.
4. Menyerahkan rencana awal, Semua yang anda temukan digabung dalam suatu laporan tertulis, pembaca laporan ini bisa saja eksekutif yang punya wewenang untuk memutuskan dan menjalankan proyek. Anda harus mendeskripsikan solusi-solusi potensial, biaya, dan keuntungan dan memberikan rekomendasi bagi anda.
Fase Kedua : Menganalisis Sistem
Tiga langkah dalam menganalisis system
Tujuan dari fase kedua ini adalah mengumpulkan data, menganalisis data, dan menuliskan laporan. Dalam fase ini, anda akan mengikuti arahan dari pihak managemen setelah mereka membaca laporan (fase pertama). Pihak manajemen memberi perintah untuk menganalisis atau mepelajari system yang sudah ada untuk memahami perbedaan system baru dengan system yang sudah ada. Tiga langkah pada tahap ini ialah:
1. Mengumpulkan data, dalam upaya mengumpulkan data, anda akan meninjau dokumen tertulis, mewawancarai pegawai dan manager, membuat kuesioner dan mengobservasi rang dan proses-proses di tempat kerja.
2. Menganalisa data, data yang telah dikumpulkan kemudian dianalisis. Ada banyak piranti analitik yang dapat dipakai, piranti pemodelan memungkinkan analisis system menampilkan representasi system dalam bentuk gambar, misal data flow diagram atau diagram aliran data. Dan Perangkat CASE (Computer Aided Software Engineering) adalah program yang mengotomatisasi berbagai aktivitas SDLC. Contoh programnya ialah Analyst Pro, Visible Analyst dan System Architect.
3. Menulis laporan, perlu membuat laporan setelah selesai melakukan analisis. Ada 3 bagian, yang pertama, harus menjelaskan cara bekerja system yang sudah ada. Kedua, harus menjelaskan masalah-masalah pasa system yang ada. Ketiga harus mendeskripsikan ketentuan-ketentuan untuk system baru dan memberikan rekomendasi tentang apa yang akan dilakukan selanjutnya.
Fase Ketiga : Mendesain Sistem
Tiga langkah ketika mendesain system
Tujuan fase ini adalah membuat desai awal, lalu desain yang detail, dan membuat laporan.
1. Membuat desain awal, desin awal mendeskripsikan kpabilitas fungsional secar umum dari system system informasi yang diusulkan. Perangkat yang digunakan pada fase ini adalah perangkat CASE dan perangkat lunak managemen proyek. Prototyping juga digunakan pada tahap ini,prototyping ialah pengguna workstation, perangkat CASE dan aplikasi perangkat lunak lain untuk membuat model kerja dari komponen system sehingga system baru bisa segera diuji dan dievaluasi. Jadi prototype adalah system dengan kemapuan kerja terbatas yang dikembangkan untuk menguji konsep-konsep desain.
2. Membuat desain yang detail, desain yang detail menggambarkan bagaimana sistem informasi yang diusulkan mampu memberikan kapabilitas yang digambarkan secara umum dalam desain awal.
3. Menulis laporan, semua pekerjaan dala desain awal dan desain yang detail akan dikemas dalam laporan yang terperinci. Anda bisa melakukan persentasi atau diskusi saat menyerahkan laporan ini kepada manajemen senior.
Fase Keempat : Mengembnagkan Sistem
Tiga langkah yang diperlukan dalam mengembangkan system
1. Mengembangkan atau mendapatkan perangkat lunak, analisis system harus membuat keputusan yang disebut keputusan “membuat-atau-membeli’. Dalam keputusan tersebut, anda menentukan apakah akan membuat program – menulis sendiri – atau embelinya, yang artinya hanya tinggal membeli paket perangkat lunak yang sudah ada.
2. Mendapatkan perangkat lunak, setelah memilih perangkat lunak, maka selanjutnya meng-uprade perangkat keras untuk menjalankan perangkat lunak tersebut. Namun bisa saja system tidak membutuhkan perangkat keras, atau perangkat keras tersebut dapat disewa tanpa harus dibeli.
3. Menguji system, dengan perangkat lunak dan perangkat keras yang telah diperoleh,maka dilakukan pengujian. Biasanya dilakukan dalam 2 tahap, yaitu :
• Pengujian unit : kinerja dari masing-masing bagian diteliti dengan menggunakan data uji (disusun atau sampel). Jika program ditulis sebagai usaha kerja sama dari banyak programmer, maka masing-masing bagian dari program diuji terpisah.
• Pengujian system : bagian-bagian dihubungkan bersama-sama dengan menggunakan data uji untuk mengetahui apakah bagian-bagian itu dapat bekerja sama. System juga dapat diuji dengan data sesungguhnya dari organisasi.
Fase Kelima : Mengimplementasikan system
1. Konversi ke system baru, proses transisi dari system informasi yang lama ke yang baru, melibatkan konversi perangkat keras, perangkat lunak, dan file. Ada 4 strategi untuk melakukan konversi,yaitu :
• Implementasi langsung : pengguna hanya berhenti menggunakan system yang lama dan mulai mengguanakn yang baru.
• Implementasi parallel : Sistem lama dan system yang baru berjalan berdampingan sampai system baru menunjukkan keandalannya di saat system lama tidak berfungsi lagi.
• Implementasi bertahap : bagian-bagian dari system baru dibuat dalam fase terpisah-entah waktu yang berbeda(parallel) atau sekaligus dalam kelompok-kelompok (langsung).
• Implementasi pilot : seluruh system dicoba, namun hanya oleh beberapa pengguna. Stelah keandalannya terbukti barulah system bisa diimplementasikan pada pengguna lainnya.
2. Melatih pengguna, ada banyak piranti yang bisa digunkan membuat pengguna membuat pengguna mengenal system baru dengan baik,dari dokumentasi hingga video tape hingga pelatiah diruang kelas secara langsung ataupun satu per satu.
Fase Keenam : Memelihara Sistem
Pemeliharaan system ialah menyesuaikan dan meningkatkan system dengan cara melakukan audit dan evaluasi secara periodic dan dengan membuat perubahan berdasarkan kondisi-kondisi baru. Meskipun pengonversian sudah lengkap, bahkan pengguna sudah dilatih, system tidak bisa berjalan dengan sendirinya. Inilah tahap dimana system harus dimonitor untuk memastikan bahwa system itu berhasil. Pemeliharaan tidak hanya menjaga agar mesin tetap berjalan, namun juga meng-upgrade dan meng-update system agar bisa mengikuti perkembangan produk, jasa, layanan, peraturan pemerintah, dan ketentuan lain yang baru.
Setelah beberapa saat, biaya pemeliharaan akan meningkat seiring makin banyaknya usaha untuk mempertahankan system agar tetap responsive terhadap kebutuhan pengguna. Dalam beberapa hal, biaya pemeliharaan ini bisa membengkak, menandakan bahwa sekaranglah saat yang tepat untuk memulai lagi SDLC.
*Apa saja fase siklus hidup pengembangan system?
Tidak semua kesalahan sama besarnya. Tingkat kesalahan computer bisa beragam dari kecil hingga yang paling menyedihkan. Contoh ini menunjukkan betapa pentingnya perencanaan, khususnya ketika organisasi mencoba meluncurkan system baru. Cara terbaik untuk menghindari kesalahan tertentu adalah dengan menerapkan analisis dan desain system.
Bagaimana seharusnya mendefenisikan sebuah system dan apa tujuannya??
Sistem ialah kumpulan dari komponen-komponen yang berhubungan yang berinteraksi untuk melakukan suatu tugas guna mencapai suatu tujuan. Sekalipun tidak bekerja dengan sangat baik, tetap saja merupakan suatu system.
Tujuan analisis dan desain system adalah untuk memastikan bagaimana suatu system bekerja dan kemudian mengambiltindakan untuk menjadikannya lebih baik.
*Membuat Proyek Berjalan: Bagaimana Memulainya dan siapa saja yang terlibat?
Keyakinan bahwa sesuatu yang buruk harus diubah merupakan awal untuk melakukan sebuah proyek. Ada 3 jenis partisipan dalam proyek
Pengertian RPL sendiri adalah suatu disiplin ilmu yang membahas semua aspek produksi perangkat lunak, mulai dari tahap awal yaitu analisa kebutuhan pengguna, menentukan spesifikasi dari kebutuhan pengguna, disain, pengkodean, pengujian sampai pemeliharaan sistem setelah digunakan. Dari pengertian ini jelaslah bahwa RPL tidak hanya berhubungan dengan cara pembuatan program komputer. Pernyataan ”semua aspek produksi” pada pengertian di atas, mempunyai arti semnua hal yang berhubungan dengan proses produksi seperti manajemen proyek, penentuan personil, anggaran biaya, metode, jadwal, kualitas sampai dengan pelatihan pengguna merupakan bagian dari RPL.
I. TUJUAN REKAYASA PERANGKAT LUNAK
Secara umunmm tujuan RPL tidak berbeda dengan bidang rekayasa yang lain. Hal ini dapat kita lihat pada Gambar di bawah ini.
Gambar 1. Tujuan RPL
Dari Gambar di atas dapat diartikan bahwa bidang rekayasa akan selalu berusaha menghasilkan output yang kinerjanya tinggi, biaya rendah dan waktu penyelesaian yang tepat. Secara leboih khusus kita dapat menyatakan tujuan RPL adalah:
a. memperoleh biaya produksi perangkat lunak yang rendah
b. menghasilkan pereangkat lunak yang kinerjanya tinggi, andal dan tepat waktu
c. menghasilkan perangkat lunak yang dapat bekerja pada berbagai jenis platform
d. menghasilkan perangkat lunak yang biaya perawatannya rendah
II. RUANG LINGKUP
Sesuai dengan definisi yang telah disampaikan sebelumnya, maka ruang lingkup RPL dapat digambarkan sebagai berikut:
Gambar 2. Ruang lingkup RPL (Abran et.al., 2004).
–         software Requirements berhubungan dengan spesifikasi kebutuhan dan persyaratan perangkat lunak
–         software desain mencakup proses penampilan arsitektur, komponen, antar muka, dan karakteristik lain dari perangkat lunak
–         software construction berhubungan dengan detail pengembangan perangkat lunak, termasuk algoritma, pengkodean, pengujian dan pencarian kesalahan
–         software testing meliputi pengujian pada keseluruhan perilaku perangkat lunak
–         software maintenance mencakup upaya-upaya perawatan ketika perangkat lunak telah dioperasikan
–         software configuration management berhubungan dengan usaha perubahan konfigurasi perangkat lunak untuk memenuhi kebutuhan tertentu
–         software engineering management berkaitan dengan pengelolaan dan pengukuran RPL, termasuk perencanaan proyek perangkat lunak
–         software engineering tools and methods mencakup kajian teoritis tentang alat bantu dan metode RPL
–         software engineering process berhubungan dengan definisi, implementasi pengukuran, pengelolaan, perubahan dan perbaikan proses RPL
–         software quality menitik beratkan pada kualitas dan daur hidup perangkat lunak
III. REKAYASA PERANGKAT LUNAK DAN DISIPLIN ILMU LAIN
Cakupan ruang lingkup yang cukup luas, membuat RPL sangat terkait dengan disiplin dengan bidang ilmu lain. tidak saja sub bidang dalam disiplin ilmu komputer namun dengan beberapa disiplin ilmu lain diluar ilmu komputer.
Hubungan keterkaitan RPL dengan ilmu lain dapat dilihat pada gambar dibawah ini
Gambar 3. Keterkaitan RPL dengan bidang ilmu lain.
–         bidang ilmu manajemen meliputi akuntansi, finansial, pemasaran, manajemen operasi, ekonomi, analisis kuantitatif, manajemen sumber daya manusia, kebijakan, dan strategi bisnis
–         bidang ilmu matematika meliputi aljabar linier, kalkulus, peluang, statistik, analisis numerik, dan matematika diskrit
–         bidang ilmu manajemen proyek meliputi semua hal yang berkaitan dengan proyek, seperti ruang lingkup proyek, anggaran, tenaga kerja, kualitas, manajemen resiko dan keandalan, perbaikan kualitas, dan metode-metode kuantitatif
–         bidang ilmu ergonomika menyangkut hubungan ( interaksi) antar manusia dengan komponen-komponen lain dalam sistem komputer
–         bidang ilmu rekayasa sistem meliputi teori sistem, analisis biaya-keuntungan, pemodelan, simulasi, proses, dan operasi bisnis
IV. PERKEMBANGAN REKAYASA PERANGKAT LUNAK
Meskipun baru dicetuskan pada tahun 1968, namun RPL telah memiliki sejarah yang cukup yang panjang. Dari sisi disiplin ilmu, RPL masih reklatif muda dan akan terus berkembang.
Arah perkembangan yang saat ini sedang dikembangkan antara lain meliputi :

Tahun	Kejadian
1940an	Komputer pertama yang membolehkan pengguna menulis kode program langsung
1950an	Generasi awal interpreter dan bahasa macro Generasi pertama compiler
1960an	Generasi kedua compiler Komputer mainframe mulai dikomersialkan Pengembangan perangkat lunak pesanan Konsep Software Engineering mulai digunakan
1970an	Perangkat pengembang perangkat lunak Perangkat minicomputer komersial
1980an	Perangkat Komputer Personal (PC) komersial Peningkatan permintaan perangkat lunak
1990an	Pemrograman berorientasi obyek (OOP) Agile Process dan Extreme Programming Peningkatan drastis kapasitas memori Peningkatan penggunaan internet
2000an	Platform interpreter modern (Java, .Net, PHP, dll) Outsourcing

V. METODE REKAYASA PERANGKAT LUNAK
Pada rekayasa perangkat lunak, banyak model yang telah dikembangkan untuk membantu proses pengembangan perangkat lunak. Model-model ini pada umumnya mengacu pada model proses pengembangan sistem yang disebut System Development Life Cycle (SDLC) seperti terlihat pada Gambar berikut ini.
Gambar 4. System Development Life Cycle (SDLC).

Kebutuhan terhadap definisi masalah yang jelas. Input utama dari setiap model pengembangan perangkat lunak adalah pendefinisian masalah yang jelas. Semakin jelas akan semakin baik karena akan memudahkan dalam penyelesaian masalah. Oleh karena itu pemahaman masalah seperti dijelaskan pada Bab 1, merupakan bagian penting dari model pengembangan perangkat lunak.
Tahapan-tahapan pengembangan yang teratur. Meskipun model-model pengembangan perangkat lunak memiliki pola yang berbeda-beda, biasanya model-model tersebut mengikuti pola umum analysis – design – coding – testing – maintenance
Stakeholder berperan sangat penting dalam keseluruhan tahapan pengembangan. Stakeholder dalam rekayasa perangkat lunak dapat berupa pengguna, pemilik, pengembang, pemrogram dan orang-orang yang terlibat dalam rekayasa perangkat lunak tersebut.
Dokumentasi merupakan bagian penting dari pengembangan perangkat lunak. Masing-masing tahapan dalam model biasanya menghasilkan sejumlah tulisan, diagram, gambar atau bentuk-bentuk lain yang harus didokumentasi dan merupakan bagian tak terpisahkan dari perangkat lunak yang dihasilkan.
Keluaran dari proses pengembangan perangkat lunak harus bernilai ekonomis. Nilai dari sebuah perangkat lunak sebenarnya agak susah di-rupiah-kan. Namun efek dari penggunaan perangkat lunak yang telah dikembangkan haruslah memberi nilai tambah bagi organisasi. Hal ini dapat berupa penurunan biaya operasi, efisiensi penggunaan sumberdaya, peningkatan keuntungan organisasi, peningkatan “image” organisasi dan lain-lain.

VI. TAHAPAN REKAYASA PERANGKAT LUNAK
Meskipun dalam pendekatan berbeda-beda, namun model-model pendekatan memiliki kesamaan, yaitu menggunaka pola tahapan analysis – design – coding(construction) – testing – maintenance.
1. Analisis sistem adalah sebuah teknik pemecahan masalah yang menguraikan sebuah sistem menjadi komponen-komponennya dengan tujuan mempelajari seberapa bagus komponen-komponen tersebut bekerja dan berinteraksi untuk meraih tujuan mereka.
Analisis mungkin adalah bagian terpenting dari proses rekayasa perangkat lunak. Karena semua proses lanjutan akan sangat bergantung pada baik tidaknya hasil analisis. Ada satu bagian penting yang biasanya dilakukan dalam tahapan analisis yaitu pemodelan proses bisnis.
2. Model proses adalah model yang memfokuskan pada seluruh proses di dalam sistem yang mentransformasikan data menjadi informasi (Harris, 2003). Model proses juga menunjukkan aliran data yang masuk dan keluar pada suatu proses. Biasanya model ini digambarkan dalam bentuk Diagram Arus Data (Data Flow Diagram / DFD). DFD meyajikan gambaran apa yang manusia, proses dan prosedur lakukan untuk mentransformasi data menjadi informasi.
3. Disain perangkat lunak adalah tugas, tahapan atau aktivitas yang difokuskan pada spesifikasi detil dari solusi berbasis computer (Whitten et al, 2004).
Disain perangkat lunak sering juga disebut sebagai physical design. Jika tahapan analisis sistem menekankan pada masalah bisnis (business rule), maka sebaliknya disain perangkat lunak fokus pada sisi teknis dan implementasi sebuah perangkat lunak (Whitten et al, 2004).
Output utama dari tahapan disain perangkat lunak adalah spesifikasi disain. Spesifikasi ini meliputi spesifikasi disain umum yang akan disampaikan kepada stakeholder sistem dan spesifikasi disain rinci yang akan digunakan pada tahap implementasi. Spesifikasi disain umum hanya berisi gambaran umum agar stakeholder sistem mengerti akan seperti apa perangkat lunak yang akan dibangun. Biasanya diagram USD tentang perangkat lunak yang baru merupakan point penting dibagian ini. Spesifikasi disain rinci atau kadang disebut disain arsitektur rinci perangkat lunak diperlukan untuk merancang sistem sehingga memiliki konstruksi yang baik, proses pengolahan data yang tepat dan akurat, bernilai, memiliki aspek user friendly dan memiliki dasar-dasar untuk pengembangan selanjutnya.
Desain arsitektur ini terdiri dari desain database, desain proses, desain user interface yang mencakup desain input, output form dan report, desain hardware, software dan jaringan. Desain proses merupakan kelanjutan dari pemodelan proses yang dilakukan pada tahapan analisis.
4. Konstruksi adalah tahapan menerjemahkan hasil disain logis dan fisik ke dalam kode-kode program komputer.
5. Pengujian sistem melibatkan semua kelompok pengguna yang telah direncanakan pada tahap sebelumnya. Pengujian tingkat penerimaan terhadap perangkat lunak akan berakhir ketika dirasa semua kelompok pengguna menyatakan bisa menerima perangkat lunak tersebut berdasarkan kriteria-kriteria yang telah ditetapkan.
6. Perawatan dan Konfigurasi. Ketika sebuah perangkat lunak telah dianggap layak untuk dijalankan, maka tahapan baru menjadi muncul yaitu perawatan perangkat lunak. Ada beberapa tipe perawatan yang biasa dikenal dalam dunia perangkat lunak seperti terlihat pada diagram di Gambar di bawah ini :
Gambar 5. Tipe-tipe perawatan.

Tipe perawatan corrective dilakukan jika terjadi kesalahan atau biasa dikenal sebagai bugs. Perawatan bisa dilakukan dengan memperbaiki kode program, menambah bagian yang dirasa perlu atau malah menghilangkan bagian-bagian tertentu.
Tipe perawatan routine biasa juga disebut preventive maintenance dilakukan secara rutin untuk melihat kinerja perangkat lunak ada atau tidak ada kesalahan.
Tipe perawatan sistem upgrade dilakukan jika ada perubahan dari komponen-komponen yang terlibat dalam perangkat lunak tersebut. Sebagai contoh perubahan platform sistem operasi dari versi lama ke versi baru menyebabkan perangkat lunak harus diupgrade.
PENGERTIAN REKAYASA PERANGKAT LUNAK
Istilah Rekayasa Perangkat Lunak (RPL) secara umum disepakati sebagai terjemahan dari istilah Software Engineering. Istilah Software Engineering mulai dipopulerkan tahun 1968 pada Software Engineering Conference yang diselenggarakan oleh NATO. Sebagian orang mengartikan RPL hanya sebatas pada bagaimana membuat program komputer. Padahal ada perbedaan yang mendasar antara perangkat lunak (software) dan program komputer.
Perangkat lunak adalah seluruh perintah yang digunakan untuk memproses informasi. Perangkat lunak dapat berupa program atau prosedur.
Program adalah kumpulan perintah yang dimengerti oleh komputer sedangkan prosedur adalah perintah yang dibutuhkan oleh pengguna dalam memproses informasi (O’Brien, 1999). Pengertian RPL sendiri adalah sebagai berikut: Suatu disiplin ilmu yang membahas semua aspek produksi perangkat lunak, mulai dari tahap awal yaitu analisa kebutuhan pengguna, menentukan spesifikasi dari kebutuhan pengguna, disain, pengkodean, pengujian sampai pemeliharaan sistem setelah digunakan. Jelaslah bahwa RPL tidak hanya berhubungan dengan cara pembuatan program komputer. Pernyataan “semua aspek produksi” pada pengertian di atas, mempunyai arti semua hal yang berhubungan dengan proses produksi seperti manajemen proyek, penentuan personil, anggaran biaya, metode, jadwal, kualitas sampai dengan pelatihan pengguna merupakan bagian dari RPL.
5. METODE REKAYASA PERANGKAT LUNAK
Ketika kita bekerja dengan komputer seperti pada kita membutuhkan serangkaian tahapan dan cara-cara tertentu agar dapat menghasilkan sesuatu yang menjadi harapan kita. Demikian juga dalam rekayasa perangkat lunak, diperlukan tahapan-tahapan kerja yang harus dilalui. Rekayasa perangkat lunak yang sukses tidak hanya membutuhkan kemampuan komputasi seperti algoritma, pemrograman, dan basis data yang kuat, namun juga perlu penentuan tujuan yang baik, identifikasi cara penyelesaian, metode pengembangan, urutan aktifitas, identifikasi kebutuhan sumberdaya, dan faktor-faktor lain. Hal-hal seperti ini terkait dengan apa yang disebut dengan metode rekayasa perangkat lunak.
Pada rekayasa perangkat lunak, banyak model yang telah dikembangkan untuk membantu proses pengembangan perangkat lunak. Model-model ini pada umumnya mengacu pada model proses pengembangan sistem yang disebut System Development Life Cycle (SDLC) seperti terlihat pada Gambar 2.2.
Setiap model yang dikembangkan mempunyai karakteristik sendirisendiri. Namun secara umum ada persamaan dari model-model ini, yaitu:
• Kebutuhan terhadap definisi masalah yang jelas. Input utama dari setiap model pengembangan perangkat lunak adalah pendefinisian masalah yang jelas. Semakin jelas akan semakin baik karena akan memudahkan dalam penyelesaian masalah. Oleh karena itu pemahaman masalah seperti dijelaskan pada Bab 1, merupakan bagian penting dari modelpengembangan perangkat lunak.
• Tahapan-tahapan pengembangan yang teratur. Meskipun model-model pengembangan perangkat lunak memiliki pola yang berbeda-beda, biasanya model-model tersebut mengikuti pola umum analysis – design – coding – testing – maintenance.
• Stakeholder berperan sangat penting dalam keseluruhan tahapan pengembangan. Stakeholder dalam rekayasa perangkat lunak dapat berupa pengguna, pemilik, pengembang, pemrogram dan orang-orang yang terlibat dalam rekayasa perangkat lunak tersebut.
• Dokumentasi merupakan bagian penting dari pengembangan perangkat lunak. Masing-masing tahapan dalam model biasanya menghasilkan sejumlah tulisan, diagram, gambar atau bentuk-bentuk lain yang harus didokumentasi dan merupakan bagian tak terpisahkan dari perangkat lunak yang dihasilkan.
• Keluaran dari proses pengembangan perangkat lunak harus bernilai ekonomis. Nilai dari sebuah perangkat lunak sebenarnya agak susah dirupiah- kan. Namun efek dari penggunaan perangkat lunak yang telah dikembangkan haruslah memberi nilai tambah bagi organisasi. Hal ini dapat berupa penurunan biaya operasi, efisiensi penggunaan sumberdaya, peningkatan keuntungan organisasi, peningkatan “image” organisasi dan lain-lain.
Ada banyak model pengembangan perangkat lunak, antara lain The Waterfall Model, Joint Application Development (JAD), Information Engineering (IE), Rapid Application Development (RAD) termasuk di dalamnya Prototyping, Unified Process (UP), Structural Analysis and Design (SAD) dan Framework for the Application of System thinking (FAST). Pada buku ini akan dibahas tiga model pengembangan yaitu The Waterfall Model, Prototyping, dan Unified Processs (UP).

TUJUH FASE PROYEK SOFTWARE
Ada 7 fase dari proyek software, yaitu :
1. DEFINITION
2. ANALYSIS
3. DESIGN
4. PROGRAMMING
5. SYSTEM TEST
6. ACCEPTANCE
7. OPERATION
Proyek software sama dengan membangun sebuah rumah
DEFINITION DEFINISIKAN RUMAH YANG AKAN DIBANGUN
ANALYISIS SPESIFIKASI RUMAH
DESIGN ARSITEK
PROGRAMMING KONSTRUKSI RUMAH
SYSTEM TEST BASEMENT, LANTAI 1, 2, ….
ACCEPTANCE RUMAH SUDAH SELESAI
OPERATION RUMAH SUDAH DAPAT DITEMPATI
Pengelolaan Proyek Sistem Informasi
BAB 2
FASE DEFINISI
Memahami Masalah User
2.1. PENDAHULUAN
Tujuan dari fase definisi adalah untuk memahami dengan baik masalah-masalah yang dihadapi oleh user dalam memperkirakan biaya dan waktu penyelesaian proyek.
Ada 3 aktifitas utama yang harus dilakukan dalam Fase Definisi :
Pertama
Anda harus memahami dengan baik masalah-masalah yang dihadapi oleh user dan apa saja yang dibutuhkan untuk menyelesaikan masalah tersebut (KEBUTUHAN).
Kedua
Anda harus memutuskan proyek akan dilaksanakan atau tidak.
Jika keputusannnya adalah melaksanakan proyek tersebut, Anda harus dapat menganalisis semua risiko-risiko yang mungkin terjadi yang dapat menggagalkan proyek tersebut. Analisis ini sangat membantu dalam penulisan PROPOSAL yang berisi rincian menganai 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.
Pertama, menulis Requirement Document (RD), yaitu dokumen yang berisi rincian kebutuhan user. Dokumen RD harus jelas dan lengkap, sehingga Tim Proyek (Project Tem (PT)) dapat memahami seluruh masalah-masalah yang dihadapi oleh user dan dapat memperkirakan biaya penyelesaian proyek tersebut.. Kejadian penting pertama yang akan Anda hadapi 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
Anda harus memberikan perkiraan-perkiraan ini kepada user dalam bentuk PROPOSAL.
Seberapa jauh perkiraan-perkiraan tersebut dapat dipertanggung jawabkan ? Ada dua alasan dalam hal ini. Pertama, kita tidak begitu ahli dalam memperkirakan sesuatu. Kedua, perkiraan-perkiraan tersebut dibuat pada saat masih dalam tahap pendefinisian masalah, dimana pada saat itu baru sebagian kecil informasi yang kita peroleh dari masalah yang sedemikian luas.
Jika anda tidak yakin dengan kebutuhan-kebutuhan yang telah digambarkan secara akurat dalam dokumen RD, disarankan untuk membagi proyek tersebut menjadi 2 tahap : Fase Analisis sebagai proyek pertama diikuti dengan fase sebelumnya sebagai proyek kedua.
Pada saat pendefinisian, proposal anda hanya akan menjadi analisis saja, dan ini disebut PROPOSAL ANALISIS. Setelah analisis akan ada PROPOSAL PENGEMBANGAN (Lihat bab 3). Kedua hal ini disebut dengan dua fase proposal. Kejadian penting yang terdapat disini adalah pembelian proposal oleh user.
2.2. 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 anda butuhkan dan tidak lebih. Tim proyek interviewer berkewajiban untuk mempelajari semua bisnis user, memahami teknologi user, dan mengajukan pertanyaan-pertanyaan.
Masalah terbesar berkaitan dengan pemakai akhir (end-user) yang sesungguhnya petugas pemasukan data atau petugas pengirim barang yang berada di gudang. Seringkali manajer atau supervisor mengatakan bahwa pemakai akhir sangat sibuk dan tidak mampu untuk memberikan informasi yang dapat dipercaya. Terkadang manajer merasa dilangkahi atau diremehkan jika anda berhubungan langsung dengan pemakai akhir yang berada di departemen mereka. 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.
Siapkan rencana untuk melakukan wawancara. Pelajari tentang bisnis yang mereka lakukan, dan tulislah pertanyaan-pertanyaan yang akan diajukan. 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.
Hal-hal yang terdapat dalam RD
Berikut ini adalah bagian-bagian dari RD :
1. Pendahuluan. Identifikasi perusahaan (user) dan juga penjual 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.
2. Tujuan Proyek. Sebuah pernyataan singkat mengapa kita mengajukan proposal untuk pengembangan proyek. Batasan-batasan utama dalam penggunaan waktu dan keuangan dapat juga disebutkan.
3. Fungsi-fungsi Utama. Pernyataan singkat mengenai bagaimana sistem berfungsi berdasarkan tujuan proyek yang telah ditetapkan.
4. Keluaran Umum. Penjelasan secara singkat tentang informasi yang dibutuhkan dari sistem.
5. 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.
6. 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).
7. 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.
8. Pengoperasian dan Lingkungan. Dimana komputer akan ditempatkan, dimana terminal-terminal yang interaktif ditempatkan, dan siapa yang akan menggunakannya.
9. 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.
10. 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.
11. Pengantarmukaan dengan Pemakai. Rincikan pengalaman-pengalaman yang dibutuhkan user dalam menggunakan komputer, jelaskan bagaimana menangani sistem kapada user yang baru.
12. 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.
13. Pemeliharaan dan Dukungan. Jaminan-jaminan yang dibutuhkan : berapa lama, sampai kapan, bagaimana pengiriman.
14. Dokumentasi dan Pelatihan. Rincikan semua dokumen-dokumen umum dan / atau pelatihan yang dibutuhkan.
15. Keuntungan (hanya RFP). Jika RD adalah RFP dalam situasi yang kompetitif, mintalah data dari penjual yang menjelaskan mengapa dokumen tersebut harus dipilih. Minta data yang relevan dari penjual yang berpengalaman, komitmen, metodologi proyek, contoh-contoh proyek yang sukses, dan referensi dimana anda dapat menghubungi penjual tersebut.
16. Persyaratan dan Kondisi. Menyatakan syarat untuk seleksi, kapan dan bagaimana akan dilakukan.
2.3. TANGGUNG JAWAB USER
Meskipun user tidak menulis RD, dia bertanggung jawab untuk menyediakan pewawancara tim proyek yang dapat dipercaya, dan informasi tepat pada waktunya. User harus dapat mengajukan orang yang mengetahui tentang semua sistem yang ada dan apa saja yang dibutuhkan untuk sistem baru.
2.4. 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 : “Dapatkah sistem ini dibangun secara teknik ? Sayangnya, tidak semuanya mungkin secara teknik, sehingga pertanyaan-pertanyaan untuk dijawab diubah menjadi, “Dengan biaya berapa sistem dapat dibangun, dan apa keuntungannya ?
Dalam suatu studi kelayakan kita mempertimbangkan semua penyelesaian masalah teknis yang mungkin, dan coba untuk memperkirakan biaya dari masing-masing penyelesaian masalah. Untuk suatu proyek yang berukuran besar, kita mempertimbangkan 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.
Perkiraan keuntungan ini mungkin saja mudah, tetapi seharusnya tidak dipergunakan. Manajer proyek tidak hanya harus menjawab “Apakah proyek ini secara teknik 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.
2.5. MANAJEMEN RISIKO
Menurut sejarah, industri pemrosesan data telah membuat reputasi yang buruk sekali karena meremehkan proyek-proyek yang ada. Ketika ditanya tentang alasannya, para ahli pemrosesan data membela diri dengan meberikan pernyataan seperti : “Saya menilai dengan benar berdasarkan fakta-fakta yang diberikan kepada saya.
Alasan yang menumpuk adalah bahwa :
(Pilih satu atau lebih : Si pemakai mengubah pikirannya ….. tidak pernah memberitahukan saya tentang… dan departemen- departemen yang lain menjanjikan ….. dan manajemen tingkat atas mendikte penilaian ….. dengan kata lain, itu bukan kesalahan saya !)
Solusi standar industri untuk semua masalah-masalah ini adalah :
SOLUSI 1. Selidiki masalah-masalah yang ada
SOLUSI 2. Hukum yang tidak bersalah
SOLUSI 3. Promosikan yang tidak terlibat
SOLUSI 4. Kembali ke solusi 1 dan berputar sampai membosankan
2.6. EMPAT LANGKAH MANAJEMEN 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.
Manajemen risiko terdiri dari empat langkah :
Langkah 1. Antisipasi risiko
Langkah 2. Singkirkan risiko yang mungkin terjadi
Langkah 3. Kurangi dampak risiko
Langkah 4. Tetap tenang ketika terjadi kesalahan
Pengelolaan Proyek Sistem Informasi
BAB 3
PERENCANAAN PROYEK
3.1. PENDAHULUAN
Sekarang anda sudah mengevaluasi proyek dan memutuskan untuk melanjutkannya. Pertama, anda harus meyakinkan rekan-rekan lain bahwa proyek sebaiknya dilaksanakan. Hal ini dilakukan dengan membuat proposal. Untuk sebuah proyek eksternal, proposal ditulis untuk meyakinkan klien agar membeli proyek dari tim proyek anda. 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.
3.2. PENDAHULUAN PERENCANAAN PROYEK
(THE PRELIMINARY PROJECT PLAN / PPP)
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.
3.3. RINCIAN STRUKTUR KERJA
(WORK BREAKDOWN STRUCTURES / WBS)
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.
Lihat Gambar 3.1. Rincian Struktur Kerja / WBS
Lihat Gambar 3.2. WBS untuk analisis
Sistem Penomoran WBS
Sistem penomoran dalam WBS seperti pada gambar 3.2 :
– Untuk Level 0 atau judul proyek adalah 0.0.
– Pada Level 1 masing-masing item diberi nomor N.0.
Contoh : 1.0, 2.0, dst.
– Kemudian masing-masing item pada Level 2 dibawah item N.0 pada Level 1 diberi nomor N.1, N.2, dst.
Contoh : di bawah Level 1 item Analysis yang bernomor 2.0, kita mempunyai item 2.1, 2.2, dst.
– Sedangkan untuk Level 3, kita tambahkan titik dan digit dari nomor di Level 2. Sebagai contoh, dibawah 2.1 kita harus menuliskan 2.1.1, 2.1.2, dst.
Kapan Anda Berhenti ?
Pemasukkan nomor pada level terendah menunjukkan tugas atau kegiatan dalam proyek. Anda dapat berhenti merinci sebuah kegiatan jika mengikuti langkah-langkah berikut dengan benar :
1. Beberapa orang (atau grup dari sebuah proyek besar) dapat diberikan tanggung jawab untuk melakukan tugas atau menyelesaikan kegiatan-kegiatan yang dilibatkan.
2. Anda dapat memperoleh perkiraan (berupa orang atau hari) secara garis besar sebagai upaya yang dibutuhkan untuk melaksanakan kegiatan-kegiatan yang terlibat. Hal ini dapat dilakukan dengan memberi tanggung jawab pada setiap orang.
3. Anda dapat menjadwalkan tugas.
4. Tugas-tugas tersebut harus singkat dan dapat diselesaikan.
Sebagai seorang ahli kita dapat menetapkan sebuah tugas kepada Programmer, Analis, atau bahkan Manajer Proyek. Tergantung pada pengalaman dan keahlian dalam membuat perkiraan, analis mungkin hanya memerlukan level 1 dari WBS. Beberapa analis dapat dengan mudah membaca RD untuk proyek ABC (Appendix A) secara keseluruhan. Analis lain untuk merinci membutuhkan sampai Level 2. Seperti pada gambar 3.2, analis lainnya memerlukan sampai Level 3 sebelum mereka dapat memperkirakan secara keseluruhan.
Sebagai contoh Level 3 WBS untuk kotak INTERVIEW dan ANALYZE EXISTING SYSTEMS dapat dilihat pada gambar 3.3.
Lihat Gambar 3.3. WBS Level 3
Para ahli merinci setiap kotak pada level terendah sampai ia dapat memperkirakan berapa upaya yang diperlukan. Perkiraan-perkiraan ini dapat dipakai pada WBS seperti pada gambar 3.4. Sebagai catatan bahwa perkiraan total adalah jumlah dari masing-masing waktu. Hal ini disebut DIRECT time, yaitu jumlah hari yang sesungguhnya dibutuhkan untuk melakukan kegiatan .
Lihat Gambar 3.4. Analysis Level 3
Para ahli tersebut dengan cara yang sama dapat merinci kotak yang lain (DEFINE NEW SYSTEM FUNCTIONS, WRITE FUNCTIONAL SPEC. dan NEGOTIATE FUNCTIONAL SPEC.) dan menambahkan total waktu untuk semua analisis. Kemudian ahli tersebut mengajukan perkiraan dan daftar kegiatan sebelumnya yang dibutuhkan untuk seluruh analisis bagi Manajer Proyek. Orang tersebut bertanggung jawab terhadap perencanaan (mungkin Manajer Proyek untuk proyek berukuran kecil – menengah) kemudian menggabungkan seluruh perkiraan dan daftar kegiatan terdahulu. Ia mungkin mengakhirnya dengan daftar seperti berikut ini :
ACTIFITY EFFORT PRECEDENTS
Definition 20 —————–
Analysis 35 Definition
Design 25 Analysis
Program A (Control) 20 Design
Program B (Registration) 30 Design
Program C (Warehouse) 25 Design
System test 10 Program A, B, C
Documentation 20 Design
Acceptance 5 System Test,
Documentation
Training 10 Documentation
Operation 10 Acceptance
TOTAL 210 person-days
3.4. DIAGRAM JARINGAN (THE NETWORK DIAGRAM)
Langkah kedua dari perencaan adalah menggambarkan diagram jaringan yang menunjukkan urutan kejadian. Tipe diagram yang paling baik untuk masalah ini adalah bagan PERT. Gambar 3.5. adalah sebuah bagan PERT untuk proyek di atas. Urutan kejadian hanya didasarkan pada contoh setiap kegiatan.
Lihat Gambar 3.5. Bagan PERT
Bentuk dari bagan PERT ini disebut Precedence Network (jaringan yang diutamakan). Setiap kotak menunjukkan sebuah kegiatan. Pada setiap kotak ditulis nama kegiatan dan waktu yang diperlukan.
Jalur Kritis & Lamanya Proyek
Bagan PERT dan jalur kritis adalah jumlah jalur, atau serangkaian kegiatan yang dapat ditelusuri pada PERT sederhana di atas, dengan mengikuti petunjuk garis panah. Lamanya waktu yang dibutuhkan untuk menelusuri setiap jalur dapat dijumlahkan dengan menambahkan lamanya waktu dari jalur masing-masing kegiatan.
Jalur kritis (CP / Critical Path) adalah jalur terpanjang dan didefinisikan waktu minimal yang dibutuhkan untuk mengerjakan proyek.
PERT pada gambar 3.5. mempunyai jalur kritis yang terdiri dari kegiatan : START, DEFINITION, ANALYSIS, DESIGN, PROGRAM B, SYSTEM TEST, ACCEPTANCE, OPERATION, dan END. Proyek tersebut membutuhkan total waktu : 135 hari.
3.5. MENGHITUNG BIAYA PROYEK
(CALCULATING PROJECT COST)
Jika kontrak proyek telah mempunyai harga tetap, Manajer Proyek dapat menghitung biaya kasar untuk tenaga kerja, dengan cara mengalikan jumlah tenaga kerja per-hari dengan rata-rata biaya per-hari.
Biaya pekerja perhari disebut ‘biaya penuh’ : yang harus mencakup biaya operasi, sewa, administrasi pekerja, dan keuntungan. Untuk itu anda harus menambahkan biaya tetap, seperti computer time, sewa peralatan khusus, biaya tak terduga, dan sebaginya. Biaya tetap harus dirinci oleh setiap estimator untuk kegiatan utamanya.
Lihat Gambar 3.6. SUPERPROJECT
Rata-rata Pgr 75 pd @ $1000 per pd 75,000
Keuntungan 25% 18,750
Faktor risiko :
User berubah pikiran terhadap 10% format
Biaya = 10% tambahan waktu pemrograman 7,500
Total pemrograman $ 101,250
3.6. PENJADWALAN PROYEK (PROJECT SCHEDULE)
Langkah selanjutnya adalah menghitung jadwal proyek. Untuk melakukan hal ini, perencana (mungkin Manajer Proyek) harus mengaplikasikan jadwal yang sebenarnya dari perkiraan ke CALENDAR DAYS (jadwal harian) atau lamanya pekerjaan.
Salah satu kesulitan tugas ini adalah mengalokasikan sumber daya manusia yang akan bekerja pada kegiatan yang akan dilaksanakan, terutama ketika pekerjaan berlangsung secara serentak. Kesulitan lain adalah memutuskan bagaimana mempersingkat pekerjaan yang dilakukan dengan menggunakan sumber daya yang ada.
Kemudian Manajer Proyek menjadwalkan semua proyek pada kelender atau jadwal yang nyata. Metode terbaik untuk melakukan hal ini adalah dengan menggambarkan ke dalam sebuah Gantt Chart atau Bar Chart seperti pada gambar 3.7.
Lihat Gambar 3.7. SUPERPROJECT project schedule
3.7. Outline Pendahuluan Perencanaan Proyek
(PRELIMINARY PROJECT PLAN OUTLINE)
Dilengkapi dengan semua pengetahuan ini, Manajer Proyek dapat menuliskan dokumen penting ini. Berikut ini adalah outline yang disarankan untuk PPP.
1. Tim Proyek (The Project Team)
Menggambarkan struktur, siapa yang memberikan laporan, siapa yang menerima laporan, kepada siapa berkomunikasi, dst.
Lihat Gambar 3.8. Typical Project Team Structure
Programmer (tidak lebih dari 5 orang). Bertanggung jawab terhadap pemrograman.
Pimpinan Proyek (Project Leader)
Mengawasi programmer.
Bertanggung jawab terhadap kegiatan-kegiatan yang bersifat teknis, seperti analisis, disain dan tugas-tugas pemrograman keseluruhan.
Tujuan utama : kualitas produk yang dihasilkan secara teknik.
Manajer Proyek (Project Manager)
Manajer dalam tim (pimpinan, motivator, dll).
Bertanggung jawab terhadap semua komunikasi yang datangnya dari luar (laporan, pertemuan-pertemuan, penghubung antara manajemen tingkat atas dengan user).
Tujuan utama : keberhasilan proyek (perencanaan, pengontrolan, komunikasi).
2. Biaya Proyek (Projects Cost)
Termasuk WBS, membuat perkiraan dan perhitungan yang digunakan untuk menaksir biaya dalam pembuatan produk.
3. Penjadwal Proyek (Project Schedule)
Merupakan bagian terpenting dalam proyek, dan dapat menggunakan metode Gantt.
4. Pemeriksaan Ulang (Reviews)
Pada bagian ini anda dapat menghubungkan antara pertemuan dari manajemen utama dengan peninjau teknik (jadwal proyek akan memberikan informasi ini), tujuan dari masing-masing peninjau, dan siapa yang akan mengerjakannya. Buatlah daftar tanggung jawab dari orang-orang yang terlibat.
5. Laporan (Reports)
Bentuk dan isi dari laporan keadaan, laporan milestone dan dokumen proyek lain dapat dirinci di dalam laporan tersebut.
6. Dokumentasi (Documentation)
Ada 2 jenis dokumen di dalam proyek, yaitu user dan manajemen proyek.
7. Asumsi (Assumptions)
Disini anda dapat menentapkan harga berdasarkan asumsi : dimana sebagian besar adalah fakta yang diberikan oleh user.
3.8. KESIMPULAN UNTUK PERENCANAAN
Perencanaan itu seperti menunggang kuda : kelihatannya sulit sebelum anda mencobanya. Tetapi begitu anda mencobanya, maka segalanya akan menjadi mudah.
6.Tahap Pemeriksaan Awal
Tahap pemeriksaan awal adalah tahap pertama dari proses pengembangan sistem klasik. Tahap ini menjawab pertanyaan apakah suatu proyek pantas untuk dikerjakan. Untuk itu, pemeriksaan awal harus mendeskripsikan tujuan dari proyek dan masalah, peluang, dan arahan yang memicu proyek tersebut. Tahap pemeriksaan awal terutama berkaitan dengan pandangan pemilik sistem secara umum terhadap sistem tersebut.
Tahap pemeriksaan awal dilakukan dalam waktu yang singkat, seluruh tahap tidak boleh melebihi 2 – 3 hari untuk sebagian besar proyek. Tahap pemeriksaan awal umumnya terdiri dari hal-hal sebagai berikut :
1. Membuat daftar masalah, peluang dan arahan
Ini adalah salah satu pekerjaan utama dalam tahap pemeriksaan awal yang diestimasi berkaitan dengan urgensi, visibilitas, keuntungan nyata, dan prioritas. Pekerjaan ini biasanya diatur oleh analis sistem senior. Pekerjaan ini dipicu oleh permintaan akan proyek.
• Urgensi : dalam waktu berapa lama sebuah masalah harus diselesaikan atau sebuah peluang terealisasikan.
• Visibilitas : pada tingkatan apa sebuah solusi atau sistem baru diperlihatkan kepada pelanggan atau manajemen eksekutif
• Keuntungan : berapa banyak sebuah solusi atau sistem baru meningkatkan pendapatan atau mengurangi biaya tahunan
• Prioritas : apa prioritas dari tiap masalah, peluang, atau arahan
2. Mendiskusikan tujuan awal
Tujuan mendeskripsikan batasan dari proyek, yaitu aspek dari bisnis yang diperhitungkan dan yang tidak. Tujuan dapat berubah selama proyek dilaksanakan, tetapi rencana proyek awal harus membangun tujuan awal. Kemudian bila tujuan berubah secara signifikan, semua anggota yang berhubungan akan memiliki pemahaman yang lebih baik terhadap perubahan anggaran dan jadwal. Pekerjaan ini menggunakan masalah yang didefinisikan oleh pekeerjaan sebelumnya. Masalah, peluang dan arahan tersebut merupakan dasar dalam menentukan tujuan.
3. Mengestimasi nilai proyek
Tidak mungkin untuk melakukan analisis feasibilitas yang menyeluruh berdasarkan fakta terbatas yang dapat dikumpulkan. Pekerjaan ini dipicu oleh pekerjaan sebelumnya yang menyediakan informasi yang dibutuhkan untuk menilai sebuah proyek. Pekerjaan selanjutnya dalam tahap pemeriksaan awal hanya dilaksanakan bila dinyatakan cukup bernilai untuk dilanjutkan.
4. Merencanakan proyek
Bila suatu proyek sudah dinyatakan layak untuk dilanjutkan, baru dapat dilakukan perencanaan secara mendalam. Perencanaan awal proyek minimal harus terdiri dari rencana utama awal (baseline plan) yang mencakup penjadwalan dan penugasan sumber daya untuk seluruh proyek. Perencanaan ini akan di evaluasi pada akhir setiap tahap dari proyek. Selain itu juga harus ada rencana dan jadwal yang mendetail untuk menyelesaikan tahap berikutnya. Pekerjaan ini menjadi tanggung jawab dari manajer proyek.
5. Presentasi proyek beserta rencananya
Pada banyak organisasi, terdapat lebih banyak proyek yang potensial dibandingkan sumber daya yang diperlukan untuk mengerjakan atai membiayainya. Jadi sbuah proyek harus dipresentasikan kepada steering body untuk mendapat persetujuan. Steering body adalah sebuah dewan bisnis eksekutif dan manajer sistem yang mempelajari dan memberikan prioritas pada proposal proyek yang diajukan untuk menentukan proyek mana yang akan memberikan keuntungan terbesar bagi perusahaan dan yang akan disetujui untuk pengembangan sistem berkelanjutan. Setiap steering body harus terdiri dari ahli sistem atau manajer noninformasi.
Di samping itu, sangat penting untuk mempresentasikan jadwal dan tujuan dari suatu proyek kepada seluruh komunitas bisnis. Kemampuan komunikasi dan interpersonal yang efektif sangat dibutuhkan untuk melakukan pekerjaan ini. Peserta pada tahap awal pemeriksaan ini dapat memutuskan bahwa proyeknya tidak layak untuk dilanjutkan. Steering body juga dapat memutukan bahwa ada proyek lain yang lebih penting. Jadi proyek tersebut akan segera dihentikan. Sebaliknya, jika proyek tersebut sudah disetujui oleh semua pemilik sistem dan steering body, proyek tesebut dapat dilanjutkan ke tahap analisis masalah.

7. Fase elaboration : Di dalam tahap pengembangan, pengembang meneliti proyek kebutuhan dalam detil lebih besar dan menggambarkan yayasan/pondasi secara ilmu bangunan nya. Gol tahap ini adalah untuk mengeluarkan/meniadakan proyek yang paling tinggi mengambil resiko kepada luas mungkin yang paling luas, sedemikian sehingga suatu harga pasti dapat dirumuskan pada ujung tahap ini. Ini meliputi pemilihan dari suatu arsitektur dapat diperluas dan optimal dan familiarisasi staff dengan teknologi untuk digunakan
Tahap konstruksi: Pada tahap konstruksi, pengembang berkonsentrasi pada menyelesaikan analisis, melakukan sebagian besar desain dan implementasi sistem. Artinya, tahap konstruksi membangun produk dengan berurusan dengan penerapan semua komponen dan integrasi mereka ke dalam satu produk. Produk ini tidak boleh tanpa cacat, karena beberapa pekerjaan lebih lanjut harus selesai dalam tahap transisi. Hasil lain dari tahap ini adalah tes rinci

Transisi fase: Pada fase transisi, pengembang memberikan sistem kepada pengguna. Fase ini menyimpulkan proyek ini dengan mengintegrasikan produk ke dalam lingkungan pengguna.

10.3 Kesesuaian Umum untuk Pengembangan Aplikasi Web
Bagian ini membahas bagaimana tahapan RUP dapat digunakan untuk pengembangan aplikasi Web. Untuk tujuan ini, kita harus mengevaluasi apakah atau tidak risiko proyek pada tahap awal dapat dikecualikan atau dikurangi sehingga upaya pengembangan tertinggi dalam jangka waktu tertentu dan pada harga tetap dapat diukur pada fase konstruksi antara lain:
·      fase Inception: Definisi dari fase pertama adalah masalah untuk aplikasi Web
pembangunan. Sebuah visi beton produk penuh, seperti yang diharapkan oleh RUP, bentuk-bentuk secara bertahap dalam rangka proyek. Sebagai instrumen pemasaran, aplikasi Web memiliki kelompok sasaran, namun kebutuhan kelompok ini tidak diketahui pada awal proyek, dan mereka berubah terus-menerus karena pengaruh pasar
·      Tahap Elaborasi: fakta bahwa siklus pengembangan yang sangat singkat untuk membangun sebuah versi produk pertama yang memiliki prioritas terhadap mengukur harga tetap untuk produk akhir yang jelas. Alasannya adalah bahwa risiko terkait dengan penggunaan produk perangkat lunak menimbang berat daripada risiko yang melekat dalam pembangunan yang sebenarnya.
·      Tahap konstruksi: Pengembangan aplikasi Web juga memiliki fase di mana pekerjaan konstruksi yang sebenarnya dilakukan. Berdasarkan pembahasan di atas tahap awal, itu hanyalah pertanyaan apakah atau tidak ada bisa menjadi salah satu titik waktu ketika cukup yakin apa yang komponen lainnya masih harus dikembangkan.
·      Transisi fase: Fase transisi dapat berarti bagi aplikasi Web, juga. Terutama ketika fungsionalitas baru ditambahkan ke aplikasi Web iteratif, ini bisa memerlukan sebuah migrasi data atau operasi paralel dua versi. Namun, fase transisi bisa sangat mudah jika mungkin untuk hanya mengganti aplikasi yang sudah ada dengan versi yang baru.

ase- fase pada sebuah proyek sistem informasi

Tahun	Kejadian
1940an	Komputer pertama yang membolehkan pengguna menulis kode program langsung
1950an	Generasi awal interpreter dan bahasa macro Generasi pertama compiler
1960an	Generasi kedua compiler Komputer mainframe mulai dikomersialkan Pengembangan perangkat lunak pesanan Konsep Software Engineering mulai digunakan
1970an	Perangkat pengembang perangkat lunak Perangkat minicomputer komersial
1980an	Perangkat Komputer Personal (PC) komersial Peningkatan permintaan perangkat lunak
1990an	Pemrograman berorientasi obyek (OOP) Agile Process dan Extreme Programming Peningkatan drastis kapasitas memori Peningkatan penggunaan internet
2000an	Platform interpreter modern (Java, .Net, PHP, dll) Outsourcing

Kebutuhan terhadap definisi masalah yang jelas. Input utama dari setiap model pengembangan perangkat lunak adalah pendefinisian masalah yang jelas. Semakin jelas akan semakin baik karena akan memudahkan dalam penyelesaian masalah. Oleh karena itu pemahaman masalah seperti dijelaskan pada Bab 1, merupakan bagian penting dari model pengembangan perangkat lunak.
Tahapan-tahapan pengembangan yang teratur. Meskipun model-model pengembangan perangkat lunak memiliki pola yang berbeda-beda, biasanya model-model tersebut mengikuti pola umum analysis – design – coding – testing – maintenance
Stakeholder berperan sangat penting dalam keseluruhan tahapan pengembangan. Stakeholder dalam rekayasa perangkat lunak dapat berupa pengguna, pemilik, pengembang, pemrogram dan orang-orang yang terlibat dalam rekayasa perangkat lunak tersebut.
Dokumentasi merupakan bagian penting dari pengembangan perangkat lunak. Masing-masing tahapan dalam model biasanya menghasilkan sejumlah tulisan, diagram, gambar atau bentuk-bentuk lain yang harus didokumentasi dan merupakan bagian tak terpisahkan dari perangkat lunak yang dihasilkan.
Keluaran dari proses pengembangan perangkat lunak harus bernilai ekonomis. Nilai dari sebuah perangkat lunak sebenarnya agak susah di-rupiah-kan. Namun efek dari penggunaan perangkat lunak yang telah dikembangkan haruslah memberi nilai tambah bagi organisasi. Hal ini dapat berupa penurunan biaya operasi, efisiensi penggunaan sumberdaya, peningkatan keuntungan organisasi, peningkatan “image” organisasi dan lain-lain.

Tipe perawatan corrective dilakukan jika terjadi kesalahan atau biasa dikenal sebagai bugs. Perawatan bisa dilakukan dengan memperbaiki kode program, menambah bagian yang dirasa perlu atau malah menghilangkan bagian-bagian tertentu.
Tipe perawatan routine biasa juga disebut preventive maintenance dilakukan secara rutin untuk melihat kinerja perangkat lunak ada atau tidak ada kesalahan.
Tipe perawatan sistem upgrade dilakukan jika ada perubahan dari komponen-komponen yang terlibat dalam perangkat lunak tersebut. Sebagai contoh perubahan platform sistem operasi dari versi lama ke versi baru menyebabkan perangkat lunak harus diupgrade.
PENGERTIAN REKAYASA PERANGKAT LUNAK
Istilah Rekayasa Perangkat Lunak (RPL) secara umum disepakati sebagai terjemahan dari istilah Software Engineering. Istilah Software Engineering mulai dipopulerkan tahun 1968 pada Software Engineering Conference yang diselenggarakan oleh NATO. Sebagian orang mengartikan RPL hanya sebatas pada bagaimana membuat program komputer. Padahal ada perbedaan yang mendasar antara perangkat lunak (software) dan program komputer.
Perangkat lunak adalah seluruh perintah yang digunakan untuk memproses informasi. Perangkat lunak dapat berupa program atau prosedur.
Program adalah kumpulan perintah yang dimengerti oleh komputer sedangkan prosedur adalah perintah yang dibutuhkan oleh pengguna dalam memproses informasi (O’Brien, 1999). Pengertian RPL sendiri adalah sebagai berikut: Suatu disiplin ilmu yang membahas semua aspek produksi perangkat lunak, mulai dari tahap awal yaitu analisa kebutuhan pengguna, menentukan spesifikasi dari kebutuhan pengguna, disain, pengkodean, pengujian sampai pemeliharaan sistem setelah digunakan. Jelaslah bahwa RPL tidak hanya berhubungan dengan cara pembuatan program komputer. Pernyataan “semua aspek produksi” pada pengertian di atas, mempunyai arti semua hal yang berhubungan dengan proses produksi seperti manajemen proyek, penentuan personil, anggaran biaya, metode, jadwal, kualitas sampai dengan pelatihan pengguna merupakan bagian dari RPL.
5. METODE REKAYASA PERANGKAT LUNAK
Ketika kita bekerja dengan komputer seperti pada kita membutuhkan serangkaian tahapan dan cara-cara tertentu agar dapat menghasilkan sesuatu yang menjadi harapan kita. Demikian juga dalam rekayasa perangkat lunak, diperlukan tahapan-tahapan kerja yang harus dilalui. Rekayasa perangkat lunak yang sukses tidak hanya membutuhkan kemampuan komputasi seperti algoritma, pemrograman, dan basis data yang kuat, namun juga perlu penentuan tujuan yang baik, identifikasi cara penyelesaian, metode pengembangan, urutan aktifitas, identifikasi kebutuhan sumberdaya, dan faktor-faktor lain. Hal-hal seperti ini terkait dengan apa yang disebut dengan metode rekayasa perangkat lunak.
Pada rekayasa perangkat lunak, banyak model yang telah dikembangkan untuk membantu proses pengembangan perangkat lunak. Model-model ini pada umumnya mengacu pada model proses pengembangan sistem yang disebut System Development Life Cycle (SDLC) seperti terlihat pada Gambar 2.2.
Setiap model yang dikembangkan mempunyai karakteristik sendirisendiri. Namun secara umum ada persamaan dari model-model ini, yaitu:
• Kebutuhan terhadap definisi masalah yang jelas. Input utama dari setiap model pengembangan perangkat lunak adalah pendefinisian masalah yang jelas. Semakin jelas akan semakin baik karena akan memudahkan dalam penyelesaian masalah. Oleh karena itu pemahaman masalah seperti dijelaskan pada Bab 1, merupakan bagian penting dari modelpengembangan perangkat lunak.
• Tahapan-tahapan pengembangan yang teratur. Meskipun model-model pengembangan perangkat lunak memiliki pola yang berbeda-beda, biasanya model-model tersebut mengikuti pola umum analysis – design – coding – testing – maintenance.
• Stakeholder berperan sangat penting dalam keseluruhan tahapan pengembangan. Stakeholder dalam rekayasa perangkat lunak dapat berupa pengguna, pemilik, pengembang, pemrogram dan orang-orang yang terlibat dalam rekayasa perangkat lunak tersebut.
• Dokumentasi merupakan bagian penting dari pengembangan perangkat lunak. Masing-masing tahapan dalam model biasanya menghasilkan sejumlah tulisan, diagram, gambar atau bentuk-bentuk lain yang harus didokumentasi dan merupakan bagian tak terpisahkan dari perangkat lunak yang dihasilkan.
• Keluaran dari proses pengembangan perangkat lunak harus bernilai ekonomis. Nilai dari sebuah perangkat lunak sebenarnya agak susah dirupiah- kan. Namun efek dari penggunaan perangkat lunak yang telah dikembangkan haruslah memberi nilai tambah bagi organisasi. Hal ini dapat berupa penurunan biaya operasi, efisiensi penggunaan sumberdaya, peningkatan keuntungan organisasi, peningkatan “image” organisasi dan lain-lain.
Ada banyak model pengembangan perangkat lunak, antara lain The Waterfall Model, Joint Application Development (JAD), Information Engineering (IE), Rapid Application Development (RAD) termasuk di dalamnya Prototyping, Unified Process (UP), Structural Analysis and Design (SAD) dan Framework for the Application of System thinking (FAST). Pada buku ini akan dibahas tiga model pengembangan yaitu The Waterfall Model, Prototyping, dan Unified Processs (UP).

7. Fase elaboration : Di dalam tahap pengembangan, pengembang meneliti proyek kebutuhan dalam detil lebih besar dan menggambarkan yayasan/pondasi secara ilmu bangunan nya. Gol tahap ini adalah untuk mengeluarkan/meniadakan proyek yang paling tinggi mengambil resiko kepada luas mungkin yang paling luas, sedemikian sehingga suatu harga pasti dapat dirumuskan pada ujung tahap ini. Ini meliputi pemilihan dari suatu arsitektur dapat diperluas dan optimal dan familiarisasi staff dengan teknologi untuk digunakan
Tahap konstruksi: Pada tahap konstruksi, pengembang berkonsentrasi pada menyelesaikan analisis, melakukan sebagian besar desain dan implementasi sistem. Artinya, tahap konstruksi membangun produk dengan berurusan dengan penerapan semua komponen dan integrasi mereka ke dalam satu produk. Produk ini tidak boleh tanpa cacat, karena beberapa pekerjaan lebih lanjut harus selesai dalam tahap transisi. Hasil lain dari tahap ini adalah tes rinci

Transisi fase: Pada fase transisi, pengembang memberikan sistem kepada pengguna. Fase ini menyimpulkan proyek ini dengan mengintegrasikan produk ke dalam lingkungan pengguna.

Mutiara Adi Saputri

Minggu, 13 Maret 2016

Fase Pengelolaan Proyek Sistem Informasi

ase- fase pada sebuah proyek sistem informasi

Tidak ada komentar:

Posting Komentar