PANDUAN AGILE UP Pusat Ilmu Komputer UI v2.2.2
Terakhir Dimodifikasi: 22 Agustus 2007
DAFTAR ISI MODEL TIM PENGEMBANG ................................................................................................2 PROJECT MANAGER ............................................................................................................... 2 SYSTEM ARCHITECT............................................................................................................... 2 BUSINESS ANALYST ............................................................................................................... 2 DEVELOPER LEAD ................................................................................................................. 3 DEVELOPER ........................................................................................................................ 3 TESTER ............................................................................................................................. 3 SKEMA AKTIVITAS PER TAHAPAN DAN ITERASI ...............................................................4 GAMBAR TAHAPAN DAN AKTIFITAS AUP ....................................................................................... 5 TABEL TAHAPAN DAN AKTIFITAS AUP .......................................................................................... 6 DETAIL AKTIVITAS PER TAHAPAN DAN ITERASI............................................................10 INCEPTION ....................................................................................................................... 10 Membina Relasi Project Stakeholder.............................................................................. 10 Initial Requirement Workshop ...................................................................................... 11 Start-Up Meeting ........................................................................................................ 13 Persiapan-Persiapan Awal ............................................................................................ 15 Kick-Off Meeting......................................................................................................... 16 ELABORATION ................................................................................................................... 17 Architectural Workshop ............................................................................................... 17 Business Workshop ..................................................................................................... 18 Architectural Meeting .................................................................................................. 20 Architectural Prototyping ............................................................................................. 22 Follow-Up Meeting ...................................................................................................... 24 CONSTRUCTION ................................................................................................................. 26 Requirement Workshop ............................................................................................... 26 Iteration Plan Meeting ................................................................................................. 29 Modelling................................................................................................................... 31 Code Programming ..................................................................................................... 34 Evaluation and Testing ................................................................................................ 35 User Feedback ........................................................................................................... 36 Installation Documentation .......................................................................................... 37 Operational Meeting.................................................................................................... 38 TRANSITION ..................................................................................................................... 39 Test-Deploy-Acceptance .............................................................................................. 39 Bug Fixing ................................................................................................................. 40 Release Documentation ............................................................................................... 41 Training Workshop...................................................................................................... 42 Release Meeting ......................................................................................................... 43 LAIN-LAIN ......................................................................................................................44 TEMPLATES .....................................................................................................................45 Activity Template........................................................................................................ 45 HAK CIPTA ......................................................................................................................46
1
Model Tim Pengembang Pada bagian ini akan dijelaskan pembagian peran dan tanggung jawab anggota tim pengembang sesuai nama jabatan.
Project Manager Kebutuhan Posisi: 1 orang. Peran: Project Manager. Tanggung Jawab: 1. Mencatat dan mengatur perencanaan alokasi waktu pengerjaan proyek. 2. Mencatat dan mengatur perencanaan alokasi dana pengerjaan proyek. 3. Membangun dan menjaga relasi, melakukan negosiasi dan menjembatani komunikasi antara tim pengembang dengan project stakeholder; sebagai liaison.
System Architect Kebutuhan Posisi: 1 orang. Peran: System Architect, Programmer & Unit Tester. Tanggung Jawab: 1. Bekerja dengan Requirements dan Project Management: a. Memberi prioritas terhadap use case (bisa juga story cards) yang akan direalisasi menjadi software, b. Menganalisa pemilihan arsitektur yang akan dipakai, c. Membuat POC (Proof of Concept---prototype/spike solutions) dari technical decisions yang mengandung resiko teknis. 2. Menghaluskan arsitektur: a. Mengenali desain model yang paling sesuai, b. Mengenali elemen-elemen yang dibutuhkan untuk mewujudkan desain model, c. Memaksimalkan penggunaan (reuse) elemen yang pernah dibangun sebelumnya, d. Membuat struktur solusi (implementasi kode), e. Memikirkan runtime architecture (concurrency, threads, communication, dsb.). 3. Menjaga/Mengontrol integritas arsitektur: a. Membuat ‘Design Guidelines’, b. Membuat ‘Coding Guidelines’, c. Meninjau ulang arsitektur, desain dan pengkodean selama proyek berjalan.
Business Analyst Kebutuhan Posisi: 1 orang. Peran: Business Analyst, Quality Controller, Programmer & Unit Tester. Tanggung Jawab: 1. Memahami kebutuhan end-users, 2. Memahami kebutuhan project stakeholder, 3. Mendokumentasi, memprioritasi dan mengkomunikasikan requirements, 4. Menegosiasikan requirements dan memfasilitasi penerimaan end-users terhadap sistem, 5. Menjaga kesesuaian sistem antara yang diminta dengan yang sedang dikembangkan (pengawas kualitas sistem).
2
Developer Lead Kebutuhan Posisi: 1 orang. Peran: Integration Tester, Programmer & Unit Tester. Tanggung Jawab: 1. Memimpin sekelompok programmer. 2. Mengatur pembagian tugas/task pengkodean kepada programmer lain. 3. Menjaga dan mengawasi kesesuaian delivery code terhadap jadwal yang telah ditetapkan. 4. Memelihara sistem repositori (subversion). 5. Melakukan itegrasi sistem dan integration test sebelum menghantarkan software release ke pengguna.
Developer Kebutuhan Posisi: 1 - 5 orang. Peran: Programmer & Unit Tester Tanggung Jawab: 1. Membuat kode program sesuai arahan desain model sistem yang telah disusun dan disepakati. 2. Mengerjakan tugas/task yang diberikan sesuai batas waktu yang disepakati. 3. Melakukan unit testing terhadap kode program.
Tester Kebutuhan Posisi: 1 / 2 orang. Peran: System Tester Tanggung Jawab: 1. Menemukan dan mengkomunikasikan permasalahan di dalam produk yang dapat memberikan dampak buruk terhadap nilai kegunaannya. 2. Membuat laporan dan menjelaskan dampak buruk yang dapat terjadi serta memberikan saran solusi yang dapat mengurangi atau menyelesaikan masalah tersebut. 3. Menjaga dan menegakkan standar kualitas produk dalam tim. 4. Membuat skenario testing.
3
Skema Aktivitas Per Tahapan dan Iterasi Pada bagian ini akan dipaparkan tahapan dan aktifitas proses Agile Unified Process (AUP). Pemaparan ini merujuk pada produk AUP yang disusun oleh Ambysoft Inc.1 Yang telah disusun sedemikian rupa untuk memenuhi kebutuhan dan untuk dijadikan standar pengerjaan proyek IT di Pusat Ilmu Komputer UI. Gambar 1 di bawah ini memperlihatkan tujuan-tujuan yang hendak dicapai dalam setiap tahapan AUP dan empat buah milestone yang menjadi tolak ukur transisi antar tahapan. Spesifikasi aktifitas dalam setiap tahapan ini diperlihatkan oleh Gambar 2 dan tabel di bagian selanjutnya.
Gambar 1 Skema Dasar Agile Unified Process 1
Ambysoft Inc. merupakan perusahaan konsultan IT asal Kanada yang dimiliki oleh seorang konsultan software engineering, Scott W. Ambler. Penjelasan lengkap produk AUP ini dapat diunduh di http://www.ambysoft.com/downloads/agileUP.zip.
4
Gambar Tahapan dan Aktifitas AUP
Gambar 2 Tahapan dan Milestone dalam AUP
5
Tabel Tahapan dan Aktifitas AUP Tahapan
Aktivitas
Penanggung Jawab
Artifak
Best Practice
Tahapan sesuai fase-fase dalam Unified Process.
normal: aktifitas eksternal, italic: aktifitas internal
Berdasarkan nama jabatan dalam tim.
normal: artifak output,
Istilah praktik kerja untuk meningkatkan agilitas.
Membina relasi project stakeholder.
Project Manager.
Initial Requirement Workshop.
Business Analyst.
INCEPTION
courier: artifak input, italic: artifak alternatif.
Project Specification (jika ada),
Reading.
Company Porfolio (jika ada). Vision, (dokumen) Basic business flowchart (cross functional flow) (Essential) Use Case, Supplementary Specification, (dokumen) Glossary, (dokumen) User Story Card. (notes) Tabel rangkuman requirements hasil preliminary analysis dan prioritasnya (dokumen)
Active Stakeholder Participation, Face-to-Face Interview, Observation, Model Storming.
Start-Up Meeting.
Project Manager.
Meeting Notes (project feasibility, risk estimation, schedule and cost estimation). --optional Gantt Chart & Iteration Plan,(sesuai dengan prioritas yang ditentukan dalam inception) Project Team Plan. –optional
Use the Simplest Tools (POW).
Persiapan-Persiapan Awal: • Instalasi subversion, • Instalasi workstation.
Administrator Perusahaan.
Shopping List. (notes)
-
Kick-Off Meeting.
Project Manager.
Lifecycle Objective (LCO) (dokumen dan presentasi)
-
6
ELABORATION
Architectural Workshop.
System Architect.
Architecture Requirements.(notes untuk ditambahkan ke supplementary specification) Legacy System Documentation (jika ada).
Active Stakeholder Participation, Face-to-Face Interview, Observation. Model Storming.
Business Workshop
Business Analyst
Use Case (update & priority), Supplementary Specification (update), Glossary (update), User Story Card (update & priority), Business Rules (dokumen). Daftar prioritas business flow dan use case
Active Stakeholder Participation, Face-to-Face Interview, Observation.
Architectural Meeting.
System Architect.
Coding Guidelines, pattern guidelines (jika ada) Architecture Model (snapshot).
Use the Simplest Tools (POW), Display Models Publicly, Model Storming.
Architecture Model (update & snapshot). Essential GUI Prototype, Architecture Prototype Code, Scenario Test Plan.
Use the Simplest Tools (POW), Display Models Publicly, Spike Solution, Prove It with Code.
Subversion Guidelines, Architectural Prototyping.
System Architect.
LAKUKAN ITERASI JIKA DIPERLUKAN.
CONSTRUCTION
Follow-Up Meeting
Project Manager
Lifecycle Architecture (LCA) dan presentasi GUI protoype kepada client
-
Requirement Workshop.
Business Analyst.
Use Case (update), Supplementary Specification (update), Glossary (update),
Active Stakeholder Participation, JIT Model and Analysis.
7
User Story Card (update). Iteration Plan Meeting.
Project Manager.
Task Card, Gantt Chart & Iteration Plan (update).
-
Modelling.
System Architect.
Domain Model (snapshot), UML Activity Diagram (snapshot), UML Class Diagram (snapshot), GUI Model, Physical Data Model (snapshot), CRC Card, UML Sequence Diagram (snapshot).
Code Programming.
Developer Lead.
Source Code, Code Documentation, Regression Test Suite.
Evaluation and Testing.
Developer Lead.
User Feedback.
Project Manager.
Acceptance Test (fill & review), Gantt Chart & Iteration Plan (notes), Bugs Report.
Regression Test Suite (update), Acceptance Test, Gantt Chart & Iteration Plan (notes), Bugs Report.
Stand-Up Meeting, Use the Simplest Tools (POW), Depict Models Simply, Apply Modeling Standards, Display Models Publicly, Prove It with Code. Stand-Up Meeting, Test-Driven Development, Refactoring (code and database). Design pattern.
Regression Testing. Daily Build. Bugzilla.
-
LAKUKAN ITERASI JIKA DIPERLUKAN. Installation Documentation.
Developer Lead.
Installation and De-installation Scripts, Configuration management and deployment guide. Training Materials.
-
8
TRANSITION
Operational Meeting
Project Manager.
Initial Operational Capability (IOC)
-
Test-Deploy-Acceptence
Project Manager.
Regression Test Suite (Final), Acceptance Test (Final).
-
Bug Fixing.
Developer Lead.
Bugs Report.
-
Release Documentation.
Developer Lead.
Training Workshop.
Project Manager.
Training Materials (final).
-
Release Meeting.
Project Manager.
Product Release (PR).
-
System Requirement Specification, System Technical Specification, Installation Guide, User Guide.
-
9
Detail Aktivitas Per Tahapan dan Iterasi Pada bagian ini akan dipaparkan penjelasan per aktifitas yang terdapat dalam setiap tahapan dan iterasi AUP.
Inception Banyak Iterasi† : 1 iterasi. Tujuan : Mendefinisikan batasan-batasan lingkup proyek, Memperoleh estimasi kasar terhadap biaya dan waktu, Mendefinisikan resiko yang mungkin terjadi, Menentukan kemampuan Perusahaan terhadap pengerjaan proyek (project feasiblility), Mempersiapkan lingkungan pengerjaan proyek (tim, tempat kerja, instalasi, dsb).
Membina Relasi Project Stakeholder Deskripsi
Hal pertama yang dilakukan oleh project manager untuk memperoleh kepercayaan, dukungan serta akses terhadap proyek yang menjadi sasaran. Hari Ke-/Lama
1 / 1 hari
Best Practice
Reading.
Penanggung Jawab
Project Manager
UP Dicipline
Project Management.
Keterangan
Dapat dilakukan melalui pembicaraan secara informal. Dari sisi internal tim sudah direkrut project triad: Project Manager, System Architect dan Business Analyst. Lihat ”Catatan Tambahan: Perekrutan Anggota Tim” di halaman 44 untuk selengkapnya. Artifak
Project Specification – Dokumen yang dikeluarkan oleh project stakeholder berkaitan tentang spesifikasi umum proyek (nama, deskripsi, latar belakang, visi, misi, tenggat waktu, pendanaan, dsb.). Opsional dan jika ada.
Company Portfolio – Dokumen yang dikeluarkan oleh Perusahaan untuk menunjukkan bukti kemampuan/ Keahlian/pengalaman yang pernah dilakukannya untuk mendukung kesuksesan Perusahaan mendapatkan proyek tsb. Tujuan
Sebagai tahap perkenalan pertama antara perusahaan pengembang dengan project stakeholder. Menentukan jadwal pertemuan untuk Initial Requirement Workshop.
† Catatan: 1 iterasi = 2 minggu. 1 minggu = 5 hari kerja = 40 jam kerja.
(Banyak iterasi yang diberikan dalam dokumen ini bersifat rekomendasi, nilai sesungguhnya tergantung dari besar-kecil proyek).
10
Initial Requirement Workshop Deskripsi
Workshop ini dilakukan untuk mendengarkan secara langsung deskripsi dan kebutuhan-kebutuhan sistem secara lengkap tapi tidak perlu dijelaskan secara mendetail. Hari Ke-/Lama
2 / 1-2 hari
Best Practice
Active Stakeholder Participation, Face-to-Face Interview, Observation, Model Storming.
Penanggung Jawab
Business Analyst
Keterangan
Workshop ini dimanfaatkan oleh tim untuk menuliskan essential use case/user story card. Pertanyaan diajukan untuk memperjelas lingkup proyek. Pertanyaan mengenai adatidaknya software referensi yang serupa yang dapat diteliti.
UP Dicipline
Model Artifak
Vision – Dokumen yang menerangkan visi atas proyek yang akan dikerjakan (executive summary), (Essential) Use Case – Dokumen use case dalam format singkat dan padat; atau cukup dengan judul use case itu sendiri. Dokumen ini menjelaskan functional requirement sistem. Contoh[1]:
Atau penggambaran use case diagram secara cepat di whiteboard atau di kertas[2]:
Supplementary Specification – Dokumen yang berisi semua kebutuhan teknis sistem (isu-isu seperti kemudahan pemakaian, keamanan, kinerja, dsb.). Sering pula disebut sebagai non-functional requirement sistem,
Glossary – Dokumen yang memaparkan istilah-istilah bisnis dan teknis yang terdapat dalam proyek untuk memudahkan pengertian antara tim pengembang dengan project stakeholder, User Story Card – Suatu pendefinisian kebutuhan kasar yang mengandung informasi yang cukup saja sehingga pengembang dapat memberikan perkiraan usaha yang masuk akal untuk mengimplementasikannya. Dipakai dalam pendekatan eXtreme Programming (XP). Contoh[2]:
11
Tujuan
Memperoleh informasi yang cukup untuk melakukan perkiraan-perkiraan awal, seperti: lingkup proyek, waktu dan anggaran dana. Referensi [1] Larman, Craig. Applying UML and Patterns—An Intro to OOA/D and the Unified Process 2nd Ed. Prentice Hall PTR, 2001:46. [2] Ambler, Scott W. “User Stories.” Agile Modelling. 3 April 2006
12
Start-Up Meeting Deskripsi
Rapat yang mengkaji ulang hasil-hasil Initial Requirement Workshop dimana akan dipertanyakan: 1. kesanggupan Perusahaan dalam memenuhi kebutuhan proyek dan manfaat proyek itu sendiri (project feasibility), 2. identifikasi perkiraan resiko yang mungkin ada baik dari segi bisnis, teknis dan organisasi; memberikan strategi untuk mengatasi resiko-resiko tersebut dan disusun dalam suatu ringkasan (risk estimation), 3. identifikasi perkiraan kasar sumber daya, biaya dan waktu berdasarkan informasi besar-kecil lingkup proyek (schedule and cost estimation). Hari Ke-/Lama
3 / 1-2 hari
Best Practice
Use the Simplest Tools (POW).
Penanggung Jawab
Project Manager.
UP Dicipline
Project Management, Deployment, Environment.
Keterangan
Topik opsional dalam rapat ini adalah mengenai perlunya pembentukan tim secara terpisah sesuai kategori masing-masing, contoh: satu tim kecil untuk pengembangan, satu tim untuk menganalisis sistem lama (legacy system) dan tim lain untuk memodifikasi aplikasi komersial (COTS-commercial off the shelf system); atau diperlukan tim khusus untuk melakukan testing dan dokumentasi. Halhal ini perlu dicatat ke dalam Project Team Plan.
Artifak
Meeting Notes – Dokumen yang mencatat hasil-hasil dalam rapat yang berisi project feasibility, risk estimation dan schedule and cost estimation. Untuk poin yang paling akhir (schedule and cost estimation) dapat langsung dicatatkan pada Gantt Chart.
Gantt Chart – Diagram rentang waktu mengenai penjadwalan waktu pengerjaan proyek[1].
Iteration Plan – Dokumen perencanaan proses kerja untuk tahapan selanjutnya---lakukan secara just-intime. Berisikan goal/tujuan dan merupakan deskripsi dari Gantt Chart. Dokumen ini akan selalu mengalami direvisi pada setiap awal iterasi untuk memberikan gambaran proses kerja dan estimasi waktu.
13
Project Team Plan – Dokumen yang berisi perencanaan pembentukan tim yang diperlukan, memuat nama jabatan, nama pemegang jabatan tersebut, jumlah orang yang dilibatkan, perkiraan lama keterlibatan dsb. Dokumen ini bersifat opsional tergantung sifat Perusahaan dan sifat proyek. Tujuan
Mengkaji isu-isu dalam proyek secara matang dan benar untuk dijadikan bahan pertimbangan Perusahaan. Membantu mempersiapkan laporan Lifecycle Objectives (LCO). Referensi
[1] Ambler, Scott W. “Agile Project Planning Tips.” Ambysoft. 30 Juni 2007
14
Persiapan-Persiapan Awal Deskripsi
Persiapan-persiapan awal yang dilakukan oleh Perusahaan untuk keperluan pengerjaan proyek. Selain itu dilakukan juga setup untuk Configuration Management, cth. Subversion, untuk menampung perubahan dokumen dan source code. Hari Ke-/Lama
3, 4 / 1 hari
Best Practice
-
Penanggung Jawab
Administrator Perusahaan.
UP Dicipline
Configure Management, Environment
Keterangan
Daftar kebutuhan: Hardware: workstation, server, printer, proyektor, dan lainnya (scanner, fax, telepon), dsb. Software: IDE, UML Modeller, Aplikasi Office, dsb. Peralatan: whiteboard, spidol, kertas, kamera digital, dsb. Lain-Lain: Internet , ruangan, kubikal, cangkir, buku, dsb. Artifak
Shopping List – Istilah untuk catatan yang berisikan daftar peralatan dan perlengkapan yang mungkin diperlukan untuk pengerjaan proyek. Tujuan
Memberikan fasilitas yang mencukupi bagi tim pengembang agar dapat mengerjakan proyek secara nyaman. Memberikan fasilitas mekanisme penyimpanan dokumen dan source code secara tepat dan berada di satu tempat.
15
Kick-Off Meeting Deskripsi
Rapat milestone I dengan project stakeholder untuk memberikan jawaban atas keberlangsungan proyek: menerima atau menolak, melakukan negosiasi dengan stakeholder dengan berargumentasi pada laporan LCO. Selain itu juga, untuk memperkenalkan anggota-anggota tim pengembang dan perencanaan ke depan apabila proyek disetujui. Hari Ke-/Lama
4, 5 / 1 hari
Best Practice
-
Penanggung Jawab
Project Manager
UP Dicipline
Keterangan
Direkomendasikan audiensi untuk rapat ini termasuk para pejabat tinggi penyedia proyek untuk memperoleh dukungan dan perhatian agar proyek dapat berjalan dengan lancar. Sebelum rapat ini diadakan, anggota tim lainnya sudah terekrut.
Project Management. Artifak
Lifecycle Objectives (LCO) – Dokumen yang menjadi milestone pertama agar dapat berpindah dari tahapan Inception ke tahapan Elaboration. Adapun isi utama dari laporan ini meliputi[1]: 1. Scope concurrence. Project stakeholder menerima batasan-batasan dalam proyek yang diajukan (penyampaian cross functional flow). 2. Initial requirement definition. Terdapat persamaan pengertian terhadap kebutuhan yang ditangkap kedua belah pihak, dalam skala pengertian secara garis besar, dan telah disetujui bersama. 3. Plan concurrence. Stakeholder menyetujui pengajuan awal besar dana dan perkiraan waktu. 4. Risk acceptance. Resiko-resiko telah diidentifikasikan, diberi bobot serta telah diberikan strategi pemecahan yang dapat diterima bersama. 5. Process acceptance. Skema proses pengerjaan (metodologi), dalam hal ini pendekatan AUP, telah disusun dan diketahui bersama. 6. Feasibility. Proyek tersebut dinilai masuk akal dan memiliki nilai dari sudut pandang bisnis, teknis dan operasional. 7. Project plan. Perencanaan proses kerja untuk tahap selanjutnya.
8. Portfolio compliance. Memperlihatkan apakah Perusahaan memang spesialis dalam menangani lingkup proyek yang diterimanya.
Tujuan
Memberikan jawaban Perusahaan atas keberlangsungan proyek: menerima atau menolak. Meminta tanggapan atas isu-isu teknis dan non-teknis berkaitan dengan proyek yang telah diidentifikasikan oleh Perusahaan. Meminta perhatian dan dukungan dari para pejabat tinggi organisasi. Referensi
[1] Ambler, Scott W. “Milestones.” Agile UP. 31 May 2006
16
Elaboration Banyak Iterasi : 1 – 2 iterasi. Tujuan : Mengidentifikasikan arsitektur sistem yang akan diimplementasikan, Memvalidasi arsitektur yang hendak diimplementasikan.
Architectural Workshop Deskripsi
Pertemuan dengan narasumber/end-users untuk membahas isu resiko-resiko teknis, skema deployment, GUI prototype. Hari Ke-/Lama
1 / 1-2 hari
Best Practice
Active Stakeholder Participation, Face-to-Face Interview, Observation. Model Storming.
Penanggung Jawab
System Architect
Keterangan
Pertemuan ini umumnya dilakukan ke Departemen IT organisasi bersangkutan.
UP Dicipline
Model. Artifak
Architecture Requirements – Catatan pertemuan dengan klien seputar isu-isu yang berkaitan dengan masalah teknis.
Legacy System Documentation – Jika proyek juga menyertakan isu pemakaian sistem lama (legacy system), disarankan untuk meminta dokumentasi mengenai hal tersebut untuk dapat dipelajari. Tujuan
Mengetahui detail isu-isu resiko teknis seperti penggunaan teknologi baru, kebutuhan load/stress sistem yang signifikan, integrasi dengan sistem lama (legacy system), Memperoleh gambaran desain arsitektur yang tepat dan dapat diimplementasikan.
17
Business Workshop Deskripsi
Pertemuan dengan narasumber/end-users (umumnya kepada departemen yang bersinggungan dengan sistem) untuk membahas isu resiko-resiko bisnis. Hari Ke-/Lama
Best Practice
Keterangan
Prioritas Kebutuhan: 1. Merupakan inti/core sistem, 2. Memiliki nilai bisnis tertinggi, 3. Memiliki resiko terbesar.
Active Stakeholder Participation, Face-to-Face Interview, Observation.
1 / 1- 2 hari. Penanggung Jawab
Business Analyst.
UP Dicipline
Model. Artifak
Use Case – baca halaman 11. Perbarui isinya untuk memberikan nilai/angka prioritas dan estimasi. Perbarui isinya apabila terdapat beberapa detail tambahan. Tambahkan jika terdapat use case baru. Supplementary Specification – baca halaman 11. Perbarui isinya. Glossary – baca halaman 11. Perbarui isinya. User Story Card - baca halaman 11. Perbarui isinya untuk memberikan nilai/angka prioritas dan estimasi. Tambahkan jika terdapat user story baru.
Business Rules – mendefinisikan aturan atau batasan yang terdapat dalam struktur bisnis atau yang dapat mempengaruhi tingkah-laku bisnis. Business Rules umumnya fokus terhadap kontrol akses, kalkulasi bisnis dan aturan-aturan bisnis. Contoh[1]:
1.
BR123 Tenured professors may administer student grades.
2.
BR124 Teaching assistants who have been granted authority by a tenured professor may administer student grades.
3.
BR177 Table to convert between numeric grades and letter grades.
4.
BR245 All master’s degree programs must include the development of a thesis.
Atau contoh lain yang lebih detail[2]: Name: Identifier: Description:
Example:
Source:
Related rules:
Tenured professors may administer student grades BR123 Only tenured professors are granted the ability to initially input, modify, and delete grades students receive in the seminars that they and they only instruct. They may do so only during the period a seminar is active. Dr. Bruce, instructor of “Biology 301 Advanced Uses of Gamma Radiation,” may administer the marks of all students enrolled in that seminar, but not those enrolled in “Biology 302 Effects of Radiation on Arachnids,” which is taught by Dr. Peters. University Policies and Procedures Doc ID: U1701 Publication date: August 14, 2000 BR12 Qualifying For Tenure BR65 Active Period for Seminars BR200 Modifying Final Student Grades
18
Tujuan
Mengetahui kebutuhan yang memiliki prioritas tertinggi sehingga dapat diberikan estimasi waktu dan usaha untuk mengimplementasikannya. Mengidentifikasikan critical business rules dan business logic. Membantu perencanaan arsitektur sistem. Referensi
[1] Ambler, Scott W. ”Business Rules.” Agile Modelling [2] Ibid.
19
Architectural Meeting Deskripsi
Rapat susulan dalam internal tim untuk membahas kembali hasilhasil yang didapat dari Architectural Workshop dan Business Workshop. Brain-storming ide arsitektur, memutuskan model arsitektur, pengenalan kerangka kerja coding, standar kerja dan praktik-praktiknya. Hari Ke-/Lama
2 / 1-2 hari
Best Practice
Use the Simplest Tools (POW), Display Models Publicly, Model Storming.
Penanggung Jawab
System Architect
Keterangan
Seluruh anggota tim wajib mengikuti rapat ini. Ada baiknya mengundang pula narasumber/end-users untuk memberikan beberapa masukan.
UP Dicipline
Model, Deployment. Artifak
Coding Guidelines – Dokumen panduan standar-standar pembuatan kode program. Ditambah pula dengan kesepakatan kerangka kerja coding.
Subversion Guidelines – Dokumen petunjuk penggunaan Subversion serta praktik-praktik standar dalam pemanfaatan direktori di Subversion untuk menyimpan perubahan, penyuntingan, pengambilan, dsb.
Architecture Model – Gambar model arsitektur yang telah disepakati dan diketahui bersama. Free-Form Diagram[1]:
20
Network Diagram[2]:
UML Deployment Diagram[3]:
Tujuan
Mengembangkan ide model arsitektur yang akan dipakai; meliputi juga jenis teknologi, tools, library API dsb. Membahas isu-isu teknis yang dinilai baru oleh Perusahaan. Mencari strategi pemecahan, penyusunan tim, perekrutan orang baru. Memperkenalkan standar pengkodean, praktik-praktik dan desain sistem kepada anggota baru. Referensi [1] Ambler, Scott W. “Free-Form Diagrams.” Agile Modelling [2] Ambler, Scott W. “Networks Diagrams.” Agile Modelling [3] Ambler, Scott W. “UML 2 Deployment Diagram.” Agile Modelling
21
Architectural Prototyping Deskripsi
Kegiatan untuk membangun prototipe arsitektur dan dapat dibuktikan (dengan kode) bahwa arsitektur tersebut mampu memenuhi pengimplementasian proyek secara nyata. Membangun pondasi atau kerangka kerja. Hari Ke-/Lama
2, 3 / 2-8 hari
Best Practice
Use the Simplest Tools (POW), Display Models Publicly, Spike Solution, Prove It with Code, Stand-Up Meeting.
Penanggung Jawab
System Architect
Keterangan
Prototipe yang dimaksud bukan berarti nanti akan dibuang dan dibuat ulang, melainkan prototipe yang akan digunakan nanti dalam implementasi.
UP Dicipline
Model, Implementation, Test. Artifak
Architecture Model – lihat halaman 20 dan perbarui snapshot sesuai kondisi riil kode program. Essential GUI Prototype – Menampilkan kebutuhan antarmuka yang berfokus pada hal kegunaan, kebutuhan dan bukan desain. Dapat pula langsung diimplementasikan menjadi kode pemprograman GUI sebatas dapat dinavigasikan ke halaman-halaman yang diperlukan. Contoh[1]:
22
Architecture Prototype Code – Kode prototipe dari arsitektur yang akan dipakai ketika implementasi tahapan Construction.
Regression Test Suite – Kumpulan test case dan kode yang dapat dijalankan dari segi teknis. Nantinya regression test suite ini akan terdiri dari macam-macam jenis testing seperti unit test, integration test, performance test, capability test, security test, dsb. Test suite ini akan banyak mengalami perkembangan di Construction. Catatan: Perbarui juga beberapa dokumen yang sekiranya mengalami perubahan, seperti Iteration Plan untuk Elaboration berikutnya (jika ada). Tujuan
Membuktikan bahwa model arsitektur dapat dipakai dan bukan hanya tergambar suatu model saja. Referensi [1] Ambler, Scott W. “Essential (Low Fidelity) User Interface Prototypes.” Agile Modelling
23
Follow-Up Meeting Deskripsi
Rapat milestone II dengan project stakeholder untuk memberikan kepastian serta kesanggupan pengerjaan proyek atas dasar kesiapan dan kematangan arsitektur sistem. Hari Ke-/Lama
3 / 1 hari
Best Practice
-
Penanggung Jawab
Project Manager
Keterangan
Direkomendasikan audiensi untuk rapat ini meliputi juga para pejabat tinggi penyedia proyek untuk memperoleh dukungan dan perhatian agar proyek dapat berjalan dengan lancar.
UP Dicipline
Project Management. Artifak
Lifecycle Architecture (LCA) – Dokumen yang menjadi milestone kedua agar dapat berpindah dari tahapan Elaboration ke tahapan Construction. Adapun isi utama dari laporan ini meliputi[1]: 1. Vision stability. Visi proyek telah dimapankan dan lebih realistik, 2. Architecture stability. Arsitektur sistem telah disepakati bahwa telah stabil dan dapat dipakai untuk memenuhi kebutuhan sistem. Prototipe arsitektur telah terbukti dapat mengatasi isu-isu resiko teknis. 3. Risk acceptance. Resiko telah dimengerti lebih matang, diberi penilaian dan dibuatkan strategi yang wajar, yang dapat diterima. 4. Project plan. Iteration plan untuk tahap Construction dalam bentuk strategi timebox/sandbox*) untuk memberikan gambaran proses kerja berikutnya. 5. Enterprice compliance. Apakah arsitektur sistem menampilkan realitas dari sistem yang dimiliki client? *) Catatan: Timebox/Sandbox[2] merupakan skema pemilahan (pemporsian) waktu untuk implementasi dan demo aplikasi ke end-users (untuk dimintakan feedback). Dapat disusun alokasi waktu riil kedalam Gantt Chart.
24
Tujuan
Memberikan penegasan bahwa Perusahaan telah benar-benar siap dari segi kematangan arsitektur sistem. Meminta dukungan dan perhatian atas keseriusan proyek yang akan segera diimplementasikan. Referensi
[1] Ambler, Scott W. “Milestones.” Agile UP. 31 May 2006 [2] Ibid.
25
Construction Banyak Iterasi : 2 – 8 iterasi. Tujuan : Memodelkan, membangun dan mengujis sistem. Membuat dokumentasi yang mendukung.
Requirement Workshop Deskripsi
Pertemuan dengan narasumber/end-user yang membahas detail kebutuhan yang telah ditargetkan oleh tim pengembang. Selidiki kebutuhan tersebut dalam lingkup yang terbatas saja sesuai perencanaan---secara just-in-time (JIT). Hari Ke-/Lama
1 / 1-2 hari
Best Practice
Active Stakeholder Participation, JIT Model and Analysis.
Penanggung Jawab
Project Manager
UP Dicipline
Keterangan
Kebutuhan yang telah ditargetkan ini diambil berdasarkan kebutuhan yang memiliki prioritas tertinggi. Diambil kira-kira 10%-20% dari keseluruhan requirement tergantung dari kesanggupan antara besar lingkup dengan alokasi waktu iterasi (timebox/sandbox).
Model Artifak
Use Case – lihat halaman 11. Perbarui isinya. Ubah menjadi Casual Format[1] atau Fully-dressed Format[2]. Contoh casual format:
26
Terkadang untuk mempermudah pengertian terhadap use case dapat dibuat secara visual flow chart[3]:
Atau melalui penggambaran UML activity diagram[4]:
27
Supplementary Specification - lihat halaman 11. Perbarui isinya. Glossary - lihat halaman 11. Perbarui isinya. User Story Card - lihat halaman 11. Perbarui isinya. Tujuan
Mengidentifikasikan informasi mendetail mengenai kebutuhan sistem sehingga mencukupi agar dapat diimplementasikan---pembuatan model dan kode program. Referensi [1] Larman, Craig. Applying UML and Patterns—An Intro to OOA/D and the Unified Process 2nd Ed. Prentice Hall PTR, 2001:47. [2] Ibid:50. [3] Ambler, Scott W. “Flow Charts.” Agile Modelling [4] Ambler, Scott W. “UML 2 Activity Diagram.” Agile Modelling
28
Iteration Plan Meeting Deskripsi
Pertemuan internal tim pengembang dalam membahas hasil Requirement Workshop, memecahnya menjadi beberapa tugas/task untuk menentukan strategi implementasi kebutuhan. Hari Ke-/Lama
2 / 1 hari
Best Practice
-
Penanggung Jawab
Project Manager
UP Dicipline
Model, Deployment, Project Management.
Keterangan
Bagan Gantt Chart akan diperhalus dimana garis-garis waktu akan dipecah-pecah sesuai detail pembagian tugas. Dalam menentukan berapa lama waktu yang direncanakan per pembagian tugas sebaiknya ditanyakan langsung kepada orang yang bertanggung jawab terhadap tugas/task tersebut. Artifak
Task Card – sebuah teks yang mendeskripsikan apa saja yang harus dilakukan untuk menyelesaikan suatu tugas. Contoh[1]:
Sebuah task card juga dapat berupa sketsa alur logik suatu tugas[2]:
29
Gantt Chart & Iteration Plan – lihat halaman 13. Perbarui isinya. Tujuan
Menentukan goal/tujuan yang menjadi development release, Melakukan pemecahan tugas/task terhadap system use case/user story, Menetapkan alokasi waktu iterasi dan sumber daya (programmer) terhadap task yang telah disusun. Referensi [1] Ambler, Scott W. “Agile Modelling Throughout the XP Lifecycle.” Agile Modelling [2] Ibid.
30
Modelling Deskripsi
Kegiatan penggambaran suatu porsi task/tugas ke dalam bentuk diagram konseptual yang sederhana tetapi mencukupi untuk memulai dilakukan pengkodean. Hari Ke-/Lama
2, 3 / 1 hari
Best Practice
Stand-Up Meeting, Use the Simplest Tools (POW), Depict Models Simply, Apply Modeling Standards, Model with Others, Display Models Publicly, Prove It with Code.
Penanggung Jawab
System Architect
UP Dicipline
Model.
Keterangan
Aktifitas modelling dapat berjalan secara paralel bersama code programming dengan porsi tertentu. Stand-up meeting bertujuan untuk melontarkan isu-isu seperti perubahan desain, perubahan jadwal, bugs, erros, progress dsb., guna menjaga komunikasi antar anggota tim. Pertemuan ini hanya +/- 30 menit di setiap awal hari. Penting diperhatikan bahwa pertemuan ini bukan untuk membicarakan solusi permasalahan atau topik-topik detail yang memakan waktu lama; hal-hal seperti itu dibicarakan setelah pertemuan berakhir. Artifak
Domain Model – model konseptual dari sistem yang mendeskripsikan entitas-entitas yang terlibat dan relasinya. Model ini menampilkan relasi diantara entitas-entitas dalam sistem dan terkadang teridentifikasi juga nama atribut dan metode. Contoh[1]:
UML Activity Diagram – lihat halaman 26.
31
UML Sequence Diagram – pemodelan dari alur logik sistem secara visual yang digunakan untuk dokumentasi dan juga untuk memvalidasi logik yang dibuat. Diagram ini dipakai untuk memodelkan: pemakaian skenario, logik metode, dan logik layanan. Contoh[3]:
GUI Model – Pemodelan lebih lanjut dari Essential GUI Prototype yang sudah mengarah ke suatu implementasi teknologi tertentu (HTML web-based, GUI desktop, command-line). Contoh[5]:
32
CRC Card – Class Responsibility Colaborator Card, digunakan untuk mengeksplorasi pemodelan secara struktural ketika melakukan desain obyek. Contoh[4] menceritakan suatu entitas bisnis class Customer dimana entitas ini memiliki responsibility seperti ‘places orders’, ‘knows name’, ‘knows address’ dsb. (nanti akan menjadi nama-nama atribut) dan memiliki colaborator yaitu class Order.
Physical Data Model – Pemodelan ini memungkinkan pengembang mengeksplorasi isu-isu yang hanya berkaitan dengan data. Perbedaan dengan Domain Model adalah bahwa selain data dapat juga dipakai untuk mengeksplorasi tingkah laku (behavior) suatu domain. Contoh[2]:
Tujuan
Membantu pengertian terhadap bisnis suatu organisasi, domain permasalahan proyek dan mengidentifikasi solusi yang dapat memecahkan masalah tersebut dari segi visualisasi. Referensi [1] Ambler, Scott W. ”UML 2 Class Diagram.” Agile Modelling [2] Ambler, Scott W. ”Data Modelling 101.” Agile Data [3] Ambler, Scott W. ”UML 2 Sequence Diagram.” Agile Modelling [4] Ambler, Scott W. ”Class Responsibility Colaborator (CRC) Models.” Agile Modelling [5] Ambler, Scott W. ”User Interface Prototypes.” Agile Modelling
33
Code Programming Deskripsi
Kegiatan implementasi sistem ke dalam bentuk kode program atas dasar pengertian kebutuhan dan konsep desain. Hari Ke-/Lama
3 / 1 – H-2 hari
Best Practice
Stand-Up Meeting, Test-Driven Development, Refactoring.
Implementation, Test
Penanggung Jawab
Developer Lead
UP Dicipline
Keterangan
Jangan lupa kode sumber dikerjakan dibawah kontrol Configuration Management (spt. Subversion). Jangan lupa kode sumber perlu disertakan komentar/catatan yang sesuai dan jelas. Jangan lupa melakukan unit testing secara pribadi ke untuk memvalidasi fungsi-fungsi yang dibuat. Artifak
Source Code – Kode sumber dari modul-modul aplikasi yang dapat dieksekusi. Sesuaikan dengan standar pengkodean Perusahaan. Struktur kode sumber disesuaikan dengan model arsitektur yang telah disusun.
Code Documentation – Komentar/catatan dalam kode sumber untuk memudahkan pengertian terhadap fungsi yang dibuat. Sesuaikan dengan standar pengkodean Perusahaan.
Regression Test Suite – lihat halaman 22. Integrasikan unit testing ke dalam suatu kumpulan testing. Perbarui dan tambahkan isinya. Tujuan
Menghasilkan kode aplikasi yang dapat dieksekusi dan tervalidasi.
34
Evaluation and Testing Deskripsi
Kegiatan periodik untuk menguji integrasi sistem dari modulmodul yang telah dikerjakan bersama. Hari Ke-/Lama
~3 / 1 hari
Best Practice
Regression Testing, Daily Build.
Penanggung Jawab
Developer Lead
Keterangan
Sesuaikan jadwal kegiatan ini dengan iteration plan.
UP Dicipline
Test Artifak
Regression Test Suite – lihat lihat halaman 22. Integrasikan integration testing ke dalam suatu kumpulan testing. Perbarui dan tambahkan isinya.
Acceptence Test – Dokumen yang berisikan pengujian kebutuhan dari segi bisnis secara black-box dimana sistem harus sanggup memenuhi hal tersebut. Digunakan dalam meminta feedback dari end-users. Perbarui dan tambahkan setiap kali selesai melakukan Evaluation and Testing.
Gantt Chart & Iteration Plan – lihat halaman 13. Perbarui isinya apabila terjadi bug-fixing. Apabila tenggang waktu iterasi telah berakhir sedangkan ada tugas/task yang belum terselesaikan, buat catatan dalam iteration plan ini agar dapat diatur/menjadi ”hutang” untuk iterasi selanjutnya.
Bugs Report – Laporan berisikan bug-bug kode program yang harus ditangani segera. Gunakan tools bug reporting sehingga lebih memudahkan pengaturannya. Tujuan
Memvalidasi modul-modul sistem agar dapat terintegrasi dengan benar; fungsi-fungsi dapat bekerja sama dengan tepat. Memindahkan Development Code ke Release Candidate Code.
35
User Feedback Deskripsi
Pertemuan dengan end-users untuk meminta tanggapan/feedback atas sistem atau modul sistem yang telah diimplementasikan. Hari Ke-/Lama
4 / 1 hari
Best Practice
-
Penanggung Jawab
Project Manager
Keterangan
Lakukan aktifitas ini di setiap akhir iterasi.
UP Dicipline
Deployment, Test. Artifak
Acceptence Test – lihat halaman 35. Evaluasi dan konsolidasikan hasil penerimaan end-users terhadap sistem atau modul sistem yang dihasilkan.
Gantt Chart & Iteration Plan – lihat halaman 13. Apabila ada yang kurang sesuai atau penambahan, hal tersebut menjadi ”catatan hutang” untuk diperbaiki dalam iterasi berikutnya.
Bugs Report – lihat halaman 35. Tujuan
Meminta tanggapan secara cepat dan bertahap dari narasumber/end-user terhadap sistem atau modul sistem yang telah berhasil diimplementasikan. Mengurangi resiko kesalahpahaman antara kebutuhan user dengan tim pengembang sehingga mudah dilakukan penyesuaian.
36
Installation Documentation Deskripsi
Menyusun dokumentasi instalasi sistem sesuai deployment diagram dan mulai menyusun bahan-bahan training workshop. Hari Ke-/Lama
5 / 1-2 hari
Best Practice
-
Penanggung Jawab
Developer Lead.
Keterangan
Dibuatkan pula shopping list untuk organisasi sebagai bentuk penyediaan barang.
UP Dicipline
Deployment, Environment Artifak
Installation and De-installation Scripts – Catatan instalasi dan de-instalasi sistem. Akan sangat membantu apabila sistem dikemas dalam bentuk installation package yang lebih memudahkan instalasi bagi orang awam.
Training Materials – Modul-modul pelatihan untuk dipakai sebagai alat bantu training workshop. Tujuan
Persiapan akhir agar sistem siap untuk diinstalasi ke dalam organisasi.
37
Operational Meeting Deskripsi
Rapat milestone III dengan project stakeholder sebagai tahap penutupan pengerjaan proyek dan menyatakan bahwa sistem telah (besar kemungkinan) diterima dan siap dihantarkan ke organisasi. Hari Ke-/Lama
6 / 1 hari
Best Practice
-
Penanggung Jawab
Project Manager
Keterangan
Penutupan pengerjaan proyek mengandung arti tidak ada bentuk permintaan kebutuhan tambahan kecuali masalah bug-fixing.
UP Dicipline
Project Management. Artifak
Initial Operational Capability (IOC) - Dokumen yang menjadi milestone ketiga agar dapat berpindah dari tahapan Construction ke tahapan Transition. Adapun isi utama dari laporan ini meliputi[1]: 1. System stability. Sistem (software) dan dokumen pendukung telah dapat diterima (matang dan stabil) sehingga dapat dihantarkan ke pengguna. 2. Prepared stakeholders. Stakeholders (dan proses bisnis) telah siap untuk sistem dihantarkan. Berikan jadwal training workshop dan estimasi jadwal deployment and installation. 3. Risk acceptance. Resiko telah dimengerti lebih matang, diberi penilaian dan dibuatkan strategi yang wajar, yang dapat diterima. 4. Cost and estimate acceptance. Pengeluaran aktual dapat diterima dan estimasi untuk pengeluaran lainnya ke depan berjumlah masuk akal. 5. Project plan. Informasi rencana untuk tahap Transition. 6. Enterprice compliance. Apakah produk yang dihasilkan telah sesuai terhadap standar bisnis organisasi? Tujuan
Memberi keyakinan dan penegasan bahwa sistem telah siap dihantarkan ke stakeholders sesuai dengan keinginan proyek. Referensi [1] Ambler, Scott W. “Milestones.” Agile UP. 31 May 2006
38
Transition Banyak Iterasi : 1 - 2 iterasi. Tujuan : Menguji sistem secara keseluruhan. Menghantarkan dan menginstalasikan sistem ke organisasi.
Test-Deploy-Acceptance Deskripsi
Aktifitas ini memiliki tiga hal penting: 1. Final Testing yang dilakukan di dalam lingkungan tim pengembang sebelum dihantarkan ke end-users. 2. Deployment and Installation yang dilakukan di dalam organisasi end-users. 3. Final Acceptance Test yang dilakukan di dalam organisasi end-users untuk menguji kesesuaian sistem terhadap kebutuhan proyek. Hari Ke-/Lama
1 / 3-5 hari
Apabila ada bug, beri catatan untuk aktifitas bug-fixing dan prioritasnya.
Best Practice
-
Penanggung Jawab
Business Analyst Project Manager
Keterangan
Agenda rencana: Hari 1-2: Final Testing. Hari 3-4: Deployment and Installation. Hari 5: Final Acceptance Test.
UP Dicipline
Test, Deployment Artifak
(Final) Regression Test Suite – lihat halaman 22. Seluruh testing dalam test suite ini dieksekusi dan diyakinkan bahwa telah valid secara keseluruhan.
(Final) User Acceptence Test – lihat halaman 35. End-users menandatangani UAT sebagai tanda sistem telah berhasil memenuhi kebutuhan proyek. Tujuan
Pengujian terakhir, instalasi dan penerimaan pengguna dalam menghadirkan sistem dalam organisasi.
39
Bug Fixing Deskripsi
Revisi kode sumber yang tidak valid. Identifikasikan bugs yang kira-kira kritis agar mempunyai prioritas tertinggi untuk diperbaiki. Hari Ke-/Lama
2 / H-5 hari.
Best Practice
-
Penanggung Jawab
Developer Lead
Keterangan
Bug-fixing dilakukan sampai tenggat waktu peluncuran sistem. Apabila dalam jangka waktu tersebut tidak dapat mencakup keseluruhan bugfixing maka keluarkan patch di saat sistem sudah berjalan.
UP Dicipline
Implementation. Artifak
Bugs Report – lihat halaman 35. Tujuan
Pemeliharaan dan garansi Perusahaan sebagai bentuk tanggung jawab pembuatan sistem.
40
Release Documentation Deskripsi
Penyusunan dan pengumpulan seluruh artifak yang terjadi selama proses pengerjaan sistem ke dalam bentuk dokumentasi formal. Hari Ke-/Lama
2 / 1 – H-3 hari
Best Practice
-
Penanggung Jawab
Developer Lead.
Keterangan
Seluruh gambar model (snapshot) diseleksi dan diubah menjadi gambar formal menggunakan UML tool.
UP Dicipline
Deployment. Artifak
System Requirement Specification – Dokumen kumpulan kebutuhan-kebutuhan sistem yang telah diidentifikasi dari tahapan Inception sampai Construction, seperti: vision, use case, supplementary specification, glossary, project plan.
System Technical Specification – Dokumen kumpulan data-data teknis pengembangan sistem dari tahapan Inception sampai Construction, seperti: architecture model, domain model, data model, UML, code API.
Installation Guide – Dokumen petunjuk instalasi sistem. User Guide – Dokumen petunjuk pemakaian sistem. Tujuan
Mendokumentasikan seluruh proses pengembangan sistem secara formal.
41
Training Workshop Deskripsi
Melatih seluruh end-users untuk memperkenalkan penggunaan sistem. Hari Ke-/Lama
3 / 2-3 hari
Best Practice
-
Penanggung Jawab
Project Manager
Keterangan
-
UP Dicipline
Deployment Artifak
Training Materials – lihat halaman 37. Tujuan
Melatih seluruh end-users untuk memperkenalkan penggunaan sistem.
42
Release Meeting Deskripsi
Rapat milestone IV dengan project stakeholder bahwa mereka puas dan menerima sistem yang telah diimplementasikan. Hari Ke-/Lama
4 / 1 hari
Best Practice
-
Penanggung Jawab
Project Manager
Keterangan
Direkomendasikan audiensi untuk rapat ini meliputi seluruh stakeholder terutama yang dahulu pernah menghadiri rapat awal pengadaan proyek.
UP Dicipline
Project Management. Artifak
Product Release (PR) – Dokumen yang menjadi milestone keempat untuk mengakhiri proyek. Adapun isi utama dari laporan ini meliputi[1]: 1. Business stakeholder acceptance. Project stakeholders merasa puas dan menerima sistem.
2. Operations acceptance. End-users yang bertanggung jawab mengoperasikan sistem merasa puas dan sesuai dengan proses bisnis yang telah disepakati.
3. Support acceptance. End-users yang bertanggung jawab memberikan bantuan merasa puas dan sesuai dengan proses bisnis yang telah disepakati.
4. Cost and estimate acceptance. Besar pengeluaran dan biaya aktual dapat diterima dan masuk akal. Tujuan
Rapat penutupan proyek. Referensi [1] Ambler, Scott W. “Milestones.” Agile UP. 31 May 2006
43
Lain-Lain Catatan Tambahan 1. PEREKRUTAN ANGGOTA TIM Di tahap Inception ini, anggota tim yang diperlukan cukup 3 jenis jabatan saja yaitu: Project Manager, System Architecture dan Business Analyst. Perekrutan ini dinilai cukup sebagai permulaan dimana batasan-batasan lingkup proyek, kemungkinan proyek dapat dikerjakan, resiko, estimasi waktu dan dana perlu dikaji terlebih dahulu dan mendapatkan persetujuan. Nantinya setelah berhasil melewati Kick-Off Meeting---proyek berhasil didapatkan, proses perekrutan selanjutnya dilakukan untuk mempekerjakan Developer Lead dan Full-Time Programmer, atau spesialis lainnya (DB Administrator, Network Specialist, Modeller, Documenter, dan sebagainya) tergantung kebutuhan atau yang telah terdaftar dalam Project Team Plan. 2. SELALU SIMPAN DOKUMEN DALAM SISTEM REPOSITORI Hal ini harus selalu diingat ketika bekerja dalam suatu tim dimana seluruh produk proyek (dokumen, source code, revisi, dsb.) harus tersimpan secara terpusat di satu tempat. Ide dari Configuration Management discipline dari AUP adalah untuk mengatur akses terhadap produkproduk tersebut agar tetap konsisten seiring perjalanan waktu proyek, termasuk memberikan versi (versioning), mengontrol dan mengatur perubahan yang terjadi.
44
Templates Silahkan menggunakan template ini (copy-and-paste) untuk melakukan modifikasi penambahan aktifitas dalam suatu tahapan.
Activity Template Deskripsi
Hari Ke-/Lama
Best Practice
Penanggung Jawab
UP Dicipline
Keterangan
Artifak Tujuan Referensi
45
Hak Cipta Dokumen panduan ini disusun dan disesuaikan oleh Josef untuk keperluan pengerjaan proyek IT Pusat Ilmu Komputer UI dengan sumber rujukan kepada produk Agile Unified Product Ambysoft Inc. This page is tailored with permission from Ambysoft Inc.'s Agile UP Product Original page is Copyright © 2005-2006 Ambysoft Inc. Tailored page is Copyright © 2007 Pusilkom UI
46
