Tampilkan postingan dengan label Rekayasa Software. Tampilkan semua postingan
Tampilkan postingan dengan label Rekayasa Software. Tampilkan semua postingan

Rabu, 30 Januari 2013

ANALISIS BERORIENTASI OBJEK

Sasaran analisis object oriented (OOA)  adalah mengembangkan sederetan model yang menggambarkan perangkat lunak komputer pada saat perangkat itu bekerja untuk memenuhi serangkaian persyaratan yang ditentukan oleh pelanggan.

Menurut Fichman dan Kemerer, yang dapat digunakan untuk membandingkan berbagai medote OOA dan Konvensional :Menurut Fichman dan Kemerer, yang dapat digunakan untuk membandingkan berbagai medote OOA dan Konvensional :
1.   Edentifikasi / klasifikasi entitas
2.   Umum ke spesifik dan keseluruhan ke hubungan entitas bagian
3.   Hubungan entitas lain
4.   Gambaran atribut entitas
5.   Partisi model skala besar
6.   Keadaan dan transisi anta keadaan
7.   Spesifikasi detail untuk fungsi
8.   Dekomposisi top-down
9.   Urutan pemrosesan end-to-end
10. Edentifikasi pelayanan eksklusif
11. Komunikasi entitas (melalui pesan atau even)



Landskap OOA


Beberapa metode yang lebih populer dalam bentuk outline. Maksudnya adalah untuk memberikan gambaran mengenai OOA yang telah diusulkan oleh penulis metode tersebut.

○ Metode Booch
Outline singkat dari pengembangannya :
» Identifikasi kelas dan objek :
   Usulkan objek calon
   Lakukan analisis tingkah laku
   Identifikasi scenario yang relevan
   Tentukan atribut dan operasi untuk masing-masing kelas.

» Identifikasi Semantik dari kelas dan objek :
   Pilih scenario dan analisis
   Tentukan tanggung jawab untuk mencapai tingkah laku yang diinginkan
   Bagikan tanggung jawab untuk menyeimbangkan tingkah laku
   Tentukan objek dan sebutkan tugas dan tanggung jawabnya satu persatu
   Tentukan operasi untuk memenuhi tanggung jawab
   Carilah kolaborasi diantara objek
» Identifikasi hubungan diantara kelas dan objek:
  Tentukan ketergantungan yang ada diantara objek
  Deskripsikan peran masing-masing objek yang berpartisipasi
  Validasi dengan berjalan melewati scenario
» Implementasi kelas dan objek
   Mengimplementasikan pelengkapan model analisis

○ Metode Coad dan Yourdon
Outline singkat pengembangannya :
» Identifikasi objek dengan menggunakan kriteria “apa yang dicari”
» Tentukan struktur generasi-spesifikasi
» Tentukan struktur keseluruhan bagian
» Identifikasi subjek
» Tentukan atribut
» Tentukan pelayanan

○ Metode Rambough
Outline singkat pengembangannya :
» Kembangkan pernyataan ruang lingkup masalah
» Bangun model objek :
   Identifikasi kelas yang relevan untuk masalah tersebut
   Tentukan atribut dan asosiasi
   Tentukan link objek
   Organisasikan kelas objek dengan menggunakan pewarisan
» Kembangkan model dinamis :
   Siapkan skenario
   Tentukan event dan kembangkan penelurusan event untuk masing-masing skenario
   Buatlah diagram aliran event
   Kembangkan diagram keadaan
   Kajilah tingkah laku untuk konsistensi dan kelengkapannya
» Buatlah model fungsional untuk sistem tersebut :
   Identifikasi input dan output
   Gunakan dengan aliran data untuk mempresentasikan tranformasi aliran
   Kembangkan masing-masing fungsi
   Tentukan batasan dan kriteria opsional

○ Metode Wirfs-Brock
Outline singkat pengembangannya :
» Evalusi spesifikasi pelanggan
» Gunakan uraian gramatikal untuk mengekstrak kelas calon dari spesifikasi
» Kelompokkan kelas dengan tujuan untuk mengidentifikasi superkelas
» Tentukan tanggung jawab untuk masing-masing kelas


Analisis Domain
Analisis domain perangkat lunak adalah identifikasi, analisis dan spesifikasi dari persyaratan umum suatu domain aplikasi spesifik, yang secara khas digunakan pada proyek bertingkat pada domain aplikasi itu.

analisis domain


Aktivitas analisis domain:
• Tentukan domain yang akan diteliti :
Untuk melakukannya, analisis harus lebih dulu mengisolasi area bisnis, atau kategori produk dai kependingan.
• Kategorikan item yang akan diekstrak dari domain tsb. :
Item dikumpulkan ke dalam kategori, dan pendefinisian umum dari karakteristik kategori itu ditentukan.
• Kumpulkan sampel representatif dari aplikasi di dalam domain tsb. :
Untuk melakukannya, analisis harus harus memastikan bahwa aplikasi memiliki item yang cocok dengan kategori yang ditentukan.
• Analisis masing-masing aplikasi pada sampel tsb. :
   Langkah – langkah berikut ini ditemui selama analisis domain :
   - identifikasi objek
   - tunjukkan alasan mengapa objek diidentifikasi
   - tentukan adaptasi bagi objek
   - perkirakan persentasi aplikasi pada domain
   - identifikasi objek menurut namanya
• Kembangkan model analisis untuk objek tsb. :
   Model analisis akan berfungsi sebagai dasar bagi desain dan konstruksi objek domain.

Kamis, 26 April 2012

EXPLORASI KONSEP DAN SPESIFIKASI PERSYARATAN

Tahap Eksplorasi Konsep

Langkah awal dalam ekplorasi konsep harus meliputi sebagai berikut :
 Masalah yang dipecahkan dengan sistem baru harus dinyatakan secara tepat
 Sistem yang dipakai harus diteliti dan dinyatakan dengan jelas, misalnya mungkin ada batasan-batasan pada sumber perhitungan.
 Tujuan sistem dan proyek harus ditentukan.  Tujuan proyek sistem meliputi suatu keuntungan yang diinginkan pada organisasi, seperti meningkatkan produktivitas, atau pengalaman pengembangan sistem.
 Feature-featur dan fungsi-fungsi dari sistem baru harus diset pada tingkat tinggi dari biasanya.

Beberapa pertimbangan yang harus diperhatikan dalam menentukan apakah suatu sistem harus dibuat, antara lain :
 Apakah masalah yang dipecahkan dengan sistem baru tersebut penting.
 Apakah masalah yang dipecahkan dengan software sering dipakai ?
 Apakah populasi pemakai yang potensial terhadap sistem baru cukup besar?
 Apakah sistem yang otomatis tersebut dapat menyediakan bentuk pemecahan masalah yang lebih baik?

Dokumen Dalam Eksplorasi Konsep

Merupakan dokumen yang menyimpan penemuan-penemuan dalam eksplorasi konsep.
Dokumen ini menyajikan bahan masukan dalam tahap spesifikasi persyaratan dan suatu perputaran kehidupan.

Tahap Spesifikasi Persyaratan

Hal penting yang ada dalam penentuan penempatan persyaratan  adalah bahwa persyaratan tersebut menerangkan “apakah” suatu sistem bekerja bukannya “bagaimana” sistem tersebut bekerja.

Dokumentasi Persyaratan

Merupakan dokumen yang berfungsi sebagai persetujuan antara developer dan klien, persyaratan tersebut bagi developer sebagai patokan apa yang akan disampaikan  dan bagi klien adalah apa yang akan diharapkan.
Dokumen ini berisi informasi mengenai :
 Pengenalan produk
 Pengembangan, pengoperasian, dan pemeliharaan lingkungan sistem
 Spesifikasi antar muka pemakai (user interface spesification)
 Persyaratan fungsional dari operasi dan transformasi data
 Persyaratan data base dan antar muka eksternal
 Penanganan kesalahan
 Peningkatan dan perubahan yang dapat diramalkan
 Implementasi rancangan, petunjuk dan panduan pengujian
 Ringkasan dari teknik rekayasa peragkat lunak.

Prototipe Dalam Tahap Pengembangan Sistem

 Prototipe adalah implementasi dari produk software yang secara typical fungsional dibatasi, reliablitas (tingkat kebenaran) rendah, miskin tampilan dan kurang ketegasan. Prototipe sering dikembangkan secara cepat dalam bahasa tingkat tinggi tanpa memperhatikan kebenaran dan ketegasan dsb. 
 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  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 : perancangan dilakukan cepat dan rancangan mewakili semua aspek software yang diketahui, dan rancangan ini menjadi dasar pembuatan prototype.
 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.

Prototipe mempunyai 2 tujuan utama :
1. Untuk membantu pengembangan persyaratan jika tidak dapat ditentukan dengan mudah.
2. Untuk mengesahkan persyaratan, khususnya dengan customer dan user potensial.

Keuntungan dari prototipe :
1. Kesalahpahaman antara system developer dan sistem user dapat diientifikasidan dibetulkan.
2. Prototpe yang sedang bekerja mungkin sangat berguna dalam suatu pembuktian manajemen dimana suatu proyek adalah fisibel (layak) sehingga menjamin kelangsungan dukungan.

Kelemahan prototipe:
1. 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. 
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.

Format Laporan Kebutuhan Perangkat Lunak

1. Pendahuluan
Menjelaskan proyek yang akan dibuat, manfaat yang diberikan dari proyek ini bagi masyarakat luas/tertentu.

2. Rumusan masalah
Apa yang menjadi inti dari masalah yang akan dipecahkan atau apa yang menjadi tantangan bagi proyek ini, misalnya bagaimana aplikasi ini akan menjadi sumber informasi bagi….. dalam hal… dan mampu menjangkau…..

3. Spesifikasi sistem
Uraian kemampuan aplikasi yang akan dibangun secara rinci sehingga bisa menggambarkan nilai tambah dan pentingnya aplikasi yang dibangun.

4. Kebutuhan sistem
Menjelaskan kebutuhan sistem baik software atau hardware yang diperlukan.

5. Jadwal Pembangunan Sistem
Buatlah time table yang mewakili jadwal kerja kelompok dalam menyelesaikan pembangunan aplikasi.

6. Tim Pembangun
Daftar nama anggota tim dan tugas/tanggung jawab masing masing anggota

Rabu, 25 April 2012

Manajemen Proyek Perangkat Lunak


Manajemen Proyek Perangkat Lunak merupakan bagian yang penting dalam pembangunan perangkat lunak.
Sekalipun tidak bersifat teknis seperti pengkodean, hal-hal dalam manajemen proyek perangkat lunak ini mampu menentukan apakah proyek akan berjalan dengan baik sehingga menghasilkan produk yang baik.
Hal-hal yang berkaitan dengan manajemen adalah pengelolaan personel dan koordinasi tim, proses, pengukuran proyek-termasuk menentukan harga dari  perangkat lunak, penjadwalan dan sebagainya.

 Manajemen proyek perangkat lunak mengatur 4 hal penting yaitu :

1. Personel
2. Produk
3. Proses
4. Proyek


1. Personel
Proses pembangunan perangkat lunak melibatkan banyak personel. Personel-personel ini digambarkan seperti pemain, dan dikatagorikan dalam 5 katagori pemain:

 Manajer senior : yang menentukan usaha yang dikerjakan, dan pemegang keputusan dalam proyek.
 Manajer proyek (teknis)– pemimpin tim:  yang membuat rencana, memotivasi, mengatur dan mengendalikan praktisi yang mengerjakan perangkat lunak.
 Praktisi : yang mengerjakan perangkat lunak
 Klien : yang menentukan kebutuhan perangkat lunak dan pihak lain yang berkaitan dengan hasil produk
 Pengguna Perangkat Lunak : yang berinteraksi langsung dengan perangkat lunak yang dibangun.


2. Pemimpin Tim/ Manajer Proyek
Kemampuan yang dibutuhkan dalam kepemimpinan seperti:
 Mampu memotivasi
 Mampu berorganisasi : mengatur proses yang ada atau membuat yang baru dalam rangka mewujudkan ide/konsep menjadi produk
 Mampu mendorong keluarnya ide-ide baru: memberi dorongan, menciptakan situasi yang kondusif untuk lahirnya ide baru
 Mencari penyelesaian masalah (problem solving): mampu menganalisa masalah-masalah teknis ataupun manajemen/organisasi kemudian mendapatkan jalan keluar atau memotivasi anggota untuk mampu menyelesaikan masalah. Akomodatif terhadap perubahan yang mungkin terjadi.

3. Tim Perangkat Lunak (Software Team)
Berikut beberapa pilihan pembagian  tugas/penugasan yang bisa diterapkan untuk tim perangkat lunak yang terdiri dari n personel yang bekerja selama k tahun:
  1. Personel ditugaskan untuk sejumlah m tugas yang berbeda dengan sedikit tugas gabungan ? koordinasi adalah tugas dari manajer yang mungkin saja punya 6 proyek lainnya.
  2. n personel di tugaskan untuk sejumlah m tugas yang berbeda dengan m < n sehingga terbentuk tim informal. Pemimpin tim khusus perlu ada ? koordinasi antar tim adalah tanggung jawab manajer
  3. n personel dibagi menjadi sejumlah t tim. Tiap tim ditugaskan mengerjakan satu atau lebih tugas. Tiap tugas mempunyai struktur yang ditentukan sebelumnya bagi semua tim ? koordinasi dikendalikan oleh tim dan manager.
Sekalipun masing-masing pilihan punya argumentasi sendiri-sendiri, namun dari pengamatan yang dilakukan, pilihan no 3 dianggap lebih produktif.


 Contoh Struktur Organisasi Tim
1. Democratic Decentralized (DD) : 
Tidak ada pemimpin yang permanen, koordinator ditunjuk untuk jangka waktu yang pendek, keputusan diambil berdasarkan konsensus bersama, komunikasi horizontal antar anggota tim (posisi sejajar semua).
Cocok untuk masalah yang sulit/rumit, cocok untuk proyek besar, tim cenderung awet dan bertahan lama, pekerjaan memuaskan, cocok untuk masalah yang modularitasnya rendah, perlu banyak waktu untuk menyelesaikan proyek.

2. Controlled decentralized (CD) :
Pemimpin tim ditentukan, ada wakil pemimpin dan mereka berbagi tugas, penyelesaian masalah adalah tugas tim dan implementasinya dibagi di antara beberapa sub-tim oleh pemimpin, komunikasi horisontal di antara sub-tim dan di antara personel, komunikasi vertikal berdasarkan struktur hirarki ? sentralisasi untuk penyelesaian masalah.
Cocok untuk masalah yang sederhana, cukup cocok untuk proyek besar, masalah dengan modularitas tinggi, menghasilkan sedikit kesalahan.

3. Controlled Centralized (CC):
Penyelesaian masalah dikerjakan oleh pemimpin, pemimpin melakukan koordinasi internal tim, komunikasi lebih banyak vertikal antara pemimpin dan anggota tim.
Cocok untuk masalah yang sederhana, melakukan penyelesaian, masalah lebih cepat, masalah dengan modularitas tinggi, menghasilkan sedikit kesalahan.


 Pengukuran Perangkat Lunak
Metric dalam software engineering didefinisikan oleh IEEE Glossary of SE sebagai 
“a quantitative mesaure of the degree to which a system, component, or process possesses a given attribute”
artinya :
Pengukuran secara kuantitatif pada tingkat sistem, komponen atau proses berdasarkan katagori yang ditetapkan

 Pengukuran Berdasarkan Ukuran
Pengukuran berdasarkan perangkat lunak - perangkat lunak yang sudah diproduksi/dibuat sebelumnya, lengkap dengan karakteristik lain seperti line of code (LOC), harga, waktu yang diperlukan pada tiap fungsi atau proyek yang dibangun, kesalahan (error) yang ditemukan. Dari total LOC, harga dan lama waktu dapat diperoleh misalnya :
 harga per KLOC (seribu baris kode)
 kesalahan per KLOC
Cara ini kurang diterima secara universal karena pengunaan LOC untuk kunci ukuran bergantung pada bahasa pemrograman yang digunakan.

 Pengukuran Berdasarkan Fungsi (Function Point – FP)
Function point ditentukan berdasarkan bagian-bagian software yang bisa  dihitung seperti :
 jumlah input dari pengguna
 jumlah output untuk pengguna
 jumlah user inquiry: inquiry didefinisikan sebagai online input yang menghasilkan respon langsung dari software dalam bentuk online  output
 jumlah file: baik file yang terpisah dari database, atau bagian dari file
 jumlah external interface: misalnya data file pada storage media yang digunakan untuk mengirimkan informasi ke sistem lain.

Ukuran untuk organisasi kecil bisa menggunakan ukuran seperti :
 waktu (hari atau jam) mulai dari permintaan/request samai evaluasi lengkap 
 usaha (personel-waktu) untuk melakukan evaluasi.
 waktu (jam atau hari) dari selesainya evaluasi sampai penugasan lain ke personel.
 usaha (personel – jam) yang dibutuhkan untuk membuat perubahan 
 waktu (jam atau hari ) untuk melakukan perubahan, 
 kesalahan yang terjadi selama pengerjaan untuk melakukan perubahan. 
 cacat yang terjadi setelah perubahan diserahkan ke klien.

Selasa, 24 April 2012

Dasar - Dasar Rekayasa Perangkat Lunak

1. Pemahaman Dasar Rekayasa Perangkat Lunak

a. Pengertian Perangkat Lunak

Program komputer dan dokumentasi yang berkaitan seperti dokumen kebutuhan, rancangan, dan user manual.
Produk perangkat lunak bisa dibangun untuk pengguna khusus atau umum:
* Generic – dibangun untuk dijual ke pengguna yang berbeda-beda misalnya perangkat lunak untuk PC seperti Excel atau Word.
* Bespoke (custom) – untuk pengguna khusus/pemesan sesuai kebutuhannya.
Perangkat lunak baru bisa dibuat dengan membangun program baru, konfigurasi sistem perangkat lunak atau gunakan lagi (reuse) program yang sudah ada.

b. Pengertian Rekayasa Perangkat Lunak
Disiplin ilmu rekayasa atau teknik yang berkaitan dengan semua aspek dalam membuat perangkat lunak.
Rekayasa perangkat lunak harus mengikuti pendekatan yang sistematis dan teratur dan menggunakan alat dan teknik yang cocok sesuai dengan masalah yang akan dipecahkan, batasan pembangunan dan sumber yang tersedia.

c. Perbedaan Rekayasa Perangkat Lunak dan Ilmu Komputer
Ilmu komputer berkaitan dengan teori dan konsep-konsep dasar sedangkan Rekayasa Perangkat Lunak berkaitan dengan praktek pembangunan perangkat lunak.
Teori ilmu komputer lebih kurang sebagai penyangga rekayasa perangkat lunak.

d. Perbedaan Rekayasa Perangkat Lunak dan Rekayasa Sistem
Rekayasa sistem berkaitan dengan semua aspek dalam pembangunan sistem berbasis komputer termasuk hardware, rekayasa perangkat lunak dan proses, sedangkan Rekayasa Perangkat Lunak adalah bagian dari rekayasa sistem yang meliputi pembangunan perangkat lunak, infrasktruktur , kontrol, aplikasi dan database pada sistem.
Para ahli sistem (system engineers) terlibat dalam spesifikasi sistem, desain  arsitektural, integrasi dan peluncurannya.

f. Pengertian Software Process
* Serangkaian aktifitas yang tujuannya adalah pembangunan atau evolusi perangkat lunak
* Aktifitas umum dalam semua proses perangkat lunak :
* Spesifikasi – apa yang dilakukan sistem dan batas pembangunan
* Pembangunan- produksi dari sistem perangkat lunak
* Validasi – pemeriksaan apakah perangkat lunak sesuai dengan permintaan pemesan
* Evolusi – mengubah perangkat lunak untuk menyesuaikan perubahan permintaan.

2. Tahap-Tahap Dalam Pembuatan Perangkat Lunak

* Fase Analisa kelayakan dan eksplorasi konsep.  Mengidentifikasi kebutuhan untuk melakukan otomatisasi proses dan menganalisa kelayakan proyek.
* Fase spesifikasi persyaratan.  Menganalisa dan mendokumentasikan persyaratan sistem.  Dokumentasi persyaratan secara jelas harus menyebutkan apa yang akan dilakukan oleh sistem yang diproyeksikan, unsur apa yang akan diperlukan oleh produk perangkat lunak serta karakteristik apa yang harus dimiliki oleh unsur produk
* Fase desain.  Mendesain sistem dan mendokumentasikan sistem.  Dokumen desain menentukan cara pembuatan sistem software untuk memenuhi persyaratan tersebut.
* Fase implementasi.  Menulis perangkat lunak.
* Fase pengujian.  Mencoba perangkat lunak untuk mengetahui apakah telah memenuhi persyaratannya.
* Fase perawatan.  Mengikuti penempatan produk perangkat lunak, membetulkan kesalahan, mengubah dan memperluas sistem.

3. Atribut kualitas Perangkat Lunak

* Benar.  Dokumentasi dikatakan benar bila secara tepat dan akurat dapat menjelaskan fungsi dan kelayakan program . Perangkat lunak dikatakan benar jika telah memenuhi persyaratan input dan outputnya.
* Efisien.  Perangkat lunak yang menunjukkan cara pemakaian sumber komputasi secara baik.
* Perawatan.  Menunjukkan betapa mudahnya dalam mekukan  perbaikan, perubahan dan perluasan.
* Portable.  Atribut ini menunjukkan bahwa perangkat lunak dapat dipindah tergantung jenis lingkungannya.
* Readable.  Atribut ini menunjukkan bahwa perangkat lunak mudah untuk dipahami produk kerjanya.
* Reliable (dapat dipercaya)
* Kuat
* Reusable (dapat dipakai berulang-ulang)
* Testable (Dapat diuji)
* Well documented (memiliki dokumentasi yang baik)