ENTERPRISE ARCHITECTURE

Sebelum kita membahas perbedaan Enterprise Architecture (EA) framework dari Zachman , TOGAF , FEA , dan Gartner. Alangkah baiknya kita mengetahui pengertian dari EA (Enterprise Achitecture).

Apa sih Enterprice Architecture (EA) ?

Pengertian dari kata Enterprise adalah gambaran bisnis pada suatu organisasi dalam bentuk yang kompleks, gambaran ini memiliki jangkauan yang sangat luas meliputi manusia (pelanggan, staff dan kontraktor), proses dan asset yang digunakan untuk mengembangkan dan menghasilkan produk-produk dan service-service, data dan informasi yang disimpan untuk digunakan dalam bisnis, dan mekanisme untuk menyediakan komunikasi dan sekuriti. 

Sedangkan Architecture ternyata dalam bidang bangunan dan konstruksi, istilah arsitektur sering bersifat ambiguity juga. Arsitektur dapat berarti (1) seni dan pengetahuan tentang mendesain sebuah lingkungan bangunan, atau juga (2) produk dari sebuah cetak biru (blueprint) sebuah bangunan yang merupakan produk dari sebuah desain dan prinsip dasar yang digunakan untuk membuat style bangunan tersebut, misal sebuah ‘gothic architecture’. Sebuah kerangka berfikir serupa dibutuhkan juga pada saat mendesain sebuah enterprise. Untuk membuat gambaran tentang struktur organisasi, proses bisnis organisasi, aplikasi sistem informasi, dan infrastruktur teknologi informasi yang mendukung maka kita perlu menyatakannya  dengan menggunakan domain dan aspek yang berbeda-beda, begitu juga dengan relasi yang terjadi.

Jadi Enterprise Architecture adalah kumpulan prinsip, metode dan model yang bersifat masuk akal yang digunakan untuk mendesain dan merealisasikan sebuah struktur organisasi enterprise, proses bisnis, sistem informasi dan infrastrukturnya.

Sedangkan Framework adalah kumpulan dari fungsi fungsi/ prosedur-prosedur dan class-class untuk tujuan tertentu yang sudah siap digunakan. Sehingga bisa mempermudah mempercepat pekerjaan seorang programmer, tanpa harus membuat fungsi atau class dari awal.

Lalu di bawah ini kita akan mempelajari perbedaan-perbedaan dari zachman.TOGAF,fea dan gartner

Zahcman Framework 

Pengertian Zachman : Zachman Framework merupakan suatu alat bantu yang dikembangkan untuk memotret arsitektur organisasi dari berbagai sudut pandang dan aspek, sehingga didapatkan gambaran organisasi secara utuh. Zachman framework, dikeluarkan oleh Zachman Institut for Framework Advancement  sebagai hasil pemikiran dari John Zachman. Framework ini merupakan framework arsitektural yang paling banyak dikenal dan diadaptasi dan memberikan gambaran yang lengkap dan menetapkan nama yang unik untuk setiap sel dalam framework.

           Zachman Framework merupakan logika terstruktur untuk pengklasifikasian dan pengorganisasian tipe-tipe dokumen, rancangan atau model yang merepresentasikan sebuah perusahaan. Zachman Framework bukan metodologi untuk mengembangkan suatu arsitekturenterprise. Zachman Framework bersifat kategorisasi artefak  Enterprise Architecture. Zachman Framework hanya berupa thingking tool yang membantu arsitek dan manajer mengisolasikanmasalah dan mengatur apa saja yang perlu diurus.

           Pengembangan system dalam Zachman Framework hampir sama dengan yang lain tetapi lebih terorganisir:

    1  .   Strategi - Perencanaan dari suatu usaha pengembangan sistem keseluruhan organisasi.

    2.   Analisa - Definisi yang terperinci tentang persyaratan untuk area tertentu dari bisnis tersebut.

   3.  Rancangan - Penerapan teknologi yang spesifik [bagi/kepada] persyaratan menggambarkan selama analisa.

    4.   Konstruksi - Konstruksi yang nyata dari sistem tersebut.

   5.   Dokumentasi - Persiapan dari manual pemakai, pedoman, dan lain lain menguraikan sistem tersebut.

  6.   Transisi - Implementasi dari sistem, agar supaya menjadi bagian dari infrastruktur organisasi tersebut.

  7.   Produksi - pengecekan berkelanjutan dari sistem, untuk memastikan bahwa sistem tersebut memenuhi kebutuhan dari organisasi.

Kelebihan dan Kekurangan Zachman Framework

Kelebihan dari Zachman Framework adalah sebagai berikut:

  1.   Zachman Framework merupakan standar secara de-facto untuk mengklasifikasikan artefak arsitektur Enterprise.

     2.   Struktur logikal untuk analisis dan presentasi artefak dari suatu perspektif manajemen.

    3.   Zachman Framework menggambarkan secara parallel baik dari sisi enjinering yang sudah sangat dimengerti maupun paradigma konstruksi

    4.   Zachman Framework dikenal secara luas sebagai tool manajemen untuk memeriksa kelengkapan arsitektur dan maturity level

Sedangkan kekurangan dari Zachman Framework antara lain:

   1.   Tidak ada proses untuk tahap implementasi.

   2.   Sulit untuk diimplementasikan secara keseluruhan.

   3.   Tidak ada contoh maupun ceklis yang siap secara utuh.

   4.   Perluasan coverage sel-sel tidak jelas

TOGAF 

Kepanjangan dari TOGAF (The Open Group Architecture Framework) sudah mencerminkan apa itu TOGAF, Framework (Enterprise) Architecture dari The Open Group. Sejarah framework TOGAF hampir sepanjang sejarah topik Enterprise Architecture itu sendiri saat pertama kali Arsitektur Sistem Informasi diperkenalkan oleh Zachman yang selanjutnya EA lebih banyak dikembangkan pada lingkungan lembaga Federal Amerika Serikat. Saat ini TOGAF sudah mencapai versi 9.1.

Sebagai sebuah program yang dilakukan secara berkelanjutan dalam sebuah organisasi yang melakukan inisiatif Enterprise Architecture, TOGAF memiliki banyak sekali terminologinya sendiri yang dirangkai dalam sebuah kesatuan metodologi. Dalam TOGAF terdapat 6 area utama dimana ada 1 area yang seakan menutupi seluruh area lainnya karena menjadi bagian yang esensial pada TOGAF yaitu Architecture Development Method (ADM).

Buku dan materi publikasi TOGAF dari The Open Group sendiri merangkai dengan sangat baik area-area ini sekalipun masih ditemukan banyak sekali area yang sulit dibayangkan secara konkrit karena TOGAF tidak membahas secara mendetail deliverable yang diharapkan dari setiap organisasi.

Ketika suatu organisasi menerapkan Enterprise Architecture, maka EA akan menjadi sebuah program yang menjelaskan keterkaitan antara bisnis, aplikasi, data hingga teknologi yang dijalankan secara berkesinambungan. Sekalipun EA dapat digunakan sebagai salah satu alat analisis dalam validasi dan justifikasi inisiatif, namun hal tersebut hanyalah bagian dari EA. Menurut kami, EA dapat lebih efektif jika digunakan sebagai salah satu metode pengelolaan knowledge perusahaan.

Kelebihan dan Kekurangan

      Kelebihan Togaf

§  Sifatnya yang fleksibel dan bersifat open source.

§  Sistematis

§  Focus pada siklus implementasi (ADM) dan proses

§  Kaya akan area teknis arsitektur

§  Recource base menyediakan banyak material referensi

§  Karena melibatkan banyak pihak terutama industri, di TOGAF banyak memberikan best practice atau kejadian riil di dunia nyata

       Kekurangan Togaf

§  Tidak ada templates standart untuk seluruh domain (misalnya untuk membuat blok diagram)

§  Tidak ada artefak yang dapat digunakan ulang (ready made)

FEA (Federal Enterprise Architecture)

Ketika ditanya apa arsitektur enterprise, praktisi FEA dapat memberikan jawaban yang sah: "basis informasi strategis yang mendefinisikan misi, informasi yang diperlukan untuk melakukan misi, dan teknologi yang diperlukan untuk menjalankan misi." Inilah definisi yang digunakan. oleh pemerintah federal Amerika Serikat, yang merupakan penghasut utama, pelaksana, dan pendukung proyek FEA.

FEA muncul sebagai tanggapan atas undang-undang, Clinger-Cohen Act of 1994 (secara resmi merupakan Undang-Undang Reformasi Manajemen Teknologi Informasi), yang menginstruksikan badan-badan federal untuk mengembangkan rencana induk untuk mengintegrasikan teknologi baru, mengelola akuisisi TI, dan mengukur dan melaporkan kinerja. Versi pertama FEA (yang kemudian disebut FEAF, dengan kata Framework di akhir) dirilis pada tahun 1999. Telah mengalami modifikasi dan perluasan sejak saat itu. Sebagian besar potongan utama tersedia hanya dalam beberapa tahun terakhir.

Mengingat keragaman keprihatinan yang ditangani oleh badan-badan federal dan banyaknya tingkat skala di mana pemerintah federal bekerja, FEA besar, kompleks, dan berlapis-lapis. Ini sebenarnya lebih merupakan kumpulan prinsip manajemen yang dinyatakan dalam istilah TI daripada taksonomi atau metodologi formal, meskipun mengandung beberapa dari keduanya. Seperti yang ditulis oleh Roger Sessions dalam bukunya Simple Architectures for Complex Enterprises, "FEA dapat dipandang sebagai metodologi untuk menciptakan arsitektur enterprise atau hasil penerapan proses tersebut ke perusahaan tertentu - yaitu Pemerintah A.S. . . . Ini mencakup semua yang diperlukan untuk membangun arsitektur enterprise agar mungkin organisasi yang paling kompleks di bumi. "Prinsip dan metodologi yang mengandung FEA dapat diterapkan di luar pemerintah federal, karena masalah alamat FEA umum terjadi pada organisasi hierarkis yang beragam dan beragam.

Nilai FEA

Bahkan dari tur singkat sorotan FEA ini, ada kemungkinan untuk melihat beberapa masalah yang dihadapi oleh FEA dan pendekatan yang telah dipilihnya. Di antara keprihatinan utamanya tampaknya:

● Menyatukan beragam unsur penyusun

● Menjaga beberapa tingkat sejajar

● Menangani hubungan kompleks dengan beragam unsur

● Menggunakan pengukuran dan pelaporan untuk meningkatkan akuntabilitas

Model Referensi

Kantor Manajemen Program FEA menyarankan agar "kerangka kerja untuk menggambarkan elemen penting FEA dalam cara yang umum dan konsisten" terletak pada lima model referensi FEA, masing-masing untuk Kinerja, Bisnis, Komponen, Teknologi, dan Data (Gambar 2). 

., 

Bersama-sama, model referensi "rangkaian model referensi yang saling terkait 'ini dirancang untuk memfasilitasi analisis lintas instansi dan identifikasi investasi duplikatif, kesenjangan, dan peluang untuk kolaborasi di dalam dan di seluruh lembaga" (FEA Consolidated Reference Manual). Pada tingkat yang paling mendasar, model referensi membentuk kosa kata umum untuk mempromosikan komunikasi dan kerja sama. Secara khusus:

● Model Referensi Kinerja (Performance Reference Model / PRM) menyediakan cara standar untuk mengukur kinerja dan menentukan investasi TI mana yang menghasilkan hasil terbaik. Tujuannya adalah peningkatan alokasi sumber daya dan identifikasi "peluang peningkatan kinerja yang mencakup struktur organisasi tradisional dan

batas. "

● Model Referensi Bisnis (BRM) mengatur operasi pemerintah dalam hal fungsi ("Penanggulangan Bencana") dan cara pengiriman ("Transfer ke Negara Bagian dan Pemerintah Daerah") daripada oleh departemen agensi atau administratif. Ini adalah tindakan melawan peraturan "stovepipe" pemerintah yang telah lama ada.

● Model Referensi Komponen Servis (SRM) adalah tampilan tingkat TI horizontal yang menyediakan landasan umum untuk menggunakan kembali aplikasi, kemampuan aplikasi, komponen, dan layanan bisnis. Tingkat tertinggi di sini adalah domain layanan seperti "Layanan Pelanggan", "Proses Otomasi", dan "Layanan Kantor Kembali" yang sepenuhnya bebas dari fungsi bisnis tertentu.

● Model Referensi Teknis (TRM) adalah kerangka kerja super (ada banyak model teknis tingkat agensi) untuk mengkategorikan dengan cara seragam standar dan teknologi yang digunakan oleh pemerintah, dengan maksud untuk mendorong penggunaan kembali, interoperabilitas, dan ekonomi skala. Kategori yang khas di sini adalah "Layanan/seragam" sejauh ini adalah yang terbesar dari Model Referensi.

GARTNER

Enterprise Architecture (EA) Model Proses yang dijelaskan dalam penelitian ini merupakan fondasi dimana penelitian EA Gartner Arsitek (dan lainnya) cenderung berpikir secara visual, jadi ini memberikan dasar yang visual untuk berpikir tentang proses dimana program EA berhasil diciptakan dan dipelihara. “The Enterprise Architecture (EA) Process Model described in this research represents the foundation on which Gartner's EA research is described. Architects (and many others) tend to think visually, so this provides a visual basis for thinking about the process by which successful EA programs are created and maintained

a. Sudut Pandang EA Gartner

Gartner framework Enterprise Architecture juga menjelaskan empat sudut pandang primer  arsitektur: Bisnis, Informasi, Teknologi dan Solusi. Setiap sudut pandang mewakili konsentrasi yang relevan dengan serangkaian stakeholder. Secara kasar, pada Sudut pandang Bisnis mewakili konsentrasiEA, sudut pandang informasi mewakili arus informasi dan konsentrasi pemodelan, sudut pandang teknologi mewakili pelaksanaan teknis dan konsentrasi operasional arsitek teknologi, sudut pandang solusi berhubungan langsung dengan masalah penting dalam arsitektur.

Sebuah dokumen pendamping memperkenalkan Gartner EA Framework, yang mengartikulasikan hubungan antara arsitektur bisnis perusahaan, arsitektur informasi perusahaa dan EA teknis (ETA) dan sintesis dengan solusi EA (ESA). Meskipun Model Proses EA dan Kerangka EA memiliki kelebihan sendiri dan nilai, mereka dapat digunakan bersamaan. Model EA Gartner merupakan pelengkap yang berharga serta kredibel, kerangka EA vendor-netral. Jadi, jika suatu organisasi telah memilih untuk mengadopsi EA yang berbeda kerangka kerja, model diperkenalkan di sini masih akan menambah nilai yang signifikan dengan disiplin arsitektur. Sebuah framework tidak menjawab pertanyaan tentang apa yang akan diproduksi kapan dan  bagaimana itu semua terkait; ini adalah isu yang dibahas oleh model proses. Selama beberapa tahun ke depan, Model Proses EA Gartner akan tetap stabil. Namun, praktek-praktek terbaik ditemukan di antara elemen rinci dari Model Proses EA akan terus berkembang, terutama di area pemodelan masa depan negara.

3. METODOLOGI

3.1. Magic Quadrant

Magic Quadrant adalah alat untuk memahami vendor atau posisi dan ekspektasipenyedia layanan. Analis Gartner menggunakan beberapa kriteria yang obyektif dan subyektif untuk mengevaluasi pemasok individu, disajikan pada dua sumbu: Kemampuan untuk menjalankan dan kelengkapan visi parameter. Ini, dinyatakan dalam empat kuadran: Leaders, Challengers, Visioner dan Niche Players.Hasil analisis menunjukkan kemampuan vendor untuk menyediakan layanan dalam kaitannya dengan persaingan, dan apa yang diharapkan untuk masa depan. Sebuah magic quadrant dapat dilihat sebagai asumsi perencanaan strategis visual. Asumsi strategis menunjukan prediksi yang berkualitas tentang perkembangan industri masa depan.

Gambar 4 : Magic Quadrant

3.2. Hype Cycle

Hype Cycle menawarkan snapshot dari kematangan relatif teknologi, metodologi IT dan manajemen disiplin

Kelima fase Siklus Hype

Gartner menulis bahwa setiap Siklus Hype ditandai

oleh lima tahap berikut :

1. " Technology Trigger " : tahap pertama dari Hype Cycle adalah " Technology Trigger " atau

terobosan , peluncuran produk atau event lainnya yang penekanan yang signifikan dan interest.

2. "Peak of Inflated Expectations" : pada fase berikutnya , dalam fase berikutnya, hiruk-pikuk

publisitas biasanya menghasilkan semangat dan harapan yang tidak realistis .

3. "Trough of Disillusionment" : teknologi memasuki " palung kekecewaan " karena

mereka gagal untuk memenuhi harapan dan menjadi ketinggalan zaman .

4. "Slope of Enlightenment " : meskipun tekanan telah berhenti mencakup teknologi , beberapa

perusahaan terus melalui " kemiringan pencerahan " dan percobaan untuk memahami manfaat dan aplikasi praktis dari teknologi .

5. " Plateau of Productivity " : teknologi mencapai " produktivitas tertinggi " manfaatnya menjadikan banyak dipraktekkan dan dapat diterima. Teknologi ini menjadi semakin stabil dan berkembang pada generasi kedua dan ketiga

Perbedaan dan Pengertian dari Beberapa Model Pengembangan Perangkat Lunak

Hai guys!!! SEPUTAR TEKNOLOGI hari ini akan berbagi info lagi. Kali ini kita akan membahas Software Development (Pengembangan Perangkat Lunak) yuk guys langsung kita simak di bawah ini.😁😁

Agile Software Development Methodology

Untuk pembuatan atau pengembangan suatu perangkat lunak terdapat beberapa hal yang harus di perhatikan, mulai dari sumber daya manusia (resources) yang menangani proyek tersebut, sampai dengan metode apa yang harus diterapkan dalam proses pengembangan perangkat lunaknya. Terdapat banyak metode dalam proses pengembangan perangkat lunak salah satunya yaitu metode Agile Sofware Development.

Agile Software development adalah salah satu metodelogi dalam pengembangan sebuah perangkat lunak (software). Kata Agile berarti bersifat cepat, ringan, bebas bergerak, waspada. Kata ini digunakan sebagai kata yang menggambarkan konsep model proses yang berbeda dari konsep model-model proses yang sudah ada. Konsep Agile software development dicetuskan oleh Kent Beck dan 16 rekannya dengan menyatakan bahwa Agile Software Development adalah cara membangun software dengan melakukannya dan membantu orang lain membangunnya sekaligus.

Dalam Agile Software Development interaksi dan personel lebih penting dari pada proses dan alat, software yang berfungsi lebih penting daripada dokumentasi yang lengkap, kolaborasi dengan klient lebih penting daripada negosiasi kontrak, dan sikap tanggap terhadap perubahan lebih penting daripada mengikuti rencana. Namun demikian, sama seperti model proses yang lain, agile software development memiliki kelebihan dan tidak cocok untuk semua jenis proyek, produk, orang dan situasi. Agile Software Development memungkinkan model proses yang toleransi terhadap perubahan kebutuhan sehingga perubahan dapat cepat ditanggapi. Namun di sisi lain menyebabkan produktiitas menurun.

Salah satu cirri dari Agile Software Development adalah tim yang tanggap terhadap perubahan. Mengapa? Karena perubahan adalah hal yang utama dalam membangun software: perubahan kebutuhan software, perubahan anggota tim, perubahan teknologi dll. Selain itu Agile Software Development juga melihat pentingnya komunikasi antara anggota tim, antara orang-orang teknis dan businessmen, anatara developer dan managernya. Cirri lain adalah klien menjadi bagian dari tim pembangun software. Ciri-ciri ini didukung oleh 12 prinsip yang diterapkan oleh Agile Alliance. Menurut Agile Alliance, 12 prinsip ini adalah bagi mereka yang ingin berhasil dalam penerapan Agile Software Development :

–          Kepuasan klien adalah prioritas utama dengan menghasilkan produk lebih awal dan terus menerus

–          Menerima perubahan kebutuhan, sekalipun diakhir pengembangan

–          Penyerahan hasil/software dalam hitungan waktu dua minggi sampai dua bulan

–          Bagian bisnis dan pembangun kerja sama tiap hari selama proyek berlangsung

–          Membangun proyek dilingkungan orang-orang yang bermotivasi tinggi yang bekerja dalam lingkungan yang mendukung dan yang dipercaya untuk dapat menyelesaikan proyek.

–          Komunikasi dengan berhadapan langsung adalah komunikasi yang efektis dan efisien

–          Software yang berfungsi adalah ukuran utama dari kemajuan proyek

–          Dukungan yang stabil dari sponsor, pembangun, dan pengguna diperlukan untuk menjaga perkembangan yang berkesinambungan.

–          Perhatian kepada kehebatan teknis dan desain yang bagus meningkatkan sifat agile

–          Kesederhanaan penting

–          Arsitek. Kebutuhan dan desain yang bagus muncul dari tim yang mengatur dirinya sendiri

–          Secara periodic tim evaluasi diri dan mencari cara untuk lebih efektif dan segera melakukannya.

Kedua belas prinsip tersebut menjadi suatu dasar bagi model-model proses yang punya sifat agile. Dengan prinsip-prinsip tersebut agile process model berusaha untuk menyiasati 3 asumsi penting tentang proyek software pada umumnya :

–          Kebutuhann software sulit diprediksi dari awal dan selalu akan berubah. Selain itu, prioritas klien juga sering berjalannya proyek.

–          Desain dan pembangunan sering tumpang tindih. Sulit diperkirakan seberapa jauh desain yang diperlukan sebelum pembangunan

–          Analisis, desain, pembangunan dan testing tidak dapat diperkirakan seperti yang diinginkan.

Beberapa jenis proses peomodelan yang termasuk kedalam metode Agile Software Development : Extreme Programming (XP), Adaptif Software Development (ASD), Dynamic System Development Method (DSDM), Scrum, Crystal, Feature Driven Development (FDD), Agile Modeling (AM).

Rapid Application Development 

Rapid Application Development (RAD) adalah strategi siklus hidup yang ditujukan untuk menyediakan pengembangan yang jauh lebih cepat dan mendapatkan hasil dengan kualitas yang lebih baik dibandingkan dengan hasil yang dicapai melalui siklus tradisional (McLeod, 2002). RAD merupakan gabungan dari bermacam-macam teknik terstruktur dengan teknik prototyping dan teknik pengembangan joint application untuk mempercepat pengembangan sistem/aplikasi (Bentley, 2004). Dari definisi-definisi konsep RAD ini, dapat dilihat bahwa pengembangan aplikasi dengan menggunakan metode RAD ini dapat dilakukan dalam waktu yang relatif lebih cepat.

Pemaparan konsep yang lebih spesifik lagi dijelaskan oleh Pressman (2005) dalam bukunya, “Software Engineering: A Practition’s Approach”. Ia mengatakan bahwa RAD adalah proses model perangkat lunak inkremental yang menekankan siklus pengembangan yang singkat. Model RAD adalah sebuah adaptasi “kecepatan tinggi” dari model waterfall, di mana perkembangan pesat dicapai dengan menggunakan pendekatan konstruksi berbasis komponen. Jika tiap-tiap kebutuhan dan batasan ruang lingkup projek telah diketahui dengan baik, proses RAD memungkinkan tim pengembang untuk menciptakan sebuah “sistem yang berfungsi penuh” dalam jangka waktu yang sangat singkat. Dari penjelasan Pressman (2012) ini, satu perhatian khusus mengenai metodologi RAD dapat diketahui, yakni implementasi metode RAD akan berjalan maksimal jika pengembang aplikasi telah merumuskan kebutuhan dan ruang lingkup pengembangan aplikasi dengan baik.

Sedangkan menurut Kendall (2010), RAD adalah suatu pendekatan berorientasi objek terhadap pengembangan sistem yang mencakup suatu metode pengembangan serta perangkat-perangkat lunak. RAD bertujuan mempersingkat waktu yang biasanya diperlukan dalam siklus hidup pengembangan sistem tradisional antara perancangan dan penerapan suatu sistem informasi. Pada akhirnya, RAD sama-sama berusaha memenuhi syarat-syarat bisnis yang berubah secara cepat.

Fase dan Tahapan Pengembangan Aplikasi

Menurut Kendall (2010), terdapat tiga fase dalam RAD yang melibatkan penganalisis dan pengguna dalam tahap penilaian, perancangan, dan penerapan. Adapun ketiga fase tersebut adalah requirements planning (perencanaan syarat-syarat), RAD design workshop (workshop desain RAD), dan implementation (implementasi). Sesuai dengan metodologi RAD menurut Kendall (2010), berikut ini adalah tahap-tahap pengembangan aplikasi dari tiap-tiap fase pengembangan aplikasi.

1)      Requirements Planning (Perencanaan Syarat-Syarat)

Dalam fase ini, pengguna dan penganalisis bertemu untuk mengidentifikasikan tujuan-tujuan aplikasi atau sistem serta untuk megidentifikasikan syarat-syarat informasi yang ditimbulkan dari tujuan-tujuan tersebut. Orientasi dalam fase ini adalah menyelesaikan masalah-masalah perusahaan. Meskipun teknologi informasi dan sistem bisa mengarahkan sebagian dari sistem yang diajukan, fokusnya akan selalu tetap pada upaya pencapaian tujuan-tujuan perusahaan (Kendall, 2010).

2)      RAD Design Workshop (Workshop Desain RAD)

Fase ini adalah fase untuk merancang dan memperbaiki yang bisa digambarkan sebagai workshop. Penganalisis dan dan pemrogram dapat bekerja membangun dan menunjukkan representasi visual desain dan pola kerja kepada pengguna. Workshop desain ini dapat dilakukan selama beberapa hari tergantung dari ukuran aplikasi yang akan dikembangkan. Selama workshop desain RAD, pengguna merespon prototipe yang ada dan penganalisis memperbaiki modul-modul yang dirancang berdasarkan respon pengguna. Apabila sorang pengembangnya merupakan pengembang atau pengguna yang berpengalaman, Kendall menilai bahwa usaha kreatif ini dapat mendorong pengembangan sampai pada tingkat terakselerasi (Kendall, 2010).

3)      Implementation (Implementasi)

Pada fase implementasi ini, penganalisis bekerja dengan para pengguna secara intens selama workshop dan merancang aspek-aspek bisnis dan nonteknis perusahaan. Segera setelah aspek-aspek ini disetujui dan sistem-sistem dibangun dan disaring, sistem-sistem baru atau bagian dari sistem diujicoba dan kemudian diperkenalkan kepada organisasi (Kendall, 2010).

Kelebihan dan Kekurangan RAD

Metode pengembangan sistem RAD relatif lebih sesuai dengan rencana pengembangan aplikasi yang tidak memiliki ruang lingkup yang besar dan akan dikembangkan oleh tim yang kecil. Namun, RAD pun memiliki kelebihan dan kekurangannya sebagai sebuah metodoligi pengembangan aplikasi. Berikut ini adalah kelebihan metodologi RAD menurut Marakas (2006):

1.    Penghematan waktu dalam keseluruhan fase projek dapat dicapai.

2.    RAD mengurangi seluruh kebutuhan yang berkaitan dengan biaya projek dan sumberdaya manusia.

3.    RAD sangat membantu pengembangan aplikasi yang berfokus pada waktu penyelesaian projek.

4.    Perubahan desain sistem dapat lebih berpengaruh dengan cepat dibandingkan dengan pendekatan SDLC tradisional.

5.    Sudut pandang user disajikan dalam sistem akhir baik melalui fungsi-fungsi sistem atau antarmuka pengguna.

6.    RAD menciptakan rasa kepemilikan yang kuat di antara seluruh pemangku kebijakan projek.

Sedangkan, mengacu pada pendapat Kendall (2010), maka dapat diketahui bahwa kekurangan penerapan metode RAD adalah sebagai berikut:

1.    Dengan metode RAD, penganalisis berusaha mepercepat projek dengan terburu-buru.

2.    Kelemahan yang berkaitan dengan waktu dan perhatian terhadap detail. Aplikasi dapat diselesaikan secara lebih cepat, tetapi tidak mampu mengarahkan penekanan terhadap permasalahan-permasalahan perusahaan yang seharusnya diarahkan.

3.    RAD menyulitkan programmer yang tidak berpengalaman menggunakan prangkat ini di mana programmer dan analyst dituntut untuk menguasai kemampuan-kemampuan baru sementara pada saat yang sama mereka harus bekerja mengembangkan sistem.

b   

     Dynamic System Development Model Methodology 

Metode Pengembangan Sistem Dinamis (DSDM) mengasumsikan bahwa semua langkah sebelumnya dapat ditinjau kembali sebagai bagian dari pendekatan iteratifnya. Karena itu, langkah saat ini perlu diselesaikan hanya cukup untuk pindah ke langkah selanjutnya, karena bisa selesai di iterasi selanjutnya. Premis ini adalah bahwa persyaratan bisnis mungkin akan berubah pula karena pemahaman meningkat, jadi pekerjaan lebih lanjut pasti akan sia-sia.

Menurut pendekatan ini, waktu dianggap sebagai kendala, yaitu waktu tetap, sumber daya tetap sementara persyaratan diizinkan untuk berubah. Ini tidak mengikuti asumsi mendasar untuk membuat sistem yang sempurna untuk pertama kalinya, namun memberikan 80% sistem yang diinginkan dan berguna dalam 20% dari total waktu pengembangan. Pendekatan ini terbukti sangat berguna dalam batasan waktu dan berbagai persyaratan.

Sekarang mari kita lihat semua langkah DSDM secara singkat 

1-Studi Kelayakan

Selama tahap proyek ini, kelayakan proyek untuk penggunaan DSDM diperiksa.Prasyarat untuk penggunaan DSDM ditangani dengan menjawab pertanyaan seperti: 'Dapatkah proyek ini memenuhi kebutuhan bisnis yang dibutuhkan?', 'Apakah proyek ini sesuai untuk penggunaan DSDM?' dan 'Apa saja risiko terpenting yang terlibat?'. Teknik yang paling penting yang digunakan dalam fase ini adalah Lokakarya .

Kiriman untuk tahap ini adalah Laporan Kelayakan dan Prototipe Kelayakan yang membahas kelayakan proyek yang sedang ditangani. Ini diperluas dengan Rencana Garis Besar Global untuk keseluruhan proyek dan Log Risiko yang mengidentifikasi risiko terpenting proyek.

Studi Bisnis

Studi bisnis memperluas studi kelayakan . Setelah proyek dianggap layak untuk penggunaan DSDM, tahap ini menguji proses bisnis yang dipengaruhi, kelompok pengguna yang terlibat dan kebutuhan dan keinginan masing-masing. Sekali lagi lokakarya adalah salah satu teknik yang paling berharga, lokakarya di mana berbagai pemangku kepentingan berkumpul untuk mendiskusikan sistem yang diusulkan. Informasi dari sesi ini digabungkan ke dalam daftar persyaratan . Properti penting dari daftar persyaratan adalah fakta bahwa persyaratannya (dapat diprioritaskan ) . Persyaratan ini diprioritaskan dengan menggunakan pendekatan MoSCoW . Berdasarkan prioritisasi ini, sebuah rencana pembangunan dibangun sebagai pedoman untuk sisa proyek.

Teknik proyek penting yang digunakan dalam pengembangan rencana ini adalah timeboxing . Teknik ini sangat penting dalam mewujudkan tujuan DSDM, yaitu tepat waktu dan sesuai anggaran, menjamin kualitas yang diinginkan. Arsitektur sistem adalah bantuan lain untuk memandu pengembangan IS. Kiriman untuk tahap ini adalah definisi area bisnis yang menggambarkan konteks proyek di dalam perusahaan, definisi arsitektur sistem yang menyediakan arsitektur global awal IS yang sedang dikembangkan bersama dengan rencana pengembangan yang menguraikan langkah terpenting dalam proses pembangunan. Di dasar dua dokumen terakhir ini ada daftar persyaratan yang diprioritaskan. Daftar ini menyatakan semua persyaratan untuk sistem, diatur menurut prinsip MoSCoW .Dan terakhir Log Risiko diperbarui dengan fakta-fakta yang telah diidentifikasi selama fase DSDM ini.

Iterasi Model Fungsional

Persyaratan yang telah diidentifikasi pada tahap sebelumnya diubah menjadi model fungsional. Model ini terdiri dari prototipe dan model yang berfungsi. Prototyping adalah salah satu teknik proyek utama dalam tahap ini yang membantu mewujudkan keterlibatan pengguna yang baik selama proyek berlangsung.Prototipe yang dikembangkan ditinjau oleh kelompok pengguna yang berbeda.Untuk memastikan kualitas, pengujian diimplementasikan pada setiap iterasi DSDM. Bagian penting dari pengujian direalisasikan dalam Functional Model Iteration. Model Fungsional dapat dibagi menjadi empat sub tahap:

·                     Identifikasi Prototipe Fungsional: Tentukan fungsi yang akan diimplementasikan pada prototipe yang dihasilkan dari iterasi ini.

·                     Setuju Jadwal: Setuju bagaimana dan kapan mengembangkan fungsionalitas ini.

·                     Buat Prototipe Fungsional: Kembangkan prototipenya. Selidiki, perbaiki, dan konsolidasikan dengan gabungan prototipe Fungsional dari iterasi sebelumnya.

·                     Tinjau Prototipe: Periksa kebenaran prototipe yang dikembangkan. Hal ini dapat dilakukan melalui pengujian oleh pengguna akhir, kemudian menggunakan catatan uji dan masukan pengguna untuk menghasilkan dokumen tinjauan prototip fungsional.

Kiriman untuk tahap ini adalah Model Fungsional dan Prototipe Fungsional yang bersama-sama mewakili fungsi yang dapat direalisasikan dalam iterasi ini, siap untuk diuji oleh pengguna. Di samping ini, Daftar Persyaratan diperbarui, menghapus item yang telah direalisasikan dan memikirkan ulang prioritas persyaratan yang tersisa. Log Risiko juga diperbarui dengan analisis risiko pengembangan lebih lanjut setelah meninjau dokumen prototyping.

Desain dan Build Iterasi

Fokus utama iterasi DSDM ini adalah mengintegrasikan komponen fungsional dari fase sebelumnya ke dalam satu sistem yang memenuhi kebutuhan pengguna. Ini juga membahas persyaratan non-fungsional yang telah ditetapkan untuk IS. Sekali lagi pengujian merupakan kegiatan berkelanjutan yang penting dalam tahap ini.Iterasi Desain dan Bangun dapat dibagi menjadi empat sub tahap:

·                     Identifikasi Prototipe Desain: Identifikasi persyaratan fungsional dan non-fungsional yang perlu dilakukan dalam sistem yang diuji.

·                     Setuju Jadwal: Setuju bagaimana dan kapan harus mewujudkan persyaratan ini.

·                     Buat Desain Prototipe: Buat sistem yang bisa dengan aman diserahkan ke pengguna akhir untuk pemakaian sehari-hari. Mereka menyelidiki, memperbaiki, dan mengkonsolidasikan prototipe iterasi saat ini dalam proses prototipe juga penting di sub-tahap ini.

·                     Review Design Prototype: Periksa kebenaran sistem yang dirancang. Sekali lagi pengujian dan pengkajian adalah teknik utama yang digunakan, karena catatan pengujian dan masukan pengguna penting untuk menghasilkan dokumentasi pengguna.

Kiriman untuk tahap ini adalah Prototipe Desain selama fase yang dapat diuji pengguna akhir dan pada akhir Design and Build Iteration, Sistem yang Teruji diserahkan ke tahap berikutnya. Pada tahap ini, sistem ini terutama dibangun dimana disain dan fungsinya dikonsolidasikan dan diintegrasikan dalam prototipe.Penyampaian lainnya untuk tahap ini adalah User Documentation.

Pelaksanaan

Pada tahap Implementasi, sistem yang diuji termasuk dokumentasi pengguna disampaikan kepada pengguna dan pelatihan pengguna masa depan terwujud.Sistem yang akan dikirim telah ditinjau untuk memasukkan persyaratan yang telah ditetapkan pada tahap awal proyek. Tahap implementasi dapat dibagi menjadi empat sub tahap:

·                     Persetujuan dan Pedoman Pengguna: Pengguna akhir menyetujui sistem teruji untuk implementasi dan pedoman sehubungan dengan penerapan dan penggunaan sistem yang dibuat.

·                     Pengguna Kereta Api: Latihlah pengguna akhir masa depan dalam penggunaan sistem.

·                     Terapkan: Terapkan sistem yang teruji di lokasi pengguna akhir.

·                     Tinjau Bisnis: Tinjau kembali dampak sistem yang diterapkan pada bisnis, sebuah isu utama adalah apakah sistem tersebut memenuhi sasaran yang ditetapkan pada awal proyek. Bergantung pada proyek ini berlanjut ke fase berikutnya, proyek pasca atau loop kembali ke tahap berikutnya

Peran di DSDM

Ada beberapa peran yang diperkenalkan di lingkungan DSDM. Adalah penting bahwa anggota proyek perlu diangkat ke peran yang berbeda sebelum mereka memulai menjalankan proyek. Setiap peran memiliki tanggung jawab tersendiri. Perannya adalah:

·                     Executive Sponsor Jadi disebut "Project Champion". Peran penting dari organisasi pengguna yang memiliki kemampuan dan tanggung jawab untuk melakukan dana dan sumber daya yang tepat. Peran ini memiliki kekuatan tertinggi untuk membuat keputusan.

·                     Visioner Orang yang memiliki tanggung jawab untuk menginisiasi proyek dengan memastikan bahwa persyaratan penting ditemukan sejak dini.Visioner memiliki persepsi yang paling akurat mengenai tujuan bisnis sistem dan proyek. Tugas lainnya adalah mengawasi dan menjaga proses pembangunan di jalur yang benar.

·                     Duta Besar Pengguna Membawa pengetahuan tentang komunitas pengguna ke dalam proyek, memastikan pengembang cukup menerima masukan pengguna selama proses pengembangan.

·                     Penasihat Pengguna Dapat menjadi pengguna yang mewakili sudut pandang penting dan membawa pengetahuan sehari-hari proyek.

   Extreme Programing Methodology 

Extreme Programming (berikutnya akan disingkat sebagai XP) adalah sebuah pendekatan atau model pengembangan perangkat lunak yang mencoba menyederhanakan berbagai tahapan dalam proses pengembangan tersebut sehingga menjadi lebih adaptif dan fleksibel. XP bukan hanya berfokus pada coding tetapi meliputi seluruh area pengembangan perangkat lunak. XP mengambil pendekatan ‘ekstrim’ dalam iterative development.

XP Pertama kali diusulkan oleh Kent Beck dan Ward Cunningham pada bulan Maret 1996, asal mula XP digunakan karena pada saat itu permintaan dari customer yang sering berubah dengan cepat sehingga mengakibatkan putaran kehidupan metode pengembangan perangkat lunak tradisional menjadi lebih pendek dan tidak selaras dengan metode tradisional karena pada umumnya memerlukan desain yang luas dan itu mengakibatkan perubahan desain yang terjadi dan tentu saja memerlukan biaya yang lebih tinggi. Tujuan XP adalah meminimalisir biaya yang diperlukan jika ada perubahan dalam pengembangan perangkat lunak.

ASPEK DASAR XP TERDIRI DARI BERBAGAI TEKNIK ATAU METODE YANG DITERAPKAN BECK DAN JEFFRIES PADA C3 PROJECT. TEKNIK-TEKNIK TERSEBUT ANTARA LAIN:

·         Whole Team

Seluruh kontributor dalam proyek yang menggunakan pendekatan XP duduk bersama sebagai suatu tim. Tim ini terdiri beberapa peran, antara lain programmer, penguji,orang yang mengerti bisnis, analis, manajer, dan lain-lain. Setiap peran yang ada tidak mutlak menjadi peran dari satu orang saja. Tim terbaik dalam XP tidak harus memiliki pakar, hanya kontributor umum dengan keterampilan khusus saja. Semua orang di tim XP memberikan kontribusi dengan cara apapun yang mereka dapat lakukan.

·         Planning game

Perencanaan dalam XP mengemukakan dua pertanyaan kunci dalam pengembangan perangkat lunak, yaitu  memprediksi apa yang akan dicapai pada waktu tertentu, dan menentukan apa yang harus dilakukan setelah itu. Ada dua langkah kunci dalam perencanaan XP, yang menangani dua pertanyaan tersebut:

2.            Release Planning yaitu praktek dimana Customer mengutarakan fitur yang diinginkannya ke programer, dan programer memperkirakan tingkat kesulitannya. Dengan estimasi biaya di tangan, dan dengan pengetahuan tentang pentingnya fitur yang diinginkan, Pelanggan meletakkan satu rencana untuk proyek tersebut. Rencana rilis awal yang selalu tepat: baik prioritas maupun perkiraan yang benar-benar solid, dan sampai tim mulai bekerja, kita tidak akan tahu seberapa cepat mereka akan pergi. Bahkan rencana rilis pertama cukup akurat untuk pengambilan keputusan, namun, dan tim XP melakukan revisi terhadap rencana rilis secara teratur.2. Iteration Planning adalah praktek di mana tim diberikan petunjuk atau arahan setiap beberapa minggu sekali. Tim XP membangun perangkat lunak dalam “iterasi” dua minggu, memberikan menjalankan perangkat lunak yang berguna pada setiap akhir iterasi. Selama Iteration Planning, Customer mengutarakan fitur yang diinginkan selama dua minggu ke depan. Para programer memecahnya ke dalam pekerjaan yang lebih kecil, dan memperkirakan biaya yang diperlukan.

o    Customer TestsSebagai bagian dari presentasi masing-masing fitur yang diinginkan, Customer XP mendefinisikan satu atau lebih  tes penerimaan otomatis untuk menunjukkan bahwa fitur tersebut bekerja dengan baik. Tim membangun tes ini dan menggunakannya untuk membuktikan pada kepada Customer bahwa fitur ini telah diimplementasikan dengan benar. Tes secara otomatis ini penting karena dalam XP hanya diberikan waktu yang singkat sehingga tes manual tidak akan digunakan karena memakan waktu yang lama.

o    Small Release

Pada setiap Iterasi, tim mengerjakan sebuah unit atau bagian dari perangkat lunak, melakukan tes terhadap unit perangkat lunak yang dibangun, kemudian di akhir iterasi perangkat lunak yang dibangun diberikan kepada Customer. Oleh customer, perangkat lunak ini bisa dijadikan bahan evaluasi maupun langsung dirilis kepada end user. Bisa juga tim XP langsung merilis ke end user secara rutin.

o    Simple Design

Tim XP membangun perangkat lunak dengan desain yang sederhana. Dimulai dengan desain yang sederhana, kemudian melalui pengujian program dan perbaikan desain. Desain yang dibuat harus benar-benar cocok untuk fungsi saat ini dari sistem sehingga tidak ada yang sia-sia dan perangkat lunak siap dikembangkan lagi selanjutnya. Namun, pembuatan desain dalam XP tidak dilakukan hanya sekali. Tahapan desain dalam Extreme Programming yang menghasilkan desain yang bagus dianggap sangat penting, sehingga selama proses development banyak difokuskan ke tahapan desain.

o    Pair Programming

Semua perangkat lunak yang dibangun dengan pendekatan XP dibangun oleh dua orang programmer. Keduanya duduk berdampingan di satu komputer yang sama. Seorang programmer akan membuat code dan programmer yang lainnya akan mengoreksinya. Praktik seperti ini mungkin kelihatan tidak efisien. Namun dari segi hasil dari pair programming, desain akan lebih baik, pengujian lebih baik, dan code yang dihasilkan pun akan lebih baik.

o    Test-Driven Development

XP begitu terobsesi dengan umpan balik, dan dalam pengembangan perangkat lunak, umpan balik yang baik mensyaratkan pengujian yang baik pula. Test-Driven Development bergantung pada pengulangan siklus development yang sangat pendek. Pertama tim XP akan menuliskan automated test case yang mendefinisikan perbaikan yang diinginkan atau fungsi baru. Kemudian dari test case tersebut dihasilkan jumlah minimal code yang harus dituliskan untuk lulus tes tersebut. Setelah itu melakukan refactoring code baru agar memenuhi standar baru.

o    Design Improvement

XP berfokus pada memberikan nilai bisnis dalam setiap perulangan. Agar dapat mencapai tujuan tersebut selama proyek berlangsung, perangkat lunak harus dirancang dengan baik. XP menggunakan proses perbaikan desain secara terus menerus dengan Refactoring. Proses refactoring berfokus pada penghapusan duplikasi dari code yang telah dibuat. Disamping itu, proses refactoring didukung dengan pengujian yang komprehensif utnuk memastikan bahwa desain yang dibuat berkembang dan tiidak ada yang rusak.

o    Continuous Integration

Beberapa kali dalam sehari, tim XP akan menggabungkan seluruh salinan pekerjaan tim menjadi satu dalam jaringan utama. Sehingga tim XP harus menjaga tim agar terintegrasi setiap saat.

o    Collective Code Ownership

Pada proyek XP, setiap pasang programmer dapat meningkatkan code apapun setiap saat. Semua code yang ada dimiliki secara kolektif oleh tim. Manfaatnya setiap code akan mendapat perhatian dari banyak orang, sehingga dapat meningkatkan kualitas code dan mengurangi cacat. Selain itu dapat mengurangi duplikasi code yang sama walaupun dibuat oleh pasangan programmer yang berbeda.

o    Coding Standard

Setiap anggota tim XP harus mengikuti standar coding yang umum, sehingga semua code dalam sistem seolah-olah tampak dibuat oleh satu orang yang sangat kompeten. Selain itu hal ini sangat mendukung Collective Code Ownership.

o    Metaphor

Tim XP akan membuat suatu deskripsi umum bagaimana program yang mereka kembangkan bekerja dengan benar.

o    Sustainable Pace

Tim XP akan bekerjasama dalam jangka waktu lama. Mereka bekerja keras dengan kecepatan tertentu tanpa batas waktu. Tim XP akan bekerja lembur pada hari efektif dan memaksimalkan produktivitas setiap minggunya.  Hal ini perlu diperhatikan dengan baik, karena akan mengurangi produktivitas atau sebaliknya menghasilkan perangkat lunak yang berkualitas.

Scrum Development Methodology

Scrum adalah sebuah kerangka kerja untuk pengembangan secara inkremental dengan menggunakan satu atau lebih tim yang cross-functional dan self-organizing yang terdiri dari kurang lebih tujuh orang pada tiap-tiap tim. Scrum menggunakan iterasi tetap bernama Sprint, yang dijalankan dalam waktu dua minggu atau tiga puluh hari. Tim Scrum berusaha untuk membangun inkremen produk (perangkat lunak) yang siap digunakan dan telah diuji pada setiap proses iterasi ini. (James, 2012)

Peran Dalam Scrum

Menurut Michael James (2012), dalam proses pengembangan sebuah perangkat lunak menggunakan metode Scrum, teradapat beberapa aktor penting, di antaranya:

1.    Product Owner. Orang ini bertugas untuk menentukan Product Backlog dan menentukan prioritas fitur yang akan disajikan pada perangkat lunak. Ia juga berhak untuk menerima atau menolak setiap hasil yang telah dikembangkan pada tiap iterasi.

2.    Tim Pengembangan Scrum. Tim yang beranggotakan antara 7-9 orang ini bersifat cross-functional, yaitu tim yang berisi orang-orang dengan kemampuan dan perang yang berbeda, misalnya terdiri dari tester, developer, business analyst, domain expert, dan lain-lain. Tim ini mendiskusikan kepada Product Owner mengenai tiap-tiap Sprint yang akan dijalankan.

3.    Scrum Master. Orang ini secara tradisional disebut sebagai Project Mabager dan bertugas untuk mengawasi keseluruhan proses Scrum, membantu mengatasi halangan yang dihadapi selama proses tersebut, menciptakan suasana yang kondusif bagi tim pengembang, dan melindungi tim dari gangguan eksternal sehingga tim dapat bekerja dengan baik pada zonanya. Akan tetapi, Scrum Master tidak memiliki otoritas untuk mengatur tim. Orang yang memiliki otoritas untuk mengatur tim ditentukan oleh tim tersebut.

Perangkat-perangkat Scrum

Penjelasan berikut ini merupakan hasil kolaborasi antara apa yang dikemukakan Michael James (2012) dan Hamid Shojaee (2012) mengenai beberapa perangkat yang digunakan dalam sebuah pengembangan menggunakan metode Scrum ini, di antaranya:

1.    Product Backlog. Product Backlog berisi kumpulan User Story yang akan menentukan fitur-fitur yang akan dibuat pada perangkat lunak. Kumpulan User Strory ini kemudian dibuat skala prioritasnya oleh Product Owner.

2.    Product Backlog Item (PBI). PBI atau secara tradisional dikenal sebagai User Story ini secara tertulis kurang lebih berisi mengenai “Sebagai seorang (nama peran), saya menginginkan (nama fitur), sehingga dapat berguna untuk (keuntungan fitur)”.

3.    Sprint Backlog. Sebuah Sprint berisi beberapa PBI yang telah diprioritaskan dalam rapat antara Product Owner dan Tim Pengembang. Sprint merupakan milestone dalam pengembangan produk yang akan berlangsung hingga maksimal tiga puluh hari, tidak boleh lebih. Pada akhir tiap-tiap Sprint harus menghasilkan shipped product (produk yang siap digunakan). Oleh sebab itu, pada Sprint pertama, pastikan semua fitur dasar dan utama yang telah diprioritaskan dimasukkan ke dalam Sprint ini. Dengan kata lain, setelah Sprint 1, perangkat lunak / aplikasi / produk dasar telah siap digunakan. Adapun pelengkapan fitur-fitur pelengkap atau lainnya pada produk dengan tingkatan prioritas yang lebih rendah dapat dikembangkan pada Sprint 2 dan seterusnya.

4.    Burndown Chart. Burndown chart digunakan untuk mengawasi setiap fase perkembangan Sprint agar berjalan mulus dan tidak melebihi tenggat waktu yang telah ditentukan. Chart ini menampilkan pengukuran harian terhadap jumlah dan sisa pekerjaan hingga produk siap dirilis. Dengan demikian tim dapat membuat perkiraan mengenai kapan sebuah Sprint atau sebuah shipped product akan selesai, sehingga apabila diperkirakan akan melebihi batas waktu, tim dapat melakukan penyesuaian dengan meningkatkan waktu/jam kerja mereka tiap harinya.

5.    Daily Scrum. Perangkat ini merupakan sarana komunikasi yang sangat penting bagi seluruh anggota tim Scrum. Daily Scrum juga sering disebut stand-up meeting karena akan berlangsung sangat singkat, yaitu kurang lebih lima belas menit. Secara teknis, Daily Scrum merupakan rapat singkat harian di mana seluruh anggota tim bertemu dan hanya mengemukakan tiga hal utama, yaitu “apa yang telah saya lakukan kemarin”, “masalah yang saya hadapi/telah diselesaikan”, dan “apa yang akan/sudah saya selesaikan hari ini”. Sedangkan Scrum Master hanya akan membuka rapat, mencatat, mengawasi, dan memfailitasi diskusi untuk menyelesaikan beberapa permasalahan yang dihadapi tim.

6.    Sprint Retrospective Meeting. Rapat ini dilakukan oleh seluruh tim saat setiap Sprint selesai dijalankan dan shipped product dihasilkan. Dalam rapat ini, tim akan mengevaluasi mana saja yang telah berjalan baik dalam proses, dan mana saja yang masih membutuhkan perubahan/perbaikan/improvement.

Demikianlah sedikit penjelasan mengenai Scrum. Lebih lanjut dan lebih lengkap untuk mengetahui Metodologi Scrum, dapat diakses melalui link-link yang menjadi sumber penulisan.