Data Object Description
Menyimpan semua atribut entitas dan relasi yang muncul pada ERD
Data Dictionary
Menyimpan semua obyek data yang dibutuhkan & dihasilkan PL. Obyek data yang muncul seperti: ERD, DFD dan STD
Proses Specification
Berisi diskripsi setiap fungsi yang muncul pada DFD (sbagai tool mentransformasikan data)
C-SPEC
berisi diskripsi dari setiap status yang dapat muncul pada sistem
software requerment
Data design
mengubah model informasi (entity relationship diagram dan data dictionary) menjadi struktur data
Architectural design
berisi hubungan antar elemen dalam program
Interface design
menjelaskan bagaimana bagaimana komunikasi di dalam perangkat lunak, dengan sistem, dan dengan manusia yang menggunakannya.
Sebuah interface mengandung maksud sebuah aliran informasi.
Procedural design
mengubah elemen struktural dari arsitektur program menjadi deskripsi prosedural dari komponen perangkat lunak
kualitas desan dan s.ware
Sebuah desain harus menunjukkan organisasi secara hirarkis
Sebuah desain harus bersifat modular; jadi, sebuah perangkat lunak seharusnya dapat dibagi-bagi secara lojik menjadi beberapa elemen yang melakukan fungsi atau subfungsi secara spesifik
Sebuah desain harus mengandung abstraksi data dan prosedural
Sebuah desain harus mengarah pada modul-modul (prosedur atau subrutin) yang menunjukkan karakteristik fungsional
prinsip desain
Prinsip Desain memungkinkan perekayasa
Perangkat lunak untuk mengendalikan proses desain
Proses desain tidak boleh mengalami “tunnel vision”
Desainer harus memperhatikan pendekatan-pendekatan alternatif, menilainya berdasarkan persyaratan masalah, sumber daya yang ada untuk melakukan pekerjaan, dan konsep desain
Desain harus dapat dilacak ke model analisis
Tidak melakukan desain pada hal yang sama berulang-ulang
Desain harus merepresentasikan masalah pada keadaan nyata
Desain harus memperlihatkan keseragaman dan integrasi
dokumentasi desain
Lingkup Sistem
Desain Data
Desain Arsitektur
Desain Antarmuka
Desain Prosedural
Catatan Khusus
Appendix
Suwun mas bro mbak sist
Minggu, 30 Oktober 2011
analisis modeling
definisi kebutuhan
Kebutuhan perangkat lunak adalah kondisi atau kemampuan yang harus dimiliki oleh perangkat lunak untuk memenuhi apa yang disyaratkan atau diinginkan oleh pemakai
jenis kebutuhan
Secara kategoris, ada tiga buah jenis kebutuhan perangkat lunak [IEE93]:
Kebutuhan fungsional (functional requirement)
Kebutuhan antarmuka (interface requirement)
Kebutuhan unjuk kerja (performance requirement)
Kebutuhan antarmuka dan unjuk kerja sering disebut Non-functional Requirement
jenis fungsional'
Disebut juga kebutuhan operasional, yaitu kebutuhan yang berkaitan dengan fungsi atau proses transformasi yang harus mampu dikerjakan oleh perangkat lunak.
Contoh:
Perangkat lunak harus dapat menyimpan semua rincian data pesanan pelanggan.
Perangkat lunak harus mampu mencetak laporan penjualan sesuai periode yang diinputkan.
Perangkat lunak harus mampu menyajikan informasi jalur pengiriman terpendek.
jenis antar muka
Kebutuhan antarmuka yang menghubungkan perangkat lunak dengan elemen perangkat keras, perangkat lunak, atau basis data.
Contoh:
Akses ke basis data menggunakan ODBC (Open Data Base Connectivity).
Perangkat untuk memasukkan data menggunakan keyboard, mouse, dan scanner.
kebutuhan utk kerja
Kebutuhan yang menetapkan karakteristik unjuk kerja yang harus dimiliki oleh perangkat lunak, seperti kecepatan, ketepatan, atau frekuensi.
Contoh:
Waktu tanggap penyajian informasi maksimal selama satu menit.
Perangkat lunak harus mampu mengolah data sampai 1 juta record untuk setiap transaksi.
Perangkat lunak harus dapat digunakan secara multi user sesuai otoritas yang diberikan kepada masing-masing pemakai.
analisis kbthn
Analisis kebutuhan perangkat lunak dapat diartikan sebagai:
Proses mempelajari kebutuhan pemakai untuk mendapatkan definisi kebutuhan sistem atau perangkat lunak [IEE93].
Proses untuk menetapkan fungsi dan unjuk kerja perangkat lunak, menyatakan antarmuka perangkat lunak dengan elemen-elemen sistem lain, dan menentukan kendala yang harus dihadapi oleh perangkat lunak [PRE01].
ptngya analisis kbhtn
Pendefinisian kebutuhan yang baik dapat menjadi faktor sukses pelaksanaan pengembangan perangkat lunak. Sebaliknya akan menyebabkan banyak kegagalan.
Menurut hasil survey DeMarco, 56% kegagalan proyek perangkat lunak adalah karena ketidaklengkapan pendefinisian kebutuhan.
tahap analisis kebutuhan
Secara teknis pelaksanaan pekerjaan analisis kebutuhan perangkat lunak pada dasarnya terdiri dari urutan aktivitas:
Mempelajari dan memahami persoalan
Mengidentifikasi kebutuhan pemakai
Mendefinisikan kebutuhan perangkat lunak
Membuat dokumen spesifikasi kebutuhan
Mengkaji ulang (review) kebutuhan
membuat dokumen
Semua kebutuhan yang telah didefinisikan selanjutnya dibuatkan dokumentasinya, yaitu Spesifikasi Kebutuhan Perangkat Lunak (SKPL) atau Software Requirements Specification (SRS).
SKPL yang dibuat harus dapat menyatakan secara lengkap apa yang dapat dilakukan oleh perangkat lunak, termasuk deskripsi lengkap dari semua antarmuka yang digunakan.
SKPL bisa terdiri dari banyak dokumentasi yang saling melengkapi.
mengkaji ulang kebutuhan
Proses untuk memeriksa (validasi) SKPL apakah sudah konsisten, lengkap, dan sesuai dengan apa yang diinginkan pemakai.
Proses ini mungkin dilakukan lebih dari satu kali.
Dan sering kali muncul kebutuhan-kebutuhan baru dari pemakai.
Untuk itu, diperlukan negosiasi antara pihak pengembang dengan pemakai sesuai prinsip “win-win solution” sampai kebutuhan tersebut dapat disepakati kedua belah pihak.
Kebutuhan perangkat lunak adalah kondisi atau kemampuan yang harus dimiliki oleh perangkat lunak untuk memenuhi apa yang disyaratkan atau diinginkan oleh pemakai
jenis kebutuhan
Secara kategoris, ada tiga buah jenis kebutuhan perangkat lunak [IEE93]:
Kebutuhan fungsional (functional requirement)
Kebutuhan antarmuka (interface requirement)
Kebutuhan unjuk kerja (performance requirement)
Kebutuhan antarmuka dan unjuk kerja sering disebut Non-functional Requirement
jenis fungsional'
Disebut juga kebutuhan operasional, yaitu kebutuhan yang berkaitan dengan fungsi atau proses transformasi yang harus mampu dikerjakan oleh perangkat lunak.
Contoh:
Perangkat lunak harus dapat menyimpan semua rincian data pesanan pelanggan.
Perangkat lunak harus mampu mencetak laporan penjualan sesuai periode yang diinputkan.
Perangkat lunak harus mampu menyajikan informasi jalur pengiriman terpendek.
jenis antar muka
Kebutuhan antarmuka yang menghubungkan perangkat lunak dengan elemen perangkat keras, perangkat lunak, atau basis data.
Contoh:
Akses ke basis data menggunakan ODBC (Open Data Base Connectivity).
Perangkat untuk memasukkan data menggunakan keyboard, mouse, dan scanner.
kebutuhan utk kerja
Kebutuhan yang menetapkan karakteristik unjuk kerja yang harus dimiliki oleh perangkat lunak, seperti kecepatan, ketepatan, atau frekuensi.
Contoh:
Waktu tanggap penyajian informasi maksimal selama satu menit.
Perangkat lunak harus mampu mengolah data sampai 1 juta record untuk setiap transaksi.
Perangkat lunak harus dapat digunakan secara multi user sesuai otoritas yang diberikan kepada masing-masing pemakai.
analisis kbthn
Analisis kebutuhan perangkat lunak dapat diartikan sebagai:
Proses mempelajari kebutuhan pemakai untuk mendapatkan definisi kebutuhan sistem atau perangkat lunak [IEE93].
Proses untuk menetapkan fungsi dan unjuk kerja perangkat lunak, menyatakan antarmuka perangkat lunak dengan elemen-elemen sistem lain, dan menentukan kendala yang harus dihadapi oleh perangkat lunak [PRE01].
ptngya analisis kbhtn
Pendefinisian kebutuhan yang baik dapat menjadi faktor sukses pelaksanaan pengembangan perangkat lunak. Sebaliknya akan menyebabkan banyak kegagalan.
Menurut hasil survey DeMarco, 56% kegagalan proyek perangkat lunak adalah karena ketidaklengkapan pendefinisian kebutuhan.
tahap analisis kebutuhan
Secara teknis pelaksanaan pekerjaan analisis kebutuhan perangkat lunak pada dasarnya terdiri dari urutan aktivitas:
Mempelajari dan memahami persoalan
Mengidentifikasi kebutuhan pemakai
Mendefinisikan kebutuhan perangkat lunak
Membuat dokumen spesifikasi kebutuhan
Mengkaji ulang (review) kebutuhan
membuat dokumen
Semua kebutuhan yang telah didefinisikan selanjutnya dibuatkan dokumentasinya, yaitu Spesifikasi Kebutuhan Perangkat Lunak (SKPL) atau Software Requirements Specification (SRS).
SKPL yang dibuat harus dapat menyatakan secara lengkap apa yang dapat dilakukan oleh perangkat lunak, termasuk deskripsi lengkap dari semua antarmuka yang digunakan.
SKPL bisa terdiri dari banyak dokumentasi yang saling melengkapi.
mengkaji ulang kebutuhan
Proses untuk memeriksa (validasi) SKPL apakah sudah konsisten, lengkap, dan sesuai dengan apa yang diinginkan pemakai.
Proses ini mungkin dilakukan lebih dari satu kali.
Dan sering kali muncul kebutuhan-kebutuhan baru dari pemakai.
Untuk itu, diperlukan negosiasi antara pihak pengembang dengan pemakai sesuai prinsip “win-win solution” sampai kebutuhan tersebut dapat disepakati kedua belah pihak.
PROROTIPE
Prototipe mendukung dua kegiatan proses rekayasa persyaratan
Elisitasi persyaratan: user bereksperimen untuk melihat bagaimana sistem dapat mendukung pekerjaan mereka dan memberikan usulan atau ide-ide baru.
Validasi persyaratan: Prototipe dapat menunjukkan kesalahan-kesalahan atau ketidak-sesuaian yang mungkin terjadi.
keuntungan prototipe
Mengurangi kesalahpahaman antara pengembang dan user
Menemukan persyaratan yang tidak lengkap
Sudah dapat ditunjukkan bahwa sistem sudah bekerja
Digunakan sebagai dasar penulisan spesifikasi untuk kualitas produksi
Tujuan Pemrograman Evolusioner dan Throw-away
Evolusioner:
Menyerahkan sistem kepada user untuk menjalankan semua prioritas utama.
Throw-Away:
Mem-validasi dan menurunkan persyaratan sistem.
Keuntungan Prototipe Evolusioner
Penyerahan sistem yang dipercepat, sehingga dapat diantisipasi keterlambatan karena perubahan sistem.
Keterlibatan user dengan sistem lebih awal dan lebih lama, sehingga menumbuhkan kepercayaan user.
spesifikasi
Proses spesifikasi, perancangan dan implementasi yang tumpang tindih.
Sistem dikembangkan dalam inkremental
Teknik-teknik pengembangan sistem yang cepat
User Interface dikembangkan menggunakan pengembangan interaktif.
masalah yg biasa timbul
Masalah manajemen, khususnya dalam ketersediaan tenaga
Masalah pemeliharaan menjadi lebih sulit
Masalah kontrak.
mslh dalm trhow away
Fitur-fitur penting bisa dihilangkan dari prototipe untuk menyederhanakan implementasi yang cepat
Implementasi tidak mempunyai kedudukan legal sebagai kontrak
Persyaratan non-fungsional seperti keandalan, ketahanan dan keselamatan tidak dapat diuji dengan memadai.
2 hal penting dalm pemakaian ulang p.tipe
Tingkat aplikasi, dimana seluruh sistem diintegrasikan dengan prototipe sehingga fungsionalitasnya dapat dipakai bersama.
Tingkat komponen, dimana komponen-komponen secara individu diintegrasikan dalam kerangka kerja standard untuk implementasi sistem
Elisitasi persyaratan: user bereksperimen untuk melihat bagaimana sistem dapat mendukung pekerjaan mereka dan memberikan usulan atau ide-ide baru.
Validasi persyaratan: Prototipe dapat menunjukkan kesalahan-kesalahan atau ketidak-sesuaian yang mungkin terjadi.
keuntungan prototipe
Mengurangi kesalahpahaman antara pengembang dan user
Menemukan persyaratan yang tidak lengkap
Sudah dapat ditunjukkan bahwa sistem sudah bekerja
Digunakan sebagai dasar penulisan spesifikasi untuk kualitas produksi
Tujuan Pemrograman Evolusioner dan Throw-away
Evolusioner:
Menyerahkan sistem kepada user untuk menjalankan semua prioritas utama.
Throw-Away:
Mem-validasi dan menurunkan persyaratan sistem.
Keuntungan Prototipe Evolusioner
Penyerahan sistem yang dipercepat, sehingga dapat diantisipasi keterlambatan karena perubahan sistem.
Keterlibatan user dengan sistem lebih awal dan lebih lama, sehingga menumbuhkan kepercayaan user.
spesifikasi
Proses spesifikasi, perancangan dan implementasi yang tumpang tindih.
Sistem dikembangkan dalam inkremental
Teknik-teknik pengembangan sistem yang cepat
User Interface dikembangkan menggunakan pengembangan interaktif.
masalah yg biasa timbul
Masalah manajemen, khususnya dalam ketersediaan tenaga
Masalah pemeliharaan menjadi lebih sulit
Masalah kontrak.
mslh dalm trhow away
Fitur-fitur penting bisa dihilangkan dari prototipe untuk menyederhanakan implementasi yang cepat
Implementasi tidak mempunyai kedudukan legal sebagai kontrak
Persyaratan non-fungsional seperti keandalan, ketahanan dan keselamatan tidak dapat diuji dengan memadai.
2 hal penting dalm pemakaian ulang p.tipe
Tingkat aplikasi, dimana seluruh sistem diintegrasikan dengan prototipe sehingga fungsionalitasnya dapat dipakai bersama.
Tingkat komponen, dimana komponen-komponen secara individu diintegrasikan dalam kerangka kerja standard untuk implementasi sistem
pertemuan 3
Analisis Terstruktur
Model yang menggambarkan muatan dan aliran informasi, pembagian sistem secara fungsional dan behavioral, esensi dari apa yang akan dibangun
Elemen Model Analisis
Model analisis harus mencapai sasaran berikut:
Menggambarkan apa yang dibutuhkan pelanggan
Membangun dasar bagi pembuatan desain perangkat lunak
Membatasi serangkaian persyaratan yang dapat divalidasi begitu perangkat lunak dibangun.
Struktur Analisis(2)
Kamus data (data dictionary)
Penyimpan yang berisi deskripsi objek data yang dikonsumsi atau diproduksi perangkat lunak
ERD adalah notasi untuk melakukan aktivitas pemodelan data
Deskripsi objek data adalah gambaran dari atribut objek data yang ditulis di ERD
3
DFD, yang digunakan untuk :
Memberi indikasi bagaimana data ditransformasi pada saat bergerak melalui sistem
Untuk menggambarkan fungsi dan subfungsi yang mentransformasi aliran data
Spesifikasi proses mendeskripsikan setiap fungsi yang disajikan DFD
4
State Transition Diagram, menunjukkan bagaimana sistem bertingkah laku sebagai akibat dari kejadian eksternal. Hal ini merupakan dasar dari pemodelan tingkah laku
Spesifikasi Kontrol, merupakan informasi aspek kontrol perangkat lunak
pemodelan data
Pemodelan data menjawab serangkaian data spesifik yang relevan dengan berbagai aplikasi pemrosesan data
Untuk memodelkan data, digunakan ERD
objek data
Representasi semua informasi gabungan yang harus dipahami perangkat lunak
contoh: Karyawan adalah objek data. Gabungan informasi yang dipunyai karyawan adalah nama, nip, golongan, tahun masuk
Model yang menggambarkan muatan dan aliran informasi, pembagian sistem secara fungsional dan behavioral, esensi dari apa yang akan dibangun
Elemen Model Analisis
Model analisis harus mencapai sasaran berikut:
Menggambarkan apa yang dibutuhkan pelanggan
Membangun dasar bagi pembuatan desain perangkat lunak
Membatasi serangkaian persyaratan yang dapat divalidasi begitu perangkat lunak dibangun.
Struktur Analisis(2)
Kamus data (data dictionary)
Penyimpan yang berisi deskripsi objek data yang dikonsumsi atau diproduksi perangkat lunak
ERD adalah notasi untuk melakukan aktivitas pemodelan data
Deskripsi objek data adalah gambaran dari atribut objek data yang ditulis di ERD
3
DFD, yang digunakan untuk :
Memberi indikasi bagaimana data ditransformasi pada saat bergerak melalui sistem
Untuk menggambarkan fungsi dan subfungsi yang mentransformasi aliran data
Spesifikasi proses mendeskripsikan setiap fungsi yang disajikan DFD
4
State Transition Diagram, menunjukkan bagaimana sistem bertingkah laku sebagai akibat dari kejadian eksternal. Hal ini merupakan dasar dari pemodelan tingkah laku
Spesifikasi Kontrol, merupakan informasi aspek kontrol perangkat lunak
pemodelan data
Pemodelan data menjawab serangkaian data spesifik yang relevan dengan berbagai aplikasi pemrosesan data
Untuk memodelkan data, digunakan ERD
objek data
Representasi semua informasi gabungan yang harus dipahami perangkat lunak
contoh: Karyawan adalah objek data. Gabungan informasi yang dipunyai karyawan adalah nama, nip, golongan, tahun masuk
pertemuan 2
Perencanaan Proyek Perangkat Lunak
Proses manajemen proyek PL dimulai dng rangkaian aktivitas yang disebut Perencanaan Proyek PL (Software Project Planning)
Apa tujuan perencanaan proyek ?
Adalah untuk memberikan batasan memungkinkan bagi manajer untuk mengestimasi sumber daya, biaya dan jadwal yang bisa dipertanggung jawabkan.
Tahapan-tahapan Dalam Perencanaan PL :
Memperkirakan (estimation)
Ruang Lingkup (scoping)
Resiko (risk)
Jadwal (schedule)
Strategi Pengendalian (control strategy)
Estimasi sumber daya, biaya dan jadwal pengembangan PL memerlukan :
Pengalaman
Akses informasi historis yang baik
Informasi historis. Dengan mengetahui data-data yang lalu kita dapat mengoptimalkan pekerjaan dan menghindari hal-hal yang bisa menimbulkan persoalan
Keberanian untuk komitmen terhadap ketersedian informasi
Hal-hal yang mempengaruhi estimasi :
“Project Complexity”
“Project size”
“Problem decomposition”
Tingkatan “structural uncertainty”. Struktur dalam hal ini adalah tingkatan kebutuhan, kemudahan fungsi yang akan dihasilkan dan informasi yang harus diproses.
Resiko diukur berdasarkan tingkatan ketidakpastian estimasi terhadap sumber daya, biaya dan jadwal. Jika batasan proyek tidak jelas dan kebutuhan proyek senantiasa berubah maka hal ini bisa menimbulkan dampak yang membahayakan.
Apa yang dimaksud dengan ruang lingkup (scopes) :
Fungsi (functions) : Estimasi biaya dan jadwal berorientasi secara fungsional.
Kinerja (performance) : berkaitan dengan proses dan waktu respon yang dispesifikasikan
Batasan (constraints) : mengidentifikasikan keterbatasan PL terhadap perangkat keras, memori maupun terhadap sistem lainnya yang sudah ada.
Antar-muka (Interfaces)
Reliabilitas (reliability)
Pertanyaan yang diajukan untuk memahami ruang lingkup PL:
Berkaitan dengan tujuan umum:
Siapa yang menginginkan pekerjaan ini ?
Siapa yang mempunyai solusi yang lain ?
Apa keuntungan ekonominya jika solusi tersebut berhasil ?
Berkaitan dengan pemahaman permasalahan :
Bagaimana output yang diinginkan pelanggan ?
Masalah apa yang bisa diatasi oleh solusi tersebut ?
Adakah batasan atau isu-isu kinerja khusus yang akan mempengaruhi cara pendekatan terhadap solusi ?
Berkaitan dengan efektifitas pertemuan :
Apakah anda orang yg tepat utk. menjawab pertanyaan ini ?
Apakah pertanyaan saya relevan dng problem anda ?
Apakah masih ada hal lain yang sebaiknya saya tanyakan ?
Perencanaan Sumber Daya
Tugas kedua perencanaan PL adalah mengestimasi sumber daya yang dibutuhkan untuk menyelesaikan usaha pengembangan PL tersebut.
Sumber Daya Manusia
Mengevaluasi ruang lingkup dan keahlian yang dibutuhkan. Perencanan harus menentukan posisi organisasi (seperti manajer, perekayasa PL, dll) dan spesialisasi (seperti telekomunikasi, data base, client/server).
Jumlah orang yang dibutuhkan untuk sebuah proyek PL bisa ditentukan setelah adanya estimasi usaha untuk pengembangan (seperti person-months).
Perencanaan Sumber Daya
Tugas kedua perencanaan PL adalah mengestimasi sumber daya yang dibutuhkan untuk menyelesaikan usaha pengembangan PL tersebut.
Sumber Daya Manusia
Mengevaluasi ruang lingkup dan keahlian yang dibutuhkan. Perencanan harus menentukan posisi organisasi (seperti manajer, perekayasa PL, dll) dan spesialisasi (seperti telekomunikasi, data base, client/server).
Jumlah orang yang dibutuhkan untuk sebuah proyek PL bisa ditentukan setelah adanya estimasi usaha untuk pengembangan (seperti person-months).
Estimasi Proyek PL
Pada masa-masa awal perhitungan, biaya perangkat lunak biasanya mendominasi proyek.
Katagori teknik estimasi :
Mendasarkan estimasi pada proyek-proyek yang mirip yang sudah dilakukan sebelumnya
Menggunakan “teknik dekomposisi” yang relatif sederhana untuk melakukan estimasi biaya dan usaha proyek.
Menggunakan satu atau lebih model empiris untuk estimasi usaha dan biaya PL.
Keputusan Make-Buy
Dalam banyak area aplikasi PL, biaya sering lebih efektif untuk mendapatkan dari pada mengembangkan PL.
Akuisisi Perangkat Lunak
Buat atau beli ? Beli / beli lalu dimodifkasi / Outsourcing
Petunjuk :
Buat spesifikasi fungsi dan kinerja yang diharapkan
Estimasi biaya internal pengembangan dan tgl. penyampaian
Pilih 3 atau 4 perangkat lunak kandidat yang paling cocok
Buat matriks perbandingan dari kandidat tersebut
Evaluasi berdasarkan kualitas sebelumnya, dukungan vendor, reputasi dan dukungan purna jual, dll.
Tanya komentar pemakai lain.
Analisis Akhir
Apakah tanggal penyampaian akan lebih cepat dibandingkan mengembangkan sendiri ?
Apakah biaya pembelian + biaya pengubahan lebih kecil dari biaya pengembangan sendiri ?
Apakah biaya dukungan dari pihak luar lebih kecil dari biaya dukungan dari dalam ?
1. Pendahuluan
- maksud dan tujuan proyek - sasaran yang akan dicapai
- fungsi utama perangkat lunak - kendala proyek
2. Estimasi Proyek
a. metode estimasi b. estimasi biaya & sumber daya manusia
3. Resiko Proyek
a. Analisis resiko b. Manajemen resiko
4. Jadwal Proyek
a. kegiatan & waktu b. network planning c. SD kegiatan
5. Sumber daya
a. Manusia b. perangkat keras c. perangkat lunak
6. Organisasi
a. struktur organisasi b. pelaporan
7. Lampiran.
Proses manajemen proyek PL dimulai dng rangkaian aktivitas yang disebut Perencanaan Proyek PL (Software Project Planning)
Apa tujuan perencanaan proyek ?
Adalah untuk memberikan batasan memungkinkan bagi manajer untuk mengestimasi sumber daya, biaya dan jadwal yang bisa dipertanggung jawabkan.
Tahapan-tahapan Dalam Perencanaan PL :
Memperkirakan (estimation)
Ruang Lingkup (scoping)
Resiko (risk)
Jadwal (schedule)
Strategi Pengendalian (control strategy)
Estimasi sumber daya, biaya dan jadwal pengembangan PL memerlukan :
Pengalaman
Akses informasi historis yang baik
Informasi historis. Dengan mengetahui data-data yang lalu kita dapat mengoptimalkan pekerjaan dan menghindari hal-hal yang bisa menimbulkan persoalan
Keberanian untuk komitmen terhadap ketersedian informasi
Hal-hal yang mempengaruhi estimasi :
“Project Complexity”
“Project size”
“Problem decomposition”
Tingkatan “structural uncertainty”. Struktur dalam hal ini adalah tingkatan kebutuhan, kemudahan fungsi yang akan dihasilkan dan informasi yang harus diproses.
Resiko diukur berdasarkan tingkatan ketidakpastian estimasi terhadap sumber daya, biaya dan jadwal. Jika batasan proyek tidak jelas dan kebutuhan proyek senantiasa berubah maka hal ini bisa menimbulkan dampak yang membahayakan.
Apa yang dimaksud dengan ruang lingkup (scopes) :
Fungsi (functions) : Estimasi biaya dan jadwal berorientasi secara fungsional.
Kinerja (performance) : berkaitan dengan proses dan waktu respon yang dispesifikasikan
Batasan (constraints) : mengidentifikasikan keterbatasan PL terhadap perangkat keras, memori maupun terhadap sistem lainnya yang sudah ada.
Antar-muka (Interfaces)
Reliabilitas (reliability)
Pertanyaan yang diajukan untuk memahami ruang lingkup PL:
Berkaitan dengan tujuan umum:
Siapa yang menginginkan pekerjaan ini ?
Siapa yang mempunyai solusi yang lain ?
Apa keuntungan ekonominya jika solusi tersebut berhasil ?
Berkaitan dengan pemahaman permasalahan :
Bagaimana output yang diinginkan pelanggan ?
Masalah apa yang bisa diatasi oleh solusi tersebut ?
Adakah batasan atau isu-isu kinerja khusus yang akan mempengaruhi cara pendekatan terhadap solusi ?
Berkaitan dengan efektifitas pertemuan :
Apakah anda orang yg tepat utk. menjawab pertanyaan ini ?
Apakah pertanyaan saya relevan dng problem anda ?
Apakah masih ada hal lain yang sebaiknya saya tanyakan ?
Perencanaan Sumber Daya
Tugas kedua perencanaan PL adalah mengestimasi sumber daya yang dibutuhkan untuk menyelesaikan usaha pengembangan PL tersebut.
Sumber Daya Manusia
Mengevaluasi ruang lingkup dan keahlian yang dibutuhkan. Perencanan harus menentukan posisi organisasi (seperti manajer, perekayasa PL, dll) dan spesialisasi (seperti telekomunikasi, data base, client/server).
Jumlah orang yang dibutuhkan untuk sebuah proyek PL bisa ditentukan setelah adanya estimasi usaha untuk pengembangan (seperti person-months).
Perencanaan Sumber Daya
Tugas kedua perencanaan PL adalah mengestimasi sumber daya yang dibutuhkan untuk menyelesaikan usaha pengembangan PL tersebut.
Sumber Daya Manusia
Mengevaluasi ruang lingkup dan keahlian yang dibutuhkan. Perencanan harus menentukan posisi organisasi (seperti manajer, perekayasa PL, dll) dan spesialisasi (seperti telekomunikasi, data base, client/server).
Jumlah orang yang dibutuhkan untuk sebuah proyek PL bisa ditentukan setelah adanya estimasi usaha untuk pengembangan (seperti person-months).
Estimasi Proyek PL
Pada masa-masa awal perhitungan, biaya perangkat lunak biasanya mendominasi proyek.
Katagori teknik estimasi :
Mendasarkan estimasi pada proyek-proyek yang mirip yang sudah dilakukan sebelumnya
Menggunakan “teknik dekomposisi” yang relatif sederhana untuk melakukan estimasi biaya dan usaha proyek.
Menggunakan satu atau lebih model empiris untuk estimasi usaha dan biaya PL.
Keputusan Make-Buy
Dalam banyak area aplikasi PL, biaya sering lebih efektif untuk mendapatkan dari pada mengembangkan PL.
Akuisisi Perangkat Lunak
Buat atau beli ? Beli / beli lalu dimodifkasi / Outsourcing
Petunjuk :
Buat spesifikasi fungsi dan kinerja yang diharapkan
Estimasi biaya internal pengembangan dan tgl. penyampaian
Pilih 3 atau 4 perangkat lunak kandidat yang paling cocok
Buat matriks perbandingan dari kandidat tersebut
Evaluasi berdasarkan kualitas sebelumnya, dukungan vendor, reputasi dan dukungan purna jual, dll.
Tanya komentar pemakai lain.
Analisis Akhir
Apakah tanggal penyampaian akan lebih cepat dibandingkan mengembangkan sendiri ?
Apakah biaya pembelian + biaya pengubahan lebih kecil dari biaya pengembangan sendiri ?
Apakah biaya dukungan dari pihak luar lebih kecil dari biaya dukungan dari dalam ?
1. Pendahuluan
- maksud dan tujuan proyek - sasaran yang akan dicapai
- fungsi utama perangkat lunak - kendala proyek
2. Estimasi Proyek
a. metode estimasi b. estimasi biaya & sumber daya manusia
3. Resiko Proyek
a. Analisis resiko b. Manajemen resiko
4. Jadwal Proyek
a. kegiatan & waktu b. network planning c. SD kegiatan
5. Sumber daya
a. Manusia b. perangkat keras c. perangkat lunak
6. Organisasi
a. struktur organisasi b. pelaporan
7. Lampiran.
Langganan:
Postingan (Atom)