Pusilkom AUP versi 2.2.2

1

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

2

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

3

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.

4

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.

5

Gambar Tahapan dan Aktifitas AUP

Gambar 2 Tahapan dan Milestone dalam AUP

6

Tabel Tahapan dan Aktifitas AUP Tahapan Tahapan sesuai fase-fase dalam Unified Process.

Aktivitas normal: aktifitas eksternal, italic: aktifitas internal

Penanggung Jawab Berdasarkan nama jabatan dalam tim.

Artifak normal: artifak output, courier: artifak input,

italic: artifak alternatif.

Best Practice Istilah praktik kerja untuk meningkatkan agilitas.

Membina relasi project stakeholder.

Project Manager. Project Specification (jika ada), Company Porfolio (jika ada).

Reading.

Initial Requirement Workshop. Business Analyst. 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) -

INCEPTION

Kick-Off Meeting. Project Manager. Lifecycle Objective (LCO) (dokumen dan presentasi)

-

7

Architectural Workshop. System Architect. Architecture Requirements.(notes untuk ditambahkan ke supplementary specification)

Legacy System Documentation (jika ada).


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


Face-to-Face Interview, Observation.

Architectural Meeting. System Architect. Coding Guidelines, pattern guidelines (jika ada)

Subversion Guidelines, Architecture Model (snapshot).

Use the Simplest Tools (POW),

Display Models Publicly, Model Storming.

Architectural Prototyping. System Architect. 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.

LAKUKAN ITERASI JIKA DIPERLUKAN.

ELABORATION

Follow-Up Meeting Project Manager Lifecycle Architecture (LCA) dan presentasi GUI protoype kepada client

-

CONSTRUCTION

Requirement Workshop. Business Analyst. Use Case (update), Supplementary Specification

(update), Glossary (update),


JIT Model and Analysis.

8

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

Stand-Up Meeting, Use the Simplest Tools

(POW), Depict Models Simply, Apply Modeling Standards, Display Models Publicly, Prove It with Code.

Code Programming. Developer Lead. Source Code, Code Documentation, Regression Test Suite.

Stand-Up Meeting, Test-Driven Development, Refactoring (code and

database). Design pattern.

Evaluation and Testing. Developer Lead. Regression Test Suite (update), Acceptance Test, Gantt Chart & Iteration Plan (notes), Bugs Report.

Regression Testing. Daily Build. Bugzilla.

User Feedback. Project Manager. Acceptance Test (fill & review), Gantt Chart & Iteration Plan (notes), Bugs Report.

-

LAKUKAN ITERASI JIKA DIPERLUKAN.

Installation Documentation. Developer Lead. Installation and De-installation Scripts,

Configuration management and deployment guide.

Training Materials.

-

9

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. System Requirement Specification, System Technical Specification, Installation Guide, User Guide.

-

Training Workshop.

Project Manager. Training Materials (final).

-

TRANSITION

Release Meeting.

Project Manager. Product Release (PR).

-

10

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

11

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

UP Dicipline

Model

Keterangan

Workshop ini dimanfaatkan oleh tim untuk menuliskan essential use case/user story card. Pertanyaan diajukan untuk memperjelas lingkup proyek. Pertanyaan mengenai ada-tidaknya software referensi yang serupa yang dapat diteliti.

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]:

12

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 <http://www.agilemodeling.com/artifacts/userStory.htm>

13

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. Hal-hal 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-in-time. 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.

14

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 <http://www.ambysoft.com/essays/agileProjectPlanning.html#Scheduling>

15

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.

16

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

Project Management.

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.

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 <http://www.ambysoft.com/downloads/agileUP.zip>

17

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 UP Dicipline

Model.

Keterangan

Pertemuan ini umumnya dilakukan ke Departemen IT organisasi bersangkutan.

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.

18

Business Workshop Deskripsi

Pertemuan dengan narasumber/end-users (umumnya kepada departemen yang bersinggungan dengan sistem) untuk membahas isu resiko-resiko bisnis.

Hari Ke-/Lama

1 / 1- 2 hari.

Best Practice

Active Stakeholder Participation, Face-to-Face Interview, Observation.

Penanggung Jawab

Business Analyst. UP Dicipline

Model.

Keterangan

Prioritas Kebutuhan: 1. Merupakan inti/core sistem, 2. Memiliki nilai bisnis

tertinggi, 3. Memiliki resiko terbesar.

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: Tenured professors may administer student grades

Identifier: BR123

Description: 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.

Example: 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.

Source: University Policies and Procedures Doc ID: U1701 Publication date: August 14, 2000

Related rules: BR12 Qualifying For Tenure BR65 Active Period for Seminars BR200 Modifying Final Student Grades

19

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 <http://www.agilemodeling.com/artifacts/businessRule.htm> [2] Ibid.

20

Architectural Meeting Deskripsi

Rapat susulan dalam internal tim untuk membahas kembali hasil-hasil 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

UP Dicipline

Model, Deployment.

Keterangan

Seluruh anggota tim wajib mengikuti rapat ini. Ada baiknya mengundang pula narasumber/end-users untuk memberikan beberapa masukan.

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]:

21

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 <http://www.agilemodeling.com/artifacts/freeForm.htm> [2] Ambler, Scott W. “Networks Diagrams.” Agile Modelling <http://www.agilemodeling.com/artifacts/networkDiagram.htm> [3] Ambler, Scott W. “UML 2 Deployment Diagram.” Agile Modelling <http://www.agilemodeling.com/artifacts/deploymentDiagram.htm>

22

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

UP Dicipline

Model, Implementation, Test.

Keterangan

Prototipe yang dimaksud bukan berarti nanti akan dibuang dan dibuat ulang, melainkan prototipe yang akan digunakan nanti dalam implementasi.

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]:

23

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 <http://www.agilemodeling.com/artifacts/essentialUI.htm>

24

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


-

Penanggung Jawab


Project Management.

Keterangan

Direkomendasikan audiensi untuk rapat ini meliputi juga para pejabat tinggi penyedia proyek untuk memperoleh dukungan dan perhatian agar proyek dapat berjalan dengan lancar.

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.

25

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 <http://www.ambysoft.com/downloads/agileUP.zip> [2] Ibid.

26

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

Model

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

Artifak

Use Case – lihat halaman 11. Perbarui isinya. Ubah menjadi Casual Format[1] atau Fully-dressed Format[2]. Contoh casual format:

27

Terkadang untuk mempermudah pengertian terhadap use case dapat dibuat secara visual flow chart[3]:

Atau melalui penggambaran UML activity diagram[4]:

28

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 <http://www.agilemodeling.com/artifacts/flowChart.htm> [4] Ambler, Scott W. “UML 2 Activity Diagram.” Agile Modelling <http://www.agilemodeling.com/artifacts/activityDiagram.htm>

29

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


-

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]:

30

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 <http://www.agilemodeling.com/essays/agileModelingXPLifecycle.htm#Figure06TaskCards> [2] Ibid. <http://www.agilemodeling.com/essays/agileModelingXPLifecycle.htm#Figure08TaskSketch>

31

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.

32

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]:

33

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 <http://www.agilemodeling.com/artifacts/classDiagram.htm> [2] Ambler, Scott W. ”Data Modelling 101.” Agile Data <http://www.agiledata.org/essays/dataModeling101.html> [3] Ambler, Scott W. ”UML 2 Sequence Diagram.” Agile Modelling <http://www.agilemodeling.com/artifacts/sequenceDiagram.htm> [4] Ambler, Scott W. ”Class Responsibility Colaborator (CRC) Models.” Agile Modelling <http://www.agilemodeling.com/artifacts/crcModel.htm> [5] Ambler, Scott W. ”User Interface Prototypes.” Agile Modelling <http://www.agilemodeling.com/artifacts/uiPrototype.htm>

34

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.

Penanggung Jawab

Developer Lead

UP Dicipline

Implementation, Test

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.

35

Evaluation and Testing Deskripsi

Kegiatan periodik untuk menguji integrasi sistem dari modul-modul yang telah dikerjakan bersama.

Hari Ke-/Lama

~3 / 1 hari

Best Practice

Regression Testing, Daily Build.

Penanggung Jawab

Developer Lead UP Dicipline

Test

Keterangan

Sesuaikan jadwal kegiatan ini dengan iteration plan.

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.

36

User Feedback Deskripsi

Pertemuan dengan end-users untuk meminta tanggapan/feedback atas sistem atau modul sistem yang telah diimplementasikan.

Hari Ke-/Lama


-

Penanggung Jawab

Project Manager

UP Dicipline

Deployment, Test.

Keterangan

Lakukan aktifitas ini di setiap akhir iterasi.

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.

37

Installation Documentation Deskripsi

Menyusun dokumentasi instalasi sistem sesuai deployment diagram dan mulai menyusun bahan-bahan training workshop.

Hari Ke-/Lama


-

Penanggung Jawab

Developer Lead.

UP Dicipline

Deployment, Environment

Keterangan

Dibuatkan pula shopping list untuk organisasi sebagai bentuk penyediaan barang.

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.

38

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


-

Penanggung Jawab


Project Management.

Keterangan

Penutupan pengerjaan proyek mengandung arti tidak ada bentuk permintaan kebutuhan tambahan kecuali masalah bug-fixing.

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


39

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


-

Penanggung Jawab

Business Analyst Project Manager

UP Dicipline

Test, Deployment

Keterangan

Agenda rencana: Hari 1-2: Final Testing. Hari 3-4: Deployment and Installation. Hari 5: Final Acceptance Test. Apabila ada bug, beri catatan untuk aktifitas bug-fixing dan prioritasnya.

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.

40

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 UP Dicipline

Implementation.

Keterangan

Bug-fixing dilakukan sampai tenggat waktu peluncuran sistem. Apabila dalam jangka waktu tersebut tidak dapat mencakup keseluruhan bug-fixing maka keluarkan patch di saat sistem sudah berjalan.

Artifak

Bugs Report – lihat halaman 35.

Tujuan

Pemeliharaan dan garansi Perusahaan sebagai bentuk tanggung jawab pembuatan sistem.

41

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. UP Dicipline

Deployment.

Keterangan

Seluruh gambar model (snapshot) diseleksi dan diubah menjadi gambar formal menggunakan UML tool.

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.

42

Training Workshop Deskripsi

Melatih seluruh end-users untuk memperkenalkan penggunaan sistem.

Hari Ke-/Lama


-

Penanggung Jawab


Deployment

Keterangan

-

Artifak

Training Materials – lihat halaman 37.

Tujuan

Melatih seluruh end-users untuk memperkenalkan penggunaan sistem.

43

Release Meeting Deskripsi

Rapat milestone IV dengan project stakeholder bahwa mereka puas dan menerima sistem yang telah diimplementasikan.

Hari Ke-/Lama


-

Penanggung Jawab


Project Management.

Keterangan

Direkomendasikan audiensi untuk rapat ini meliputi seluruh stakeholder terutama yang dahulu pernah menghadiri rapat awal pengadaan proyek.

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


44

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 produk-produk tersebut agar tetap konsisten seiring perjalanan waktu proyek, termasuk memberikan versi (versioning), mengontrol dan mengatur perubahan yang terjadi.

45

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

46

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

Pusilkom AUP versi 2.2.2

Documents

Transcript of Pusilkom AUP versi 2.2.2