Prosiding Seminar Nasional Manajemen Teknologi IV Program Studi MMT-ITS, Surabaya 5 Agustus 2006
PEMBUATAN SPESIFIKASI MANAGEMEN KEBUTUHAN IMPLEMENTASI MICROSOFT ERP AXAPTA DI PDAM KOTA SURABAYA Subekti Pranoto1), Aries Tjahyanto2) Corporate IT Administrator, PDAM Kota Surabaya 2) Fakultas Teknologi Industri - Institut Teknologi Sepuluh Nopember E-mail:
[email protected],
[email protected] 1)
ABSTRAK Dewasa ini hampir semua perusahaan menyadari besarnya peranan teknologi informasi dalam format bisnis yang dijalani. Berbagai macam proyek teknologi informasi mulai dari otomatisasi administrasi kantor (back office) untuk meningkatkan efisiensi sampai dengan pengembangan sistem front office yang bersifat strategis dikembangkan secara simultan dalam portfolio manajemen. Untuk meningkatkan kualitas proses bisnis, Manajemen PDAM Kota Surabaya melakukan implementasi aplikasi back office modul-modul Microsoft ERP (Enterprise Resource Planning) Axapta yang dibagi ke dalam beberapa kategori (a) Modul Financial (General Ledger, Account Payable, Account Receivable, Bank), (b) Modul Distribution (Sales Order, Purchase Order, Inventory), (c) Modul Project ( Project Management) Untuk alasan ini maka dilakukan penelitian yang meliputi cara-cara proses menemukan, menganalisis, mendokumentasikan dan pengujian layanan-layanan dan batasan pernyataan/gambaran pelayanan yang disediakan oleh sistem dalam Implementasi Microsoft ERP Axapta di PDAM Kota Surabaya. Proses menemukan, menganalisis, mendokumentasikan dan pengujian layanan-layanan dan batasan pernyataan/gambaran pelayanan yang disediakan oleh sistem, batasan-batasan dari sistem dan bisa juga berupa definisi matematis fungsi-fungsi sistem sendiri merupakan suatu disiplin ilmu tersendiri yang diberi nama Rekayasa Perangkat Lunak (RPL, atau dalam bahasa Inggris: Software Engineering (SE) atau Requirement Engineering (RE)). Analisis cara-cara proses menemukan, menganalisis, mendokumentasikan dan pengujian pelayanan yang disediakan oleh sistem untuk Implementasi Microsoft ERP Axapta di PDAM Kota Surabaya dilaksanakan menggunakan metode RUP (Rational Unified Process). Metode ini meliputi inception, elaboration, construction, dan transition. Dalam penelitian, proses pengumpulan kebutuhan yang mendukung metodologi RUP menggunakan suatu tools IBM Rational Requisite Pro 2003.06.15.734.000 Hasil dari penelitian ini berupa : (a) Dokumen Rencana Manajemen Kebutuhan (Requirements Management Plan) yang berisi uraian petunjuk yang digunakan oleh proyek untuk menetapkan dokumen kebutuhan standard, jenis kebutuhan, atribut kebutuhan, dan traceabilitas. (b) Dokumen Analisis Luas Cakupan (Coverage Analysis) yang berisi penjelasan secara mendetil kebutuhan fungsional maupun nonfungsional yang berlaku pada keseluruhan proyek. (c) Dokumen Analisa Dampak (Impact Analysis) yang memberikan gambaran dampak potensi perubahan sistem manakala suatu kebutuhan Axapta berubah. (d) Dokumen Analisa Kebutuhan Pengganti (Supplementary Requirements) dimana merupakan dokumen yang berhubungan dengan Kebutuhan Pengganti yang memberikan rincian semua kekhususan (detail) produk yang belum terperinci ke dalam seperangkat kebutuhan nonfungsional. Kata kunci: Requirement Engineering, Implementasi Microsoft ERP Axapta, RUP (Rational Unified Process), IBM Rational Requisite Pro
Prosiding Seminar Nasional Manajemen Teknologi IV Program Studi MMT-ITS, Surabaya 5 Agustus 2006
PENDAHULUAN Dewasa ini hampir semua perusahaan menyadari besarnya peranan teknologi informasi dalam format bisnis yang dijalani. Berbagai macam proyek teknologi informasi mulai dari otomatisasi administrasi kantor (back office) untuk meningkatkan efisiensi sampai dengan pengembangan sistem front office yang bersifat strategis dikembangkan secara simultan dalam portfolio manajemen. Untuk meningkatkan kualitas proses bisnis, Manajemen PDAM Kota Surabaya melakukan implementasi aplikasi back office modul-modul Microsoft ERP (Enterprise Resource Planning) Axapta [1] yang dibagi ke dalam beberapa kategori : 1. Modul Financial (General Ledger, Account Payable, Account Receivable, Bank) 2. Modul Distribution (Sales Order, Purchase Order, Inventory) 3. Modul Project ( Project Management) Dalam proses implementasi Microsoft Axapta, pendekatan yang digunakan adalah pendekatan model proses bisnis. Dengan menggunakan pendekatan model proses bisnis, akan didapatkan suatu pemahaman yang terbaik kebutuhan bisnis dan lebih jauh secara otomatis memastikan dokumentasi spesifikasi kebutuhan dari semua keputusan dan proses bisnis sebagai progres implementasi sampai tercapai tahap pengembangan sistem. Secara khusus, pendekatan proses bisnis akan mengurangi resiko kegagalan implementasi proyek. Untuk alasan ini maka dilakukan penelitian yang meliputi cara-cara proses menemukan, menganalisis, mendokumen-tasikan dan pengujian layanan-layanan dan batasan pernyataan/gambaran pelayanan yang disediakan oleh sistem dalam Implementasi Microsoft ERP Axapta di PDAM Kota Surabaya, dalam suatu disiplin ilmu tersendiri yang diberi nama Rekayasa Perangkat Lunak (RPL, atau dalam bahasa Inggris: Software Engineering (SE) atau Requirement Engineering (RE)), sesuai IEEE Std 830-1998 [2]. Manfaat dari penelitian ini adalah : (a) Pendekatan sistematis untuk membuat, mengorganisir, dan men-dokumentasikan kebutuhan dari implementasi Microsoft Axapta di PDAM Kota Surabaya, (b) Memudahkan kebutuhan peninjauan ulang di masa mendatang yang sesuai untuk merumuskan kebutuhan dan memastikan ketelitian dan kejelasan lingkup, perilaku sistem, hubungan timbal balik, dan kosa kata (vocabulary) yang digunakan. Requirements Engineering Dalam bagian ini dijelaskan konsep dasar yang berkaitan dengan Requirements Engineering. Penjelasan diberikan secara singkat dengan tujuan untuk memberikan pengertian, tujuan, dan manfaat dari aspek Requirements Engineering. Definisi Requirements Engineering Menurut IEEE Std 830-1998 [2], Rekayasa perangkat lunak (RPL, atau dalam bahasa Inggris: Software Engineering (SE) atau Requirement Engineering (RE)) adalah satu bidang profesi yang mendalami cara-cara pengembangan perangkat lunak termasuk pembuatan, manajemen organisasi pengembanganan software, desain sistem, implementasi, testing dan perawatan sistem. Requirement tidak hanya ditulis oleh pembangun, tapi sebelumnya justru ditulis oleh klien yang memesan software. Klien menuliskan requirement dalam bentuk yang masih abstrak tentang kebutuhannya. Kemudian requirement tersebut diserahkan kepada tim pembangun. Saat sudah ada persetujuan, pembangun kemudian menuliskan kemampuan sistem yang bisa dipahami oleh klien, inipun disebut requirement. Beberapa macam requirement menurut Sommerville [3] yaitu: a. User Requirement (Kebutuhan Pengguna) Pernyataan tentang layanan yang disediakan sistem dan tentang batasan-batasan operasionalnya. Pernyataan ini dapat dilengkapi dengan gambar/diagram yang dapat dimengerti dengan mudah.
ISBN : 979-99735-1-1 C-10-2
Prosiding Seminar Nasional Manajemen Teknologi IV Program Studi MMT-ITS, Surabaya 5 Agustus 2006 b. System Requirement (Kebutuhan Sistem) Sekumpulan layanan/kemampuan sistem dan batasan-batasannya yang ditulis secara detil. System requirement document sering disebut functional specification (spesifikasi fungsional), harus menjelaskan dengan tepat dan detil. Ini bisa berlaku sebagai kontrak antara klien dan pembangun. c. Software Design Specification (Spesifikasi Rancangan Perangkat Lunak) Gambaran abstrak dari rancangan software yang menjadi dasar bagi perancangan dan implementasi yang lebih detil. Ketiga jenis requirement tersebut diperlukan dalam pembangunan software karena masing-masing memberi pengertian ke pihak yang berbeda. Fungsi ketiga requirement diatas menurut Sommerville [3] dapat memberi pengertian pada beberapa pihak yang dipetakan menjadi: a. User Requirement (Kebutuhan Pengguna), yaitu Manager Klien, End User System, Staf Ahli Klien, Manager Developer dan Arsitek System b. System Requirement (Kebutuhan Sistem) yaitu End User System, Staf Ahli Klien, Tim Developer, Arsitek System c. Software Design Specification (Spesifikasi Rancangan Perangkat Lunak) yaitu Staf Ahli Klien, Tim Developer dan Arsitek System Tujuan Requirements Engineering Menurut IEEE Std 610.12 – 1990 [4], di dalam rancang-bangun sistem (system engineering atau system design engineering), suatu kebutuhan adalah suatu uraian dari apa yang perlu lakukan terhadap suatu sistem. Sistem mungkin punya dari beberapa sampai beribu-ribu kebutuhan. Suatu koleksi kebutuhan menggambarkan karakteristik atau corak yang diinginkan (atau diperlukan) sistem, tetapi secara umum tidak dikatakan bagaimana sistem perlu menerapkan kebutuhan itu. Di dalam rancang-bangun perangkat lunak (software engineering), suatu perangkat lunak kebutuhan (software requirement) adalah suatu potongan uraian dari apa yang perlu dilakukan (atau diperlukan) terhadap perangkat lunak tertentu. Suatu potongan perangkat lunak juga boleh mempunyai beberapa sampai beribu-ribu kebutuhan. Manfaat Requirements Engineering Menurut IEEE Std 1233-1998 [5], suatu perangkat lunak spesifikasi kebutuhan (software requirements specification, SRS) adalah suatu uraian yang lengkap menyangkut perilaku dari sistem yang akan dikembangkan. Sesuai IEEE Std 830 – 1998 [5], SRS biasanya berisi: i) Kebutuhan Fungsional: Suatu kebutuhan yang menetapkan suatu tindakan dimana suatu sistem harus mampu melaksanakan suatu aksi, tanpa mempertimbangkan batasan phisik; suatu kebutuhan yang menetapkan perilaku input/output dari suatu sistem. ii) Kebutuhan Non-Fungsional: Suatu kebutuhan yang menetapkan property sistem, seperti lingkungan dan batasan implementasi, capaian (performance), ketergantungan platform, kebutuhan maintainance, sifat dapat dikembangkan (extensibility), dan keandalan. Kebutuhan Non-Fungsional seringkali diklasifikasikan menjadi beberapa kategori, yaitu: a) Kebutuhan capaian (performance). Suatu kebutuhan dimana menetapkan karakteristik capaian yang dimiliki suatu sistem secara utuh atau komponen system. Misalnya: max. penggunaan CPU, max. penggunaan memory. b) Kebutuhan Interface Eksternal: Suatu kebutuhan dimana menetapkan spesifikasi perangkat keras, perangkat lunak, atau unsurunsur database di dalam suatu sistem yang utuh atau komponen sistem yang dijembatani menghubungkan, atau menetapkan batasan pada format, pemilihan waktu atau faktor lain yang disebabkan oleh alat penghubung seperti itu. c) Batasan disain. Suatu kebutuhan dimana mempengaruhi atau membatasi perancangan suatu sistem secara utuh atau komponen system. Misalnya: kebutuhan bahasa pemrograman, kebutuhan phisik perangkat
ISBN : 979-99735-1-1 C-10-3
Prosiding Seminar Nasional Manajemen Teknologi IV Program Studi MMT-ITS, Surabaya 5 Agustus 2006 keras, standard pengembangan software, dan standard jaminan mutu perangkat lunak. d) Atribut Mutu. Suatu kebutuhan dimana menetapkan suatu derajat tingkatan dimana suatu sistem memiliki atribut yang mempengaruhi mutunya. Misalnya: ketepatan, keandalan, kebutuhan maintainance, dan portabilitas. Menurut Sommerville & Sawyer [6], SRS berisi seperangkat aktivitas untuk menemukan, menganalisa, mendokumen-tasikan, memvalidasi dan seperangkat kebutuhan pemeliharaan suatu sistem. SRS adalah dibagi menjadi dua kelompok utama aktivitas, manajemen kebutuhan (requirements management.) dan pengembangan kebutuhan (requirements development). Pengembangan kebutuhan meliputi aktivitas yang berhubungan dengan menemukan, menganalisa, mendokumentasikan dan memvalidasi kebutuhan, sedangkan manajemen kebutuhan meliputi aktivitas berhubungan dengan pemeliharaan yaitu identifikasi, traceabilitas dan perubahan manajemen kebutuhan. METODOLOGI PENELITIAN Pada bab ini dipaparkan langkah-langkah yang digunakan untuk membahas permasalahan yang diambil dalam penelitian. Dibagian ini juga dijelaskan alat dan metoda yang digunakan untuk melakukan perencanaan. Rational Unified Process (RUP) adalah salah satu metodologi dan proses Requirement Engineering. RUP adalah suatu kerangka proses low-level pengembangan software yang dikembangkan oleh Rational Software. RUP benar-benar merupakan suatu kerangka proses dan kerangka disain karena memiliki unsur-unsur suatu metodologi dan suatu proses. Menggunakan RUP, pengembangan lifecycles perangkat lunak dibagi menjadi pengembangan siklus individu. Masing-masing siklus ini dibagi menjadi tahapan-tahapan. Tahapan ini terdiri atas aktivitas yang berulang-ulang. Aktivitas berulang-ulang ini dibatasi dalam suatu timeframe (batas waktu tertentu) dan masing-masing tahapan mempunyai sasaran hasil. Di dalam metodologi RUP, tahapan dibagi menjadi: 1. Tahap Permulaan (Inception Phase) Pada tahap ini, implementasi yang dilaksanakan meliputi menggali konteks bisnis yang digeluti, faktor-faktor kesuksesan bisnis (seperti besaran pendapatan yang diinginkan, pangsa pasar dll) dan peramalan keuangan. Setelah tahap ini diselesaikan, proyek implementasi dicocokan terhadap ukuran-ukuran yaitu Definisi lingkup implementasi sesuai permintaan stakeholder, Pemahaman kebutuhan yang dibuktikan dengan ketepatan jadwal implementasi, Ketepatan menyangkut perkiraan cost/schedule, prioritas, resiko, dan proses pengembangan serta Evaluasi luas lingkup dan kedalaman detail tentang arsitektur prototipe yang dikembangkan. 2. Tahap Pengembangan (Elaboration Phase) Di dalam tahap pengembangan dilakukan analisa permasalahan dan arsitektur dari proyek dibuat dalam format dasar. Keberhasilan tahap ini diukur dengan ukuran criteria yaitu Suatu uraian menyangkut arsitektur perangkat lunak di dalam suatu perangkat lunak pengembangan proses sistem dan Suatu perencanaan pengembangan untuk keseluruhan proyek. 3. Tahap Konstruksi (Construction Phase) Di dalam tahap ini, fokus utamanya adalah pengembangan komponen dan fitur-fitur lain dari sistem yang sedang dirancang. Ini adalah tahap dimana pemrograman dilakukan. 4. Tahap Transisi (Transition Phase) Di dalam tahap transisi, implementasi telah diperkenalkan ke end user. Aktivitas pada tahap ini meliputi pelatihan kepada end user, User Accepteance Test dan perbaikan bug yang muncul. Proses implementasi juga dicocokan terhadap standart mutu yang telah ditetapkan dalam Tahap Permulaan. Jika tidak sesuai, keseluruhan siklus di dalam tahap ini mulai lagi dari awal
ISBN : 979-99735-1-1 C-10-4
Prosiding Seminar Nasional Manajemen Teknologi IV Program Studi MMT-ITS, Surabaya 5 Agustus 2006 Penelitian yang dilakukan menggunakan suatu metode untuk menggambarkan prosesproses yang dilakukan. Dalam penelitian ini, secara keseluruhan pengumpulan kebutuhan menggunakan metodologi RUP dilaksanakan dengan bantuan suatu tools IBM Rational Requisite Pro 2003.06.15.734.000 dari IBM [7]. Diagram alur kerja yang digunakan dalam metodologi penelitian ini sebagai pada Gambar 1. berikut:
Gambar 1 Diagram Metodologi Penelitian HASIL PENELITIAN Hasil dari penelitian ini berupa : (a) Dokumen Rencana Manajemen Kebutuhan (Requirements Management Plan) yang berisi uraian petunjuk yang digunakan oleh proyek untuk menetapkan dokumen kebutuhan standard, jenis kebutuhan, atribut kebutuhan, dan traceabilitas. (b) Dokumen Analisis Luas Cakupan (Coverage Analysis) yang berisi penjelasan secara mendetil kebutuhan fungsional maupun nonfungsional yang berlaku pada keseluruhan proyek. (c) Dokumen Analisa Dampak (Impact Analysis) yang memberikan gambaran dampak potensi perubahan sistem manakala suatu kebutuhan Axapta berubah. (d) Dokumen Analisa Kebutuhan Pengganti (Supplementary Requirements) dimana merupakan dokumen yang berhubungan dengan Kebutuhan Pengganti yang memberikan rincian semua kekhususan (detail) produk yang belum terperinci ke dalam seperangkat kebutuhan nonfungsional. Rencana Manajemen Kebutuhan (Requirements Management Plan) Rencana Manajemen Kebutuhan berisi isi dan kerangka kerja (frame work) yang disajikan oleh IBM Rational RequisitePro 2003.06.15.734.000 untuk membantu mengembangkan Rencana Manajemen Kebutuhan proyek implementasi Microsoft Axapta di PDAM Kota Surabaya. Dokumen ini menguraikan petunjuk yang digunakan oleh proyek untuk menetapkan dokumen kebutuhan standard, jenis kebutuhan, atribut kebutuhan, dan traceabilitas. Hal ini
ISBN : 979-99735-1-1 C-10-5
Prosiding Seminar Nasional Manajemen Teknologi IV Program Studi MMT-ITS, Surabaya 5 Agustus 2006 menggambarkan suatu strategi umum untuk memanage kebutuhan dan bertindak sebagai suatu sumber daya untuk semua para orang yang mengambil bagian di dalam proyek implementasi Microsoft Axapta di PDAM Kota Surabaya. Dokumen ini menguraikan bagaimana malakukan tracking kebutuhan menggunakan atribut dan traceabilitas yang dihubungkan kepada kebutuhan lain. Dokumen ini juga menguraikan proses manajemen perubahan yang diadopsi untuk proyek implementasi Microsoft Axapta di PDAM Kota Surabaya. Dokumen ini menetapkan milestone untuk dicapai dan standard untuk dipertahankan sedemikian sehingga dapat dipastikan dan dilakukan evaluasi pemenuhan menyangkut kebutuhan yang ditetapkan. Organisasi Proyek dan Tanggung Jawab Adapun Struktur Organisasi yang berlaku di PDAM sesuai dengan Keputusan Walikota No. 43 tahun 2003 digabungkan dengan SK Direksi tahun 2003 adalah sebagai berikut :
Gambar 2 Struktur Organisasi PDAM Kota Surabaya Organisasi, Tugas dan Tanggung Jawab Tim proyek implementasi Microsoft Axapta di PDAM Kota Surabaya terbagi menjadi Steering Committee, Quality Assurance, Pemimpin Proyek, Sekretaris Proyek, Koordinator Proses Bisnis dan Prototyping, Proses Bisnis, Prototyping, Koordinator Pengembangan Aplikasi dan Migrasi Data, Developer, Data Migrator, Report Designer, Koordinator Training dan Testing Aplikasi, Trainer dan Tester, sebagai berikut: Steering Committee
Quality Assurance
Pemimpin Proyek
Koordinator Training dan Testing Aplikasi
Koordinator Pengembangan Aplikasi dan Migrasi Data
Koordinator Proses Bisnis dan Prototyping Sekretaris Proyek
Tester Aplikasi
. Developer
Proses Bisnis
Training
Data. Migrator
. Prototyping
Report Designer
Gambar 3 Tim Proyek Implementasi Axapta Artifact Kebutuhan Type Artifact kebutuhan proyek implementasi Microsoft Axapta di PDAM Kota Surabaya terdiri dari:
ISBN : 979-99735-1-1 C-10-6
Prosiding Seminar Nasional Manajemen Teknologi IV Program Studi MMT-ITS, Surabaya 5 Agustus 2006 1) Definisi Artifact Kebutuhan proyek implementasi Microsoft Axapta di PDAM Kota Surabaya, terdiri atas Type Dokumen Axapta, Deskripsi Dokumen Axapta dan Tipe Kebutuhan Standart Axapta 2) Tipe Kebutuhan proyek implementasi Microsoft Axapta di PDAM Kota Surabaya, terdiri atas Tipe Kebutuhan Axapta, Deskripsi Kebutuhan Axapta dan Atribut Kebutuhan Axapta 3) Atribut Kebutuhan, terdiri atas Atribut Kebutuhan Axapta, Deskripsi Kebutuhan Axapta, Daftar Nilai Kebutuhan Axapta dan Tipe Kebutuhan Axapta 4) Nilai Atribut Axapta, terdiri atas Penilaian Atribut Axapta, Tipe Atribut Axapta dan Deskripsi Atribut Axapta Artifact kebutuhan proyek implementasi Microsoft Axapta di PDAM Kota Surabaya menghasilkan: Traceabilitas Strategi traceabilas menggambarkan penggunaan use-case dan kebutuhan pengganti yang akan melacak kepada kekhususan produk secara detil, sebagaimana ditunjukan dalam gambar berikut:
Gambar 4 Traceablitias Axapta Strategi traceabilitas terdiri dari: 1) Kriteria traceabilitas untuk tipe kebutuhan, digolongkan menjadi: Fitur (Feature, FEAT), Use Case (UC), Kebutuhan Pengganti (Supplementary Requirement, SUPP) dan Daftar Istilah / Kata (Glossary Term, TERM) 2) Laporan dan Pengukuran Kebutuhan, digolongkan menjadi Nama Query, Deskripsi Traceabilitas, Nama Paket dan Penjelasan Keuntungan tiap-tiap query Rencana Managemen Perubahan Kebutuhan Permintaan perubahan kebutuhan Axapta harus dievaluasi dan disetujui Direksi PDAM Kota Surabaya. Permintaan perubahan kebutuhan Axapta yang disetujui Direksi PDAM Kota Surabaya dilakukan revisi terhadap dokumen yang telah dibuat dan ditandai dengan nama dokumen revisi dalam history dokumen. Analisis Luas Cakupan (Coverage Analysis) Dokumen Analisis Luas Cakupan Axapta menjelaskan secara mendetil kebutuhan fungsional maupun nonfungsional yang berlaku pada keseluruhan proyek implementasi Microsoft Axapta di PDAM Kota Surabaya. Dokumen Analisis Luas Cakupan Axapta menggambarkan masalah yang harus dipecahkan dalam proyek implementasi Microsoft Axapta di PDAM Kota Surabaya dan untuk menggambarkan kebutuhan bisnis level tingkat tinggi, kebutuhan pemakai, dan kebutuhan lain untuk sistem Axapta.
ISBN : 979-99735-1-1 C-10-7
Prosiding Seminar Nasional Manajemen Teknologi IV Program Studi MMT-ITS, Surabaya 5 Agustus 2006 Dokumen Analisis Luas Cakupan Axapta terdiri dari: 1. Dokumen Fitur yang tidak berhubungan dengan Kebutuhan Pengganti Dokumen Fitur yang tidak berhubungan dengan Kebutuhan Pengganti dimana memberikan rincian semua kekhususan (detail) produk yang belum terperinci ke dalam seperangkat kebutuhan nonfungsional 2. Dokumen Fitur yang tidak berhubungan dengan use-case Dokumen ini memberikan rincian semua kekhususan yang belum terperinci ke dalam seperangkat use case (yang merepresentasikan kebutuhan fungsional). 3. Dokumen Pemenuhan Kebutuhan Fungsional Dokumen Pemenuhan Kebutuhan Fungsional menunjukkan jejak kekhususan produk yang berhubungan dengan kemampuan sistem dan use case. 4. Dokumen prioritas tingkat tinggi yang tidak dipenuhi (not coverage) oleh Use-case Dokumen ini memberikan rincian semua kekhususan dengan tingkat prioritas tinggi yang belum terperinci ke dalam seperangkat use case (yang merepresentasikan kebutuhan fungsional). 5. Dokumen Rencana Keseluruhan Proyek Dokumen Rencana Keseluruhan Proyek berupa tree yang menunjukkan semua mata rantai yang menyusun proyek implementasi Microsoft Axapta di PDAM Kota Surabaya Analisa Dampak (Impact Analysis) Dokumen Analisa Dampak Axapta merupakan paket query yang memberikan gambaran dampak potensi perubahan sistem manakala suatu kebutuhan Axapta berubah. Dokumen Analisa Dampak Axapta terdiri dari: 1. Dokumen Use Case yang terpengaruh oleh perubahan fitur Axapta Dokumen daftar kebutuhan use case yang berpotensi terpengaruh oleh suatu perubahan fitur Axapta. 2. Dokumen Kebutuhan Pengganti terpengaruh oleh perubahan fitur Axapta Dokumen daftar kebutuhan pengganti yang berpotensi terpengaruh oleh suatu perubahan fitur Axapta Analisa Kebutuhan Pengganti (Supplementary Requirements) Dokumen Analisa Kebutuhan Pengganti Axapta merupakan dokumen yang berhubungan dengan Kebutuhan Pengganti dimana memberikan rincian semua kekhususan (detail) produk yang belum terperinci ke dalam seperangkat kebutuhan nonfungsional. Dokumen Analisa Kebutuhan Pengganti terdiri dari: 1. Dokumen usabilitas proyek Dokumen usabilitas proyek meliputi semua dokumen dari kebutuhan yang mempengaruhi usabilitas proyek implementasi Microsoft Axapta di PDAM Kota Surabaya. 2. Dokumen Perfomansi Proyek Dokumen Perfomansi Proyek merupakan dokumen yang menggambarkan Karakteristik performansi dari proyek implementasi Microsoft Axapta di PDAM Kota Surabaya.
PENUTUP Pada penelitian ini dilakukan analisis cara-cara proses menemukan, menganalisis, mendokumentasikan dan melakukan pengujian pelayanan yang disediakan oleh sistem untuk Implementasi Microsoft ERP Axapta di PDAM Kota Surabaya yang dilaksanakan menggunakan metode RUP (Rational Unified Process). Proses pengumpulan kebutuhan menggunakan tools IBM Rational Requisite Pro 2003.06.15.734.000. Hasil dari penelitian ini berupa : (a) Rencana Manajemen Kebutuhan (Requirements Management Plan) yang berisi uraian petunjuk yang digunakan oleh proyek untuk menetapkan dokumen kebutuhan standard, jenis kebutuhan, atribut kebutuhan, dan traceabilitas. (b) Dokumen Analisis Luas Cakupan (Coverage Analysis) yang berisi penjelasan secara mendetil
ISBN : 979-99735-1-1 C-10-8
Prosiding Seminar Nasional Manajemen Teknologi IV Program Studi MMT-ITS, Surabaya 5 Agustus 2006 kebutuhan fungsional maupun nonfungsional yang berlaku pada keseluruhan proyek. (c) Dokumen Analisa Dampak (Impact Analysis) yang memberikan gambaran dampak potensi perubahan sistem manakala suatu kebutuhan Axapta berubah. (d) Dokumen Analisa Kebutuhan Pengganti (Supplementary Requirements) dimana merupakan dokumen yang berhubungan dengan Kebutuhan Pengganti yang memberikan rincian semua kekhususan (detail) produk yang belum terperinci ke dalam seperangkat kebutuhan nonfungsional. Manfaat yang dihasilkan penelitian ini adalah : (a) Pendekatan sistematis untuk membuat, mengorganisir, dan men-dokumentasikan kebutuhan dari implementasi Microsoft Axapta di PDAM Kota Surabaya, (b) Memudahkan kebutuhan peninjauan ulang di masa mendatang yang sesuai untuk merumuskan kebutuhan dan memastikan ketelitian dan kejelasan lingkup, perilaku sistem, hubungan timbal balik, dan kosa kata (vocabulary) yang digunakan. DAFTAR PUSTAKA
http://www.microsoft.com/dynamics/ax/default.mspx IEEE Recommended Practice for Software Requirements Specifications (IEEE Std 8301998). (1998). Institute of Electrical and Electronics Engineering, Inc. Sommerville, Ian. (2001), "Software Engineering" .6th . Addison Wesley. IEEE Standard Glossary of Software Engineering Terminology (IEEE Std 610.12 – 1990). (1990). Institute of Electrical and Electronics Engineering, Inc. IEEE Guide for Developing System Requirements Specifications (IEEE Std 1233, 1998 edition). (1998). Institute of Electrical and Electronics Engineering Inc. Sommerville, I. & Sawyer, P. (1997). Requirements Engineering: A Good Practise Guide. John Wiley & Sons. http://www14.software.ibm.com/webapp/download/brand.jsp?b=Rational
ISBN : 979-99735-1-1 C-10-9
