AGILE MODELLING

Agile Modeling

Sekilas Tentang Agile Modeling 
Dalam situasi pembangunan software harus membangun sistem bisnis yang besar dan penting. Jangkauan dan kompleksitas sistem harus dimodelkan sehingga dapat dimengerti, masalah dapat dibagi menjadi lebih kecil dan kualitas dapat dijaga pada tiap langkah pembangunan
software. Agile Modeling adalah suatu metodologi yang praktis untuk dokumentasi dan pemodelan system software. Agile Modeling adalah kumpulan nilai-nilai, prinsip dan praktek-praktek untuk memodelkan software agar dapat diaplikasian pada software development proyek secara efektif.

Prinsip dalam Agile Modeling :
–       Membuat model dengan tujuan: tentukan tujuan sebelum membuat model
–       Mengunakan multiple models: tiap model mewakili aspek yang berbeda dari model lain.
–       Travel light: simpan model-model yang bersifat jangka panjang saja
–       Isi lebih penting dari pada penampilan: modeling menyajikan informasi kepada audiens yang tepat.
–       Memahami model dan alat yang yang digunakan untuk membuat software
–       Adaptasi secara local

Tunggu posting selanjutnya..... :D

metodologi pembuatan software, SCRUM

Sekilas tentang metodologi pembuatan software, SCRUM

Scrum adalah suatu metodologi yang mengatur (manage) proses pembuatan software.
Scrum yang dikategorikan pada agile software development methodology.
Lihat agile manifesto, untuk mengerti filosofi dibalik kata agile pada konteks software development methodology atau project management.

** Kenapa Scrum?

Scrum menarik karena scrum lebih condong pada cara me-manage proyek secara praktikal (practical process model). Lebih menuntun tim untuk melakukan hal-hal yang perlu dan menyarankan hal-hal yang tidak perlu dalam menginspeksi proses dan melakukan adaptasi terus meneus untuk menyetir arah dari proses. Tidak seperti metodologi manajemen proyek lain yang cenderung deskriptif dan heavyweight.

** Scrum Role
Orang yang terlibat dalam proses scrum dibagi menjadi 3 jenis peran (role), yaitu:

• Product Owner yaitu orang yang menentukan spesifikasi atau feature dari software yang akan di-deliver.
• ScrumMaster yang bertanggung jawab untuk mengatur scrum process selama proyek berjalan. Oleh karena itu ScrumMaster harus menguasai Scrum process. ScrumMaster adalah fasilitator, yang mempersiapkan dan memimpin pertemuan (meeting)
• Project Team (tim 7 plus minus 2) yang merupakan self-organizing team yang menjalankan project, seperti business analyst, software architect, developer, tester dan lain-lain.

** Teminologi ayam dan babi (chickens and pigs)

Terminologi ini dapat dijelaskan dengan lelucon dibawah ini:

A chicken and a pig decide to start a restaurant.
The pig says, "What should we call it?"
The chicken says, "How about 'Ham & Eggs'?"
The pig says, "No thanks. I'd be committed, but you'd just be involved."

Terminologi ayam (chicken) berarti orang yang berkepentingan terhadap proyek (involved) tapi tidak sepenuhnya terlibat dalam proyek.
Terminologi babi (pig) adalah orang yang terlibat sepenuhnya dalam proyek. Yang termasuk dalam kategori pig adalah anggota project team.


** Proses

Proses eksekusi proyek dengan menggunakan scrum, dapat dilihat pada gambar ini

• First meeting
• Proses scrum diawli dengan pebuatan tujuan yang akan dicapai dan product backlog.
  Product backlog dikuantisasi waktu dengan satuan hari (antara 1-20 hari)
  Product backlog merupakan ombinasi antara story-based work (pekerjaan yang berbasis use case/product feature) dan task-based work misalnya "Tambahkan validasi pada semua form"
  Product backlog diprioritaskan oleh product owner.
• Product backlog yang berisi list yang diprioritaskan dari fitur-fitur atau perubahan yang akan ada pada produk.

• Sprint planning meeting
• Meeting untuk product owner, scrum team dan orang-orang yg berkepentingan.
• Menentukan sprint goal yaitu tujuan yang ingin dicapai pada scrum sprint berikutnya (30 hari kedepan).
  Sprint goal biasa adalah minimum fungsinalitas yang harus dicapai.
  Jika sprint goal tidak dicapai maka dilakukan abnormal termination
• Membuat sprint backlog yaitu list dari pekerjaan yang akan dilakukan selama sprint.
  Sprint backlog merupakan bagian produck backlog yang didetailkan.
  Sprint backlog dikuantisasi waktu berdasarkan jam (bukan hari yaitu antara 1-16).
  Sprint backlog harus tranparan untuk semua orang dalam tim
• Meeting yang tidak lebih dari 8 jam saja.
  Dengan 4 jam pertama adalah waktu yang digunakan untuk Product Owner menjelaskan atau presentasi tentang prioritas dari product backlog.
  Kemudian tanya jawab dari tim tetang isi, maksud, tujuan dari item yang ada di product backlog.
• Empat jam berikutnya adalah sesi untuk tim merencanakan Sprint.
• Fokus pada melakukan pekerjaan bukan berfikir mengenai bagaimana mengerjakannya.

• Daily Scrum meeting (Inspect and adapt cycle)
• Meeting harian selama tidak lebih dari 15 menit
• Yang boleh bicara dalam tim ini adalah scrum master dan anggota tim (pigs)
• Orang lain yang bekepentingan (chickens) dapat ikut dalam tim tetapi tidak boleh berkomunikasi (berbicara)
• Scrum master menanyakan 3 pertanyaan dari kepada anggota tim:
• Apa yang sudah kamu lakukan kemarin (selama 24 jam kebelakang)?
• Apa yang akan dikerjakan pada esok hari (24 jam mendatang)?
• Hal apa yang bisa menghentikan pekerjaan besok hari (kendala)?

• Sprint review meeting
• Meeting setelah aktivitas selama 2 minggu atau 1 bulanan (Sprint) berakhir, yang kemudian diikuti oleh sprint planning meeting untuk Sprint berikutnya.
• Meeting sebagai review atas Sprint yang sudah dilaksanakan.
• Memperbarui (update) sprint backlog yang merefleksikan berapa lama waktu yg dibutuhkan untuk menyelesaikan pekerjaan (task)

• Sprint retrospective meeting
• Meeting setelah sprint review meeting dan sprint planning meeting ScrumMaster dengan tim untuk merevisi proses dan cara kerja Scrum, proses development agar Sprint berikutnya lebih efektif dan enjoyable.
• Meeting ini sebaiknya tidak lebih dari 3 jam.

** Burndown charts

Burndown charts adalah grafik yang menunjukan seberapa banyak waktu yang dibutuhkan untuk menyelesaikan proyek. Grafik ini merefleksikan progress dari proyek.

Y-axis: Sisa waktu yang diperlukan untuk menyelesaikan pekerjaan (dalam jam)
atau jumlah item pekerjaan yang masih harus diselesaikan
X-Axis: Tanggal

Referensi tentang burndown chart yang cukup detail bisa dibaca di artikel "Earned-Value and Burn Charts"

Dynamic Systems Development Method (DSDM)

Dynamic System Development Method (DSDM)

Bagan Fase DSDM

Intermezzo

Merupakan Metodologi Pengembangan Software yang dikembangkan oleh Konsorsium Vendor dan Para Expert dalam bidang pengembangan Sistem Informasi(IS) di United Kingdom pada tahun 1990 dan pertamakali go public pada tahun 1995. Metodologi ini merupakan pengembangan tahap lanjut dari metode Rapid Application Development (RAD) yang sangat menerapkan  metode incremental dan iteratif. metode ini sangat ideal digunakan ketika suatu software dituntut untuk sangat fokus dan mementingkan tampilan yang mudah dan aspek kegunaan yang baik dari produk tersebut.

Versi terbaru dari DSDM, diluncurkan pada tahun 2007, disebut DSDM Atern. Atern adalah burung kolaboratif yang dapat melakukan perjalanan jarak yang luas dan melambangkan banyak aspek metode yang cara alami kerja misalnya prioritas dan kolaborasi.

Versi sebelumnya DSDM (dirilis pada bulan Mei 2003) yang masih banyak digunakan dan masih berlaku adalah DSDM 4.2 yang merupakan perbaikan DSDM versi 4. Versi perbaikanberisi panduan tentang cara menggunakan DSDM dengan Extreme Programming .

Asal-Usul

Pada awal 1990-an, Rapid Application Development (RAD) telah menyebar di industri TI. User interface untuk aplikasi perangkat lunak bergerak dari layar hijau tua untuk antarmuka pengguna ke era grafis yang digunakan saat ini. Alat pengembangan aplikasi baru datang di pasar, seperti PowerBuilder. Hal ini pengembang applikasi untuk menyampaikan solusi yang diusulkan mereka jauh lebih mudah kepada pelanggan mereka.

Namun, gerakan RAD sangat terstruktur: tidak ada definisi yang disepakati dari proses yang sesuai dan banyak organisasi datang dengan definisi mereka sendiri dan pendekatan. Banyak perusahaan besar yang sangat tertarik pada kemungkinan tapi mereka juga khawatir bahwa mereka tidak akan kehilangan tingkat kualitas.

The DSDM Konsorsium didirikan pada tahun 1994 oleh asosiasi vendor dan ahli di bidang rekayasa perangkat lunak dan telah dibuat dengan tujuan "bersama-sama mengembangkan dan mempromosikan kerangka kerja RAD independen". Asal-usul itu merupakan acara yang diselenggarakan oleh Grup Butler di London. Orang-orang di pertemuan itu semua bekerja untuk organisasi blue-chip seperti British Airways, American Express, Oracle dan Logica.

Pada pertemuan awal diputuskan bahwa Jennifer Stapleton, Logica , akan membuat sebuah arsitektur untuk end-to-end, pengguna-sentris tapi kualitas dikendalikan metode iteratif dan pembangunan bertahap. Arsitektur yang dihasilkan dirancang untuk sepenuhnya kompatibel dengan ISO 9000 dan PRINCE2 , yang menjadi perhatian utama bagi kelompok. Setelah arsitektur berada di tempat (sebulan setelah pertemuan awal), Konsorsium membentuk berbagai kelompok tugas untuk mengisinya dengan semua aspek pengembangan perangkat lunak, termasuk alat-alat manajemen proyek dan teknik, kualitas dan pengujian, pengembangan alat dan teknik, personil dan perangkat lunak pengadaan.

Kriteria Pemilihan Metode

Metode ini digunakan ketika kondisi sistem yang akan dikembangkan memiliki kriteria :

•     •Hasil dari pengembangan sesegera mungkin dapat dilihat
•     •Pengguna sistem dapat aktif memberikan kontribusi mereka dalam merangkul pengembang
•     •Fungsi utama telah didefenisikan secara cepat, dan funsi lainnya dapat menyusul secara berkala
•     •Pihak yang berkepentingan dapat berkomunikasi secara lancar tanpa ada birokrasi yang rumit atau halangan karena umpan balik dari pengguna sistem secara konstan baik dalam pengembangan sistem.
•     •Proyek memiliki indikator awal apakah akan bekerja secara baik atau tidak, sehingga meminimalisir sesuatu yang tidak diinginkan ketika aplikasi dikembangkan.
•     •Sistem harus selesai pada tepat waktu dan anggaran yang baik pas.
•     •Pengguna sistem mengerti dalam arah proyek. 

Prinsip

DSDM memiliki 8 prinsip yang sangat penting dalam implementasinya. menyepelekan salah satunya akan merusak filosofi kerangka kerja dan meningkatkan resiko kegagalan.

1) Fokus pada kebutuhan bisnis

Kriteria utama untuk penerimaan dari "penyampaian" adalah memberikan suatu sistem yang membahas kebutuhan bisnis saat ini. Menyampaikan sistem yang sempurna yang membahas semua kebutuhan bisnis yang mungkin kurang penting daripada berfokus pada fungsi kritis.
    • Memahami prioritas bisnis sejati
    • Membentuk Kasus Bisnis suara
    • Mencari sponsor bisnis yang berkesinambungan dan komitmen
    • Jaminan Subset Usable Minimum fitur.

2) Memberikan tepat waktu

    • Timebox pekerjaan
    • Fokus pada prioritas bisnis
    • Selalu memenuhi tenggat waktu

3) Berkolaborasi

Keterlibatan pengguna merupakan kunci utama dalam menjalankan proyek yang efisien dan efektif, dimana kedua pengguna dan pengembang berbagi tempat kerja (baik fisik atau melalui alat), sehingga pengambilan keputusan dapat dilakukan secara kolaboratif dan cepat.
    • Melibatkan pemangku kepentingan yang tepat, pada waktu yang tepat, seluruh proyek
    • Pastikan bahwa anggota tim diberi wewenang untuk mengambil keputusan atas nama rakyat yang mereka wakili.
    • Aktif melibatkan perwakilan bisnis
    • Membangun budaya satu tim

4) Jangan kompromi soal kualitas

    • Mengatur tingkat kualitas di awal
    • Memastikan kualitas yang tidak menjadi variabel
    • Desain, dokumen dan uji tepat
    • Membangun kualitas dengan review konstan
    • Uji awal dan terus menerus

5) Membangun secara bertahap

    • Upayakan untuk pengiriman awal manfaat bisnis di mana mungkin
    • Terus mengkonfirmasi solusi yang tepat sedang dibangun
    • Secara formal menilai kembali prioritas dan kelayakan proyek yang sedang berlangsung.

6) Mengembangkan Iterasi

Fokus pada penyajian produk sesering mungkin, dengan asumsi bahwa untuk memberikan sesuatu yang "cukup baik" sebelumnya selalu lebih baik daripada memberikan segalanya "sempurna" pada akhirnya. Dengan memberikan produk sering dari tahap awal dari proyek, produk dapat diuji dan ditinjau di mana catatan uji dan dokumen review dapat diperhitungkan pada iterasi berikutnya atau fase.
    • Jangan cukup desain depan untuk menciptakan fondasi yang kuat
    • Mengambil pendekatan iteratif untuk membangun semua produk
    • Membangun umpan balik pelanggan dalam setiap iterasi untuk fokus pada solusi bisnis yang efektif
    • Terimalah bahwa detail yang paling muncul kemudian daripada cepat
    • Merangkul berubah - solusi yang tepat tidak akan berkembang tanpa itu
    • Jadilah kreatif, bereksperimen, belajar, berevolusi

7) Berkomunikasi terus menerus dan jelas

Komunikasi dan kerja sama di antara semua stakeholder proyek diperlukan untuk menjadi efisien dan efektif.
    • Jalankan tim setiap hari
    • Gunakan lokakarya
    • Gunakan teknik komunikasi yang kaya seperti pemodelan dan prototyping
    • Iterasi kini berkembang solusi awal dan sering
    • Menjaga dokumentasi ramping dan tepat waktu
    • Mengelola harapan pemangku kepentingan seluruh proyek
    • Mendorong informal komunikasi tatap muka di semua tingkatan

8) Menunjukkan kontrol.

    • Gunakan tingkat yang sesuai formalitas untuk pelacakan dan pelaporan
    • Buatlah rencana dan kemajuan terlihat oleh semua
    • Mengukur kemajuan melalui fokus pada pengiriman produk daripada kegiatan selesai
    • Mengelola secara proaktif
    • Evaluasi kelayakan proyek terus berdasarkan tujuan bisnis
 

Teknik Utama

Manajemen proyek yang tradisional menggunakan "Milestones" dalam menandai pencapaiannya. DSDM berbeda, DSDM menggunakan teknik "Timeboxing" dalam menandai pencapainnya yang biasannya berjangka waktu 2,4 atau enam pekan. beberapa teknik utamanya adalah sebagai berikut :

Timebox

    • Dapat berisi beberapa tugas.
    • Pada akhirnya produk perlu disampaikan
    • Dapat berubah karena tugas didefenisikan sebagai subyek, bukan apa yang akan disampaikan
    • Tugas dapat diubah selama waktu "Iteratif" yang memungkinkan untuk respon cepat dalam kebutuhan bisni

MoSCoW Rules

Proyek DSDM sangat difokuskan pada waktu, budget dan keterlibatan pengguna dalam proses pengembangan. so sangat diwajibkan selalu memantau apa yang diinginkan pengguna.
Kebutuhan pengguna dapat berubah selama proses dengan syarat :
    • Menyadari kemungkinan teknis yang baru
    • Perubahan lingkungan kerja pengguna
Penerapan teknik MosCow memiliki aturan sebagai berikut :
1. Must Have : Semua fitur yang diklasifikasikan dalam kelompok harus di implementasikan oleh pengguna dan jika mereka tidak disampaikan, sistem akan tidak bekerja.
2. Should Have : Fitur ini menjadi prioritas bagi sistem, namun dapat diabaikan apabila kendala waktu sangat berisiko.
3. Could Have : Fitur ini bisa bisa ada namun juga dapat diabaikan karena tidak mempengaruhi tuntutan bisnis
4. Would Have : Persyaratan ini akan dipenuhi bila terdapat waktu sisa dalam pengembangan sistem atau pada pengembangan selanjutnya.

Prototyping

Prototyping memiliki dua prinsip utama yaitu :
    • Seringnya pengiriman aplikasi kepada pengguna
    • Pengembangan yang incremental

Mengimplementasikan fungsi utama dari aplikasi, sehingga kita dapat menemukan kendala lebih cepat dalam proses pengembangan dan kita dapat lebih cepat mengirimkan aplikasi kepada user untuk mendapatkan feedback. feedback yang secara rutin sangat diperlukan.
DSDM membedakan tipe prototipe sebagai berikut :
    a. Bussines Prototype : Mempersilahkan penilaian pada sistem yang akan dikembangkan
    b. Usability Prototype : Periksa User Interface
    c. Performance Prototype : Pastikan solusi dapat mengatasi kinerja dan volume
    d. Capability Prototype : Mengevaluasi opsi yang memungkinkan

Faktor Kunci Kesuksesan DSDM

Konsorsium DSDM telah membuat sepuluh faktor penting bagi penganutnya :
    1. Menyetujui terlebih dahulu filosofi DSDM sebelum memulai kerja.
    2. Pengambilan keputusan haruslah melibatkan pengguna dan pengembang.
    3. Komitmen dari manajemen senior haruslah penting
    4. Penyampaian yang rutin
    5. Kemudahan akses antara developer dan pengguna
    6. Kestabilan team
    7. Kemampuan bekerjasama pada tim pengembang
    8. Ukuran tim pengembang
    9. Dukungan komersil
    10. Teknologi pada pengembangan

Kelemahan dari DSDM:

     Biaya lisensi
     Penghalang yang relatif tinggi untuk masuk
     Pergeseran budaya dalam organisasi

DSDM jelas mewakili dirinya sebagai pengembangan tangkas paling matang method.Even Microsoft meminjam ide dari DSDM, penerbitan kerangka solusi semi-tangkas mereka sendiri. Xansa digunakan DSDM untuk mengatur pengembangan lepas pantai di India.The versi terbaru dari DSDM adalah "DSDM Atern". Hal ini telah terbukti menjadi kerangka tangkas kuat untuk manajemen proyek yang efisien yang didukung dan Certified oleh DSDM Consortium.Not hanya itu tetapi juga telah dinominasikan untuk AGILE CONCEPT Awards 2011.

Fase-Fase Pengembangan Proyek

Bagan Fase DSDM

Apa itu Adaptive Software Development (ASD)

Adaptive Software Development (ASD)

ASD merupakan suatu model yang tergolong dalam pendekatan agile yang diusulkan oleh Jim Highsmith. ASD menekankan pada pengorganisasian tim secara mandiri, kolaborasi antar-perseorangan, dan terus belajar, baik secara individu maupun secara tim. ASD menggunakan tools yang disebut "time-boxing" - yaitu berupa aktifitas yang menentukan jangka waktu tertentu yang dialokasikan untuk menyelesaikan berbagai macam tugas. Apabila waktu yang ditentukan tersebut selesai, maka pembangunan sistem akan pindah ke tugas berikutnya, dengan harapan bahwa sebagian besar dari critical work telah berhasil diselesaikan sebelum waktu keseluruhan tugas berakhir. Terdapat tiga tahapan pada model ASD, yaitu: Speculation, Collaboration, dan Learning.

Adaptive Software Development (Pressman, 2005)

Pada tahap Speculation, proyek dimulai dan adaptive cycle planning diselenggarakan. Pada tahapan ini, didefinisikan visi dan misi pengguna terhadap sistem yang akan dibuat, selanjutnya mendefinisikan project constraints, misalnya: waktu deliver. dan selanjutnya mendefinisikan satu set dari requirements yang akan dikerjakan dalam suatu cycle. Pada tahap Collaboration, pada tahap ini diorganisasikan tim kerja untuk membangun sistem. Direkomendasikan menggunakan model Joint Application Development (JAD). Pada tahap Learning, terdapat tiga aktifitas yaitu: pelanggan atau end-user menyediakan feedback terhadap hasil incremental delivery, tim ASD melakukan review terhadap komponen perangkat lunak untuk memperbaiki dan meningkatkan kualitas perangkat lunak yang sedang dibuat.

EXTREME PROGRAMING

Extreme Programming

Sejarah Extreme Programming

 

Extrem programming dimunculkan untuk menangani perubahan-perubahan yang biasanya sering terjadi pada saat pengembangan berlangsung bahkan pada saat proses pengembangan sudah hampir berakhir. Selainitu XP juga dimunculkan untuk mengatasi berbagai requirements yang tidak jelasdari user. Sebagai sebuahmetodologi untuk mengembangkan peragkat lunak XP tentu memiliki siklus hidup. Siklus hidup pada XP inierdapat lima fase yaitu : Extreme Programming diciptakan oleh Kent Beck selama bekerja di Chrysler MenyeluruhbSistem Kompensasi (C3) proyek penggajian. Beck C3 menjadi pemimpin proyek Maret 1996 dan mulai untuk memperbaiki metode pengembangan yang digunakan dalam proyek dan menulis sebuah buku tentang   metode (pada Oktober 1999, Extreme Programming Explained diterbitkan). Chrysler membatalkan proyek C3 pada Februari 2000, setelah perusahaan diakuisisi oleh Daimler-Benz. Meskipun Extreme Programming itu sendiri adalah relatif baru, banyak dari praktik sudah ada selama beberapa waktu, metodologi, setelah semua, diperlukan praktek terbaik untuk tingkat ekstrem. Sebagai contoh, tes-praktek pembangunan pertama, perencanaan dan tes tertulis sebelum setiap mikro-increment digunakan sebagai awal NASA Project Mercury, pada awal 1960-an (Larman 2003). Refactoring, modularitas, bottom-up dan desain inkremental digambarkan oleh Leo Brodie dalam bukunya yang diterbitkan pada tahun 1984 

1.3. ASAL EXTREME PROGRAMMING

Sebagian besar pengembangan perangkat lunak pada 1990-an dibentuk oleh dua pengaruh utama: internal, pemrograman berorientasi objek pemrograman prosedural digantikan sebagai paradigma pemrograman yang disukai oleh beberapa orang dalam industri; eksternal, munculnya internet dan booming dot-com-untuk menekankan kecepatan pasar dan perusahaan-pertumbuhan sebagai faktor bisnis kompetitif. Persyaratan berubah dengan cepat menuntut lebih pendek siklus hidup produk, dan sering tidak sesuai dengan metode tradisional pengembangan perangkat lunak. Chrysler Menyeluruh Sistem Kompensasi dimulai dalam rangka untuk menentukan cara terbaik untuk menggunakan teknologi obyek, dengan menggunakan sistem penggajian di Chrysler sebagai objek penelitian, dengan sebagai bahasa Smalltalk dan batu permata sebagai lapisan akses data. Mereka dibawa di Kent Beck, Smalltalk praktisi terkemuka, untuk melakukan kinerja tuning pada sistem, tetapi perannya diperluas ketika ia melihat adanya beberapa persoalan yang mereka hadapi dengan proses pembangunan mereka. Dia mengambil kesempatan ini untuk mengusulkan dan mengimplementasikan beberapa perubahan dalam praktik mereka didasarkan pada sering bekerja dengan kolaborator, Ward Cunningham. Pertama kali saya diminta untuk memimpin sebuah tim, saya meminta mereka untuk melakukan sedikit hal yang saya pikir itu masuk akal, seperti pengujian dan ulasan. Kedua kali ada lebih banyak di telepon. Saya pikir, Sialan torpedo, setidaknya ini akan membuat artikel yang baik, dan meminta tim untuk mendongkrak semua tombol-tombol untuk 10 pada hal-hal yang saya pikir sangat penting dan meninggalkan segala sesuatu yang lain. -Kent Beck Ron Je ries Beck diundang ke proyek untuk membantu mengembangkan dan memperbaiki metode ini. Je ries kemudian bertindak sebagai pelatih untuk menanamkan praktek-praktek sebagai kebiasaan dalam tim C3. Informasi tentang prinsip-prinsip dan praktek-praktek di belakang XP ini disebarluaskan ke dunia yang lebih uas melalui diskusi di Wiki asli, WikiWikiWeb Cunningham. Berbagai kontributor dibahas dan dikembangkan atas ide-ide, dan beberapa spin-o metodologi yang mengakibatkan (lihat gesit pengembangan perangkat unak). Selain itu, konsep XP telah dijelaskan, selama beberapa tahun, menggunakan sistem teks hiper-peta di website XP di www.extremeprogramming.org sekitar tahun 1999 (website XPorg). Beck edited serangkaian buku on XP, mulai dengan dirinya sendiri Extreme Programming Explained (1999, ISBN 0-201-61641-6) , menyebarkan ide-idenya ke yang lebih besar, namun sangat reseptif, penonton. Penulis dalam seri melewati berbagai aspek menghadiri XP dan praktik, bahkan sebuah buku kritis terhadap praktek-praktek. XP cukup menciptakan buzz di akhir 1990-an dan awal 2000-an, melihat adopsi dalam sejumlah lingkungan yang sangat berbeda dari asal-usulnya. Disiplin tinggi yang diperlukan oleh praktek-praktek asli sering pergi di pinggir jalan, menyebabkan beberapa praktik yang dianggap terlalu kaku untuk menjadi usang atau kiri dibatalkan di setiap situs. Praktek-praktek pembangunan tangkas tidak berdiri diam, dan XP masih berkembang, asimilasi lebih banyak pelajaran dari pengalaman di lapangan. Dalam edisi kedua Extreme Programming Dijelaskan, Beck menambahkan lebih banyak nilai-nilai dan praktik-praktik dan dibedakan antara primer dan praktek wajar.

 1.4. Latar Belakang Extreme Programming

Requirement yang berubah dengan cepat menuntut lifecycles yang lebih pendek, dan tidak selaras dengan metoda pengembangan tradisional, yang pada umumnya memerlukan disain luas di awal dan mengakibatkan perubahan desain yang terjadi kemudian memerlukan biaya yang lebih tinggi atau kehilangan milestones. Berdasarkan hal ini kemudian dilahirkan konsep XP yang digagas oleh Kent Beck dan Ward Cunningham pada Maret 1996. Metode XP merupakan yang terpopuler dari beberapa metodologi pengembangan software yang dipakai untuk mengimplementasikan proyek pengembangan perangkat lunak.

1.5. Pengertian Extreme Programing

Proyek Pemrograman Extreme pertama dimulai 6 Maret 1996. Extreme Programming adalah salah satu dari beberapa Proses Agile populer. Sudah terbukti sangat sukses di banyak perusahaan dari berbagai ukuran dan industri di seluruh dunia.Extreme Pemrograman berhasil karena menekankan kepuasan pelanggan. Alih-alih memberikan semua yang anda mungkin inginkan pada tanggal beberapa jauh di masa depan proses ini memberikan perangkat lunak yang Anda butuhkan saat Anda membutuhkannya. Extreme Pemrograman memberdayakan pengembang Anda untuk percaya diri menanggapi perubahan kebutuhan pelanggan, bahkan terlambat dalam siklus hidup.Extreme Pemrograman menekankan kerja sama tim. Pengelola, pelanggan, dan pengembang semua mitra setara dalam sebuah tim kolaboratif. Extreme Pemrograman menerapkan, sederhana namun efektif yang memungkinkan tim lingkungan menjadi sangat produktif. Tim mengorganisir diri mengatasi masalah untuk menyelesaikannya see sien mungkin.Extreme Pemrograman meningkatkan proyek perangkat lunak dalam lima cara penting; komunikasi, kesederhanaan, umpan balik, rasa hormat, dan keberanian. Extreme Programmer selalu berkomunikasi dengan pelanggan mereka dan programer sesama. Mereka terus desain mereka yang sederhana dan bersih. Mereka mendapatkan umpan balik dengan menguji perangkat lunak mereka dimulai pada hari pertama. Mereka memberikan sistem ke pelanggan sebagai perubahan sedini mungkin dan melaksanakan seperti yang disarankan. Setiap keberhasilan kecil memperdalam rasa hormat mereka atas kontribusi yang unik dari masing-masing dan setiap anggota tim. Dengan dasar Extreme pemrogram dapat berani merespon perubahan kebutuhan dan teknologi.Aspek yang paling mengejutkan dari Extreme Programming adalah aturan sederhana. Extreme Pemrograman sangat mirip jig gergaji teka-teki. Ada banyak potonganpotongan

kecil. Individual potongan Extreme Programming adalah metode pengembangan perangkat lunak yang ringan dan termasuk salah satu agile methods yang dipelopori oleh Kent Beck, Ron Je ries, dan Ward Cunningham. Extreme Programming merupakan agile methods yang paling banyak digunakan dan menjadi sebuah pendekatan yang sangat terkenal. Sasaran Extreme Programming adalah tim yang dibentuk berukuran antara kecil sampai medium saja, tidak perlu menggunakan sebuah tim yang besar. Hal ini dimaksudkan untuk menghadapi requirements yang tidak jelas maupun terjadinya perubahan-perubahan requirements yang sangat cepat.Extreme Programming sebagai sebuah metode yang dinamis diperlihatkan dalam empat values yang dimilikinya dan keempatnya merupakan dasar-dasar yang diperlukan dalam Extreme Programming. Kent Beck menyatakan bahwa tujuan jangka pendek individu sering berbenturan dengan tujuan sosial jangka panjang. Dalam Extreme Programming ada penekanan kuat pada komunikasi informal dan langsung , tes otomatis dan pasangan pemrograman , yang memantau kemajuan pengembangan perangkat lunak , yang memungkinkan umpan balik terus menerus pada skala waktu yang berbeda .Akar XP terletak pada masyarakat Smalltalk dan khususnya, dalam kolaborasi dekat Kent Beck dan Ward Cunningham dimulai padaakhir 1980-an . Keduanya menyempurnakan praktik ini pada berbagai proyek selama awal 1990-an , memperluas ide-ide mereka dari pengembangan perangkat lunak Pendekatan yang kedua adaptif dan berorientasi pada orang langkah dari praktek informal metodologi terjadi pada tahun 1997 ketika Kent Beck berhasil menggunakan XP untuk melaksanakan proyek penggajian untuk Daimler Chrysler. Sejak itu , XP telah berhasil digunakan di banyak perusahaan , seperti Bayerische Landesbank , Kredit Swiss Life, Pertama Union National Bank , Ford Motor Company dan UBS. XP didasarkan pada Beck dan Cunningham pengamatan dari apa yang membuat pengembangan program lebih cepat dan apa yang membuatnya lebih lambat . XP merupakan metodologi penting karena merupakan salah satu dari beberapa metodologi perangkat lunak baru yang diciptakan untuk menghasilkan perangkat lunak berkualitas tinggi dan mengurangi biaya perangkat lunak. Pengalaman ini kemudian diformalkan dan diterbitkan pada tahun 1999 oleh Kent Beck yang mende nisikan satu praktik dapat mewujudkan empat nilai-nilai fundamental yaitu komunikasi, umpan balik, keberanian , kesederhanaan. Extreme programming memiliki lima nilai yaitu :

Komunikasi: Nilai ini berfokus pada membangun orang-ke - orang,saling pengertian dari lingkungan

masalah melalui minimal resmi dokumentasi dan melalui interaksi tatap muka maksimal . Praktek XP

dirancang untuk mendorong interaksi , pengembang - to- developer dan pengembang - ke-pelanggan .

Kesederhanaan: Nilai ini menantang setiap anggota tim untuk terus bertanya, Apa hal paling sederhana yang mungkin bisa bekerja ? XP berpendapat bahwa lebih baik untuk melakukan hal yang sederhana dan membayar sedikit lebih besok untuk perubahan daripada melakukan lebih rumit,hal hari ini yang mungkin tidak akan pernah digunakan .

Tanggapan: Dalam extreme programming team mendapatkan umpan balik dengan menguji perangkat lunak mereka,memberikan sistem ke pelanggan sedini mungkin dan mengimplementasikan perubahan dan prioritas seperti yang disarankan oleh umpan balik dari pelanggan .

Keberanian: Pengembang sering mengutip tekanan untuk kapal produk buggy. Itu Dibutuhkan keberanian untuk menolak tekanan ini. Beck juga menyatakan bahwa tim harus berani dan bersedia untuk membuat perubahan di akhir proyek atau bahkan membuang kode dan mulai dari awal lagi.

Menghormati: Jika anggota tim tidak peduli satu sama lain dan pekerjaan mereka , ada metodologi

dapat bekerja . Anda harus menghormati kepada rekan-rekan Anda dan kontribusi mereka , untuk

organisasi Anda , untuk orang-orang yang hidupnya tersentuh oleh sistem. Beck mengatakan Praktek

adalah bukti dari nilai-nilai Tugas yang dapat dijatuhkan jika kita mendapatkan kendala . Dengan cara ini akan tetap margin keamanan dan memecahkan kasus masalah.

Seluruh: Tim tim harus terdiri dari anggota dengan semua keterampilan dan perspektif yang dibutuhkan untuk proyek untuk berhasil . Mereka harusmemiliki rasa yang kuat milik , dan harus membantu satu sama lain . Informatif Workspace : ruang kerja harus dilengkapi dengan poster informatif dan hal-hal lain , memberikan informasi tentang status proyek dan pada tugas-tugas yang akan dilakukan.

Kerja: Berenergi pengembang harus di-refresh , sehingga dapat fokus pada pekerjaan mereka dan

menjadi produktif . Akibatnya setiap orang bisa menghabiskan waktu untuk nya atau kehidupan

pribadinya sendiri . praktek ini dalam versi lama XP disebut "kecepatan berkelanjutan " .

Pair: Programming : kode selalu ditulis oleh dua programmer di salah satu mesin . Praktek ini keluar

pada extrme programming asli .

Tambahan: Desain extreme programming menentang menghasilkan desain yang lengkap di depan .Tim pengembangan menghasilkan kode sesegera mungkin dalam rangka untuk mendapatkan umpan balik dan memperbaiki sistem terus menerus. Desain diperlukan untuk mendapatkan kode yang baik Pertanyaannya adalah ketika merancang XP menyarankan untuk melakukannya secara bertahap selama coding . Cara membantu memperoleh ini adalah untuk menghilangkan duplikasi dalam kode. 

Pemrograman Test- Pertama : sebelum memperbarui dan menambahkan kode perlu untuk menulis tes untuk memveri kasi kode. Hal ini memecahkan empat masalah : 

·                   Cowboy coding yaitu sangat mudah untuk mendapatkan,dapat dibawa pergi dengan program cepat dan menempatkan semuanya dalam pikiran serta dalam kode. Tes membantu kita fokus pada masalah yang dihadapi dan dapat membuktikan bahwa desain kami adalah benar.

·                     Coupling dan kohesi yaitu jika tidak mudah untuk menulis tes , ini berarti bahwa anda memiliki masalah desain , bukan dari pengujian atau coding

·                     Kepercayaan yaitu jika Anda menulis kode dokumen dengan tes otomatis , rekan kerja Anda akan mempercayai Anda .

·                     Rhythm yaitu mudah untuk tersesat dan mengembara selama berjam-jam ketika kita coding . Jika kita membiasakan diri dengan: tes, kode ,refactor , tes, kode , refactor , itu tidak akan terjadi .

1.6. Tujuan Extreme Programming

Tujuan utama dalam extreme programming adalah menurunkan biaya dari adanya perubahan software .Dalam metodologi pengembangan sistem tradisional, kebutuhan sistem ditentukan padatahap awal pengembangan proyek dan bersifat xed. Hal ini berarti biaya terhadap adanya perubahan kebutuhan yang terjadi pada tahap selanjutnya akan menjadi mahal. XP diarahkan untuk menurunkan biaya dari adanya perubahan dengan memperkenalkan nilai-nilai basis dasar, prinsip dan praktis. Dengan menerapkan XP, pengembangan suatu sistem haruslah lebih eksibel terhadap perubahan. Sasaran XP adalah tim yang dibentuk berukuran antara kecil sampai medium saja, tidak perlu menggunakan sebuah tim yang besar. Hal ini dimaksudkan untuk menghadapi requirements yang tidak jelas maupun terjadinya perubahan-perubahan requirements yang sangat cepat. XP dimunculkan untuk menangani perubahan-perubahan yang biasanya sering terjadi pada saat pengembangan berlangsung bahkan pada saat proses pengembangan sudah hampir berakhir.

1.7. Kelebihan dan Kelemahan Extreme Programing

Keunggulan:

·  Menjalin komunikasi yang baik dengan klien. (Planning Phase)

·  Menurunkan biaya pengembangan (Implementation Phase)

·   Meningkatkan komunikasi dan sifat saling menghargai antar developer. (Implementation Phase)

· XP merupkan metodologi yang semi formal. (Planning Developer harus selalu siap dengan perubahan karena perubahan akan selalu diterima, atau dengan

·     kata lain eksibel. (Maintenance Phase)

Kelemahan :

·    Tidak bisa membuat kode yang detail di awal (prinsip simplicity dan juga anjuran untuk melakukan

apa yang diperlukan hari itu juga). Selain dari keunggulan dan kelemahan XP yang telah disebutkan

diatas, XP juga memiliki keunggulan yang sekaligus menjadi kelemahannya, yaitu XP tidak memiliki

dokumentasi formal yang dibuat selama pengembangan. Satu-satunya dokumentasi adalah dokumentasi awal yang dilakukan oleh user.

1.8. PRINSIP DASAR EXTREME PROGRAMMING

Terdapat lima prinsip dasar yang sangat fundamental dalam Extreme Programming, dimana prinsip -prinsip ini digunakan untuk menentukan apakah semua tindakan/pekerjaan yang telah dilakukan akan sukses atau sebaliknya (dalam konteks Extreme Programming). Kelima prinsip tersebut adalah:

·                     Aliran umpan balik (Rapid Feedback)

·                     Asumsi kesederhanaan (Asume Simplicity)

·                     Penambahan perubahan (Incremental Change)

·                     Pemelukan pekerjaan (Embrace Work)

·                     Kualitas kerja (Quality Work)

Extreme programming merupakan suatu disiplin ilmu dari software development yang didasarkan pada nilai dari kelima aspek di atas. Dalam extreme programming seluruh team bekerja sebagai satu kesatuan dalam bekerja, dengan feedback yang cukup maka mereka akan mengetahui sudah sampai mana mereka bekerja, dan apabila terdapat sesuatu hal mereka ingin melihat ke belakang tentang apa yang telah dikerjakan mereka dapat menggunakan feedback tersebut. Jadi feedback menyimpan informasi tentang apa apa saja yang telah dilakukan oleh team.Disamping kelima prinsip tersebut terdapat sepuluh prinsip lainnya yang bersifat opsional,namun sebaiknya perlu diperhatikan agar hasil yang dihasilkan memuaskan. kesepuluh prinsip tersebut adalah

·                     Teach Learning

·                     Small initial investment

·                     Play to win

·                     Cncrete experiments

·                     Open, honest communication

·                     Work with people's instinct not against them

·                     Accepted responsibility

·                     Local adaptation

·                     Travel light

·                     Honest measurement

1.9. Kegiatan Exreme Programming

Dalam extreme programming menggambarkan empat kegiatan dasar yang dilakukan dalam proses pengembanganperangkat lunak yaitu :

Coding: Pendukung XP berpendapat bahwa satu-satunya benar-benar produk yang penting dari proses pengembangan sistem kode instruksi perangkat lunak komputer dapat menafsirkan. Tanpa kode, tidak ada produk kerja.Coding juga dapat digunakan untuk mengetahui solusi yang paling cocok. Sebagai contoh, XP akan menganjurkan bahwa dihadapkan dengan beberapa alternatif untuk masalah pemrograman, satu kode hanya perlu semua solusi dan menentukan dengan tes yang otomatis solusi yang paling sesuai. Coding juga dapat membantu untuk mengkomunikasikan pikiran tentang masalah pemrograman. Seorang pemrogram berurusan dengan masalah pemrograman yang kompleks dan sulit untuk menjelaskan solusi untuk sesama programer mungkin kode ini dan gunakan kode untuk menunjukkan apa yang dia berarti. Kode, mengatakan para pendukung posisi ini, selalu jelas dan ringkas dan tidak dapat ditafsirkan dengan lebih dari satu cara. Pemrogram lain dapat memberikan umpan balik kode ini oleh juga pengkodean pikiran mereka.

Pengujian: Satu tidak bisa memastikan bahwa fungsi bekerja kecuali satu tes itu. Desain bug dan masalah kesalahan yang meresap dalam pengembangan software. Extreme Programming Pendekatan adalah bahwa jika sedikit pengujian dapat menghilangkan beberapa kekurangan, banyak pengujian dapat menghilangkan banyak kelemahan. Unit tes menentukan apakah tur yang diberikan bekerja sebagaimana dimaksud. Seorang pemrogram menulis sebagai banyak tes otomatis mereka bisa memikirkan yang dapat memecahkan kode; jika semua tes berjalan dengan sukses, maka pengkodean selesai. Setiap potongan kode yang tertulis diuji sebelum pindah ke tur berikutnya. * Tes Penerimaan memveri kasi bahwa persyaratan sebagaimana yang dipahami oleh para programer memenuhi persyaratan pelanggan yang sebenarnya. Ini terjadi pada tahap eksplorasi perencanaan rilisSebuah testathon adalah sebuah peristiwa ketika programmer bertemu untuk melakukan tes kolaboratif menulis, semacam brainstorming relatif terhadap pengujian perangkat lunak.

Mendengarkan: Programmer harus mendengarkan apa yang pelanggan membutuhkan sistem untuk

melakukan, apa yang logika bisnis diperlukan. Mereka harus memahami kebutuhan-kebutuhan ini cukup baik untuk memberikan umpan balik pelanggan tentang aspek teknis bagaimana masalah bisa dipecahkan, atau tidak dapat dipecahkan. Pemahaman masalah nya. Komunikasi antara pelanggan dan pemrogram adalah dibahas lebih lanjut dalam The Perencanaan Game.

Merancang: Dari sudut pandang kesederhanaan, orang bisa mengatakan bahwa pengembangan sistem tidak membutuhkan lebih dari coding, pengujian dan mendengarkan. Jika kegiatan tersebut dilakukan dengan baik, hasilnya harus selalu menjadi sistem yang bekerja. Dalam prakteknya, ini tidak akan bekerja. Satu dapat datang jauh tanpa merancang tetapi pada waktu tertentu seorang pun akan terjebak. Sistem menjadi terlalu kompleks dan dependensinya di dalam sistem berhenti menjadi jelas. Satu dapat menghindari hal ini dengan menciptakan sebuah desain struktur yang mengatur logika dalam sistem. Desain yang baik akan menghindari banyak dependensi dalam sistem ini berarti bahwa mengubah salah satu bagian dari sistem tidak akan mempengaruhi bagian lain dari sistem.

 

Konsep Extreme Programming

2.1. Penerapan Extreme Programmning

Beberapa hal yang harus dipertimbangkan sebelum seseorang masuk dalam dunia Extreme Programmning adalah sebagai berikut:

·  User harus memahami konteks bisnis yang akan dikembangkan sistemnya, sehingga developer dapat menangkap sistem secara aplikatif dan dapat mengusulkan teknologi apa yang dapat dikembangkan dalam sistem barunya.

·   Akan lebih efektif apabila developer pernah menangani proyek pengembangan sistem yang sejenis sehingga dapat memberikan usulan model sistem baru, di samping alasan bahwa developer telah memiliki template aplikasi sistem tersebut untuk dijadikan prototype sistem baru. Hal ini akan berimplikasi kepada kemudahan dalam konstruksi sistem karena dikembangkan berdasarkan template yang sudah ada.

· Extreme programming menuntut komunikasi antar developer dan user secara intensif dan komunikasi internal antar developer secara komprehensif, sehingga akan lebih representatif apabila tahap pengembangan sistem dilakukan di lokal yang mendukung proses komunikasi tersebut.

2.2. Kunci Utama XP (XP Value)

XP sebagai sebuah metode yang dinamis diperlihatkan dalam empat values yang dimilikinya dan keempatnya merupakan dasar-dasar yang diperlukan dalam XP . Kent Beck menyatakan bahwa tujuan jangka pendek individu sering berbenturan dengan tujuan sosial jangka panjang. Karena itu dibuatlah values yang menjadi aturan, hukuman, dan juga penghargaan. Keempat values tersebut adalah :

·                     communication

·                     simplicity

·                     feedback

·                     courage

Communication: (Komunikasi) Komunikasi menekankan pada pendekatan yang lebih menekankan pada orang per orang secara langsung, dimana hal tersebut akan lebih baik daripada hanya berdasarkan pada dokumen yang menjelaskan tentang software yang dibangun. Dan juga, kemungkinan penggunaan dari beberapa parktis XP sehingga dibutuhkan alokasi waktu yang banyak untuk berkomunikasi dengan costomer.

Simplicity: (Kesederhanaan) Simplicity adalah sebuah nilai (value) dari XP yang digunakan untuk

memberikan solusi dari problem atau permasalahan yang dihadapi oleh customer sehingga problem

atau masalah tersebut bisa disederhanakan. Kedua pihak yaitu pengembang (developer) dan pemesan(customer) bisa mengerti solusi software jika itu tidak nyata, dimana solusi tersebut merupakan kandidat untuk praktis yang lain yang disebut dengan Refactoring (salah satu inti dari praktis XP). Yang pasti, Simple Design (salah satu inti dari praktis XP) merupakan sebuah paktis yang memberikan kontribusi bagi nilai Simplicity.

Feedback: berarti bahwa segala sesuatu yang telah dilakukan atau dicapai dievaluasi dengan respect/ reaksi untuk mengetahui bagaimana agar pekerjaan tersebut berjalan dengan baik dan menghasilkan software yang sesuai dengan kebutuhan customer. Pernyataan Bagaimana agar pekerjaan tersebut berjalan dengan baik mengindikasikan bahwa feedback diperoleh dari evaluasi setiap bagian pekerjaan dari solusi. Feedback, yang merupakan hasil kerja dari Nyquist di Laboratorium Bell pada awal tahun 1930, digunakan untuk menjamin bahwa solusi tersebut adalah benar. Pada saat engineers(insinyur) mulai mempelajari feedback, hal tersebut telah menjadi salah satu jalan dalam mencari solusi dari suatu masalah.

Courage: berarti bahwa pihak pengembang mempersiapkan segala sesuatunya untuk membuat keputusan yang sangat penting yang mendukung praktis XP pada saat membangun dan merelis(meluncurkan) software kepada customer untuk masing-masing iterasi. Hal ini sangat menentukan untuk melihat apakah hasil dari suatu iterasi tersebut sudah sesuai dengan requirement (permintaan), bila ternyata hal tersebut belum sesuai maka pihak developer akan meminta waktu untuk meninjau kembali modul modul yang telah dibuat guna melakukan penyesuaian. Ada 2 jalan penting yang bisa ditempuh oleh tim developer dalam meluncurkan small releases, yaitu : Pertama, tim akan menjalankan releases tersebut, melakukan pengujian terhadap perangkat lunak, dan mengirimkan nilai bisnis yang telah dipilih oleh customer, untuk setiap iterasinya. Customer bisa menggunakan perangkat lunak ini untuk tujuan lain, apakah akan dievaluasi atau akan dilepas kepada end user. Aspect yang paling penting adalah bahwa perangkat lunak tersebut ada, dan diberikan kepada customer, pada akhir setiap iterasi. Kedua, Tim developer XP melepaskan release ke end user. Web project XP diluncurkan setiap hari, di dalam software house setiap bulan atau lebih sering lagi. 

2.3. Siklus Hidup Pada Extreme Programming

Extreme Programing dimunculkan untuk menangani perubahan-perubahan yang biasanya sering terjadi
pada saat pengembangan berlangsung bahkan pada saat proses pengembangan sudah hampir berakhir. Selain itu XP juga dimunculkan untuk mengatasi berbagai requirements yang tidak jelasdari user. Sebagai sebuah metodologi untuk mengembangkan peragkat lunak XP tentu memiliki siklus hidup. Siklus hidup pada XP ini terdapat lima fase yaitu :

1.            Exploration Phase 

2.            Planning Phase 

3.            Iteration to Release Phase 

4.            Productionizing Phase 

5.            Maintenance Phase

6.            Death Phase

2.4. Aspek Dasar Extreme Programming

Extreme Programmning adalah suatu bentuk pembangunan perangkat lunak yang berbasis nilai kemudahan, komunikasi, umpan balik, dan keberanian. Bekerja dalam whole team bersama-sama dengan praktek yang mudah. Dalam Extreme Programming terdapat 12 practices utama yaitu :

·   Planning Game

·   Small Releases

·  Metaphor

·  Testing

·   Refactorin

·   Pair Programming

·   Collective Ownershi 

·   Continuous Integration

·   40-hour week

·   On-site Customer

·   Coding Standard

Planning: Process , kadang-kadang disebut dengan Planning Game . Planning Process mengijinkan

extreme programming " pelanggan" untuk menggambarkan nilai bisnis itu dari corak yang diinginkan,

dan perkiraan biaya penggunaan yang disajikan oleh para programmer, untuk memilih apa yang perlu untuk dilaksanakan dan apa yang perlu untuk ditunda. Efek dari proses perencanaan extreme programming adalah bahwa mudah untuk mengemudi proyek itu ke arah sukses. extreme programming perencanaan menunjuk dua pertanyaan kunci di dalam pengembangan software: penggambaran kesimpulan apa yang akan terpenuhi oleh tanggal jatuh tempo, dan menentukan harus berbuat apa berikutnya. Penekanan adalah pada Pengendalian proyek yang mana adalah secara langsung dibanding pada perencanaan yang tepat dari apa yang akan diperlukan dan berapa lama itu akan diperlukan yang dalam hal ini cukup sulit. Ada dua langkah-langkah perencanaan kunci di (dalam) extreme programming, menujukan dua pertanyaan,pada pertanyaan yang pertama yaury Release Planning adalah suatu praktek di mana Pelanggan memberikan corak yang diinginkan kepada para programmer, dan para programmer menaksir kesukaran mereka. Dengan biaya-biaya yang telah ditaksir, dan dengan pengetahuan pentingnya corak, Denah Pelanggan suatu rencana untuk proyek itu. Release Planning Awal perlu jelas: bukan prioritas maupun perkiraan sungguh-sungguh padat, dan sampai regu mulai untuk bekerja, kita tidak akan mengetahui sekedar bagaimana cepat mereka akan melakukannya. Bahkan Release Planning yang pertama adalah yang cukup akurat untuk pengambilan keputusan, bagaimanapun, dan extreme programming regu meninjau kembali Release Planning itu secara teratur. Pertanyyan kedua yaitu Iteration Planning adalah praktis dengan mana regu diberi arahan tiap pasang dalam mingguan. XP regu membangun perangkat lunak di dalam dua mingguan " Iteration Planning", pengiriman menjalankan perangkat lunak bermanfaat pada akhir Iteration Planning masing-masing. Selama Perencanaan Iteration Planning, Pelanggan memberikan corak itu yang diinginkan untuk dua minggu yang berikutnya . Para programmer masuk ke dalam tugas, dan menaksir biaya mereka ( pada suatu pendenda tingkat detil dibanding iteration Planning). yang didasarkan pada Jumlah pekerjaan memenuhi Iteration Planning yang sebelumnya, regu menandatangani kontrak untuk yang akan dikerjakan yang iteration Planning yang sekarang .

Small: Releases XP regu menaruh suatu sistem sederhana ke dalam produksi awal, dan membaharuinya dengan frekuensi suatu siklus yang sangat pendek. XP regu praktis small releases di dalam dua jalur yang penting yaitu : Pertama, regu releases yang menjalankan,pengujian perangkat lunak, nilai bisnis pengiriman yang terpilih oleh Pelanggan, tiap-tiap iteration. Pelanggan dapat menggunakan perangkat lunak ini untuk hal-hal lain, apakah evaluasi atau melepaskan ke pemakai akhir ( yang sangat direkomendasikan). Aspek yang paling utama adalah bahwa perangkat lunak adalah visible, dan diberikan kepada pelanggan, pada akhir tiap iteration. Segalanya dijaga terbuka dan terukur. Ke dua, XP regu melepaskan kepada pemakai akhir mereka yang sering juga. XP Web merancang release setiap kali sehari-hari, di dalam house projects bulanan atau lebih. Bahkan produk shrink-wrapped dikirimkan setiap kali triwulanan.

Metaphor: XP regu menggunakan suatu yang]umum " system of names " dan suatu uraian sistem umum yang memandu pengembangan dan komunikasi. Regu Extreme Programming kembangkan suatu visi yang umum bagaimana program bekerja, yang kita sebut " metaphor". Paling baik nya , metaphor adalah suatu uraian yang membangkitkan ingatan sederhana bagaimana program bekerja, seperti " program ini bekerja seperti suatu sarang lebah, perjalanan tepung sari berusaha untuk dan mengembalikan kepada sarang" sebagai uraian untuk suatu sistem pengembalian informasi agentbased. Kadang-Kadang suatu metaphor yang puitis tidak muncul. Setidak-Tidaknya, dengan atau tanpa perumpamaan hidup, XP regu menggunakan suatu sistem yang umum menyebut untuk menjadi yakin bahwa semua orang memahami bagaimana pekerjaan sistem dan di mana untuk menantikan temukan kemampuan itu kamu sedang mencari, atau untuk temukan sasaran yang tepat itu untuk menaruh kemampuan itu kamu mulai menambahkan.

Simple: Design Suatu program membangun dengan XP harus merupakan program yang paling sederhana yang menyesuaikan dengan kebutuhan yang sekarang itu. Adalah tidak banyak bangunan " untuk masa depan". Sebagai gantinya, fokus adalah untuk menyediakan nilai bisnis. Tentu saja itu adalah diperlukan untuk memastikan bahwa kamu mempunyai suatu disain baik, dan di dalam XP ini adalah disempurnakan melalui " refactoring". Disain XP bukanlah hal yang dilakukan suatu waktu saja, atau suatu hal yang dibuat sekali saja, itu adalah suatu all-the-time hal. Ada langkah-langkah disain di dalam release planning dan iteration planning, regu lebih terlibat dalam sesi disain cepat dan revisi disain melalui refactoring, melalui keadaan itu keseluruhan proyek. Di dalam suatu incremental, iterative memproses seperti Extreme Programming, disain baik adalah penting. itu adalah mengapa banyak fokus pada disain sepanjang seluruh keadaan itu adalah keseluruhan pengembangan.

Testing: regu memusatkan pada pengesahan perangkat lunak terus menerus. Para programmer mengembangkan perangkat lunak dengan penulisan test dulu, kemudian perangkat lunak yang memenuhi kebutuhan itu mencerminkan test itu. Pelanggan menyediakan test penerimaan yang memungkinkan mereka pastinya bahwa corak yang mereka kebutuhan disajikan. Extreme Programming dipengaruhi dengan umpan balik, dan di dalam pengembangan software, umpan balik baik memerlukan pengujian baik. Top Xp Regu praktis " test-driven development", bekerja siklus yang sangat pendek dengan menambahkan suatu test, kemudian pembuatan itu bekerja. Hampir sebagian kecil, regu menghasilkan kode dengan pemenuhan hampir 100 persen menguji , yang mana adalah suatu langkah maju dalam pembuatan perangkat lunak. ( Jika para programmer mu telah melakukan lebih pengujian canggih lagi , lebih kuat kepada kamu. Lanjutkan atau jaga, itu hanya dapat membantu!) Itu bukan cukup untuk menulis test: kamu harus menjalankannya. Di sini, juga, Extreme Programming adalah ekstrim. Ini " test programmer", atau " test unit" adalah semua dikumpulkan bersama-sama, dan setiap kali manapun programmer melepaskan manapun kode kepada tempat penyimpanan ( dan memasangkan secara khas melepaskan dua kali suatu hari atau lebih ), tiap-tiap tunggal salah satu dari programmer test harus menjalankan dengan tepat. Seratus persen, sejak semula! makna ini yang para programmer mendapatkan umpan balik segera pada bagaimana mereka adalah yang melakukan. Apalagi, test ini menyediakan pendukungan tidak ternilai sebagai disain perangkat lunak ditingkatkan.

Refactoring: XP regu meningkatkan perancangan sistem sepanjang keseluruhan pengembangan. Ini

adalah dilaksanakan dengan pemeliharaan perangkat lunak dan membersihkannya: tanpa duplikasi, dengan komunikasi tinggi, sederhana, namun lengkap. The refactoring process memusat pada kepindahan duplikasi ( suatu tanda dari disain lemah atau kurang), dan pada meningkatkan " kohesi" tentang kode, selagi menurunkan " penggabungan". Kohesi tinggi dan penggabungan rendah telah dikenali ketika tanda dari kode dirancang dengan baik untuk sedikitnya tiga puluh tahun. Hasilnya adalah bahwa XP regu mulai dengan suatu disain sederhana yang baik, dan selalu mempunyai suatu

disain yang sederhana tetapi baik untuk perangkat lunak itu. Ini mendukung kecepatan pengembangan mereka, dan sesungguhnya biasanya meningkatkan kecepatan sebagai proyek kedepannya.

Pair: Programming Programmer XP menulis semua kode produksi berdua, dua programmer bekerja

bersama dalam satu mesin. Pasangan Programming telah ditunjukkan oleh banyak eksperimen untuk menghasilkan perangkat lunak lebih baik yang serupa atau menurunkan biaya dibanding para programmer bekerja sendiri. Semua perangkat lunak produksi di dalam XP dibangun oleh dua para programmer, duduk berdampingan, di mesin yang sama . Praktis ini memastikan bahwa semua kode produksi ditinjau oleh sedikitnya satu programmer yang lain, dan mengakibatkan disain lebih baik, lebih baik pengujiannya, dan kode lebih baik. Beberapa programmer menolak untuk memasangkan programming tanpa pernah berusaha. Itu mengambil beberapa keuntungan dengan baik, dan kamu memerlukan melakukan itu baik bagi beberapa minggu untuk lihat hasilnya . Sembilan puluh persen para programmer yang belajar berpasangan yang memprogram menyukai itu, maka kita sangat merekomendasikannya kepada semua regu. Memasangkan, sebagai tambahan terhadap menyediakan kode lebih baik dan test, juga melayani untuk komunikasi pengetahuan terhadap seluruh regu. Seperti memasangkan tombol, semua orang mendapat keuntungan-keuntungan dari orang yang memiliki pengetahuan khusus. Para programmer belajar, ketrampilan mereka meningkat, mereka menjadi bergerak ke arah yang lebih baik kepada regu dan kepada perusahaan itu. Memasangkan, bahkan pada di luar sendiri XP, adalah suatu kemenangan besar untuk semua orang.

Collective: Ownership Semua kode kepunyaan semua para programmer itu. Ini menyebabkan regu itu bergerak secepat-cepatnya, sebab ketika sesuatu yang dibutuhankan berubah, itu dapat diubah dengan segera. Pada suatu proyek Extreme Programming , pasangan dari programmer dapat meningkatkan kode apapun pada setiap waktu. makna ini bahwa semua kode mendapatkan manfaat dari banyak perhatian dari semua orang, yang meningkatkan kode yang berkwalitas dan mengurangi cacat. Ada manfaat penting yang lain juga: kapan kode dimiliki oleh individu, corak yang diperlukan adalah sering disalahkan tempat, ketika satu programmer menemukan bahwa ia memerlukan suatu corak di suatu tempat di dalam kode yang ia tidak memiliki. Pemilik adalah terlalu sibuk untuk melakukannya, sehingga programmer menaruh corak itu di dalam kode miliknya, dimana itu bukan dari bagiannya. Ini mengarahkan ke arah yang buruk, hard-to-maintain kode, penuh dengan duplikasi dan dengan rendah ( tidak baik) kohesi.

Continuous: Integration XP regu mengintegrasikan dan membangun sistem perangkat lunak itu berulang kali per hari. Ini menampung para programmer itu pada halaman yang sama, dan memungkinkan kemajuan yang sangat cepat. Mungkin permasalahannya, mengintegrasikan lebih sering cenderung untuk menghapuskan permasalahan pengintegrasian.hal itu mempengaruhi regu yang mengintegrasikan lebih sedikit.

40-hour: Week Kelelahan dari Para programmer dikhawatirkan membuat banyak kesalahan . XP regu tidak bekerja lembur berlebihan, untuk menjaga diri mereka agar tetap konsentrasi, sehat, dan efektif.

On-site: Customer Suatu XP proyek yang dijalankan oleh suatu individu dilakukan untuk menentukan kebutuhan, menetapkan prioritas, dan pertanyaan jawaban ketika para programmer mempunyai hal itu. Efeknya menjadi ada komunikasi yang meningkatkan, dengan lebih sedikit hard-copy dokumentasisering salah satu dari yang paling mahal bagian-bagian dari suatu proyek perangkat lunak.

Coding: Standard Karena suatu regu untuk bekerja secara efektif secara berdua, dan untuk berbagi kepemilikan dari semua kode, semua para programmer harus tulis kode itu dengan cara yang sama, dengan aturan yang meyakinkan kode itu dapat dikomunikasikan dengan jelas. 

2.5. Akti tas Requirement

Requirements Elicitation Adalah proses mengumpulkan dan memahami requirements dari user. Kadang masalah yang muncul berakar dari gap masalah knowledge domain (perbedaan disiplin ilmu yang dimiliki). Customer adalah expert pada domain yang softwarenya ingin dikembangkan (domain specialist), dilain pihak sang pengembang (requirements analyst) adakalanya sama sekali buta terhadap knowledge domain tersebut, meskipun tentu memahami dengan benar bagaimana sebuah software harus dikembangkan. Gap knowledge domain tersebut yang diharapkan bisa diatasi dengan adanya interaksi terus menerus dan berulang (iterasi) antara pengembang dan customer. Proses interaksi tersebut kemudian dimodelkan menjadi beberapa teknik dan metodologi diantaranya adalah interviewing, brainstorming, prototyping, use case, dsb.

Requirements Speci cation Setelah masalah berhasil dipahami, pengembang mendeskripsikannya dalam bentuk dokumen spesi kasi dokumen. Spesi kasi ini berisi tentang tur dan fungsi yang diinginkan oleh customer, dan sama sekali tidak membahas bagaimana metode pengembangannya. IEEE mengeluarkan standard untuk dokumen spesi kasi requirements yang terkenal dengan nama IEEE

Recommended Practice for Software Requirements Speci cations [IEEE-830]. Dokumen spesi kasi requirements bisa berisi functional requirements, performance requirements, external interface requirements, design constraints, maupun quality requirements.

Requirements Validation and Veri cation Setelah spesi kasi requirements berhasil dibuat, perlu dilakukan dua usaha: Validation (validasi), yaitu proses untuk memastikan bahwa requirements yang benar sudah ditulis. Veri cation (veri kasi), yaitu proses untuk memastikan bahwa requirements sudah ditulis dengan benar. Proses validasi dan veri kasi ini melibatkan customer (user) sebagai pihak yang menilai dan memberi feedback berhubungan dengan requirements.

Tujuan Requirement:

·                     Menetapkan dan menjaga kesepakatan dengan customer dan stakeholder lain tentang apa yang harus dilakukan oleh system

·        Untuk memberikan pemahaman yang lebih baik kepada pengembang system tentang kebutuhan system

·                     Menetapkan batasan system

·                     Untuk menyediakan dasar perencanaan teknis

·                     Untuk menyediakan dasar perkiraan biaya dan waktu pengembangan system

·                     Untuk mende nisikan user interface system

Sering terjadi salah kaprah dalam Requirement Engineering (RE), mereka terlalu menyederhanakan RE, mereka beranggapan bahwa RE dimulai dari bertanya pada stakeholder tentang keinginan mereka (requirement elicitation), mempelajari hasilnya hingga dimengerti (requirement analysis), menulis kebutuhan ke dalam dokumen (requirement speci cation), dan bertanya pada custumer apakah yang dikerjakan sudah benar (requirement validation). Namun sayangnya, yang dilakukan diatas tersebut belum tentu benar, karena keempat hal tersebut adalah pekerjaan(tasks), bukan urutan yang sequensial, Kesalahpahaman tersebut dapat menjurus kedalam ketidak lengkapan serta ketidak suksesan proyek. Dalam tulisan ini kedepan akan dibahas tentang pengenalan dari semua pekerjaan utama dalam RE. Kekompakan dalam tim RE harus dipastikan diawal, setiap anggota tim harus bisa saling bekerja sama secara efektif. Komposisi tim pun harus diperhitungkan dari background yang bisa berhubungan dengan stakeholder serta mampu memperhitungkan feasibilitas dari sebuah requirement. Ada beberapa pekerjaan RE yang bisa dilakukan untuk memperoleh RE sesuai yaitu

BUSINESS: ANALYSIS Menganalisa context dari bisnis yang akan dikembangkan sistemnya. Terdiri

atas beberapa proses : Analyze the customer organization's business enterprise, Analyze the competitor organizations, Analyze current and potential/planned marketplace, Analyze critical technologies, Analyze current and intended future user communitie, Analyze the stake holder, dan Develop a business case.

VISIONING: Bersama stakeholder menghasilkan visi dari sistem baru yang akan dikembangkan. Mulai dari menentukan misi, masalah dalam bisnis dan kesempatan, kebutuhan dari stakeholder, tujuaan serta fungsionalitas selain itu juga batasan-batasannya.

REQUIREMENTS: IDENTIFICATION Mengidenti kasikan requirement yang potensial. Prosesnya terdiri atas identify sources of requirement,elicit needs, goals, desires, and requirement, gather potential requirement, invent new requirement transform stakeholder desires, expectation, and needs into informal, textual, potential requirement.

REQUIREMENTS: REUSE Mengunakan ulang semua atau sebagian requirement yang sudah ada Melibatakan beberapa proses yaitu mengidenti kasikan requiremen yang potensial untuk di reusable, mengevaluasi requirement yang relevan, menyesuaikan requirement agas sesuai dengan kebutuhan, mengunakan requirement yang telah disesuaikan.

REQUIREMENT: ANALYSIS Tim RE menganalisa requirement yang telah diidenti kasi dan requirement yang digunakan kembali. Pekerjaan yang harus dilakukan adalah Study, categorize, decompose and organize , model, quantify, re ne, prioritize, justify, and trace each requirement, transform informal tekstual requirement, negotiate the prioritization of requirement, verify, transform potential raw requirement, ensure the requirement well unsterstood.

REQUIREMENTS: PROTOTYPING Menciptakan RE Prototypes, meliputi pembuatan satu atau

lebih prototype, mengevaluasinya, dan mengunakan prototype tersebut.

REQUIREMENT: SPECIFICATION Membuat dan mempublikasi requirement yang telah dianalisa dan divalidasi dalam bentuk dokumen, langkah-langkahnya meliputi menciptakan dokumen, mendistribusikannya serta memperbaiki jika terdapat feedback terhadap dokumen tersebut.

REQUIREMENT: MANAGEMENT Mengelola semua kebutuhan, meliputi Record and store the requirement, control acess (CRUD) the requirement, negotiate with stakeholder, report the status, dan trace the requirement.

REQUIREMENT: VALIDATION Memvalidasi kebenaran dari requirement yang telah dianalisa bersama dengan stakeholder dan melakukan koreksi yang diperlukan. Meliputi identify a stakeholder to validate the requirement, ensure these stakeholder validate the correctness of the requirement, iterate to x requirement problem, certify an acceptable requirement.Terdapat tiga pekerjaan yang secara teknik dan logika dipunyai oleh bidang lain, namun sangat kritikal terhadap kesuksesan RE, adalah Scope Management, Requirement Veri cation , Requirement Con guration Control. RE seharusnya tidak dianggap sebagai fase awal dalam Waterfall development cycle. RE harusnya dilakukan dalam iterative, incremental, concurrent , dan time-box. Iterative dalam arti pekerjaan RE biasanya perlu dilakukanperulangan untuk memperbaiki kekurangan dan membuat peningkatan, incremental Karena dalam pembuatan sistem yang besar sangat sulit membuat requirement yang lengkap dan benar pada permulaan proyek, sehingga baiknya dilakukan dengan metode top-down, dan layer by layer.Concurrent berarti RE dilaksanakan bersamaan dengan disiplin yang lain. Time-boxed berarti penyelesaian RE tetap harus dijadwalkan.

2.6. Modeling Proses Extreme Programming

Proses Perangkat Lunak Simulasi menjadi semakin populer dikomunitas rekayasa perangkat lunak , baik di kalangan akademisi dan praktisi. Bahkan teknik rekayasa perangkat lunak baru dan inovatif yang terus dikembangkan, sehingga pemahaman yang lebih baik dari ini berguna untuk menilai efektivitas dan memprediksikemungkinan masalah . simulasi dapat memberikan informasi tentang masalah untuk menghindari eksperimendunia nyata . Perangkat lunak simulasi telah menarik minat yang tumbuh selama dua puluh tahun terakhir, tetapi hanya baru-baru ini itu mulai digunakan untuk mengatasi beberapa isu mengenai manajemen strategis pengembangan perangkat lunak dan mendukung proses perbaikan. Hal ini juga dapat membantu manajer proyek dan insinyur untuk rencana perubahan dalam proses pembangunan . Pengembangan model simulasi adalah cara yang relatif murah dibandingkan dengan bereksperimen dengan proyek perangkat lunak yang sebenarnya, dari pengumpulan informasi ketika biaya, risiko dan kompleksitas sistem nyata yang sangat tinggi .Dalam rangka untuk menghubungkan hasil dunia nyata untuk hasil simulasi , biasanya untuk menggabungkan temuan empiris dan pengetahuan dari proses nyata. Secara umum data empiris digunakan untuk mengkalibrasi model dan hasil dari proses simulasi yang digunakan untuk perencanaan , desain dan analisis eksperimen nyata .Beberapa konsep utama harus dijelaskan agar memiliki pemahaman yang lebih baik di daerah ini , terutama model dan model simulasi. Model adalah abstraksi konseptual sistem yang kompleks . Sebuah model dirancang untuk menampilkan signi kan tur dan karakteristik sistem , yang satu keinginan untuk belajar , memprediksi, memodi kasi , atau kontrol. Jadi model mencakup beberapa tapi tidak semua aspek sistem yang dimodelkan . Model simulasi adalah model komputer yang memiliki karakteristik yang dijelaskan di atas dan yang mewakili beberapa sistem dinamis atau fenomena. Salah satu motivasi utama untuk mengembangkan model simulasi atau menggunakan metode pemodelan lain adalah bahwa hal itu cara murah untuk mendapatkan wawasan penting ketika biaya, risiko atau logistik memanipulasi nyata sistem bunga yang mahal .

2.7. Penggunaan Umum Dari Pemodelan Simulasi

tujuan model simulasi adalah untuk memberikan dasar untuk eksperimen , memprediksi perilaku , menjawab pertanyaan , mengajarkan tentang sistem yang dimodelkan . Model proses simulasi perangkat lunak berfokus pada beberapa perangkat lunak pembangunan atau pemeliharaan atau evolusi proses tertentu, hal ini dapat mewakili proses tersebut seperti yang diterapkan atau seperti yang direncanakan untuk pelaksanaan di masa depan. Karena semua model adalah abstraksi , model hanya mewakili beberapa dari aspek dari proses perangkatn lunak yang berpotensi dapat dimodelkan yaitu yang diyakini oleh model pengembang menjadi sangat relevan dengan isu-isu dan pertanyaan model digunakan untukalamat . Ada berbagai alasan untuk melakukan simulasi perangkat lunak model proses . Dalam banyak kasus simulasi adalah bantuan untuk pengambilan keputusan juga membantu dalam pengurangan risiko , dan membantu manajemen di strategis, taktis ,dan tingkat operasional .

Perencanaan: perencanaan simulasi dapat mendukung perencanaan pengelolaan di sejumlah cara langsung, termasuk :

·                     Prakiraan usaha / biaya, jadwal, dan kualitas produk

·                     Tingkat staf perkiraan dibutuhkan sepanjang waktu

·                     Mengatasi keterbatasan sumber daya dan alokasi sumber daya

·                     Merkiraan tingkat layanan yang disediakan (misalnya, untuk dukungan produk)

·                     Menganalisis risiko. 

Semua ini dapat diterapkan untuk kedua perencanaan awal dan selanjutnya kembali perencanaan. Simulasi juga dapat digunakan untuk membantu memilih, menyesuaikan, dan menyesuaikan proses terbaik untuk konteks proyek tertentu.Hal ini adalah proses perencanaan masalah.

Kontrol: dan Manajemen Operasional Simulasi dapat memberikan dukungan yang efektif untuk pengendalian manajerial dan manajemen operasional. Simulasi dapat memfasilitasi proyek pelacakan dan pengawasan karena kunci parameter proyek (misalnya, status yang sebenarnya dan kemajuan di produk kerja, konsumsi sumber daya, dan sebagainya) dapat dipantau dan dibandingkan terhadap nilai-nilai yang direncanakan dan dihitung dengan simulas, hal ini dapat membantu manajer proyek menentukan kapan kemungkinan tindakan korektif dapatdiperlukan. Manajer proyek juga dapat

menggunakan simulasi untuk mendukung keputusan operasional, seperti coding dan pengujian integrasi. Untuk melakukan hal ini, manajer akan mengevaluasi status proyek saat ini menggunakan data proyek yang sebenarnya dan menggunakan simulasi untuk memprediksi hasil jika tindakan yang diusulkan ditunda.

Proses: perbaikan dan Adopsi Teknologi dapat mendukung perbaikan proses dan adopsi teknologi dalam berbagai cara. Dalam pengaturan proses perbaikan , organisasi sering dihadapkan dengan banyak yang menyarankan perbaikan simulasi dapat membantu proses tertentu. Aplikasi ini menggunakan simulasi apriori untuk membandingkan alternatif proses , dengan hasil proyeksi yang penting bagi pengambil an keputusan contohnya: biaya , siklus waktu , dan kualitas yang dihasilkandari model simulasi proses alternatif .Simulasi juga dapat digunakan ex post untuk mengevaluasi hasil perubahan proses atau seleksi sudah dilaksanakan . Di sini hasil aktual yang diamati akan dibandingkan dengan simulasi proses tidak dipilih , setelah memperbarui simulasi yang mencerminkan proyek yang sebenarnya karakteristik yang terlihat misalnya ukuran , keterbatasan sumber daya . Hasil yang sebenarnya juga akan digunakan untuk mengkalibrasi model proses yang digunakan , untuk meningkatkan aplikasi masa depan model tersebut. Sama seperti organisasi menghadapi banyak pertanyaan perbaikan proses dan keputusan , hal yang sama berlaku untuk adopsi teknologi. Analisis memasukkan teknologi baru ke dalam proses pengembangan perangkat lunak atau bisnis proses akan mengikuti pendekatan yang sama seperti untuk proses perubahan dan mempekerjakan model dasar yang sama . Hal ini terutama karena adopsi baru teknologi umumnya diharapkan mempengaruhi hal yang biasanya pantulan sebagai parameter masukan untuk coding tingkat produktivitas dan untuk mengubah proses terkait dengan cara yang lebih mendasar lainnya . tentang proses perangkat lunak dalam beberapa cara.

Memahami: Simulasi dapat mempromosikan pemahaman yang disempurnakan banyak masalah proses. Sebagai contoh, model simulasi dapat membantu seorang manajer proyek, pengembang perangkat lunak, dan personil jaminan kualitas lebih memahami aliran proses yaitu sequencing, paralelisme, arus produk kerja, simulasi animasi, gra k Gantt, dan sejenisnya yang berguna dalam menyajikan hasil simulasi untuk membantu orang memvisualisasikan masalah aliran proses tersebut. Simulasi juga dapat membantu orang untuk memahami dampak dari loop umpan balik yang kompleks dan penundaan yang melekat dalam proses perangkat lunak, perangkat lunak profesional bahkan mengalami memiliki kesulitan memproyeksikan efek ini sendiri karena rumit interaksi dari waktu ke waktu. Selain itu, model simulasi dapat membantu peneliti untuk mengidenti kasi dan memahami konsisten, sifat meresap pengembangan perangkat lunak dan proses pemeliharaan. Selain itu simulasi dapat membantu orang memahami ketidak pastian yang melekat dalam perangkat lunak dan kemungkinan variabilitas dalam hasil aktual terlihat. Akhirnya , simulasi membantu.

Pelatihan: dan belajar Simulasi dapat membantu dengan pelatihan dan pembelajaran tentang proses

perangkat lunak dalam beberapa cara . Meskipun tujuan ini terkait dengan pemahaman, pengaturan tertentu dibayangkan di sini adalah salah satu yang secara eksplisit instruksional. Simulasi memberikan cara untuk personil untuk berlatih / belajar manajemen proyek, contohnya adalah analog dengan pilot berlatih di simulator penerbangan . Sebuah lingkungan simulasi dapat membantu management trainee mempelajari kemungkinan dampak keputusan umum atau misalnya, bergegas ke coding, melompat-lompat inspeksi , atau mengurangi waktu pengujian . Akhirnya , pelatihan melalui partisipasi dalam simulasi dapat membantu orang untuk menerima tidak dapat diandalkan dalam harapan awal mereka tentang hasil yang diberikan tindakan, sebagian orang tidak memiliki keterampilan yang baik atau kemampuan melekat untuk memprediksi perilaku sistem dengan loop umpan balik yang kompleks dan ketidakpastian (seperti yang hadir dalam proses perangkat lunak ) . Secara keseluruhan , partisipasi aktif dalam campuran yang baik dari simulasi dapat memberikan kesempatan belajar yang bisa dinyatakan hanya diperoleh melalui pengalaman bertahun-tahun di dunia nyata.

2.8. Teknik simulasi dan pendekatan

Selama desain dan implementasi simulator , berbagai teknik dan strategi dapat diadopsi untuk model

perilaku sistem yang diberikan. Tergantung pada sistem yang akan disimulasikan , beberapa teknik mungkin lebih menguntungkan daripada yang lain . Faktor-faktor termasuk tingkat abstraksi dan akurasi yang diinginkan dan kecepatan simulasi harus dipertimbangkan ketika merancang mesin simulator . Secara tradisional , simulator dirancang baik menggunakan teknik kontinyu atau kejadian diskrit untuk mensimulasikan diberikan sistem. Hal ini berguna untuk mengklasi kasikan sistem yang disimulasikan ke dalam dua kategori terpisah tergantung pada tingkat keacakan terkait dengan perilaku sistem dalam lingkungan simulasi nya . Sebuah sistem yang sangat bergantung pada perilaku acak disebut sebagai sistem stokastik . Sebaliknya, sistem simulasi deterministik menggabungkan sekali tidak perilaku acak apapun . Dengan demikian , hasil simulasi untuk himpunan input akan selalu identik. Dengan waktu simulasi terus menerus dikendalikan oleh variabel continue dinyatakan sebagai persamaan diferensial selama simulasi perangkat lunak akan mengintegrasikan persamaan . Pendekatan yang lebih populer untuk simulasi dalam waktu cara Continue Dinamika Sistem pemodelan . Bidang ini diperkenalkan oleh JW Forreste dan menerapkan prinsip prinsip rekayasa umpan balik dan kontrol untuk sistem sosial. Abdel dan Hamid adalah orang pertama yang menggunakan dinamika sistem pemodelan proses perangkat lunak manajemen proyek. Dalam dinamika sistem sistem dide nisikan sebagai kumpulan elemen yang terus berinteraksi satu sama lain dan unsur-unsur luar dari waktu ke waktu untuk membentuk suatu kesatuan yang utuh. Dua elemen penting dari sistem ini adalah struktur dan perilaku . Struktur dide nisikan sebagai kumpulan komponen dari sistem dan hubungan. Struktur sistem juga mencakup variabel yang penting dalam mempengaruhi sistem. Perilaku disini dide nisikan sebagai cara di mana unsur-unsur atau variabel menyusun sistem bervariasi dari waktu ke waktu. Dinamika sistem model menggambarkan sistem dalam hal " arus " yang terakumulasi dalam berbagai " level " . Arus dapat berfungsi dinamis atau dapat merupakan konsekuensi lain " tambahan " variabel . Sebagai kemajuan simulasi waktu kecil bertahap merata spasi itu menghitung perubahan tingkat dan laju aliran . Sebagai contoh, tingkat kesalahan generasi dapat diperlakukan sebagai " aliran " dan saat ini jumlah kesalahan dapat diperlakukan sebagai " tingkat " . Hal ini memungkinkan model untuk menangkap stabilitas atau instabilitas loop umpan balik . Sebuah sistem Model dinamika dapat berharga dalam mencari tingkat di mana model dapat menjadi tidak stabil , atau dalam memprediksi efek samping yang tak terduga dari perubahan dalam variabel sistem. Sementara model dinamika sistem adalah cara terbaik untuk menggambarkan perilaku variabel proyek , itu adalah cara yang lebih sulit untuk menggambarkan proses langkah . Meskipun dimungkinkan untuk mewakili kegiatan diskrit dalam dinamika sistem Model , sifat alat menyiratkan bahwa semua tingkatan berubah setiap waktu, teknik simulasi dan pendekatan Interval . Jika proses berisi kegiatan sekuensial , beberapa mekanisme harus ditambahkan untuk mencegah semua kegiatan dari pelaksana sekaligus. Sebagai contoh, jika kita model proses perangkat lunak sebagai kegiatan uji mende nisikan , desain, kode , dan sebagai begitu beberapa kode dide nisikan , desain akan mulai . Jika kita ingin model proses yang menyelesaikan semua pekerjaan desain sebelum coding dimulai , kita akan memiliki untuk menciptakan suatu mekanisme eksplisit untuk mengontrol sequencing. Karena model dinamika sistem berurusan dengan aliran dan tingkat ada entitas individu dan dengan demikian tidak ada atribut entitas . Untuk proses perangkat lunak Model ini berarti bahwa semua modul dan semua pengembang sama. Akhirnya suatu model dinamika sistem tidak mudah memungkinkan untuk model ketidakpastian yang melekat dalam perkiraan parameter model. Jika kita memperkirakan bahwa coding setiap modul akan mengambil dari 3 sampai 6 minggu , kita harus menerjemahkan memperkirakan bahwa dalam tingkat coding setara. Sebuah model diskrit bisa sampel dari distribusi menggunakan waktu yang berbeda untuk setiap modul . sistem Model dinamika baik harus mencicipi tingkat di setiap langkah waktu atau harus menggunakan tingkat yang sama untuk masing-masing model run. 

2.10. Peristiwa Terpisah Simulasi

Simulasi kejadian diskrit melibatkan pemodelan sistem seperti itu berlangsung melalui waktu dan sangat berguna untuk menganalisis sistem antrian. Dengan demikian sistem yang umum dalam lingkungan manufaktur dan jelas bekerja dalam kemajuan, penyangga saham , dan bagian gudang . Kekuatan utama dari simulasi kejadian diskrit adalah kemampuan untuk Model dan untuk memprediksi efek dari interaksi yang kompleks antara peristiwa ini . Eksperimen biasanya dilakukan dengan menggunakan perangkat lunak Model untuk menjawab pertanyaan . Hal ini dicapai dengan mengubah input untuk model dan kemudian membandingkan hasil . Jenis simulasi terutama alat pendukung keputusan . Di dalam perangkat lunak atau model akan menjadi sejumlah konsep penting , yaitu entitas dan pernyataan logika . Entitas adalah unsur yang berwujud ditemukan di dunia nyata , misalnya untuk pembuatan ini bisa mesin atau truk . Entitas dapat berupa sementara (misalnya bagian yang melewati model ) atau permanen ( misalnya mesin yang tetap dalam model ) . itu konsep temporer dan permanen adalah alat bantu yang berguna untuk memahami Tujuan keseluruhan menggunakan simulasi , biasanya untuk mengamati perilaku entitas sementara melewati ones.clock permanen dan eksekutif adalah bagian penting dari sebuah sistem simulasi mereka sangat mudah untuk melaksanakan dan sangat sederhana dalam perilaku . Hubungan logis menghubungkan entitas yang berbeda bersama-sama , misalnya bahwa badan mesin akan memproses entitas bagian . Hubungan logis adalah kunci bagian dari model simulasi , mereka menentukan perilaku keseluruhan model . Setiap pernyataan logis ( misalnya " menjalankan mesin jika bagian yang menunggu " ) sederhana tetapi kuantitas dan berbagai dan fakta bahwa mereka tersebar luas seluruh model menimbulkan kompleksitas . Bagian penting lain dari setiap sistem simulasi adalah simulasi eksekutif . Eksekutif bertanggung jawab untuk mengendalikan waktu sebelumnya . Sebuah pusat Jam digunakan untuk melacak waktu . Eksekutif akan mengontrol logis hubungan antara entitas dan memajukan jam untuk waktu yang baru . Eksekutif simulasi merupakan pusat untuk menyediakan dinamis , perilaku berbasis waktu model.

 

BAB 3

Tools Untuk Extreme Programming

3.1. Netbeans

NetBeans merupakan sebuah proyek kode terbuka yang sukses dengan pengguna yang sangat luas, komunitasyang terus tumbuh, dan memiliki hampir 100 mitra (dan terus bertambah!). Sun Microsystems mendirikanproyek kode terbuka NetBeans pada bulan Juni 2000 dan terus menjadi sponsor utama. Saat ini terdapat dua produk : NetBeans IDE dan NetBeans Platform. The NetBeans IDE adalah sebuah lingkungan pengembangan- sebuah kakas untuk pemrogram menulis, mengompilasi, mencari kesalahan dan menyebarkan program. Netbeans IDE ditulis dalam Java - namun dapat mendukung bahasa pemrograman lain. Terdapat banyak modul untuk memperluas Netbeans IDE. Netbeans IDE adalah sebuah produk bebas dengan tanpa batasan bagaimana digunakan. Tersedia juga NetBeans Platform; sebuah fondasi yang modular dan dapat diperluas yang dapat digunakan sebagai perangkat lunak dasar untuk membuat aplikasi desktop yang besar. Mitra ISVmenyediakan plug-in bernilai tambah yang dapat dengan mudah diintegrasikan ke dalam Platform dan dapatjuga digunakan untuk membuat kakas dan solusi sendiri. Kedua produk adalah kode terbuka (open source) dan bebas (free) untuk penggunaan komersial dan non komersial. Kode sumber tersedia untuk guna ulang dengan lisensi Common Development and Distribution License (CDDL) dan juga ada forum yang sangat terbuka bagi semua orang yang ingin mengetahui lebih dalam tentang netbeans itu sendiri. Forum terseebut beralamatkan netbeans.org. didalam forum tersbut juga terdapat fasilitas unduhan netbeans versi teranyar. Belajar tentang oarang-ornag yang terlibat dalam suatu proyek dan masi banyak lagi.apabila anda ingin mengunduh netbeans versi terbaru dapat diunduh alamat http://netbeans.org/downloads/

3.1.1. Sejarah Netbans. 

NetBeans dimulai pada tahun 1996 sebagai Xel (kata bermain pada Delphi), Java IDE proyek mahasiswa di bawah bimbingan Fakultas Matematika dan Fisika di Charles University di Praha . Pada tahun 1997 Stan¥k Romawi membentuk perusahaan sekitar proyek tersebut dan menghasilkan versi komersial NetBeans IDE hingga kemudian dibeli oleh Sun Microsystems pada tahun 1999. Sun open-source IDE NetBeans pada bulan Juni tahun berikutnya. Sejak itu, komunitas NetBeans terus berkembang.

3.1.2. Kelebihan Netbeans. 

Mendukung berbagai bahasa pemograman seperti java,C/C++,php, Berjalan pada multiplatform sistem operasi termasuk Windows, Linux, Mac OS, Solaris Berfungsi untuk pengembangan aplikasi mobile menggunakan bahasa Java Mendukung untuk pengembangan aplikasi web menggunakan PHP Mendukung permodelan perangkat lunak dengan UML(Uni ed Modeling Language) Terdapat banyak modul untuk mengembangkan lebih lanjut Merupakan produk free(baca:bebas) tanpa ada batasan penggunaannya

Merupakan produk open source (baca:kode sumber terbuka) Jika anda berminat menggunakan Netbeans IDE silahkan download disitus resminya http://netbeans.org/. Saat ini Netbeans IDE sudah mencapai versi 6.8. Bagi Anda pengguna Ubuntu Linux silahkan ikuti langkah-langkah berikut untuk mendownload Netbeans IDE6.8

3.1.3. Netbeans Versi.

·                     NetBeans IDE 6.0 memperkenalkan dukungan untuk mengembangkan modul IDE dan aplikasi klien kaya berdasarkan platform NetBeans, Java Swing GUI builder (sebelumnya dikenal sebagai "Proyek Matisse"), meningkatkan CVS dukungan,WebLogic 9 dan JBoss 4 dukungan, dan perangkat tambahan banyak editor. NetBeans 6 tersedia dalam repositori resmi dari distribusi Linux utama. 

·                     NetBeans IDE 6.5, dirilis pada bulan November 2008, diperpanjang yang ada Java EE tur (termasuk dukungan Kegigihan Java, EJB 3 dan JAX-WS). Selain itu, NetBeans Enterprise Pack mendukung pengembangan aplikasi Java EE 5 perusahaan, termasuk SOA alat desain visual, skema XML tools, web orkestrasi layanan (untuk BPEL), dan UML modeling. The NetBeans IDE Bundle untuk C / C + + mendukung C / C + + pembangunan

·                     NetBeans IDE 6.8 adalah IDE pertama untuk memberikan dukungan lengkap Java EE 6 dan GlassFish Enterprise Server v3 . Hosting pengembang sumber terbuka proyek di kenai.com tambahan manfaat dari instant messaging dan pelacakan masalah integrasi dan navigasi kanan dalam IDE, dukungan untuk pengembangan aplikasi web dengan PHP 5.3 dan kerangka Symfony, dan kode selesai diperbaiki, layout, petunjuk dan navigasi dalam proyek JavaFX. 

·                     NetBeans IDE 6.9, dirilis pada bulan Juni 2010, menambahkan dukungan untuk OSGi , Spring Framework 3.0, Java EE injeksi ketergantungan (JSR-299), Zend Framework untuk PHP , dan navigasi kode lebih mudah (seperti "Apakah / ditimpa Penerapan" penjelasan), format , petunjuk, dan refactoring di beberapa bahasa. NetBeans IDE 7.0 dirilis pada bulan April 2011.

3.1.1. Cara menginstals Netbeans. 

Buka ke instalasi Netbeans dengan nama: netbeans-7.0.1-mlwindows exe

Setelah itu akan tampil prosees kon gurasi installer, anda tunggu prosesnya hingga selesai.

Jika anda melakukan pengaturan Customiz lalu klik Ok dan kemudian Next untuk memulai proses Instalasi.

Kemudian anda dapat memilih paket instalasi java, klik Customize. Atau dapat juga langsung menekan

tombol Next.

Berikutnya anda pilih I accept the terms in the license agreement. Install JUnit.

Selanjutnya anda dapat menentukan lokasi instalasi netbeans dan JDK. Kemudaian klik Next, seperti pada gambar berikut ini:

  

Teruskan dengan menentukan lokasi Instalasi paket Glass Fish. Setelah itu klik Next. Seperti gambar di bawah ini:

Untuk melajutkan ke tahap penginsallan anda klik Install.

Maka akan tampil proses installasi seperti gambar di bawah ini, anda tunggu sampai selesai prosesnya.

Setelah proses Instalasi selesai anda klik nish, maka Jendela wizard akan tertutup

Jalankan aplikasi Netbeans untuk memulai membuat program java.

Tampilan IDE Netbeans akan terlihat seperti pada gambar di bawah ini

3.2. Eclepse

Eclipse merupakan komunitas open source yang bertujuan menghasilkan platform pemrograman terbuka. Eclipse terdiri dari framework yang dapat dikembangkan lebih lanjut, peralatan bantu untuk membuat dan memanage software sejak awal hingga diluncurkan. Platform Eclipse didukung oleh ekosistem besar yang terdiri dari vendor tekonologi, start-up inovatif, universitas, riset institusi serta individu. Banyak orang mengenal Eclipse sebagai IDE (integrated development environment) untuk bahasa Java, tapi Eclipse lebih dari sekedar IDE untuk Java. Komunitas Eclipse memiliki lebih dari 60 proyek open source. Proyek-proyek ini secara konsep terbagi menjadi 7 kategori :

·                     Enterprise Development

·                     Embedded and Device Development

·                     Rich Client Platform

·                     Rich Internet Applications

·                     Application Frameworks

·                     Application Lifecycle Management (ALM)

·                     Service Oriented Architecture (SOA)

Secara umum Eclipse digunakan untuk membangun software inovatif berstandar industri, dan alat bantu beserta frameworknya membantu pekerjaan menjadi lebih mudah. Lisensi Eclipse menggunakan EPL (Eclipse PublicLicense), yaitu lisensi yang memungkinkan organisasi untuk menjadikan Eclipse sebagai produk komersialnya, dan pada saat yang sama meminta orang yang melakukan perubahan untuk mengkontribusikan hasilnya kembali kepada komunitas.

3.2.1. Sejarah Eclipse. 

Eclipse awalnya dikembangkan oleh IBM untuk menggantikan perangkat lunak pengembangan IBM Visual Age for Java 4.0. Produk Eclipse ini diluncurkan oleh IBM pada tanggal 5 November 2001. IBM menginvestasikan US$ 40 juta untuk pengembangannya. Sejak 5 November 2001, konsorsium Eclipse Foundation mengambil alih pengembangan Eclipse lebih lanjut.

3.2.2. Arsitektur Eclipse. 

Sejak versi 3.0, Eclipse pada dasarnya merupakan sebuah kernel. Apa yang dapat digunakan di dalam Eclipse sebenarnya adalah fungsi dari plug-in yang sudah dipasang (diinstal). Ini merupakan basis dari Eclipse yang dinamakan Rich Client Platform (RCP). Berikut ini adalah komponen yang membentuk RCP:

·                     Core platform

·                     OSGi

·                     SWT (Standard Widget Toolkit)

·                     JFace

·                     Eclipse Workbench

Secara standar Eclipse selalu dilengkapi dengan JDT (Java Development Tools), plug-in yang membuat Eclipse kompatibel untuk mengembangkan program Java, dan PDE (Plug-in Development Environment) untuk mengembangkan plug-in baru. Eclipse beserta plug-in-nya diimplementasikan dalam bahasa pemrograman Java. Konsep Eclipse adalah IDE yaitu :

·                     Terbuka (open)

·                     Mudah diperluas (extensible) untuk apa saja

·                     Tidak untuk sesuatu yang spesi k.

Eclipse tidak saja untuk mengembangkan program Java, tetapi juga untuk berbagai macam keperluan. Perluasanapapun cukup dengan menginstal plug-in yang dibutuhkan.

3.2.3. Sifat Eclipse.

Multi-platform: Target sistem operasi Eclipse adalah Microsoft Windows, Linux, Solaris, AIX, HP-UX dan Mac OS X. Mulit-language: Eclipse dikembangkan dengan bahasa pemrograman Java, akan tetapi Eclipse mendukung pengembangan aplikasi berbasis bahasa pemrograman lainnya, seperti C/C++, Cobol, Python, Perl, PHP, dan lain sebagainya. Multi-role: Selain sebagai IDE untuk pengembangan aplikasi, Eclipse pun bisa digunakan untuk aktivitas dalam siklus pengembangan perangkat lunak, seperti dokumentasi, test perangkat lunak, pengembangan web, dan lain sebagainya. Eclipse pada saat ini merupakan salah satu IDE favorit dikarenakan gratis dan open source, yang berarti setiap orang boleh melihat kode pemrograman perangkat lunak ini. Selain itu, kelebihan dari Eclipse yang membuatnya populer adalah kemampuannya untuk dapat dikembangkan oleh pengguna dengan komponen yang dinamakan plug-in (sumber : wikipedia). Lalu bagaimana langkah-langkah untuk dapat melakukan pemrograman dengan Eclipse ini? Pertama kita unduh terlebih dahulu perangkat lunak ini di situs resmi Eclipse : www.eclipse.org .

3.2.4. Instalasi Eclipse. 

Kita membutuhkan Java 5 JRE untuk menjalankan Eclipse. Download Eclipse IDE for Java Developers untuk menggunakan kode pada situs Belajar Java ini. Gunakan utility pada sistem operasi anda untuk membuka kompresi le tersebut ke dalam hard disk anda. Catatan untuk Windows: Apabila Anda menggunakan utilitas kompresi le yang berasal dari Windows XP atau Windows Vista itu sendiri, kadang kala utilitas tersebut tidak berhasil membuka le dengan nama yang panjang. Jika Anda mengalami masalah dekompresi Eclipse pada Windows, letakkan hasil dekompresi pada root directory (misalnya C:\eclipse) atau gunakan software dekompresi lain yang gratis seperti 7-Zip

3.2.5. Menjalankan Eclipse. 

Cari le bernama eclipse.exe (pada Windows) atau eclipse (pada Ubuntu) kemudian double-click Pada saat Eclipse pertama kali dijalankan, Eclipse akan menanyakan workspace, yaitu folder tempat proyek dan data diletakkan. Anda bisa menempatkan di mana saja asalkan jangan di dalam folder Eclipse itu sendiri. Click Browse dan pilih folder yang ada inginkan. Tik Use this as default and do not ask again Halaman pembuka akan muncul. Klik Workspace , tombol paling kanan berbentuk anak panah untuk masuk ke dalam workspace Anda.

3.3. SCRUM Pada Extreme Programming

3.3.1. De nisi SCRUM.

Scrum pertama kali diperkenalkan oleh Je Sutherland tahun awal tahun1990an, dan dikembangkan selanjutnya dilakukan oleh Schwaber dan Beedle. Pada dasarnya Scrum merupakan salah satu komponen dari metodologi pengembangan Agile mengenai pertemuan harian untuk membahas kemajuan sedangkan XP adalah menekankan metodologi yang berbeda yaitu ujian, pemrograman dan pembangunan. Scrum menguraikan proses untuk mengidenti kasi dan katalogisasi pekerjaan yang perlu dilakukan, memprioritaskan yang bekerja dengan berkomunikasi dengan pelanggan atau wakil pelanggan, dan pelaksanaanyang bekerja menggunakan rilis iterative dan memiliki tujuan utama untuk mendapatkan perkiraan berapa lama akan pembangunan. XP lebih lanjut tentang pengembang membantu menyelesaikan pekerjaan secepat dan maintainably mungkin Scrum merupakan suatu kerangka kerja. Jadi, bukannya menyediakan deskripsi rinci tentang bagaimana segala sesuatu yang harus dilakukan pada proyek seperti diserahkan kepada tim pengembangan perangkat lunak pada umumnya. Hal ini dilakukan supaya tim akan tahu bagaimana cara terbaik untuk memecahkan masalah yang mereka disajikan. Ada 3 elemen organisasi utama pada scrum yaitu product owner, Scrum master, dan the Scrum team. Scrum Master dapat dianggap sebagai pelatih bagi tim, membantu anggota tim menggunakan kerangka Scrum untuk tampil di tingkat tertinggi. Product Owner mewakili bisnis, pelanggan atau pengguna dan memandu tim ke arah pegembangan produk yang tepat. Sedangkan The Scrum Team merupakan grup pengembang kecil biasanya terdiri dari 5-9 orang. Untuk projek yang sangat besar, pekerjaan biasanya dibagi dan didelegasikan ke grup-grup kecil. Jika sangat dibutuhkan the scrum master juga dapat ikut membantu dalam koordinasi team. Scrum tepat digunakan saat kondisi:

·                     Keperluan berubah dengan cepat

·                     Tim programmer sedikit, yaitu 5-9 orang

·                     Pelanggan tidak terlalu paham dengan apa yang diinginkan

Scrum memiliki prinsip yaitu:

·                     Ukuran tim yang kecil melancarkan komunikasi, mengurangi biaya, dan memberdayakan satu sama lain

·                     Proses dapat beradaptasi terhadap perubahan teknis dan bisnis Proses menghasilkan beberapa software increment

·                     Pembangunan dan orang yang membangun dibagi dalam tim yang kecil

·                     Dokumentasi dan pengujian terus menerus dilakukan setelah software dibangun

·                     Proses scrum mampu menyatakan bahwa produk selesai kapanpun diperlukan.

Kelebihan Scrum antara lain: 

·                     Keperluan berubah dengan cepat

·                     Tim berukuran kecil sehingga melancarkan komunikasi, mengurangi biaya dan memberdayakan satu sama lain

·                     Pekerjaan terbagi-bagi sehingga dapat diselesaikan dengan cepat

·                     Dokumentasi dan pengujian terus menerus dilakukan setelah software dibangun

·                     Proses Scrum mampu menyatakan bahwa produk selesai kapanpun diperlukan

Kelemahan Scrum antara lain:

·                     Developer harus selalu siap dengan perubahan karena perubahan akan selalu diterima.

3.3.2. Tim Scrum. 

Tim Scrum terdiri dari Product Owner, Tim Pengembang dan Scrum Master. Tim Scrum mengatur diri mereka sendiri dan berfungsi antar - lintas. Tim yang mengatur dirinya sendiri menentukan cara terbaik untuk menyelesaikan pekerjaannya, daripada diatur oleh pihak lain yang berada di luar anggota tim. Tim yang berfungsi antar - lintas memiliki semua kompetensi yang dibutuhk an untuk menyelesaikan pekerjaan, tanpa mengandalkan pihak lain yang berada di luar anggota tim. Model tim di dalam Scrum diranc ang sedemikian rupa untuk mengo timalisasi eksibilitas, kreati tas dan produkti tas. Tim Scrum menghantarkan produk secara berkala dan bertahap untuk memperbesar kesempatan mendapatkan masukan. Penghantaran secara bertahap dari sebuah produk yang Selesai , memastikan produk yang berpotensi dapat digunakan, selalu siap.

Product: Owner bertanggung - jawab untuk memaksimalkan nilai produk dan hasil kerja Tim Pengembang. Cara pelaksanaannya sangat bervariasi antar organisasi, Tim Scrum dan individu. Product Owner merupakan satu satunya orang yang bertanggung - jawab untuk mengelola Product Backlog. Pengelolaan Produc t Backlog mencakup:

·                     Mengekspresikan dengan jelas item Product Backlog

·                     Mengurutkan item di dalam Product Backlog untuk mencapai tujuan dan misi dengan cara terbaik

·                     Mengoptimalkan nilai dari hasil pekerjaan Tim Pengembang

·                     Memastikan Product Backlog trans paran, jelas, dan dapat dilihat semua pihak, dan menunjukkanapa yang akan dikerjakan oleh Tim Scrum selanjutnya

·                     Memastikan Tim Pengembang dapat memahami item dalam Product Backlog hingga batasan yang diperlukan

Product Owner dapat saja mengerjakan peke rjaan - pekerjaan di atas, atau menyerahkan pengerjaannya kepada Tim Pengembang, namun satu - satunya pihak yang bertanggung jawab tetaplah Product Owner. Product Owner adalah satu orang dan bukan berupa sebuah komite. Product Owner dapat mengejawantahkan asp irasi dari komite ke dalam Product Backlog, namun mereka yang ingin merubah prioritas item Product Backlog, harus melakukannya melalui Product Owner. Agar Product Owner berhasil menjalankan tugasnya, seluruh organisasi harus menghormati setiap keputusan yang ia buat. Keputusan dari Product Owner ini dapat dilihat dari isi dan urutan Product Backlog. Tidak ada seseorang pun yang dapat memerintah Tim Pengembang untuk mengerjakan kebutuhan lain selain Product Owner. Dan Tim Pengembang pun tidak diperbolehkan untuk melakukan apa yang diperintahkan oleh pihak lain selain Product Owner.

Tim: pengembang terdiri dari para profesional yang bekerja untuk menghasilkan tambahan potongan produk (selanjutnya disebut Inkremen) Selesai , yang berpotensi untuk dirilis di setiap akhir Sprint. Hanya anggota Tim Pengembang yang mengembangkan Inkremen ini.Tim Pengembang dibentuk dan didukung oleh organisasi untuk mengatur dan mengelola pekerjaannya secara mandiri. Sinergi yang ada di dalam tim akan meningkat kan e siensi dan efekti tas dari Tim Pengembang secara keseluruhan.

Tim Pengembang memiliki karakteristik sebagai berikut:

·                     Mereka mengatur dirinya sendiri. Tidak ada satu orang pun (bahkan Scrum Master) yang memerintah

·                     Tim Pengembang bagaimana cara merub ah Product Backlog menjadi Inkremen yang berpotensi untuk dirilis;

·                     Tim Pengembang berfungsi antar - lintas, sebagai sebuah tim, memiliki semua keahlian yang dibutuhkan untuk menghasilkan produk;

·                     Scrum tidak mengenal adanya jabatan tertentu untuk anggota Tim Pengembang selain Pengembang, apapun pekerjaan yang dikerjakan oleh masing - masing anggota tim; tidak ada pengecualian untuk aturan yang satu ini;

·                     Tim Pengembang tidak mengenal adanya sub - tim yang dikhususkan untuk bidang tertentu seperti pengujian atau analisa bisnis; tidak ada pengecualian untuk aturan yang satu ini;

·                     Anggota Tim Pengembang boleh memiliki spesialisasi keahlian dan fokus di satu area tertentu, namun akuntabilitas dari hasil dari pekerjaan secara keseluruhan adalah milik Tim Pengembang.

Jumlah anggota Tim Pengembang yang optimal adalah cukup kecil untuk dapat berkoordinasi dengan cepat, dan cukup besar untuk dapat menyelesaikan pekerjaan dalam satu Sprint. Jumlah anggota tim yang kurang dari tiga orang akan mengurangi interaksi dan akan menyebabkan produkti tas yang rendah. Tim Pengembang yang kecil kemungkinan akan mengalami kekurangan keahlian tertentu pada saat Sprint berjalan, yang pada akhirnya menyebabkan Tim Pengembang tidak dapat menghasilkan Inkremen yang be rpotensi untuk dirilis. Tim Pengembang dengan jumlah anggota lebih dari sembilan orang membutuhan terlalu banyak koordinasi. Tim Pengembang dengan jumlah anggota tim yang banyak, akan menimbulkan terlalu banyak kompleksitas bagi proses yang berbasiskan emp irisme. Product Owner dan Scrum Master tidak termasuk dalam hitungan, kecuali mereka juga turut ikut mengerjakan pekerjaan yang ada di Sprint Backlog

Scrum: Master bertanggung jawab untuk memastikan Scrum telah dipahami dan dilaksanakan. Scrum Master melakukannya dengan memastikan Tim Scrum mengikuti teori, praktik, dan aturan main Scrum. Scrum Master adalah seorang pemimpin yang melayani Tim Scrum. Scrum Master membantu pihak di luar Tim Scrum, untuk memahami apakah interaksi mereka dengan Ti m Scrum bermanfaat atau tidak. Scrum Master membantu setiap pihak untuk merubah interaksi - interaksi yang tidak bermanfaat sehingga bisa memaksimalkan nilai yang dihasilkan oleh Tim Scrum.

3.3.3. Scrum Mater Pada Product Owner. 

Scrum Master melayani Product Owner dengan berbagai cara yang mencakup :

·                     Mencari teknik yang paling efektif untuk mengelola Product Backlog

·                     Membantu Tim Scrum untuk memahami pentingnya Product Backlog item yang jelas dan padat

·                     Memahami bagaimana perencanaan produk pada lingkun gan yang didasarkan empirisme

·                     Memastikan Product Owner tahu bagaimana mengelola Product Backlog guna memaksimalkan nilai dari produk

·                     Memahami dan mempraktikkan agility

·                     Memfasilitasi acara - acara dalam Scrum bila dipanggil dan dibutuhkan.

3.3.4. Scrum Master kepada Tim Pengembang. 

Scrum Master melayani Tim Pengembang lewat berbagai cara yang mencakup:

·                     Membimbing Tim Pengembang untuk dapat mengatur dirinya sendiri dan berfungsi antar - lintas

·                     Membantu Tim Pengembang untuk membuat produk bernilai ti nggi

·                     Menghilangkan hambatan - hambatan yang dialami oleh Tim Pengembang

·                     Memfasilitasi acara - acara dalam Scrum bila dipanggil dan dibutuhkan

·                     Membimbing Tim Pengembang dalam suasana organisasi di mana Scrum belum sepenuhnya diterapkan dan dipahami.

3.3.5. crum Master Service kepada Organisasi. 

Scrum Master melayani organisasi tempat dia berada lewat berbagai cara yang mencakup:

·                     Memimpin dan membimbing organisasi dalam penerapan Scrum

·                     Merencanakan implementasi Scrum di dalam organisasi

·                     Membantu se tiap pegawai dan stakeholder dalam memahami dan menggunakan Scrum dan pengembangan produk dengan metoda empiris

·                     Membuat perubahan yang dapat meningkatkan produkti tas di dalam Tim Scrum

·                     Bekerja bersama dengan Scrum Master lainnya guna meningkatkan efekti tas dari pengaplikasian Scrum di dalam organisasi

3.3.6. Aktivitas Scrum. Scrum memiliki akti tas yang meliputi :

1.            Backlog adalah daftar kebutuhan yang jadi prioritas klien, dan daftar yang dibuat dapat bertambah

2.            Sprints Akti tas merupakan unit pekerjaan yang diperlukan untuk memenuhi kebutuhan yang ditetapkan

3.            dalam backlog sesuai dengan waktu yang ditetapkan dalam time-box (biasanya 30hari). Selama

4.            proses ini berlangsung backlog tidak ada penambahan.

5.             Scrum Meetings merupakan pertemuan yang rutin dilakukan perhari untuk evaluasi apa yang dikerjakan,

6.            hambatan yang ada, dan target penyelesaian untuk bahan meeting selanjutnya.

7.             Demo Akti tas adalah penyerahan software increment ke klien didemonstrasikan dan dievaluasi oleh klien.

3.4. jUnit Pada Extreme Programming

JUnit adalah salah satu tools yang membantu kita untuk melakukan unit testing terhadap kode yang cocok sekali bila diimplementasikan dalam XP. Martin Fowler berkata Whenever you are tempted to type something into a print statement or a debugger expression, write it as a test instead. JUnit adalah sebuah framework yang dikembangkan di atas Java, yang dibuat oleh masternya Extreme Programming, Kent Beck dan masternya Design Pattern, Erich Gamma. JUnit dapat dikatakan sebuah simple test framework yang didesain untuk melakukan testing yang bersifat berulang. Sebelumnya Kent Beck mengembangkan Sunit yaitu unit testing untuk SmallTalk yang sangat populer dengan MVC-nya. Umumnya programmer malas untuk membuat unit testing karena dianggap pekerjaan tambahan. Memang sih, untuk pekerjaan yang simpel dan tetap, unit testin  dirasakan memberatkan, tetapi kalau programmer yang sudah terbiasa membuat komponen pasti tahu deh, apa yang terjadi kalau ada kode-kode yang sudah berjibun dan direfactor, sebagai contoh misalnya semua kode dari com.intercitra.model.

·                     Dipindahkan ke org.blueoxygen.cimande. model. 

·                     Pekerjaan di atas memang mudah apalagi kalau menggunakan Eclipse dari eclipse.org, tinggal click kanan, pilih refactor, terus rename, selesai. Sadar, tidak sadar, semua code yang berhubungan dengan object didalam package com.intercitra. model.

·                      Harus dirubah. Kalau semua code dalam Eclipse Project, kita tidak perlu pusing, karena secara tidak langsung semua import com.intercitra.model. 

·                     Akan di-rename menjadi import org.blueoxygen.cimande. model. 

·                     Sayangnya, apa dikata, bagi programmer JSP, tetap harus melakukan unit testing satu per satu semu kegiatan yang memanggil object didalam package org.blueoxygen.cimande.model.

Harus edit satu per satu, makanya sampai saat ini JSP dibilang salah satu mekanisme pemograman yang kotor dengan kata lain membuat pekerjaan tambahan di kemudian hari. Lain halnya dengan aplikasi menggunakan pendekatan lain yang lebih OOP, kita dapat melakukan refactoring secara cepat terhadap seluruh kode. Apakah dengan melakukan refactoring, semua programer yakin semua kode kita akan berjalan dengan mulus dan stable? Unit testing adalah jawaban untuk merealisasikannya, karena unit testing adalah sebuah mekanisme yang meyakinkan kita bahwa setiap perubahaan terhadap kode akan menghasilkan result yang benar. Unit testing yang sukses akan lebih meyakinkan bahwa kode kita ini benarbenar berjalan dengan baik.

Sebenarnya melakukan unit testing itu gampang-gampang susah, karena secara konsep yang mengacu pada JUnit, unit testing itu dipecah menjadi dua bagian, yaitu TestCase dan TestSuite, di mana TestSuite merupakan kumpulan TestCase-TestCase. Hebatnya saat ini IDE yang ada sudah memasukan JUnit secara terintegrasi, sehingga kita tidak perlu pusing, jalankan IDE, buat TestCase, execute testing, selesai. Malahan IDE yang hebat tersebut kita tidak perlu membeli, semuanya open source, cobalah kunjungi eclipse.org atau netbeans.org untuk mendapatkannya. Apakah dengan mekanisme seperti melakukan unit testing secara console based tidak relevan lagi? Dari pengalaman penulis, didapatkan bahwa melakukan testing dengan IDE memang menyenangkan, kita bisa melakukan testing satu demi satu, tetapi apa yang terjadi kalau kita ada 1000 TestSuite, dan setiap TestSuite ada 100 TestCase.

3.4.1. TestCase dan TestSuite di JUnit.

Seperti yang telah diutarakan sebelumnya, unit testing dengan Junit hanya diperlukan dua keahlian, yaitu membuat TestCase dan TestSuite, di mana TestSuite adalah kumpulan testing untuk melakukan eksekusi TestCase. Struktur pengembangan TestCase itu simple sekali, dan untuk lebih jelasnya lihatlah kode berikut ini:

public class MoneyTest extends TestCase {

public void testSimpleAdd() {

Money m12CHF= new Money(12, CHF );

Money m14CHF= new Money(14, CHF );

Money expected= new Money(26, CHF ); Money result= m12CHF.add (m14CHF);

Assert.assertTrue(expected.equals (result));

} }

diatas adalah kode yang sederhana, sedangkan yang lebih lengkap adalah:

public class MoneyTest extends TestCase {

private Money f12CHF;

private Money f14CHF;

protected void setUp() {

f12CHF= new Money(12, CHF );

f14CHF= new Money(14, CHF );

}

public void testEquals() {

Assert.assertTrue(!f12CHF.equals (null));

Assert.assertEquals(f12CHF, f12CHF);

Assert.assertEquals(f12CHF, new Money(12, CHF ));

Assert.assertTrue(!f12CHF.equals (f14CHF));

}

public void testSimpleAdd() {

Money expected= new Money(26, CHF );

Money result= f12CHF.add(f14CHF);

Assert.assertTrue(expected.equals (result));

} }

Code di atas adalah sebuah TestCase simple untuk melakukan test terhadap code Money, di mana testingnya adalah testEquals() untuk test method equals() dan testSimpleAdd() untuk test metho simpleAdd(). Setiap assert akan membandingkan result yang dihasilkan, bila lolos, berarti testing lolos skenario tersebut.

3.4.2. Bekerja Dengan jUnit. 

Untuk memulai pengembangan dengan JUnit, buatlah sebuah project, yang termudah adalah menggunakan Eclipse. Artikel mengenai Eclipse ada di InfoLINUX edisi Januari 2004 atau kunjungi http:// www.eclipse.org. Sesuai yang disarankan oleh team JUnit, sebaiknya kita membuat 2 folder pada projek tersebut yaitu src untuk menyimpan source code, dan test untuk menyimpan unit testing code, sehingga bila kita akan melakukan packaging binary dari source code, unit testingnya tidak terbawa. Untuk memudahkan biasanya source code ditaruh di subfolder java di bawah src, karena umumnya para programmer menyimpan source code lainnya juga di dalam folder src, seperti sql, template, con g, malah tidak jarang memasukkan WAR container ke dalamnya. Jadi struktur yang disarankan penulis adalah sebagai berikut:

src

java

org

blueoxygen

SomeClass1.java

SomeClass2.java sql

smiletown.

sql conf cimande.properties

test

java

org

blueoxygen

SomeClass1Test.java

SomeClass2Test.java S

omeClassSuite.java

Kasus di atas dapat diartikan bahwa ada code java dengan nama org.blueoxygen. SomeClass1 yang akan dilakukan unit testing, di mana code unit testingnya adalah org.blueoxygen.SomeClass1Test, sedangkan org.blueoxygen.SomeClass2, kode unit testingnya adalah SomeClass2Test, serta sebuah TestSuite org.blueoxygen. SomeClassSuite. Bila suatu hari dirasakan bahwa menggunakan package org.blueoxygen untuk test merasa terganggu, dimungkinkan untuk menggunakan package org.blueoxygen.test atau test.org.blueoxygen. Bila suatu hari dirasakan bahwa menggunakan package org.blueoxygen untuk test merasa terganggu, dimungkinkan untuk menggunakan package org.blueoxygen.test atau test.org.blueoxygen.

3.4.3. Membuat TestCase. 

Untuk membuat sebuah TestCase sebenarnya mudah sekali, Eclipse telah menyediakan Wizardnya, sehingga kita hanya perlu memasukan kode testingnya seperti Assert.assertTrue, Assert. assertEquals atau Assert.assertNull.

Contohnya adalah seperti berikut:

assertEquals(3,testMap.size());

assertEquals( Intercitra , testMap.get ( Company ));

Untuk memulai project unit testing, kita akan membuat sebuah unit.

Testing untuk HashMap, sebuah kode yang sudah disediakan secara otomatis oleh Java SDK, HashMap adalah salah satu dari Java Collection Library, selain HashMap, ada beberapa Java Collection seperti HashTable,ArrayList, atau List. Didalam HashMap, terdapat banyak method seperti put, putAll, size, get, ataupuncontainsKey, maka untuk melakukan unit testing sebaiknya semua testing tersebut dilakukan satu persatu,seperti untuk testing put kita membuat sebuah method dengan nama testPut() didalam TestCase, testing method get menggunakan method testGet() di dalam TestCase. Untuk memudahkannya cobalah buat sebuah le HashMapTest. java dibawah directory yang telah diterangkan diatas, dan ketiklan baris di bawah ini.

packageorg.blueoxygen.collection;
importjunit.framework.TestCase;
importjava.util.Map; importjava.util.HashMap;
/*
* Created on Jan 18, 2004
*
* To change the template for this generated le go to
* Window>Preferences> Java>Code Generation>
Code and Comments
*/
/**
* @author Frans Thamura (frans@intercitra.com)
*
* To change the template for this generated type comment go to
* Window>Preferences>Java>
Code Generation>Code and Comments
*/
publicclassHashMapTest extends TestCase {
private Map testMap;
private Map testMap2;
private static nal String MAP_KEY =
Open Source ;
private static nal String MAP_VALUE = BlueOxygen ;
/**
* Constructor for HashMapTest.
* @param arg0
*/
public HashMapTest(String arg0) {
super(arg0); }
// You can run the TestCase as a standalone Swing
// If you are using Eclipse, you dont need this public static void main(String[] args)
{
// You can use swingui, awtui or text ui. But, I love Swing UI junit.swingui.TestRunner.run
(HashMapTest.class); }
/*
* @see TestCase#setUp()
*/
protected void setUp() throws Exception {
// First Collection
testMap = new HashMap();
testMap.put(MAP_KEY, MAP_VALUE);
testMap.put( Open Source , BlueOxygen );
testMap2 = new HashMap();
testMap2.put( Company , Intercitra );
testMap2.put( Community , Java User Group );
}
// the real test
public void testPut() {
String key = Juragan ;
String value = Patimura ;
// second Put
testMap.put(key,value);
String value2 = (String)testMap. get(key);
assertEquals( The value back from the map , value, value2);
}
public void testSize() {
assertEquals(1, testMap.size());
}
public void testGet()
{
assertEquals( BlueOxygen , testMap.get(MAP_KEY));
assertNull(testMap.get ( JUNK_KEY ));
}
public void testPutAll() {
// put testMap2 to testMap
testMap.putAll(testMap2);
// check the size, must be 3, because the Juragan in the testMap now.
assertEquals (3, testMap.size());
assertEquals( Intercitra , testMap.get( Company ));
}
public void testContainsKey()
{
assertTrue( MAP_KEY value : , testMap.containsKey(MAP_KEY));
}
public void testContainsValue()
{
assertTrue(testMap.containsValue (MAP_VALUE));
}
public void testRemove() {
String key = Juragan ;
String value = Patimura ;
testMap.put(key, value);
testMap.remove(key);
assertNull (testMap.get(key));
}
/* * @see TestCase#tearDown()
*/ protected void tearDown()
throws Exception { super.tearDown();
}
}

3.4.4. Membuat TestSuite. 

TestSuite Untuk memudahkan konsep pengembangan TestSuite, buatlah sebuah script seperti di bawah ini dan tentu saja di bawah folder test/org/blueoxygen/collection.

public class AllTests {
public static void main(String[] args)
{
junit.swingui.TestRunner.run (AllTests.class);
}
public static Test suite() {
TestSuite suite = new TestSuite ( Test for org.blueoxygen. collection );
//$JUnit-BEGIN$ suite.addTest(new TestSuite (HashMapTest.class));
//$JUnit-END$ return suite;
}
}

TestSuite di atas akan mengeksekusi TestCase, yang dalam kasus di atas adalah HashMapTest.class.

 

Penerapan Extreme Programming

4.1. Penerapan Extreme Programming Pada Netbean

4.1.1. Pengertian Junit.

JUnit adalah salah satu tools yang membantu kita untuk melakukan unit testing terhadap kode yang cocok sekali bila diimplementasikan dalam XP. Martin Fowler berkata Whenever you are tempted to type something into a print statement or a debugger expression, write it as a test instead. JUnit adalah sebuah framework yang dikembangkan di atas Java, yang dibuat oleh masternya Extreme Programming, Kent Beck dan masternya Design Pattern, Erich Gamma. JUnit dapat dikatakan sebuah simple test framework yang didesain untuk melakukan testing yang bersifat berulang. Sebelumnya Kent Beck mengembangkan Sunit yaitu unit testing untuk SmallTalk yang sangat populer dengan MVC-nya. Umumnya programmer malas untuk membuat unit testing karena dianggap pekerjaan tambahan. Memang sih, untuk pekerjaan yang simpel dan tetap, unit testing dirasakan memberatkan, tetapi kalau programmer yang sudah terbiasa membuat komponen pasti tahu deh, apa yang terjadi kalau ada kode-kode yang sudah berjibun dan direfactor, sebagai contoh misalnya semua kode dari com.intercitra.model.* dipindahkan ke org.blueoxygen.cimande. model.*. Pekerjaan di atas memang mudah apalagi kalau menggunakan Eclipse dari eclipse.org, tinggal click kanan, pilih refactor, terus rename, selesai. Sadar, tidak sadar, semua code yang berhubungan dengan object didalam package com.intercitra. model.* harus dirubah. Kalau semua code dalam Eclipse Project, kita tidak perlu pusing, karena secara tidak langsung semua import com.intercitra.model.* akan di-rename menjadi import org.blueoxygen.cimande. model.*. Sayangnya, apa dikata, bagi programmer JSP, tetap harus melakukan unit testing satu per satu semua kegiatan yang memanggil object didalam package org.blueoxygen.cimande.model.*, harus edit satu per satu, makanya sampai saat ini JSP dibilang salah satu mekanisme pemograman yang kotor dengan kata lain membuat pekerjaan tambahan di kemudian hari. Lain halnya dengan aplikasi menggunakan pendekatan lain yang lebih OOP, kita dapat melakukan refactoring secara cepat terhadap seluruh kode. Apakah dengan melakukan refactoring, semua programer yakin semua kode kita akan berjalan dengan mulus dan stable?

Unit testing adalah jawaban untuk merealisasikannya, karena unit testing adalah sebuah mekanisme yang meyakinkan kita bahwa setiap perubahaan terhadap kode akan menghasilkan result yang benar. Unit testing yang sukses akanlebih meyakinkan bahwa kode kita ini benarbenar berjalan dengan baik. Sebenarnya melakukan unit testing itu gampang-gampang susah, karena secara konsep yang mengacu pada JUnit, unit testing itu dipecah menjadi dua bagian, yaitu TestCase dan TestSuite, di mana TestSuite merupakan kumpulan TestCase-TestCase. Hebatnya saat ini IDE yang ada sudah memasukan JUnit secara terintegrasi, sehingga kita tidak perlu pusing, jalankan IDE, buat TestCase, execute testing, selesai. Malahan IDE yang hebat tersebut kita tidak perlu membeli, semuanya open source, cobalah kunjungi eclipse.org atau netbeans.org untuk mendapatkannya. Apakah dengan mekanisme seperti melakukan unit testing secara console based tidak relevan lagi? Dari pengalaman penulis, didapatkan bahwa melakukan testing dengan IDE memang menyenangkan,kita bisa melakukan testing satu demi satu, tetapi apa yang terjadi kalau kita ada 1000 TestSuite, dan setiap TestSuite ada 100 TestCase.

Untuk melakukan unit testing dengan Netbeans dapat dilakukan dengan tahapah sebagai berikut :

1.            Jalankan Netbeans dan buat project java baru

2.            buat simple class yang mempunyai nilai kembalian (return value) dan void method.

3.            Gunakan return value untuk proses yang mudah sebagai contoh dapat menggunakan proses penanbahan atau pengurangan

contoh classnya :

/* class SimpleMath.java */

public class SimpleMath{

public int doAddition(int a, int b){

return a + b;

}

public int doSubtraction(int a, int b){

return a/b;

}

public void printAdditon(int a, int b){

System.out.println( var1 = +a= , var2 = +b+ +

hasilnya adalah = +doAddition(a,b));

}

}

untuk membuat unit testing

Setelah mengetahui mengenai Unit testing dengan Junit, kita dapat menatik satu kesimpulan yaitu: manfaat Unit Testing ini akan mengerucut pada satu hal; Code Quality. Banyak metode best practice yang harus ditempuh dan diperhatikan untuk menghasilkan Code yang berkualitas, salah satunya dengan Unit Testing. Junit merupakan cara untuk mengetahu code Quality yang dibuat dengan menggunakan bahasa pemprograman java.

4.2. Penerapan Extreme Programming Pada Perusahaan

4.2.1. PT. Yubi Citra Karyadikara. 

Jenis penelitian yang akan digunakan dalam penelitian ini adalah deskriptif dan metode penelitiannya adalah studi kasus dan survey yang menganalisis tentang perencanaan bahan baku material dengan menggunakan metode Material Requirement Planning (MRP) serta unit analisisnya adalah PT. Yubi Citra Karyadikara. Pro l Perusahaan PT. Yubi Citra Karyadikara adalah perusanaan industri swasta yang bergerak dalam bidang industri mebel yaitu memproduksi o ce chairs atau kursi _ kursi kantor yang memiliki pabrik berlokasi di jalan peternakan II no.15, Kapuk Jagal jakarta 11720 dan letak kantornya di jalan tanjung duren barat 1 no.31. Ditinjau dari segi hukum PT. Yubi Citra Karyadikara telah berdiri sejak tahun 1989 dengan no SIUP 7237/09.03/PM/VIII/1991. Perusahaan ini sudah berjalan selama 18 tahun, dengan modal awal adalah sebesar Rp 300.000.000. Perusahaan sebelumnya tidak hanya di bidang industri o rice chairs saja, tetapi memproduksi mebel lainnya seperti lemari, meja meja tetapi karena produk tersebut kurang diminati oleh pelanggan, maka perusahaan hanya menciptakan kursi kursi kantor, karena perusahaan bekerja sama dengan beberapa kantor juga, sehingga sudah memilki pelanggan tetap. Banyak perkembangan dalam perusahaan ini, perusahaan terus menciptakan produk produk baru, sehingga perusahaan memiliki banyak sekali jenis dan model kursi- kursi dengan fungsinya yang berbeda. PT. Yubi Citra Karyadikara banyak memproduksi kursi-kursi kantor yang mempunyai tipe dan model pilihan yaitu sta chair, secretary chair, executive secretary chair, bar chair, manager chair, executive manager chair, director chair, executive director chair, meeting chair, salon chair dan visitor chair. Dalam Master Production Schedule ini menyatakan bahwa adanya pesanan untuk produk kursi OX 830 secara keseluruhan adalah sebanyak 950 unit kursi, untuk memproduksi kursi tersebut memerlukan waktu 10 menit per-unit. Kursi yang sudah diproduksi harus di proses lebih lanjut ke dalam proses nishing yang memerlukan waktu 2 menit Iamanya dan proses nishing ini akan dimulai di menit ke-8 dan selesai pada menit ke-10. Jika perusahaan menerima banyak pesanan maka perusahaan akan menambah waktu lembur. Biasanya dalam sehari perusahaan bisa memproduksi sebanyak 60 - 80 unit, tetapi jika menambah waktu lembur maka dalam sehari perusahaan bisa memproduksi sebanyak 100-120 unit. Secara garis besar penambahan fase requirements management pada eXtreme Programming sangat membantu untuk lebih menstrukturkan metode ini. Requirements Management yang disisipkan terutama difokuskan dalam hal dokumentasi. Pendokumentasian pada eXtreme Programming ini tidak akan mengganggu proses secara keseluruhan karena dilaksanakan secara paralel dengan planning phase. Hasil pengukuran yang dilaksanakan terhadap penambahan fase requirements management yang paralel dengan planning phase pada siklus hidup eXtreme Programming menunjukkan bahwa metodologi ini tetap pada posisi agile. Pengukuran yang dilakukan dengan menggunakan statistik yaitu dengan menilai indikator-indikator agile-nya yang kemudian diklasikasikan dengan menggunakan distribusi normal memperoleh empat klasi kasi. Klasi kasi itu adalah A untuk posisi sangat agile, B untuk posisi agile, C untuk posisi cukup agile, dan D untuk posisi tidak agile. Setelah pengukuran, penambahan fase ini menunjukkan berada pada posisi B. Dengan hasil tersebut berarti penambahan fase requirements management tidak menjadikan eXtreme Programming keluar dari metodologi Agile. Mempunyai RE yang bagus adalah penting karena dampaknya mampu mengurangi biaya proyek, dan diterimanya sistem oleh stakeholder sehingga bisa mengarah kepada keuntungan yang tinggi. Namun juga harus diakui dibutuhkan tenaga dan waktu yang tidak sedikit untuk berinvestasi dalam pembuatan requirement yang benar-benar bagus. Untuk mendapatkan requirement yang bagus, ada banyak pekerjaan/tasks harus dilakukan, untuk itu tim RE tidak hanya bekerja pada awal dari proyek namun bekerja melalui tahap pengembangan sampai tahap delivery untuk memastikan requirement benar-benar sesuai. Dengan dilakukannya penelitian mengenai penerapan metode Material Ruirement Planning dalam perencanaan kebutuhan material kursi OX 830 pada PT. Yubi Citra Karyadikara maka dapat disimpulkan bahwa :

1.              Dalam memenuhi pesanan pelanggan akan permintaan produkJcursi OX 830 sebanyak 950 unit ,maka PT. Yubi Citra Karyadikara memerlukan komponen komponen sebagai berikut, komponenpapan dudukan sebanyak 950 unit, papan senderan sebanyak 950 unit, kaki cakar lima sebanyak 950 unit, busa atau foam dudukan sebanyak 950 unit, seat mechanis sebanyak 950 unit, busa atau foam senderan sebanyak 950 unit, kote kote sebanyak 950 unit, roda castor sebanyak 4750 unit, gas lift atau hydraulic sebanyak 950 unit, kain alabama sebanyak 1900 unit, dan list karet sebanyak 1900 unit.

2.     Dalam memproduksi seluruh pesanan pelanggan akan permintaan kursi OX 830 sebanyak 950 unit maka setelah diperhitungkan biaya biaya yang akan dikeluarkan oleh perusahaan dibagi menjadi 2 yaitu total biaya material berdasarkan perencanaan kebutuhan material (MRP) yaitu sebesar Rp 298.775.000 dan total biaya material berdasarkan analisis sistem berjalan yaitu s.'-tesar Rp 302.899.994. Jadi dapat disimpulkan bahwa untuk memproduksi pesanan kursi OX 830 sebanyak 950 unit sebaiknya perusahaan menerapkan sistem Material Reqiurement Planning (MRP) karena total biaya material yang dikeluarkan perusahaan lebih minimal sehingga biaya biaya yang dikeluarkan untuk memproduksi oleh perusahaan tidak besar dan memberikan keuntungan bagi perusahaan.

4.2.2. Beta Mart.

Profil l: perusahaan

BetaMart adalah sebuah minimarket yang menjual beberapa kebutuhan keluarga dan kebutuhan lainnya. BetaMart mempunyai 2 orang kasir untuk menjaga toko dengan bergantian. Sedangkan untuk mempermudah pengontrolan barang, BetaMart mempunyai 2 karyawan lagi sebagai staf warehouse (gudang). Sedangkan di toko itu sendiri terdapat 4 pramuniaga toko untuk membantu pembeli yang bekerja secara shift.

Proses:

Proses bisnis dimulai ketika pelanggan memilih/berbelanja, setelah puas dalam memilih kebutuhannya, pelanggan akan melakukan pembayaran, bila pelanggan tersebut belum bergabung menjadi member maka pelangan tersebut ditawarkan untuk menjadi member dan pelayan/kasir menjelaskan keuntungan bergabung sebagai member. Prosedur menjadi member yaitu dengan memberikan deposit kepada BetaMart, maka pelanggan akan diberikan voucher belanja dengan nilai sesuai dengan deposit yang disetorkan, dan akan mendapatkan diskon 10% disetiap transaksi dan diskon promo lainnya. Nantinya sistem pembayaran dengan deposit disebut sebagai sistem voucher. Bila tidak maka transaksi dilakukan dengan pembayaran tunai, dimana petugas tidak mencatat nama & identitas pembeli. Petugas kasir akan memberikan laporan penjualan secara harian kepada petugas gudang sehingga petugas gudang dapat mengecek persediaan barang di toko. Apabila stok barang yang dijual sudah habis atau memerlukan tambahan stock, petugas gudang akan mengirim barang ke toko dan petugas kasir akan melakukan pencatatan data barang yang dikirimkan. Petugas gudang juga melakukan pengecekan harian stok barang pada gudang untuk melakukan purchase order.

4.2.3. Penerapan Aplikasi Dengan Extreme Programming.

(1) Planning

* Use Case Diagram

Transaksi Member

Transaksi Pembayaran

3. Coding

Setelah metode designing dilakukan, maka akan dilakukan pengkodean untuk membuat program dari sistem penjualan/kasir Beta Mart.

4. Testing

Testing yang saya lakukan hanya pada proses pembayaran/kasir dan tidak pada semua menu. Saya melakukan testing pada menu pelanggan, menu pembayaran dan cetak faktur. Data yang bisa di cari yaitu data barang atau pelanggan.

1. Login

2. Pelanggan

3.Input Data Pelanggan

4.Pencarian Data Pelanggan

5.Transaksi pembayaran

6. Incremental Release

Setelah melalui unit testing akan dilakukan incremental release, yaitu release software secara bertahap.

Release Texts :

Betamart: System V.1.1

·                     Fitur pada Betamart V.1.1

-Login : access database karyawan dengan authorisasi

-Member checking : access database member

-Member added : penambahan database member

-Transaction recording : access database transaksi, detail barang, metode bayar

-Au-tomated calculation: kalkulasi otomatis diskon & jumlah pembayaran

-Automated stock calculation: kalkulasi otomatis pengurangan stok barang di toko

-Stock added : penambahan stok barang di toko

·                     Issue

-Rejection stock added (bug130875)

-Temp solution : restart system

Betamart: System V.1.2

·                     Pembaharuan & Fitur Tambahan pada Betamart V.1.2

- Fix bug130875

- Search member Pada versi sebelumnya, search member dilakukan secara manual dengan button

next. Dengan search member, petugas tinggal memasukkan nama member, kemudian akan

muncul list member dengan nama sesuai keyword.

·                      Issue

- Manual synchronization stock data system penjualan & data warehouse (based on kasir report yang dibuat secara manual)

Betamart: System V.1.3

·                     Pembaharuan & Fitur Tambahan pada Betamart V.1.3

- Automatic synchronization stock data system penjualan & data warehouse

- Automatic generate cashier report - Automatic amount checking of stock data

6. Veri kasi Dan Validasi

LOGIN:

·                     Tujuan yang ingin dicapai : User dapat melakukan login sesuai dengan autorisasinya.

·                     Data Test > > Data Login :

  - Username : C31198

- Password : *******

·                     Skenario :

- User mengisikan username & password

- User menekan button Login

- Apabila terjadi kesalahan penulisan, user dapat menekan button Reset dan eld username & password   akan kembali kosong pabila terjadi kesalahan username atau password

·                     Hasil yang diharapkan :

-  User dapat masuk ke dalam sistem

·                     Hasil yang diperoleh : 1

·                     Status : Ok

PRE: TRANSACTION

·                     Tujuan yang ingin dicapai : user dapat memilih jenis transaksi (member atau non member) dan mencari data pelanggan

·                     Data Test > > Data Input :

-Member Code : M121

-Name : Rino Andriya (manual or automatic lled)

-Address : Karang Menur I No. 10 (automatic lled)

-Deposit : Rp 750.000, 00 (automatic lled)

-Last Transaction : 10 May 2009 (automatic lled)

·                     Skenario :

-User mengisikan member code

-Data lainnya (name, address, deposit, last transaction) akan muncul secara otomatis

-User dapat menggunakan metode lain dengan mengisikan name

-Data lainnya (member code, address, deposit, last transaction) akan muncul secara otomatis

-Untuk nama yang similar, user dapat menekan button > > dan < <

-Setelah data member sesuai, user dapat menekan button Next

-Untuk member baru, user dapat menekan button Register

-Untuk nonmember, user dapat menekan button Non Member

·                     Hasil yang diharapkan :

- Jenis transaksi (member/non member) dapat diidenti kasi dan data member dapat ditampilkan.

·                     Hasil yang diperoleh : 1

·                     Status : OK

MEMBER: REGISTRATION

·                     Tujuan yang ingin dicapai :

- user dapat mendata member baru atau mengubah data member

·                     Data Test > > Data Input :

- Member Code : M203 (automatic generated)

- Name : Samantha Rosalia (manual lled)

- Address : Gajahmada I No. 30 (manual lled)

- Phone No. : +62812339876087

- Deposit : Rp 500.000, 00 (manual lled)

·                     Skenario :

- User menginput data member seperti nama, alamat, no. telp, dan jumlah deposit awal

- User menekan button Save

- Untuk mengubah data member, user dapat menekan button Edit dan menekan button Save setelah melakukan perubahan

·                     Hasil yang diharapkan :

- Member baru dapat atau perubahan data member dapat tercatat pada system.

·                     Hasil yang diperoleh : 1

·                     Status : OK

TRANSACTION:

·                     Tujuan yang ingin dicapai : user dapat mencatat transaksi yang dilakukan pelanggan

·                     Data Test > > Data Input :

-  Cashier : Ranie (Automatic lled from login data)

-  Member Code : M121 (automatic lled from )

- Item Code : S141

- Discount : 10%

·                     Skenario :

- User menginput item code & quantity, lalu menekan button Insert (bisa dilakukan denganbarcode)

- User dapat menginput data barang berdasar nama, dengan memasukkan nama barang pada 

 - Textbox Search lalu menekan button Search

- Field discount akan otomatis terisi apabila pelanggan adalah member Betamart

- Field total akan otomatis terisi (automatic calculate)

- Untuk barang yang tidak jadi dibeli, user dapat menekan button Cancel: untuk mengeluarkan barang tersebut dari list.

- Apabila pencatatan transaksi sudah selesai, user dapat menekan button OK untuk mencetak struk sekaligus menyimpan data transaksi pada database.

- Untuk membatalkan transaksi dan kembali ke halaman sebelumnya, user dapat menekan button Cancel

Untuk mengosongkan eld, user dapat menekan tombol Reset

·                     Hasil yang diharapkan :

- transaksi dapat tercatat pada system dan pencetakan struk dapat dilakukan

·                     Hasil yang diperoleh : 1

·                     Status : OK

4.2.4. Unit Pelayanan Teknis Perpustakaan STT Telkom. 

Extreme Programming (XP) adalah sebuah metodologi pada pengembangan perangkat lunak yang berdasarkan pada simplicity, communication, feedback, dan courage. Salah satu praktik dari XP adalah TDD (Test Driven Development), TDD merupakan teknik pengembangan perangkat lunak yang melakukan tes pada interface-interface dari implementasi perangkat lunak dan semua kode program harus melalui tes. TDD digunakan untuk mengurangi kerugian yang ditimbulkan dari perubahan requirement. Proses yang terdapat dalam TDD salah satunya adalah refactoring. Refactoring adalah teknik untuk merestruktur program dengan teknikteknik tertentu supaya memiliki struktur kode program dan disain yang baik. Pada tugas akhir ini telah dibangun suatu perangkat lunak peminjaman buku di Perpustakaan, studi kasus di Unit Pelayanan Teknis Perpustakaan STT Telkom. Perangkat lunak ini sebelumnya telah dibangun dengan mengutamakan disain bukan implementasi. Selanjutnya perangkat lunak dibangun ulang dengan teknik Test Driven Development supaya memiliki struktur dan disain yang lebih baik. Refactoring dapat dikatakan berhasil jika telah memiliki nilai McCabe's cyclomatic yang rendah yaitu 1 sampai 10. Karena dengan kecilnya nilai McCabe's cyclomatic menyatakan kesederhana perangkat lunak dan memiliki resiko error yang kecil. Pada studi kasus ini nilai rata-rata McCabe's cyclomatic sesudah di-refactoring lebih baik dari pada sebelum di-refactoring. Nilai rata-rata McCabe's cyclomatic sebelum di-refactoring adalah 3,517, sedangkan sesudah di-refactoring adalah 1,241. Reusability object dapat diukur dengan teknik metrics suite, pada studi kasus ini nilai ideal belum dapat dicapai, namun hasilnya lebih baik dari pada hasil sebelum direfactoring. Nilai SCCr sebelum di-refactoring adalah 0,473, sedangkan nilai SCCr sesudah di-refactoring 0,46, sedangkan nilai ideal adalah 0,61 sampai 1. Nilai SCCp sebelum di-refactoring adalah 0,16, sedangkan nilai SCCp sesudah di-refactoring adalah 0,79, sedangkan nilai ideal adalah 0,42 sampai 0,77.

 

Sumber : http://topieks.blogspot.com