Teknik Dokumentasi Aplikasi Part II

::: Resume Teknik Dokumentasi Aplikasi :::

Pertemuan            : 3

Part                         : 2

Mata Kuliah         : Teknik Dokumentasi Aplikasi

Dosen                     : Ayuningtyas, S.Kom.,M.MT.,-MOS

PROSES PENGEMBANGAN PERANGKAT LUNAK

:  ^ :   Agile Process Model   :  ^ :

^.^ Adalah suatu chaordic, yaitu suatu proses berdasarkan praktek untuk memodelkan dan mendokumentasikan suatu sistem yang berbasiskan software secara efektif.

^.^ Agile Modeling juga dikatakan sebagai suatu kumpulan dari kebiasaan-kebiasaan berdasarkan beberapa nilai dan prinsip-prinsip teknik software yang terpercaya.

^.^ Agile Modeling merupakan sebuah pendekatan light-weight yang mempertinggi usaha pemodelan dan pendokumentasian untuk  proses software lainnya seperti XP dan RUP.

^.^ Agile model lebih efektif daripada model tradisional yang tidak cukup bagus dan tidak sempurna. Kita bisa memakai pendekatan Agile modeling pada requirements, analysis, architecture, dan design.

^.^ Agile modeling bukan suatu proses yang bersifat menentukan, dengan kata lain tidak mendefinisikan prosedur secara detil untuk bagaimana membuat suatu tipe model yang telah diberikan, meskipun terdapat cara bagaimana untuk menjadi suatu modeler yang efektif.

Pendekatan Agile fokus pada :

1.       Individual dan interaction dari pada proses proses dan tools

2.       Kinerja software daripada dokumentasi yang lengkap

3.       Kolaborasi customer daripada negosiasi kontrak

4.       Reaksi untuk mengubah daripada mengikuti suatu rencana 

Tujuan dari Agile Modeling sendiri antara lain adalah :

1.      Untuk mendefinisikan dan menunjukkan bagaimana mempraktekkan, sekumpulan nilai, prinsip prinsip dan praktek yang lebih efektif, suatu modeling yang ringan.

Rahasia dari Agile Modeling bukan teknik modelingnya sendiri, seperti use case model, class model, data model, or user interface model  tetapi bagaimana mereka diaplikasikan.

2.     Selain itu adalah untuk menempatkan persoalan bagaimana cara untuk mengaplikasikan teknik modeling pada suatu proyek software yang menggunakan pendekatan agile seperti eXtreme Programming (XP), Dynamic Systems Development Method (DSDM), atau SCRUM. Mengambil komentar Kent Beck dari eXtreme Programming Explained (XPE) "kita akan terus menerus memperbaiki design dari sistem, mulai dari suatu awal yang sederhana. Kita akan menghapus fleksibilitas yang tidak terbukti berguna”.

Berkebalikan dengan klaim dari beberapa kritikus eXtreme Programming bahwa akan memakan banyak waktu untuk memodelkan pada kenyataanya ketika menggunakan suatu pendekatan eXtreme Programming, tetapi jika kita tidak mempunyai pilihan lain.

Terkadang lebih produktif bagi developer untuk menggambar bubble dan garis daripada memikirkan suatu ide, atau untuk membandingkan beberapa pendekatan yang berbeda untuk mengatasi permasalahan, daripada memulai membajak kode yang sederhana.

3.    Untuk menempatkan permasalaha bagaimana memodelkan sesuatu dengan lebih efektif pada suatu proyek Unified Process (UP), instansiasi yang biasa yang meliputi Rational Unified Process (RUP) dan Enterprise Unified Process (EUP).

EUP meliputi beberapa workflow yang berorientasi modeling pada requirement, Business Modeling, Analysis & Design, Infrastructure Management dimana ketika mengaplikasikan pada suatu nilai akan lebih memberatkan.

Agile Modeling membantu untuk meningkatkan keefektifan dari usaha memodelkan pada suatu proyek Unified Process atau beberapa proyek lain yang terjadi.

::~ R u a n g   L i n g k u p ~::

Ruang lingkup Agile Modeling. 
-   Konsep yang penting untuk dimengerti dari suatu Agile Modeling adalah bahwa ini bukanlah proses software yang lengkap.

-    Agile Modeling berkonsentrasi pada modeling dan dokumentasi yang efektif.

Tidak meliputi aktifitas pemrograman, meskipun mengatakan untuk membuktikan model kita dengan suatu code (coding).

Tidak meliputi aktifitas testing juga, meskipun mengatakan untuk mempertimbangkan model yang bisa lolos testing.

Tidak mencakup manajemen proyek, system deployment, system operasi, system support, dan sebagainya.

Karena Agile Modeling fokus pada suatu porsi dari semua proses software yang harus memakai yang lain, proses full-fledged seperti eXtreme Programming (XP), Dynamic Systems Development Method (DSDM), SCRUM atau Unified Process (UP) seperti yang telah disebutkan pada tujuan dari Agile Modeling.

Nilai dari Agile Modeling meliputi nilai dari eXtreme Programming communication, simplicity, feedback dan courage, dilengkapi dengan nilai kelima yaitu humility:

1.       Communication.

Model meningkatkan komunikasi antara tim kita dengan stakeholder proyek kita sebaik antara developer dan tim kita.

2.       Simplicity

Penting bahwa developer mengerti bahwa model mudah untuk disederhanakan baik software dan proses software, lebih mudah untuk mengeksplorasi ide, dan meningkatkannya sesuai dengan peningkatan pemahaman, dengan menggambar diagram atau menulis puluhan bahkan ribuan baris kode.

3.       Feedback

Kent Beck mengatakan bahwa yang terbaik pada Extreme Programming Explained:“optimis adalah suatu resiko dalam pekerjaan pemrograman,dan feedback adalah pengobatannya.” Dengan mengkomunikasikan ide kita melalui deigram, kita akan cepat mendapatkan feedback, sehingga kita bisa melakukan sesuai nasehat itu.

4.       Courage

Courage penting karena kita harus membuat keputusan yang penting dan bisa untukn merubah perintah dengan pembuangan atau pembuatan kembali pekerjaan  kita ketika beberapa dari keputusan kita terbukti tidak mencukupi.

5.       Humility

Developer yang terbaik mempunyai kerendahan hati untuk mengenali bahwa mereka tidak tahu semuanya, bahwa developer bawahan mereka, customer, dan pada kenyataannya semua stakeholder proyek juga mempunyai daerah kemampuan masing masing dan mempunyai nilai untuk menambahkan sesuatu pada proyeknya. Suatu pendekatan yang efektif adalah untuk mengasumsikan bahwa semua orang terlibat dengan proyek kita mempunyai nilai sama dan harus dihormati.

Kesimpulannya, kunci untuk modeling yang sukses adalah dengan mempunyai komunikasi yang efektif antara semua yang terlibat dalam proyek.

Untuk mengembangkan solusi yang paling sederhana yang mungkin sesuai dengan semua kebutuhan kita, untuk mendapatkan feedback sesuai dengan yang kita kerjakan dengan cepat dan sesering mungkin.

Untuk mendapatkan keberanian untuk membuat dan membuang keputusan, dan mempunyai kerendahan hati untuk mengatakan bahwa kita mungkin tidak mengetahui segalanya dan bahwa semua mempunyai nilai untuk berperan dalam proyek kita.

Prinsip prinsip Agile Modeling

Agile Modeling mendefinisikan sekumpulan prinsip prinsip yang utama dan pendukung yang jika diaplikasikan dalam proyek software development membangun tingkatan untuk kumpulan praktek pemodelan.

Prinsip prinsip utama

1.       A s s u m e     S i m p l i c i t y

Selama kita membangun kita harus mengasumsikan bahwa solusi yang sederhana adalah solusi yang terbaik.

Jangan membuat software sampai overbuild, atau pada kasusnya AM tidak menggambarkan fitur fitur tambahanpada model kita yang tidak kita butuhkan sekarang.

Mempunyai keberanian bahwa kita tidak membutuhkan untuk terlalu memodelkan system secara berlebihan sekarang, kita dapat memodelkan berdasarkan requirement yang ada sekarang dan membangun kembali system di masa depan jika requirementnya bertambah. Pertahankan model kita sesederhana mungkin.

2.       E m b r a c e     C h a n g e

Requirement meningkat sewaktu waktu.

Stakeholder proyek dapat merubah proyek kedepannya, orang baru menambah dan yang sudah ada bias ditinggalkan.

“Stakeholder proyek dapat merubah sudut pandang, merubah tujuan dan menambahkan criteria pada peran kita.”

Maksudnya adalah bahwa project environment kita berubah sesuai dengan efforts progress, dan bahwa sebagai hasilnya pendekatan kita pada pengembangan ini harus merefleksikan realita ini.

3.        E n a b l i n g     T h e    N e x t    E f f o r t    I s    Y o u r     S e c o n d a r y    G o a l

-          Proyek kita masih dapat mengalami kegagalan meskipun tim kita memberikan suatu working system pada user kita, bagian dari melengkapi kebutuhan dari stakeholder proyek adalah untuk memastikan bahwa sistem kita cukup kuat jadi bisa ditambahkan sewktu waktu.

-          Usaha kita selanjutnya mungkin menjadi pengembangan dari dikeluarkannya rilis selanjutnya dari sistem kita atau bisa juga menyederhanakan operasi dan mendukung versi yang telah ada yang kita bangun.

-          Untuk memfungsikannya kita tidak hanya ingin membangun kualitas software tapi juga membuat dokumentasi yang cukup dan materi pendukung sehingga orang selanjutnya yang mengerjakan bisa lebih efektif.

Kesimpulannya, ketika kita bekerja pada sistem, kita harus memperhatikan masa depan pembuatan sistem ini.

4.       I n c r e m e n t a l     C h a n g e

-          Suatu konsep yang penting untuk mengerti suatu pemodelan adalah bahwa kita tidak harus membuat benar pada pertama kalinya, kenyataanya tidak seperti yang diinginkan meskipun kita sudah berusaha.

-          Terlebih lagi kita tidak harus merekam setiap detil pada model kita, kita hanya harus mengusahakan yang terbaik pada waktunya

Karena kita bisa melakukan perubahan secara bertahap jika dibutuhkan.

5.       M a x i m i z e     S t a k e h o l d e r      I n v e s t m e n t

-          Stakeholder proyek kita menanamkan resource resource seperti waktu, uang, fasilitas dan sebagainya untuk mendapatkan software yang dikembangkan sesuai dengan keinginannya.

-          Karenanya kita harus bisa memanfaatkan resource tersebut secara maksimal untuk kepuasan semua pihak.

6.       M o d e l     W i t h     A     P u r p o s e

Beberapa pengembang khawatir mengenai artifact mereka seperti model, source code, atau dokumen apakah cukup detil atau terlalu detil, ataukah akurat atau tidak.

Kemudian yang dilakukan adalah kembali kebelakang mempertanyakan mengapa membuat artifact ini dan untuk siapa dibuat.

Karenanya untuk menghindari terjadinya hal tersebut maka kita harus terlebih dulu menentukan tujuan pembuatan dan sasaran dibuatnya model tersebut.

7.       M u l t i p l e     M o d e l s

Kita mungkin saja butuh menggunakan model yang beragam untuk membangun software karena tiap model menggambarkan suatu aspek tunggal dari software.

Dengan mempertimbangkan kompleksitas software sekarang ini maka kita harus mengetahui cakupan yang luas dari teknik pada peralatan intelektual modeling kita sehingga lebih efektif.

Kita tidak harus membangun semua model yang diberikan tetapi harus dilihat cara yang paling efektif meskipun menggunakan beragam model.

8.       Q u a l i t y    W o r k

Tak ada orang yang menyukai pekerjaan yang sembarangan.

Seseorang akan menyukai pekerjaan jika itu bisa dibanggakan dan ada hasil yang akan dicapai, tidak lemah dan sesuai dengan yang diinginkan.

9.       R a p i d     F e e d b a c k

Waktu antara aksi dan umpan balik dari aksi adalah penting.

Bekerja dekat dengan customer, untuk mengetahui requirement, menganalisa atau membangun suatu user interface yang sesuai keinginan akan membuat umpan balik yang lebih cepat.

10.    S o f t w a r e    Is    Y o u r     P r i m a r y     G o a l

Tujuan dari pengembangan software adalah untuk menghasilkan software yang sesuai dengan keinginan dari stakeholder proyek dengan cara yang efektif, bukan dengan dokumentasi atau model model yang berlebihan.

11.    T r a v e l     L i g h t

Setiap artifak yang dibuat, dan diputuskan untuk dipertahankan, akan membutuhkan untuk di maintain sewaktu waktu.

Kompleksitas dan detil yang kita buat diawal akan memberatkan sehingga jika kita membuat model awal harus yang mudah dimengerti dan efektif sehingga akan meringankan perjalanan menuju akhir pembuatan software.

Prinsip - Prinsip Pendukung

1.       C o n t e n t    Is    M o r e    I m p o r t a n t    T h a n    R e p r e s e n t a t i o n

Model yang diberikan mempunyai banyak cara merepresentasikannya. Tetapi isi dari model dan software yang dikerjakan lebih penting daripada representasinya.

2.       E v e r y o n e     C a n     L e a r n     F r o m     E v e r y o n e     E l s e

Kita tidak bisa benar benar mencontoh sesuatu, tetapi kita bisa belajar dari orang lain termasuk teknik melaui berbagai cara misalnya training, education, mentoring, reading dan lain lain.

3.       K n o w    Y o u r     M o d e l s

Karena kita mempunyai multiple model yang harus diaplikasikan maka kita harus tahu kekuatan dan kelemahan untuk penggunaan yang efektif.

4.       K n o w     Y o u r     T o o l s

Kita harus memahami peralatan, software, modeling tools, diagramming tools untuk menggunakannya dengan baik.

5.       L o c a l    A d a p t a t i o n

Pendekatan pada software development harus merefleksikan lingkungan kita, termasuk organisasi kita, keadaan stakeholder proyek dan lingkungan proyek itu sendiri.

6.       O p e n    A n d     H o n e s t     C o m m u n i c a t i o n

Kita harus terbuka dan berkomunikasi dengan jujur pada pengembang dan stakeholder proyek, pengguna dan semua yang terlibat pada pembuatan proyek.

7.       W o r k    W i t h     P e o p l e ' s     I n s t i n c t s

Bekerja pada bidang ini bukan berarti tidak mempertimbangkan perasaan dan insting.

Kita juga harus bekerja dengan insting manusia.

Praktek  Agile Modeling

Kebiasaan kebiasaan Agile Modeling juga mempunyai praktek utama dan praktek pendukung.

Praktek utama

1.       Partisipasi Aktif Stakeholder

2.       Menggunakan Barang-Barang yang Tepat

3.       Collective Ownership

4.       Mempertimbangkan Kemampuan Tes

5.       Membuat Beberapa Model Secara Paralel

6.       Membuat Kandungan Sederhana

7.       Menggambarkan Kesederhanaan Model

8.       Memperlihatkan Model di Depan Umum

9.       Mengiterasi Artefak lainnya

10.    Model in Small Increments

11.    Modelkanlah Dengan Yang Lainnya

12.    Percayakan Dengan Kode

13.    Gunakan Alat Paling Sederhana

Praktek Pendukung

1.         Gunakan Permodelan Standar

2.         Gunakan Contoh dengan Hati-Hati

3.         Buang Model Sementara

4.         Bentuklah Kontrak Model

5.         Model Untuk Berkomunikasi

6.         Model Untuk Dimengerti

7.         Gunakan Kembali Artefak yang Ada

8.         Update Hanya Ketika Rusak

Dokumentasi Agile

ü  Pemakaian dokumentasi pada Agile Modeling mempunyai beberapa alasan baik alas an yang bagus atau alasan buruk.

ü  Alasan bagusnya  antara lain karena stakeholder kita membutuhkannya, untuk menentukan kontrak model, untuk mendukung komunikasi dengan kelompok luar, untuk memikirkan sesuatu dari awal sampai selesai.

ü  Sedangkan alasan yang dianggap buruk adalah karena pemohon ingin terlihat dalam kendali, pemohon ingin diketahui keberadaannya, pemohon tidak mengetahui yang lebih baik, proses anda mengatakan untuk membuatnya, seseorang ingin meyakinkan bahwa semuanya baik-baik saja, tugas spesial anda untuk kelompok lain, kontrak perusahaan anda secara rutin mengarah ke kompetisi ulang.

ü  Sedangkan tujuan adanya dokumentasi Agile adalah memaksimalkan investasi stakeholder yang berharga, memenuhi tujuan pembuatan model, menggambarkan informasi yang kemungkinan besar sedikit untuk dirubah, menggambarkan “barang bagus untuk diketahui”, mempunyai pelanggan tertentu dan memfasilitasi usaha pelanggan tersebut, cermat, konsisten, and detail, mempunyai daftar pengerjaan semua proses.

Untuk menjaga Agile Modelling tetap sederhana yaitu dengan cara cara sebagai berikut yaitu :

1.         Tambahkan praktek AM hanya ketika mereka akan mempertinggi produktifitas anda

2.         Buatlah sebuah model hanya ketika model menambah nilai

3.         Buatlah dokumen hanya ketika model menambah nilai dan stakeholder anda berkeinginan untuk membayar dan stakeholder anda mengerti perdagangan

Kapan kita menggunakan Agile Modeling dalam pemodelan bisa dibatasi pada masalah masalah antara lain ketika kita menggunakan pendekatan Agile untuk pembangunan, jika bekerja secara iteratif dan increment, persyaratan yang tidak jelas atau berubah – ubah, tujuan utama anda adalah membangun software, kita mempunyai dukungan dan keterlibatan stakeholder aktif, kelompok pembangun berada didalam kontrol atas nasibnya, seorang pemenang sebenarnya untuk keberadaan AM, kita mempunyai tanggung jawab dan memotifasi pembangun, kita mempunyai sumber yang cukup untuk anda gunakan.

Sumber : http://dwijaantara.wordpress.com/2010/10/25/agile-method/

:  © :   Linear Sequencial Model   :  © :

-          Model Linear Sequential/Waterfall merupakan paradigma rekayasa perangkat lunak yang paling tua dan paling banyak dipakai.

-          Model metode rekayasa perangkat lunak (RPL) ini sering disebut dengan “classic life cycle” atau model waterfall.

-          Karena model ini diperkenalkan pertama kali pada tahun 70-an maka sering dianggap kuno, tetapi merupakan model yang paling banyak dipakai didalam Software Engineering (SE).

-          Model ini melakukan pendekatan secara sistematis dan urut mulai dari level kebutuhan sistem lalu menuju ke tahap analisis, desain, coding, testing / verification, dan maintenance.

-          Disebut dengan waterfall karena tahap demi tahap yang dilalui harus menunggu selesainya tahap sebelumnya dan berjalan berurutan.

-          Sebagai contoh tahap desain harus menunggu selesainya tahap sebelumnya yaitu tahap requirement.

K e l e b i h a n     M o d e l      I n i

1.       Mudah diaplikasikan

2.       Memberikan template tentang metode analisis, desain, pengkodean, pengujian, dan pemeliharaan

3.       Cocok digunakan untuk produk software yang sudah jelas kebutuhannya di awal, sehingga minim kesalahannya

K e k u r a n g a n     M o d e l      I n i

1.       Terjadinya pembagian proyek menjadi tahap-tahap yang tidak fleksibel, karena komitmen harus dilakukan pada tahap awal proses

2.       Sulit untuk mengalami perubahan kebutuhan yang diinginkan customer

3.       Customer harus sabar untuk menanti produk selesai, karena dikerjakan tahap per tahap,menyelesaikan tahap awal baru bisa ke tahap selanjutnya

4.       Perubahan ditengah-tengah pengerjaan produk akan membuat bingung team work yang sedang membuat produk

5.       Adanya waktu menganggur bagi pengembang, karena harus menunggu anggota tim proyek lainnya menuntaskan pekerjaannya

Menurut Roger S. Pressman model waterfall dibagi menjadi 6 tahapan yaitu:

1.       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 Definition.

2.       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.

3.       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.

4.       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.

5.       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.

6.       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.