Local News Simsalabim IndonesiaSDS

Local News Simsalabim Indonesia Clicking Here!

Sahabat Sukses

Salam sahabat

 News

 Reviews

 Typography

 Blog

 Videos

 Page

0

0

0

Share Widgets

Analisis Perbandingan Generic Software Process Model

Diposting oleh Mahmud Yunus , 23.47 Be the first to comment!

Pada kesempatan kali ini kelompok kami akan menganalisis perbandingan Generic Software Process Model, sedikit singkat dan hampir mendekati. Ada 4 Software Process Model : Waterfall Model, Spiral Model, Prototyping Model, Incremental Model.

Pada gambar disamping adalah tahapan umum dari model proses ini. Akan tetapi Roger S. Pressman memecah model ini menjadi 6 tahapan meskipun secara garis besar sama dengan tahapan-tahapan model waterfall pada umumnya. Berikut adalah penjelasan dari tahap-tahap yang dilakukan di dalam model ini menurut PressmanSystem / Information Engineering and Modeling. Permodelan ini diawali dengan mencari kebutuhan dari keseluruhan sistem yang akan diaplikasikan ke dalam bentuk software. Hal ini sangat penting, mengingat software harus dapat berinteraksi dengan elemen-elemen yang lain seperti hardware, database, dsb. Tahap ini sering disebut dengan Project Definitiona. Software Requirements Analysis. Proses pencarian kebutuhan diintensifkan dan difokuskan pada software. Untuk mengetahui sifat dari program yang akan dibuat, maka para software engineer harus mengerti tentang domain informasi dari software, misalnya fungsi yang dibutuhkan, user interface, dsb. Dari 2 aktivitas tersebut (pencarian kebutuhan sistem dan software) harus didokumentasikan dan ditunjukkan kepada pelanggan.

Design. Proses ini digunakan untuk mengubah kebutuhan-kebutuhan diatas menjadi representasi ke dalam bentuk “blueprint” software sebelum coding dimulai. Desain harus dapat mengimplementasikan kebutuhan yang telah disebutkan pada tahap sebelumnya. Seperti 2 aktivitas sebelumnya, maka proses ini juga harus didokumentasikan sebagai konfigurasi dari software.

Coding. Untuk dapat dimengerti oleh mesin, dalam hal ini adalah komputer, maka desain tadi harus diubah bentuknya menjadi bentuk yang dapat dimengerti oleh mesin, yaitu ke dalam bahasa pemrograman melalui proses coding. Tahap ini merupakan implementasi dari tahap design yang secara teknis nantinya dikerjakan oleh programmer.

Testing / Verification. Sesuatu yang dibuat haruslah diujicobakan. Demikian juga dengan software. Semua fungsi-fungsi software harus diujicobakan, agar software bebas dari error, dan hasilnya harus benar-benar sesuai dengan kebutuhan yang sudah didefinisikan

sebelumnya.

Maintenance. Pemeliharaan suatu software diperlukan, termasuk di dalamnya adalah pengembangan, karena software yang dibuat tidak selamanya hanya seperti itu. Ketika dijalankan mungkin saja masih ada errors kecil yang tidak ditemukan sebelumnya, atau ada penambahan fitur-fitur yang belum ada pada software tersebut. Pengembangan diperlukan ketika adanya perubahan dari eksternal perusahaan seperti ketika ada pergantian sistem operasi, atau perangkat lainnya.

Masalah dengan waterfall :

1. Perubahan sulit dilakukan karena sifatnya yang kaku.

2. Karena sifat kakunya, model ini cocok ketika kebutuhan dikumpulkan secara lengkap sehingga perubahan bisa ditekan sekecil mungkin. Tapi pada kenyataannya jarang sekali konsumen/pengguna yang bisa memberikan kebutuhan secara lengkap, perubahan kebutuhan adalah sesuatu yang wajar terjadi.

3. Waterfall pada umumnya digunakan untuk rekayasa sistem yang besar dimana proyek dikerjakan di beberapa tempat berbeda, dan dibagi menjadi beberapa bagian sub-proyek

Kelebihan dan Kekurangan Waterfall Model Kelebihan :

 Merupakan model pengembangan paling handal dan paling lama digunakan.

 Cocok untuk system software berskala besar.

 Cocok untuk system software yang bersifat generic.

 Pengerjaan project system akan terjadwal dengan baik dan mudah dikontrol.

  Kekurangan :

 Persyaratan system harus digambarkan dengan jelas.

 Rincian proses harus benar-benar jelas dan tidak boleh berubah-ubah.\Sulit untuk mengadaptasi jika terjadi perubahan spesifikasi pada suatu tahapan pengembangan.

 Proses digambarkan sebagai spiral. Setiap loop mewakili satu fase dari software process. Loop paling dalam berfokus pada kelayakan dari sistem, loop selanjutnya tentang definisi dari kebutuhan, loop berikutnya berkaitan dengan desain sistem dan seterusnya. Setiap Loop dibagi menjadi beberapa sektor :

1. Objective settings (menentukan tujuan) : menentukan tujuan dari fase yang ditentukan. Batasan-batasan pada proses dan produk sudah diketahui. Perencanaan sudah disiapkan. Resiko dari proyek sudah diketahui. Alternatif strategi sudah disiapkan berdasarkan resiko-resiko yang diketahui, dan sudah direncanakan.

2. Risk assessment and reduction (Penanganan dan pengurangan resiko) : setiap resiko dianalisis secara detil pada sektor ini. Langkahlangkah penanganan dilakukan, misalnya membuat prototype untuk mengetahui ketidakcocokan kebutuhan.

3. Development and Validation (Pembangunan dan pengujian) : Setelah evaluasi resiko, maka model pengembangan sistem dipilih. Misalnya jika resiko user interface dominan, maka membuat prototype User Interface. Jika bagian keamanan yang bermasalah, maka menggunakan model formal dengan perhitungan matematis, dan jika masalahnya adalah integrasi sistem model waterfall lebih cocok.

4. Planning : Proyek dievaluasi atau ditinjau-ulang dan diputuskan untuk terus ke fase loop selanjutnya atau tidak. Jika melanjutkan ke fase berikutnya rencana untuk loop

selanjutnya.

Pembagian sektor tidak bisa saja dikembangkan seperti pada pembagian sektor berikut pada model variasi spiral di bawah ini:

Kadang-kadang klien hanya memberikan beberapa kebutuhan umum software tanpa detil input, proses atau detil output. Di lain waktu mungkin dimana tim pembangun (developer) tidak yakin terhadap efisiensi dari algoritma yang digunakan, tingkat adaptasi terhadap sistem operasi atau rancangan form user interface. Ketika situasi seperti ini terjadi model prototyping sangat

membantu proses pembangunan software.

Proses pada model prototyping yang digambarkan pada gambar 1, bisa dijelaskan

sebagai berikut:

1. pengumpulan kebutuhan : developer dan klien bertemu dan menentukan tujuan umum, kebutuhan yang diketahui dan gambaran bagian-bagian yang akan dibutuhkan

berikutnya. Detil kebutuhan mungkin tidak dibicarakan disini, pada awal pengumpulan kebutuhan.

2. perancangan : perancangan dilakukan cepat dan rancangan mewakili semua aspek software yang diketahui, dan rancangan ini menjadi dasar pembuatan prototype. 3. Evaluasi prototype : klien mengevaluasi prototype yang dibuat dan digunakan untuk

memperjelas kebutuhan software. Perulangan ketiga proses ini terus berlangsung hingga semua kebutuhan terpenuhi. Prototype-prototype dibuat untuk memuaskan kebutuhan klien dan untuk memahami kebutuhan klien lebih baik.

Prototype yang dibuat dapat dimanfaatkan kembali untuk membangun software lebih cepat, namun tidak semua prototype bisa dimanfaatkan. Sekalipun prototype memudahkan komunikasi antar developer dan klien, membuat klien mendapat gambaran awal dari prototype, membantu mendapatkan kebutuhan detil lebih baik namun demikian prototype juga menimbulkan masalah:

terhadap produk tersebut, maka developer harus kerja keras untuk mewujudkan produk tersebut menjadi lebih baik, sesuai kualitas yang seharusnya.

2. developer biasanya melakukan kompromi dalam beberapa hal karena harus membuat prototype dalam waktu singkat. Mungkin sistem operasi yang tidak sesuai, bahasa pemrograman yang berbeda, atau algoritma yang lebih sederhana.

Agar model ini bisa berjalan dengan baik, perlu disepakati bersama oleh klien dan developer bahwa prototype yang dibangun merupakan alat untuk mendefinisikan kebutuhan software.

Kelebihan dan Kekurangan Prototyping Model Kelebihan :

 Prototype melibatkan user dalam analisa dan desain.

 Punya kemampuan menangkap requirement secara konkret daripada secara abstrak.

 Untuk digunakan secara standalone.

 Digunakan untuk memperluas SDLC.

 Mempersingkat waktu pengembangan Sistem Informasi

Kekurangan :

 Tidak ada cara untuk mengetahui banyaknya iterasi yang diperlakukan.

 Proses analisis dan perancangan terlalu singkat.

 Mengesampingkan alternatif pemecahan masalah.

 Bisanya kurang fleksible dalam mengahdapi perubahan.

 Protitype yang dihasilkan tidak selamanya mudah dirubah

 Protype terlalu cepat selesai

1. Customer communication : membangun komunikasi yang baik dengan pengguna/customer.

2. Planning : mendefinisikan sesumber, batas waktu, informasi-informasi lain seputar proyek

3. Risk analysis : identifikasi resiko managemen dan teknis

6. Customer evaluation : mendapatkan feedback dari pengguna beradasarkan evaluasi PL pada fase engineering dan fase instalasi. Pada model spiral, resiko sangat

dipertimbangkan. Resiko adalah sesuatu yang mungkin mengakibatkan kesalahan. Model spiral merupakan pendekatan yang realistik untuk PL berskala besar. Pengguna dan pembangun bisa memahami dengan baik software yang dibangun karena setiap kemajuan yang dicapai selama proses dapat diamati dengan baik. Namun demikian, waktu yang cukup panjang mungkin bukan pilihan bagi pengguna, karena waktu yang lama sama dengan biaya yang lebih besar.

Kelebihan dan Kekurangan Iterative Model Kelebihan :

 Dapat mengakomodasi jika terjadi perubahan pada tahapan pengembangan yang telah dilaksanakan.

 Dapat disesuaikan agar system bisa dipakai selama hidup software computer.

 Cocok untuk pengembangan sistem dan perangkat lunak skala besar.

 Pengembang dan pemakai dapat lebih mudah memahami dan bereaksi terhadap resiko setiap tahapan karena system terus bekerja selama proses.

Kekurangan :

 Hanya berlaku untuk Short-Lifetime system.

 Tahapan proses tidak terlihat sedang berada ditahapan mana suatu pekerjaan.

 Memerlukan alat ukur kemajuan secara regular.

 Perubahan yang sering terjadi dapat merubah struktur system.

 Memerlukan tenaga ahli dengan kemampuan tinggi.

1. kombinasikan element-element dari waterfall dengan sifat iterasi/perulangan. 2. element-element dalam waterfall dikerjakan dengan hasil berupa produk dengan

spesifikasi tertentu, kemudian proses dimulai dari fase pertama hingga akhir dan menghasilkan produk dengan spesifikasi yang lebih lengkap dari yang sebelumnya. Demikian seterusnya hingga semua spesifikasi memenuhi kebutuhan yang ditetapkan oleh pengguna.

3. produk hasil increment pertama biasanya produk inti (core product), yaitu produk yang memenuhi kebutuhan dasar. Produk tersebut digunakan oleh pengguna atau menjalani review/pengecekan detil. Hasil review tersebut menjadi bekal untuk pembangunan pada increment berikutnya. Hal ini terus dikerjakan sampai produk yang komplit dihasilkan. 4. model ini cocok jika jumlah anggota tim pengembang/pembangun PL tidak cukup. 5. Mampu mengakomodasi perubahan secara fleksibel.

6. Produk yang dihasilkan pada increment pertama bukanlah prototype, tapi produk yang sudah bisa berfungsi dengan spesifikasi dasar.

Masalah dengan Incremental model :

1. cocok untuk proyek berukuran kecil (tidak lebih dari 200.000 baris coding).

2. mungkin terjadi kesulitan untuk memetakan kebutuhan pengguna ke dalam rencana spesifikasi masing-masing hasil increment.

Kelebihan dan Kekurangan Incremental Model Kelebihan Incremental Model

 Personil bekerja optimal

 Pihak konsumen dapat langsung menggunakan dahulu bagian-bagian yang telah selesai dibangun. Contohnya pemasukan data karyawan

 Mengurangi trauma karena perubahan sistem.

 Klien dibiasakan perlahan-lahan menggunakan produknya bagian per bagian

Kekurangan Incremental Model

 kemungkinan tiap bagian tidak dapat diintegrasikan

 Dapat menjadi build and Fix Model, karena kemampuannya untuk selalu mendapat perubahan selama proses rekayasa berlangsung

 Harus Open Architecture

Process pengembangan perangkat lunak (Software development process) adalah

suatu struktur yang diterapkan pada pengembangan suatu produk perangkat lunak

yang bertujuan untuk mengembangkan sistem dan memberikan panduan yang

bertujuan untuk menyukseskan proyek pengembangan sistem melalui tahap demi

tahap. Proses ini memiliki beberapa model yang masing-masing menjelaskan

pendekatan terhadap berbagai tugas atau aktivitas yang terjadi selama proses.

Contoh model proses pengembangan perangkat lunak antara lain adalah proses

iteratif, Extreme Programming, serta proses air terjun

(waterfall)

SHARE THIS POST





















Author: Mohammad

Mohammad is the founder of STC Network which offers Web Services and Online Business

Solutions to clients around the globe. Read More →

Related Posts:

0 komentar:

Posting Lebih Baru Posting Lama Beranda

Total Tayangan Halaman

988

Subscribe now!

Join 

1807+

 People Following SS

Facebook

Twitter

Stay Updated via Email Newsletter

Popular Posts

Analisis Perbandingan Generic Software Process Model

Generic View Of Software Engineering

RPL (Rekayasa Perangkat Lunak)

Software Process

Syarat Untuk Sukses

Archive

Su Mo Tu We Th Fr Sa

◄View Archive

Social Icons

 Follow us on Facebook

 Follow us on Twitter

 Follow us on Google+

 Follow us on Pinterest

 Subscribe with RSS

Followers

About Me

Mahmud Yunus Lihat profil lengkapku

Featured Posts  Latest Posts

 Video

 Recent Comments

 Home

 Typography

 Sitemap

 Services

 Contact Back to top

ABOUT

Sahabat Sukses

Salam sahabat

 News

 Reviews

 Typography

 Blog

 Videos

 Page

0

0

0Share Widgets

Analisis Perbandingan Generic Software Process Model

Diposting oleh Mahmud Yunus , 23.47 Be the first to comment!

Pada kesempatan kali ini kelompok kami akan menganalisis perbandingan

Software Process Model, sedikit singkat dan hampir mendekati. Ada 4 Software Process Model : Waterfall Model, Spiral Model, Prototyping Model, Incremental Model.

Pada gambar disamping adalah tahapan umum dari model proses ini. Akan tetapi Roger S. Pressman memecah model ini menjadi 6 tahapan meskipun secara garis besar sama dengan tahapan-tahapan model waterfall pada umumnya. Berikut adalah penjelasan dari tahap-tahap yang dilakukan di dalam model ini menurut PressmanSystem / Information Engineering and Modeling. Permodelan ini diawali dengan mencari kebutuhan dari keseluruhan sistem yang akan diaplikasikan ke dalam bentuk software. Hal ini sangat penting, mengingat software harus dapat berinteraksi dengan elemen-elemen yang lain seperti hardware, database, dsb. Tahap ini sering disebut dengan Project Definitiona. Software Requirements Analysis. Proses pencarian kebutuhan diintensifkan dan difokuskan pada software. Untuk mengetahui sifat dari program yang akan dibuat, maka para software engineer harus mengerti tentang domain informasi dari software, misalnya fungsi yang dibutuhkan, user interface, dsb. Dari 2 aktivitas tersebut (pencarian kebutuhan sistem dan software) harus didokumentasikan dan ditunjukkan kepada pelanggan.

Design. Proses ini digunakan untuk mengubah kebutuhan-kebutuhan diatas menjadi representasi ke dalam bentuk “blueprint” software sebelum coding dimulai. Desain harus dapat mengimplementasikan kebutuhan yang telah disebutkan pada tahap sebelumnya. Seperti 2 aktivitas sebelumnya, maka proses ini juga harus didokumentasikan sebagai konfigurasi dari software.

Coding. Untuk dapat dimengerti oleh mesin, dalam hal ini adalah komputer, maka desain tadi harus diubah bentuknya menjadi bentuk yang dapat dimengerti oleh mesin, yaitu ke dalam bahasa pemrograman melalui proses coding. Tahap ini merupakan implementasi dari tahap design yang secara teknis nantinya dikerjakan oleh programmer.

Testing / Verification. Sesuatu yang dibuat haruslah diujicobakan. Demikian juga dengan software. Semua fungsi-fungsi software harus diujicobakan, agar software bebas dari error, dan hasilnya harus benar-benar sesuai dengan kebutuhan yang sudah didefinisikan

sebelumnya.

Maintenance. Pemeliharaan suatu software diperlukan, termasuk di dalamnya adalah pengembangan, karena software yang dibuat tidak selamanya hanya seperti itu. Ketika dijalankan mungkin saja masih ada errors kecil yang tidak ditemukan sebelumnya, atau ada penambahan fitur-fitur yang belum ada pada software tersebut. Pengembangan diperlukan ketika adanya perubahan dari eksternal perusahaan seperti ketika ada pergantian sistem operasi, atau perangkat lainnya.

Masalah dengan waterfall :

1. Perubahan sulit dilakukan karena sifatnya yang kaku.

2. Karena sifat kakunya, model ini cocok ketika kebutuhan dikumpulkan secara lengkap sehingga perubahan bisa ditekan sekecil mungkin. Tapi pada kenyataannya jarang sekali konsumen/pengguna yang bisa memberikan kebutuhan secara lengkap, perubahan kebutuhan adalah sesuatu yang wajar terjadi.

3. Waterfall pada umumnya digunakan untuk rekayasa sistem yang besar dimana proyek dikerjakan di beberapa tempat berbeda, dan dibagi menjadi beberapa bagian sub-proyek

Kelebihan dan Kekurangan Waterfall Model Kelebihan :

 Merupakan model pengembangan paling handal dan paling lama digunakan.

 Cocok untuk system software berskala besar.

 Cocok untuk system software yang bersifat generic.

 Pengerjaan project system akan terjadwal dengan baik dan mudah dikontrol.

  Kekurangan :

 Persyaratan system harus digambarkan dengan jelas.

 Rincian proses harus benar-benar jelas dan tidak boleh berubah-ubah.\Sulit untuk mengadaptasi jika terjadi perubahan spesifikasi pada suatu tahapan pengembangan.

 Proses digambarkan sebagai spiral. Setiap loop mewakili satu fase dari software process. Loop paling dalam berfokus pada kelayakan dari sistem, loop selanjutnya tentang definisi dari kebutuhan, loop berikutnya berkaitan dengan desain sistem dan seterusnya. Setiap Loop dibagi menjadi beberapa sektor :

1. Objective settings (menentukan tujuan) : menentukan tujuan dari fase yang ditentukan. Batasan-batasan pada proses dan produk sudah diketahui. Perencanaan sudah disiapkan. Resiko dari proyek sudah diketahui. Alternatif strategi sudah disiapkan berdasarkan resiko-resiko yang diketahui, dan sudah direncanakan.

2. Risk assessment and reduction (Penanganan dan pengurangan resiko) : setiap resiko dianalisis secara detil pada sektor ini. Langkahlangkah penanganan dilakukan, misalnya membuat prototype untuk mengetahui ketidakcocokan kebutuhan.

3. Development and Validation (Pembangunan dan pengujian) : Setelah evaluasi resiko, maka model pengembangan sistem dipilih. Misalnya jika resiko user interface dominan, maka membuat prototype User Interface. Jika bagian keamanan yang bermasalah, maka menggunakan model formal dengan perhitungan matematis, dan jika masalahnya adalah integrasi sistem model waterfall lebih cocok.

4. Planning : Proyek dievaluasi atau ditinjau-ulang dan diputuskan untuk terus ke fase loop selanjutnya atau tidak. Jika melanjutkan ke fase berikutnya rencana untuk loop

selanjutnya.

Pembagian sektor tidak bisa saja dikembangkan seperti pada pembagian sektor berikut pada model variasi spiral di bawah ini:

Kadang-kadang klien hanya memberikan beberapa kebutuhan umum software tanpa detil input, proses atau detil output. Di lain waktu mungkin dimana tim pembangun (developer) tidak yakin terhadap efisiensi dari algoritma yang digunakan, tingkat adaptasi terhadap sistem operasi atau rancangan form user interface. Ketika situasi seperti ini terjadi model prototyping sangat

membantu proses pembangunan software.

Proses pada model prototyping yang digambarkan pada gambar 1, bisa dijelaskan

sebagai berikut:

1. pengumpulan kebutuhan : developer dan klien bertemu dan menentukan tujuan umum, kebutuhan yang diketahui dan gambaran bagian-bagian yang akan dibutuhkan

berikutnya. Detil kebutuhan mungkin tidak dibicarakan disini, pada awal pengumpulan kebutuhan.

2. perancangan : perancangan dilakukan cepat dan rancangan mewakili semua aspek software yang diketahui, dan rancangan ini menjadi dasar pembuatan prototype. 3. Evaluasi prototype : klien mengevaluasi prototype yang dibuat dan digunakan untuk

memperjelas kebutuhan software. Perulangan ketiga proses ini terus berlangsung hingga semua kebutuhan terpenuhi. Prototype-prototype dibuat untuk memuaskan kebutuhan klien dan untuk memahami kebutuhan klien lebih baik.

Prototype yang dibuat dapat dimanfaatkan kembali untuk membangun software lebih cepat, namun tidak semua prototype bisa dimanfaatkan. Sekalipun prototype memudahkan komunikasi antar developer dan klien, membuat klien mendapat gambaran awal dari prototype, membantu mendapatkan kebutuhan detil lebih baik namun demikian prototype juga menimbulkan masalah:

terhadap produk tersebut, maka developer harus kerja keras untuk mewujudkan produk tersebut menjadi lebih baik, sesuai kualitas yang seharusnya.

2. developer biasanya melakukan kompromi dalam beberapa hal karena harus membuat prototype dalam waktu singkat. Mungkin sistem operasi yang tidak sesuai, bahasa pemrograman yang berbeda, atau algoritma yang lebih sederhana.

Agar model ini bisa berjalan dengan baik, perlu disepakati bersama oleh klien dan developer bahwa prototype yang dibangun merupakan alat untuk mendefinisikan kebutuhan software.

Kelebihan dan Kekurangan Prototyping Model Kelebihan :

 Prototype melibatkan user dalam analisa dan desain.

 Punya kemampuan menangkap requirement secara konkret daripada secara abstrak.

 Untuk digunakan secara standalone.

 Digunakan untuk memperluas SDLC.

 Mempersingkat waktu pengembangan Sistem Informasi

Kekurangan :

 Tidak ada cara untuk mengetahui banyaknya iterasi yang diperlakukan.

 Proses analisis dan perancangan terlalu singkat.

 Mengesampingkan alternatif pemecahan masalah.

 Bisanya kurang fleksible dalam mengahdapi perubahan.

 Protitype yang dihasilkan tidak selamanya mudah dirubah

 Protype terlalu cepat selesai

1. Customer communication : membangun komunikasi yang baik dengan pengguna/customer.

2. Planning : mendefinisikan sesumber, batas waktu, informasi-informasi lain seputar proyek

3. Risk analysis : identifikasi resiko managemen dan teknis

6. Customer evaluation : mendapatkan feedback dari pengguna beradasarkan evaluasi PL pada fase engineering dan fase instalasi. Pada model spiral, resiko sangat

dipertimbangkan. Resiko adalah sesuatu yang mungkin mengakibatkan kesalahan. Model spiral merupakan pendekatan yang realistik untuk PL berskala besar. Pengguna dan pembangun bisa memahami dengan baik software yang dibangun karena setiap kemajuan yang dicapai selama proses dapat diamati dengan baik. Namun demikian, waktu yang cukup panjang mungkin bukan pilihan bagi pengguna, karena waktu yang lama sama dengan biaya yang lebih besar.

Kelebihan dan Kekurangan Iterative Model Kelebihan :

 Dapat mengakomodasi jika terjadi perubahan pada tahapan pengembangan yang telah dilaksanakan.

 Dapat disesuaikan agar system bisa dipakai selama hidup software computer.

 Cocok untuk pengembangan sistem dan perangkat lunak skala besar.

 Pengembang dan pemakai dapat lebih mudah memahami dan bereaksi terhadap resiko setiap tahapan karena system terus bekerja selama proses.

Kekurangan :

 Hanya berlaku untuk Short-Lifetime system.

 Tahapan proses tidak terlihat sedang berada ditahapan mana suatu pekerjaan.

 Memerlukan alat ukur kemajuan secara regular.

 Perubahan yang sering terjadi dapat merubah struktur system.

 Memerlukan tenaga ahli dengan kemampuan tinggi.

1. kombinasikan element-element dari waterfall dengan sifat iterasi/perulangan. 2. element-element dalam waterfall dikerjakan dengan hasil berupa produk dengan

spesifikasi tertentu, kemudian proses dimulai dari fase pertama hingga akhir dan menghasilkan produk dengan spesifikasi yang lebih lengkap dari yang sebelumnya. Demikian seterusnya hingga semua spesifikasi memenuhi kebutuhan yang ditetapkan oleh pengguna.

3. produk hasil increment pertama biasanya produk inti (core product), yaitu produk yang memenuhi kebutuhan dasar. Produk tersebut digunakan oleh pengguna atau menjalani review/pengecekan detil. Hasil review tersebut menjadi bekal untuk pembangunan pada increment berikutnya. Hal ini terus dikerjakan sampai produk yang komplit dihasilkan. 4. model ini cocok jika jumlah anggota tim pengembang/pembangun PL tidak cukup. 5. Mampu mengakomodasi perubahan secara fleksibel.

6. Produk yang dihasilkan pada increment pertama bukanlah prototype, tapi produk yang sudah bisa berfungsi dengan spesifikasi dasar.

Masalah dengan Incremental model :

1. cocok untuk proyek berukuran kecil (tidak lebih dari 200.000 baris coding).

2. mungkin terjadi kesulitan untuk memetakan kebutuhan pengguna ke dalam rencana spesifikasi masing-masing hasil increment.

Kelebihan dan Kekurangan Incremental Model Kelebihan Incremental Model

 Personil bekerja optimal

 Pihak konsumen dapat langsung menggunakan dahulu bagian-bagian yang telah selesai dibangun. Contohnya pemasukan data karyawan

 Mengurangi trauma karena perubahan sistem.

 Klien dibiasakan perlahan-lahan menggunakan produknya bagian per bagian

Kekurangan Incremental Model

 kemungkinan tiap bagian tidak dapat diintegrasikan

 Dapat menjadi build and Fix Model, karena kemampuannya untuk selalu mendapat perubahan selama proses rekayasa berlangsung

 Harus Open Architecture

Process pengembangan perangkat lunak (Software development process) adalah

suatu struktur yang diterapkan pada pengembangan suatu produk perangkat lunak

yang bertujuan untuk mengembangkan sistem dan memberikan panduan yang

bertujuan untuk menyukseskan proyek pengembangan sistem melalui tahap demi

tahap. Proses ini memiliki beberapa model yang masing-masing menjelaskan

pendekatan terhadap berbagai tugas atau aktivitas yang terjadi selama proses.

Contoh model proses pengembangan perangkat lunak antara lain adalah proses

iteratif, Extreme Programming, serta proses air terjun

(waterfall)

SHARE THIS POST





















Author: Mohammad

Mohammad is the founder of STC Network which offers Web Services and Online Business

Solutions to clients around the globe. Read More →

Related Posts:

0 komentar:

Posting Lebih Baru Posting Lama Beranda

Total Tayangan Halaman

988

Subscribe now!

Join 

1807+

 People Following SS

Facebook

Twitter

Stay Updated via Email Newsletter

Popular Posts

Analisis Perbandingan Generic Software Process Model

Generic View Of Software Engineering

RPL (Rekayasa Perangkat Lunak)

Software Process

Syarat Untuk Sukses

Archive

Su Mo Tu We Th Fr Sa

◄View Archive

Social Icons

 Follow us on Facebook

 Follow us on Twitter

 Follow us on Google+

 Follow us on Pinterest

 Subscribe with RSS

Followers

About Me

Mahmud Yunus Lihat profil lengkapku

Featured Posts  Latest Posts

 Video

 Recent Comments

 Home

 Typography

 Sitemap

 Services

 Contact Back to top

ABOUT

© 2012 Designed by My Blogger Tricks

Local News Simsalabim Indonesia Clicking Here! Sahabat Sukses Salam sahabat News

Reviews Typography Blog Videos Page 0 0 0 Share Widgets Analisis Perbandingan Generic Software Process Model Diposting oleh Mahmud Yunus , 23.47 Be the first to comment! Pada kesempatan kali ini kelompok kami akan menganalisis perbandingan Generic Software Process Model, sedikit singkat dan hampir mendekati. Ada 4 Software Process Model : Waterfall Model, Spiral Model, Prototyping Model, Incremental Model. Waterfaal Model Pada gambar disamping adalah tahapan umum dari model proses ini. Akan tetapi Roger S. Pressman memecah model ini menjadi 6 tahapan meskipun secara garis besar sama dengan tahapan-tahapan model waterfall pada umumnya. Berikut adalah penjelasan dari tahap-tahap yang dilakukan di dalam model ini menurut Pressman System / Information Engineering and Modeling. Permodelan ini diawali dengan mencari kebutuhan dari keseluruhan sistem yang akan diaplikasikan ke dalam bentuk software. Hal ini sangat penting, mengingat software harus dapat berinteraksi dengan elemen-elemen yang lain seperti hardware, database, dsb. Tahap ini sering disebut dengan Project Definitiona. Software Requirements Analysis. Proses pencarian kebutuhan diintensifkan dan difokuskan pada software. Untuk mengetahui sifat dari program yang akan dibuat, maka para software engineer harus mengerti tentang domain informasi dari software, misalnya fungsi yang dibutuhkan, user interface, dsb. Dari 2 aktivitas tersebut (pencarian kebutuhan sistem dan software) harus didokumentasikan dan ditunjukkan kepada pelanggan. Design. Proses ini digunakan untuk mengubah kebutuhan-kebutuhan diatas menjadi representasi ke dalam bentuk “blueprint” software sebelum coding dimulai. Desain harus dapat mengimplementasikan

kebutuhan yang telah disebutkan pada tahap sebelumnya. Seperti 2 aktivitas sebelumnya, maka proses ini juga harus didokumentasikan sebagai konfigurasi dari software. Coding. Untuk dapat dimengerti oleh mesin, dalam hal ini adalah komputer, maka desain tadi harus diubah bentuknya menjadi bentuk yang dapat dimengerti oleh mesin, yaitu ke dalam bahasa pemrograman melalui proses coding. Tahap ini merupakan implementasi dari tahap design yang secara teknis nantinya dikerjakan oleh programmer. Testing / Verification. Sesuatu yang dibuat haruslah diujicobakan. Demikian juga dengan software. Semua fungsi-fungsi software harus diujicobakan, agar software bebas dari error, dan hasilnya harus benar-benar sesuai dengan kebutuhan yang sudah

berbeda, dan dibagi menjadi beberapa bagian sub-proyek Kelebihan dan Kekurangan Waterfall Model Kelebihan : Merupakan model pengembangan paling handal dan paling lama digunakan. Cocok untuk system software berskala besar. Cocok untuk system software yang bersifat generic. Pengerjaan project system akan terjadwal dengan baik dan mudah dikontrol.

Kekurangan : Persyaratan system harus digambarkan dengan jelas. Rincian proses harus benar-benar jelas dan tidak boleh berubah-ubah.\Sulit untuk mengadaptasi jika terjadi perubahan spesifikasi pada suatu tahapan pengembangan. 2. Iterative Model/Spiral Model Proses

digambarkan sebagai spiral. Setiap loop mewakili satu fase dari software process. Loop paling dalam berfokus pada kelayakan dari sistem, loop selanjutnya tentang definisi dari kebutuhan, loop berikutnya berkaitan dengan desain sistem dan seterusnya. Setiap Loop dibagi menjadi beberapa sektor : Objective settings (menentukan tujuan) : menentukan tujuan dari fase yang ditentukan. Batasan-batasan pada proses dan produk sudah diketahui. Perencanaan sudah disiapkan. Resiko dari proyek sudah diketahui. Alternatif strategi sudah disiapkan berdasarkan resiko-resiko yang diketahui, dan sudah direncanakan. Risk assessment and reduction

(Penanganan dan pengurangan resiko) : setiap resiko dianalisis secara detil pada sektor ini. Langkahlangkah penanganan dilakukan, misalnya membuat prototype untuk mengetahui ketidakcocokan kebutuhan. Development and Validation (Pembangunan dan pengujian) : Setelah evaluasi resiko, maka model pengembangan sistem dipilih. Misalnya jika resiko user interface dominan, maka membuat prototype User Interface. Jika bagian keamanan yang bermasalah, maka menggunakan model formal dengan perhitungan matematis, dan jika masalahnya adalah integrasi sistem model waterfall lebih cocok. Planning : Proyek dievaluasi atau ditinjau-ulang dan diputuskan untuk terus ke fase loop selanjutnya atau tidak. Jika melanjutkan ke fase berikutnya rencana untuk loop selanjutnya. Pembagian sektor tidak bisa saja dikembangkan seperti pada pembagian sektor berikut pada model variasi spiral di bawah ini: 3. Prototyping Model Kadang-kadang klien hanya memberikan beberapa kebutuhan umum software tanpa detil input, proses atau detil output. Di lain waktu mungkin dimana tim

pembangun (developer) tidak yakin terhadap efisiensi dari algoritma yang digunakan, tingkat adaptasi terhadap sistem operasi atau rancangan form user interface. Ketika situasi seperti ini terjadi model prototyping sangat membantu proses pembangunan software. Proses pada model prototyping yang digambarkan pada gambar 1, bisa dijelaskan sebagai berikut: pengumpulan kebutuhan : developer dan klien bertemu dan menentukan tujuan umum, kebutuhan yang diketahui dan gambaran bagian-bagian yang akan dibutuhkan berikutnya. Detil kebutuhan mungkin tidak dibicarakan disini, pada awal pengumpulan kebutuhan. perancangan :

dalam membuat prototype banyak hal yang diabaikan seperti efisiensi, kualitas, kemudahan dipelihara/dikembangkan, dan kecocokan dengan lingkungan yang sebenarnya. Jika klien merasa cocok dengan prototype yang disajikan dan berkeras terhadap produk tersebut, maka developer harus kerja keras untuk mewujudkan produk tersebut menjadi lebih baik, sesuai kualitas yang seharusnya. developer biasanya melakukan kompromi dalam beberapa hal karena harus membuat prototype dalam waktu singkat. Mungkin sistem operasi yang tidak sesuai, bahasa pemrograman yang berbeda, atau algoritma yang lebih sederhana. Agar model ini bisa berjalan dengan baik, perlu disepakati bersama oleh klien dan developer bahwa prototype yang dibangun merupakan alat untuk mendefinisikan kebutuhan software. Kelebihan dan Kekurangan Prototyping Model Kelebihan : Prototype melibatkan user dalam analisa dan desain. Punya kemampuan menangkap requirement secara konkret daripada secara abstrak. Untuk digunakan secara standalone. Digunakan untuk memperluas SDLC. Mempersingkat waktu pengembangan Sistem Informasi Kekurangan : Tidak ada cara untuk mengetahui banyaknya iterasi yang

diperlakukan. Proses analisis dan perancangan terlalu singkat. Mengesampingkan alternatif pemecahan masalah. Bisanya kurang fleksible dalam mengahdapi perubahan. Protitype yang dihasilkan tidak selamanya mudah dirubah Protype terlalu cepat selesai Customer

communication : membangun komunikasi yang baik dengan pengguna/customer. Planning : mendefinisikan sesumber, batas waktu, informasi-informasi lain seputar proyek Risk analysis : identifikasi resiko managemen dan teknis Engineering : pembangunan contoh-contoh aplikasi, misalnya prototype Construction and release : pembangunan, test, install dan support. Customer evaluation : mendapatkan feedback dari pengguna beradasarkan evaluasi PL pada fase

tersebut menjadi bekal untuk pembangunan pada increment berikutnya. Hal ini terus dikerjakan sampai produk yang komplit dihasilkan. model ini cocok jika jumlah anggota tim

pengembang/pembangun PL tidak cukup. Mampu mengakomodasi perubahan secara fleksibel. Produk yang dihasilkan pada increment pertama bukanlah prototype, tapi produk yang sudah bisa berfungsi dengan spesifikasi dasar. Masalah dengan Incremental model : cocok untuk proyek berukuran kecil (tidak lebih dari 200.000 baris coding). mungkin terjadi kesulitan untuk memetakan kebutuhan pengguna ke dalam rencana spesifikasi masing-masing hasil increment. Kelebihan dan Kekurangan Incremental Model Kelebihan Incremental Model Personil bekerja optimal Pihak konsumen dapat langsung menggunakan dahulu bagian-bagian yang telah selesai dibangun. Contohnya pemasukan data karyawan Mengurangi trauma karena perubahan sistem. Klien dibiasakan perlahan-lahan menggunakan produknya bagian per bagian Memaksimalkan pengembalian modal investasi konsumen Kekurangan Incremental Model kemungkinan tiap bagian tidak dapat diintegrasikan Dapat menjadi build and Fix Model, karena kemampuannya untuk selalu mendapat perubahan selama proses rekayasa berlangsung Harus Open

software. Hal ini sangat penting, mengingat software harus dapat berinteraksi dengan elemen-elemen yang lain seperti hardware, database, dsb. Tahap ini sering disebut dengan Project Definitiona. Software Requirements Analysis. Proses pencarian kebutuhan diintensifkan dan difokuskan pada software. Untuk mengetahui sifat dari program yang akan dibuat, maka para software engineer harus mengerti tentang domain informasi dari software, misalnya fungsi yang dibutuhkan, user interface, dsb. Dari 2 aktivitas tersebut (pencarian kebutuhan sistem dan software) harus didokumentasikan dan ditunjukkan kepada pelanggan. Design. Proses ini digunakan untuk mengubah kebutuhan-kebutuhan diatas menjadi representasi ke dalam bentuk “blueprint” software sebelum coding dimulai. Desain harus dapat mengimplementasikan

kebutuhan yang telah disebutkan pada tahap sebelumnya. Seperti 2 aktivitas sebelumnya, maka proses ini juga harus didokumentasikan sebagai konfigurasi dari software. Coding. Untuk dapat dimengerti oleh mesin, dalam hal ini adalah komputer, maka desain tadi harus diubah bentuknya menjadi bentuk yang dapat dimengerti oleh mesin, yaitu ke dalam bahasa pemrograman melalui proses coding. Tahap ini merupakan implementasi dari tahap design yang secara teknis nantinya dikerjakan oleh programmer. Testing / Verification. Sesuatu yang dibuat haruslah diujicobakan. Demikian juga dengan software. Semua fungsi-fungsi software harus diujicobakan, agar software bebas dari error, dan hasilnya harus benar-benar sesuai dengan kebutuhan yang sudah

didefinisikan sebelumnya. Maintenance. Pemeliharaan suatu software diperlukan, termasuk di dalamnya adalah pengembangan, karena software yang dibuat tidak selamanya hanya seperti itu. Ketika dijalankan mungkin saja masih ada errors kecil yang tidak ditemukan sebelumnya, atau ada penambahan fitur-fitur yang belum ada pada software tersebut. Pengembangan diperlukan ketika adanya perubahan dari eksternal perusahaan seperti ketika ada pergantian sistem operasi, atau perangkat lainnya. Kekurangan yang utama dari model ini adalah kesulitan dalam mengakomodasi perubahan setelah proses dijalani. Fase sebelumnya harus lengkap dan selesai sebelum mengerjakan fase berikutnya. Masalah dengan waterfall : Perubahan sulit dilakukan karena sifatnya yang kaku. Karena sifat kakunya, model ini cocok ketika kebutuhan dikumpulkan secara lengkap sehingga perubahan bisa ditekan sekecil mungkin. Tapi pada kenyataannya jarang sekali konsumen/pengguna yang bisa memberikan kebutuhan secara lengkap, perubahan kebutuhan adalah sesuatu yang wajar terjadi. Waterfall pada umumnya digunakan untuk rekayasa sistem yang besar dimana proyek dikerjakan di beberapa tempat berbeda, dan dibagi menjadi beberapa bagian sub-proyek Kelebihan dan Kekurangan Waterfall Model Kelebihan : Merupakan model pengembangan paling handal dan paling lama digunakan. Cocok untuk system software berskala besar. Cocok untuk system software yang bersifat generic. Pengerjaan project system akan terjadwal dengan baik dan mudah dikontrol.

Kekurangan : Persyaratan system harus digambarkan dengan jelas. Rincian proses harus benar-benar jelas dan tidak boleh berubah-ubah.\Sulit untuk mengadaptasi jika terjadi perubahan spesifikasi pada suatu tahapan pengembangan. 2. Iterative Model/Spiral Model Proses

disiapkan. Resiko dari proyek sudah diketahui. Alternatif strategi sudah disiapkan berdasarkan resiko-resiko yang diketahui, dan sudah direncanakan. Risk assessment and reduction

(Penanganan dan pengurangan resiko) : setiap resiko dianalisis secara detil pada sektor ini. Langkahlangkah penanganan dilakukan, misalnya membuat prototype untuk mengetahui ketidakcocokan kebutuhan. Development and Validation (Pembangunan dan pengujian) : Setelah evaluasi resiko, maka model pengembangan sistem dipilih. Misalnya jika resiko user interface dominan, maka membuat prototype User Interface. Jika bagian keamanan yang bermasalah, maka menggunakan model formal dengan perhitungan matematis, dan jika masalahnya adalah integrasi sistem model waterfall lebih cocok. Planning : Proyek dievaluasi atau ditinjau-ulang dan diputuskan untuk terus ke fase loop selanjutnya atau tidak. Jika melanjutkan ke fase berikutnya rencana untuk loop selanjutnya. Pembagian sektor tidak bisa saja dikembangkan seperti pada pembagian sektor berikut pada model variasi spiral di bawah ini: 3. Prototyping Model Kadang-kadang klien hanya memberikan beberapa kebutuhan umum software tanpa detil input, proses atau detil output. Di lain waktu mungkin dimana tim

pembangun (developer) tidak yakin terhadap efisiensi dari algoritma yang digunakan, tingkat adaptasi terhadap sistem operasi atau rancangan form user interface. Ketika situasi seperti ini terjadi model prototyping sangat membantu proses pembangunan software. Proses pada model prototyping yang digambarkan pada gambar 1, bisa dijelaskan sebagai berikut: pengumpulan kebutuhan : developer dan klien bertemu dan menentukan tujuan umum, kebutuhan yang diketahui dan gambaran bagian-bagian yang akan dibutuhkan berikutnya. Detil kebutuhan mungkin tidak dibicarakan disini, pada awal pengumpulan kebutuhan. perancangan :

Sistem Informasi Kekurangan : Tidak ada cara untuk mengetahui banyaknya iterasi yang diperlakukan. Proses analisis dan perancangan terlalu singkat. Mengesampingkan alternatif pemecahan masalah. Bisanya kurang fleksible dalam mengahdapi perubahan. Protitype yang dihasilkan tidak selamanya mudah dirubah Protype terlalu cepat selesai Customer

communication : membangun komunikasi yang baik dengan pengguna/customer. Planning : mendefinisikan sesumber, batas waktu, informasi-informasi lain seputar proyek Risk analysis : identifikasi resiko managemen dan teknis Engineering : pembangunan contoh-contoh aplikasi, misalnya prototype Construction and release : pembangunan, test, install dan support. Customer evaluation : mendapatkan feedback dari pengguna beradasarkan evaluasi PL pada fase

engineering dan fase instalasi. Pada model spiral, resiko sangat dipertimbangkan. Resiko adalah sesuatu yang mungkin mengakibatkan kesalahan. Model spiral merupakan pendekatan yang realistik untuk PL berskala besar. Pengguna dan pembangun bisa memahami dengan baik software yang dibangun karena setiap kemajuan yang dicapai selama proses dapat diamati dengan baik. Namun demikian, waktu yang cukup panjang mungkin bukan pilihan bagi pengguna, karena waktu yang lama sama dengan biaya yang lebih besar. Kelebihan dan Kekurangan Iterative Model Kelebihan : Dapat mengakomodasi jika terjadi perubahan pada tahapan pengembangan yang telah dilaksanakan. Dapat disesuaikan agar system bisa dipakai selama hidup software computer. Cocok untuk pengembangan sistem dan perangkat lunak skala besar. Pengembang dan pemakai dapat lebih mudah memahami dan bereaksi terhadap resiko setiap tahapan karena system terus bekerja selama proses. Kekurangan : Hanya berlaku untuk Short-Lifetime system. Tahapan proses tidak terlihat sedang berada ditahapan mana suatu pekerjaan. Memerlukan alat ukur kemajuan secara regular. Perubahan yang sering terjadi dapat merubah struktur system. Memerlukan tenaga ahli dengan kemampuan tinggi. 4. Incremental Mode kombinasikan element dari waterfall dengan sifat iterasi/perulangan. element-element dalam waterfall dikerjakan dengan hasil berupa produk dengan spesifikasi tertentu, kemudian proses dimulai dari fase pertama hingga akhir dan menghasilkan produk dengan spesifikasi yang lebih lengkap dari yang sebelumnya. Demikian seterusnya hingga semua spesifikasi memenuhi kebutuhan yang ditetapkan oleh pengguna. produk hasil increment pertama biasanya produk inti (core product), yaitu produk yang memenuhi kebutuhan dasar. Produk tersebut digunakan oleh pengguna atau menjalani review/pengecekan detil. Hasil review tersebut menjadi bekal untuk pembangunan pada increment berikutnya. Hal ini terus dikerjakan sampai produk yang komplit dihasilkan. model ini cocok jika jumlah anggota tim

bagian tidak dapat diintegrasikan Dapat menjadi build and Fix Model, karena kemampuannya untuk selalu mendapat perubahan selama proses rekayasa berlangsung Harus Open

Architecture Process pengembangan perangkat lunak (Software development process) adalah suatu struktur yang diterapkan pada pengembangan suatu produk perangkat lunak yang bertujuan untuk mengembangkan sistem dan memberikan panduan yang bertujuan untuk menyukseskan proyek pengembangan sistem melalui tahap demi tahap. Proses ini memiliki beberapa model yang masing-masing menjelaskan pendekatan terhadap berbagai tugas atau aktivitas yang terjadi selama proses. Contoh model proses pengembangan perangkat lunak antara lain adalah proses iteratif, Extreme Programming, serta proses air terjun (waterfall) SHARE THIS POST Author: Mohammad Mohammad is the founder of STC Network which offers Web Services and Online Business Solutions to clients around the globe. Read More → Related Posts: 0 komentar: Posting Lebih Baru Posting Lama Beranda Total Tayangan Halaman 988 Subscribe now! Join 1807+ People Following SS RSSFacebookTwitterStay Updated via Email Newsletter Popular Posts Analisis Perbandingan Generic Software Process Model Generic View Of Software Engineering RPL (Rekayasa Perangkat Lunak) Software Process Syarat Untuk Sukses Archive Su Mo Tu We Th Fr Sa ◄ View Archive Custom Text Widget Social Icons Follow us on Facebook Follow us on Twitter Follow us on Google+ Follow us on Pinterest Subscribe with RSS Followers About Me Mahmud Yunus Lihat profil lengkapku Featured Posts Latest Posts Video Recent Comments HomeTypographySitemapServicesContact Back to top ABOUT

ShareThis Copy and Paste © 2012 Designed by My Blogger Tricks © 2012 Designed by My Blogger Tricks

© 2012 Designed by My Blogger Tricks

__________

Tugas RPL-Langsung Jawaban

Tugas RPL..

4.1 Jelaskan mengapa ketidakberwujudan sistem perangkat lunak menimbulkan masalah khusus

pada manajemen proyek perangkat lunak.

4.2 Jelaskan mengapa programmer terbaik tidak selalu merupakan manajer perangkat lunak teraik.

Anda bisa terbantu jika mendasarkan jawaban Anda pada daftar kegiatan manajemen yang

diberikan pada subbab 4.1

4.3 Jelaskan mengapa proses perencanaan proyek bersifat iteratif dan mengapa sebuah rencana harus senantiasa ditinjau pada saat pelaksanaan proyek

perangkat lunak.

4.4 Jelaskan dengan singkat tujuan setiap bagian pada rencana proyek perangkat lunak

diserahkan (deliverables)?

4.6 Peraga 4.16 menujukan sejumlah kegiatan, duasi, dan ketergantungan. Buat diagram kegiatan dan diagram batang yang menunjukan jadwal proyek.

4.7 Peraga 4.5 memberikan durasi pekerjaan untuk kegiatan proyek perangkat lunak.

Misalkan terjadi kemunduran yang serius dan tidak diantisipasi sehingga pekerjaan

T5 memakan waktu 40 hari dan bukan 10 hari. Revisilah jaringan kegiatan dengan menujukan jalur kritis yang baru. Buat diagram batang baru yang menunjukan bagaimana proyek dapat disusun ulang.

4.8 Dengan menggunakan contoh masalah proyek yang dilaporkan pada literatur, buat daftar kesulitan

manajemen yang terjadi pada proyek pemrograman yang gagal ini. (Mulailah dengan buku Brook,

sebagaimana dianjurkan pada bacaan lajutan).

4.9 Sebagai Tambahan Untuk beberapa resiko yang ditujukan pada Peraga 4.12, identifikasi enam risiko lainnya yang mungkin muncul pada proyek perangkat lunak.

JAWAB :

4.1 Sudah jelas kan.

Kalau sistemnya saja tidak jelas (tidak berwujud) bagaimana kita bisa me-manage-nya?

Sulit untuk mengatur sesuatu yang tidak berwujud.

4.2 Perlu anda ketahui, programmer dan manajer itu berbeda! Tetapi bisa jadi seorang manajer adalah juga seorang programmer yang handal, namun belum tentu seorang programmer yang handal adalah seorang manajer yang baik. Kaitannya dengan pertanyaan anda, jawabannya adalah karena seorang programmer adalah seorang ekspert/akhli yang tugasnya membuat program tentang sesuatu aplikasi, misalnya aplikasi gaji (payroll), aplikasi akuntansi perusahaan besar atau menengah, dll aplikasi lainnya yang dibutuhkan

perusahaan sesuai dengan bidang usahanya. Bisa jadi dalam membuat program itu, seorang programmer melaksanakannya seorang diri dari awal sampai

selesai.

Sedangkan manajer perangkat lunak, adalah orang yang mengendalikan

beberapa orang yang berada dibawahnya, mungkin saja programmer-programer yang ada di bawahnya untuk mencapai tujuan usaha perusahaan. Haruskah seorang manajer perangkat lunak adalah juga seorang programmer? Tentunya idealnya ya! karena hal ini akan sangat membantu tugas manajernya dalam mengawasi bawahannya, tetapi tidak harus, yang penting adalah ybs mampu mengkordinir atau mengatur orang lain untuk kemajuan perusahaan. Ini berarti pula belum tentu seorang programmer yang terbaik sekalipun akan mampu jadi manajer perangkat lunak yang baik, karena belum tentu ia mampu mengerakkan orang lain untuk kemajuan perusahaan.

Bersifat iteratif/ mengandung perulangan. Hasil proses berupa produk

yang makin lama makin lengkap sampai versi terlengkap dihasilkan sebagai produk akhir dari proses.

4.4 Tujuan perencanaan proyek perangkat lunak adalah untuk menyediakan sebuah kerangka kerja yang memungkinkan manajer membuat estimasi yang dapat dipertanggungjawabkan mengenai sumber daya, biaya dan jadwal. Tujuan perencanaan dicapai melalui suatu proses penemuan informasi yang menunjuk ke estimasi yang dapat dipertanggungjawabkan.

4.5

 Ketika merencanakan proyek, serangkaian patokan (milestone) harus ditentukan. Patokan ini merupakan akhir dari suatu aktivitas proses perangkat lunak.

 Pada setiap patokan harus ada output formal, seperti laporan yang dapat

diberikan kepada manajemen.

 Hasil yang diserahkan (deliverables) adalah hasil proyek yang dikirimkan ke

pelanggan. Hasil ini biasanya dikirimkan pada akhir fase proyek yang besar seperti spesifikasi, perancangan, dsb.

 Deliverables biasanya merupakan patokan (milestones), tetapi patokan belum

tentu merupakan deliverables.

 Patokan ini bisa jadi berupa hasil proyek internal yang dipakai oleh manajer

proyek untuk memeriksa kemajuan proyek, yang tidak diserahkan kepada pelanggan