PERANCANGAN KERANGKA KERJA DAUR HIDUP DAN IMPLEMENTASI DASHBOARD MANAJERIAL PUSAT DATA, STUD1 KASUS PT ADIRA DINAMIKA MULTIFINANCE, TBK
ARRY EKANANTA
SEKOLAH PASCASARJANA INSTITUT PERTANIAN BOGOR 2006
SURAT PERNYATAAN Dengan ini saya menyatakan bahwa Tesis yang berjudul: Perancangan Kerangka Kerja Daur Hidup dan Implementasi Dashboard Manajerial Pusat Data, Studi Kasus PT Adira Dinamika Multifinance, Tbk adalah benar merupakan hasil karya sendiri dan belum pemah dipublikasikan. Semua sumber dan informasi yang digunakan telah dinyatakan secara jelas dan dapat diperiksa kebenarannya. Jakarta, Agustus 2006
Arrv Ekananta G651024104
ABSTRAK Kinerja pusat data sangat ditentukan oleh pencapaian kondisi operational dan strategic excellence-nya. Operational excellence yang tercermin melalui kegiatan rutin sehari-hari pusat data harus dapat memenuhi standar kinerja yang mampu menjamin integritas dan fungsionalitas data bagi pengguna. Pencapaian standar kinerja tersebut sangat ditentukan oleh strategic excellence yang tercermin melalui ketajaman analisis kebutuhan, kualitas desain dan rancangan logis, pengimplementasian konstruksi fisik, ketepatan penentuan indikator kinerja utama operasional, serta strategi penerapan manajemen perubahan dalam membentuk perilaku sumber daya manusia yang diharapkan. Penelitian bertujuan untuk merancang suatu kerangka kerja acuan dalam membangun dan mengoperasikan pusat data serta mengimplementasikan purwarupa aplikasi pengelolaan pusat data sebagai suatuproof of concept dari pemantauan kinerja pusat data berdasarkan standar kinerja yang disepakati. Metodologi penelitian mencakup mempelajari, memahami, kemudian memetalan langkah-langkah pembangunan serta pengoperasian pusat data ke dalam kerangka kerja berupa dokumen yang bemama Kerangka Kerja Daur Hidup Pusat Data lalu menangkap kebutuhan pengguna, menganalisis, mendesain, kemudian memrogram suatu aplikasi yang bemama Adjusted Management DASHboard (AMDASH). Sebagai hasil, Kerangka Kerja Daur Hidup Pusat Data dapat menjadi acuan dan arahan dalam pembangunan serta pengoperasian sebuah pusat data yang baik dan berkualitas. Dokumen tersebut dapat juga berfungsi sebagai alat audit untuk memantau seberapa jauh suatu pusat data telah memenuhi kaidah dan aturan seperti yang telah tertuang di dalamnya. Selain itu, AMDASH dapat menjadi aplikasi perangkat lunak manajemen X~isualyang berfungsi sebagai alat bantu pengambilan keputusan dalam mengelola pusat data secara efektif dan efisien. Kata kunci : rekayasa perangkat lunak, rekayasa system, pusat data, manajemen visual, Problem Identzj?cation & Corrective Action (PICA)
ABSTRACT The performance of a data center is defined by its achievements in both operational and strategic excellences. Operational excellence is defined as the dailyroutine activities of a data center to achieve and maintain its standards in data integration and functionality for users. The standards in operational excellence could only be derived from strategic excellence of a data center, which must be defined in the preliminary stage in developing a data center. The activities in strategic excellence are analyzing user's requirement, designing a logical pattern and in physical construction, deJning the key indicators of operational performance, and applying the change management. This research is designed to build a framework in developing and operating a data center, and to build a data center performance monitoring application based on approved standarh as a proof of concept. The research methodologies started by learning and understanding the concept of a data center, then mapping the steps in developing and operating a data center into a document called Kerangka Kerja Daur Hidup Pusat Data. AndJinally with thorough analysis, design, coding, and intensive work with users, develop an application named Adjusted Management DASHboard (AMDASH). As the result, Kerangka Kerja Daur Hidup Pusat Data can act as a reference and guidance for deploying and operating a good and qualiJied data center. Meanwhile, that document can also perform as an audit tool to monitor and mitigate the implementation of a data center as suggested by it. On the other side, AMDASH acts as a visual management sofmare application that can help decision makers in dealing with their data center to ensure its daily-routine activities operate effectively and efficiently. Keywords : sistem and sofmare engineering, data center, visual management, Problem IdentiJication & Corrective Action (PICA)
PERANCANGAN KERANGKA KERJA DAUR HIDUP DAN IMPLEMENTASI DASHBOARD MANAJERIAL PUSAT DATA, STUD1 KASUS PT ADIRA DINAMIKA MULTIFINANCE, TBK
ARRY EKANANTA
Tesis Sebagai salah satu syarat untuk memperoleh gelar Magister Sains pada Program Studi I!.mu Komputer
SEKOLAH PASCASARJANA INSTITUT PERTANLAN BOGOR 2006
Judul Tesis
: Perancangan Kerangka Kerja Daur Hidup dan Implementasi
Dashboard Manajerial Pusat Data, Studi Kasus PT Adira Dinamika Multifinance, Tbk Nama
: Arry Ekananta
NRP
: G651024104
Progranl Studi
: Ilnlu Konlputer
Menyetujui, 1. Komisi Pembimbing
&@Ir. Heru Triyono Natalisa. M.Math. Anggota
Ketua
Mengetahui,
2. Ketua Program Studi Ilmu Komputer
Tanggal Ujian: 4 Agustus 2006
RIWAYAT HIDUP Penulis, Arry Ekananta, dilahirkan di Bogor, 2 Oktober 1978 sebagai putra sulung dari pasangan Dr. Ir. Djoko Setiyanto dan Dra. Hanny Saraswaty, M.Pd. Penulis menamatkan pendidikan sarjana dengan gelar Sarjana Teknik (ST) di Jurusan Teknik Informatika, Fakultas Teknologi Industri, Institut Teknologi Bandung pada tahun 2001 seraya menjabat sebagai Manajer Pelatihan di Quantum ecornmerce College (QCollege), Bandung. Selain di QCollege, Penulis juga sempat menjadi asisten serta pengajar di Pojok Internet (Pointer) dan Pusat Ilmu Komputer dan Sistem Informasi (PIKSI) ITB. Pada tahun 2002, Penulis melanjutkan karir sebagai pengembang Web di Transforma Online, unit bisnis dari PT Transforma Global (Transforma), yang dilanjutkan dengan menjadi konsultan huntan capital dan organizational development di Transforma pada tahun 2003. Seiring dengan pesatnya perkembangan bisnis Transforma, penulis juga merangkap sebagai konsultan Teknologi Informasi (TI) di VIPRO, juga merupakan unit bisnis Transforma, pada tahun 2005 dan konsultan Six Sigma pada tahun 2006. Dengan kecintaan dan ketertarikan Penulis terhadap dunia TI, pada tahun 2002 Penulis melanjutkan pendidikannya di program studi Ilmu Komputer, Sekolah Pascasarjana IPB.
PRAKATA Puji syukur Penulis panjatkan kepada Allah, SWT karena atas rahmat dan karunia-Nya Penulis dapat menyelesaikan tesis ini dengan baik. Begitu banyak pihak yang telah mendukung terselesaikannya tesis ini sehingga perkenankanlah Penulis dengan segenap kerendahan hati mengucapkan terima kasih secara khusus kepada
1 Dr. Sugi Guritrnan dan Ir. Hem T. Natalisa, M.Math, selaku komisi pembimbing, atas arahan dan bimbingan selama pengerjaan Tesis ini. 2 Kedua orang tua dan mertua Penulis yang senantiasa memberikan doa serta dukungan moril maupun materil.
3 Istri tercinta, Yesse Vidya Hapsari, untuk curahan kasih sayang dan perhatiannya selama ini. 4 Rekan-rekan Magister Ilmu Kompuer IPB terutama Gysber Jan Tamaela untuk seluruh dukungan tanpa hentinya. 5 Rekan-rekan kerja di PT Transforma Global. Ibarat gading yang tak ada yang tak retak, Penulis sangat menyadari bahwa masih terdapat banyak kekurangan pada tesis ini. Karena itu sudi kiranya Sidang Pembaca berkenan memberikan saran dan kritik membangun agar kekurangan yang terjadi tidak terulang kembali pada penulisan ilmiah berikutnya. Akhir kata semoga Tesis ini dapat memberi makna dalam hidup kita semua, terutama bagi Penulis dalam upayanya mencari dun memberi yang terbaik demi
Tuhan, bangsa, dun almamater. Jakarta, Agustus 2006
Arrv Ekananta G651024104
DAFTAR IS1 ........................................iv ......................................V
...........................................................................................................................
ix
.......................................X ...............................................I
BAB I. PENDAHULUA
I.1. Latar Belakang .................................................................................................... 1 1 1.2. Formulasi Permasalahan ..................................................................................... .. 1.3. Tujuan Penelltlan ............................................................................................ 2 1.4. Ruang Lingkup .................................................................................................... 3 .. 1.5. Manfaat Penelltian ............................................................................................. 3 .. 1.6. Keaslian Penelltian ........................................................................................ 3 1.7. Sistematika Penulisan.......................................................................................... 4
BAB I1. TlNJAUAN PUSTAKA ...................................................................................................... II. 1. IT Service Excellence Management ................................................................... 6
6
11.2. Pusat Data .......................................................................................................... 8 8 2.1. Pengantar ........................................................................................................ 2.2. Filosofi Desain................................................................................................ 9 Usahakan Desain Sesederhana Mungkin..................................................... 10 Desain untuk fleksibilitas ................................................................................ 10 Desain untuk Skalabilitas ................................................................................ 10 10 Gunakan Desain yang Modular ...................................................................... Menjaga Kesehatan ......................................................................................... 10 2.3. Standardisasi dan Konsolidasi ...................................................................... 10 . . Konsolidasi Server ........................................................................................... 11 . . . . Konsolidasl Apllkasi ....................................................................................... 12 12 Konsolidasi Media Penyimpanan ................................................................... Konsolidasi Shared Service ............................................................................. 13 14 Konsolidasi Jaringan ....................................................................................... . . Konsolldasi Pusat Data .................................................................................... 14 Konsolidasi SDM dan Proses ........................................................ .......... 14 2.4. Service Level Agreement (SLA) ................................................................... 14 ......................................................................... 2.5. Audit ................................... 15 IL3. ~ e k a ~ aSistem sa .............................................................................................. 16 3.1. Formal Technical Review ............................................................................. 17 11.4. Kerangka Kerja ................................................................................................ 18 II.5. Flowchart ......................................................................................................... 19 11.6. Digital Dashboard ........................................................................................ 21 22 11.7. Rekayasa Perangkat Lunak .............................................................................. 7.1. Model Linear Sequential .............................................................................. 23 .. Pengujlan ......................................................................................................... 24 7.2. UnSfied Modeling Language ......................................................................... 25 11.8. Plan-Do-Check-Action (PDCA) ....................................................................... 28 ~
~
~
Check ...............................................................................................................29 Action ............................................................................................................... 29
BAB 111. METODOLOGI PENELITIAN ............................................................................................30
..
111.1. Kerangka Pemlklran .................................................................................. 111.2. Tata Laksana ................................................................................................... 111.3. Waktu dan Tempat Penelitian ........................................................................ . . .............................................................................. 111.4. Bahan dan Alat Penel~t~an
30 31 32 33
BAB IV. KERANGKA KERJA DAUR HIDUP PUSAT DATA ..........................................................34
IV.1. Pengantar ........................................................................................................ 34 IV.2. Kerangka Kerja Level 0 ................................................................................ 35 IV.3. Kerangka Kerja Level 1 ................................................................................. 37 IV.4. Kerangka Kerja Level 2 dan 3 ........................................................................ 37 4.1. P-1 Business Requirement ............................................................................ 37 P-1 .1 Data Collection ...................................................................................... 37 P-1.2 Determine Stakeholder..................................................................... 38 P-1.3 Data Documentation .............................................................................. 38 . . . P-1.4 List and Przorrtrze ;.............. :................................................................. 38 P-1.5 Initiate User Request Proposal .............................................................. 38 P-1.6 Distribute to Stakeholder ...................................................................... 39 4.2. P-2 Analysis and Feasibility Study ............................................................... 39 P-2.1 Initial Information Gathering ................................................................ 39 40 P-2.2 Sizing ...................................................................................................... P-2.3 Issue RFQs and Collect Quotations.................................................. 40 40 P-2.4 Validate Selected-Quotations................................................................. P-2.5 Make Business Justification and Get Approval for Additional Budget .41 P-2.6 Finalize Data Center Analysis and Feasibility Study .............................41 4.3. P-3 Technical and Functional Design .......................................................... 41 42 P-3.1 Select and Finalize Component List ...................................................... P-3.2 Prepare Implementation Strategy ...:...................................................... 42 P-3.3 Site Selection .......................................................................................... 43 P-3.4 Prepare Operational .............................................................................. 44 44 ............................................................ P-3.5 DeJine Future Expansion Guide P-3.6 Develop Risk Scenario and ContingencyPlan ......................................45 P-3.7 Finalize Data Center Design ................................................................. 46 48 4.4. P-4 Procurement & Implementation ............................................................ .......................................... P-4.1 Initiate Tender Process ............................... 49 49 P-4.2 Finalize with Steering Committee .......................................................... ................................................................. P-4.3 Initiate Project Management 50 P-4.4 Project Planning .................................................................................... 50 P-4.5 Project Execution ................................................................................... 50 P-4.6 Project Controlling ................................................................................ 51 4.5. P-5 Acceptance & Operationalized ...............................................................51 . . . P-5.1 Commzsszonzng....................................................................................... 52 52 P-5.2 Acceptance of Data Center .................................................................... 8-5.3 Gap Mitigation ....................................................................................... 52 P-5.4 Execute Migration Plan ......................................................................... 52 P-5.5 Data Center Operationalized................................................................. 52 4.6. P-6 Monitoring & Review ......;...................................................................... 53 P-6.1 DeJine Architecture for Central Monitoring .......................................... 53 P-6.2 Development of DC Dashboard ........:.................................................... 54 P-6.3 Data Center Periodic Monitoring ................................................... 54 P-6.4 Gap Mitigation and Counter Action ..................................................... 55 . . . ................................................................................... 55 4.7. P-7 Decommrsszonzng
P.7.1 End of L$e Conjrmafion....................................................................... 56 P.7.2 Execute Disposal Plan ........................................................................... 56 56 IV.5. Alur Kerja Dokumen Pusat Data .................................................................... I V.6. Formal Technical Review ...............................................................................58 IV.7. Analisis Manfaat ............................................................................................ 59 IV.8. Potensi Pengembangan................................................................................... 59 BAB V. DASHBOARD MANAJERlAL PUSAT DATA ..................................................................... 60 V.1. Spesifikasi Kebutuhan Perangkat Lunak (SKPL) ........................................... 60 1.1. Pendahuluan ................................................................................................ 60 Tujuan .............................................................................................................. 60 . . Definisi, Akronim, dan Singkatan ................................................................... 60 1.2. Deskripsi Umum Perangkat Lunak .............................................................. 60 Perspektif Produk ............................................................................................60 Fungsi Produk .................................................................................................. 64 . . Karakteristik Pengguna ................................................................................... 65 Batasan-batasan ............................................................................................... 65 Asumsi dan Ketergantungan............................................................................ 66 . . 1.3. Deskripsi h n c i Kebutuhan........................................................................... 66 Kebutuhan Antarmuka Ekstemal .................................................................... 66 Kebutuhan Fungsional ..................................................................................... 67 Kebutuhan Data ............................................................................................... 75 Ringkasan Kebutuhan ...................................................................................... 75 76 V.2. Deskripsi Perancangan Perangkat Lunak (DPPL) ........................................... 7 6 2.1. Pendahuluan ........................................................................................ Tujuan .............................................................................................................. 76 Lingkup Masalah ............................................................................................. 76 Definisi. Akronim. dan Singkatan ................................................................... 76 2.2. Deskripsi Perancangan Global ..................................................................... 76 Deskripsi Data .................................................................................................76 .. Dekomposisi Fungsional Modul ......................................................................77 Dekomposisi Fisik Modul ............................................................................... 78 Matriks Ketenmutan .................................................................................... 7 8 V.3. Perencanaan Uji Perangkat Lunak (PUPL) .....................................................79 3.1. Pendahuluan .................................................................................................79 Tujuan ....................................................... ................................................ 79 .... Definisi. Akronim. dan Singkatan .............................................................. 80 3.2. Lingkungan Pengujian Perangkat Lunak ...................................................... 80 Perangkat Lunak .............................................................................................. 80 Perangkat Keras ............................................................................................... 80 ....................................................81 Material Tambahan ..................................... Instalasi. Pengujian. dan Pengendalian ........................................................... 81 ........................................................................................ Rencana Pengenalan 81 ..................................................................... Pengujian yang Akan Dilakukan 81 .. 3.3. Identifikasi Pengu~lan................................................................................... 81 Infomasi Umum .:...................................................................... 81 .. ..................... .......................................................................................... Rencana Pengu~ian 82 V.4. Hasil Uji Perangkat Lunak (HUPL) ................................................................ 82 4.1. Pendahuluan ................................................................................................. 82 Identifikasi ....................................................................................................... 82 Deskripsi Dokumen .........................................................................................82 -~
~
Definisi. Akronim. dan Singkatan ................................................................... .. 4.2. Deskripsi Umum Hasil Uji ........................................................................... . . Penilalan Umum ......................................................................................... Rekomendasi ................................................................................................... . . . . . 4.3. Perincian Hasil Uji .................................................................................... Hasil Uji Modul Front-end [HUPL.AMDASH .K-0 I] .................................... Hasil Uji Modul Back-end [HUPL.AMDASH.K.02] ..................................... V.5. Potensi Pengembangan ....................................................................................
83 83 83 83 83 83 85 87
BAB VI. SllWPULAN DAN SARAN ..........................................................................................88
VI.l. Simpulan................................................................................................... 88 VL2 . Saran...............................................................................................................89
DAFTAR PUSTAKA ....................................................................................................................... 90
...
Vlll
DAFTAR TABEL Tabel 1 Keterkaitan UML dengan . . SDLC................................................................... 26 Tabel 2 Jadwal kegiatan penehtlan .............................................................................. 32 Tabel 3 Kesepakatan kode untuk diagram dokumen masukan. proses. dan dokumen keluaran ...................................................................................................................... 34 Tabel 4 Contoh checklist untuk RFQ ..........................................................................40 Tabel 5 Contoh checklist untuk validasi biaya dan ketersediaan komponen .............. 41 Tabel 6 Contoh kriteria kinerja pusat data .................................................................. 45 Tabel 7 Skema penggunaan rak dan data-data pelengkapnya ..................................... 47 Tabel 8 Keterlibatan peran dalam kegiatan FTR ......................................................... 58 Tabel 9 Kategori dan parameter yang menjadi indikator utama kinerja pusat data ....61 Tabel 10 Hubungan antara sitemap dengan kode kebutuhan sistem ........................... 65 Tabel 11 Kategori pengguna AMDASH .............................................................. 65 Tabel 12 Tabel ringkasan kebutuhan fungsional dan non-fungsional AMDASH ....... 75 Tabel 13. Tabel-tabel yang terdapat pada AEADASH ................................................. 76 Tabel 14 Fungsi/proses pada AMDASH dan kode perancangannya ........................... 77 Tabel 15 Dekomposisi fisik AMDASH ....................................................................... 78 78 Tabel 16 Matriks keterunutan antara kode kebutuhan danperancangan .................... Tabel 17 Perangkat lunak untuk rencana pengujian.................................................... 80 Tabel 18 Hasil pengujian modul+ont-end .................................................................. 83 85 Tabel 19 Hasil pengujian modul back-end ..................................................................
DAFTAR GAMBAR Gambar 1. Peran dan karakteristik TI (sumber: Vipro. 2005)....................................... 6 Gambar 2. Keselarasan antara Process-People-Technology (sumber: Vipro. 2005)....7 Gambar 3. Arsitektur end-to-end saat ini (sumber: David Homby et al.. 2002)......... 12 Gambar 4 . Simbolprocess (surnber: Rijanto Tosin. 1994)......................................... 19 Gambar 5. Simbol decision (sumber: Riianto Tosin. 1994)........................................ 19 " Gambar 6. Simbol terminal (sumber: Rijanto Tosin. 1994)........................................ 20 Gambar 7. Simbol document (sumber: Rijanto Tosin. 1994)...................................... 20 Gambar 8. Contoh tampiIan produk dashboard....................................................... 21 Gambar 9. Lapisan rekayasa perangkat lunak (sumber: Roger S. Pressman. 1997)...22 Gambar 10. Model linear sequential (sumber: Roger S. Pressman. 1997)................. 24 Gambar 11. Segitiga pemod&n per&gkat lunak (sumber: Sri ~ h a n v i ~ h t2003) i . .. 25 Gambai 12. Kerangka pemikiran penelitian................................................................ 30 Gambar 13. Kerangka Kerja Level 0........................................................................... 35 Gambar 14. Kerangka Kerja Level 1........................................................................... 37 Gambar 15. Kerangka Kerja Level 2 untuk P-1 Business Requirement......................37 Gambar 16. Kerangka Kerja Level 3 untuk P-1.2 Determine Stakeholder................. 38 Gambar 17. Kerangka Kerja Level 3 untuk P.1.3 Data Documentation .................... 38 Gambar 18. Kerangka Kerja Level 3 untuk P.1.4 List and Prioritize.........................38 Gambar 19. Kerangka Kerja Level 2 untuk P-2 Analysis and Feasibility Study......... 39 Gambar 20. Kerangka Kerja Level 3 untuk P.2.1 Information Gathering.................39 Gambar 21. Kerangka Kerja Level 3 untuk P.2.2 Sizing............................................40 Gambar 22. Kerangka Kerja Level 3 untuk P-2.3 Issue RFQs and Collect Quotations. ..................................................................................................................................... 40 Gambar 23 . Kerangka Kerja Level 2 untuk P-3 Technical and Functional Design; ..41 Gambar 24. Kerangka Kerja Level 3 untuk P-3.1 Select and Finalize Component List . ..................................................................................................................................... 42 Gambar 25. Kerangka Kerja Level 3 untuk P-3.2 Prepare Implementation Strategy.42 Gambar 26. Kerangka . Keria Level 3 untuk P.3.3 Site Selection................................43 Gambar 27. Kerangka Kerja Level 3 untuk P.3.4 Prepare Operational....................44 Gambar 28. Kerangka Kerja Level 3 untuk P.3.5 Define Future Expansion Guide...44 Gambar 29. Kerangka Kerja Level 3 untuk P-3.6 Develop RiskScenario and Contingency Plan........................................................................................................ 45 Gambar 30. Kerangka Kerja Level 3 untuk P.3.7 Finalize Data Center Design ........ 46 Gambar 31. Kerangka Kerja Level 2 untuk P-4 Procurement &Implementation......48 Gambar 32. Kerangka Kerja Level 3 untuk P.4.1 Initiate Tender Process................49 Gambar 33. Kerangka Kerja Levei 3 untuk P-4.2 Finalize with Steering Committee.49 Gambar 34. Kerangka Kerja Level 3 untuk P.4.3 Initiate Project Management........50 Gambar 35. Kerangka Kerja Level 3 unruk P.4.4 Project Planning...........................50 Gambar 36. Kerangka Kerja Level 3 untuk P.4.5 Project Execution......................... 50 Gambar 37. Kerangka Kerja Level 3 untuk P.4.6 Project Controlling.......................51 Gambar 38. Kerangka Kerja Level 2 untuk P-5 Acceptance & Operationalized........51 Gambar 39. Kerangka Kerja Level 3 untuk P.5.1 Commisioning...............................52 Gambar 40. Kerangka Kerja Level 3 untuk P.5.3 Gap Mitigation.............................52 Gambar 41. Kerangka Kerja Level 2 untuk P-6 Monitoring & Review ......................53 Gambar 42. Kerangka Kerja Level 3 untuk P-6.1 Define Architecturefor Central . . ...................................................................................................................53 Monztorzng
Gambar 43 . Kerangka Kerja Level 3 untuk P.6.2 Development of DC Dashboard ... 54 Gambar 44 . Kerangka Kerja Level 3 untuk P-6.3 Data Center Periodic Monitoring.54 Gambar 45 . Kerangka Kerja Level 3 untuk P-6.4 Gap Mitigation and Counter Action . Gambar 46 . Kerangka Kerja Level 2 untuk P-7 Decomissioning ............................... 55 Gambar 47 . Alur kerja dokumen pada daur hidup pusat data (bagian 1 dari 4).......... 56 Gambar 48 . Alur kerja dokumen pada daur hidup pusat data (bagian 2 dari 4).......... 57 Gambar 49 . Alur kerja dokumen pada daur hidup pusat data (bagian 3 dari 4).......... 57 Gambar 50 . Alur k e j a dokumen pada daur hidup pusat data (bagian 4 dari 4 ).......... 57 Gambar 51 . Potensi pengembangan kerangka kerja................................................. 59 Gambar 52. AMDASH dalam Kerangka Kerja Daur Hidup Pusat Data............... 61 Gambar 53 . Keterkaitan arsitektur internal dengan eksternal AMDASH................... 62 Gambar 54. Modul+ontend dan backend dengan masing-masing sitemap-nya pada AMDASH.................................................................................................................... 63 66 Gambar 55 . Garnbaran aplikasi AMDASH.............................................................. Gambar 56 . Use-case diagram antara actor Pengguna dan use-case-nya dalam modul frontend ...................................................................................................................... 67 Gambar 57 . Use-case dicgrcm mtara actor Administrator dan use-case-nya dalarn modul backend........................................................................................................... 67 Gambar 58 . Sequence diagram untuk proses login pengguna .................................... 68 Gambar 59 .Sequence diagram untuk proses logout pengguna ..................................68 Gambar 60. Sequence dianram untuk mengakses menu dashboard........................... 68 Gambar 61. ~eguencediagram untuk menampilkan informasi detil dari suatu parameter ..................................................................................................................... 69 Gamb* 62. Sequence diagram untuk mengakses menu controlpanel .......................69 Gambar 63. Sequence diagram untukmenampilkan PICA dengan kriteria waktu tertentu....................................................................................................................... 69 Gambar 64. Sequence diagram mtuk mengubahproblem identz3cation atas suatu . . kejadian.................................................................................................................... 70 Gambar 65. Sequence diagram untuk mengubah counter action atas suatu kejadian.70 Gambar 66 . Sequence diagram untuk mengakses menu option.................................. 70 Gambar 67 . Sequence diagram untuk mengubahpassword.......................................71 Gambar 68. Sequence diagram untuk mengubah tampilan desktop pengguna ........... 71 Gambar 69. Sequence diagram untuk proses login administrator............................... 71 Gambar 70. Sequence diagram untuk proses logout administrator.............................72 Gambar 71. Sequence diagram untuk mengakses menupassword.............................72 Gambar 72. Sequence diagram untuk mengubahpassword administrator................. 72 Gambar 73. Sequence diagram untuk mengakses menu user list............................... 73 Gambar 74.Sequence diagram untuk menambah pengguna ...................................... 73 Gambar 75. Sequence diagram untuk mengubahpassword pengguna .......................73 Gambar 76. Sequence diagram untuk menghapus pengguna ......................................74 Gambar 77. Sequence diagram untuk mengakses menu target setting....................... 74 Gambar 78. Sequence diagram untuk melihat target dari parameter pada tahun tertentu......................................................................................................................... 74 Gambar 79. Sequence diagram untuk mengganti target dari suatu parameter ............ 74 Gambar 80 . Class diagram untuk menggambarkan skema relasi tabel yang terlibat. 75 Gambar 8 1 . Gambaran pengembangan AMDASH..................................................... 87 Gambar 82. Modul Frontend - Login .......................................................................... 25 Gambar 83 . Modul Frontend - Dashboard .................................................................. 26 Gambar 84 . Modul Frontend - Control Panel .............................................................26 -
Gambar 85. Modul Frontend . Option ......................................................................... Gambar 86. Modul Backend - Login .......................................................................... Gambar 87. Modul Backend - Home .......................................................................... Gambar 88. Modul Backend - Password .................................................................... Gambar 89. Backend - Userlist ................................................................................... Gambar 90. Modul Backend - Target Setting.............................................................
xii
26 27 27 27 27 28
BAB I. PENDAHULUAN 1.1. Latar Belakang Pesatnya perkembangan teknologi informasi dan komunikasi telah menghadirkan beragarn aplikasi perangkat lunak (sofhoare) untuk memenuhi berbagai macam kebutuhan pengguna, baik pengguna individu, kelompok, organisasi, instansi, institusi, perusahaan, atau bahkan negara. Fokus perhatian dari pengelolaan d m perawatan aplikasi perangkat lunak sangat ditentukan oleh seberapa penting keberadaannya bagi pengguna. Sebagai ilustrasi, perlakuan terhadap suatu aplikasi yang menjadi aplikasi andalan (core-application) di sebuah bank swasta internasional berbeda dengan perlakuan terhadap suatu aplikasi andalan di sebuah organisasi nirlaba. Indikator kinerja utama (key performance indicator) yang dijadikan sebagai tolok ukur keberhasilan pencapaian atas tuntutan kebutuhan pengguna (key result area) antar aplikasi pun berbeda. Dalam pengelolaan dan perawatan aspek fisik perangkat lunak, perangkat keras (hardwaretperangkat jaringan (netware)-media penyimpanan (dataware) merupakan bagian komplementer tak terpisahkan yang biasanya terintegrasi dalam sebuah pusat data (data center). Pusat data merupakan suatu fasilitas yang berguna untuk menyimpan dan mengelola perangkat elektronik berskala besar (unumnya perangkat komputasi dan komunikasi) agar dapat memenuhi tuntutan kebutuhan pengguna. Operational excellence yang tercermin melalui kegiatan rutin sehari-hari pusat data harus dapat memenuhi standar kinerja yang tinggi dalam menjamin integritas dan fungsionalitas data bagi pengguna. Pencapaian standar kinerja tersebut juga sangat ditentukan oleh strategic excellence yang tercermin melalui bagaimana ketajaman analisis kebutuhan, kualitas desain dan rancangan logis, pengimplementasian konstruksi fisik, ketepatan penentuan indikator kinerja utama operasional pusat data, serta strategi penerapan manajemen perubahan (change management) dalam membentuk perilaku sumber daya manusia (brainware) yang diharapkan.
1.2. Formulasi Permasalahan Dalam ha1 strategis, saat ini belum terdapat metode baku yang dapat dijadikan sebagai acudarahan dalam membuat rancangan logis, mengimplementasikan konstruksi fisik, serta memantau kegiatan operasional sehari-hari pusat data. Perusahaan yang ingin membangun sebuah pusat data seringkali hanya bermodalkan pengalaman empiris anggota timnya atau mengandalkan keberuntungan melal~itrial and error. Adakalanya mereka berkonsultasi dengan vendor namun seringkali hasil konsultasi tersebut membuat mereka terjebak pada solusi yang tidak optimal mengingat vendor juga memiliki kepentingan politis untuk menawarkan solusi yang umumnya sangat kental dengan merek tertentu. Kondisi tersebut diperparah oleh kurangnya rasa kepemilikian (sense of ownership) perusahaan terhadap pusat data karena vendor jarang melibatkan perusahaan dalam proses pengimplementasian solusi sehingga mengakibatkan tingkat kebergantungan perusahaan kepada vendor menjadi sangat besar. Solusi yang ditawarkan vendor juga cenderung bersifat quick-fix dan tidak menyeluruh karena jarang dikaitkan dengan rencana pengembangan teknologi informasi dan bisnis perusahaan di masa depan. Akibatnya, pertumbuhan pusat data menjadi terbatas dan
ketika titik tersebut tercapai, mau tidak mau perusahaan harus mencari solusi baru yang seringkali hams merombak ulang apa yang telah ada. PT Adira Dinamika Multi Finance, Tbk (Adira) mempakan suatu pemsahaan pembiayaan terkemuka yang pusatnya berlokasi di Jakarta. Semenjak PT Bank Danamon Indonesia, Tbk (Danamon) menjadi pemegang saham mayoritas, pengawasan terhadap pelaksanaan prosedur di Adira menjadi lebih ketat mengingat selama ini Danamon sangat kental dengan kepatuhan terhadap standar dunia perbankan yang berlaku. Permasalahan muncul ketika pusat data yang sudah dimiliki Adira herdak diaudit Danamon. Danamon tidak memberikan arahan mengenai standar mana yang menjadi acuan dalam audit dan memberikan kebebasan penuh kepada Adira untuk menentukan. Karena ha1 tersebut mempakan sesuatu yang bam, ditambah saat ini Adira sedang melakukan migrasi pusat data mereka ke lokasi baru, Adira merasa perlu melakukan audit internal untuk melihat tingkat kesesuaian dari apa yang sudah dilakukan dengan apa yang menjadi standar acuan. Berdasarkan gambaran kondisi nyata tersebut, dirasa perlu adanya metode baku yang dapat dijadikan sebagai acuanlarahan dalam membuat rancangan logis, mengimplementasikan fisik, serta mengawasi kegiatan operasional sehari-hari pusat data. Dalam ha1 operasional, pusat data biasanya mengoperasikan beragam peralatan elektronik dengan beragam standar dan beragam aplikasi pemantau kinerja. Aplikasi yang ada jarang dapat memantau kinerja peralatan-peralatan di pusat data secara terintegrasi. Bahkan Adira belum memiliki standar kinerja dan aplikasi yang dapat memantau performa kinerja peralatan elektronik pusat data. Berdasarkan gambaran kondisi nyata tersebut, dirasa perlu adanya suatu standar kinerja pusat data dan aplikasi yang dapat berfungsi sebagai manajemen visual merangkap decision support tool untuk membantu pengambilan keputusan pihak manajemen dalam menindaklanjuti suatu permasalahan yang terjadi di pusat data.
1.3. Tujuan Penelitian Berlatar belakang permasalahan konkrit di atas, penelitian ini bertujuan untuk 1 Dalam konteks strategis, merancang suatu kerangka kerja Cframework) acuan dalam membangun dan mengoperasikan pusat data. Metodologi penelitian yang dilakukan mencakup: mempelajari, memahami, kemudian memetakan langkah-langkah pembangunan serta pengoperasian pusat data ke dalam kerangka kerja bempa dokumen yang diberi nama Kerangka Kerja Daur Hidup Pusat Data (Data Center Life-Cycle Framework). 2 Dalam konteks operasional, mengimplementasikan purwampa (prototype) aplikasi pengelolaan pusat data sebagai suatu proof of concept dari pemantauan kinerja pusat data berdasarkan standar kinerja yang disepakati. Metodologi penelitian yang dilakukan mencakup: menangkap kebituhan pengguna, menganalisis, mendesain, kemudian memrogram suatu a~likasi vang diberi nama Adjusted Management DASHboard ( A M D A ~ ) . ~eselu;;han proses tersebut terangkke dalam suatu dokumen yang diberi nama Dashboard Manajerial Pusat Data (Data Center Management Dashboard). Tesis ini mengambil judul "Perancangan Kerangka Kerja Daur Hidup dan Implementasi Dashboard Manajerial Pusat Data" dengan dosen pembimbing tesis sebagai berikut 1 Dr. Sugi Guritman 2 Ir. Heru Triyono Natalisa, M.Math.
1.4. Ruang Lingkup Kerangka Kerja Daur Hidup Pusat Data merupakan dokumen yang dirancang
dengan mengacu kepada berbagai standar dan praktik terbaik yang banyak dijadikan sebagai referensi dalam pembangunan dan pengoperasian sebuah pusat data. Adapun garis besar siklus dan proses pembangunan serta pengoperasian pusat data tergambar dalam diagram level 0 dimana urutan siklus danlatau prosesnya menggambarkan langkah-langkali yang akan diikuti untuk sampai pada suatu desain pusat data yang efektif dan sesuai dengan kebutuhan operasional perusahaan untuk kemudian diimplementasikan. Kerangka Kerja Daur Hidup Pusat Data mencakup pula Alur Kerja Dokumen Pusat Data (Data Center Document Workj7ow), yakni dokumen yang n~enggambarkanaliran dokumen yang terlibat dalam Kerangka Kerja Daur Hidup Pusat Data. Dashboard Manajerial Pusat Data merupakan dokumen perancangan dan implementasi suatu purwarupa pemantauan kinerja pusat data bernama AMDASH. Berbeda dengan gauge-meter atau life-meter, AMDASH lebih berfungsi sebagai alat
manajemen yang memantau tindak lanjut dari tindakan koreksi (corrective action) berkenaan dengan ~ermasalahanyang terjadi (problem & issue) dalam pencapaian indikator kinerja utama pusat data. Informasi yang ditampilkan AMDASH dikelompokkan dalam lima kategori: Server, memory, disk system Database Storage Area Network (SAN) Backbone nehvork Facility
1.5. Manfaat Penelitian Kerangka Kerja Daur Hidup Pusat Data diharapkan dapat menjadi acuan dan
arahan dalam pembangunan serta pengoperasian sebuah pusat data yang baik dan berkualitas. Selain dapat digunakan sebagai referensi dalam pengimplementasian sebuah pusat data, dokumen ini dapat juga di-wakan sebagai alat audit untuk memantau seberapa jauh suatu pusat data telah memenuhi kaidah dan aturan seperti yang telah tertuang di dalamnya. AMDASH diharapkan dapat menjadi aplikasi perangkat lunak manajemen visual yang berfungsi sebagai alat bantu pengambilan keputusan dalam mengelola pusat data secara efektif dan efisien. Karenanya, informasi yang ditampilkan hams sama bagi semua orang dan berdampak secara langsung terhadap indikator kinerja utama pusat data.
1.6. Keaslian Penelitian Sejauh ini belum terdapat dokumen yang menjadi standar dan acuan baku dalam pembangunan dan pengoperasian pusat data. Dokumen yang sering dijadikan sebagai acuan praktis dalam pembangunan dan pengoperasian pusat data adalah dokumen karangan Rob Snevely berjudul "Enterprise Data Center Design and Methodology" yang diterbitkan oleh Sun Microsystems, Inc. Namun dokumen ini hanya memaparkan filosofi dan garis besar pembangunan dan pengoperasian pusat data serta kurang menj'elaskan langkah-langkah yang hams dilakukan dalam pelaksanaan kedua proses tersebut. Komponen-komponen yang dicantumkan juga terlalu spesifik dengan produk perangkat keras keluaran Sun Microsystems.
Saat ini terdapat banyak aplikasi dashboad pengelolaan pusat data seperti HP OpenView dan Orion Solarwinds. Namun sayangnya belum ada satupun dari aplikasi tersebut yang dapat berfungsi sebagai alat manajemen yang ampuh karena kebanyakan dari aplikasi tersebut hanya menitikberatkan pada pemantaum dan pelaporan kinerja pusat data serta tidak bisa menangkap keputusan dan tindak lanjut yang diputuskan oleh pihak manajemen sehubungan dengan suatu kejadian. Dashboard Manajerial Pusat Data diharapkan dapat menjadi aplikasi yang menjembatani fitur yang ditawarkan oleh aplikasi dashboard pengelolaan pusat data yang sudah ada terlebih dahulu dengan keputusan manajemen sehingga kehadirannya dapat menambal kekurangan-kekurangan yang terjadi terutama dari sisi aspek manajerial.
1.7. Sistematika Penulisan Bagian utama tesis ini terdiri dari 7 (tujuh) bab yaitu: Pendahuluan, Landasan Teori, Metodol~giPenelitian, Kerangka Kerja Daur Hidup Pusat Data, Dashboard Manajerial Pusat Data, Pembahasan, serta Simpulan dan Saran dengan rincian sebagai berikut: Bab I. Pendahuluan Bab ini menguraikan latar belakang, formulasi permasalahan, tujuan penelitian, ruang lingkup, manfaat penelitian, keaslian penelitian, serta sistematika penulisan. Bab 11. Tinjauan Pustaka Bab ini berisi tinjauan pustaka mengenai IT service excellence management, pusat data, rekayasa sistem, flowchart, digital dashboard, rekayasa perangkat lunak (sofhuare engineering) dan Plan-Do-CheckAction (PDCA). * Bab 111. Metodologi Penelitian Bab ini menjelaskan detil metodologi penelitian yang dilakukan melalui paparan kerangka pemikiran, tata laksana, waktu dan tempat, serta bahan dan alat penelitian. a Bab IV. Kerangka Kerja Daur Hidup Pusat Data Bab ini menguraikan tujuh faseltahapan daur hidup pusat data secara berjenjang mulai dari Level 0 sampai level 3 dimana setiap level menggambarkan detil proses pada setiap fasettahapan dalam daur hidup pusat data. Bab ini juga memaparkan uji validasi dan kelayakan serla bagaimana potensi pengembangan kerangka kerja ke depannya. a Bab V. Dashboard Manajerial Pusat Data Bab ini menguraikan analisis, desain, implementasi, rencana pengujian, dan hasil pengujian aplikasi purwarupa Dashboard Manajerial Pusat Data bernarna ADMASH. Keseluruhan proses tersebut mengacu pada standar pendokumentasian perangkat lunak yang terdiri &mi Spesifikasi Kebutuhan Perangkat Lunak (SKPL), Deskripsi Perancangan Perangkat Lunak (DPPL), Perencaan Uji Perangkat Lunak (PUPL), dan Hasil Uji Perangkat Lunak (HUPL). Bab ini juga menjabarkan bagaimana potensi pengembangan aplikasi purwarupa tersebut ke depannya. a Bab VI. Sim~ulan dan Saran Bab ini menjabarkan kesimpulan yang didapat dari penelitian beserta saran yang diajukan sebagai bahan pertimbangan untuk perbaikan ke depannya. a Lampiran A
Selain bagian utama, tesis ini juga dilengkapi dengan beberapa lampiran yang diharapkan dapat memperjelas pemahaman mengenai penelitian yang telah dilakukan.
BAB 11. TINJAUAN PUSTAKA 1
. IT Service Excellence Management
Saat ini, isu utama yang berkaitan dengan kelemahan teknologi informasi (TI) adalah ketidakmampuannya untuk bergerak cepat dan responsif dalam menyumbang nilai kompetitif bisnis. Menurut Vipro (2005), umumnya perusahaan memandang bagian teknologi informasi mereka: Tidak mampu memenuhi apa yang telah dijanjikan, bahkan cenderung semakin parah dari hari ke hari. Tidak responsif terhadap perubahan kebutuhan bisnis yang sangat tergambarkan dari kebutuhan pengguna. Tidak sejalan dengan strategi dan operasional bisnis. Tidak dapat menjadi aset, baik dalam konteks biayafnilai finansial dan kapasitasnya dalam berkontribusi sebagai nilai bisnis. Mahal. Dalam pengerjaan proyek untuk mengimplementasikan pembahan bisnis, biasanya lebih banyak biaya yang dikeluarkan daripada nilai tambah yang diberikan. Hal ini diperparah dengan rendahnya Return on Investment (ROI) suatu penerapan teknologi. Lebih berorientasi kepada teknologi daripada berorientasi kepada bisnis.
Gambar 1. Peran dan karakteristik TI (sumber: Vipro, 2005).
Pada Gambar I., masih menumt Vipro (2005), umumnya konsultan TI mengklaim bahwa mereka lebih mengerti mengenai proses dan teknologi dimana mereka menawarkan layanan jangka pendek yang lebii responsif terhadap bisnis utama atau apa yang menjadi prioritas. Di sisi lain, vendor TI mengklaim bahwa mereka memiliki solusi teknologi dimana solusi yang ditawarkan seringkali lebih bersifat product-driven. Mereka juga menawarkan layanan jangka pendek yang lebih responsif terhadap bisnis utama atau apa yang menjadi prioritas. Padahal sebenarnya, internal TI perusahaan lebih memahami apa yang menjadi kendala atau tantangan, lebih memahami siapa yang menjadi pengguna, dan lebih bertanggung jawab dalam memberikan layanan yang berkelanjutan. Narnun sayang, internal TI pemsahaan seringkali kurang responsif terhadap prioritas lainnya. Sekitar 75% anggaran TI dialokasikan untuk kegiatan operasional dan hanya 25% yang dialokasikan untuk investasi/inovasi proyek. Kondisi tersebut diperburuk dengan suatu kebiasaan dimana TI dikendalikan oleh perkembangan teknologi saja dan tidak dapat mengintegrasikan serta memfokuskan kepada sumber daya manusia dan proses bisnis.
Vipro (2005) juga mengatakan bahwa secara garis besar, tantangan bagi perusahaan saat ini adalah mernbuat bagian TI mereka mampu memberi nilai lebiwtambah dari waktu ke waktu meskipun: Tuntutan untuk rnengurangi sumber daya manusia sernakin meningkat sebagai bagian dari rencana peningkatan produktifitas dan efisiensi. Alokasi anggaran TI untuk perawatan dan proyek relatif tetap dari tahun ke tahun sementara biaya yang dibutuhkan terus bertambah. 0 Anggaran yang tersedia untuk memberikan layanan baru berkurang dari tahun ke tahun disebabkan pertumbuhan portofolio perusahaan. Sedangkan tantangan berat bagi para Chief Information Oflcer (CIO) adalah untuk Menyediakan dana lebih untuk proyek dengan cara mengurangi jatah untuk anggaran operasional. 0 Menyediakan lebih banyak sumber daya manusia untuk proyek dan inisiatif strategis. 0 Meningkatkan produktifitas dan ketersediaan layanan. 0 Meningkatkan kepuasan pelangganlpengguna dengan cara: o Memberikan layanan berkualitas. o Mengurangi waktu yang dibutuhkan untuk implementasi atau memecahkan permasalahan. o Lebih cepat tanggap.
.a=-
.'J ;.,i7esd. , i:.
\ "
*,
Gambar 2. Keselarasan antara Process-People-Tecltrtology (sumber: Vipro, 2005).
Pada akhimya, Vipro (2005) meyakini bahwa perusahaan yang akan sanggup bertahan dan memenangkan persaingan adalah perusahaan yang Mampu menjembatani antara sumber daya TI perusahaan, proses bisnis, dan sumber daya manusia sambil tetap mengacu kepada strategi perusahaan. e Mampu membuat sumber daya perusahaan mencapai kondisi operating excellence. Mampu mengoptimalkan sumber daya TI yang ada (sistem, fasilitas, dan tim) sampai ke ambang batas kinerja, kehandalan, dan ketersediaannya tanpa banyak mengeluarkan biaya tambahan. Atau sederhananya, perusahaan yang mampu bertahan dan memenangkan persaingan adalah perusahaan yang berhasil mengembangkan dan mengintegrasikan
sumber daya manusia ('people) dengan proses bisnis ('process) melalui pengelolaan layanan yang memuaskan (service excellence management) untuk menjamin informasi dan perencanaan sumber daya perusahaan (enterprise resource planning) dapat berjalan dengan baik dalam rangka mendukung bisnis perusahaan Pengelolaan layanan yang memuaskan merupakan serangkaian standar, kerangka kerja, metodologi, dan acuan dalam memberikan layanan yang dapat diandalkan, efektif dari sisi biaya, serta berkualitas dengan memerhatikan tingkat kepuasan penggundpelanggan yang dapat membuat perusahaan mampu berkompetisi dalam ~ersainganpasar saat ini. Secara nyata, Vipro (2005) meyakini bahwa untuk memberikan layanan yang memuaskan, perusahaan haruslah: Memilih dan memiliki orang yang tepat. 0 Mengelola dan mempertahankan kepuasan pelanggan, misal dengan mendapatkan umpan balik melalui survey kepuasan pelanggan dan tindak lanjutnya secara berkala. Menerapkan praktik terbaik, misal Infortnation Technology Infrastructure Library (IT-IL) dari Oflce of Government Commerce (OCG), Control Objectives for Information and Related Technology (COBIT), dan lainlain. Melakukan sesuatu dengan benar dari awal. 0 Benchmark dengan industri yang samalberbeda dan bandingkan dengan standar global. Menerapkan perbaikan berkelanjutan (continuous improvement).
11.2. Pusat Data 2.1. Pengantar "The historical path of the data center is not that o f a pendulum that simply reverses direction periodically. Rather, it is of a spiral or a ratchet that is inexorably evolving the data center in a single direction: toward larger numbers of smaller, simpler, more specialized component systems that are more dynamically composed into solution systems via increasingly powerful networks. This is the data center of thefitwe." Metagroup.com (2004). Menurut Richart T. Matlus et al. (ZOOS), pusat data (data center) merupakan perangkat komputer terpusat yang dilengkapi dengan fasilitas aman, inflastruktur jaringan, serta proses dan organisasi yang mendukung. Menurut Wikipedia (2005), pusat data dapat menempati satu ruangan dalam gedung, satu lantaillebih, atau seluruh gedung. Beberapa kota di luar negeri bahkan memiliki bangunan khusus yang didedikasikan sebagai pusat data yang terletak di lokasi aman dan dekat dengan sentra layanan telekomunikasi. Perangkat pusat data umumnya diletakkan pada server 1U (sering disebut juga sebagai pizza boxes) yang disusun pada rak 19 inci memanjang dan membentuk semacarn koridor dengan rak 19 inci lainnya untuk memungkinkan orang mengakses bagian depan dan belakang dari setiap rak. Terkadang sejumlah perangkat seperti komputer mainfran~edan media penyimpanan berukuran sebesar rak-rak tersebut diletakkan bersebelahan dengannya. Alasan keberadaan suatu pusat data berbeda antara satu pengguna dengan pengguna lainnya yang sangat dipengaruhi oIeh tingkat kedewasaan organisasi dari pengguna bersangkutan. Terdapat beragam alasan yang mendasari pengguna dalam
mendirikan pusat data, salah satunya adalah terdapat kebutuhan atas keberadaan sistem yang terintegrasi secara fisik untuk memudahkan proses pengelolaan dan pemeliharaan perangkat komputasi yang dibutuhkan. Rob Snevely (2002) memaparkan bahwa filosofi desain yang moduler dan mudah dikembangkan (scalable) merupakan faktor kritis untuk dapat memenuhi kebutuhan pusat data hari ini dan masa yang akan datang. Untuk rnemberikan layanan prima, kebutuhan fungsional pusat data hams senantiasa terpenuhi. Kebutuhan fungsional yang dimaksud Rob Snevely (2002)terdiri dari 0 Tempatflokasi untuk meletakkan komputer, media penyimpanan, dan peralatan jaringan dengan aman dan nyaman. Daya listrik yang cukup untuk menghidupkan semua perangkat di atas. Lingkungan dengan temperatur terkontrol. Konektifitas antar perangkat baik di dalam maupun di luar pusat data. Di masa mendatang, menurut Metagroup (2004), kesuksesan pusat data ditentukan oleh empat kekuatan ekonomi yakni commoditization, virtualisasi (virtualization), integrasi (integration), dan inovasi (innovation). Commoditization: Standardisasi dan spesialisasi fungsi, dengan pergerakan progresif yang fokus terhadap kualitas, produkllayanan pelengkap, dan biaya. Virtualisasi: Komposisi dari pertambahan jumlah beragam subsistem yang sederhana, keciwringan, dan berbeda menjadi suatu kesatuan fungsi. Integrasi: Jaringan terpusat yang dapat saling berkomunikasiheroperasi. * Inovasi: Tingkat inovasi kurnulatif dengan ketiga hal di atas sebagai pendorong yang mampu membawa perubahan radikal untuk menghasilkan sesuatu yang baru (breakthrough) di bidang bisnis dan teknologi. 2.2. Filosofi Desain Rob Snevely (2002) memaparkan bahwa proses detil dari desain pusat data terkadang lebih banyak melibatkan proses mekanis seperti tata ruang, komputasi untuk menentukan kapasitas komponen yang diperlukan, dan beragam detil rekayasa lainnya. Tentu saja hal tersebut sangat penting dalam perancangan dan pembuatan pusat data, namun proses mekanis tersebut tidak cukup untuk membangun pusat data. Proses mekanis saja jarang menghasilkan sesuatu yang berguna, kalaupun ada biasanya mengandalkan pada faktor kebetulan saja. Sebenamya, terdapat acuan filosofis yang hams diperhatikan selama proses desain pusat data dimana acuan tersebut dirancang berdasarkan pengalaman empiris para praktisi yang telah berhasil merancang dan membangun pusat data. Masih menurut Rob Snevely (2002), terdapat sepuluh langkah yang dapat dijadikan acuan dalam mendesain pusat data: 1 Rencanakan jauh ke depan. 2 Pertahankan kesederhanaannya. 3 Fleksibilitas tinggi. 4 Berpikir modular. 5 Gunakan Rack Location Unit (RLU) dan bukan satuan meter persegi. 6 Perhatikan masalah berathobot. 7 Gunakan bahan aluminium pada lantai yang ditinggikan. 8 Beri label segalanya. 9 Jaga kerapian dan kebersihan. 10 Berharap untuk yang terbaik, bersiap untuk yang terburuk.
Sebagai pelengkap, Rob Snevely (2002) menambahkan bahwa terdapat lima nilai utama yang menjadi landasan bagi filosofi desain suatu pusat data: kesederhanaan (simpliciiy), fleksibilitas Wexibiliiy), skalabilitas (scalability), modularitas (modulariiy), dan kesehatan (sanily). Keputusan desain harus senantiasa memerhatikan kelima nilai utama tersebut. Usahakan Desain Sesederhana Mnngkin Desain pusat data yang sederhana memudahkan desain tersebut untuk dimengerti dan dikelola. Sebagai contoh, pemberian label setiap perangkat (misal: port jaringan, catu daya, kabel, saklar, lokasi perangkat tersebut di lantai) dapat mencegah pekerjaan yang bersifat menebak-nebak. Ketika memasang perangkat baru, dapat diketahui dengan mudah sebaiknya perangkat tersebut diletakkan di mana dan bagaimana perangkat tersebut harus disambungkan dengan perangkat lainnya. Hal tersebut juga memudahkan dalam memeriksa apakah pekerjaan telah dilakukan dengan baik dan benar. Desain untuk fleksibilitas Tak ada seorangpun yang dapat memastikan teknologi seperti apa yang &!an hadir lima tahun ke depan. Karenanya desain yang fleksibel dan mudah di-upgrade merupakan faktor kritis bagi keberhasilan desain jangka panjang. Tantangan utarna dari fleksibilitas adalah membuat desain dengan biaya yang efektif. Setiap keputusan desain berdampak terhadap anggaran. Desain untuk mendapatkan biaya yang efektif sangat ditentukan oleh apa yang menjadi misi dari pusat data. Desain nntuk Skalabilitas Ketika terdapat beragam perangkat yang harus diperhatikan, kalkulasi penggunaan watt per meter persegi dalam desain tidak mencukupi karena kebutuhan setiap perangkat akan daya listrik berbeda. Sebagai altematif, gunakan kalkulasi berdasarkan RLU yang mendukung skalabilitas, selain itu agar dapat direkayasa balik (reverse engineered). Gunakan Desaiu yang Modular Pusat data mmerupakan ha1 yang kompleks dan hal yang kompleks biasanya seringkali menjadi sulit dikelola. Desain modular memungkinkan membuat hal yang kompleks dari bagian-bagian kecil yang lebih mudah dikelola. Bagian-bagian kecil tersebut lebih mudah didefinisikan dan direplikasi. Menjaga Kesehatan Mendesain dan membangun pusat data dapat sangat melelahkan. Terdapat banyak hal yang dapat dan akan berjalan dengan tidak semestinya. Hal tersebut terkadang membuat tim pengembang dan pengimplementasi merasa stres namun carilah cara untuk dapat menikrnati proses tersebut.
2.3. Standardisasi dan Konsolidasi Menurut CommScope (2004), infiastruktur berbeda yang mendukung beragam pulau aplikasi umumnya sulit untuk diubah dan mahal untuk dikelola, diintegrasikan, diamankan, serta di-back up. Sejumlah contoh dari aplikasi, sistem, dan platjbrm pusat data yang dimaksud adalah e E-commerce, e-mail, dan aplikasi yang bersifat in-house.
Supply Chain Management (SCM), Enterprise Resource Planning (ERP), dan Customer Relationship Management (CRM). Media penyimpanan: storage area network dan tape back-up. * Computer clustering, mainframe systems, dan layanan IP. Masih menurut CommScope (2004), paradigma mengenai pusat data telah mengalami pergeseran dari alatlmedia penghubung antara server dengan hub. Definisi pusat data teIah meluas dari sekedar "ruang komputer" menjadi "aset strategis perusahaan", dimana ha1 ini harus diikuti pula dengan pentingnya optimalisasi pusat data. Apabila pusat data dijadikan sebagai salah satu tolok ukur kesehatankeberhasilan perusahaan, infrastruktur jaringan yang dapat diandalkan (reliable), fleksibel Vexible), dan tahan banting (resilient) merupakan suatu ha1 yang tidak dapat ditawar lagi. Diyakini bahwa lapisan fisik infrastruktur harus tangguh (robust) dan siap sedia (versatile) dalam menyediakan dukungan dan pemantauan ketersediaan layanan 24 jam sehari 7 hari seminggu. Saat ini sejumlah organisasi standar infrastmktur dunia sedang menyusun rekomendasi yang disarankan untuk infrastruktur pengkabelan berperforma tinggi. Sebagai contoh, menurut CommScope (2004), di Arnerika Serikat standar infrastruktur tersebut telah tertuang dalam Draft TL4lEIA-942 (SP-3-0092): Telecommunications Infrastructure Standardfor Data Centers. Standar ini mencakup media pengkabelan: o ANSUTIAEIA-56843.2.1 CAT 6 cable o ANSUTIALEIA-568-B.3.1 Laser-optimized OM3 multimode cable o ANSUTIAiEIA-568-B.3 Singlenlode cable Di Eropa, standar infiastruktur tersebut tertuang dalam Draft EN 50173-5:200x : Information Technology - Generic Cabling Systems, Part 5: Data Centers. Pemilihan solusi pengkabelan yang tepat memungkinkan bagian TI untuk lebih bebas dan fleksibel dalam mendesain lapisan fisik infrastruktur agar dapat memenuhi kebutuhan pusat data. Ilal ini diyakini sebagai langkah awal yang tepat untuk konvergensi dan konsolidasi pusat data. David Hornby et al. (2002) memaparkan bahwa pada awalnya, fokus konsolidasi adalah server namun fokus tersebut saat ini telah mengalami perubahan. Apapun yang terdapat pada suatu pusat data merupakan calon kandidat untuk dikonsolidasi. Saat ini, konsolidasi berkenaan dengan segala sesuatu yang berhnbungan dengan pengurangan jumlah peralatan yang hams dikelola dan pengurangan cara pengelolaan mereka. Lebih jauh David Hornby et al. (2002) menjelaskan, konsolidasi yang dapat dilakukan di lingkunan TI saat ini mencakup konsolidasi server, aplikasi (application), media penyimpanan (storage), shared services, jaringan (network). pusat data secara keseluruhan, serta sumber daya manusia dan proses. Konsolidasi Server
Yang dimaksud dengan mengkonsolidasi server adalah melakukan skalabilitas terhadap server yang ada secara vertikal dan horisontal dimana Skalabilitas secara vertikal memungkinkan pengurangan jumlah server dengan cara mengkonsolidasi sejmlah aplikasi ke dalam satu server. Skalabilitas secara horisontal memungkinkan peningkatan beban kerja (workload) dengan cara replikasi server dan pendistribusian beban kerja kepada server lain yang ada.
Gambar 3. Arsitektur end-to-endsaat ini (sumber: David Hornby et al., 2002).
Pada arsitektur end-to-end yang banyak ditemui saat ini, perhatikan pola dari populasi yang ada ketika mengkonsolidasi server. Pola lapisan (tier) menentukan strategi konsolidasi yang akan dilakukan dengan skalabilitas sebagai kata kuncinya. Umumnya terdapat tiga lapisan server: Lapisan presentasi (presentation tier), merupakan lapisan yang terdekat dengan pengguna, * Lapisan bisnis (businesslmiddleware tier), merupakan lapisan dimana terdapat aplikasi penghubung antar lapisan lainnya. Lapisan sumber daya (resource tier), merupakan lapisan dimana terdapat server berukuran besar yang menjalankan aplikasi kritis dan basis data. Meskipun arsitektur di atas banyak ditemui saat ini, masih banyak perusahaan yang menggunakan arsitektur tunggal (monolithic). Dalam banyak kasus, server yang ada menjalankan aplikasi yang telah stabil. Kondisi seperti inilah yang ideal untuk mengkonsolidasi server dan aplikasi. Konsolidasi Aplikasi
Dalam mengkonsolidasi aplikasi, setiap aplikasi yang ada harus dievaluasi. Pihak yang mengerti aplikasi dengan baik adalah para pengembang (developer), administrator basis data (database adminisfrator), dan administrator sistem (system administrator) yang sehari-hari menangani aplikasi tersebut. Proses konsolidasi aplikasi biasanya sangat melibatkan mereka. Secara garis besar, terdapat tiga tipe konsolidasi aplikasi yang sering dilakukan: Konsolidasi set aplikasi Konsolidasi beragam tipe basis data * Konsolidasi beban kerja yang samafmirip Konsolidasi Media Penyimpanan
Saat ini, konsolidasi media penyimpanan mendapat perhatian yang sama seperti halnya konsolidasi server. Seperti telah dikemukakan sebelumnya, penambahan server baru akan diikuti dengan bertambahnya media penyimpanan. Pada banyak kasus, biaya media penyimpanan sebuah server dapat melebihi biaya pembelian server. Meskipun server tidak terlalu banyak mengalami perkembangan, media penyimpanan yang dibutuhkan untuk suatu aplikasi umumnya pasti berkembang.
Pada suatu set aplikasi, biasanya terdapat banyak replikasi data karena banyak proses mencari pada data yang sama. Sama halnya seperti pada server, tujuan dari konsolidasi media penyimpanan adalah untuk mengurangi kompleksitas, meningkatkan utilisasi, dan menurunkan Total Cost of Ownership (TCO). Tujuan tersebut dapat dicapai melalui beragam teknik konsolidasi. Tujuan utama untuk saling berbagi data antar aplikasi seringkali terganjal karena membutuhkan perancangan dan pengembangan ulang aplikasi. Keuntungan lain dari konsolidasi media penyimpanan mencakup: Kemudahan backup dan recovery. Peningkatan ketersediaan. Peningkatan skalabilitas. Pengumpulan sumber daya penyimpanan. Secara garis besar terdapat tiga tipe konsolidasi media penyimpanan yang paling sering digunakan: * Konsolidasi server dan media penyimpanannya. Menghubungkan lingkungan heterogen dengan satu komponen media penyimpanan. Konsolidasi Storage Area Networks (SAN). Storage Area Networks (SAN) menjadi fenomena dari arsitektur penyimpanan selama beberapa tahun terakhir. Sebagai suatu teknologi, SAN telah cukup dewasa untuk diimplementasikan menggunakan konfigurasi standar. Teknologi SAN memungkinkan server dan client nemanfaatkan media penyimpanan secara langsung melalui jaringan menggunakan protokol yang banyak digunakan seperti Network File System (NFS) dan Server Message Block (SMB). Meskipun tidak digunakan secara besar-besaran pada konsolidasi server dan aplikasi di pusat data, teknologi tersebut biasanya digunakan pada konsolidasiJile dan pencetakan. Konsolidasi Shared Service
Tipe lain dari konsolidasi yang secara cepat menjadi populer adalah konsolidasi middleware atau shared service. Bertahun-tahun lamanya perusahaan telah mengimplementasikan shared service (sepertifile, pencetakan, otentikasi, dan email) melalui beragam cara. Unit bisnis biasanya mengimplementasikan versi tersendiri dari layanan ini menggunakan perangkat Iunak dari beragam vendor, namun ketika mereka hendak saling membagi sejumlah informasi, mereka menemukan adanva inkonsistensi dan ketidakcocokan antara beragam - arsitektur tersebut vans - mengakibatkan meningkatnya kompleksitas, meningkatnya biaya, dan menjadikannya sulit untuk saling - berbagi. Akibatnya, banyak perusahaan yang berusaha membangun ulang shared service Gereka menggunakan web service yang berbasis pada suatu standar dan arsitektur terintegrasi seperti SunTMOpen Net Environment (Sun ONE). Contoh m u m dari ha1 tersebut adalah penggunaan layanan direktori (directory service). Layanan direktori telah diimplementasikan bertahun-tahun lamanya dalam beragam variasi arsitektur. Karena saat ini arsitektur berbasis standar telah tersedia, produk seperti Sun One Directory Server, yang berbasis Lightweight Directory Access Protocol (LDAP), digunakan untuk merancang dan mengimplementasikan layanan direktori perusahaan. Penggabungan beragam arsitektur direktori yang terpisah menjadi satu memudahkan perusahaan dalam mengelola dan mereplikasi layanan direktori ketika dibutuhkan.
Konsolidasi Jaringan
Dalam mengkonsolidasi server dan aplikasi, konsolidasi jaringan biasanya menjadi isu besar atau bahkan tidak menjadi isu sama sekali. Ketika jumlah pusat data dikurangi dan server serta aplikasi dikonsentrasikan ke dalam lokasi fisik yang lebih sedikit, terdapat kemungkinan dimana ha1 tersebut berpengaruh terhadap jaringan yang ada. Pengaruh yang timbul tersebut perlu dievaluasi sebagai bagian dari proyek konsolidasi. Harus dipastikan bahwa tersedia bandwidth jaringan yang cukup untuk menangani lalu-lintasjaringan dari dan ke lokasi yang dikonsolidasi. Di sisi lain, ketika melakukan rasionalisasi pada sebuah pusat data, sering ditemukan bahwa tidak ada perubahan mendasar yang perlu dilakukan terhadap jaringan. Secara keseluruhan tidak terjadi peningkatan arus lalu-lintas karena tidak ada penambahan server dan aplikasi baru. Lebih lanjut, rasionalisasi dapat saja mengurangi lalu-lintas jaringan karena aplikasi-aplikasi yang berada pada satu sistem komputer dan sistem operasi tidak membutuhkan jaringan untuk berkomunikasi. Konsolidasi Pusat Data
Banyak perusahaan yang mencari cara untuk mengkonsolidasi sejumlah pusat data mereka menjadi satu. Konsolidasi ini beragam mulai dari konsolidasi sederhana antar kota sampai konsolidasi rumit antar wilayah. Kebanyakan perusahaan melakukan konsolidasi pusat data untuk menekan biava komunikasi dari "iarinnan telekomunikasi, menekan perbedaan pendapatan di bidang TI yang sangat beragam pada sejumlah wilayah di dunia, dan menekan biaya sewa lokasi yang mahal di kota . yang besar (terutama kota seperti New York, ~ o i d o n , dan ~ o k ~ i )Bagi mempertimbangkan untuk melakukan konsolidasi menjadi lokasi yang lebih sederhana, ha1 tersebut menawarkan penghematan biaya dan kemudahan inisiatif penanggulangan bencana (disaster recovery initiative). w
Konsolidasi SDM dan Proses
Dalam proyek konsolidasi, jangan pemah mengabaikan sumber daya manusia (SDM) dan proses yang ada. Sejumlah grup konsultan mengestimasi bahwa hanya 20% dari ketersediaan pusat data ditentukan oleh pilihan perangkat keras dan teknologi sedangkan 80% lainnya sangat terkait langsung dengan isu SDM manusia dan proses. Intinya adalah, konsolidasi yang berhasil hams memerhatikan stindar yang berlaku, SDM, dan proses. Keuntungan lain dari mengimplementasikan standar dan praktik terbaik adalah biasanya terjadi pengurangan sebesar 10-20% dari Total Cost of Ownership (TCO). 2.4. Service Level Agreement (SLA) Menurut Edward Wustenhoss (2002), kemampuan dalam memberikan layanan sesuai dengan apa yang telah dijanjikan menentukan nilai kompetitif dari suatu pusat data. Itu sebabnya kenapa Service Level Management (SLM) yang efektif dan efisien sangat penting dimana kunci suksesnya terletak pada apa yang disebut sebagai Service Level Agreement (SLA). SLA yang baik, masih menurut Edward Wustenhoss (2002), membantu pusat data menjanjikan apa yang mungkin diberikan dan memberikan apa yang telah dijanjikan. SLA mempertemukan ekspektasi dan harapan antara pihak pengguna dengan penyedia layanan serta menggambarkan bagaimana penyedia layanan mengatur dan mengelola komitmennya terhadap pengguna. SLA yang baik menggambarkan lima aspek penting: Apa yang dijanjikan ole11 penyedia layanan.
Bagaimana penyedia layanan akan memenuhi janji tersebut. Siapa yang akan mengukur layanan yang diberikan, dan bagaimana cara pengukurannya. Apa yang akan terjadi apabila penyedia layanan gagal memenuhi janjinya. Bagaimana SLA akan menyesuaikan terhadap perubahan waktu. Dalam menentukan SLA, komitmen yang akan diberikan haruslah realistis dan terukur. SLA urnumnya dicek ulang setiap enam bulan sekali dan diperbaiki sekiranya dibutuhkan. SLA hams mendefinisikan secara detil mengenai bagaimana pengukuran dilakukan, batasan layanan yang diberikan, dan bagaimana serta siapa yang menerima laporan mengenai gangguan yang mungkin terjadi serta bagaimanan solusi penanggulangannya. Masih menurut Edward Wustenhoss (2002),SLA yang baik sangat dibutuhkan untuk menentukan batasan dan ekspektasi dari aspek-aspek layanan yang diberikan pusat data: Komitmen pengguna. Janji yang didefinisikan dengan jelas memperkecil kemungkinan terjadinya kekecewaan dari pengguna. Janji tersebut juga menjaga fokus terhadap kebutuhan pengguna dan menjamin bahwa proses internal telah mengikuti arahan yang benar. Indikator kinerja utama (key performance indicator) bagi layanan pengguna. Adanya indikator yang jelas akan memudahkan dalam proses perbaikan kualitas (quality improvement process) seperti Six Sigma. Tentu saja hal tersebut bertujuan untuk meningkatkan kepuasan pengguna. Indikator kinerja utama bagi organisasi intemal. SLA mengarahkan proses intemal dengan menentukan kinerja standar yang jelas dan terukur. Akibatnya, objektif internal menjadi lebih jelas dan mudah diukur. Kunci sukses bagi layanan pusat data terletak pada bagaimana kinerjanya mampu memenuhi standar yang telah ditentukan. Kinerja dapat diartikan sebagai seberapa mampu memenuhi (atau bahkan melebihi) ekspektasi pengguna. SLA mendefinisikan hubungan yang jelas antara pengguna dan penyedia layanan dengan menentukan batasan, kondisi, penalti, dan ekspektasi yang jelas. Karena SLA menghubungkan kebutuhan pengguna dengan kebutuhan infrastruktur, ia juga menghubungkan antara tingkat layanan dengan biaya layanan dan sebagai hasilnya, penentuan harga yang menguntungkan dapat ditentukan. Lebih daripada itu, menghabiskan biaya berdasarkan kebutuhan yang jelas daripada berdasarkan intuisi belaka akan berkontribusi terhadap pengelolaan biaya yang efektif. 2.5. Audit
Analisis Gartner mengatakan bahwa tuntutan untuk mengelola perusahaan dengan baik sambil meminimalkan risiko terus mendorong peningkatan pemenuhan terhadap berbagai tata-aturan seperti Sarbanes-Oxley dan Base1 11. Diperkirakan bahwa di tahun 2006 akan semakin banyak perusahaan yang menaruh perhatian terhadap ha1 tersebut. Untuk meningkatkan tata-pamong perusahaan yang baik (good corporate governance) dan pada saat yang sama meningkatkan kapabilitas pengelolaan risiko (risk management), perusahaan-perusahaan semakin terdorong untuk menerapkan berbagai tata-aturan, baik yang terkait dengan aturan pengelolaan bisnis di suatu negara maupun aturan yang dituntut oleh industri secara global. Hal tersebut tak hanya terkait dengan tekanan persaingan namun juga perkembangan lingkungan bisnis dunia. Menurut Tharsikin Insa (2004), audit TI mencakup sedikitnya enam komponen yang sangat esensial yakni
1 Pendefinisian tujuan perusabaan. 2 Penentuan isu, tujuan, dan perspektif bisnis antara penanggung jawab bagian dengan bagian TI. 3 Evaluasi terhadap pengorganisasian bagian TI yang meliputi perencanaan proyek, status dan prioritasnya, staffing levels, belanja TI, dan manajemen perubahan TI. 4 Assessment inilastruktur teknologi. 5 Assessment aplikasi bisnis. 6 Temuan-temuan dan laporan rekomendasi. Sedangkan subjek yang perlu diaudit mencakup aspek keamanan, keandalan, kinerja, dan pengelolaan (manageability). Lebib jaub, Isnaeni Achdiat (2004) memaparkan bahwa salab satu kegiatan yang dilakukan pada fase pertama dari dua fase audit yang dilakukan oleh tim audit TI Ernst & Young (EY) adalah Review Desain Infrastruktur (setelah Review Manajemen Proyek dan Review Desain Proses dan Pengendalian Kontrol Ap!ikasi). Review ini mencakup analisis efektivitas dan efisiensi desain infrastruktur pendukung (server, workstation, sistem operasi, basis data, dan komunikasi data).
11.3. Rekayasa Sistem Menurut Roger S. Pressman (1997), rekayasa sistem (system engineering) merupakan serangkaian proses yang fokus terhadap analisis, perancangan, dan pengaturan semua elemen tersebut ke dalam suatu sistem. Hasil dari rekayasa sistem dapat berupa sebuah produk, jasa/layman, atau sebuah teknologi untuk mentransformasi sebuah informasi. Rekayasa sistem terdiri dari aktifitas pemecahan masalah berkaitan dengan data yang ada, fungsi komponen, dan tingkah laku sistem. Rekayasa sistem tidak hanya tertuju kepada perangkat lunak saja namun juga kepada beragam elemen yang ada untuk kemudian menganalisis, mendesain, dan mengatur elemen-elemen tersebut dalam suatu sistem yang dapat berupa produk, layanan, atau teknologi untuk mentransformasi informasi. Salah satu tujuan dari sistem berbasis komputer (computer-based system) adalah memberikan dukungan terhadap sejumlah fungsi bisnis atau mengembangkan produk yang dapat dijual untuk mendapatkan keuntungan bisnis. Dalam mencapai tujuan tersebut, sistem berbasis komputer didukung oleh beragam elemen sistem yang terdiri dari Perangkat lunak (software). Program komputer, struktur data, dan dokumentasi yang menjabarkan metode, prosedur, atau kontrol logis yang dibutuhkan. Perangkat keras (hardware). Peralatan elektronik yang menyediakan kemampuan komputasi. a Sumber daya manusia (peop!e). Pengguna atau operator perangkat lunak dan perangkat keras. a Basis data (database). Kumpulan informasi berukuran besar yang diakses melalui perangkat lunak. a Dokumentasi (documentation). Manual, borang, dan informasi deskriptif lainnya yang menggambarkan penggunaan/pengoperasian sistem. a Prosedur (procedure). Langkah-langkah yang menjabarkan penggunaan spesifik dari setiap elemen sistem atau konteks prosedural dimana sistem berada. Elemen-elemen tersebut dikombinasikan dengan cara beragam untuk mengubab informasi. Rekayasa sistem umumnya diawali dengan "world view", yakni
validasi domain bisnis atau produk secara keseluruhan untuk memastikan bahwa konteks bisnis atau teknologi yang tepat dapat dihasilkan. World view kemudian dipertajam untuk bisa lebih fokus terhadap apa yang akan menjadi pusat perhatian. Pada bagian yang menjadi pusat perhatian, apa yang menjadi kebutuhan dari elemen sistem kemudian ditangkap. Kemudian analisis, desain, dan konstruksi elemen sistem dilakukan. Rekayasa sistem merupakan proses pemodelan. Baik fokus terhadap world view ataupun detailed view, perekayasa harus mampu: Mendefinisikan proses yang dapat memenuhi kebutuhan berdasarkan view yang dipilih. Menggambarkan perilaku proses dan asumsi yang menjadi landasan bagi perilaku tersebut. Secara eksplisit mendefinisikan masukan ekstemal maupun internal dari model. Menggambarkan hubungan menyeluruh (termasuk keluaran) yang dapat membuat perekayasa dapat memahami view secara lebih baik. Dalam menyusun model sistem, perekayasa hams mempertimbangkan sejumlah faktor berikut Asumsi yang mengurangi kemungkinan jurnlah permutasi dan variasi, namun tetap dapat menggambarkan perrnasalahan dalam model yang masuk akal. e Penyederhanaan yang memungkinkan model dapat selesai secara hitungan waktu. r Ruang lingkup untuk membantu menentukan cakupan sistem. Batasan yang akan menjadi acuan dalam pembuatan model dan pendekatan yang akan diambil dalam pengimplementasian model. 8 Pilihan yang menggambarkan pilihan arsitektur untuk seluruh data, fungsi, dan teknologi. 3.1. Formal Tecl~nicalReview Menurut dimport (2003), Formal Technical Review merupakan suatu metode untuk mengidentifikasi kesalahdkegagalan (defect) pada suatu produk sebelum berlanjut pada tahap pengembangan berikutnya. FTR dapat dilakukan kapan saja dan dimana saja dalam daur hidup pengembangan produk sehingga identifikasi, dokumentasi, dan perbaikan terhadap kesalahanlkegagalan yang mungkin terjadi dapat dilakukan secara lebih cepat. Philip Johnson (1999) mengatakan bahwa FTR dapat didefinisikan sebagai suatu metode yang melibatkan sekelompok orang yang ahli secara teknis dengan mengikuti serangkaian proses yang telah didefinisikan dan didokumentasikan. Metode ini menghasilkan artifak terstruktur yang memperbaiki dan meningkatkan kualitas artifak bersangkutan. Ketika bekerja di IBM pada tahun 1970, Michael Fagan mencetuskan ide mengenai FTR untuk kualitas perangkat lunak yang kemudian dipublikasikan secara resmi pada tahun 1976. Saat ini mayoritas metode FTR bersumber kepada Fagan's Code Inspection. Selain metode Fagan's Code Inspection, terdapat juga metode Active Design Reviews, Phased Inspections, dan FTArm. Altematif yang sering digunakan dalam formal technical review adalah walkthrough dan code reading. Walkthrough merupakan pertemuan singkat antara pihak yang berkepentingan (misal: pengembang, pimpinan, pengguna) untuk mendiskusikan kualitas dan kecocokan produk sedangkan code reading melibatkan dua atau lebih pengembang yang membaca/menganalisis detil produk secara terpisah
kemudian bertemu dengan pihak yang berkepentingan untuk mendiskusikan temuantemuan. Pembagian peran pada Fagan's Code Inspection terdiri dari moderator, scribe, inspector, dan author sedangkan langkah-langkah yang dilakukan adalah overview, preparation, inspection, rework, dan follow-up. Langkah pertama adalah overview dimana tim penanggung jawab diserahi dokumen dan diberikan pengarahan mengenai gambaran proyek secara menyeluruh. Langkah berikutnya adalahpreparation dimana setiap anggota tim penanggung jawab secara terpisah membaca dan memahami dokumen yang te!ah diberikan kepada mereka. Tahap ini biasanya menggunakan semacam checklist untuk memperbesar kemungkinan ditemukannya kesalahan. Tahap inspection biasanya berupa pertemuan yang melibatkan tim penanggung jawab dan penulis untuk membahas temuan-temuan yang terjadi. Temuan yang berupa kesalahan kemudian diperbaiki oleh penulis pada tahap rework yang merupakan tahap selanjutnya. Tahap terakhir adalah memeriksa ulang kesalahan yang telah diperbaiki yang disebut tahapfollow-up.
11.4. Kerangka Kerjn Houghton Mifflin Company (2006) dalam The American Heritage@ Dictionary of the English Language, Fourth Edition mengartikan framework (kerangka kerja) sebagai "a set of assumptions, concepts, values, andpractices that constitutes a way of viewing reality". Kamus tersebut juga mengartikan framework sebagai "structure for supporting or enclosing something else, especially a skeletal support used as the basis for something being constructecP'. Princetown Uriversity (2003) dalam WordNet@ 2.0 mengartikan framework sebagai "a simplified description of a complex entity or process", "the underlying structure", serta "a structure supporting or containing something". Salah satu kerangka kerja yang menjadi acuan dalam bidang teknologi informasi adalah Information Technology Infrastructure Library (IT-IL). Menurut Wikipedia (2006), IT-IL merupakan suatu kerangka kerja berisi pendekatan mumpuni (best practice) yang bertujuan untuk memberikan layanan teknologi informasi berkualitas tinggi. IT-IL menggambarkan rangkaian prosedur manajemen yang mendukung kegiatan bisnis dalam pencapaian kualitas dan nilai uang (value for money) dari kegiatan operasional teknologi informasi. Rangkaian prosedur tersebut tidak bergantung kepada siapa yang menjadi pemasok dan teldl dikembangkan untuk memberikan acuan bagi infrastruktur, pengembangan, dan operasional teknologi informasi. Dalam hidang industri, Astra Management System (Ahis) merupakan kerangka kerja yang menjadi acuan dalam kegiatan bisnis PT Astra International, Tbk. dan anak-anak perusahaannya. AMS adalah sistem manajemen yang mengikutsertakan seluruh karyawan dari semua tingkatan organisasi baik vertikal maupun horizontal dengan penerapan metode statistik untuk mengelola dan meningkatkan kualitas proses bisnis demi tercapainya kepuasan pelanggan dan daya saing. Sistem yang dibangun perlu memiliki karakteristik berikut agar dapat diterima semua pihak: generik dan terbuka. Generik berarti AMS bisa digunakan untuk semua jenis industrilinstitusi sedangkan terbuka berarti AMS adalah open system yang terbuka terhadap penambahan tools atau konsep baru yang tidak bertentangan dengan prinsip dasar perusaham.
11.5. Flowchart Menurut Rijanto Tosin (1994),flowcharf merupakan gambar atau bagan yang memperlihatkan urutan dan hubungan antar proses beserta instruksinya dimana gambaran ini dinyatakan dengan simbol. Dengan demikian setiap simbol menggambarkan proses tertentu sedangkan hubungan antar proses digambarkan dengan garis penghubung. Rijanto Tosin (1994) memaparkan bahwa terdapat dua macamflowchart yang menggambarkan proses dengan sistem/komputer yaitu Systemflowchart, adalah bagan yang memperlihatkan urutan prosedur dan proses dari beberapafile di dalam media tertentu. Melalui flowchart ini, dapat terlihat jenis media penyimpanan yang dipakai dalam pengolahan data. Selain itu, flowchart ini juga menggambarkan file yang dipakai sebagai nlasukan maupun keluaran. Systemflowchart menggambarkan: Hubungan antara suatuJile denganjle lainnya. Media yang dipakai untuk setiapjle. Jadi system flowchart dapat memberikan gambaran urnum mengenai suatu sistem pengolahan data. Program flowchart, adalah bagan yang memperlihatkan umtan dan hubungan proses dalam suatu program. Flowchart ini merupakan langkah awal pembuatan program. Dengan adanya program flowchart, urutan proses di program menjadi lebih jelas. Jika ada penambahan proses, maka dapat dilakukan dengan mudah. Programflowchart memberikan gambaran secara rinci tentang urutan instruksi yang disusun oleh pemrogram untuk diterapkan ke komputer. Flowchart tersusun atas simbol-simbol yang digunakan sebagai alat bantu untuk menggambarkan proses di dalam sistem. Simbol-simbol yang digunakan terbagi menjadi tiga kelompok yaitu Flow direction symbols, merupakan kumpulan simbol yang digunakan untuk menghubungkan antara simbol yang satu dengan simbol lainnya. Kumpulan simbol ini disebut juga connecting line. Processing symbols, merupakan kumpulan simbol yang menunjukkan jenis operasi pengolahan dalam suatu prosedur. Simbol yang sering digunakan pada kelompok ini adalah
Gambar 4. Simbolprocess (sumber: Rijanto Tosin, 1994).
o Simbol process, adalah simbol yang menunjukkan pengolahan yang dilakukan sistem.
Gatnbar 5. Simbol decision (sumber: Rijanto Tosin, 1994).
o Simbol decision, adalah simbol untuk kondisi yang .&an menghasilkan beberapa kemungkinan jawabanlaksi.
L) Gambar 6. Simbol tcrnrirral (sumber: Rijanto Tosin, 1994).
a
o Simbol terminal, adalah simbol penanda permulaan atau akhir dari suatuflowchart. Input-output sy~nbols,merupakan kumpulan simbol yang digunakan untuk menyatakan jenis peralatan yang menjadi media masukan atau keluaran. Simbol yang sering digunakan pada kelompok ini adalah
Gambar 7. Simbol doc~rmerrt(sumber: Rijanto Tosin, 1994).
o Simbol document, adalah simbol untuk merepresentasikan masukanfkeluaranberupa dokumen dalam bentuk kertas.
II. 6. Digital Dashboard Merupakan ha1 yang lumrah saat ini untuk menemukan perusahaan menengahbesar memiliki beragam perangkat jaringan, server, media penyimpanan, dan perangkat TI lainnya yang terpasang dengan beragam kompleksitas dan bersinergis dalam mengeksekusi aplikasi-aplikasi kritis milik perusahaan. Pertanyaan yang sering diajukan adalah bagaimana kinerja sistem tersebut serta bagaimana caranya mengetahui dan menangani permasalahan yang timbul dengan cepat dan mudah.
Gambar 8. Contoh tampilan produk dasl~board.
Kebanyakan dari perangkat yang telah disebutkan di atas memiliki mekanisme untuk melaporkan diri mereka secara statistik menggunakan protokol semacam Simple Network Management Protocol (SNMP), Remote Monitoring W O N ) , atau protokol khusus lainnya. Tentu saja terdapat perkakas yang dapat menangkap dan menampilkan data statistik tersebut dalam tampilan yang mudah untuk dianalisis. Hal inilah yang paling penting dari sebuali dashboard TI. Salah satu contoh produk yang dimaksud dapat dilihat pada Gambar 4. Dashboard memungkinkan para pengambil keputusan menemukan hotspot di pusat data dan melakukan investigasi lebih mendalam untuk menemukan sumber masalahnya. Dashboard bekeja layaknya lampu lalu lintas yang memperlihatkan warna hijau untuk kondisi bagus, warna kuning untuk kondisi yang perlu mendapat perhatian walau masih dalam batas kewajaran, serta warna merah untuk kondisi yang perlu mendapat perhatian dan tindakan lebih lanjut. Di sisi lain, adakalanya informasi yang ditampilkan melalui dashboard terlalu rinci sehigga sulit bagi para pengambil keputusan menahan godaan untuk mencermati setiap transaksi yang tejadi sehingga fokus pekerjaannya malah menjadi terganggu. Dengan perkakas yang tepat, mengelola perangkat yang kompleks, melibatkan banyak lapisan, dan berasal dari beragam vendor menjadi lebih mudah. Penggunaan kode warna yang seragam dan tampilan yang tertata dengan baik memungkinkan administrator TI untuk menemukan potensi permasalahan secara cepat, sebisa mungkin sebelum permasalahan tersebut diietahui oleh pengguna. Memantau data statistik penting dalam bentuk grafis memungkinkan mereka untuk mengelola kinerja dan ekspektasi pengguna secara proaktif. Mark A. Stephens et al. (2004) mengatakan bahwa digital dashboard menyediakan visualisasi terhadap indikator kinerja utama melalui tanlpilan grafis
sederhana seperti grafik dan tabel melalui sebuah penjelajah jejaring (Web browser). Digital dashboard menarik karena Menampilkan beragam pengukuran dalam satu tampilan terkonsolidasi. Mengelompokkan detil menjadi kesimpulan secara m u m . Menyediakan indikator yang mudah dipahami, misalnya garis merah berarti terdapat masalah sedangkan garis hijau berarti segala sesuatu berjalan sesuai dengan yang telah direncanakan. Menampilkan informasi secara berjenjang yang mencakup pemsahaan secara keseluruhan. Sederhananya, digital dashboard dapat dianalogikan dengan dashboard pada kendaraan. Perkakas tersebut memberikan tampilan sekilas mengenai kondisi operasional terkini kendaraan. Digital dashboard harus mampu menyeleksi informasi dan menyampaikannya kepada pembuat keputusan yang tepat melalui tampilan informatif untuk digunakan dalam pengambilan keputusan strategis. Dengan pemikiran seperti itu, digital dashboard: w BUKAN tampilan statis dari informasi terbatas yang tidak berhubungan dengan proses pengambilan keputusan. BUKAN informasi terpisah yang ditampilkan secara bersamaan. BUKAN tampilan dari serangkaian angka tanpa ringkasan informasi. BUKAN tampilan grafik dan tabel sederhana tanpa logika bisnis. Tampilan yang ada didesain untuk menampilkan data secara nyata (realtime) dan dapat disimpan secara sistematis untuk analisis lebih lanjut, misal pada akhir bulan untuk laporan kumulatif atau bahkan untuk keperluan analisis tren yang terjadi. Tampilan dapat dilakukan secara hirarki yang dilengkapi dengan fasilitas pendetilan (drill-down) sehingga fokus terhadap fungsi bisnis utama, wilayah, atau layanan dapat dilakukan. Selebihnya bergantung kepada administrator TI dalam melakukan konfigurasi terhadap perangkat yang ada untuk menghasilkan data statistik yang diperlukan dan kemampuan perkakas tersebut untuk mengolahnya. Terdapat beragam pilihan perkakas yang tersedia dengan bermacam kapabilitas dan kecanggihan fitur. Langkah yang perlu diambil pemsahaan adalah mendefinisikan indikator kinerja, mencatat seluruh sistem yang terlibat, mengeset kebutuhan sistem tersebut dengan benar, dan berdasarkan parameter yang ada memilih sistem yang cocok untuk digunakan sebagai dashboard kinerja mereka.
11.7. Rekayasa Perangkat Lunak Roger S. Pressman (1997) memaparkan bahwa menurut IEEE, rekayasa perangkat lunak (sofiare engineering) mempakan pengaplikasian dari pendekatan sistematis, disiplin, serta kuantitatif dalam pengembangan, pengoperasian, dan pemeliharaan perangkat lunak. Rekayasa perangkat lunak mempakan teknologi yang berlapis. Pendekatan rekayasa perangkat lunak haruslah didasari komitmen menveiuruh terhadav kualitas karena diyakini inti dari rekayasa adalah fokus terhadap kualitas yang memingkinkan terjadinia perbaikan proses secara tems-menems serta mengarah kepada kematangan proses rekayasa perangkat lunak itu sendiri.
Gambar 9. Lapisan rekayasa perangkat lunak (sumber: Roger S. Pressman, 1997).
Landasan dari rekayasa perangkat lunak adalah lapisan proses (process). Proses menggambarkan suatu kerangka kerja yang terdiri dari proses kunci (key process area) yang harus dilakukan untuk menghasilkan teknologi rekayasa perangkat lunak yang efektif. Proses kunci menjadi dasar dalam pengontrolan proyek perangkat lunak karena menghasilkan konteks yang tepat untuk menentukan bagailnana metode teknis yang harus diaplikasikan, hasil kerja (seperti model, dokumen, data, laporan, dan borang) yang harus dihasilkan, target yang harus dicapai, kualitas yang harus dijaga, dan manajemen perubahan yang harus dikelola dengan baik. Metode (methods) rekayasa perangkat lunak menyediakan "technical howto's" untuk membangun perangkat lunak. Metode yang dimaksud mencakup analisis kebutuhan, desain, konstruksi program, pengujian, dan pemeliharaan. Perkakas (tools) rekayasa perangkat lunak menyediakan dukungan otomatis atau semiotomatis bagi proses dan metode. Computer-Aided Sofhvare Engineering (CASE) mengkombinasikan perangkat lunak, perangkat keras, dan basis data rekayasa perangkat lunal-yang merupakan kumpulan inforrnasi penting mengenai analisis, desain, konstruksi program, dan pengujian-untuk membentuk lingkungan rekayasa perangkat lunak yang kondusif, mirip dengan Computer-Aided Design/Engineering (CADICAE) pada perangkat keras. Langkah-langkah yang dilakukan dalam rekayasa perangkat lunak secara m u m dapat dikategorikan ke dalam tiga fase tanpa memandang area aplikasi, ukuran proyek, atau kompleksitas. Fase pendefinisian (definition phase) memfokuskan kepada 'apa' (what). Pada fase ini, pengembang perangkat lunak mengidentifikasi informasi apa yang akan diproses, fungsi atau perforrnansi aps yang diharapkan, perilaku sistem apa yang diinginkan, antarmuka apa yang akan dikembangkan, serta batasan desain apa yang ada. Hal tersebut mencakup pula rekayasa sistem atau informasi, perencanaan proyek perangkat lunak, serta analisis kebutuhan. Fase pengembangan (development phase) memfokuskan kepada 'bagaimana' (how). Pada fase ini, pengembang perangkat lunak mengidentifikasi bagaimana stuktur data, bagaimana fungsi-fungsi diimplementasikan sebagai arsitektur perangkat lunak, bagaimana detil subrutin diimplementasikan, bagaimana antarmuka dirancang, bagaimana desain diterjemahkan ke dalam bahasa pernrograman, dan bagaimana pengujian akan dilakukan. Hal tersebut mencakup pula desain perangkat lunak, pembuatan kode program, serta pengujian perangkat lunak. Fase pemeliharaan (maintenailce phase) memfokuskan kepada 'perubahan' (change) ya& berhubungan dengan perbaikan kesalahan, adaptasi yang dibutuhkan ketika lingkungan perangkat lunak berubah, dan perubahan yang diakibatkan oleh berubahnya perrnintaanlkebutuhan pelanggan.
7.1. Model Linear Sequeiztial Menurut Roger S. Pressman (1997), model proses (process model) atau paradigma rekayasa perangkat lunak (sofmare engineeringparadigm) adalah strategi pengembangan yang dipilih untuk mengakomodasi tiga lapisan (proses, metode, dan perkakas) serta tiga fase (pendefinisian, pengembangan, dan pemeliharaan) dimana penentuan strategi ini sangat bergantung kepada lingkungan proyek dan aplikasi, metode dan perkakas yang akan digunakan, serta hasil dan target yang ingin dicapai. Beberapa literatur menyatakan bahwa model proses sering disebut juga sebagai model Sofmare Development Life Cycle (SDLC) . Model linear sequential sering juga disebut sebagai model classic life cycle atau waterfall. Model ini menggambarkan pendekatan sistematis dan sekuensial
dalam pengembangan perangkat lunak yang diawali dari level sistem dan berlanjut kepada analisis, desain, implementasi, pengujian, dan pemeliharaan.
Gambar 10. Model linear sequerrlial (sumber: Roger S. Pressman, 1997).
Model linear sequential terdiri dari serangkaian aktifitas sebagai berikut Rekayasa sistedinformasi dan pemodelan (system/information engineering and modeling). Karena perangkat lunak merupakan bagian dari sistem yang lebih besar, pekerjaan dimulai dengan mengidentifikasi kebutuhan untuk semua elemen sistem dan kemudian mengalokasikan sebagian kebutuhan tersebut ke dalam perangkat lunak. Rekayasa sistem dan analisis mencakup pendataan kebutuhan di tingkat sistem dengan sedikit analisis dan desain di tingkat atas. Rekayasa inforrnasi mencakup pendataan kebutuhan di tingkat strategi dan area bisnis. Analisis kebutuhan perangkat lunak (sofMare requirements analysis). Proses pendataan kebutuhan diintensifkan dan difokuskan pada perangkat lunak. Untuk memahami lingkungan tempat program akan dibuat, pengembang harus memahami domain informasi untuk perangkat lunak (termas.uk juga fungsi, perilaku, dan antarmuka yang dibutuhkan). Desain (design). Desain perangkat lunak sesungguhnya merupakan proses dari sejumlah langkah yang memfokuskan kepada empat atribut berbeda dari sebuah program: struktur data, arsitektur perangkat lunak, representasi antarmuka, dan detil algoritma. Proses desain menerjemahkan kebutuhan ke dalam representasi dari perangkat lunak yang dapat diperiksa kualitasnya sebelum pembuatan kode program dimulai. * Pengkodean (code generation). Desain harus diterjemahkan dalam bentuk bahasa mesin. Langkah pembuatan kode melakukan hal tersebut. Pengujian (testing). Proses pengujian memfokuskan kepada logika internal dari perangkat lunak, yakni menjamin bahwa seluruh bagian telah diuji dan ekstemal fungsional, yakni melakukan pengujian untuk mencari kesalahan dan menjamin bahwa data masukan akan mengeluarkan hasil yang sesuai dengan hasil yang diinginkan. Pemeliharaan (maintenance) Selain model linear sequeantial, diienal pula model proses lain seperti model protoyping, Rapid ~ ~ ~ l i c a Development tioi ( G D ) , incremental, spiral,~component assembly, concurent development, danfor~nalmethod. Pengujian
Dalarn bukunya, Roger S. Pressman (1997) mengemukakan beberapa objektif dari pengujian perangkat lunak: Pengujian merupakan suatu proses yang mengeksekusi program dengan tujuan untuk menemukan kesalahan. Kasus pengujian yang baik adalah kasus pengujian yang memiliki probabilitas tinggi menemukan kesalahan yang belum terprediksi sebelumnya.
-
Pengujian yang berhasil adalah pengujian yang berhasil menemukan kesalahan yang belum terprediksi sebelumnya. Prinsip pengujian menurut Roger S. Pressman (1997): Seluruh pengujian harus dapat ditelusuri kembali terhadap kebutuhan pengguna. Pengujian harus direncanakan jauh sebelum pengujian dilakukan. Prinsip Pareto berlaku pada pengujian perangkat lunak. Pengujian harus diawali dengan "sesuatu yang sederhana" dan bergerak menuju "sesuatu yang kompleks". Mustahil melakukan pengujian tanpa akhir. Yang dapat dilakukan adalah menangkaplmenganalisis seluruh logika pemrograman dan memastikan bahwa seluruh kondisi yang didapat dari fase desain telah terakomodir dengan baik. 7.2. Un~jiedModeling Language Sri Dhanviyanti (2003) menjelaskan bahwa kesuksesan suatu pemodelan perangkat lunak ditentukan oleh tiga unsur yang kemudian terkenal dengan sebutan segitiga sukses (the triangle of success). ICetiga unsur tersebut adalah metode pemodelan (notation method), proses @recess), dan perkakas yang digunakan (tool). Memahami notasi pemodelan tanpa mengetahui cara pemakaian yang sebenarnya (proses) akan membuat proyek pengembangan perangkat lunak menjadi gagal. Sesudah itu, pemahaman terhadap metode pemodeian dan proses disempurnakan dengan penggunaan perkakas yang tepat.
Gambar 11. Segitiga pemodelan perangkat lunak (sumber: Sri Dharwiyanti, 2003).
Unified Modeling Language (UML) merupakan sebuah bahasa yang telah menjadi standar dalam industri untuk visualisasi, merancang, dan mendokumentasikan sistem perangkat lunak. Seperti bahasa-bahasa lainnya, UML mendefinisikan notasi dan sintakslsemantik. Notasi UML merupakan sekumpulan bentuk khusus yang menggambarkan berbagai macam diagram perangkat lunak. Setiap bentuk memiliki makna tertentu dan sintaks UML mendefinisikan bagaimana bentuk-bentuk tersebut dapat dikombinasikan. Notasi UML diturunkan dari tiga notasi yang telah ada sebelumnya yakni notasi Object-Oriented Design (OOD) dari Grady Booch, Object Modeling Technique (OMT) dari Jim Rumbaugh, dan Object-Oriented Software Engineering (OOSE) dari Ivar Jacobson. Menurut A. Suhendar et al. (2002), sejarah UML sendiri cukup panjang. Sampai dengan era 1990, puluhan metodologi pemodelan berorientasi objek telah bermunculan di dunia diantaranya Object Modeling Technique (OMT) dari Jim Rumbaugh, Object-Oriented Analysis/Design (OOAD) ciari Shlaer-Mellor, ObjectOriented Design (00D) dari Grady Booch, Responsibility-Driven-DesigrJClassResponsibility-Collaboration (RDDICRC) dari Wirfs-Brock, CoadIYourdon, dan Object-Oriented Software Engineering (OOSE) dari Ivar Jacobson. Masa itu lebih dikenal sebagai masa perang metodologi (method war) dalam desain berorientasi
objek. Masing-masing metodologi membawa notasi sendiri yang mengakibatkan ti~nbulnlasalah baru apabila seseorang bekerjasama dengan gruplperusahaan lain yang menggunakan metodologi yang berlainan. OMT dari Jim Rumbaugh terbagi dalam tahapan utama yang terdiri dari analisis, desain sistem dan objek, serta implementasi. Keunggulan metodologi ini terletak pada notasinya yang mendukung semua konsep berorientasi objek yang menitikberatkan pada analisis terstruktur dan pemodelan entiq-relationship. OOAD dari Shlaer-Mellor merupakan teknik pemodelan informasi tradisional menggunakan state diagram yang memodelkan keadaan (state) dari entitas dan data-$ow diagram yang memodelkan alur data dalam sistem. Metodologi ini menghasiikan tiga jenis model yaitu information model, state model, dan process model. Keunggulan metodologi ini terletak pada cara memandang permasalahan dari sudut yang berbeda serta mudah dibuat (dikonversi) dari metodologi stmkthual. OOD dari Grady Booch mengklasifikasi proses analisis dan desain ke dalam empat tahapan yang iteratif (dapat bemlang) yaitu identifikasi kelas dan objek, identifikasi semantik dan hubungan objek dengan kelas tersebut, perincian antarmuka, dan implementasi. Metodologi Booch sangat detil dan kaya dengan notasi elemen yang merupakan gabungan dari metodologi lain. RDDICRC dari Wirfs-Brock menekankan pada desain, tetapi sangat berguna dalam memunculkan ide pada tahap analisis. Keunggulan metodologi ini adalah mudah untuk digunakan. Metodologi ini juga mengidentifikasi hirarki kelas dan subsistem. Metodologi Coad/Yourdon berdasar pada pemodelan berorientasi objek dan entity-relationship. Metodologi ini menyelesaikan masalah dalam lima tahapan dimana setiap tahapan terdiri dari aktivitas-aktivitas yang berbeda. Tahapan tersebut adalah tahapan pendefinisian kelas, objek, struktur, subjek, dan layanan. Keunggulan metodologi ini terletak pada kesederhanaan, cara pendekatan secara intuisi, serta mudah untuk dimengerti dan digunakan. Namun metodologi ini tidak banyak digunakan dan mengantung fitur non-berorientasi objek. OOSE dari Jacobson mengandung elemen dari metodologi-metodologi berorientasi objek lainnya. Metodologi ini menekankan pada use-case. OOSE terdiri dari tiga tahapan yaitu membuat model kebutuhan dan analisis, desain dan implementasi, serta pengujian. Keunggulannya adalah mudah untuk dipelajari karena memiliki notasi yang sederhana dan mencakup seluruh tahapan dalam rekayasa perangkat lunak. Pada Oktober 1994, Booch, Rumbaugh, dan Jacobson (merupakan tiga tokoh yang metodologinya banyak digunakan) memelopori usaha untuk penyatuan metodologi pendesainan berorientasi objek. Pada tahun 1995 dirilis dvaj? pertama dari UML (versi 0.8). Sejak tahun 1996 pengembangan tersebut dikoordinasikan oleh Object Management Group. Pada tahun 1997 dirilis UML versi 1.1, dan saat ini versi terbaru adalah versi 1.5 yang dirilis pada bulan Maret 2003. Booch, Rumbaugh, dan Jacobson menyusun tiga buku serial tentang UML pada tahun 1999. Sejak saat itulah UML telah menjelma menjadi standar bahasa pemodelan untuk aplikasi berorientasi objek. Dikaitkan dengan SDLC model linear sequential, terdapat beberapa notasi diagram UML yang dapat digunakan dalam setiap fase: Tabel 1 Keterkaitan U M L dengan SDLC ,*,.,
,.,,.,> , .<*
,
."
':.(?'.
a,
:;:-.. .'.V,>W,.r( t,:*yz.-,lili22
:\',;*\*~~~~:;.V*:
**-Ar.
sva*am
Requirements
Use-case model
.. ..
s*i*sTq qaz~ri~hmt,.%32*2~ .$&"
g:;{$&g!+k $&$b~~&b~odel~~~a&~g~$j: ~$~~,~~~r~j&g2~~g&]#~
,eh~g"d%-,:
Use-case diagram Sequence diagram
,
&f;
Analysis
Analysis model
Design
-
Design model Deployment model
Implementation
Implementation model
Test
Test model
Statechart diagram Activity diagram Class & object diagram Sequence diagram Collaboration diagram Statechart diagram Activity diagram Class & object diagram Sequence diagram Collaboration diagram Statechart diagram Activity diagram Deployment diagram Sequence diagram Component diagram Sequence diagram Collaboration diagram Deployment diagram
UML tidak mencakup: Bahasa pemrograman. UML mempakan bahasa pemodelan visual dan bukan bahasa pemrograman visual, namun UML memberikan arahan ke kode program. Perkakas pemodelan. UML hanya mendefinisikan semantik dan notasi. Untuk alat bantu pemodelan dapat menggunakan perkakas yang memang tersedia untuk itu seperti Rational Rose dan Enterprise Architect. Model SDLC. UML tidak terikat pada suatu model SDLC tertentu dan ha1 ini bukan merupakan tujuan UML dari OMG. Rational Software selaku pengembang perangkat lunak Rational Rose mengeluarkan SDLC bemarna Rational Unified Process (RUP). Sri Dhanviyanti (2003) memberikan tips pengembangan perangkat lunak menggunakan UML sebagai berikut 1 Buatlah daftar proses bisnis (business process) dari level tertinggi untuk mendefinisikan aktivitas dan proses yang mungkin muncul. 2 Petakan use-case untuk setiap proses bisnis untuk mendefinisikan dengan tepat fungsionalitas yang harus disediakan oleh sistem. Kemudian perhalus use-case diagram dan lengkapi dengan kebutuhan, batasan, dan catatancatatan lainnya. 3 Buatlah deployment diagram secara kasar untuk mendefinisikan arsitektur fisik sistem. 4 Definisikan kebutuhan lain (non-fungsional, keamanan, dan sebagainya) yang juga harus disediakan oleh sistem. 5 Berdasarkan use-case diagram, mulailah membuat activity diagram. 6 Definisikan objek-objek level atas backage atau domain) dan buatlah sequence dantatau collaboration diagram untuk tiap alur pekerjaan. Apabila sebuah use-case memiliki kemungkinan alur normal dan kesalahanlkegagalan, buatlah satu diagram untuk masing-masing alur. 7 Buatlah rancangan model antarmuka pengguna yang menyediakan antarmuka bagi pengguna untuk menjalankm skenario use-case.
8
9 10 11 12 13 14 15
Berdasarkan model-model yang sudah ada, buatlah class diagram. Setiap package atau domain dipecah menjadi hirarki class lengkap dengan atribut dan metodenya. Akan lebih baik jika untuk setiap class dibuat unit pengujian yang berfungsi untuk rnenguji fungsionalitas class dan interaksi dengan class lain. Setelah class diagram dibuat, dapat dilihat kemungkinan pengelompokan class menjadi komponen-komponen. Karena itu buatlah component diagram pada tahap ini. Perhalus deployment diagram yang sudah dibuat. Detilkan kernampuan dan kebutuhan perangkat lunak, sistem operasi, jaringan, dan sebagainya. Petakan komponen ke dalam node. Mulailah membangun sistem. Ada dua pendekatan yang dapat digunakan: Pendekatan use-case, yaitu menugaskan setiap use-case kepada tim pengembang tertentu untuk mengembangkan unit dan tesnya. Pendekatan komponen, yaitu menugaskan setiap komponen kepada tim pengembang tertentu. Lakukan uji modul dan uji integrasi serta perbaiki model berserta kode programnya. Model harus selalu sesuai dengan kode program yang aktual. Perangkat lunak siap dirilis.
11.8. Plan-Do-Check-Action (PDCA) Menurut Wikipedia (2006), Plan-Do-Check-Action (sering diienal juga dengan istilah Deming Cycle, Shewhart Cycle, atau Deming Wheel) merupakan suatu strategi kendali mutu empat langkah yang bersifat iteratif. Konsep PDCA dipopulerkan oleh W. Edwards Deming pada tahun 1950-an. Waktu itu Deming ditugaskan untuk membantu memulihkan perekonomian Jepang selepas Perang Dunia Kedua. PDCA digunakan dalam proses perbaikan berkelanjutan (continuous improvement) untuk membantu industri Jepaang agar bisa bersaing dengan pasar dunia di masa depan. Masih menurut Wikipedia (2006), PDCA membuat peluang untuk tejadinya lompatan (breakthrozlgh) yang menjadi ciri khas pendekatan Barat dan juga Kaizen yang menjadi ciri !&as pendekatan Timur melalui perbaikan berkelanjutan. Menurut Transforma (2003), pengelolaan siklus bisnis secara menyeluruh mengandung arti memutar penuh siklus PDCA yang tertutup sempurna pada seluruh lapisan hirarki korporasi, mulai dari Chief Executive OfJicer (CEO) sampai pada setiap karyawan, untuk mencapai pertumbuhan berkelanjutan dan menghasilkan keuntungan. Plan
Tahap perencanaan @!an) bertujuan untuk mendefinisikan tujuan (goal), rencana tindakan (action program), dan garis acuan (guideline). Lebih spesifik, tahap ini bertujuan untuk Mengenali dan memahami postur terkini binis dan organisasi korporasi. Mendefinisikan postur yang diharapkan terjadi di masa depan. Memformulasi kebijakan: o Kebijakan korporasi o Kebijakan perusahaan o Kebijakan departemenlfungsi e Menyusun aktifitas kerja (activityplan). Menentukan control-point dari setiap aktifitas.
Do
Tahap pelaksanaan (do) bertujuan untuk mengeksekusi seluruh rencana aktifitas yang telah disepakati pada tahap perencanaan. Tahap pengecekan (check) bertujuan untuk memantau, mengecek, dan mengevaluasi pencapaian sampai pada titik tertentu. Lebih spesifik, tahap ini bertujuan untuk Terus-menerus memantau d m mengevaluasi pencapaian hasil dari setiap aktifitas yang telah dilakukan. Mengidentifikasi permasalahan dan implikasi yang ditimbulkan sejak dini.
Action Tahap tindak lanjut (action) bertujuan untuk mengidentifikasi permasalahan dan bagaimana tindak lanjutnya (problem identijkation and counter action). Lebih spesifik, tahap ini bertujuan untuk Memperbaiki proses inti. Meningkatkan kemampuan organisasi. Mendefinisikan ulang posisUrencana bisnis. Menghasilkan tanggapan strategis yang sesuai dengan perkembangan yang terjadi. Tindak lanjut yang diambil terhadap permasalahan yang terjadi dapat bempa Retooling, yakni mengkaji ulang aktifitas yang telah dilakukan dan menganalisis apakah ada yang perlu diperbaikilditingkatkanterhadap cara eksekusi atau sumber daya yang ada untuk bisa mencapai target yang diinginkan. Revitalization, yakni mengkaji dan memformulasi ulang strategi yang telah ditetapkan pada tahap perencanaan. e Redirection, yakni mengkaji d m memformulasi ulang penentuan arah yang telah ditetapkan pada tahap perencanaan.
BAB 111. METODOLOGI PENELITIAN 111.1. Kerangka Pemikiran
Gambar 12. Kerangka pemikiran penelitian.
111.2. Tata Laksana Penelitian ini dilakukan dalam beberapa tahapan yaitu 1 Memformulasi permasalahan dimana permasalahan yang ada diidentifikasi dan dirumuskan berdasarkan aspek strategis dan aspek operasional pusat data. 2 Menyusun hipotesa sebagai kesimpulan awal dan strategi untuk menguji apakah hipotesa tersebut merupakan jawaban atas permasalahan yang ada. 3 Studi literatur mengenai hal-ha1 yang berhubungan dengan pusat data dan digital dashboard yang akan dikembangkan. Secara garis besar, studi literatur ini mencakup materi mengenai pusat data, rekayasa sistem, digital dashboard, dan rekayasa perangkat lunak. 4 Untuk Kerangka Kerja Daur Hidup Pusat Data: 1 Memetakan dan mendokumentasikan langkah-langkah pembuatan dan pengoperasian pusat data secara bertahap. Tahapan ini diawali dengan pembuatan helicopter view yang diberi nama sebagai Kerangka Kerja Level 0 untuk mendapat gambaran keseluruhan dari proses pembuatan dan pengoperasian pusat data. 2 Setelah mendapat kesepakatan atas Kerangka Kerja Level 0, tahapan pengerjaan dilanjutitan dengan Kerangka Kerja Level 1, Level 2, dan Level 3. Setiap level merupakan pendetilan (drilldown) dari level sebelumnya. Proses dan dokumen masukankeluaran yang terlibat pada Kerangka Kerja Level 2 dan Kerar,gka Kerja Level 3 lalu diuepresentasikan dalam notasi flowchart'. Proses validasi dari setiap level melibatkan saran dan pendapat sejumlah pakar dan praktisi yang telah banyak berkecimpung dalam pembuatan dan pengoperasian pusat data. 3 Merekapitulasi dan menampilkan detil daur hidup dari seluruh dokurnen masukankeluaran ke dalam sebuah dokumen khusus yang diberi nama Alur Kerja Dokumen Pusat Data (Data Center Document Workj7ow). 4 Melakukan uji materi dari kerangka kerja yang dihasilkan melalui mekanisme audit terhadap kenyataan yang terjadi di Adira menggunakan metode Formal Technical Review (FTR). Hasil audit ini dapat berdampak terhadap terjadinya perbaikan kerangka kerja yang telah dirancang maupun perbaikan cara kerja dalam pembuatan atau pengoperasionalan pusat data Adira. 5 Untuk Dashboard Manajerial Pusat Data: 1 Menentukan kriteria standar kinerja pusat data dan nilai ambang batas dari setiap kriteria yang ada dimana proses validasi dari setiap kriteria melibatkan saran dan pendapat sejumlah pakar dan praktisi yang telah banyak berkecimpung dalam pembuatan dan pengoperasian pusat data. 2 Menangkap kebutuhan perangkat lunak yang dilakukan dengan mempelajari cara kerja dan perilaku digital dashboard yang sudah
' Flowchart dipilih karena: Mampu memberikan gambaran besar maupun detil dari keseluruhan proses yang terjadi dan dokumen masukanlkeluaran yang terlibat. Notasiflowchart menggunakan logika umum (cornr11onsense) dan mudah dalam pembacaannya.
3
4
5
6
ada untuk mendapatkan gambaran besar dari digital dashboard yang akan dikembangkan. Merancang analisis dan desain perangkat lunak yang mencakup rancang bangun perangkat lunak seperti stmktur data, arsitektur, representasi antannuka, dan detil algoritma yang akan mentransformasikan komponen-komponen dalam arsitektur perangkat lunak ke dalam modul perangkat lunak. Model Software Development Life Cycle (SDLC) yang digunakan dalam pengembangan aplikasi ini adalah linear sequential/waterfal12 dengan menggunakan notasi Un$ed Modeling Language (uML)~. Pengkodean hasil desain perangkat lunak menggunakan bahasa pemrograman komputer yang sesuai dengan memanfaatkan rutinrutin pemrograman yang tersedia. Bahasa pemrograman yang dimaksud adalah P H P ~dengan ~ i c r o s o f SQL t ~ ~ server6 sebagai DBMS-nya. Perangkat lunak memanfaatkan hasil statistik dari protokol SNMP dan diujicoba menggunakan data yang dihasilkan oleh aolikasi Orion ~olarwinds'. ~ e n & j ihasil pengkodean untuk menentukan apakah perangkat lunak yang . - dikembangkan sudah memenuhi kriteria digital dashboard yang baik din benat menggunakan metode pengujian blackbox dan whitebox. Dokumentasi untuk langkah 2 sampai dengan 5 mengikuti standar dokumentasi dalam rekayasa perangkat lunak yaitu dokumen Spesifikasi Kebutuhan Perangkat Lunak (SKPL), Deskripsi Perancangan Perangkat Lunak (DPPL), Perencanaan Uji Perangkat Lunak (PUPL), dan Hasil Uji Perangkat Lunak (HUPL). Menginstalasi dan memantau kinerja digital dashboard yang telah dikembangkan.
111.3. Waktu dan Tempat Penelitian Tabel 2 Jadwal kegiatan penelitian
Linear sequential1waterfaN dipilih karena perangkat lunak yang dikembangkan tidak memerlukan emodelan@rotofyping) dan dapat diselesaikan dalam proses iterasi yang sedikit. 'Notasi UML dipilih dalam analisis dan desain karena implementasi perangkat lunak menggunakan endekatan berorientasi objek yang moduler dan untuk memudahkan dalam tahapan berikutnya. 'Selain karena oeranekat lunak . y a w- dikembangkan berbasis jejaring, PHP dipilih karena bahasa pemrograman ini memiliki fitur library untuk koneksi basis data danprotokol pemantauan jaringan. Microsoft adalah merk terdaftar dari Microsoft Corporation. Microsoft@ SQL Server dipilih karena Orion Solarwinds menyimpan hasil pemantauannya di DBMS jenis ini. Orion Solarwinds dipilih karena untuk saat ini, aplikasi tersebut adalah apliasi yang paling tangguh dan akurat untuk memantau kinerja perangkat keras yang berbasis protokol SNMP.
-
Studi literatur mulai dilakukan sejak bulan Desember 2005, perancangan Kerangka Kerja Daur Hidup Pusat Data dilakukan pada bulan Januari-Februari 2006, dan pembuatan aplikasi purwarupa Dashboard Manajerial Pusat Data dilakukan pada bulan Maret-April 2006. Secara keseluruhan, penelitian ini memakan waktu sekitar 6 bulan kalender kerja. Penelitian ini sendiri dilakukan di bagian Teknologi Informasi PT Adjra Dinamika Multi Finance Tbk yang berlokasi di jalan Agus Salim, Jakarta sedangkan perancangan dokumen lebih banyak dilakukan di PT Transforma Global, perusahaan konsultan human capital dan organizational development, yang berlokasi di Plasa Mutiara, kawasan Mega Kuningan, Jakarta.
111.4. Bahan dan Alat Penelitian Pada perancangan Kerangka Kerja Daur Hidup Pusat Data, bahan penelitian berupa teori dasar yang diambil dari beragam literatur seperti buku, jurnal, artikel, atau petikan wawancara berbentuk sofrcopy maupun hardcopy. Teori dasar tersebut dipilih berdasarkan tingkat kesesuaian dengan penelitian yang dilakukan dengan fokus utama terhadap pusat data, rekayasa sistem, digital dashboard, dan rekayasa perangkat lunak. Proses dokumentasi dilakukan menggunakan sistem komputer dengan spesifikasi perangkat keras: Prosesor Intel Pentium 111,900 MHz Memori SDRAM 256 MB Igardisk 20 GB Tiusan (mouse) dan papan kunci (keyboard) dan spesisifikasi perangkat lunak: Operating system: Microsoft@Windows XP Professional Service Pack 2 Wordprocessor: o Microsoft@ Office Word 2003 Service Pack 1 o Microsoft@ Office ~isio@'Professional 2003 Pada pembuatan Dashboard Manajerial Pusat Data, lingkungan pengembangan dilakukan menggunakan sistem komputer dengan spesifikasi perangkat keras: Prosesor Intel Pentium 111,900 MHz Memori SDRAM 256 MB Hardisk 20 GB Tiusan (mouse) dan papan kunci (keyboard) dan spesifikasi perangkat lunak: Operating system: Microsoft@Windows 2000 Server Webserver: Internet Information Services (11s) 5.1 Computer Aided Sofmare Engineering (CASE): Rational Rose 98 Professional C t t Edition Scripting engine: PHP: Hypertext Preprocessor (PHP) 5.0.5 CGUFastCGI Editor teks: EditPlus Text Editor v2.12 DBMS: Microsoft@ SQL Server 2000 Resource meter: Orion Solarwinds Wordprocessor: o Microsoft@ Office Word 2003 Service Pack 1 o Microsoft@ Office Visioa Professional 2003 Visio adalah merk terdaftar dari Microsoft Corporation.
BAB IV. KERANGKA KERJA DAUR HIDUP PUSAT DATA IV.l. Pengantar Penyusunan kerangka kerja daur hidup pusat data mengacu kepada berbagai standar dan praktik terbaik yang sering menjadi referensi dalam pembangunan dan pengoperasian sebuah pusat data. Harapannya, kerangka kerja ini dapat menjadi acuan dan arahan dalam membangun dan mengoperasikan sebuah pusat data yang baik dan berkualitas. Kerangka Kerja Daur Hidup Pusat Data disusun dan diselaraskan dengan proses bisnis yang menjadi landasan dalam implementasi pusat data. Kerangka kerja tersebut terdiri dari langkah-langkah yang secara generik dilakukan dalam konteks pembangunan dan pengoperasian sesuatu secara mum (misal: perangkat lunak). Langkah-langkah yang diterjemahkan ke dalam fase tersebut mencakup: Fase menangkap kebutuhan bisnis yang bertujuan untuk mendapatkan gambaran urnurn mengenai kebutuhan bisnis, lingkup kerja, serta objektiutujuan kegi~tari. Fase analisis yang bertujuan untuk memeriksa kelayakan proposal yang diajukan yang didapat dari fase sebelumnya. Fase ini juga menganalisis skalabilitas dan tingkat ketersediaan perlengkapan. Fase rancangan teknis yang bertujuan untuk mendapatkan gambaran me~yeluruh dari apa yang hendak dibangun termasuk juga rencana implementasi dan operasionalnya, jadwal, serta analisis risiko. ask implementasi. * Fase pengujian. Fase serah terima. * Fase operasionalisasi. Khusus dalam konteks pembangunan dan pengoperasian pusat data, fase-fase di atas dilengkapi dengan fase pembubaran untuk memberikan gambaran kegiatan yang harus dilakukan pada saat diputuskan bahwa pusat data akan diganti dengan pusat data yang baru. Garis besar dari siklus proses pembangunan dan pengoperasian pusat data tergambar dalam Kerangka Kerja Level 0, dimana urutan siklus danlatau prosesnya menggambarkan langkah-langkah yang menjadi acuan bagi perancang dan implementator pusat data daiam menghasilkan suatu pusat data yang efektif serta sesuai dengan harapan dan kebutuhan operasional perusahaan. Kerangka Kerja Level 1, Kerangka Kerja Level 2, dan Kerangka Kerja Level 3 merupakan pendetilan dari suatu proses yang terdapat pada kerangka kerja level sebelumnya. Untuk memudahkan pembacaan dan menjaga konsistensi dalam penelusuran dokurnen, pencantuman kode untuk setiap diagram dokurnen masukan, proses, dan dokumen keluaran mengikuti kesepakatan seperti berikut Tabel 3 Kesepakatan kode untuk diagram dokumen masukan, proses, dan dokumen keluaran A-B[.C].[D][-El
fnarna dokurnenlprosesl e
A
menandakan kategori diagram: o I untuk dokumen masukan
[+I
o P untuk proses o 0 untuk dokumen keluaran
B menandakan nomor urut dokumedproses dalam lingkup Kerangka Kerja Level 0. [C] menandakan nomor urut dokumedproses dalam lingkup Kerangka Kerja Level 1 atau Kerangka Kerja Level 2 terkait dengan level di atasnya. [Dl menandakan nomor urut dokurnen/proses dalam lingkup Kerangka Kerja Level 3 terkait dengan level di atasnya. [El menandakan nomor urut dokumen masukanlkeluaran dalam lingkup Kerangka Kerja Level 2 atau Kerangka Kerja Level 3. Tanda plus '+' pada pojok kanan atas hanya berlaku bagi diagram proses yang terdapat pada Kerangka Kerja Level 2 dan menandakan bahwa terdapat pendetilan dari proses tersebut pada Kerangka Kerja Level 3. 0 Tanda kurung siku '11' menandakan bahwa bagian kode tersebut bersifat opsional. Contoh: * Kode untuk diagram P-5 Procurement & Implementation diartikan sebagai proses ke-5 daiam Kerangka Kerja Level 0 dan proses tersebut bemama Procurement & Implementation. * Kode untuk diagram 0-1.2.3-1 Roles, Responsibilities & Authorizations Map diartikan sebagai o dokumen keluaran ke-1 bemama Roles, Responsibilities & Authorizations, o pada proses ke-3 dalam Kerangka Kerja Level 2, o pada proses ke-2 dalam Kerangka Kerja Level 1, o pada proses ke-1 dalam Kerangka Kerja Level 0
IV.2. Kerangka Kerja Level 0 Kerangka Kerja Level 0 menggambarkan tujuh faseltahap dalam daur hidup sebuah pusat data.
Gambar 13. Kerangka Kerja Level 0.
35
Fase B~csinessRequireitzents menjelaskan mengenai latar belakang, tujuan, sasaran, batasan, standar yang menjadi acuan, serta alasan bisnis yang mendasari keberadaan pusat data yang akan dijalankan. Hasil dari tahap ini berupa sebuah dokumen User Request Proposal yang berisi kebutuhan pusat data baru untuk kemudian mengusulkannya kepada pihak manajemen pemsahaan. Fase berikutnya, Analysis and Feasibility, melakukan analisis dan memastikan bahwa usulan proposal layak serta realistis untuk pengerjaan lebih lanjut dan sesuai dengan batasan dan kemampuan serta tujuan yang menjadi harapan perusahaan. Beberapa ha1 yang harus diperhatikan antara lain: tingkat skalabilitas dan ketersediaan barang, dukungan penyedia layanan, perangkat maupun komponen pusat data lainnya, dan komponen lama yang masih akan dipertahankan. Kesesuaian tersebut mempakan persyaratan kunci untuk mendapatkan persetujuan dari Steering Committee sebelum dauat meneruskan ke langkah - berikutnva. Fase Teclzizical and Functional Design membahas mengenai kerangka desain pusat data lengkap dengan rencana implementasi dan operasional, jadwal dan kriteria pengembangan, serta analisis risiko. Fase ini juga membahas penentuan lokasi serta komponen lainnya, serta kriteria ekspansi serta potensi pengembangan di masa mendatang. Hasil dari fase ini berupa suatu rancangan teknis yang layak untuk diimplementasikan. Fase Procuremerzt atzd Iitzplemeiztation menjelaskan mengenai proses standar pengadaan barang yang berlaku di perusahaan terkait, proses pembangunan dan penyusunarl komponen, bagaimana dukungan dari vendor, serta pengimplementasian proyek. Fase ini menghasilkan sebuah pusat data yang terangkai secara fisik dan siap beroperasi. Fase Acceptance and Operationalized melakukan serangkaian uji coba untuk memastikan bahwa pusat data terangkai secara benar dan sesuai dengan kesepakatan pada kriteria awal. Penyelesaian segala kekurangan yang terjadi selama masa uji coba dan commissioning hams menyesuaikan dengan rencana awal sehingga pada tahap akhir, pusat data tersebut telah beroperasi sesuai dengan harapan serta target yang telah ditentukan sebelumnya. Fase Monitoring and Review melakukan pemantauan terhadap kinerja pusat data yang telah beroperasi dan berlangsung paralel dengan tahap kelima yakni operasionalisasi pusat data. Pengawasan ini dilakukan dengan suatu platform terintegrasi yang secara mudah dapat menemukan parameter-parameter di luar batas normal. Dengan bekal rencana dan kriteria pengeinbangan yang telah disepakati, dapat dilakukan keputusan untuk pengembangan atau upgrade komponen sesuai dengan bagaimana hasil pengawasan. Dengan demikian, pusat data dapat tetap beroperasi sesuai dengan sasaran dan harapan yang ada. Tentunya seiring dengan perkembangan usaha yang pesat, terdapat kemungkinan bahwa kebutuhan operasional pemsahaan tidak dapat lagi terpenuhi oleh pusat data meskipun telah mengalami serangkaian upgrade dan pengembangan. Bilamana diputuskan bahwa diperlukan suatu pusat data baru untuk menggantikan pusat data yang sedang beroperasi, daur hidup pusat data tersebut memasuki fase ketujuh dan terakhir. Fase terakhir adalah Deconznzissioning dimana sudah terdapat persiapan untuk penggantian pusat data yang beroperasi dengan suatu desain baru yang lebih sesuai. Fase ini memuat suatu rencana migrasi dari pusat data operasional ke pusat data pengganti serta rencana penghentian pusat data operasional segera setelah seluruh layanannya dipindahkan ke pusat data yang baru.
IV.3. Kerangka Kerja Level 1
Gambar 14. Kerangka Kerja Level 1.
IV.4. Kerangka Kerja Level 2 dan 3 4.1. P-1 Busiizess Requirement
Gambar 15. Kerangka Kerja Level 2 untuk P-1 Business Requirement.
Proses ini bertujuan untuk menjelaskan latar belakang dari proyek pusat data yang akan berjalan dan untuk mendapatkan suatu dokumentasi berisi kebutuhan yang desain pusat data harus penuhi. P-1.1 Dntn Collection
Proses P-1.1 Data Collection bertujuan untuk mengumpulkan dokumen yang melatarbelakangi pendirian pusat data seperti dokumen cetak biru (blueprint) bisnis,
cetak biru teknologi informasi, standar industri yang menjadi acuan, serta perkiraan awal mengenai alokasi anggaranbiaya. P-1.2 Determine Stakeltolder
Gambar 16. Kerangka Kerja Level 3 untuk P-1.2 Defernti,reStakeltolder.
Biasanya, stakeholder dari proyek pembangunan dan implementasi pusat data adalah s e l d unit terkait di bagian TI dan juga kelompok pengguna (user) serta pihak manajemen perusahaan yang tergambar pada organigram perusahaan. Organigram tersebut berguna dalam menganalisis pihak-pihak yang terlibat dalam pembangunan dan pengimplementasian pusat data. P-1.3 Data Documentation
Gambar 17. Kerangka Kerja Level 3 untuk P-1.3 DataDocumentation.
Proses ini bertujuan untuk mengumpulkan seluruh dokumentasi maupun informasi pendukung sebagai bahan penyusunan User Request Proposal (URP) pusat data. P-1.4 List and Prioritize
Gambar 18. Kerangka Kerja Level 3 untuk P-1.4 LisI andPrioritize.
Proses ini merupakan proses lanjutan dari proses P-1.3 Data Documentation dan bertujuan untuk memberikan skala prioritas terhadap dokumentasi maupun informasi pendukung yang telah terkumpul. Skala prioritas ini nantinya &an menentukan lingkup dan batasan dari pusat data. P-1.5 Initiate User Reqriest Proposal
Biasanya perusahaan telah memiliki semacam template dokumen URP untuk mendokumentasikan tujuan, batasan, cara, dan standar yang menjadi acuan. Pengisian dokumen tersebut menggunakan informasi yang telah terkumpul sehingga penyusunan suatu URP untuk pusat data dapat terjadi.
P-1.6 Distribute to Siakelrolrlcr Dokumen URP kemudian didistribusikan kepada seluruh stakeholder yang telah diidentifikasi sebelumnya untuk dipelajari. Jika terdapat usulan perubahan dari stakeholder maka dapat dilakukan perbaikan terlebih dahulu atas dokumen tersebut sebelum siap diajukan untuk lanjut ke fase berikutnya.
4.2. P-2 Analysis and Feasibility Study
!I Gambar 19. Kerangka Kerja Level 2 untuk P-2 Analysis and Feasibilily Study.
Fase ini bertujuan untuk melakukan analisis kebutuhan dan studi kelayakan atas usulan URP. Pembuatan Request for Quotations (RFQ), yakni dokumen yang berisi permintaan penawaran dari para vendor berdasarkan kebutuhan atas sejumlah komponen dan perlengkapan pusat data, merupakan tindak lanjut atas informasi yang terdapat pada URP. Validasi terhadap penawaran (quotation) yang masuk harus memperhatikan apakah melebihi anggaran yang tersedia atau tidak. Akhir dari fase ini menghasilkan suatu laporan hasil analisis dan studi kelayakan. P-2.1 Initial Znfortt~ationGatlzering
Gambar 20. Kerangka Kerja Level 3 untuk P-2.1 Ittfortnafio Gatlreri~zg.
Selain URP, data-data historis, dan cetakbiru TI, regulasi yang berhubungan dengan Quality Confrol, Health, Safety, and Environment (QHSE) menjadi salah satrl faktor yang berperan dalam penentuan komponen pusat data. Daftar komponen yang didapat dari hasil pengumpulan informasi tersebut umumnya terdiri dari komponen perangkat keras dan fasilitas serta informasi yang dibutuhkan untuk kepentingan sizing komponen server dan media penyimpanan.
Gambar 21. Kerangka Kerja Level 3 untuk P-2.2 Sizing.
Sizing bertujuan untuk memprediksi kapasitas pengembangan dari setiap komponen pusat data. Data historis, rencana pengembangan ke depan, dan daftar komponen yang ada menjadi bahan pertimbangan dalam menentukan kebutuhan kapasitas komponen saat ini dan bagaimana rencana pengembangannya ke depan. P-2.3 Issue RFQs and Collect Quotations
Gambar 22. Kerangka Kerja Level 3 untuk P-2.3 Issue RFQs and Collect Quotations.
Setelah penentuan dan pengelompokan komponen-komponen yang dibutuhkan, dikeluarkan RFQ bagi setiap kelompok komponen untuk memberikan kesempatan kepada vendor memasukkan penawaran (quotation). Penawaran yang masuk kemudian direkapitulasi untuk kemudian divalidasi. Checklist RFQ yang telah dikeluarkan dapat berbentuk: Tabel 4 Contoh clrecklist untukRFQ
P-2.4 Validate Selected-Qrtotatiotrs
Validasi atas penawaran yang masuk dari setiap komponen terhadap anggaran serta ketersediaan produk biasanya menggunakan checklist berbentuk:
Tabel 5 Contoh clrecklist untuk validasi biaya dan ketersediaan komponen
P-2.5 Make B~~siness Just~jicationand Get Approval for Additiotzal Budget
Jika penawaran yang rnasuk melebihi anggaran yang telah dialokasikan untuk pusat data, rnaka perlu ada pertirnbangan ulang untuk rnemutuskan apakah selisih yang terjadi dapat ditolerir atau tidak. Apabila tidak, perlu dipertirnbangkan untuk rnerevisi ulang URP. P-2.6 Finalize Data Center AtraIysis and Feasibility Study
Finalisasi analisis dan studi kelayakan dilakukan dengan mengikuti standar prosedur yang berlaku di internal perusahaan. Setelah penentuan komponenkornponen pusat data yang diperlukan, selanjutnya harus disusun sebuah matriks kompatibilitas antara setiap komponen terkait. Hal ini dilakukan untuk menjamin integrasi dari setiap komponen pusat data dan untuk menghindari kasus dan biaya tambahan yang tidak diperhitungkan. Sebagai jaminan, seluruh vendor wajib menyerahkan sernacarn surat jaminan kompatibilitas atas produk/solusi yang ditawarkan berdasarkan rnatriks kompatibilitas yang telah ditetapkan sebelumnya oleh pihak perusahaan saat melakukan P-4.1 Initiate Tender Process. 4.3. P-3 Tecltnical and Functional Design
Gambar 23. Kerangka Kerja Level 2 untuk P-3 Teclrnical atrd Functional Design.
Fase P-2 Analysis & Feasibility Study rnenghasilkan dafiar komponen beserta konfigurasi dan perkiraan harganya. Fase P-3 Technical and Functional Design ini mernbuat suatu desain yang memenuhi tujuan awal rnenggunakan perangkat, kornponen, serta layanan yang sesuai dengan standar dan kriteria perusahaan dengan hasil akhir suatu diagram rancangan teknis, rencana irnplernentasi, rnekanisrne operasional, jadwal dan kriteria pengembangan, serta analisis risiko dari pusat data $ng bersangkutan.
P-3.1 Select artd Finalize Contporrerzt List
Gambar 24. Kerangka Kerja Level 3 untuk P3.1 Select and Finalize Cort~partetzt List.
Berdasarkan daftar perangkat yang didapat dari proses 2.5 Finalize Data Center Analysis and Feasibility Study, disusun suatu daftar komponen dari masingmasing perangkat yang sesuai dengan anggaran yang telah ditetapkan. Daftar komponen tersebut dibagi menjadi beberapa kelompok besar, yaitu Perangkat keras server Perangkat keras sistem media penyimpanan Perangkat keras jaringan Perangkat keras infrastruktw (terutama bangunan, sistem pengaturan udara, listrik, dan air) P-3.2 Prepare Implententation Strategy
Gambar 25. Kerangka Kerja Level 3 untuk P-3.2 Prepare ItnplernenfationStrategy.
Dengan perangkat yang sudah ditentukan berdasarkan proses sebelumnya, dapat dilakukan penyusunan strategi implementasi untuk meminimalkan gangguan terhadap layanan yang sedang berjalan. Bagi pusat data yang sama sekali baru, biasanya tidak ada gangguan yang mungkin terjadi. Strategi implementasi yang dibuat lebih bersifat ad-hoc dan dikerjakan sesuai dengan datangnya perangkat yang telah dipesan. Penyusunan strategi implementasi dilakukan dengan mengumpulkan secara akumulatif kriteria dan parameter yang akan menjadi batasan pembangunan pusat data. Beberapa kriteria yang dikumpulkan adalah sebagai berikut = Anggaran biaya komponen. Regulasi atau kode: peraturan yang terkait ke pemasangan dan penggunaan perangkat Cjika ada). Daya listrik: kebutuhan listrik dan fluktuasinya Pendingin: batasan suhu operasional perangkat keras dan panas yang dihasilkan (iika ada). Jika data ini tidak ada maka d a ~ a dilakukan t suatu perhitungkrata-rata menggunakan konsep Rack ~ o c a i i o nUnit @U). Keterhubungan: Kebutuhan sambungan jaringan yang diperlukan untuk operasionalnya. e Dimensi: ukuran perangkat dan kebutuhan ruangan, termasuk ruangan di atas perangkat untuk kemudahan instalasi dan pemindahan nantinya. Bobot: berat perangkat untuk keperluan desain raisedfloor yang sesuai. P3.3 Site Selection
Gambar 26. Kerangka Kerja Level 3 untuk P3.3 Site Selection.
Jika dijabarkan lebih detil, yang perlu diperhatikan dalam pemilihan lokasi adalah 0
0
Regulasi peruntukan gedung dan ruangan, serta peraturan lain yang membatasi penggunaannya. Faktor risiko lokasi yang dipilih terhadap bahaya bencana alam (gempa bumi, banjir, angin topan dan badai, tanah longsor) serta potensi kebakaran (kedekatan dengan restoran, turbin pemanas gedung, atau perangkat sejenis). Faktor HSE seperti polusi udara, suara, interferensi elektromagnetik, dan getaran (kedekatan dengan bandara atau re1 kereta api). Adanya beberapa altematif akses yang dapat dijaga keamanannya
Keberadaan faktor pendukung (listrik, air, sirkulasi udara, jalur kabel gedung, sumber cahaya alam, dan lift barang) serta redundansi faktor pendukung tersebut. Jika terdapat keterbatasan pasokan faktor di atas, maka hams dilakukan catatan pada desain yang hendak dibangun. Parameter seperti yang sudah terakumulasi pada langkah sebelumnya yaitu luas mangan yang memadai, struktur yang cukup kuat untuk rnenampung berat total pusat data terpasang, sumber daya listrik yang cukup, dan seterusnya. Hal-hal lainnya yang patut menjadi catatan dalarn rencana implementasi pusat data. P-3.4 Prepare Operalional
Gambar 27. Kerangka Kerja Level 3 untuk P-3.4 Prepare Operational.
Proses P-3.4 Prepare Operational bertujuan untuk menyiapkan segala aspek operasional yang dibutuhkan termasuk alokasi sumber daya manusia dan jadwal kerjanya. Penyiapan sumber daya manusia hams diimbangi pula dengan rencana pengembangan dan karir ke depannya. Pada akhirnya, P-3.4 Prepare Operational akan menghasilkan acuan yang menjadi Standard Operating Procedure (SOP) seharihari pusat data nantinya. P-3.5 Define Future Expansion Guide
Gambar 28. Kerangka Kerja Level 3,untuk P 3 . 5 Define Future Expa~tsionGuide.
Perlu ada penentuan kriteria kinerja pusat data yang hendak dirnonitor. Hal ini antara lain dapat dilakukan rnelalui diskusi untuk rnenentukan suatu plarform pengelolaan dashboard pusat data. Segera setelah kriteria tersebut didapat, bisa ditentukan satu atau lebih parameter terkait yang rnenentukan kinerja pusat data sehingga dapat diarnbil suatu batasan target operasional yang jika dilarnpaui oleh pusat data tersebut maka harus ditindalJanjuti dengan rencana pengembangan atau ekspansi yang sesuai. Contoh dasar dari kriteria yang dimaksud dapat dilihat pada tabel berikut Tabel 6 Contoh kriteria kinerja pnsat data
P3.6 Develop Risk Scertario and ~ o n t i n ~ c rPt+c ~
Gambar 29. Kerangka Kerja Level 3 untuk P-3.6 Develop Risk Scenario arid Comlirrgency Plan.
Rencana contingency rnencakup hal-ha1 yang berhubungan dengan Disaster Recovery Center (DRC). Pada tingkat pertama contingency biasanya dibuat dua basis data master yang beroperasi dari pusat data baru diiana keduanya rnerupakan hot mirror yang dapat saling menggantikan bilamana terjadi suatu gangguan. Pemindahan layanan ke lokasi DRC hanya diperlukan jika kedua hot mirror tersebut sama-sama mengalami gangguan. Sehubungan dengan hal tersebut, perlu dilakukan suatu analisis kuantitatif rnengenai besarnya kernungkinan gangguan ataupun penyusunan suatu rnatriks risiko atas kegiatan operasional pusat data. Kategori manajemen risiko dapat dilakukan melalui tabulasi risiko yang rnungkin terjadi dalam operasionalisasi pusat data beserta faktor probabilitas dan dampak yang mungkin dirasakan oleh pusat data apabila risiko tersebut terjadi. Hasil tabulasi tersebut memungkinkan terjadinya prioritasisasi sehubungan dengan
persiapan dalam menghadapi dan mengatasi risiko, terutama risiko yang berkaitan dengan kebutuhan biaya yang timbul. Risiko yang harus diperhatikan dapat muncul dari faktor di bawah ini Jadwal pembangunan dan implementasi. Biaya, baik pembangunan maupun operasional. Biaya keseluruhan (lifeycle cost) Technical obsolescence Kelayakan dari rencana yang ditawarkan. o Reliabilitas sistem, utama maupun pendukung. Dependensi antar komponen dan interoperabilitasnya. Perlindungan aset dan investasi. Ketergantungan terhadap vendor. Risiko kegagalan proyek secara mum. Perubahan personil, organisasi, manajemen, dan kepemilikan. Analisis terhadap tabulasi risiko di atas hams terjadi untuk bisa menentukan jaminan kinerja dari operasionalisasi pusat data. Berdasarkan kepada data tersebut, dapat dihitung tingkat kualitas layanan (service level agreement) yang diarapkan dan dijanjikan. P 3 . 7 Finalize Data Center Design
Gambar 30. Kerangka Kerja Level 3 untuk P-3.7 Finalize Data Ce~zterDesign.
Finalisasi daftar komponen yang terdapat pada desain pusat data dilakukan melalui diskusi dengan vendor perangkat atau komponen masing-masing. Daftar final komponen desain pusat data akan memuat informasi sebagai berikut Daftar final komponen utarna pusat data (didapat dari proses 3.1). Daftar final kebutuhan komponen pusat data dengan konsep RLU (didapat dari proses 3.2). a Desain dan denah lokasi pusat data yang dipilih (didapat dari proses 3.3 yang dilengkapi dengan proposal desain dari vendor yang ditunjuk). Kriteria pengembangan dan pengawasan (didapat dari proses 6.3). Rencana keadaan darurat (disaster recovery planning) dan target Service Level Agreement (SLA) operasional yang ditetapkan (didapat dari proses 3.6). Denah penempatan komponen pusat data dan denah penggunaan rak pusat data. Langkah berikutnya adalah mengidentifikasi komponen lama yang masih akan terpakai dan mempersiapkan rencana migrasi (migrationplan) untuk pemakaiannya di pusat data yang baru. Umumnya langkah tersebut tidak diperlukan untuk pusat data yang menggunakan komponen baru. Rencana migrasi yang dibuat lebih untuk instalasi perangkat baru di pusat data yang sedang dibangun. Umtan instalasi perangkat ini disesuaikan dengan urutan tingkat kepentingan perangkat yang
bersangkutan. Selama proses, perlu dilakukan koordinasi dengan manajer proyek untuk memastikan bahwa urutan yang dibuat sudah sesuai dengan proses pembangunan dan implementasi pusat data. Langkah ini juga menghasilkan rencana migrasi dari masing-masing perangkat, jika diperlukan. Rencana migrasi ini digunakan apabila perangkat tersebut akan diganti dengan yang baru atau digunakan kembali di lokasi lainnya. Keluaran akhir dari langkah ini berupa dokumen Disposal Guideline berisi prosedur penghentian operasionalisasi perangkat pusat data termasuk prosedur perlucutan (disposal) dari lokasi saat ini disertai dengan prosedur perlucutan lainnya. Sesuai dengan pengelompokan yang telah dibuat pada proses P-3.1 Select and Finalize Component List, desain teknis (technical design) disepakati menggunakan format berikut a. Perangkat Keras Server dan Media Penyimpanan Langkah pertama adalah melengkapi tabel berikut dengan paramaterparameter yang diminta. Tabel 7 Skema penggunaan rak dan data-data pelengkapnya
IOU
12U
294kg
24in x 48in
2 buah European
Netwo*, storage A, tape drive A
-
12in x22in
1 buah European
ServerA
312kg
24in x48in
2 buah European
Sewer A, FCA
Pengisian tabel di atas akan membantu dalam menentukan kebutuhan tempat dari masing-masing rak Penempatan komponen server dan media penyimpanan pada rak berdasarkan pada fungsi dari komponen tersebut (server aplikasi, server basis data, media penyimpanan, dan lain-lain). Langkah berikutnya adalah menentukan koneksi antar komponen dan kemudian membuat gambar detil dari masing-masing rak berikut bagaimana interkoneksinya. Hal ini sekaligus berfungsi sebagai mekanisme kontrol untuk melihat apakah konsep desain yang diinginkan yaitu "tidak adanya unsur single point offailure dalam desain sistem" telah tercapai atau belum. Adapun hal-ha1 yang perlu diperhatikan dalam desain final adalah sebagai berikut 1. Rancangan konektivitas daya (electricalpower) dan distribusinya. i. Perlu ada pembedaan untuk jalurprimary dan secondary. ii. Perlu ada pembedaan fase darr MCB dalam distribusinya sehingga jika terjadi power-failure/trip maka tidak akan menggangu perangkatlsistem yang lain, baik itu antara perlengkapan jaringan, server aplikasi, server basis data, atau
Storage Area Network (SAN) maupun antara perangkat utama dengan cadangannya. 2. Rancangan perangkat jaringan (network devices) dan redundancy-nya. Perlu adanya pembedaan port dan perangkat dalam konektivitas maupun pembagian beban jaringan sehingga jika terjadi devicefailure/trip maka tidak akan mengganggu perangkat/sistem yang lain baik itu antara perlengkapan jaringan, server aplikasi, server basis data, atau Storage Area Network ( S A N ) maupun antara perangkat utama dengan cadangannya. 3. Sinkronisasi untuk rancangan redundancy & fault-tolerance untuk setiap lapisan di bawah ini Perangkat keras dan sistem kandar i. ii. Fitur hotswap dan hotplug iii. Sistem pengarsipan (file system) iv. Logika basis data pada aplikasi b. Perangkat Keras Jaringan Dibuat beberapa level diagram jaringan dan inftastruktur pengkabelan untuk menggambarkan deti! koneksi jaringan. Pada level 0, dibuat suatu diagram logika untuk menggambarkan jaringan secara keseluruhan. Kemudian dibuat diagram level 1 untuk menggambarkan diagram logika dalam pusat data. Level 2 akan memberikan gambaran yang lebih terinci untuk hubungan antar komponen. c. Perangkat Keras Fasilitas Pusat Data/Infrastdchu Infrastruktur mencakup bangunan, sistem pengaturan udara, listrik, dan air. Diagram dari setiap komponen inftastntktur mengacu pada proses yang dilakukan pada proses P-3.2 Prepare Implementation Strategy dan P-3.3 Site Selection den gar^ mengacu pada kebutuhan setiap komponen. 4.4. P-4 Procurement & Implementatiofz
Gambar 31. Kerangka Kerja Level 2 untuk P-4 Procurement & Itnplenie~itation.
Proses standar pengadaan barang mengawali fase P-4 Procurement and Implementation yang kemudian dilanjutkan dengan implementasi proyek dimana proses ini mencakup pembangunan dan penyusunan komponen pusat data dengan
dukungan penuh dari vendor. Fase ini pada akhirnya menghasilkan sebuah pusat data yang terangkai secara fisik dan siap untuk beroperasi. P-4.1 Ittitiate Tender Process
Gambar 32. Kerangka Kerja Level 3 untuk P-4.1 Initiate Tender Process.
Request for Proposal (RFP) diajukan kepada para vendor terpilih berdasarkan
hasil seleksi terhadap penawaran yang masuk dan kebutuhan komponen seperti yang terdapat pada dokumen Data Center Design. Proposal yang masuk kemudan menjalani seleksi dan evaluasi u n t u k menentukan siapa pemenangnya. Hasil dari keseluruhan proses ini kemudian dilaporkan kepada Steering Committee. P-4.2 Finalize with Steering Committee
Gambar 33. Kerangka Kerja Level 3 untuk P-4.2 Firralizr with Steering Conmnmittee.
Penyeleksian proposal yang masuk biasanya melalui proses penilaian (scoring) dan shortlisted vendor. Proposal yang 1010s seleksi kemudian diajukan kepada pihak manajemen untuk mendapatkan persetujuan.
P-4.3 I~litiateProject Managentent
Gambar 34. Kerangka Kerja Level 3 untuk P-4.3 Initiate Project Martager~te~~t.
Implementasi proyek bermula dari evaluasi dokumen Data Center Design dan penentuan pihak yang terkait dalam proses implementasi nantinya. Pihak yang terkait mencakup siapa yang menjadi pemilik proyek, sponsor proyek, anggota proyek, bagian-bagian yang terlibat, dan klien. Proses ini kemudian dilanjutkan dengan pembuatan Project DeJinition Docunzent (PDD). P-4.4 Project Planning
Gambar 35. Kerangka Kerja Level 3 untuk P-4.4 ProjeelPIa~r~iirrg.
Perencanaan proyek mencakup Work Breakdown Structure - penyusunan - . (WBS) serta kesepakitan mengenai bagaimana mekanisme pelaporan dan pendokumentasian. Perencanaan proyek juga mengatur mengenai pengelolaan sumber daya yang ada dan apa peran d&i setiap anggota tim. Setelah perencanaan selesai, biasanya diadakan kick-oflmeeting sebagai pertanda dimulainya proyek. P-4.5 Project Execution
Gambar 36. Kerangka Kerja Level 3 untuk P-4.5 Project Execution.
Ekseskusi proyek mengacu kepada WBS yang telah disepakati dengan melibatkan seluruh pihak yang terkait.
P-4.6 Project ControIling
Gambar 37. Kerangka Kerja Level 3 untuk P-4.6 Project Corrtrolling.
Pengawasan proyek mengacu kepada apa yang menjadi batu loncatan (milestone) dan target pencapaian. Untuk itu, perlu diadakan pertemuan rutin dan pelaporan berjangka. Pertemuan tersebut selain untuk memantau perkembangan yang terjadi juga untuk mengawasi alokasi dana, menyesuaikan/mensinkronisasijadwal, dan melihat kualitas pencapaian hasil.
4.5. P-5 Acceptance & Operationalized
Ga~nbar38. Kerangka Kerja Level 2 untuk P-5 Acceptance & Operatiorralized
Fase P-5 Acceptance & Operationalized berawal dengan serangkaian uji coba untuk memastikan bahwa pusat data sudah terangkai secara benar dan sesuai dengan kesepakatan awal. Fase ini kemudian berlanjut dengan serah terima pusat data dari tim implementator kepada pihak yang bertanggung jawab terhadap opersionalisasinya.
Gambar 39. Kerangka Kerja Level 3 untuk P-5.1 Cortrt~tisiorrirrg.
Berdasarkan kriteria dan skenario penerimaan yang telah disusun pada fase sebelumnya, dilakukan mitigasi untuk melihat apakah perlu diambil tindakan dalam menyikapi gap yang terjadi. Apabila sudah tidak ada gap, atau sekiranya gap yang ada dapat ditoleransi, berarti proyek implementasi sudah hampir selesai dan dapat dilakukan closeout meeting. P-5.2 Acceptance of Data Center
Pada proses ini, pusat data diserahterimakan dari tim implementor kepada tim operasional. Tim implementator tidak serta merta selesai tugasnya narnun mereka masih berkewajiban memantau perkembangan pusat data selama tiga bulan ke depan. P-5.3 Gap Mifigafion
Gambar 40. Kerangka Kerja Level 3 untuk P-5.3 Gap Mitigation.
Tim implementator kemudian mengawasi jalannya operasional pusat data sambil memantau dan melihat bagian mana yang masih perlu disesuaikan atau diperbaiki. P-5.4 Execute Migration Plan
Proses ini bertujuan untuk mengeksekusi rencana migrasi dari pusat data yang lama ke yang baru, apabila ada. P-5.5 Data Center Operationalized
Proses ini menandakan mulai beroperasinya pusat data secara resmi dimana tanggung jawabnya beradapenuh di bawah tim operasional pusat data..
4.6. P-6 Monitoring & Review
Gambar 41. Kerangka Kerja Level 2 untuk P-6 Monitoring & Review
Fase P-6 Monitoring & Review melakukan pemantauan berkala terhadap kinerja pusat data yang telah beroperasi. Fase ini biasanya berlangsung secara paralel dengan fase P-5 Acceptance & Operationalized. Rancanganplatform terintegrasi yang telah disusun pada fase-fase sebelumnya akan memudahkan dalam mengidentifikasi dan menemukan parameter di luar batas normal. Pemantauan parameter tersebut dapat menggunakan semacam dashboard khusus yang telah dipemtukkan bagi pusat data. Dengan bekal rancangan platform tersebut, dapat juga diputuskan mengenai kapan perlunya dilakukan ekspansi atau upgrade komponen. Ketika kebutuhan operasional tidak dapat terpenuhi lagi melalui ekspansi atau upgrade komponen, pusat data dapat memasuki fase ketujuh, yang merupakan fase terakhir dalam siklus hidup pusat data, yaitu P-7 Decommissioning. P-6.1 Define Arcltifecfure/or Cent& Moniforing
Gambar 42. Kerangka Kerja Level 3 untuk P-6.1 Dejirre Arcltitecturefor Central Monitoring.
Penyusunan kebutuhan (requirement) dashboard pusat data dilakukan melalui analisis terhadap dokumen final komponen pusat data, platform dan protokol yang menjadi standar, petunjuk operasional, serta apa yang menjadi faktor-faktor penentu
kinerja. Dari kebutuhan tersebut, dapat disusun arsitektur dashboard pusat data yang dibutuhkan. P-6.2 Deve~op~?lelzt of DC Daslrboard
.~-~ -<-.
.. ,
Gambar 43. Kerangka Kerja Level 3 untuk P-6.2Developtnent of DC Daslrboard.
ArsiteLtur dashboard yang telah disusun pada proses sebelumnya menjadi masukan dalarn implernentasi perangkat lunak dashboard dengan mengacu kepada Sofmare Development Life-Cycle (SDLC) yang berlaku. P-6.3 Data Center Periodic Monitoring
Gambar 44. Kerangka Kerja Level 3 untuk P-6.3Data Center Periodic Monitoring.
Pernantauan pusat data menggunakan dashboard yang telah dikonfigurasi target dan batasan (threshold) berdasarkan ketentuan kineja yang diinginkan. Hasil pemantauan ini dilaporkan secara berkala kepada pihak operasional terkait. Ketika kinerja tidak sesuai dengan yang diharapkan, hal tersebut harus disarnpaikan dan diketahui oleh pihak yang menjadi penanggung jawab pusat data sesegera rnunglun.
P-6.4 Gap Mitigation and Cord~rterAction
Gambar 45. Kerangka Kerja Level 3 untuk P-6.4 Gap Mitigation arrd CourrterAction.
Permasalahan yang terjadi kemudian dianalisis untuk ditindaklanjuti secara proporsional. Kemungkinan permasalahan yang dapat terjadi adalah permasalahan yang telah teridentifikasi sebelumnya sehingga tindak lanjutnya cukup dengan mengikuti skenario yang telah disusun sebelumnya. Kemungkinan lainnya adalah permasalahan baru yang tidak teridentifikasi atau belurn pernah terjadi sebelumnya sehingga tindak lanjutnya dengan mengkonfigurasi ulang komponen pusat data atau mengusulkan pembuatan pusat data yang baru.
Gambar 46. Kerangka Kerja Level 2 untuk P-7 DecotrrLFsiorrirrg.
Fase P-7 Decommissioning mencakup konfirmasi terakhir mengenai penggantian pusat data yang beroperasi dengan pusat data baru yang lebih sesuai. Fase ini mencakup pula eksekusi rencana migrasi serta rencana penghentian pusat data operasional segera setelah seluruh layanannya dipindahkan ke pusat data yang baru. P-7.1 End of Life Confirmatiort
Fase ini diawali dengan konfirmasi dari pihak manajemen bahwa telah dibentuk suatu rencana untuk pusat data baru yang akan menggantikan fungsi pusat data yang sekarang beroperasi. Sejak keputusan ini diambil, pusat data hams melakukan persiapan untuk pemindahan operasional ke pusat data yang baru. P-7.2 Execute Disposal Plan
Terdapat beberapa tahapan penting yang berlangsung di proses ini seperti * Migrasi data (backup dari sistem operasional dan restore ke sistem yang baru). Disposal data-data lama yang tidak diperlukan lagi. Perpindahan operasional perangkat dan komponen ke pusat data yang baru. * Proses disposal keseluruhan terhadap perangkat dan komponen pusat data lama. Hal ini dilakukan setelah pusat data yang baru telah beroperasi secara penuh dan stabil. Namun jika diberlakukan suatu periode parallel run, maka proses disposal perangkat lama ini harus menunggu sampai akhir masa purulle1 run tersebut dimana fungsinya sudah tergantikan secara penuh oleh sistem yang baru.
IV.5. Alur Kerja Dokumen Pusat Data Worylow yang menggambarkan alum dan keterlibatan dokumen di masingmasing fase pada Kerangka Kerja Daur Hidup Pusat Data dapat terlihat melalui rangkaian gambar berikut ini. Kode 'CF' menandakan bahwa dokumen disusun (create) dan difinalisasi vnalize) pada fase yang bersangkutan.
Gambar 47. Alur kerja dokumen pada daur hidup pusat data (bagian 1 dari 4).
Gambar 48. Alur kerja dokumen pada daur bidup pusat data (bagian 2 dari 4).
Gambar 49. Alur kerja dokumen pada daur hidup pusat data (bagian 3 dari 4).
Gambar 50. Alur kerja dokumen pada daur hidup pusat data (bagian 4 dari 4).
57
IK 6. Formal Technical Review Uji materi dan kelayakan Kerangka Kerja Daur Hidup Pusat Data dilakukan dengan metode Formal Technical Review (FTR) mengingat FTR merupakan bagian dari rekayasa sistem. FTR yang dilakukan mencakup walkthrough dan code reading. Mengikuti pembagian peran seperti yang terdapat dalam mekanisme FTR, penulis berperan sebagai moderator dan author sedangkan yang berperan sebagai scribe adalah Wakil kepala divisi (deputy division head) IT Architecture & Improvemsnt Adira Manajer (manager) Quality Assurance Adira Manajer (manager) Data Center Adira Kepala seksi (section head) Data Center Adira Konsultan ekstemal VIPRO dan yang berperan sebagai inspector adalah Kepala divisi (division head) IT Adira ~ k a j e(manager) r IT ~nfrastructureAdira General Manager VIPXO Tabel 8 Keterlibatan peran dalam kegiatan RTR
Seluruh informasi walkthrough (seperti waktu dan lokasi, peserta, rencana pertemuan berikutnya, serta hasil pertemuan) yang tejadi sebanyak 16 kali terdokumentasi dalam bentuk Minutes of Meeting (MOM). Adapun rangkaian kegiatan mengikuti langkah-langkah daiam mekanisme FTR sebagai berikut a Overview, disebut juga sebagai Project Kick-off; dilaksanakan pada 27 Oktober 2005. Pertemuan ini bertujuan untuk memberikan penjelasan global mengenai tujuan dan langkah-langkah yang akan dilakukan serta mendapatkan komitmen untuk berpartisi aktif dari pihak-pihak yang terlibat. e Preparation mengkombinasikan kegiatan walkthrough dan code reading. Scribe mendauatkan draf dokumentasi dari author kemudian masingmasing scribe membaca dan menganalisis sekiranya ada hal-ha1 yang perlu diklarifikasi atau diperbaiki. Author melakukan walthrough secara terpisah untuk menangkap mengakomodir sekiranya ada masukan dari mireka. Kegiatan ini bertujuan untuk melengkapi dan memperbaiki draf kerangka kerja daur hidup serta mensinkronisasi dan menyelaraskan best-practice yang - - diusulkan author dengan kenyataan yang tejadi di Adira. e Inspection dilakukan melalui walkthrough rutin setiap Kamis pagi untuk memberikan info terbaru dan mendapatkan persetujuan dari para inspector.
dan
Rework danfollow-up dilakukan untuk menindaklanjuti hasil inspection. Siklus preparation-inspection-rework;follow-upberulang secara terusmenerus sampai kerangka kerja daur hidup disepakati dan berakhir pada Desember 2005. Keseluruhan proses ini menghasilkan dokumen final:
.
Kerangka Kerja Daur Hidup Pusat Data Alur Kerja Dokumen Pusat Data Data Center Project Documentation
IV.7. Analisis Manfaat Kerangka Kerja Daur Hidup Pusat Data yang dihasilkan lalu dijadiian sebagai acuan audit serta diujicobakan terhadap kondisi lapangan yang terjadi karena pada saat yang bersamaan Adira sedang dalam proses memindahkan pusat data mereka ke lokasi yang baru. Temuan-temuan dari hasil mitigasi antara kerangka kerja dengan kenyataan yang terjadi di Adiua dan usulan rekomendasi terhadap hal-hal yang sekiranya dapat dilakukan untuk meningkatkan kinerja pusat data Adira terdokumentasi dalam Data Center Project Documentation.
IV.8. Potensi Pengembangan
Gambar 51. Potensi pengembangan kerangka kerja.
Beberapa potensi pengembangan Kerangka Kerja Daur Hidup Pusat Data ke depannya adalah Kebijakan (policy) dan prosedur standar operasi (Standard Operating Procedure) pusat data mengingat sampai sekarang belum terdapat aturan baku yang berlaku d i i a Kerangka Kerja Daur Hidup Pusat Data dapat menjadi landasan dalam penyusunannya. Kebijakan Disaster Recovery Center mengingat sampai sekarang belum juga terdapat aturan baku yang berlaku dalam penyusunan kebijakan yang diturunkan dari kebijakan bagian Teknologi Informasi dan Business Contigency Policy (BCP) ini. Adira menindaklanjuti kerangka keja dengan penyusunan kebijakan dan prosedur standar operasi (Standard Operating Procedure) untuk departemen IT Infrastructure dimana pusat data Adira merupakan bagian dari departemen tersebut.
BAB V. DASHBOARD MANAJERIAL PUSAT DATA V.1. Spesifikasi Kebutuhan Perangkat Lunak (SKPL) 1.1. Pendahuluan Tujuan Bagian berikut ini berisi Spesifikasi Kebutuhan Perangkat Lunak (SKPL) atau Software Requirement Specrjkation (SRS) bagi purwarupa dashboard manajerial bernama AMDASH (Adjusted Management DASHboard). SKPL m e ~ p a k a ndokumen spesifikasi kebutuhan perangkat lunak yang akan diiembangkan. SKPL digunakan oleh pengembang perangkat lunak sebagai acuan teknis pengembangan perangkat lunak pada tahapan selanjutnya. Isi dari bagian ini sebagian besar mengadaptasi spesifiasi IEEE seperti yang termuat pada dokumen IEEE Std 830-1993. Definisi, Akronim, dan Singkatan SKPL adalah Spesifikasi Kebutuhan Perangkat Lunak, disebut juga Software Requirement Specification (SRS), merupakan spesifikasi dari perangkat lunak yang akan diiembangkan. SKPL-AMDASH.K-[xx]adalah kode yang disepakati untuk merepresentasikan kode kebutuhan (requiretnent) pada AMDASH, dengan AMDASH mempakan kode perangkat lunak, AMDASH.K adalah kode fase, dan [xx] adalah digitlnomor kebutuhan. * Unged Modeling Language (UML) adalah bahasa pemodelan perangkat lunak berorientasi objek yang dikembangkan oleh Grady Booch, Jim Rumbaugh, dan Ivar Jacobson. Use-case diagram adalah diagram UML yang menggambarkan kebutuhan fungsional sistem dimana penekannya pada apa yang dilakukan sistem cara sistem melakukannya (how). (what) dan bukan bagaimana * Actor adalah notasi UML untuk merepresentasikan pengguna (dapat sistem. berupa manusia atau sistem ekstemal). .yang- berinteraksi dengan Use-case adalah notasi UML yang merepresentasikan suatu kebutuhan fungsional sistem berdasarkan pemjabaran dari perspektif pengguna. a Sequence diagram menggambarkan interaksi antar objek di dalam dan di sekitar sistem (termasuk pengguna, tampilan; dan sebagainya) berupa . pesan (message) yang digambarkan terhadap waktu. Sequence diagram terdiri atas dimensi vertikal yang menggambarkan waktu dan dimensi horizontal yang menggambarkan objek-objek terkait.
1.2. Deskripsi Umum Perangkat Lunak Perspektif Produk AMDASH (Adjusted Management DASHboard) merupakan proof of concept dari suatu purwarupa aplikasi pemantauan kinerja pusat data. AMDASH, sebagai perangkat lunak manajemen visual berbasis jejaring, membantu pengambilan keputusan pihak manajemen dalam menindaklmjuti suatu pennasalahan yang terjadi pada pusat data. Berbeda dengan gauge-meter atau life-meter, AMDASH lebih berfkgsi sebagai alat manajemen yang memantau tindak lanjut dari tindakan koreksi
(corrective action) berkenaan dengan pennasalahan yang terjadi (problem & issue) dalam pencapaian indikator utama kinerja pusat data. Sehubungan dengan Kerangka Kerja Daur Hidup Pusat Data, AMDASH merupakan implementasi dari beberapa proses pada fase P-6 Monitoring & Review yakni proses P-6.1 Define Architecture for Central Monitoring dan P-6.2 Development of DC Dashboard.
Gambar 52. AMDASH dalam Kerangka Kerja Daur Hidup Pusat Data.
Informasi yang ditampilkan AMDASH dikelompokkan dalam lima kategori dimana setiap kategori masih terbagi lagi dalam beberapa parameter. Kategori d m parameter yang dipilih disesuaikan dengan hal-ha1 yang perlu diperhatikan dan dipantau dalam konteks kebutuhan dan penggunaan perangkat keras (hardware), perangkat lunak (sofnuare), perangkat jaringan (netware), dan perangkat penyimpanan (dataware). Kategori d m parameter ditampilkan sebagai berikut: Tabel 9 Kategori dan parameter yang menjadi indikator utama kinerja pnsat data
Server, memory, disk system
Database
Logical disk space
Logical disk space menunjukkan kapasitas ruang kosong yang masih tersisa pada hardisk, biasanya dalam megabyte (MB). Jika tersisa kurang dari 10% maka terdapat risiko data tidak dapat disimpan karena hardisksudah penuh.
Memofy availability
Memory availability menunjukkan ketersediaan MM. Biasanya jika RAM yang tersedia di bawah'80% maka terdapat risiko sistem akan kekurangan memori yang dapat mengakibatkan kegagalan sistem.
Processorload
Processor load di atas 85% menunjukkan terjadinya overloading CPU.
System uptime
System uptime merupakan ukuran ketersediaan dan kehandalan sistem.
Cache manager
Cache hit ratio rnenggambarkan perbandingan antara cache hit dan lookup pada Microsoft@SQL Server dimana idealnya harus di atas 90%.
General statistics User connection menggambarkan jumlah koneksi pengguna basis data pada saat yang bersamaan.
Basis data rnelakukan alokasi sumber daya untuk rnasing-rnasing koneksi dimana konfigurasi untuk pengguna yang terlalu banyak akan mengakibatkan basis data rnenggunakan surnber daya yang besar. Storage Area Network (SAN) Backbone network
Facility
Availability
Biasanya diukur dari uptime, idealnya di atas 95%.
Availability
Biasanya diukur dari uptime, idealnya di atas 95%.
Latency Utilization
ldealnya di atas 150 rnilidetik. ldealnya tingkat pernakaian (utilisasi) rata-rata di bawas 75%.
UPS
Uninfermptible Power Supply (UPS)
HVAC
Heating, Ventilation, Air Conditioning (HVAC)
Gambar 53. Keterkaitan arsitektur internal dengan eksternal AMDASH.
Arsitektur internal AMDASH terdiri atas tiga lapisan (layer), yakni Visual management Lapisan ini bertugas untuk menampilkan informasi performa pusat data dalam bentuk grafik dan tally berdasarkan kategori dan parameter kinerja yang telah disepakati. Lapisan ini bekerja dengan cara mengambil informasi dari lapisan performance monitoring application kemudian mengolahnya ke dalam bentuk dan format tampilan yang diinginkan. * Executive information summary Lapisan ini bertugas untuk menyeleksi dan menampilkan grafik yang menjadi fokus perhatian dari seorang pengguna. Bagian ini dapat dipersonalisasi oleh setiap pengguna AMDASH yang memiliki otorisasi
Decision support tool Lapisan ini bertugas untuk menampilkan dan memodifikasi borang Problem IdentiJication & Counter Action (PICA) dari suatu parameter. Arsitektur tersebut berjalan di atas lingkungan eksternal AMDASH yang terdiri dari lapisan: I Data center routine operation Lapisan ini menggambarkan proses rutin yang terjadi pada pusat data. Proses rutin tersebut mencakup proses yang dilakukan oleh perangkat keras, perangkat lunak, media penyimpanan dan basis data, serta perangkat komunikasi jaringan. 2 Performance Monitoring Application Lapisan ini menggambarkan aplikasi pada pusat data yang berfungsi untuk memantau kinerja perangkat yang terpasang pada lapisan di bawahnya (data center routine operation). Aplikasi pemantau tersebut biasanya memanfaatkan protokol Simple Nebvork Monitoring Protocol (SNMP) yang telah banyak diadopsi pada perangkat-perangkat pusat data. Hubungan antara modul d m sitemap-nya pada AMDASH adalah sebagai berikut
Gambar 54. Mod111fro~ltenddan backenddengan masing-masing siternap-nya pada AMDASH.
Sitemap untuk modul@ontend: Login Pengguna harus memasukkan username dan password yang telah diberikan untuk dapat menggunakan AMDASH. Logout Pengguna harus logout sebelum meninggalkanj?ontend AMDASH. Dashboard Menu dashboard merupakan halaman pertama yang ditampilkan setelah login. Halaman ini memberikan gambaran besar dari parameter-parameter yang ingin dimonitor. Parameter-parameter yang ditampilkan dapat dipersonalisasi untuk masing-masing pengguna melalui menu option. Grafik pada halaman ini menampilkan performa dari parameter selama tahun yang diukur dalam satuan unit bulan. Garis merah menyatakan target yang hams dicapai sedangkan garis biru menyatakan rata-rata performa yang dicapai tahun lalu. Detil masing-masing parameter dapat diketahui dengan cara mengklik gambar dari parameter bersangkutan. Control panel Menu control panel merupakan penggambaran lebih lanjut dari apa yang sudah ditampilkan di menu dashboard. Pada halaman ini diperlihatkan tally bulan berjalan dan bulan sebelumnya. Tally adalah komponen-komponen yang berkontribusi kepada parameter yang diukur. Tersedia borang PICA untuk memantau pennasalahan yang
terjadi sehingga untuk setiap permasalahan dapat dimasukkan informasi mengenai apa yang menjadi penyebab dan bagaimana tindak lanjutnya. Option Pada menu ini terdapat fitur untuk mengubah password dan personalisasi parameter yang akan ditampilkan pada dashboard dari masing-masing pengguna. Batas maksimum yang dapat dipilih adalah tujuh parameter dari sekian parameter yang ada. Sitemap untuk modul backend Login Administrator harus memasukkan username dan password administrator yang telah diberikan untuk dapat mengadministrasi dan mengkonfigurasi AMDASH.
* Logout Administrator hams logout sebelum meninggalkan backend AMDASH untuk menghindari penyalahgunaan wewenang oleh pengguna lain. Password configuration Pada menu ini administrator dapat mengubah password-nya. Untuk mengurangi risiko salah ketik untuk password baru, administrator diharuskan mengisipassword barunya sebanyak dua kali. * Userlist Dari menu ini, administrator dapat menambah dan menghapus pengguna. Administrator dapat pula mengubahpassword pengguna. * Target setting Menu ini untuk menentukan nilai target parameter selama setahun. Model Sofware Development Life Cycle (SDLC) yang digunakan dalam pengembangan aplikasi ini adalah linear sequentiallwaterfall dengan menggunakan notasi Unified Modeling Language (UML). Perangkat lunak yang digunakan sebagai Computer Aided Sofhvare Engineering (CASE) adalah Rational Rose 98 Professional Ci-+ Edition, sedangkan perangkat lunak yang digunakan sebagai lingkungan pengembangan adalah PHP: Hypertext Preprocessor (PHP) dikombinasikan dengan Microsoft@SQL Server sebagai Database Management System (DBMS). Fungsi Produk
Adapun fungsi-fungsi yang dimiliki oleh perangkat lunak ini adalah 8 L o-~ i n[SKPL-AMDASH.K-011 dan logout [SKPL-AMDASH.K-021 pengguna. Menampilkan informasi parameter berbentuk grafik yang telah dipersonalisasi oleh setiap pengguna dan deril informasi dari graf~k tersebut dalam bentuk tally [SKPL-AMl3ASH.K-031. 8 Menampilkan dan memodifikasi borang PICA [SKPL-AL4DASH.K-041. Mengkonfigurasipassword pengguna [SKPL-AMDASH.K-051. Melakukan personalisasi atas parameter yang akan ditampilkan pada dashboard dari masing-masing pengguna [SKPL-AMDASH.K-061. Login [SKPL-AMDASH.K-071 dan logout [SKPL-AMDASH.K-081 administrator. 8 Mengkonfigurasipassword administrator [SKPL-AMDASH.K-091. Mengadministrasi pengguna yang mencakup menambah dan menghapus serta mengubahpassword pengguna [SKPL-AMDASH.K-101. Menentukan nilai target parameter dalam setahun [SKPL-AMDASH.K-111. -
Tabel 10 Hubungan antara si1e111apdengan kode kebutuhan sistem
Karakteristik Pengguna Pengguna perangkat lunak ini adalah pengguna yang memiliki otorisasi untuk mengaktifian antarmuka AMDASH dan benvenang melihat hasil pemantauan parameter serta melakukan konfigurasi sesuai dengan hak aksesnya. Pengguna yang dimaksud tersebut disebut sebagai "pengguna". Secara operasional, "pengguna" adalah operator pusat data. Selain "pengguna", terdapat pengguna lain perangkat lunak yang memiliki otorisasi lebih untuk melakukan administrasi "pengguna" dan mengkonfigurasi batasan target dari setiap parameter. Pengguna yang dimaksud tersebut disebut sebagai "administrator". Secara operasional, "administrator" adalah penanggung jawab pusat data. Tabel 11 Kategori pengguna AMDASH -.
Kategori Pengguna
Wewenang
Pengguna
Melihat hasil pemantauan parameter serta melakukan konfigurasisesuai dengan haknya.
Administrator
Melakukan administrasi pengguna dan mengkonfigurasi batasan target dari setiap parameter.
-
Kode Kebutuhan
Batasan-batasan Batasan-batasan yang digunakan pada pengembangan perangkat lunak ini adalah 0 AMDASH tidak dilengkapi dengan so$ computing.
e
Hanya terdapat 12 pilihan parameter dari 5 kategori. Pengguna hanya dapat memilih maksimum 7 parameter untuk ditampilkan pada menu dashboard. Membutuhkan aplikasi penjelajah jejaring karena AMDASH berbasis jejaring. Server AMDASH hanya dapat bekerja pada lingkungan sistem operasi Microsoft@ Windows.
Asumsi dan Ketergantungan I
Webbmwlcr IE.
I
Client
I
I
Web & Database Server
1
,
PParty Application
Gambar 55. Gambaran aplikasi AMDASH.
Perangkat keras yang dibutuhkan oleh AMDASH adalah * PC IBM Compatible dengan prosesor Intel Pentium I11 atau lebih Memori: Random Access Memory (RAM) 256 MB atau lebih (disarankan 512 MB) a Hardisk: 50 MB ruang hardisk atau lebih Papan kunci (keyboard) * Tikusan (mouse) Perangkat lunak yang dibutuhkan oleh AMDASH adalah a Sistem operasi: Microsoft@ Windows 2000 ServerKP a Webserver: Internet Information Services (11s) a DBMS: Microsoft@ SQL Server 2000 Scripting engine: PHP: Hypertext Preprocessor (PHP) 5.0.5 CGIEastCGI Resource meter: Orion Solarwinds 1.3. Deskripsi Rinci Kebutuhan Kebutuhan Antarmuka Eksternal
Kebutuhan antarmuka eksternal pada perangkat lunak AMDASH mencakup: * Antarmuka pengguna Antarmuka pengguna dikembangkan menggunakan modus Graphical User Interface (GUI) berbasis jejaring, karenanya untuk melihat dan menggunakan AMDASH dibutuhkan aplikasi penjelajah jejaring. AMDASH menerima masukan dari pengguna melalui perintah yang diklik pada tikusan (mouse) atau yang diketikkan melalui papan kunci (keyboard). Keluaran dari AMDASH dapat dilihat melalui layar monitor secara langsung.
0
e
Antarmuka perangkat keras Aplikasi ini tidak membutuhkan antarmuka perangkat keras yang spesifik dimana kebutuhan perangkat keras secara m u m dapat dilihat pada bagian Asumsi dan Ketergantungan. Antarmuka perangkat lunak Aplikasi ini tidak membutuhkan antarmuka perangkat lunak yang spesifik dimana kebutuhan perangkat lunak secara m u m dapat dilihat pada bagian Asumsi dan Ketergantungan. Antarmuka komunikasi AMDASH membutuhkan protokol Transmission Control Protocol/Znternet Protocol (TCPIIP).
Kebutuhan Fungsional
Use-case diagram menspesifikasikan fungsionalitas atau perilaku yang menggambarkan interaksi keseluruhan sistem aplikasi dengan satu atau lebih actor ekstemal. Actor merupakan pengguna atau sistem apapun yang berinteraksi dengan sistem yang akan dikembangkan. Use case dikembangkan berdasarkan kebutuhan actor untuk menjamin bahwa sistem akan melakukan apa yang diinginkan pengguna. Use-case didgram merepresentasikan kebutuhan fimgsional AMDASH melalui use-case diagram untuk actor pengguna dalam modulfrontend dan actor administrator dalam modul backend.
Gambar 56. Use-case diagram antara actor Pengguna dan use-case-uya dalam modulfrontend.
Gambar 57. Use-case diagram antara actor Administrator dan use-case-nya dalam modul backa~d.
Sequence diagram merepresentasikan terjadinya suatu interaksi antara pengguna dengan sistem dalam suatu satuan waktu. -
a p login ~ page
, :,
/
rhoxprro~llzed
ric show wm message on wn page (iflogin tailed)
I
I
Gambar 58. Sequemce diagram untuk proses login pengguna.
Berdasarkan gambar di atas, pengguna melakukan login dan apabila validasi login berhasil, akan ditampilkan halaman dashboard yang telah dipersonalisasi.
R
: Penaauna clkk logout link
redlrect to login page
show login page
I Gambar 59. Sequence &gram untuk proses logout pengguna.
1
click dashboard link
1
v
initialize penonal)zed dashboard appearance
I
k3
show personalized dashboard appearance
1! Lr'
Gambar 60. Sequence figrant untuk mengakses menu dasltbourd.
Berdasarkan gambar di atas, pengguna memilih menu untuk menampilkan dashboard yang telah dipersonalisasi.
I
ahavrequerlcd,yq?
&lair
I
iritidiZ8 PlCA
rhav PiCA
Gambar 61. Sequence diagram untuk menampilkan informasi detil dari suatu parameter.
Berdasarkan gambar di atas, pengguna memilih menu untuk menampilkan detil informasi dari suatu parameter yang mencakup grafik, tally, dan PICA.
ii
Y
].
click control panel link
->
initidizerequested graph 8 tdiy
A -
i
<.-
s b w requested gnph 8 tdly
-----
.1ml8dire .. PICA
Gambar 62. Sequence diagrar~runtuk mengakses menu co~ttrolparrel.
h
select PlCA initialize selected PlCA show selected PlCA
Gambar 63. Sequence (lingram untuk menampilkan PlCA dengan kriteria vtaktu tertentu.
<
1 z
,i
j, I. -:... ,
:...................
ldent~vpmMem idenllfica(m
... :.
modih. p a e m identificationinfo
inilidize requesled gntph 6 tally
I'
.... shhvrequerled graph a tally
j 'i
shhv PICA
I Gambar 64. Sequence diagrarrz untuk mengubahproblerr~iderrfz~catiorzatas suatu kejadian.
: Pemauna identily counter action
h I
sho~requestedgraph R tally
I
Gambar 65. Sequerlce ifiagranr untuk mengubah counter action atas suatu kejadian.
I
.... ~n!tlltzechosen dashbard ccnfiguratirn 1 ,
6-
I : shw, chmen dashboard configuratjan
IF
I-
!
1
7
Gambar 66. Sequerzce diagram untuk meugakses menu optiorr.
.....
: Pelwauna ~
.. ..
.
.. .. .-.-.- -
wrify. =lidate & rncdify password
show status
I
initilize chosen dashboard configuration
,+..
I / /<--I shnvchosen dashboard cMlfiguration
,
Gambar 67. Sequerrce diagranr untuk mengubahpassword.
h
i
change desktop appearence
I
II show passvmrd form
Gambar 68. Seqrrerrce diagram untuk mengubah tampilau desktop pengguna.
A : Administrator
insefl usemame 8 password elidate Login
Yr l
redirect to home page 6f losin succeeded)
show home page
iF message on iwin page (if logjn failed)
II
Gambar 69. Seqrrerrce diagranr uutuk proses logirr administrator.
A
Administrator
Administrator
: Administrator
click iwout link
I
I II
show login page
I Gambar 70. Sequence diagram untuk proses logout administrator.
n , Administrator
I
click password link
n 1
s
show password f~
'
/ '01
u
Gambar 71. Sequence diagram untuk mengakses menupassword.
A : Administrator
I
insert password
show status show pass&
krm
Gambar 72. Sequence diagranz untuk mengubahpassword administrator.
I
: Administrator
I
I
1
1
click user list link
initialize user list show user list s h w add user fm
Gambar 73. Sequerice diugruni untuk mengakses menu user list.
EEI User List
: Administrator
Gambar 74. Sequertce cliagrurn untuk menamhah pengguna.
X
c
I user list
Admlnlstrator
I
click selected user name link show update password form
't I
I
I
insert new user password
0
!I
I
change user p a s s w d
s h w user list
Gambar 75. Sequertce diugrurn untuk mengubahpusswordpengguna.
A
User List
: Administrator
/
I
I
tick selected name@)
-
.'., ,
click delete button
I-I
U
delete user & update user list shwuser itst
I
s h w add user fwm /
Gambar 76. Sequence diagrant uutuk menghapus pengguna.
initialize target setting
Gambar 77. Sequence diagrairr untuk mengakses menu target setting.
D Tamet Satin
retqted p-eter
& year
showselected panmeter&year
i
Gambar 78. Sequence diagram untuk melihat target dari parameter pada tahun tertentu.
9: Administrator
I
71 i
insnwtarget
I >.Ii > t
modify target
I
, -;
showtarget
<
1 /
I
rd !i 1
Gambar 79. Sequerrce diagrat~untuk mengganti target dari suatu parameter.
Kebutuhan Data
Class diagram m e ~ e ~ r e s e n t a s i krelasi k dan kebutuhan data statis untuk menggambarkan skema dari sebelas tabel yang terdapat pada basis data AMDASH.
Gambar 80. Class diagrarn untuk menggambarkan skema relasi tabel yang terlibat. Ringkasan Kebutuhan Tabel 12 Tabel ringkasan kebutuhan fungsional dan non-fungsional AMDASH
SKPL-AMDASH.K-03
SKPL-AMDASH.K-04
SKPL-AMDASH.K-09
Mengkonfigurasipassword administrator.
SKPL-AMDASH.K-10
Mengadministrasi pengguna yang mencakup menambah dan menghapus serta mengubah password pengguna.
Menentukan nilai target paramer per bulan dalam setahun.
SKPL-AMDASH.K-11
V.2. Deskripsi Perancangan Perangkat Lunak (DPPL) 2.1. Pendahuluan
Tujuan Bagian berikut ini berisi Deskripsi Perancangan Perangkat Lunak (DPPL)atau Sofhvare Design Description (SDD) bagi AMDASH. DPPL merupakan dokumen deskripsi perancangan perangkat lunak yang akan dikembangkan dan bertujuan untuk memberikan landasan yang diperlukan dalam proses pengkodean aplikasi AMDASH. DPPL digunakan oleh pengembang perangkat lunak sebagai acuan teknis pengembangan perangkat lunak pada tahapan selanjutnya. Isi dari bagian ini sebagian besar mengadaptasi spesifikasi IEEE seperti yang termuat pada dokumen IEEE Std 1016.1-1993. Lingkup Masalah Semua deskripsi perancangan yang dijelaskan pada bagian ini dibatasi oleh spesifikasi fungsional perangkat lunak dengan mengacu pada bagian SKPL AMDASH. Definisi, Akronirn, dan Singkatan DPPL adalah Deskripsi Perancangan Perangkat Lunak, disebut juga Sofmare Design Document (SDD), merupakan deskripsi perancangan dari perangkat lunak yang akan dikembangkan. * DPPL-AMDASH.K-[XX]adalah kode yang digunakan dalam implementasi perancangan AMDASH, dengan AMDASH merupakan kode perangkat lunak, AMDASH.K adalah kode fase, dan [xx] adalah digiunomor perancangan. e tbl-[nama-tabel] adalah kode yang digunakan untuk aturan penamaan bagi nama tabel yang terdapat pada AMDASH dengan [nama-tabel] adalah rangkaian huruf dari nama tabel yang bersangkutan. 2.2. Deskripsi Perancangan Global
Deskripsi Data Tabel 13. Tabel-tabel yang terdapat pada AMDASH
tbl-category
id-category
tbl-param
id-param
id-category
tbl-log
id-log
id-param
tbl-monthlog tbl-monthtally
id-param, month-date, year-date id-param,
month-date, year-date id-param
seluruh parameter pemantauan. Daftar seluruh parameter pemantauan. Log seluruh parameter secara keseluruhan. Log seluruh parameter yang dikelompokkan menurut bulan kejadian. Detil informasi tally dari
username, id-param
I
I
I
I
untuk menindaklanjuti suatu permasalahan.
Dekomposisi Fuugsional Modul Tabel 14 Fungsilproses pada AMDASH dan kode perancangannya
I
parameter. DPPL-AMDASH.K-19
saveTarget
DPPL-AMDASH.K-20
adminLogout
Mengubah target dari masing-masing parameter. Menghapus session administrator.
Dekomposisi Fisik Modul Tabei 15 Dekomposisi fisik AMDASH
Matriks Keterunutan Tabel 16 Matriks keterunutan antara kode kebutuhan dan perancangan
SKPL-AMDASi4.K-01
Login pengguna.
userLogin
DPPL-AMDASH.K-01
SKPL-AMDASH.K-02
Logout pengguna.
userLogout
DPPL-AMDASH.K-09
SKPL-AMDASH.K-03
Menampilkan informasi parameter berbentuk grafik yang telah
showDashboard
DPPL-AMDASH.K-02
showPerformance
DPPL-AMDASH.K-03
dan detil informasi dari grafik tersebut dalam bentuk tally.
borang PICA.
V.3. Perencanaan Uji Perangkat Lunalr (PUPL) 3.1. Pendahuluan Tujuan
Bagian berikut ini berisi Perencanaan Uji Perangkat Lunak (PUPL) atau Test Plan bagi AMDASH. PUPL merupakan dokumen rencana pengujian (testing) AMDASH yang menjadi dasar bagi penulisan dokumen selanjutnya dalam lingkungan pengujian yaitu dokumen Hasil Uji Perangkat Lunak (HUPL) atau Test Result. Pengujian rnerupakan rangkaian proses eksekusi program untuk menemukan kesalahan diinana test case yang baik besar kemungkinannya menemukan kesalahan yang belum
ditemukan sebelumnya. Pengujian dapat dikatakan berhasil apabila dapat menemukan kesalahan yang sebelumnya tidak ditemukan tadi. Rencana pengujian perangkat lunak AMDASH mencakup: Lingkungan pengujian perangkat lunak berangkat lunak, perangkat keras, maupun material tarnbahan). Identifikasi pengujian (tingkat, jenis, kondisi pengujian, dan ha1 yang akan diuji). Jadwal pengujian. Penelusuran kebutuhan.
-
Definisi, Akronim, dan Singkatan PUPL adalah Perencanaan Uji Perangkat Lunak, disebut juga Sofhare Testing Plan (STP), merupakan rencana pengujian dari perangkat lunak yang akan dikembangkan. PUPL-AMDASH-K-[xxxxxx] adalah kode yang digunakan sebagai rencana pengujian AMDASH, dengan AMDASH merupakan kode perangkat lunak, AMDASH.K adalah kode fase, dan [xxmx] adalah digitfnomor rencana pengujian. 3.2. Lingkungan Pengujian Perangkat Lunak Untuk dapat melaksanakan rencana pengujian AMDASH, beberapa perangkat lunak dan perangkat keras hams dipersiapkan terlebih dahulu.
Perangkat Lunak Tabel 17 Perangkat lunak untuk rencana pengujian
Microsoft Windows XP Professional
2002 Service Pack 2
MicrosoftGorp,
SistemOperasi
Internet Information Services
5.1
Microsoft Corp.
Websewer
PHP: Hypertext Preprocessor (PHP)
5.0.5
PHP Group
Scripting engine
Microsoft@SQL Server
2000
Microsoft Corp.
DBMS
ODBC
3.525.11 17.0
Penghubung antara scripting engine & DBMS.
AMDASH
1.O
Perangkat lunak yang akan diuji.
CGllFastCGl
Perangkat Keras Minimum kebutuhan: Prosesor Intel Pentiurn 111,900 MHz i Memori SDRAM 256 MB Hardisk 20 GB Tikusan (mouse) dan papan k v c i (keyboard) Disarankan: a Prosesor Intel Pentium IV, 2 GHz
* Memori SDRAM 5 12 MB Material Tambahan
*
AMDASH - Source Code
Instalasi, Pengujian, dan Pengendalian
Diasumsikan seluruh perangkat keras sudah terinstalasi dan dapat berfungsi dengan baik serta tidak terjadi masalah yang bersifat teknis. Terdapat kemungkinan dimana perangkat lunak yang dibutuhkan ada yang belum terinstalasi sehingga harus diinstalasi terlebih dahulu. Selama berjalannya proses pengujian, setiap perangkat lunak dan perangkat keras diharapkan dapat berjalan sesuai dengan fungsinya masingmasing dan tidak terjadi kesalahan bersifat teknis yang sekiranya dapat menghambat dan menghaiangi proses pengujian AMDASH. Rencana Pengenalan
Berhubung pihak yang akan melaksanakan rencana pengujian adalah pihak pengembang sendiri dimana pihak pengembang merupakan pihak yang sudah merencanakan, merancmg, dan mengimplementasikm AMDASH maka dirasa tidak perlu adanya rencana pengenalan terlebih dahulu. Pengujian yang Akan Dilakukan
Jenis pengujian yang akan dilakukan terhadap ADMASH adalah pengujian terhadap setiap modul dan proseslfungsi yang sudah dirancang. Sedangkan tingkat pengujian yang akan dilakukan hanya mencakup unit testing saja dimana keseluruhan pengujian akan dilakukan terhadap modulffontend dan backend.
3.3. Identifikasi Pengujian Informasi Umum
Secara keseluruhan, pengujian yang akan dilakukan mengikuti strategi sebagai berikut: Pengujian dimulai dari level proses/fungsi, modul, sampai integcasi dari keseluruhan sistem. Teknik pengujian yang berbeda disesuaikan dengan tujuan pengujian. Pengujian dilaksanakan oleh pengembang perangkat lunak dan seharusnya dilaksanakanjuga oleh penguji di luar pengembang perangkat lunak. Pengujian dan debugging adalah dua kegiatan yang berbeda namun debugging diakomodasikan dalam pengujian. Tingkat Pengujian
Tingkat pengujian yang dilakukan sesuai dengan pendekatan strategi pengujian perangkat lunak yaitu e Unit testing, yaitu pengujian untuk setiap modul yang diimplementasikan. Pengujian ini memakai white box-testing. Integration testing, terdiri dari tiga jenis yaitu top-down, bottom-up, dan regression testing. Pengujian ini berfokus pada perancangan dan konstruksi dari arsitektur perangkat lunak. Test case yang biasanya digunakan untuk integration testing adalah black-box testing namun pada beberapa bagian masih menggunakan white-box testing.
0
Validation testing, yaitu pengujian untuk mendapatkan jaminan bahwa perangkat lunak yang diuji telah benar secara fungsional, perilaku, dan kebutuhan performansi. Teknik testing yang digunakan adalah black-box testing. Setelah pengujian validasi dilaksanakan, terdapat satu dari dua kemungkinan yang bisa terjadi yaitu (1) fungsi atau karakteristik performansi sesuai dengan spesifikasi dan diterima dengan baik atau (2) terdapat penyimpangan dari spesifikasi yang belum ditemukan.
Jenis Pengujian
Test case yang digunakan untuk pengujian adalah White-box testing, yaitu rnetode test case yang menguji semua prosedur secara rinci dengan memeriksa semua jalur logis (logicalpath)yang ada. Black-box testing, yaitu metode test case yang menguji apakah keluaran proseslfungsi sesuai dengan yang diharapkan apabila diberi masukan tertentu. Pengujian tidak memperhatikan apa yang terjadi dalam proses/fungsi yang diuji dan hanya memperhatikan hasilnya. Prosedur Analisis Pencntatan dan Reduksi Data
Seluruh pencatatan hasil pengujian dan manipulasi data dilakukan secara manual. Alat bantu yang digunakan adalah template untuk pengecekan mana yang sudah diuji dan bagaimana hasil pengujiannya. Rencana Pengujian
Pengujian direncanakan untuk setiap proseslfungsi dan setiap proseslf~~ngsi bisa memiliki lebih dari satu kasus uji. Detil seluruh kasus uji terdapat di lampiran.
V.4. Hasil Uji Perangkat Lunak (HUPL) 4.1. Pendahuluan Identifikasi
Identifikasi dari perangkat lunak AMDASH yang akan diuji keseluruhan sistemnya adalah sebagai berikut Judul : Adjusted Management DASHboard Singkatan : AMDASH Nomor versi : v1.0 Deskripsi Dokumeu
Dokumen ini bertujuan untuk mendokumentasikan h a i l pengujian (testing) aplikasi AMDASH serta menindaklanjuti penulisan dokumen sebelurnnya dalam lingkungan pengujian perangkat lunak yaitu dokumen Perencanaan Uji Perangkat Lunak (PUPL). Dokumen pengujian ini melalui dua tahapan, dimana tahapan pertama adalah pengecekan terhadap kesalahan yang terjadi dan tahapan berikutnya adalah adalah pengecekan terhadap penyimpangan yang terjadi. Dari hasil pengujian yang telah dilakukan, segala sesuatunya dicatat dan khusus bagi permasalahan yang tejadi, didokumentasikan dengan jelas apa yang menjadi masalah, deskripsi, dan informasi lainnya agar dapat menjadi masukan dalam pengembangan perangkat lunak selanjutnya. Pengujian dilaksanakan oleh penulis sendiri sehingga dalam penggunaan dokumen ini tidak ada masalah keamanan ataupun privasi yang harus diperhatikan.
Definisi, Akronim, da11 Singkatan e
HUPL adalah Hasil Uji Perangkat Lunak, disebut juga Sofiware Testing Result (STR), merupakan hasil pengujian dari perangkat lunak yang dikembangkan. HUPL-AMDASH-K-[xxxxxx] adalah kode yang digunakan sebagai hasil pengujian AMDASH, dengan AMDASH merupakan kode perangkat lunak, AMDASH.K adalah kode fase, d m [xxxxxx] adalah digitbornor hasil pengujian.
4.2. Deskripsi Umum Hasil Uji Penilaian Umum
Sesuai dengan kebutuhan yang dituntut dari aplikasi AMDASH dan bila dibandingkan dengan hasil final aplikasi tersebut, secara umum dapat disimpulkan bahwa AMDASH telah dapat bejalan dengan baik. Keseluruhan fungsi dan proses yang diharapkan ada seperti yang tertuang dalam dokurnen spesifikasi kebutuhan dapat dipenuhi dengan baik. Proses pengujian yang dilakukan pun dapat berjalan dengan baik dengan rincian terdapat 20 kasus uji untuk blackbox testing dan 69 kasus uji untuk white-box testing. Namun perlu diperhatikan bahwa pengujian dilakukan pada lingkungan pengembangan aplikasi (development environment) yang mungkin akan berbeda dengan lingkungan operasional aplikasi (wroduction environment) nantinya. Rekomendasi
Untuk memberikan kinerja optimal, direkomendasikan agar lingkungan operasional AMDASH dibuat semirip mungkin atau setidaknya memiliki standar minimal yang sama dengan lingkungan pengembangan aplikasi.
4.3. Perincian Hasil Uji Bagian berikut terbagi menjadi beberapa sub bab yang akan berisi rincian dari setiap hasil pengujian. Dalam konteks ini, istilah pengujian berhubungan langsung dengan setiap kasus uji yang termuat dalam dokumen Perencaaan Uji Perangkat Lunak (PUPL). Hasil Uji Modul Froirt-end [HUPL-AMDASH.K-011
Kesimpulan Hasil Uji
Pengujian dilakukan terhadap kasus uji: Tabel 18 Hasil pengujian modulfroirt-end
permasalahan. Hal ini didapat dari
Dari tabel di atas dapat disimpulkan bahwa pengujian berjalan dengan baik dan hasilnya sesuai dengan yang diharapkan. Masalah
Tidak ada. Hasil Uji Modul Back-end [HUPL-AMl3ASH.K-021 Kesimpulan Hasil Uji
Pengujian dilakukan terhadap kasus uji: Tabel 19 Hasil pengujian modul back-end
Dari tabel di atas dapat disimpulkan bahwa pengujian berjalan dengan baik dan hasilnya sesuai dengan yang diharapkan. Masalah
Tidak ada.
V.5. Potensi Pengembangan
client
I I
Web & Database Server
i,
3d Party Application
Gambar 81. Gambaran pengembangan AMDASH.
Gambar di atas menunjukkan gambaran aplikasi AMDASH dan potensi pengembangan aplikasi tersebut ke depannya yang ditandai dengan notasi bintang. Secara garis besar, potensi pengembangan AMDASH adalah Pengembangan modul yang mcndukung Simple Nehvork Management Protocol (SNMP). Versi aplikasi vana sekarana - ini masih meneandalkan kemampu& lapisan ~erfoimance-~ o n i t o v i nApplication ~ seperti Orion Solarwinds dan HP Openview untuk memantau kinerja pusat data. Hal ini diperkuat mengingat PHP sudah dilengkapi dengan subrutin yang mendukung SNMP. Pengembangan modul yang mendukung soj? computing. Versi aplikasi yang sekarang ini masih mengharuskan seorang administrator untuk memasukkan detil permasalahan yang terjadi. Pekejaan tersebut bersifat administratif dan tentunya akan cukuv b m a k menakonsumsi waktu administrator. Dengan dilengkapi so3 computing, aplikasi dapat teriadinya suatu permasalahan berdasarkan memprediisi -penyebab pembelajaran terhadap data-data -yang ada dan kemudian melaporkan usulan tersebut kepada administrator sehingga nantinya administrator cukup memverifikasi apakah usulan dari aplikasi tersebut tepat atau tidak. Validasi ulang parameter pemantauan. AMDASH saat ini dapat menampilkan informasi kinerja pusat data dalam 12 parameter pemantauan yang dikelompokkan menjadi 5 kategori. Di masa mendatang, akan semakin banyak perlengkapan pusat data yang mendukung protokol SNMP sehingga perlu dipertimbangkan mengenai parameter yang akan ditampilkan untuk nantinya dipantau.
-
-
BAB VI. SIMPULAN DAN SARAN VI.l. Simpulan Berdasarkan penelitian yang telah dilakukan, dalam konteks strategis pusat data, disimpulkan bahwa Kerangka Kerja Daur Hidup Pusat Data dapat menjadi suatu kerangka kerja acuan yang sebelumnya tidak pernah ada dalam membangun dan mengoperasikan pusat data. Kerangka kerja tersebut merupakan komplementer bagi pengalaman empiris, hasil konsultasi dengan vendor, dan hasil menguji keberuntungan melalui trial and error sehingga dapat tercapai keseimbangan dalam menjaga netralitas dari solusi terbaik yang sejalan dengan kebutuhan perusahaadorganisasi. Diharapkan, solusi untuk rancang bangun pengembangan dan pengoperasian pusat data dapat lebih meluas dan lebih mendalam karena sudah mempertimbangkan kondisi dan kebutuhan perusahaan/organisasi serta tersedianya strategi implementasi, rencana pengembangan berikutnya, dan skenario pembubaran pusat data. Kerangka kerja tersebut juga menjadi pelengkap dari beragam dokumen yang sudah ada, terutama dokumen Rob Snevely berjudul "Enterprise Data Center Design and Methodology" yang sering dijadikan sebagai acuan dalam implementasi pusat data. Selain itu, Kerangka Kerja Daur Hidup Pusat Data dapat menjadi alat audit untuk melihat bagaimana pelaksanaan pusat data di suatu pemsahaadorganisasi. Seperti yang telah dilakukan oleh Adira sejauh ini melalui audit yang dilakukan Danamon, gap yang terjadi antara kerangka kerja yang menjadi acuan dengan kondisi nyata di lapangan telah menghasilkan rekomendasi yang diharapkan dapat memperbaiki dan meningkatkan kualitas kinerja pusat data Adira ke depannya. Sedangkan dalam konteks operasional pusat data, disimpulkan bahwa AMDASH menjadi suatu purwarupa aplikasi pemantauan kinerja pusat data berdasarkan standar kinerja pusat data yang telah disepakati. Terdapat 5 kategori dan 12 parameter pemantauan kinerja pusat data yang dapat ditampilkan AMDASH yakni I Server, memory, disk system: logical disk space, memory availability, processor load, system uptime 2 Database: cache manager, general statistics 3 Storage Area Network (SAN): availability 4 Backbone network: availability, latency, utilization 5 Facility: Uninterruptible Power Supply (UPS) & Heating, Ventilation,Air Conditioning (HVAC) AMDASH mengakses dan menampilkan informasi yang didapat dari aplikasi pemantau kinerja pusat data kemudian mengolah dan menampilkannya dalam bentuk grafik dan tally serta memberikan kemudahan dalam mengidentifikasi dan mengatasi permasalahan yang terjadi melalui mekanisme PICA. Dengan terpasangnya aplikasi tersebut di Adira, sekarang pihak manajemen dapat dengan mudah memantau kinerja dan mengawasi kegiatan operasional pusat data mereka. Penggunaan notasi UML dan pendokumentasian AMDASH -terdiri dari serangkaian dokumen dengan susunan: Spesifikasi Kebutuhan Perangkat Lunak (SKPL), Deskripsi Perancangan Perangkat Lunak (DPPL), Perencanaan Uji Perangkat Lunak (PUPL), dan Hasil Uji Perangkat Lunak (HUPLF yang mengikuti SDLC linear sequentiallwaterfall dapat menjadi acuan dalam rekayasa perangkat lunak lainnya.
VI.2. Saran Baik Kerangka Kerja Daur Hidup Pusat Data maupun AMDASH memiliki banyak sekali peluang pengembangan ke depannya. Untuk perbaikan dan pengembangan kedepannya, sejumlah ha1 yang disarankan adalah Mengujicobakan Kerangka Kerja Daur Hidup Pusat Data dan AMDASH pada pusat data milik IPB. Mengeskalasi peran dan pengaruh Kerangka Kerja Daur Hidup Pusat Data, misal dengan menjadikannya sebagai standar acuan berskala nasional atau intemasional yang hams diikuti dalam pengembangan dan pengoperasian pusat data. Mengembangkan kebijakan dan standard operatingprocedure untuk pusat data serta kebijakan untuk Disaster Recovery Center (DRC). Memvalidasi parameter pemantauan yang perlu ditampilkan pada AMDASH. o
Mengembangkan modul SNMP dan aspek so$ computing pada AMDASH. Memperbaiki tampilan grafis pengguna (graphical user interface) serta mengimplementasikan AMDASH pada lingkungan pengembangan yang berbeda seperti di lingkungan pengembangan dengan sistem operasi UnixILinux dan basis data MySQL.
DAFTAR PUSTAKA A. Suhendar, S.Si & Hariman Gunadi, S.Si., MT (2002). Visual Modeling Menggunakan UML dan Rational Rose. Informatika Bandung.
CommScope (2004). Dynamic Designfor the Data Center. CommScope, Inc. David Hornby & Ken Pepple (2002). Consolidation in the Data Center.. Sun Professional Services, SunBluePrintsTMOnline.
4 entries found for Dictiouary.com (2006). (htt~:Ndictionar~.reference.com/browsehamework). Lexico Group, LLC.
framework Publishing
Dimport (2003). Sofmare Quality - Formal Technical Review Method @ttp://www.sosix.net~modules/artic1e/index.h?id=186.htm). Open Source Institute, 21 Juni 2003. Edward Wustenhoff (2002). Service Level Agreement in the Data Center. Sun Professional Services, Sun BlueprintsTM OnLine. Isnaeni Achdiat (2004). Bagaimana Audit TI Dilakukan. e B i d s i a , volume I1 no. 17, Mei-Juni 2004. Mark A. Stephens & Sumner J. Schmiesing (2004). True Digital Dashboards Support Strategic Effectiveness, The Right Information - Right Now. Visum Solutions, Inc. Metagroup (2004). First Steps Toward the Data Center of the Future. A META Group White Paper.
PT Astra International, Tbk (2001). Astra Management System. PT Astra International Terbuka. Philip
Johnson (1999). The WWW Formal Technical Review Archive (http://www2.ics.hawaii.edu/-iohnson/FTR.h).Department of Information and Computer Sciences University of Hawaii, 28 April 1999.
Richart T. Matlus, William Maurer (2005). Magic Quadrant for Data Center Outsourcing. Gartner RAS Core Reasearch Note G00128275. Rijanto Tosin (1994). Flowchart untuk Siswa dan Mahasiswa. PT Dinastindo Adiperkasa Internasional, Penerbit Dinastindo. Rob Snevely (2002). Enterprise Data Center Design and Methodology. Sun Professional Services, Sun BlueprintsTMOnLine.
Roger S. Pressman (1997). Sofiare Engineering: A Practitioner's Approach. McGraw-Hill. Sri Dhanviyanti (2003). Pengantar Unified Modeling Language (UML). 1lmuKomputer.Com. Tharsikin Insa (2004). Yang Penting Harus Diaudit! eBizzAsia, volume I1 no. 17, Mei-Juni 2004. Transforma (2003). Plan-Do-Check-Action Facilitator Training. PT Transforma Global, September 2003. Vipro (2005). IT Professional Services Outsourcing. Vipro, Desember 2005. Wikipedia (2005). Data Center ( h Wikipedia Foundation, Inc. (http://www.wikipedia.org).
p
.
Wikipedia (2006). Information Technology Infi.astructure Library (http://en.wikipedia.ordwiki/Information Technologv Infrastructure Library) . Wikipedia Foundation, Inc. (http:l/www.wikipedia.or&. Wikipedia (2006). PDCA Foundation, Inc. g.-)
(http://en.wikipedia.orp/wiki/PDCA).
Wikipedia
LAMPIRAN Deskripsi Perancangan Rinci Deskripsi Rinci Tabel Tabel 20 Struktur tbl-category
id-category
integer
name
text
Primary key, identitas kategori. Berisi nama kategori dari parameter pemantauan.
Tabel 21 Struktur tblqaram
Tabel 22 Struktur tbl-log
Tabel 23 Struktur tbl-monthlog
Tabel 24 Struktur tbl-monthtally
node
text
score
real
Primary key, perangkat mana yang rnenjadi target pernantauan. Urutan prioritas dari perangkat yang rnenjadi target pernantauan.
Tabel 25 Struktur tbl-dashboard
id-dashboard
integer
Primary key, identitas dashboard.
username
text
id-param
integer
Foreign key, nama pengguna. Foreign key, parameter yang dipilih untuk ditarnpilkan pada dashboard pengguna.
Tabel 26 Struktur tbl-monthtarget
Tabel 27 Struktur tbl-user
Tabel 28 Struktur t b l j
integer
Primary key, identitas permasalahan.
event-trigger
integer text
Foreign key, identitas parameter. Penyebab permasalahan.
date-time
datelime
Waktu terjadinya pertnasalahan.
id-P id-param
Tabel 29 Struktur tbl-i
Tabel 30 Struktur tbl-ca
id-ca
integer
id-i counter-action deadline PIC
integer text date/time text
status
jnteger
close-date
datebime
Primary key, identitas tindak lanjut. Foreign key, identitas isu terkait. Tindak lanjut yang akan dilakukan. Batas waktu tindak lanjut. Penanggung jawab tindak lanjut. Status tindak lanjut, apakah rnasih dikerjakan atau sudah selesai. NULL penyelesaian tindak lanjut, boleh Waktu
Deskripsi Fungsional Secara Rinci Spesifikasi FungsilProses userLogin ldentifikasilnarna
: DPPL-AMDASH.K-OlluserLogin
Deskripsi isi
: Mernvalidasi hak akses pengguna berdasarkan nama dan password rnasukan.
Spesifikasi Query Q1.
Q2.
SELECT last-login FROM tbl-user WHERE username = 'Susername' AND password UPDATE tbl-user SET last-login = now-login, now-login WHERE username = 'Susername'
=
=
'Spassword'
'Snow-login'
Spesifikasi ~ l g o r i t m Global a Initial State (IS)
:
Username dan password terinisialisasi.
Final State (FS)
:
Bila validasi masukan benar, informasi login termutakhirkan. Bila salah, kembali ke tampilan awal dengan pesan kesalahan.
procedure oUserLogin::userLogin($username, Spassword) if jumlah hasil eksekusi Q1 > 0 then $now login t informasi waktu saat ini eksekusi Q2 pindah ke halaman dashboard else kembali ke halaman login tampilkan pesan kesalahan
Spesifikasi FungsilProses showDashboard ldentifikasilnarna
: DPPL-AMDASH.K-02lshowDashboard
Deskripsi isi
:
Menarnpilkan halarnan dashboard yang sesuai dengan pengguna
Spesifikasi Query Ql.
SELECT tbl-param.*, tbl-category.name AS category FROM tbl-param INNER J O I N tbl category ON
tbl-category. iTcategory = tblparam.id-category INNER J O I N tbl-dashboard ON tbl-dashboard.id-param = tbl-param.id-param WHERE tbl-dashboard.username = '$username';
*
FROM tbl-param WHERE id-param
'$idgaram'
Q2.
SELECT
Q3.
SELECT AVG(score) FROM tbl-monthlog WHERE year-date = '$last-year' AND id-param = '$id-param'
Q4.
SELECT score FROM tbl-monthlog WHERE id-param = '$id-param' AND month-date
AND year-date Q5.
=
=
=
'$monthT
'$yearT";
SELECT target FROM tbl-monthtarget WHERE id-param = '$id-param' AND month-date = '$month1 AND year-date = '$yeart";
SpesifNGasi Algoritma Global I n i t i a l S t a t e (IS)
:
Username terinisialisasi.
F i n a l S t a t e (FS)
:
Dashboard personalisasi pengguna.
procedure oDashboard::showDashboard($username) f o r setiap parameter hasil eksekusi Ql
$idgaram t id parameter tampilkan nama kategori dan parameter dari hasil eksekusi Q2 {tampilkan rata-rata parameter tahun lalu) $last-year t tahun lalu tampilkan rata-rata tahun lalu dari hasil eksekusi Q3 (tampilkan nilai dan target parameter per bulan dalam setahun terakhir) f o r $i C 1 t o 12 $month = bulan ke-$i $year = tahun ini eksekusi (14 eksekusi Q5
Spesifikasi FungsilProses showPerformance Identifikasilnarna
: DPPL-AMDASH.K-03/showPerfonance
Deskripsi isi
: Menarnpilkan graph, tally, dan borang PICA untuk paramater tertentu.
Class::Objek
: controlPanel::oControlPanel
Spesifikasi Query
*
FROM tbl-category
Q1.
SELECT
Q2.
SELECT tblgaram.* FROM tbl param INNER J O I N tbl-dashboard ON-
tbl-dashboard.id-param = tbl-param.id-param WHERE tbl-param.id category = '$id category' AND tbl-dashboard.;sername = '$use;name1 Q3.
SELECT type, unit FROM tbl-param WHERE id-param
Q4.
SELECT target FROM tbl-monthtarget WHERE id-param = '$id-param' AND month-date = '$month1 AND year-date
Q5.
SELECT COUNT(*) FROM tbl-p WHERE MONTH(date-time) = '$month1 AND YEAR(date-time) = '$year1 AND id-param = '$id-param'
Q6.
SELECT * FROM tbl-p WHERE MONTH(date-time) = '$month1 AND YEAR(date-time) = '$yeart AND id-param = '$id param' ORDER BY date-time ~ E S C
Q7.
SELECT * FROM tbl-i WHERE id-p = '$id-p' ORDER BY id-i
Q8.
SELECT * FROM tbl-ca WHERE id-i = '$id-i' ORDER BY id-ca
=
=
'$id-param'
'$year1
SpesifikasiAlgorittna Global Initial State (IS)
:
Username dan parameter terinisialisasi.
Final State (FS)
:
Graph, tally, dan PICA.
procedure oControlPanel::showPerformance($username, f o r setiap kategori dari hasil eksekusi Ql f o r setiap parameter dari hasil eksekusi Q2
$id-param)
tampilkan kategori dan parameter ambil unit dan tipe dari eksekusi Q 3 ambil target dari eksekusi Q4 tampilkan graph dan tally berdasarkan $idgaram $month = bulan PICA yang diinginkan pengguna $tahun = tahun PICA yang diinginkan pengguna tampilkan total kejadian dari eksekusi Q 5 f o r setiap kejadian dari eksekusi Q 6 tampilkan kejadian f o r setiap identifikasi permasalahan dari eksekusi Q7 tampilkan identifikasi permasalahan f o r setiap tindak lanjut dari eksekusi Q8 tampilkan tindak lanjut
Spesifikasi FungsilProses doPl ldentifikasilnama
: DPPL-AMDASH.K-04IdoPI
Deskripsi isi
: Menambah atau mengubah permasalahanlisu untuk suatu kejadian.
Spesijikasi Query
Q1.
INSERT INTO tbl-i(id-p, problem-issue, username, date-time) VALUES ($id-p, '$pi1, '$username', getdate())
Q2. UPDATE tbl-i SET problem-issue = '$pi' WHERE: id-i
=
'$id-i'
SpesifikasiAlgoritma Global Initial State (IS)
:
Identitas kejadian, permasalahan/isu, username, identitas permasalahan/isu terinisialisasi.
Final State (FS)
:
Tabel tbl-i termutakhirkan.
procedure oControlPanel::doPI($id-p, $id-i, $pi, $usename) if menambah identifikasi permasalahan/isu then eksekusi Q1 else eksekusi Q2
Spesifikasi FungsilProses doCA ldentifikasilnarna : DPPL-AMDASH.K-05ldoCA Deskripsi isi
: Menambah atau rnengubah tindak lanjut untuk suatu permasalahanlisu.
Spesifkasi Query Q1.
INSERT INTO tbl-ca(id -i, counter-action, deadline, PIC, status) VALUES ($id-i, 'Sca', '$deadline', '$PIC', '0')
Q2. UPDATE tbl ca SET counter-action = ' $ca ' , deadline PIC = '$PIC1, status = '$status1 WHERE id-ca = '$id-ca'
=
'$deadline' ,
Q3. UPDATE tbl-ca SET counter-action = '$car,deadline = '$deadlinet, PIC = '$PIC1, status = '$statusT,close-date = '$date' WHERE id-ca = '$id-ca'
Spesifkasi Algoritma Global Initial State (IS)
:
Identitas perrn.lsalahan/isu, identitas tindak lanjut, tindak lanjut, batas waktu tindak lanjut, dan penanggung jawab tindak lanjut terinisialisasi.
Final State (FS)
:
Tabel tbl-ca termutakhirkan.
procedure oControlPanel::doCA($id-i, $id-ca, Sca, $deadline, $PIC) if menambah tindak lanjut permasalahan/isu then eksekusi Q1 else $status '? status tindak lanjut if status tindak lanjut sudah selesai then $date '? waktu selesainya tindak lanjut eksekusi Q3 else eksekusi Q2
Spesifikasi FungsilProses showoption ldentifikasilnama
: DPPL-AMDASH.K-O6lshowOption
Deskripsi isi
: Menampilkan pilihan parameter yang ingin ditampilkan pengguna pada menu dashboard.
Ql.
SELECT tbl-param.id-param AS id-param, tbl-category.name A S category, tbl-param.name AS param FRoM tbl-category INNER JOIN tbl param ON tbl-category. id-category = tblgaram.id-category
Q2.
SELECT
* FROM tbl-dashboard
WHERE
username
=
'$username'
Spesifkasi Algoritma Global Initial State (IS)
:
Username terinisialisasi.
Final State (FS)
:
Pilihan parameter sesuai personalisasi pengguna.
procedure oOption::show0ption($username)
if hasil eksekusi Q 1 terdapat pada hasil eksekusi Q2 then beri tanda bahwa parameter tersebut dipilih oleh pengguna
Spesifikasi FungsilProses updatePassword ldentifikasilnama
: DPPL-AMDASH.K-07lupdatePassword
Deskripsi isi
: Mengubah password pengguna.
Class::Objek
: option::oOption
Spesifkasi Query Q1.
SELECT
*
FROM tbl-user
WHERE username Q2.
=
'$username' AND password
UPDATE tbl-user SET password username = '$username'
=
=
'$oldPasswordl
'$newpassword '
WHERE
Spesifikasi Algoritma Global Initial Final
State
State
(IS)
(FS)
:
Username, password saat ini, dan password baru terinisialisasi.
:
Password baru pengguna termutakhirkan.
procedure o0ption::updatePassword($username, $newpassword) if terdapat hasil dari eksekusi Q 1 then eksekusi Q2
SoldPassword,
Spesifikasi FungsilProses updateDashboard ldentifikasilnama
: DPPL-AMDASH.K-08lupdateDashboard
Deskripsi isi
: Mengubah pilihan parameter yang ingin ditampilkan pengguna pada menu dashboard.
Spesijikasi Query Q1.
DELETE FROM tbl-dashboard WHERE username
Q2.
INSERT INTO tbl dashboard(username, id-param) VALUES ( '$username' , $id-param)
=
'$username'
Spesijikasi Algoritma Global I n i t i a l S t a t e (IS)
:
Username, parameter yang dipilih terinisialisasi.
F i n a l S t a t e (FS)
:
Dashboard personalisasi parameter pengguna termutakhirkan.
procedure oOption::updateDashboard($username,
$id-param)
eksekusi Q1 eksekusi Q2
Spesifikasi FungsilProses userLogout identifikasilnarna
: DPPL-AMDASH.K-091userLogout
Deskripsi isi
:
Menghapus session pengguna.
Spesijikasi Algorit~naGlobal I n i t i a l S t a t e (IS)
:
-
F i n a l S t a t e (FS)
:
Seluruh informasi sementara pengguna berupa session/cookies terhapus.
procedure oUserLogout::userLogout()
hapus seluruh session/cookies
Spesifikasi FungsilProses adminLogin identifikasilnarna
: DPPL-AMDASH.K-IOIadminLogin
Deskripsi isi
: Memvalidasi hak akses administrator berdasarkan narna dan password rnasukan.
Spesijikasi Query Q1. Q2.
SELECT * FROM tbl-user WHERE username = 'administrator' ANC password
=
'$password1
UPDATE tbl-user SET last-login = now-login, now-login = 'Snow-login' WHERE username = 'admnistrator"';
Spesijikasi Algoritma Global I n i t i a l S t a t e (IS)
:
Username dan password terinisialisasi.
F i n a l ' S t a t e (FS)
:
Bila validasi masukan benar, informasi login termutakhirkan. Bila salah, kembali ke tampilan awal dengan pesan kesalahan.
procedure oAdminLogin::adminLogin(Susername, Spassword) if jumlah hasil eksekusi Q1 > 0 then Snow-login 6 informasi waktu saat ini eksekusi Q2 pindah ke halaman home else kembali ke halaman login tampilkan pesan kesalahan
Spesifikasi FungsilProses showHome Identifikasilnama
: DPPL-AMDASH.K-1llshowHome
Deskripsi isi
: Menampilkan halarnan home.
C1ass::Objek
: home::oHome
Spesifkasi Algoritma Global Initialstate (IS)
:
-
Final State (FS)
:
Halaman home.
procedure oHome::showHome() tampilkan halaman home
Spesifikasi FungsilProses showPassword Identifikasilnama
: DPPL-AMDASH.K-12/showPassword
Deskripsi isi
: Menampilkan halaman password.
Class::Objek
: password::oPassword
Spes@kasi AlgoriOna Global Initial State (IS)
:
-
Final State (FS)
:
Halaman password.
procedure oPassword::showPassword() tampilkan halaman password
Spesifikasi FungsilProses updatepassword ldentifikasilnama
: DPPL-AMDASH.K-l3lupdatePassword
Deskripsi isi
: Mengubah password administrator.
Class::Objek
: password::oPassword
Spesifikasi Query Ql.
SELECT
* FROM tbl-user
WHERE username = 'administrator' AND password = 'SoldPassword'
Q2. UPDATE tbl-user SET password = 'Snewpassword' WHERE username = 'administrator'
Spesifkasi Algoritma Global Initial State (IS)
:
Password saat ini dan password baru terinisialisasi.
Final State (FS)
:
Password baru administrator termutakhirkan.
procedure oPassword::updatePassword($oldPassword, if terdapat hasil dari eksekusi Q 1 then eksekusi Q2
SnewPassword)
Spesifikasi FungsilProses showuser ldentifikasilnama
:
Deskripsi isi
: Menampilkan daftar pengguna aplikasi
Class::Objek
: user:oUser
DPPL-AMDASH.K-14lshowUser
Spesifkasi Query Ql.
SELECT username, last login FROM tbl-user WHERE username <> 'a&inistratorl ORDER BY username
Spesijkasi Algoritma Global Initialstate (IS)
:
-
Final State (FS)
:
Daftar pengguna dan informasi login terakhir pengguna bersangkutan.
procedure oUser::showUser() for setiap hasil eksekusi Ql tampilkan nama pengguna dan informasi login terakhir ke layar
Spesifikasi FungsilProses insertuser ldentifikasilnama
: DPPL-AMDASH.K-15linsertUser
Deskripsi isi
: Menambah pengguna aplikasi.
Class::Objek
: user:oUser
Spesijkasi Query Ql.
INSERT INTO tbl-user(username, password, last-login, now-login) VALUES('$username', 'Spassword', 'Slogin-info', 'Slogin-info')
Spes$kasi Algoritma Global Initial State (IS)
:
Username dan password terinisialisasi.
~ i n a lState (FS)
:
Tabel tbl-user termutakhirkan.
procedure oUser::insertUser($username, Slogin-info t waktu saat ini eksekusi Q1
Spassword)
Spesifikasi FungsilProses updateuser ldentifikasilnama
: DPPL-AMDASH.K-161updateUser
Deskripsi isi
: Mengubah password pengguna aplikasi.
Class::Objek
: user:oUser
Spesifikasi Query Q1. UPDATE tbl user SET password WHERE username = '$username'
=
'$password1
Spesifikasi Algoritma Global Initial State (IS)
:
Username dan password terinisialisasi.
Final State (FS)
:
Tabel tbl-user termutakhirkan
procedure oUser::updateUser($username, eksekusi Q1
$password)
Spesifikasi FungsilProses deleteuser ldentifikasilnama
: DPPL-AMDASH.K-17ldeleteUser
Deskripsi isi
: Menghapus pengguna aplikasi.
Class::Objek
: user:oUser
Spesifikasi Query Ql. DELETE FROM tbl-user WHERE username
=
'$iduser'
Spesijikasi Algoritma Global Initial State (IS)
:
Username terinisialisasi.
Final State (FS)
:
Tabel tbl-user termutakhirkan.
procedure oUser::deleteUser($id-user) eksekusi Q1
Spesifikasi FungsilProses showTarget ldentifikasilnama
: DPPL-AMDASH.K-l8lshowTarget
Deskripsi isi
: Menampilkan target dari masing-masing parameter.
Spesijikasi Query Q1.
SELECT id-category, name FROM tbl-category
Q2.
SELECT id-param, name, unit unit, critical-threshold, type FROM tbl param WHERE id:category = '$idv
Q3.
SELECT target FROM tbl-monthtarget WWERE id-param = '$id-param' AND month-date = '$monthf AND year-date = '$year"';
Spesijikasi Algoritma Global Initial State (IS)
:
-
Final State (FS)
:
Target parameter selama 12 bulan pada tahun tertentu:
procedure oTarget::showTargetO for setiap hasil eksekusi Q1 tampilkan nama kategori ke layar sebagai pilihan
if parameter telah dipilih then $id t parameter yang dipilih else $id f? pilih parameter yang pertama for setiap hasil eksekusi Q2 tampilkan nama dan unit pengukuran parameter bersangkutan $id-param f? identitas parameter bersangkutan if tahun telah dipilih then $year t tahun yang dipilih else $year t tahun ini for $i t. 1 to 12 $month t $i for setiap hasil eksekusi Q3 tampilkan target untuk bulan pada tahun dari parameter
Spesifikasi FungsilProses saveTarget identifikasilnama
: DPPL-AMDASH.K-191saveTarget
Deskripsi isi
: Mengubah target dari masing-masing parameter.
Class::Objek
: target::oTarget
Spesifikasi Query Q1. DELETE FROM tbl-monthtarget WHERE id-param = '$id-param' AND year-date Q2.
=
'$year1
INSERT INTO tbl-monthtarget(month-date, year-date, idgaram, target ) VALUES('$il, '$year1, '$id-param', '$target1)
Spesifikasi Algoritma Global Initial State (IS)
:
Identitas parameter, tahun, dan besar target terinisialisasi.
Final State (FS)
:
Tabel tbl-monthtarget termutakhirkan.
procedure oTarget::saveTarget($id-param, for $i C 1 to 12 if Si = 1 then eksekusi Q1 eksekusi Q2
$year, $target)
Spesifikasi FungsilProses adminLogout ldentifikasilnama
: DPPL-AMDASH.K-20ladminLogout
Deskripsi isi
: Menghapus session administrator.
Class::Objek
: adminLogout::oAdminLogout
Spesifikasi Algoritrna Global Initial State (IS)
:
-
F i n a l S t a t e (FS)
:
Seluruh informasi sementara administrator berupa session/cookies terhapus.
procedure oAdminLogout::adminLogout()
hapus seluruh session/cookies
Uji Modul Front-end
Uji Proses/Fuizgsi userLogin [DPPL-AMDASH.K-011 I n i t i a l S t a t e (IS)
:
Username dan password terinisialisasi.
F i n a l S t a t e (FS)
:
Bila validasi masukan benar, informasi login termutakhirkan. Bila salah, kembali ke tampilan awal dengan pesan kesalahan.
procedure oUserLogin::userLogin($username, i f jumlah hasil eksekusi Ql > 0 t h e n
Spassword)
$now login t informasi waktu saat ini eksekusi Q2 pindah ke halaman dashboard else
kembali ke halaman login tampilkan pesan kesalahan
Pembagian blok algoritma: Path
I
Code p r o c e d u r e oUserLogin::userLogin($username, Spassword) i f jumlah hasil eksekusi Ql > 0 t h e n
$now login C informasi waktu saat ini eksekusi Q2 pindah ke halaman dashboard else
kembali ke halaman login tampilkan pesan kesalahan Black-boxJesting [PUPL-AMDASH.K-010101] I n i t i a l S k a t e (IS)
:
Username dan password terinisialisasi.
F i n a l S t a t e (FS)
:
Bila validasi masukan benar, informasi login termutakhirkan. Bila salah, kembali ke tampilan awal dengan pesan kesalahan.
White-boxTesting e
Path 1-2-3-4-5 [PUPL-AMDASH.K-010201] Path 1-2-6-7-8 [PUPL-AMDASH.K-0102021
I n i t i a l S t a t e (IS)
:
Username terinisialisasi.
F i n a l S t a t e (FS)
:
Dashboard personalisasi pengguna.
procedure oDashboard::showDashboard($username) f o r setiap parameter hasil eksekusi Q1
$id-param t id parameter tampilkan nama kategori dan parameter dari hasil eksekusi Q2 (tampilkan rata-rata parameter tahun lalul
$last-year t tahun lalu tampilkan rata-rata tahun lalu dari hasil eksekusi Q3 (tampilkan nilai dan target parameter per bulan dalam setahun terakhir) f o r $i t 1 t o 12 $month = bulan ke-$i $year = tahun ini eksekusi Q4 eksekusi Q5
Pembagian blok algoritrna: Path
I
1 2
Code p r o c e d u r e oDashboard::showDashboard($username) f o r setiap hasil eksekusi 01 - parameter -
$id-param C id parameter tampilkan nama kategori dan parameter dari eksekusi Q2 (tampilkan rata-rata parameter tahun lalu) $last-year t tahun lalu tampilkan rata-rata tahun lalu dari hasil eksekusi Q3 (tampilkan nilai dan target parameter per bulan dalam setahun terakhir) f o r $i t 1 t o 12 $month = bulan ke-$i $year = tahun ini eksekusi Q4 eksekusi Q5 Black-box Testing [PUPL-AMDASH.K-020101] I n i t i a l State (IS)
:
Username terinisialisasi.
F i n a l S t a t e (FS)
:
Dashboard personalisasi pengguna.
White-box Testing e e
e
Path 1-2 [PUPL-AMDASH.K-0202011 Path 1-2-3-4-5-6-7-8-9-10 [PUPL-AMDASH.K-0202021 Path 1-2-3-4-5-6-7 [PUPL-AMDASH.K-0202031
I n i t i a l State (IS)
:
Username dan parameter terinisialisasi.
F i n a l S t a t e (FS)
:
Graph, tally, dan PICA.
p r o c e d u r e oControlPanel::showPerformance($username, f o r setiap kategori dari hasil eksekusi Q1 f o r setiap parameter dari hasil eksekusi Q2
tampilkan kategori dan parameter ambil unit dan tipe dari' eksekusi Q3 ambil target dari eksekusi Q4 tampilkan graph dan tally berdasarkan $id-param $month
=
bulan PICA yang diinginkan pengguna
$id-param)
Stahun = tahun PICA yang diinginkan pengguna tampilkan total kejadian dari eksekusi Q5 for setiap kejadian dari eksekusi Q6 tampilkan kejadian for setiap identifikasi permasalahan dari eksekusi Q7 tampilkan identifikasi permasalahan for setiap tindak lanjut dari eksekusi Q8 tampilkan tindak lanjut Pembagian blok algoritma: Path
1
Code
1
procedure oControlPanel::showPerformance(Susername,
2 3 4
Sidgaram) for setiap kategori dari hasil eksekusi Q1 for setiap parameter dari hasil eksekusi Q2 tampilkan kategori dan parameter
5 6
ambil unit dan tipe dari eksekusi Q3 ambil target dari eksekusi Q4
l
tampilkan graph dan tally berdasarkan $id-param Smonth = bulan PICA yang diinginkan pengguna Stahun = tahun PICA yang diinginkan pengguna tampilkan total kejadian dari eksekusi Q5 for setiap kejadian dari eksekusi Q6 tampilkan kejadian for setiap identifikasi permasalahan dari eksekusi Q7 tampilkan identifikasi permasalahan for setiap tindak lanjut dari eksekusi Q8 tampilkan tindak lanjut
Black-box Testing [PUPL-AMi2ASH.K-03010I]
Initial State (IS)
:
Username dan parameter terinisialisasj
Final State (FS)
:
Graph, tally, dan PICA.
White-box Testing
*
0
m
Path 1-2-5-6-7-8-9-10-1 1 [PUPL-AMDASH.K-0302011 Path 1-2-3-5-6-7-8-9-10-11 [PUPL-AMDASH.K-0302021 Path 1-2-3-4-5-6-7-8-9-10-1 1 [PUPL-AMDASH.K-0302031 Path 1-2-5-6-7-8-9-10-11-12-13 [PUPL-AMDASH.K-0302041 Path 1-2-3-5-6-7-8-9-10-1 1-12-13 [PUPL-AMDASH.K-0302051 Path 1-2-3-4-5-6-7-8-9-10-1 1-12-13 [PUPL-AMDASH.K-0302061 Path 1-2-5-6-7-8-9-10-1 1-12-13-14-15 [PUPL-AMDASH.K-0302071 Path 1-2-3-5-6-7-8-9-10-1 1-12-13-14-15 [PUPL-AMDASH.K-0302081 Path 1-2-3-4-5-6-7-8-9-10-11-12-13-14-15 [PUPL-AMDASH.K-0302091 Path 1-2-5-6-7-8-9-10-1 1-12-13-14-15-16 [PUPL-AMDASH.K-0302101 Path 1-2-3-5-6-7-8-9-10-11-12-13-14-15-16 [PUPL-AMDASH.K-030211j Path 1-2-3-4-5-6-7-8-9-10-1 1-12-13-14-15-16 [PUPL-AMDASH.K-0302121
Uji Proses/Fu,~gsidoPI [DPPL-AMDASH.K-041 ~nitialState (IS)
:
Identitas kejadian, permasalahan/isu,
username, identitas permasalahan/isu terinisialisasi. Final State (FS)
:
Tabel tbl-i termutakhirkan.
procedure oControlPanel::doPI($id-p, $id i, $pi, $usename) i f menambah identifikasi permasalahan/isu then
eksekusi Q1 else
eksekusi Q 2
Pembagian blok algoritma: Path
(
Code procedure oControlPanel::doPI($idg, $id-i, $pi, $usename) if menambah identifikasi permasalahan/isu then
eksekusi Q1 else
eksekusi 42 Black-box Testing [PUPL-AMDASH.K-040101] I n i t i a l State (IS)
:
Identitas kejadian, permasalahan/isu, username, identitas permasalahan/isu terinisialisasi.
Final State (FS)
:
Tabel tbl-i termutakhirkan.
White-box Tesfing
Path 1-2-3 [PUPL-AMDASH.K-040201j Path 1-2-4-5 [PUPL-AMDASH.K-0402021
I n i t i a l State (IS)
:
Identitas permasalahan/isu, identitas tindak lanjut, tindak lanjut, batas waktu tindak lanjut, dan penanggung jawab tindak lanjut terinisialisasi.
Final State (FS)
:
Tabel tbl-ca termutakhirkan.
procedure oControlPanel::doCA($id-i, $id-ca, $ca, $deadline, $PIC) if menambah tindak lanjut permasalahan/isu then
eksekusi Q1 else
$status C status tindak lanjut if status tindak lanjut sudah selesai then
$date t wektu selesainya tindak lanjut eksekusi Q3 else
eksekusi Q2
Pemba ,ian blok algoritma: Path
Code
-
procedure oControlPanel::doCA($id-i,
$id-ca, Sca, $deadline,
SPJC) i f menambah tindak lanjut permasalahadisu then
eksekusi Q1 else
$status C status tindak lanjut if status tindak lanjut sudah selesai then
$date waktu selesainya tindak lanjut eksekusi Q3 else eksekusi Q2 Black-box Testing [PUPL-AMDASH.K-050101]
Initial State (IS)
:
Identitas permasalahan/isu, identitas tindak lanjut, tindak lanjut, batas waktu tindak lanjut, dan penanggung jawab tindak lanjut terinisialisasi.
Final State (FS)
:
Tabel tbl-ca termutakhirkan
White-box Jesting 0
*
Path 1-2-3 [PUPL-AMDASH.K-0502011 Path 1-2-4-5-6-7-8 [PUPL-AMDASH.K-0502021 Path 1-2-4-5-6-9-10 [PUPL-AMDASH.K-0502031
Initial State (IS)
:
Username terinisialisasi.
Final State (FS)
:
Pilihan parameter sesuai personalisasi pengguna.
procedure o0ption::showOption($username) if hasil eksekusi Q 1 terdapat pada hasil eksekusi Q2 then beri tanda bahwa parameter tersebut dipilih oleh pengguna
ian blok algoritma: Code
Path
procedure o0ption::showOption($username) if hasil eksekusi Q1 terdapat pada hasil eksekusi Q2 then beri tanda bahwa parameter tersebut dipilih oleh pengguna Black-box Testing [PUPL-AMDASH.K-060101]
Initial State (IS)
:
Username terinisialisasi.
Final State ( F S )
:
Pilihan parameter sesuai personalisasi pengguna
.
White-box Jesting
Path 1-2 [PUPL-AMDASH.K-0602011 Path 1-2-3 [PUPL-AMDASH.K-0602021
Uji Proses/FungsiupdatePassword [DPPL-AM0ASH.K-On Initial State (IS)
:
Username, password saat ini, dan password baru terinisialisasi.
Final State (FS)
:
Password baru pengguna termutakhirkan.
procedure o0ption::updatePassword($username, $oldPassword, $newpassword)
if terdapat hasil dari eksekusi Q1 then eksekusi Q2
Pembagian blok algoritma: Pa th
Code
1
procedure oOption::updatePassword($username, $oldPassword, SnewPassword) if terdapat hasil dari eksekusi Q1 then eksekusi Q2
2 3
Black-boxTesting [PUPL-AMDASH.K-070101] Initial State (IS)
:
Username, password saat ini, dan password baru terinisialisasi.
Final State (FS)
:
Password baru pengguna termutakhirkan.
White-boxTesting 8 8
Path 1-2 [PUPL-AMDASH.K-0702011 Path 1-2-3 [PUPL-AMDASH.K-0702021
Uji Proses/Fuizgsi updateDashboard [DPPL-AMDASH.K-081 Initial State (IS)
:
Username, parameter yang dipilih terinisialisasi.
Final State (FS)
:
Dashboard personalisasi parameter pengguna termutakhirkan.
procedure o0ption::updateDashboard($username, eksekusi Q1 eksekusi Q2
$id-param)
Pembagian blok algoritrna: Path
1 2 3
Code procedure oOption::updateDashboard($username, eksekusi Ql eksekusi Q2
$id-param)
Black-boxTesting [PUPL-AMi3ASH.K-080101] Initial State (IS)
:
Username, parameter yang dipilih terinisialisasi.
Final State (FS)
:
Dashboard personalisasi parameter pengguna termutakhirkan.
'
White-boxTesting
Path 1-2-3 [PUPL-AMDASH.K-0802011 Uji Proses/FurzgsiuserLogout [DPPL-AMDASH.K-091 Initial State (IS)
:
Final State (FS)
:
Seluruh informasi sementara pengguna berupa session/cookies terhapus.
procedure oUserLogout::logout~)
hapus seluruh session/cookies
Pembagian blok algoritma: Path 1
Code 'procedure ouserLogout::logout() hapus seluruh session/cookies
I
Black-box Testing [PUPL-AMDASH.K-0901011
Initial State (IS)
:
-
Final State (FS)
:
Seluruh informasi sementara pengguna berupa session/cookies terhapus.
White-box Testing
Path 1-2 [PUPL-AMDASH.K-0902011 Uji Modul Back-end
Initial State (IS)
:
Username dan password terinisialisasi.
Final State (FS)
:
Bila validasi masukan benar, informasi login termutakhirkan. Bila salah, kembali ke tampilan awal dengan pesan kesalahan.
procedure oAdminLogin::adminLogin($username, Spassword) if jumlah hasil eksekusi Q1 > 0 then Snow-login t informasi waktu saat ini eksekusi Q2 pindah ke halaman home else kembali ke halaman login tampilkan pesan kesalahan
Pembagian blok algoritma: Path
1
Code procedure oAdminLogin::adminLogin($username, Spassword) if jumlah hasil eksekusi Q1 > 0 then Snow-login t informasi waktu saat ini eksekusi Q2 pindah ke halaman home else kembali ke halaman login tampilkan pesan kesalahan
Initial State (IS)
:
Username dan password terinisialisasi.
Final State (FS)
:
Bila validasi masukan benar, informasi login termutakhirkan. Bila salah, kembali ke tampilan awal dengan pesan kesalahan.
White-box Testing
Path 1-2-3-4-5 [PUPL-AMDASH.K-100201]
Path 1-2-6-7-8 [PUPL-AMDASH.K-100202]
I n i t i a l S t a t e (IS)
:
-
Final S t a t e (FS)
:
Halaman home.
p r o c e d u r e oHome::showHome()
tampilkan halaman home
Pembagian blok algoritma: Path
Code
1
procedure oHome::showHome()
2
tampilkan halaman home
Black-boxTesting [PUPL-AMi3ASH.K-I101011 I n i t i a l S t a t e (IS)
:
-
Final . S t a t e (FS)
:
Halaman home.
White-boxTesting e
Path 1-2 [PUPL-Ak4DASH.K-110201]
Uji Proses/Fungsi showPassword [DPPL-AMDASH.K-121 I n i t i a l S t a t e (IS)
:
-
F i n a l S t a t e (FS)
:
Halaman password.
procedure oPassword::showPassword()
tampilkan halaman password
Pembagian blok algoritma: Path 1 2
I
Code procedure oPassword::showPassword~)
tampilkan halaman password
Black-boxTesting [PUPL-AMDASH.K-120101] I n i t i a l S t a t e (IS)
:
-
Final' S t a t e (FS)
:
Halaman password.
White-boxTesting
Path 1-2 [PUPL-AMDASH.K-120201]
Uji Proses/Fungsi updatePassword [DPPL-AMDASH.K-131 I n i t i a l S t a t e (IS)
:
Password saat ini dan password baru terinisialisasi.
F i n a l S t a t e (FS)
:
Password baru administrator termutakhirkan.
procedure oPassword::updatePassword($oldPassword, i f terdapat hasil dari eksekusi Q 1 then
.eksekusi Q2
$newpassword)
Pembagian blok algoritrna:
1
Path
Code procedure oPassword::updatePassword($oldPassword, $newpassword) if terdapat hasil dari eksekusi Q1 then eksekusi Q2
1 2 3
Black-boxTesting [PUPL-AMDASH.K-130101] Initial State (IS)
:
Password saat ini dan password baru terinisialisasi.
Final State (FS)
:
Password baru administrator termutakhirkan.
White-boxTesting
Path 1-2-3 [PUPL-AMDASH.K-130201] .UjiProses/Fungsishowuser [DPPL-AMDASH.K-141 Initial State (IS)
:
Final State (FS)
:
Daftar pengguna dan informasi login terakhir pengguna bersangkutan.
procedure oUser::showUser() for setiap hasil eksekusi Q1 tampilkan nama pengguna dan informasi login terakhir ke layar
Pembagian blok algoritma: Path
Code
1.
procedure oUser::showUser() for setiap hasil eksekusi Ql tampilkan nama pengguna dan informasi login terakhir ke layar
2 3
Black-boxTesting [PUPL-AMDASH.K-140101] Initialstate (IS)
:
-
Final State (FS)
:
Daftar pengguna dan informasi login terakhir pengguna bersangkutan.
White-boxTesting
Path 1-2 [PUPL-AMDASH.K-140201] Path 1-2-3 [PUPL-AMDASH.K-1402021 Uji Proses/Fui~gsiinsertuser [DPPL-AMDASH.K-151 Initial State (IS)
:
Username dan password terinisialisasi.
Final State (FS)
:
Tabeltbl-user termutakhirkan.
procedure oUser::insertUser($username, $logininfo t. waktu saat ini eksekusi Q1
Spassword)
Pembagian blok algoritma: Path
(
Code
p r o c e d u r e oUser::insertUser($username,
1 2 3
Spassword)
Slogin-info t waktu saat ini eksekusi Q1
Black-box Testing [PUPL-AMDASH.K-1501011 Initizl State Final S t a t e
(IS)
(FS)
:
Username dan password terinisialisasi.
:
Tabel tbl-user termutakhirkan.
White-box Testing
Path 1-2-3[PUPL-AMDASH.K-l50201] Uji Proses/Fungsi updateuser [DPPL-AMDASH.K-161 Initial State Final State
(IS)
(FS)
:
Username dan password terinisialisasi.
:
Tabel tbl-user terrnutakhirkan.
procedure oUser::updateUser($usernarne,
Spassword)
eksekusi Q1
Pembagian blok algoritma: Code
Path
p r o c e d u r e oUser::updateUser($username,
1 2
Spassword)
eksekusi Q1
Black-box Testing [PUPL-AMDASH.K-160101j Initial State Final S t a t e
(IS)
(FS)
:
Usernarne dan password terinisialisasi.
:
Tabel tbl-user termutakhirkan.
White-box Testing
Path 1-2[PUPL-AMDASH.K-160201] U j i Proses/Fungsi deleteuser [DPPL-AMDASH.K-171 I n i t i a l S t a t e (IS) Final State
(FS)
:
Username terinisialisasi.
:
Tabel tbl-user terrnutakhirkan.
procedure oUser::deleteUser($id-user)
eksekusi Q1
Pembagian blok algoritma: Path 1 2
1
Code p r o c e d u r e oUser::deleteUser($id-user)
eksekusi Q1
Black-box Testing [PUPL-AMDASH.K-170101] Initial State Final S t a t e
(IS)
(FS)
:
Username terinisialisasi.
:
Tabel tbl-user termutakhirkan.
White-box Testing
Path 1-2[PUPL-AMDASH.K-170201]
Initial State (IS)
:
-
Final State (FS)
:
Target parameter selama 12 bulan pada tahun tertentu.
procedure oTarget::showTarget() for setiap hasil eksekusi Q1 tampilkan nama kategori ke layar sebagai pilihan if parameter telah dipilih then $id t parameter yang dipilih else $id C pilih parameter yang pertama for setiap hasil eksekusi Q2 tampilkan nama dan unit pengukuran parameter bersangkutan $id-param identitas parameter bersangkutan if tahun telah dipilih then $year t tahun yang dipilih else $year C tahun ini for $i t 1 to 12 $month t $i for setiap hasil eksekusi Q3 tampilkan target untuk bulan pada tahun dari parameter
Pembagian blok algoritrna: Path
1 2 3 4
5
6 7 8
9
10
Code procedure 0Target::showTargetO for setiap hasil eksekusi Q1 tampilkan nama kategori ke layar sebagai pilihan
if parameter telah dipilih then $id C parameter yang dipilih else $id C pilih parameter yang pertama for setiap hasil eksekusi Q2 tampilkan nama dan unit pengukuran parameter bersangkutan $idparam t identitas parameter bersangkutan if tahun telah dipilih then $year t tahun yang dipilih else $year t tahun ini for $i t 1 to 12 $month t $i for setiap hasil eksekusi Q3 tampilkan target untuk bulan pada tahun dari parameter
Black-box Testing [PUPL-AMDASH.K-180101]
Initial State (IS)
:
-
Final State (FS)
:
Target parameter selama 12 bulan pada tahun tertentu.
White-box Testing
0
e a e 0
e 0
e e e e e
e
Path 1-2-3-4-5-8 [PUPL-AMDASH.K-180201] Path 1-2-3-4-5-8-9-10-1 1-12-15 [PUPL-AMDA3H.K-180202] Path 1-2-3-4-5-8-9-10-1 1-12-15-16-17 [PUPL-AMDASH.K-180203] Path 1-2-3-4-5-8-9-10-1 1-12-15-16-17-1 8 [PUPL-AMDASH.K-180204] Path 1-2-3-4-5-8-9-10-11-13-14-15 [PUPL-AMDASH.K-180205] Path 1-2-3-4-5-8-9-10-1 1-13-14-15-16-17 [PUPL-AMDASH.K-1802061 Path 1-2-3-4-5-8-9-10-1 1-13-14-15-16-17-18 [PUPL-AMDASH.K-1802071 Path 1-2-3-4-6-7-8 [PUPL-AMDASH.K-1802081 Path 1-2-3-4-6-7-8-9-1 0-1 1-12-15 [PUPL-AMDASH.K-l80209] Path 1-2-3-4-6-7-8-9-10-1 1-12-15-16-17 [PUPL-AMDASH.K-180210] Path 1-2-3-4-6-7-8-9-10-1 1-12-15-16-17-18 [PUPL-AMDASH.K-18021 I ] Path 1-2-3-4-6-7-8-9-10-11-13-14-15 [PUPL-AMDASH.K-180212] Path 1-2-3-4-6-7-8-9-10-11-13-14-15-16-17 [PUPL-AMDASH.K-1802131 Path 1-2-3-4-6-7-8-9-10-11-13-14-15-16-17-18 [PUPL-AMDASH.K-1802141 Path 1-2-4-5-8 [PUPL-AMDASH.K-180215] Path 1-2-4-5-8-9-10-1 1-12-15 [PUPL-AMDASH.K-I 802161 Path 1-2-4-5-8-9-10-1 1-12-15-16-17 [PUPL-AMDASH.K-180217) Path 1-2-4-5-8-9-10-1 1-12-15-16-17-18 [PUPL-AMDASH.K-180218] Path 1-2-4-5-8-9-10-11-13-14-15 [PUPL-AMDASH.K-180219] Path 1-2-4-5-8-9-10-1 1-13-14-15-16-17 [PUPL-AMDASH.K-180220] Path 1-2-4-5-8-9-10-11-13-14-15-16-17-18 [PUPL-AMDASH.K-180221] Path 1-2-4-6-7-8 [PUPL;AMDASH.K-180222] Path 1-2-4-6-7-8-9-10-1 1-12-15 [PUPL-AMDASH.K-1802231 Path 1-2-4-6-7-8-9-10-1 1-12-15-16-17 [PUPL-AMDASH.K-1802241 Path 1-2-4-6-7-8-9-10-11-12-15-16-17-18 [PUPL-AMDASH.K-1802251 Path 1-2-4-6-7-8-9-10-1 1-13-14-15 [PUPL-AMDASH.K-1802261 Path 1-2-4-6-7-8-9-10-11-13-14-15-16-17 [PUPL-AMDASH.K-1802271 Path 1-2-4-6-7-8-9-10-11-13-14-15-16-17-18 [PUPL-AMDASH.K-180228]
Initial State (IS)
:
Identitas parameter, tahun, dan besar target terinisialisasi.
Final State (FS)
:
Tabel tbl-monthtarget termutakhirkan.
procedure oTarget::saveTarget($id-param, for $i 1 to 12 if $i = 1 then eksekusi Q1 eksekusi Q2
+'
$year, $target)
Pembagian blok algoritrna: Path
1
Code
procedure oTarget::saveTarget($id-param,
$year, Starget)
f o r $i t 1 t o 12 if $i = 1 then
2 3 4 5
eksekusi Q1 eksekusi Q2
Black-box Testing [PUPL-AMDASH.K-190101] I n i t i a l S t a t e (IS)
:
Identitas parameter, tahun, dan besar target terinisialisasi.
Final S t a t e (FS)
:
Tabel tbl-monthtarget termutakhirkan.
White-box Testing
*
Path 1-2 [PUPL-AMDASH.K-l90201] Path 1-2-3-5 [PUPL-AMDASH.K-I902021 Path 1-2-3-4-5 [PUPL-AMDASH.K-1902031
Uji Proses/Fungsi adminLogout [DPPL-AMDASH.K-201 I n i t i a l S t a t e (IS)
:
-
Final S t a t e (FS)
:
Seluruh informasi sementara administrator berupa session/cookies terhapus.
procedure oAdminLogout::logout~)
hapus seluruh session/cookies
Pembagian blok algoritrna: Path
I
2.
I
Code procedure oAdminLogout::logout~)
hapus seluruh session/cookies
Black-box Testing [PUPL-AMDASH.K-200101] I n i t i a l S t a t e (IS)
:
-
Final S t a t e (FS)
:
Seluruh informasi sementara administrator berupa session/cookies terhapus.
White-box Testing e
Path 1-2 [PUPL-AMDASH.K-2002011
Snapshot AMDASH
Gambar 82. Modul Frontend - Login
-.
-
--
"a:
1 .
u
" "
....
2 - - ,
Gambar 83. Modul Frontend - Dashboard
Gambar 84. Modul Frontend -Control Panel
Gambar 85. Modul Frontend - Option
iit
Gambar 86:Modul Baekend -Login
Gambar 87. Modul Baekend -Home
Gambar 88. Modul Backend -Password
Gambar 89. Bacicend - Userlist
-
Gambar 90. Modul Backend Target Setting
