Selasa 17 Maret 2009
Proses pembuatan SRS dilakukan di level business analyst dan juga sistem analyst di bawah project manager.
SRS selesai, maka akan dibawa ke bagian Architecture yang akan menyusun solusi sesuai dengan requirement yang telah dijelaskan di SRS.
Lanjutan pembuatan SRS ini berupa SAD (Software Architecture Document) yang dibuat oleh Arsitek dengan detail teknikal untuk supplementari bagi FDD.
Di dalam SAD, use case yang dicantumkan yang memiliki prioritas utama.
Berdasarkan referensi http://restama.com/wordpress/wordpress/wp-content/uploads/2009/01/software-documentation.rtf, menyebutkan bahwa SAD berisi tentang :
- Deskripsi tentang arsitektur sistem (decompotition modul)
- Deskripsi tentang arsitektur setiap program di dalam sistem (logical model)
- Deskripsi tentang pemilihan teknologi
RUP (Rational Unified Process) -> breakdown ke logical view (business), logical view (use case), dan physical view (ke arah coding).
RUP menggunakan konsep object oriented, dengan aktifitas yang berfokus pada pengembangan model dengan menggunakan Unified Model Language (UML).
Rational Unified Process (RUP) merupakan suatu metode rekayasa perangkat lunak yang dikembangkan dengan mengumpulkan berbagai best practises yang terdapat dalam industri pengembangan perangkat lunak. Ciri utama metode ini adalah menggunakan use-case driven dan pendekatan iteratif untuk siklus pengembangan perankat lunak.
Metode RUP merupakan metode pengembangan kegiatan yang berorientasi pada proses. Dalam metode ini, terdapat empat tahap pengembangan perangkat lunak yaitu:
- Inception
Pada tahap ini pengembang mendefinisikan batasan kegiatan, melakukan analisis kebutuhan user, dan melakukan perancangan awal perangkat lunak(perancangan arsitektural dan use case).
- Elaboration
Pada tahap ini dilakukan perancangan perangkat lunak mulai dari menspesifikasikan fitur perangkat lunak hingga perilisan prototipe dari perangkat lunak.
- Construction
Pengimplementasian rancangan perangkat lunak yang telah dibuat dilakukan pada tahap ini. Pada akhir tahap ini, perangkat lunak versi akhir yang sudah disetujui administrator dirilis beserta dokumentasi perangkat lunak.
- Transition
Instalasi , deployment dan sosialisasi perangkat lunak dilakukan pada tahap ini.
http://sms.unikom.ac.id/taryana/download/metode_rup.doc
RUP ini menggunakan Rational Rose, yaitu sebuah tool untuk software design.
Dalam Wikipedia disebutkan bahwa cara kerja RUP itu didasarkan pada 6 kunci prinsip
bagi perkembangan bisnis yang terkendali yaitu :
1. Mengadaptasi proses
2. Menyeimbangkan prioritas dari para stakeholders
3. Melakukan kolaborasi antar tim
4. Mendemonstrasikan hasil-hasil yang ada secara berulang-ulang
5. Menaikkan level abtraksi dari sebuah software
6. Memfokuskan pada kualitas secara terus-menerus
Keuntungan penggunaan RUP adalah :
1. Menyediakan akses yang mudah terhadap pengetahuan dasar bagi anggota tim.
2. Menyediakan petunjuk bagaimana menggunakan UML secara efektif.
3. Mendukung proses pengulangan dalam pengembangan software.
4. Memungkinkan adanya penambahan-penambahan pada proses.
5. Memungkinkan untuk secara sistematis mengontrol perubahan-perubahan yang terjadi pada software selama proses pengembangannya.
6. Memungkinkan untuk menjalankan test case dengan menggunakan Rational Test Manager Tool
http://ang-dee.blog.friendster.com/2007/11/rup-rational-unified-process/
Rational Rose adalah tools yang memudahkan kita merancang dan menganalisis sistem dengan pendekatan yang berorientasi objek(object-oriented design and programming). Dimulai dari analisis domain masalah, business requirements, data model, function model, generate database & application code, sampai dengan menuliskan dokumentasi sistem; semuanya dilakukan secara otomatis oleh tools ini.
Setelah pembuatan sequence diagram, maka dibuat class diagram.
Wednesday, March 18, 2009
Wednesday, March 4, 2009
Model Incremental : Hmmmm.....
Pada pertemuan kuliah Software Engineering kali ini, dosen saya mendatangkan pihak ICT kampus untuk bercerita tentang pembuatan CIS kampus.
Beliau bercerita tentang process model yang dipakai selama pembuatan CIS tersebut, dengan menggunakan model incremental.
Selasa, 3 Maret 2009
Process model yang digunakan adalah model incremental.
analysis --> design --> code --> test (Delivery of 1st incremental)
analysis --> design --> code --> test (Delivery of 2nd incremental)
analysis --> design --> code --> test (Delivery of 3rd incremental)
Sebelum dipecah - pecah kedalam delivery tersebut, lebih baik ada gambaran besar dulu apa yang diinginkan atau yang dibutuhkan di dalam aplikasi tesebut secara general.
Biasanya untuk 1 kali incremental, harus menunggu sampai test dulu baru lanjut ke incremental selanjutnya.
Tetapi karena masalah SDM dan waktu, bisa saja setelah analysis dan design, langsung lanjut ke analysis level 2.
Di dalam incremental, kita memilah - milah cakupannya menjadi modul - modul yang lebih kecil. Misalnya bagian home --> modul sendiri, bagian update & delete --> modul sendiri, dst. Intinya harus sama, jangan sampai berubah dalam hal struktur data. Kalau sampai mengubah, maka mulai dari awal lagi. Dan itu harus dipertanyakan ketika analysis dan design. Oleh karena itu, biasanya analysis dan design membutuhkan waktu lebih lama. Untuk menambah atau mengurangi, tidak apa-apa.
Dalam requirement gathering, yang merupakan poin penting adalah prosesnya seperti apa. Dan sesuai dengan disiplin ilmu kita yaitu IT, sedikit banyak kita mengetahui prosesnya.
Dan di dalam dokumen SRS berisi tentang apa yang customer butuhkan dan functionality apa yang bisa kita provide.
=================================================================================================
Untuk membuat incremental, harus dibuat dulu framework nya. Contoh: database nya menggunakan apa, JSP nya bagaimana.
Tiap incremental harus ada core product atau base productnya.
Proses yang ada di incremental itu berupa analysis --> test.
Jika di generic process framework, dari communication --> deployment.
Contoh: di delivery of 1st incremental, membuat login page dari analysis sampai test. Setelah berhasil di TAG dulu yang kemudian menjadi base product dan statusnya menjadi login page v1.0. Apabila ada perubahan, maka statusnya menjadi login page v1.1, dst.
Incremental termasuk di dalam RAD (Rapid Application Development) yang semua prosesnya berdasarkan waktu.
Berdasarkan buku yang saya baca yang berjudul Software Process (oleh Umi Proboyekti, S.Komp, MLIS), RAD menekankan pada siklus pembangunan yang pendek/singkat. RAD mengadopsi model waterfall dan pembangunan dalam waktu singkat dicapai dengan menerapkan component based construction. Waktu yang singkat adalah batasan yang penting untuk model ini.
Dan berdasarkan http://ega.staff.gunadarma.ac.id/Downloads/files/3254/PERANCANGAN_BAB+6.doc (oleh Ida Ayu Yulie Primashanti), Model incremental (Incremental waterfall model) merupakan perbaikan dari model waterfall dan sebagai standar pendekatan top-down. Ide dasar dari model ini adalah membangun software secara meningkat (increment) berdasarkan kemampuan fungsional. Model incremental ini diaplikasikan pada sistem pakar dengan penambahan rules yang mengakibatkan bertambahnya kemampuan fungsional sistem. Keuntungan dari model ini adalah bahwa penambahan kemampuan fungsional akan lebih mudah diuji, diverifikasi, dan divalidasi dan dapat menurunkan biaya yang dikeluarkan untuk memperbaiki sistem. Model incremental merupakan model continous rapid prototype dengan durasi yang diperpanjang hingga akhir proses pengembangan. Pada model prototipe biasa, prototipe hanya dibuat pada tahap awal untuk mendapatkan kebutuhan user.
CR management --> untuk menentukan berapa main desk.
Contoh: coding selama 4 bulan --> 4 x 20 hari kerja = 80 hari kerja.
80 hari kerja ini dilakukan oleh 2 orang, maka ada 80 x 2 = 160 main desk.
Jadi, dibutuhkan 160 orang per hari untuk menyelesaikan coding tersebut.
Bagaimana designer's product dapat dibaca oleh programmer?
Menggunakan RUP (Rational Unified Process) yang biasanya berupa UML. Hasilnya bisa berupa use case sampai sequence diagram.
Berdasarkan www.whatis.com, RUP membentuk empat tahap pembangunan, masing-masing yang diatur dalam sejumlah terpisah Iterasi yang harus memenuhi kriteria yang ditetapkan sebelum tahap berikutnya dilakukan: dalam tahap permulaan, developer menetapkan lingkup dari proyek dan bisnis kasus; di tahap elaborasi, developer proyek menganalisa kebutuhan secara lebih detail dan menetapkan nya arsitektur dasar; dalam tahap konstruksi, developer membuat aplikasi desain dan source code, dan dalam tahap transisi, developer deliver system ke penggunanya.
Dokumen SRS :
- data dictionary bisa dimasukkan, seperti database design.
Data dictionary menurut wikipedia, merupakan sekumpulan informasi tentang data seperti relationship dengan data lainnya, penggunaannya, original, dan formatnya. Dan istilah ini menyangkut dengan database dan sistem manajemen database (DBMS). Merupakan dokumen yang menjelaskan database, komponen dari DBMS yang diperlukan untuk menentukan struktur.
- content : semua yang berhubungan dengan requirement dan spesification
- template: free format tetapi mencakup semua content nya.
- tujuan : mengkonsolidasi requirement user ke vendor.
- bisa dimasukkan untuk capacity planning, merupakan proses penentuan kapasitas produksi yang dibutuhkan oleh sebuah organisasi untuk memenuhi permintaan untuk produknya. Tujuan adanya capacity planning adalah meminimalkan ketidakcocokan antara kapasitas developer dan kebutuhan user. Proses penentuan kapasitas in bervariasi bergantung pada perubahan yang ada dalam hasil produksi, apakah mengalami peningkatan atau penurunan dalam jumlah produksi atau membuat produk baru.
Beliau bercerita tentang process model yang dipakai selama pembuatan CIS tersebut, dengan menggunakan model incremental.
Selasa, 3 Maret 2009
Process model yang digunakan adalah model incremental.
analysis --> design --> code --> test (Delivery of 1st incremental)
analysis --> design --> code --> test (Delivery of 2nd incremental)
analysis --> design --> code --> test (Delivery of 3rd incremental)
Sebelum dipecah - pecah kedalam delivery tersebut, lebih baik ada gambaran besar dulu apa yang diinginkan atau yang dibutuhkan di dalam aplikasi tesebut secara general.
Biasanya untuk 1 kali incremental, harus menunggu sampai test dulu baru lanjut ke incremental selanjutnya.
Tetapi karena masalah SDM dan waktu, bisa saja setelah analysis dan design, langsung lanjut ke analysis level 2.
Di dalam incremental, kita memilah - milah cakupannya menjadi modul - modul yang lebih kecil. Misalnya bagian home --> modul sendiri, bagian update & delete --> modul sendiri, dst. Intinya harus sama, jangan sampai berubah dalam hal struktur data. Kalau sampai mengubah, maka mulai dari awal lagi. Dan itu harus dipertanyakan ketika analysis dan design. Oleh karena itu, biasanya analysis dan design membutuhkan waktu lebih lama. Untuk menambah atau mengurangi, tidak apa-apa.
Dalam requirement gathering, yang merupakan poin penting adalah prosesnya seperti apa. Dan sesuai dengan disiplin ilmu kita yaitu IT, sedikit banyak kita mengetahui prosesnya.
Dan di dalam dokumen SRS berisi tentang apa yang customer butuhkan dan functionality apa yang bisa kita provide.
=================================================================================================
Untuk membuat incremental, harus dibuat dulu framework nya. Contoh: database nya menggunakan apa, JSP nya bagaimana.
Tiap incremental harus ada core product atau base productnya.
Proses yang ada di incremental itu berupa analysis --> test.
Jika di generic process framework, dari communication --> deployment.
Contoh: di delivery of 1st incremental, membuat login page dari analysis sampai test. Setelah berhasil di TAG dulu yang kemudian menjadi base product dan statusnya menjadi login page v1.0. Apabila ada perubahan, maka statusnya menjadi login page v1.1, dst.
Incremental termasuk di dalam RAD (Rapid Application Development) yang semua prosesnya berdasarkan waktu.
Berdasarkan buku yang saya baca yang berjudul Software Process (oleh Umi Proboyekti, S.Komp, MLIS), RAD menekankan pada siklus pembangunan yang pendek/singkat. RAD mengadopsi model waterfall dan pembangunan dalam waktu singkat dicapai dengan menerapkan component based construction. Waktu yang singkat adalah batasan yang penting untuk model ini.
Dan berdasarkan http://ega.staff.gunadarma.ac.id/Downloads/files/3254/PERANCANGAN_BAB+6.doc (oleh Ida Ayu Yulie Primashanti), Model incremental (Incremental waterfall model) merupakan perbaikan dari model waterfall dan sebagai standar pendekatan top-down. Ide dasar dari model ini adalah membangun software secara meningkat (increment) berdasarkan kemampuan fungsional. Model incremental ini diaplikasikan pada sistem pakar dengan penambahan rules yang mengakibatkan bertambahnya kemampuan fungsional sistem. Keuntungan dari model ini adalah bahwa penambahan kemampuan fungsional akan lebih mudah diuji, diverifikasi, dan divalidasi dan dapat menurunkan biaya yang dikeluarkan untuk memperbaiki sistem. Model incremental merupakan model continous rapid prototype dengan durasi yang diperpanjang hingga akhir proses pengembangan. Pada model prototipe biasa, prototipe hanya dibuat pada tahap awal untuk mendapatkan kebutuhan user.
CR management --> untuk menentukan berapa main desk.
Contoh: coding selama 4 bulan --> 4 x 20 hari kerja = 80 hari kerja.
80 hari kerja ini dilakukan oleh 2 orang, maka ada 80 x 2 = 160 main desk.
Jadi, dibutuhkan 160 orang per hari untuk menyelesaikan coding tersebut.
Bagaimana designer's product dapat dibaca oleh programmer?
Menggunakan RUP (Rational Unified Process) yang biasanya berupa UML. Hasilnya bisa berupa use case sampai sequence diagram.
Berdasarkan www.whatis.com, RUP membentuk empat tahap pembangunan, masing-masing yang diatur dalam sejumlah terpisah Iterasi yang harus memenuhi kriteria yang ditetapkan sebelum tahap berikutnya dilakukan: dalam tahap permulaan, developer menetapkan lingkup dari proyek dan bisnis kasus; di tahap elaborasi, developer proyek menganalisa kebutuhan secara lebih detail dan menetapkan nya arsitektur dasar; dalam tahap konstruksi, developer membuat aplikasi desain dan source code, dan dalam tahap transisi, developer deliver system ke penggunanya.
Dokumen SRS :
- data dictionary bisa dimasukkan, seperti database design.
Data dictionary menurut wikipedia, merupakan sekumpulan informasi tentang data seperti relationship dengan data lainnya, penggunaannya, original, dan formatnya. Dan istilah ini menyangkut dengan database dan sistem manajemen database (DBMS). Merupakan dokumen yang menjelaskan database, komponen dari DBMS yang diperlukan untuk menentukan struktur.
- content : semua yang berhubungan dengan requirement dan spesification
- template: free format tetapi mencakup semua content nya.
- tujuan : mengkonsolidasi requirement user ke vendor.
- bisa dimasukkan untuk capacity planning, merupakan proses penentuan kapasitas produksi yang dibutuhkan oleh sebuah organisasi untuk memenuhi permintaan untuk produknya. Tujuan adanya capacity planning adalah meminimalkan ketidakcocokan antara kapasitas developer dan kebutuhan user. Proses penentuan kapasitas in bervariasi bergantung pada perubahan yang ada dalam hasil produksi, apakah mengalami peningkatan atau penurunan dalam jumlah produksi atau membuat produk baru.
Subscribe to:
Posts (Atom)