Sertifikasi TOGAF 2018: Mengapa, Apa dan Bagaimana?

1.Pengertian sertifikasi TOGAF

Apa itu “Sertifikasi TOGAF” Tentang?

Open Group telah memperkenalkan program sertifikasi untuk TOGAF, saat ini Versi 8.1 – kerangka kerja dan metode arsitektur standar industri.

Sertifikasi TOGAF adalah untuk individu dan organisasi. Individu dapat menjadi tersertifikasi dengan menunjukkan pengetahuan mereka tentang TOGAF baik dengan mengikuti kursus pelatihan atau lulus ujian. Organisasi dapat memiliki produk mereka (Alat TOGAF atau Kursus Pelatihan), dan layanan bersertifikat.

Pelanggan yang ingin mendasarkan arsitektur TI mereka bekerja pada metode TOGAF standar industri terbuka, sekarang dapat memperoleh alat, pelatihan, dan layanan konsultan (individu dan integrator) atas dasar kesesuaian bersertifikat dengan standar TOGAF.

2. Pentingnya sertifikasi TOGAF

Mengapa ini penting?

Arsitektur TI memperoleh pengakuan yang semakin meningkat sebagai suatu disiplin yang diperlukan untuk memastikan bahwa desain dan implementasi TI di seluruh perusahaan benar-benar menjawab dan mendukung kebutuhan bisnis. TOGAF adalah kerangka kerja, standar industri terbuka dan metode untuk Arsitektur TI, dikembangkan dan terus berkembang sejak pertengahan tahun 90-an oleh perwakilan dari beberapa perusahaan IT dan vendor organisasi terkemuka di dunia.

Pengenalan program sertifikasi untuk TOGAF memungkinkan organisasi besar (baik swasta maupun sektor publik) untuk membakukan metode terbuka ini untuk Arsitektur TI, dan jadi hindari mengunci ke dalam metode kepemilikan dari konsultan utama.

Ini merupakan langkah penting dalam membuat Arsitektur TI disiplin yang diakui, dan dalam memperkenalkan ketelitian dalam pengadaan alat dan layanan untuk Arsitektur TI.

 

3. Isi sertifikasi TOGAF

Program Sertifikasi TOGAF 9 untuk Orang adalah program pendidikan dan sertifikasi yang digerakkan oleh pasar untuk mendukung TOGAF 9 (dan pembaruan pemeliharaannya).

Ada dua tingkatan untuk sertifikasi: Level 1, yang dikenal sebagai TOGAF 9 Foundation, dan Level 2, yang dikenal sebagai TOGAF 9 Certified. Level 2 berisi persyaratan pembelajaran untuk Level 1.

1. TOGAF® 9 Foundation (level 1)

Tujuan sertifikasi untuk TOGAF 9 Level 1, yang dikenal sebagai TOGAF 9 Foundation, adalah untuk memberikan validasi bahwa Kandidat telah memperoleh pengetahuan tentang terminologi, struktur, dan konsep dasar dari TOGAF 9 standar, dan memahami prinsip-prinsip inti Arsitektur Perusahaan dan standar TOGAF.

Tujuan pembelajaran pada tingkat ini berfokus pada pengetahuan dan pemahaman.

Nilai dari Sertifikasi ini

Individu yang disertifikasi pada tingkat ini akan menunjukkan pemahaman mereka tentang:

• Konsep dasar Arsitektur Perusahaan dan standar TOGAF
• Konsep inti dari standar TOGAF 9
• Terminologi kunci dari standar TOGAF 9
• Siklus dan tujuan ADM dari setiap fase, dan bagaimana menyesuaikan dan memperluas ADM
• Konsep Enterprise Continuum; tujuan dan bagian penyusunnya
• Bagaimana masing-masing fase ADM berkontribusi pada keberhasilan Arsitektur Perusahaan
• Panduan dan teknik ADM
• Bagaimana Tata Kelola Arsitektur berkontribusi pada Siklus Pengembangan Arsitektur
• Konsep pandangan dan sudut pandang serta peran mereka dalam berkomunikasi dengan para pemangku kepentingan
• Konsep blok bangunan
• Pengiriman kunci dari siklus ADM
• Model referensi TOGAF
• Program sertifikasi TOGAF

 

2. TOGAF® 9 Bersertifikat (level 2)

Tujuan sertifikasi untuk TOGAF 9 Level 2, yang dikenal sebagai TOGAF 9 Certified, adalah untuk memberikan validasi bahwa selain pengetahuan dan pemahaman dari TOGAF 9 Foundation, Calon mampu menganalisis dan menerapkan pengetahuan ini. Tujuan pembelajaran di tingkat ini karena itu fokus pada aplikasi dan analisis di samping pengetahuan dan pemahaman.

Nilai dari Sertifikasi ini

Individu yang disertifikasi pada tingkat ini akan menunjukkan pemahaman mereka tentang:

• Bagaimana menerapkan fase ADM dalam pengembangan Arsitektur Perusahaan
• Bagaimana menerapkan Tata Kelola Arsitektur dalam pengembangan Arsitektur Perusahaan
• Bagaimana menerapkan Kerangka Kerja Arsitektur TOGAF
• Bagaimana menerapkan konsep Blok Bangunan
• Bagaimana menerapkan Teknik Manajemen Pemangku Kepentingan
• Bagaimana cara menerapkan Metamodel Konten TOGAF
• Bagaimana menerapkan teknik standar TOGAF yang direkomendasikan saat mengembangkan EnterpriseArsitektur

• Model Referensi Teknis TOGAF dan bagaimana menyesuaikannya untuk memenuhi kebutuhan organisasi
• Model Referensi Infrastruktur Informasi Terpadu
• Isi pengiriman kunci dari siklus ADM
• Bagaimana suatu Arsitektur Perusahaan dapat dipartisi untuk memenuhi kebutuhan spesifik suatu organisasi
• Tujuan dari Arsitektur Repositori
• Bagaimana menerapkan iterasi dan berbagai tingkat arsitektur dengan ADM

 

4. Berapa lama proses sertifikasi berlangsung dan berapa biayanya ?

A. WAKTU :

1. Itu berlangsung hingga 24 bulan. Dalam beberapa kasus, untuk kelas sertifikasi tergantung pada lisensi TOGAF Komersial tahunan maka sertifikasi awal akan disinkronkan dengan tanggal perpanjangan lisensi.
2. Untuk kehadiran kursus, durasi minimum adalah 4 hari atau 28 jam belajar untuk pembelajaran jarak jauh. Pemeriksaan membutuhkan waktu 2 jam.

Dengan asumsi penyerahan lengkap, otoritas sertifikasi memiliki target tingkat layanan berikut untuk menyelesaikan 80% dari kiriman yang lengkap dan benar sebagai berikut:

• TOGAF Certified – 6 Hari Kerja
• Kelas Lainnya – 10 Hari Kerja

100% dari semua kiriman yang lengkap dan benar akan diproses dalam 12 hari kerja. Jika pengiriman yang tidak lengkap atau salah diterima, jam ditunda sampai bagian yang hilang atau dikoreksi diterima.

B. BIAYA

Di Amerika Serikat, ujian biaya $ 320 masing-masing untuk level 1 dan level 2, sedangkan tingkat gabungan 1 dan tingkat 2 ujian biaya $ 495. Open Group menawarkan kursus empat hari yang dipimpin instruktur, yang bisa sangat mahal sekitar $ 3.000; kursus e-learning juga tersedia untuk sekitar $ 1,125, termasuk voucher ujian.

 

Berikut adalah spesifikasi biaya sertifikasi TOGAF :

TOGAF^® 9 Examination fees:

Examination	Exam Fee**
TOGAF® 9 Part 1 English	USD $320
TOGAF® 9 Part 2 English	USD $320
TOGAF® 9 Combined Part 1 and 2 English	USD $495
TOGAF® 9 Part 1 Brazilian Portuguese	USD $210 (in Brazil), USD $320 (Worldwide)
TOGAF® 9 Part 2 Brazilian Portuguese	USD $210 (in Brazil), USD $320 (Worldwide)
TOGAF® 9 Part 1 French	USD $320
TOGAF® 9 Part 2 French	USD $320
TOGAF® 9 Part 1 Latin American Spanish	USD $320
TOGAF® 9 Part 2 Latin American Spanish	USD $320
TOGAF® 9 Part 1 Simplified Chinese	USD $320
TOGAF® 9 Part 2 Simplified Chinese	USD $320
TOGAF® 9 Combined Part 1 and 2 Simplified Chinese	USD $495

 

5. Jadwal sertifikasi TOGAF di Indonesia sepanjang 2018

Contoh Jadwal sertifikasi TOGAF di Indonesia sepanjang 2018

 

 

TOGAF ( The Open Group Architecture Framework)

1. Pengertian TOGAF ( The Open Group Architecture Framework) :

     Open Group Architectural Framework (TOGAF) pertama kali dikembangkan pada tahun 1995 dan didasarkan pada Kerangka Arsitektur Teknis Departemen Pertahanan untuk Manajemen Informasi. TOGAF berfokus pada aplikasi bisnis missioncritical yang menggunakan blok bangunan sistem terbuka. “Elemen kunci TOGAF adalah Metode Pengembangan Arsitektur (ADM) yang menentukan proses untuk mengembangkan arsitektur perusahaan”. TOGAF menjelaskan aturan untuk mengembangkan prinsip-prinsip yang baik, daripada menyediakan seperangkat prinsip arsitektur. Tiga tingkat prinsip mendukung pengambilan keputusan di seluruh perusahaan, memberikan bimbingan sumber daya TI, dan mendukung prinsip arsitektur untuk pengembangan dan implementasi.

Dalam pengertian lain disebutkan TOGAF adalah:

• Metodologi dan kerangka arsitektur perusahaan yang telah terbukti digunakan oleh organisasi terkemuka di dunia untuk meningkatkan efisiensi bisnis.
• Standar arsitektur perusahaan yang paling menonjol dan dapat diandalkan, memastikan standar, metode, dan komunikasi yang konsisten antara para profesional arsitektur enterprise.
• Profesional arsitektur perusahaan yang fasih dalam standar TOGAF menikmati kredibilitas industri yang lebih besar, efektivitas kerja, dan peluang karir.
• TOGAF membantu praktisi menghindari dikunci dengan metode berpemilik, memanfaatkan sumber daya secara lebih efisien dan efektif, dan mewujudkan pengembalian investasi yang lebih besar.

2. Mengapa perlu memakai TOGAF?

1. TOGAF memberikan metode yang detil bagaimana membangun dan mengelola serta mengimplementasikan arsitektur enterprise dan sistem informasi yang disebut dengan Architecture Development Method (ADM) (Open Group, 2009).
2. TOGAF ADM merupakan metode generik yang berisikan sekumpulan aktivitas yang digunakan dalam memodelkan pengembangan arsitektur enterprise. Metode ini juga dibisa digunakan sebagai panduan atau alat untuk merencanakan, merancang, mengembangkan dan mengimplementasikan arsitektur sistem informasi untuk organisasi (Yunis dan Surendro, 2008).
3. TOGAF ADM juga merupakan metode yang fleksibel yang dapat mengantifikasi berbagai macam teknik pemodelan yang digunakan dalam perancangan, karena metode ini bisa disesuaikan dengan perubahan dan kebutuhan selama perancangan dilakukan.
4. TOGAF diperlukan untuk mengembangkan enterprise architecture, dimana terdapat metode dan tools yang detil untuk mengimplementasikannya, hal inilah yang membedakan dengan framework EA lain misalnya framework Zachman. Salah satu kelebihan menggunakan framework TOGAF ini adalah karena sifatnya yang fleksibel dan bersifat open source. 

Siklus ADM

      Yang dalam pembahasan siklus ADM , TOGAF mempunyai poin-poin tertentu dalam mewujudkan perancangan sistem yaitu:

1. Metode umum yang komprehensif
2. Melengkapi, tidak bersaing dengan kerangka kerja lainnya
3. Diadopsi secara luas di pasar
4. Disesuaikan untuk memenuhi kebutuhan organisasi dan industri
5. Tersedia di bawah lisensi abadi gratis
6. Vendor, alat dan teknologi terbuka standar netral
7. Menghindari menciptakan kembali roda
8. Penyelarasan IT bisnis
9. Berbasis di praktik terbaik
10. Memungkinkan untuk berpartisipasi dalam evolusi kerangka kerja

 

3. Pada saat bagaimana TOGAF diperlukan?

        TOGAF diperlukan ketika :

1. Pemanfaatan dan penerapan sistem informasi dalam suatu organisasi saling tumpang tindih yang membuat sistem informasi tidak dapat dimanfaatkan sesuai dengan yang diharapkan.
2. Ketidakberhasilan dalam penerapan sistem informasi, yaitu efesiensi dan efektifitas dalam pemenuhan kebutuhan organisasi, mulai dari pemenuhan kebutuhan pada level yang tertinggi dalam organisasi sampai pada kebutuhan paling bawah yaitu kebutuhan operasional.
3. Karena kurangnya perencanaan dan tanpa memikirkan kunci utama dalam proses pengembangan sistem informasi yaitu perancangan, perancangan sistem informasi yang baik harus melihat dari berbagai sudut pandang pengembangan sistem, dimulai dari mendefinisikan arsitektur bisnis yang ada dalam organisasi, mendefinisikan arsitektur data yang akan digunakan, mendefinisikan arsitektur aplikasi yang akan dibangun serta mendefinisikan arsitektur teknologi yang mendukung jalannya sistem informasi tersebut.
4. Keselarasan penerapan sistem informasi dengan kebutuhan organisasi hanya mampu dijawab dengan memperhatikan faktor integrasi didalam pengembangnnya.
5. Membuat perancangan sebuah sistem informasi dalam organisasi dan bagaimana cara mengelola, mewujudkan rancangan sistem informasi tersebut menjadi efisien dan efektif.

      Untuk menurunkan kesenjangan tersebut, maka diperlukanlah sebuah paradigma dalam merencanakan, merancang, dan mengelola sistem informasi yang disebut dengan arsitektur enterprise (enterprise architecture). Arsitektur enterprise adalah sebuah pendekatan logis, komprehensif, dan holistik untuk merancang dan mengimplementasikan sistem dan komponen sistem secara bersamaan.

    Dalam kondisi tersebut akan memerlukan penggunaan TOGAF ADM dalam perancangan arsitektur enterprise, sehingga didapatkan gambaran yang jelas bagaimana melakukan perancangan arsitektur enterprise, untuk mendapatkan sebuah arsitektur enterprise yang baik dan bisa digunakan oleh organisasi untuk mencapai tujuan strategisnya.

4. Manfaat TOGAF ketimbang dengan framework lain adalah :

1. TOGAF digunakan untuk mengembangkan enterprise architecture, dimana terdapat metode dan tools yang detil untuk mengimplementasikannya, hal inilah yang membedakan dengan framework EA lain misalnya framework Zachman.
2. Salah satu kelebihan menggunakan framework TOGAF ini adalah karena sifatnya yang fleksibel dan bersifat open source.
3. Framework TOGAF memenuhi beberapa kriteria yang harus ada dalam pendesainan EA, yaitu:

     a. Reasoned: Framework yang masuk akal yang dapat memungkinkan pembuatan                 arsitektur yang bersifat deterministik ketika terjadi perubahan kontrain dan tetap           menjaga integritasnya walalupun menghadapi perubahan bisnis dan teknologi serta           demand yang tak terduga.

    b. Cohesive: Framework yang kohesif memiliki sekumpulan perilaku yang akan                      seimbang dalam cara pandang dan scope-nya.

    c. Adaptable: Framework haruslah bisa beradaptasi terhadap perubahan yang                        mungkin sangat sering terjadi dalam organisasi.

   d. Vendor-independent: Framework haruslah tidak tergantung pada vendor tertentu             untuk benar-benar memaksimalkan benefit bagi organisasi.

  e. Technology-independent.

  f. Domain-neutral: Adalah atribut penting bagi framework agar memiliki peranan                  dalam pemeliharaan tujuan organisasi.

 g. Scalable: Framework haruslah beroperasi secara efektif pada level departemen, unit

     bisnis, pemerintahan dan level korporat tanpa kehilangan fokus dan

     kemampuan untuk dapat diaplikasikan.

5. Bagian – bagian TOGAF adalah

     TOGAF memandang enterprise architecture ke dalam empat bagian seperti yang              ditunjukkan  gambar dibawah ini, Keempat bagian tersebut adalah:

1. Business Architecture Mendeskripsikan tentang bagaimana proses bisnis untuk mencapai tujuan organisasi
2. Application Architecture Merupakan pendeskripsian bagaimana aplikasi tertentu didesain dan bagaimana interaksinya dengan apikasi lainnya
3. Data Architecture adalah penggambaran bagaimana penyimpanan, pengelolaan dan pengaksesan data pada perusahaan
4. Technical Architecture Gambaran mengenai infastruktur hardware dan software yang mendukung aplikasi dan bagaimana interaksinya.

6. Pendapat saya tentang TOGAF adalah :

           TOGAF merupakan enterprise architecture paling terkenal terbukti digunakan oleh organisasi terkemuka di dunia karena sangat lengkap dengan prinsip-prinsip yang mendukung pengambilan keputusan di seluruh perusahaan, memberikan bimbingan sumber daya TI, mendukung prinsip arsitektur untuk desain dan implementasi dalam meningkatkan efisiensi bisnis.

        Juga sifat TOGAF yang open source dan fleksibel yang dapat mengantifikasi berbagai macam teknik pemodelan yang digunakan dalam perancangan, karena metode ini bisa disesuaikan dengan perubahan dan kebutuhan selama perancangan dilakukan. TOGAF ADM juga bisa diasosiasikan dengan framework atau metode lain, seperti Zachman Framework, COBIT dan lainnya.

       Juga EA TOGAF merupakan enterprise arsitektur yang mempunyai kelebihan, bahkan bisa dibilang hampir sempurna dibanding dengan EA Framework lain yaitu TOGAF memenuhi kriteria dalam perancangan sistem informasi suatu organisasi. Tabel berikut yang menunjukkan bahwa EA TOGAF lebih lengkap dan mewakili semua kerangka kriteria perancangan sistem.

A Comparison of Enterprise Architecture Frameworks Table 3. Comparison by SDLC Phases   SDLC Phase/ Framework Planning Analysis Design Implementation Maintenance Zachman Yes Yes Yes Yes No DoDAF Yes Yes Yes Describes final products No FEAF   Yes Yes Yes Yes Detailed Subcontractor’s View TEAF   Yes Owner’s Analysis Yes Yes No TOGAF   principles that support decision making across enterprise; provide guidance of IT resources; support architecture principles for design and implementation

 

Macam-macam Enterprise Architecture Framework

“Ini adalah hasil rangkuman kuliah enterprise architecture di prodi Sistem Informasi Universitas Trunojoyo Madura”

1. ZACHMAN

A. Sejarah Zachman Enterprise Architecture

Kerangka Zachman untuk Arsitektur Enterprise: John Zachman menerbitkan Zachman Framework for Enterprise Architecture pada tahun 1987 dan dianggap sebagai salah satu pelopor dalam domain ini. Menurut Zachman , “peningkatan cakupan desain dan tingkat kompleksitas implementasi sistem informasi memaksa penggunaan beberapa konstruksi logis (atau arsitektur).” Kerangka Zachman didasarkan pada prinsip-prinsip arsitektur klasik yang membentuk persamaan umum. kosa kata dan seperangkat perspektif untuk menggambarkan sistem perusahaan yang kompleks. Kerangka kerja ini tidak memberikan panduan mengenai urutan, proses, atau implementasi, namun berfokus pada memastikan bahwa semua pandangan telah mapan, memastikan sistem yang lengkap terlepas dari urutan kemunculannya. Kerangka Zachman memiliki enam perspektif atau pandangan: Perencana, Pemilik, Perancang, Pembangun, Subkontraktor, dan Pengguna. Penjelasannya adalah sebagai berikut:

1. Planner/ Perencana: yang menetapkan objek dalam pembahasan; latar belakang, lingkup, dan tujuan enterprise.

2. Owner /Pemilik: penerima atau pemakai produk/jasa akhir dari enterprise.

3. Designer/Perancang: perantara antara apa yang diinginkan (pemilik) dan apa yang dapat dicapai secara teknis dan fisik.

4. Builder/ Pembangun: pengawas/pengatur dalam menghasilkan produk/jasa akhir.

5. Subkontraktor: bertanggung jawab membangun dan merakit bagian-bagian dari produk/jasa akhir f. Functioning enterprise: wujud nyata dari produk/jasa akhir.

Karakteristik Zachman Framework:

1. Mengkategorikan deliverables dari EA

2. Kegunaan EA yang terbatas

3. Banyak diadopsi di seluruh dunia

4. Perspektif view yang kurang menyeluruh

5. Merupakan tool untuk perencanaan

Banyak organisasi tertarik untuk membangun arsitektur enterprise mereka dengan menggunakan framework Zachman. Mereka berharap dapat memecahkan masalah ketidaksesuaian antara proses bisnis dan sistem informasi seiring dengan memperoleh tingkat interoperabilitas dan fleksibilitas yang diinginkan di lingkungan TI mereka. Namun, dalam kebanyakan kasus kerangka kerja Zachman tetap sebagai kerangka konseptual lebih dari yang pragmatis. Hal ini menyebabkan keraguan yang serius mengenai apakah perusahaan dapat memuaskan motivasi penggunaan kerangka kerja Zachman.

Ide dasar dibalik Framework Zachman adalah bahwa hal kompleks yang sama dapat digambarkan untuk tujuan yang berbeda dengan cara yang berbeda menggunakan berbagai jenis deskripsi. Setiap baris dalam Zachman framework mewakili perspektif tertentu. Sebuah baris atas atau perspektif tidak selalu memiliki pemahaman yang lebih komprehensif dari perspektif yang lebih rendah. Dalam Zachman framework tahun 1997 baris dijelaskan dari sudut pandang Planner’s view (scope), Owner’s view (enterprise atau model bisnis), Designer’s view (Information System model), Builder’s view (Techn Ide dasar dibalik Framework Zachman adalah bahwa hal kompleks yang sama dapat digambarkan untuk tujuan yang berbeda dengan cara yang berbeda menggunakan berbagai jenis deskripsi.Sebuah baris atas atau perspektif tidak selalu memiliki pemahaman yang lebih komprehensif dari perspektif yang lebih rendah.

Kolom Zachman framework dapat dijelaskan sebagai berikut: masing-masing perspektif memfokuskan perhatian pada pertanyaan mendasar yang sama, jawaban pertanyaan-pertanyaan dari sudut pandang itu, menciptakan representasi deskriptif yang berbeda (yaitu model), yang menerjemahkan dari persepktif yang lebih tinggi ke yang lebih rendah. Kolom Zachman framework adalah sebagai berikut deskripsi data–what (apa), deskripsi fungsi–how (bagaimana), deskripsi jaringan–where (dimana), deskripsi orang–who (siapa), deskripsi waktu–when (bila), gambaran motivasi– mengapa. Menurut Zachman, faktor tunggal yang membuat kerangka kerja yang unik adalah bahwa setiap elemen di kedua sumbu matriks secara eksplisit dibedakan dari semua elemen lain pada sumbu itu. Representasi dalam setiap sel matriks tidak hanya tingkatan detail meningkat, namun sebenarnya adalah representasi berbeda-beda dalam konteks, makna, motivasi, dan penggunaan. Karena setiap elemen pada sumbu secara eksplisit berbeda dari yang lain maka memungkinkan untuk mendefinisikan dengan tepat apa yang termasuk dalam setiap sel. Jenis model atau representasi deskriptif arsitektur dibuat eksplisit di persimpangan baris dan kolom.

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.

2.  TOGAF

          A. Sejarah The Open Group Architecture Technique (TOGAF)

The Open Group Architecture Technique (TOGAF) adalah sebuah  framework yang dikembangkan oleh The Open Group’s Architecture Framework pada tahun 1995. Awalnya TOGAF digunakan oleh Departemen Pertahanan Amerika Serikat namun pada perkembangannya TOGAF banyak digunakan pada berbagai bidang seperti perbankan, industri manufaktur dan juga pendidikan.  TOGAF ini digunakan untuk mengembangkan enterprise architecture, dimana terdapat metode dan tools yang detil untuk mengimplementasikannya, hal inilah yang membedakan dengan framework EA lain misalnya framework Zachman. Salah satu kelebihan menggunakan framework TOGAF ini adalah karena sifatnya yang fleksibel dan bersifat open source.

Kerangka Arsitektur Open Group Architectural (TOGAF): Kerangka Arsitektur Open Group (TOGAF) pertama kali dikembangkan pada tahun 1995 dan didasarkan pada Kerangka Arsitektur Teknis Departemen Pertahanan untuk Manajemen Informasi. TOGAF berfokus pada aplikasi bisnis missioncritis yang menggunakan blok bangunan sistem terbuka. “Elemen kunci TOGAF adalah Architecture Development Method (ADM) yang menentukan proses pengembangan arsitektur enterprise”. TOGAF menjelaskan peraturan untuk mengembangkan prinsip-prinsip yang baik, daripada menyediakan seperangkat prinsip arsitektur. Tiga tingkat prinsip mendukung pengambilan keputusan di seluruh perusahaan; memberikan panduan sumber daya TI; dan mendukung prinsip-prinsip arsitektur untuk pengembangan dan implementasi.

B. Karakteristik Togaf

Sebagai kerangka kerja perancangan arsitektur, TOGAF memiliki beberapa karakteristik, antara lain:

1. Termasuk dalam 3 kerangka kerja perancangan arsitektur yang paling sering  digunakan (Schekkerman, 2003).

2. Merupakan kerangka kerja yang bersifat open-standard.

3. Bersifat netral –> fits all

4. Diterima oleh masyarakat internasional secara luas –> fits all

5. Pendekatannya bersifat menyeluruh (holistic).

6. Dibutuhkan metode yang fleksibeluntuk mengintegrasikan unit-unit informasi dan juga sistem informasi dengan platform dan standar yang berbeda-beda.

7. TOGAF mampu untuk melakukan integrasi untuk berbagai sistem yang berbeda-beda

8. TOGAF adalah kerangka kerja umum dan dimaksudkan untuk digunakan dalam berbagai macam lingkungan, ia menyediakan konten kerangka kerja yang fleksibeldan extensible yang mendasari seperangkat pengiriman arsitektur generik.

9. TOGAF cenderung bersifat generikdan fleksibel karena dapat mengantisipasi segala macam artefak yang mungkin muncul dalam proses perancangan (Resource base TOGAF menyediakan banyak material referensi), standarnya diterima secara luas, dan mampu mengatasi perubahan.

10. Fokus pada siklus implementasi (ADM) dan proses –> process driven

11. Kunci TOGAF adalah metode – TOGAF Architecture Development Method (ADM – Metode Pengembangan Arsitektur) – untuk mengembangkan suatu arsitektur enterprise yang membahas kebutuhan bisnis.

12. TOGAF relatif mudah diimplementasikan –> fits all

13. TOGAF bersifat open source, sehingga bersifat netral terhadap teknologi dari vendortertentu –> fits all

3. TOGAF Enterprise Architecture Category

TOGAF memandang enterprise architecture ke dalam empat kategori. Keempat kategori tersebut adalah:

1. Business Architecture Mendeskripsikan tentang bagaimana proses bisnis untuk mencapai tujuan organisasi.

2. Application Architecture Merupakan pendeskripsian bagaimana aplikasi tertentu didesain dan bagaimana interaksinya dengan apikasi lainnya.

3. Data Architecture Adalah penggambaran bagaimana penyimpanan, pengelolaan dan pengaksesan data pada perusahaan.

4. Technical Architecture Gambaran mengenai infastruktur hardware dan software yang mendukung aplikasi dan bagaimana interaksinya.

C. Struktur dan Komponen TOGAF

 

TOGAF  secara umum memiliki struktur dan komponen sebagai berikut:

1. Architecture Development Method (ADM) Merupakan bagian utama dari TOGAF yang memberikan gambaran rinci bagaimana menentukan sebuah enterprise architecture secara spesifik berdasarkan kebutuhan bisnisnya.

2. Foundation Architecture (Enterprise Continuum) Foundation Architecture merupakan sebuah “framework-within-a-framework” dimana didalamnya tersedia gambaran hubungan untuk  pengumpulan arsitektur yang relevan, juga menyediakan bantuan petunjuk pada saat terjadinya perpindahan abstraksi level yang berbeda. Foundation Architecture dapat dikumpulkan melalui ADM. Terdapat tiga bagian pada foundation architecture yaitu Technical Reference Model,Standard Information dan  Building Block Information Base .

3. Resource Base Pada bagian ini terdapat informasi mengenai guidelines, templates, checklists, latar belakang informasi dan detil material pendukung yang membantu arsitek didalam penggunaan ADM.

D. TOGAF- Architecture Development Method (ADM)

Architecture Development Method (ADM) merupakan metodologi lojik dari TOGAF yang terdiri dari delapan fase utama untuk pengembangan dan pemeliharaan technical architecture dari organisasi. ADM membentuk sebuah siklus yang iteratif untuk keseluruhan proses, antar fase, dan dalam tiap fase di mana pada tiap-tiap iterasi keputusan baru harus diambil. Keputusan tersebut dimaksudkan untuk menentukan luas cakupan enterprise, level kerincian, target waktu yang ingin dicapai dan asset arsitektural yang akan digali dalam enterprise continuum.  ADM merupakan metode yang umum sehingga jika diperlukan pada prakteknya ADM dapat disesuaikan dengan kebutuhan spesifik tertentu, misalnya digabungkan dengan framework yang lain sehingga ADM menghasilkan arsitektur yang spesifik terhadap organisasi. ADM dapat dikenali dengan penggambaran siklus seperti yang ditunjukkan pada gambar 9 yang terdiri dari  langkah sembilan langkah proses. Secara singkat kedelapan fase ADM adalah sebagai berikut:

1. Fase Preliminary: Framework and Principles Merupakan fase persiapan yang bertujuan untuk mengkonfirmasi komitmen dari stakeholder, penentuan framework dan metodologi detil yang akan digunakan pada pengembangan EA.

2. Fase A : Architecture Vision Fase ini memiliki tujuan untuk memperoleh komitmen manajemen terhadap fase ADM ini, memvalidasi prinsip, tujuan dan pendorong bisnis, mengidentifikasi stakeholder. Terdapat beberapa langkah untuk mencapaian tujuan fase ini dengan inputan berupa permintaan untuk pembuatan arsitektur, prinsip arsitektur dan enterprise continuum. Output dari fase ini adalah

(1) pernyataan persetujuan pengerjaan arsitektur yang meliputi: Scope dan konstrain serta rencana pengerjaan arsitektur,

(2) prinsip arsitektur termasuk prinsip bisnis,

(3) Architecture Vision

3. Fase B : Business Architecture Fase B bertujuan untuk (1) memilih sudut pandang terhadap arsitektur yang bersesuaian dengan bisnis dan memilih teknik dan tools yang tepat (2) mendeskripsikan arsitektur bisnis eksisting dan target pengembangannya serta analisis gap antara keduanya. Inputan untuk fase B berasal dari output fase A, sedangkan outputnya adalah revisi terbaru dari hasil ouput fase A ditambah dengan arsitektur bisnis eksisting dan target pengembangannya secara detil serta hasil analisis gap, business architecture report dan kebutuhan bisnis yang telah diperbaharui.

4. Fase C : Information Systems Architectures Tujuan fase ini adalah untuk mengembangkan arsitektur target untuk data dan/atau domain aplikasi. Pada arsitektur data misalkan untuk menentukan tipe dan sumber data yang diperlukan untuk mendukung bisnis dengan cara yang dimengerti oleh stakeholder. Pada arsitektur aplikasi untuk menentukan jenis sistem aplikasi yang dibutuhkan untuk memproses data dan mendukung bisnis.

5. Fase D : Technology Architecture Untuk pengembangan arsitektur teknologi target yang akan menjadi basis implementasi selanjutnya.

6. Fase E : Opportunities and Solutions Secara umum merupakan fase untuk mengevaluasi dan memilih cara pengimplemetasian, mengidentifikasi parameter strategis untuk perubahan, perhitungan cost dan benefit dari proyek serta menghasilkan rencana implementasi secara keseluruhan berikut strategi migrasinya.

7. Fase F : Migration Planning Fase ini bertujuan untuk mengurutkan implementasi proyek berdasarkan prioritas dan daftar tersebut akan menjadi basis bagi rencana detil implementasi dan migrasi.

8. Fase G : Implementation Governance Merupakan tahapan memformulasikan rekomendasi untuk setiap implementasi proyek, membuat kontrak arsitektur yang akan menjadi acuan implementasi proyek serta menjaga kesesuaiannya dengan arsitektur yang telah ditentukan.

9. Fase H : Architecture Change Management Pada akhir fase ini diharapkan terbentuk skema proses manajemen perubahan arsitektur

10. Requirements Management : Bertujuan untuk menyediakan proses pengelolaan kebutuhan arsitektur sepanjang fase pada siklus ADM, mengidentifikasi kebutuhan enterprise, menyimpan lalu memberikannya kepada fase yang relevan.

E. Kelebihan dan Kekurangan TOGAF

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

3.     FEAF

A. Sejarah Federal enterprise architecture (FEAF)

Federal enterprise architecture adalah arsitektur enterprise pemerintah federal. Sebuah enterprise architecture menggambarkan keadaan pada saat ini dan masa depan lembaga, dan menjabarkan rencana untuk transisi dari kondisi saat ini ke keadaan masa depan yang diinginkan. Federal enterprise architecture adalah sebuah karya dalam proses untuk mencapai tujuan tersebut. Hal ini dirancang untuk kemudahan berbagi informasi dan sumber daya di seluruh badan-badan federal, mengurangi biaya, dan memperbaiki keadaan masyarakat.

FEA dibangun dengan menggunakan berbagai macam model referensi, yang mengembangkan taksonomi umum dan ontologi untuk menggambarkan sumber daya IT, ini termasuk: Kinerja reference model, bisnis model reference, layanan komponen model reference, data reference model, dan model referensi teknis.

Pada FEAF  arsitektur yang ada diperuntukkan sebagai reference point untuk memfasilitasi koordinasi yang efektif dan efisien dari proses bisnis yang umum, penyisipan teknologi , aliran inforamsi dan investasi pada Federal Agencies. FEAF menyediakan sebuah struktur untuk mengembangkan, memelihara dan  mengimplementasikan lingkungan operasional pada top-level dan mendukung implementasi dari sistem TI.

Pada gambar tersebut menunjukkan gambaran matriks  5 x 3 FEAF dengan tipe-tipe arsitektur pada sumbu mendatar dan  perspektif pada sumbu lainnya. Hubungan antara produk EA terdapat pada cells matriks.

B. Karakteristik dari FEAF:

1. Merupakan EA Reference Model
2. Standar yang dipakai oleh pemerintahan Amerika Serikat
3. Menampilkan perspektif view yang menyeluruh
4. Merupakan tool untuk perencanaan dan komunikasi.

C.  Struktur komponen FEAF

Struktur komponen FEAF diperuntukkan sebagai reference point untuk memfasilitasi koordinasi yang efektif dan efisien dari proses bisnis, penggunaan teknologi, aliran informasi, dan investasi pada Federal Agencies. FEAF menyediakan sebuah struktur untuk mengembangkan, memelihara dan mengimplementasikan lingkungan operasional di top-level dan mendukung implementasi dari sistem TI. Objektif dari FEAF memungkinkan pemerintahan federal dan organisasinya mencapai hal berikut (Minoli , 2008):

(a) Meningkatkan teknologi dan mengurangi pengeluaran TI yang berlebih di   pemerintahan.

(b) Memfasilitasi integrasi TI dan sharing data antar institusi.

(c) Menggunakan praktik arsitektur yang umum.

(d) Membantu institusi bertemu mandat legislatif Enterprise Architecturenya.

4.   GARTNER

A. Pandangan Gartner mengenai Enterprise Architecture

Menurut Gartner, arsitektur enterprise adalah mengenai menyatukan tiga unsur yaitu pemilik bisnis, spesialis informasi, pelaksana teknologi. Arsitektur enterprise dalam tampilan Gartner adalah tentang strategi bukan tentang teknik. Hal ini difokuskan pada tujuan. Salah satu visi yang memiliki konsekuensi besar adalah di arsitektur bisnis, informasi dan teknik.

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

B. Revisi Proses Model EA Gartner

Gartner Framework Sebuah dokumen pendamping memperkenalkan Gartner EA Framework, yang mengartikulasikan hubungan antara arsitektur bisnis perusahaan, arsitektur informasi perusahaan 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. M EA Gartner merupakan pelengkap yang berharga arsitektur: Bisnis, Informasi, Teknologi dan Solusi. Setiap sudut pandang mewakili konsentrasi yang relevan dengan serangkaian stakeholder. Secara kasar, pada Sudut pandang Bisnis mewakili konsentrasi EA, 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 perusahaan 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 proses 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.

Tabel 1. Kriteria dan Ringkasan Peringkat Metodologi Enterprise Architecture.  

Criteria	Zachman	TOGAF	FEA	Gartner
Taxonomy completes (taksonomi)	4	2	2	1
Process completeness (kelengkapan proses)	1	4	2	3
Reference model guidance (panduan referensi model)	1	3	4	1
Practice guidance (panduan pelaksanaan)	1	2	2	4
Maturity model	1	1	3	2
Business focus (Fokus bisnis)	1	2	1	4
Governance guidance	1	2	3	3
Partitioning guidance (panduan partisi)	1	2	4	3
Prescriptive catalog (katalog yang memberi petunjuk)	1	2	4	2
Vendor neutrality (netralitas vendor)	2	4	3	1
Information availability (ketersediaan informasi)	2	4	2	1
Time to value	1	3	1	4

Tabel 2. Perbandingan Karakteristik  Enterprise Architecture Framework.

Enterprise architecture framework	Characteristic
TOGAF	Enterprise architecture development methodology, History in defence, Open standard, Neutral, Broad acceptance, Holistic perspective, Process/planning tool.
Zachman	Positioning framework, Catogorizing deliverables, Limited usesfulness EA, History in manufacturing, Broad acceptance, Limited holistic Perspect, Planning tool.
FEAF	Enterprise architecture reference framework, History in enterprise architecture planning, US Gov standard, Broad US Gov acceptance, Holistic Perspective, Planning and communication tool.
Gartner Framework	Strategy, Planning and communication tool

Tabel 3. Perbandingan Komponen Enterprise Architecture Framework

Komponen		Framework
	Zachman	TOGAF	FEAF	Gartner
Data
Function
Network	√
People	√
Time	√
Motivation	√
Arsitektur Bisnis		√	√	√
Arsitektur Data		√	√
Arsitektur Aplikasi		√	√
Arsitektur Teknis		√		√
Arsitektur Technology			√
Arsitektur Informasi				√

Kesimpulan

Ketika mempelajari lebih dalam mengenai enterprise architecture, faktanya tidak ada satupun macam dari pendekatan ini yang terlengkap. Untuk beberapa enterprise, tidak ada satupun macam dari metodologi ini benar-benar lengkap dijadikan sebagai suatu solusi. Ada pendekatan lain yang disebut blended metodology yaitu memilih bagian-bagian dari metodologi, memodifikasi, menggabungkan, dan menyusunnya untuk kebutuhan khusus organisasi. Dalam prakteknya EA Framework yang telah ada, tidak ada yang sempurna, masing-masing memiliki kelebihan dan kekurangan. Bahkan penggunaan EA framework di masing-masing enterprise bisa menjadi berbeda. Hal ini tergantung dengan karakteristik dari enterprise itu sendiri, fokus yang ingin dicapai dan lain-lain.

1. Untuk membangun sebuah sistem informasi yang terintegrasi harus menentukan framework yang sesuai dengan kondisi organisasi/institusi yang ada.
2. Komponen utama dalam sebuah framework adalah pandangan, metode, dan pelatihan.

 

 

 

 

 

 

 

 

 

Perbedaan beberapa model pengembangan software

 

1. Agile Software Development Methodology

          Agile development methods merupakan salah satu dari Metodologi pengembangan perangkat lunak yang digunakan dalam pengembangan perangkat lunak. Agile memiliki pengertian bersifat cepat, ringan, bebas bergerak, dan waspada. Sehingga saat membuat perangkat lunak dengan menggunakan agile development methods diperlukan inovasi dan responsibiliti yang baik antara tim pengembang dan klien agar kualitas dari perangkat lunak yang dihasilkan bagus dan kelincahan dari tim seimbang.

a. Prinsip agile software development

1. Kepuasan klien adalah prioritas utama dengan menghasilkan produk lebih awal dan terus menerus.
2. Menerima perubahan kebutuhan, sekalipun diakhir pengembangan.
3. Penyerahan hasil/software dalam hitungan waktu dua minggu sampai dua bulan.
4. Bagian bisnis dan pembangun kerja sama tiap hari selama proyek berlangsung.
5. Membangun proyek dilingkungan orang-orang yang bermotivasi tinggi yang bekerja dalam lingkungan yang mendukun dan yang dipercaya untuk dapat menyelesaikan proyek.
6. Komunikasi dengan berhadapan langsung adalah komunikasi yang efektif dan efisien.
7. Software yang berfungsi adalah ukuran utama dari kemajuan proyek.
8. Dukungan yang stabil dari sponsor, pembangun, dan pengguna diperlukan untuk menjaga perkembangan yang berkesinambungan.
9. Perhatian kepada kehebatan teknis dan desain yang bagus meningkatkan sifat agile.
10. Kesederhanaan penting.
11. Arsitektur, kebutuhan dan desain yang bagus muncuk dari tim yang mengatur dirinya sendiri.
12. Secara periodik tim evaluasi diri dan mencari cara untuk lebih efektif dan segera melakukannya.

a. Cara bekerja Agile Software Development

    Komposisi tim

Secara umum komposisi dari sebuah tim pengembang perangkat lunak yaitu :

• Owner/ Klien, bersama dengan developer sebagai bagian terpenting dalam proyek, tugas dari klien menentukan fungsi dari perangkat lunak yang akan di buat, melakukan testing dan memberikan feedback.
• Manajer / Scrum Master, bertugas mengkolaborasikan developer dengan klien, membuat dan mengevaluasi target pengerjaan perangkat lunak.
• Sistem Analis, membuat arsitektur sistem dari perangkat lunak yang akan dibuat.
• Developer, merupakan titik vital dalam tim, tanpa developer perangkat lunak tidak akan bisa dibuat.

 Story

Story adalah daftar kebutuhan atau fitur yang nanti akan dibuat. Story berisi apa yang klien kehendaki, dan ditulis dalam bahasa yang dimengerti klien. Dengan kata lain dapat disimpulan Story adalah bagian terpenting dari Scrum.

Story terdiri dari kolom-kolom berikut ini:

• ID – Identifikasi unik, biasanya berupa nomor urut. Hal ini untuk menghindari kehilangan jejak story kalau kita mengganti namanya.
• Nama – Nama story bersifat deskriptif, padat, singkat, dan jelas (2-10 kata), sehingga tim dan klien memahami kira-kira story yang dibicarakan.
• Kepentingan – Derajat kepentingan yang diberikan oleh klien terhadap story. Pemberian derajat kepentingan biasanya menggunakan deret fibonacci (1,1,2,3,5,dst). Semakin tinggi nilainya maka semakin tinggi pula prioritas pengerjaannya.
• Perkiraan awal – Perkiraan awal tim tentang berapa banyak kerja yang diperlukan untuk mengimplementasikan sebuah story.
• Demo – deskripsi umum bagaimana cara story ini didemokan pada waktu sprint demo (lakukan ini, klik itu, lalu ini akan muncul,dll).

Sprint

Sprint (Rapat perencanaan pembuatan perangkat lunak dilakukan 2-8 minggu sekali), yang perlu diperhatikan saat melaksanakan sprint antara lain :

• Tujuan sprint.
• Daftar anggota tim harus lengkap.
• Sprint backlog (daftar story yang akan diikutkan dalam sprint).
• Tanggal demo yang pasti.
• Tempat dan waktu yang jelas untuk pelaksanaan sprint berikutnya.

Tim akan melakukan sprint secara simultan sampai perangkat lunak selesei dikerjakan, sebagai contoh:

Sprint 1, tim membuat fungsi login,logout dan demo perangkat lunak akan dilakukan 3 minggu kemudian. Setelah dilakukan demo untuk mengevaluasi kerja yang dilakukan tim pada Sprint 1, maka Sprint 1 dianggap selesei. Bahan evaluasi dari Sprint 1 akan dibawa ke Sprint 2 begitu seterusnya sampai aplikasi selesei dikerjakan.

 

a.       Kelebihan dan kerungan Agile Software Development

• Kelebihan:

Beberapa kelebihan dari agile diantaranya :

1. Menambah produktivitas tim.
2. Menambah kualitas perangkat lunak.
3. Menambah kepuasan klien.
4. Menghemat biaya.

• Kekurangan:

1. Agile tidak akan berjalan dengan baik jika komitmen tim kurang.
2. Tidak cocok dalam skala tim yang besar (>20 orang).
3. Perkiraan waktu release dan harga perangkat lunak sulit ditentukan.

2. Rapid Application Development

     Rapid Application Development (RAD) adalah metodologi pengembangan perangkat  lunak yang berfokus pada membangun aplikasi dalam waktu yang sangat singkat. Istilah ini menjadi kata kunci pemasaran yang umum menjelaskan aplikasi yang dapat dirancang dan  dikembangkan dalam waktu 60­90 hari. . Rapid application development menggunakan metode iteratif (berulang) dalam mengembangkan sistem di mana working model (model bekerja) sistem dikonstruksikan di awal tahap pengembangan dengan tujuan menetapkan kebutuhan (requirement) user dan selanjutnya disingkirkan.

a.       Cara bekerja RAD

Metodelogi RAD  mengunakan  Prototyping dan Throw­away Prototyping

• RAD Prototyping

Karena keunggulan metode ini menggabungkan teknik SDLC, Prototyping, teknik joint application development (JAD)   dan computer aided software engineering (CASE  Tools) yang bertujuan untuk membuat system dalam waktu singkat ( kurang dari 6 bulan ).  Pada  gambar 2 diatas Metodologi prototyping melakukan analisis, desain dan implementasi secara   bersamaan untuk menghadirkan sebuah sistem dengan skala kecil dalam fungsi  minimal  kemudian di review oleh user untuk dilakukan proses development secara berulang  hingga menghasilkan  sebuah system.

• RAD Throw-away Prototyping

 Untuk gambar 3 adalah metode Throwaway Prototyping, pada metodologi ini Analisa  dilakukan lebih mendalam, prototype dibuat dan ditest, pengalaman yang diperoleh dari latihan ini digunakan untuk membuat produk finalnya, tetapi prototype­nya sendiri dibuang.

b.      Model RAD

Model RAD mengadopsi model waterfall dan pembangunan dalam waktu singkat yang dicapai dengan menerapkan :

1. Component based construction ( pemrograman berbasis komponen bukan prosedural).

2. Penekanan pada penggunaan ulang (reuse) komponen perangkat lunak yang telah ada.

3. Pembangkitan kode program otomatis/semi otomatis.

4. Multiple team (banyak tim), tiap tim menyelesaikan satu tugas yang selevel tetapi tidak sama. Banyaknya tim tergantung dari area dan kompleksitasnya sistem yang dibangun.

Jika keutuhan yang diinginkan pada tahap analisis kebutuhan telah lengkap dan jelas, maka waktu yang dibutuhkan untuk menyelesaikan secara lengkap perangkat lunak yang dibuat adalah berkisar 60 sampai 90 hari. Model RAD hampir sama dengan model waterfall, bedanya siklus pengembangan yang ditempuh model ini sangat pendek dengan penerapan teknik yang cepat.

c. Kelebihan dan keuntungan RAD

• Kelebihan

1.Sangat berguna dilakukan pada kondisi user tidak memahami  kebutuhankebutuhan apa saja yang digunakan pada proses pengembangan perangkat lunak.

2.RAD mengikuti tahapan pengembangan sistem sepeti umumnya, tetapi  mempunyai kemampuan untuk menggunakan kembali komponen yang ada  (reusable object) sehingga pengembang tidak perlu membuat dari awal lagi  dan waktu lebih singkat berkisar antara 60 hari­90 hari.

3.Karena mempunyai kemampuan untuk menggunakan komponen yang su dah  ada dan waktu yang lebih singkat maka membuat biaya menjadi lebih rendah  dalam menggunakan RAD.

• Kekurangan

1.Proyek yang berskala besar, RAD memerlukan sumber daya manusia yang  memadai untuk menciptakan jumlah tim yang baik.

2.RAD menuntut pengembang dan pelanggan memiliki komitmen dalam  aktivitas rapid fire yang diperlukan untuk melengkapi sebuah sistem dalam waktu yang singkat. Jika komitmen tersebut tidak ada maka proyek RAD akan  gagal.

3. Dynamic System Development Model Methodology

Merupakan Metodologi Pengembangan Software yang dikembangkan oleh Konsorsium Vendor dan Para Expert dalam bidang pengembangan Sistem Informasi(IS) di United Kingdom pada tahun 1990 dan pertamakali go public pada tahun 1995. Metodologi ini merupakan pengembangan tahap lanjut dari metode Rapid Application Development (RAD) yang sangat menerapkan  metode incremental dan iteratif. metode ini sangat ideal digunakan ketika suatu software dituntut untuk sangat fokus dan mementingkan tampilan yang mudah dan aspek kegunaan yang baik dari produk tersebut.

DSDM memperbaiki biaya, kualitas dan waktu sejak awal dan menggunakan prioritas MoSCoW dalam lingkup menjadi musts , shoulds , coulds dan tidak akan dapat menyesuaikan deliverable proyek untuk memenuhi batasan waktu yang disebutkan. DSDM adalah salah satu dari sejumlah metode Agile untuk mengembangkan solusi perangkat lunak dan non-TI, dan ini merupakan bagian dari Agile Alliance.

a.       Prinsip DSDM

Ada delapan prinsip yang mendasari DSDM Atern. Prinsip-prinsip ini mengarahkan tim dalam sikap yang harus mereka ambil dan pola pikir yang harus mereka adopsi agar dapat disampaikan secara konsisten.

1.     Fokus pada kebutuhan bisnis

2.     Kirim tepat waktu

3.     Berkolaborasi

4.     Jangan kompromi kualitas

5.     Bangun secara bertahap dari fondasi yang kuat

6.     Kembangkan secara iteratif

7.     Berkomunikasi terus menerus dan jelas

8.     Tunjukkan kontrol

 

b.      Kelebihan dan kelemahan DSDM

1.      Kelebihan:

1.      Menyajikan kerangka kerja (framework) untuk membangun dan memelihara sistem dalam waktu yang terbatas melalui penggunaan prototyping yang incremental dalam lingkungan yang terkondisikan.

2.      Membangun software dengan cepat.

3.      DSDM dapat dikombinasikan dengan XP menghasilkan kombinasi model proses yang mengikuti DSDM dan praktek yang sejalan dengan XP

2.      Kekurangan:

1.      Setiap iterasi bergantung pada prototype sebelumya.

2.      Menentukan scope dari suatu prototype proyek tidak pernah selesai.

3.      Dokumentasi sering kali tidak lengkap fokus pada pembuatan prototype.

4.      Isu-isu mengenai system backup and recovery, system performance dan system security kurang/tidak diperhatikan dan sering terlupakan.

 

4.      Extreme programming methodology

Metodologi pengembangan perangkat lunak yang ditujukan untuk meningkatkan kualitas perangkat lunak dan daya tanggap terhadap perubahan kebutuhan pelanggan. Sebagai jenis pengembangan perangkat lunak tangkas , ini sering menganjurkan “rilis” dalam siklus pengembangan singkat, yang dimaksudkan untuk meningkatkan produktivitas dan mengenalkan pos pemeriksaan di mana persyaratan pelanggan baru dapat diadopsi. Metodologi ini mengambil namanya dari gagasan bahwa unsur-unsur yang menguntungkan dari praktik rekayasa perangkat lunak tradisional dibawa ke tingkat “ekstrim”. Sebagai contoh, review kode dianggap sebagai praktik yang bermanfaat; Yang diambil secara ekstrem, kode bisa ditinjau terus menerus , yaitu praktek pemrograman pair .

a.       Prinsip EPM:

1.Rapid Feedback Menurut ilmu psikologi, waktu antara sebuah aksi dengan feedbacknya sangat penting untuk dipelajari. Dalam sebuah proyek XP, developer memperoleh feedback sesegera mungkin, menginterpretasikannya, lalu mengambil inti sarinya dan meletakkannya ke dalam system. Feedback dari pelanggan terhitung harian, bukan bulanan, dan feedback dari developer terhitung menitan, bukan mingguan.

2.Assume Simplicity Hanya mendesain untuk masalah saat ini dan menghemat waktu 98% dari masalah tersebut dan hanya menekuni sekitar 2% untuk bagian yang sulit. XP berencana untuk masa depan sehingga desainnya bias di-reuse, lakukan pekerjaan yang penting, dan percayalah bahwa untuk kekompleksitasan bias ditambahkan kemudian.

3.Incremental Change Pemecahan problem yaitu dengan bagian-bagian kecil perubahan saja. Jadi perubahan-perubahan yang terjadi pada XP melalui tahap-tahap kecil dan waktu yang singkat.

4.Embracing Change Mencari dan menyediakan terlebih dahulu sebanyak mungkin pilihan ketika menyelesaikan masalah yang begitu menekan.

5.Quality Work setiap orang suka mengerjakan pekerjaan yang bagus dan layak dan kualitas yang dimaksud di sini adalah kualitas yang sempurna dan kualitas yang sempurna secara ekstrim. Karena tanpa kualitas kita tidak akan suka melakukan pekerjaan tersebut, hasilnya tidak akan sempurna dan proyeknya akan jatuh berantakan.

b.      Kelebihan dan kekurangan EPM

• Kelebihan:

1. Komunikasi dalam XP dibangun dengan melakukan pemrograman berpasangan (pair programming). Developer didampingi oleh pihak klien dalam melakukan coding dan unit testing sehingga klien bisa terlibat langsung dalam pemrograman sambil berkomunikasi dengan developer. Selain itu perkiraan beban tugas juga diperhitungkan.

2.Setiap feed Developer harus selalu siap dengan perubahan karena perubahan akan selalu diterima. back ditanggapi dengan melakukan tes, unit test atau system integration dan jangan menunda karena biaya akan membengkak (uang, tenaga, waktu).

3. Banyak ide baru dan berani mencobanya, berani mengerjakan kembali dan setiap kali kesalahan ditemukan, langsung diperbaiki.

4.Menjalin komunikasi yang baik dengan klien. (Planning Phase).

5.Menurunkan biaya pengembangan (Implementation Phase).

6.Meningkatkan komunikasi dan sifat saling menghargai antar developer.                             (Implementation Phase).

• Kekurangan:

1.Developer harus selalu siap dengan perubahan karena perubahan akan selalu                diterima.

2. Tidak bisa membuat kode yang detail di awal (prinsip simplicity dan juga                          anjuran untuk melakukan apa yang diperlukan hari itu juga).

5. Scrum Development Methodology

Scrum merupakan framework untuk manajemen pengembangan software dengan karakteristik cekatan dan bersifat iteratif dan incremental. Scrum mendefinisikan dirinya fleksible, strategi pengembangan yang menyeluruh di mana seluruh team bekerja sebagai satu unit dalam mencapai sebuah gol yang sama. Prinsip kunci dari scrum adalah memahami bahwa dalam project yang tengah berlangsung, klien mungkin mengubah apa yang menjadi kebutuhan dan keinginannya. Perubahan sulit diadaptasi oleh framework pengembangan aplikasi yang bersifat tradisional.  Scrum menerima perubahan ini dan memaksimalkan seluruh anggota team untuk menyesuaikan perubahan mendadak ini.

a. Prinsip Scrum:

1.Ukuran tim yang kecil melancarkan komunikasi, mengurangi biaya, dan                            memberdayakan satu sama lainProses dapat beradaptasi terhadap perubahan teknis        dan bisnis.

2. Proses menghasilkan beberapa software increment.

3. Pembangunan dan orang yang membangun dibagi dalam tim yang kecil.

4.Dokumentasi dan pengujian terus menerus dilakukan setelah software dibangun.

5.Proses scrum mampu menyatakan bahwa produk selesai kapanpun diperlukan.

c.       Kelebihan dan kekurangan :

•  Kelebihan:

1. Keperluan berubah dengan cepat.

2 .Tim berukuran kecil sehingga melancarkan komunikasi, mengurangi biaya dan                 memberdayakan satu sama lain.

3.Pekerjaan terbagi-bagi sehingga dapat diselesaikan dengan cepat.

4.Dokumentasi dan pengujian terus menerus dilakukan setelah software dibangun.

5.Proses Scrum mampu menyatakan bahwa produk selesai kapanpun diperlukan

• Kekurangan:

Developer harus selalu siap dengan perubahan karena perubahan akan selalu                   diterima.

 

 

 

 

 

 

 

Macam-macam sistem operasi

1.         MacOS

           MacOS (singkatan Macintosh) merupakan salah satu sistem operasi ekslusif yang dikeluarkan oleh perusahaan Apple Inc. dan hanya terdapat di komputer apple saja. MacOS diluncurkan pada tahun 1984 dan pertama kali digunakan oleh computer LISA. Sistem operasi ini merupakan pengembangan dari dasar sistem operasi Linux.

           Dalam perkembangannya, MacOS diganti dengan versi terbarunya yaitu MacOS X , dimana ‘X’ artinya angka romawi 10, versi ini adalah penerus dari system operasi yg digunakan sebelumnya yaitu MacOS 8 dan MacOS 9. MacOS X dikeluarkan pada tahun 2001 dan popular dikalangan pengguna.

Perkembangan MacOS dari waktu ke waktu:

1. Mac OS System 1 (1984)
2. Mac OS System 2 (1985 )
3. Mac OS System 3 (1986)
4. Mac OS System 4 (1987)
5. Mac OS System 5 (1987)
6. Mac – OS System 6 (1988)
7. Mac OS System 7 (1991)
8. Mac OS 8(1997)
9. Mac OS 9 (1999)
10. Mac OS X /Cheetah (2001)
11. Mac OS X /Puma (2001)
12. Mac OS X /Jaguar (2002)
13. Mac OS X /Panther (2003)
14. Mac OS X /Tiger (2005)
15. Mac OS X /Leopard (2007)
16. Mac OS X /Snow Leopard (2009)
17. Mac OS X /Lion (2011)
18. Mac OS X /Mountain Lion (2012)
19. Mac OS X /Maverick (2013)
20. Mac OS X /Yosemite (2014)

 

Kelebihan :

1. Tampilannya lebih indah dibanding sistem operasi lainnya.
2. Sistem lebih stabil karena menggunakan UNIX
3. Tingkat keamanannya tinggi, sehingga sulit terkena virus atau diretas.

Kekurangan :

1. Karena Apple sudah tidak memberi license buat perusahaan lain untuk membuat hardware yang bisa menggunakan Mac OS, jadi MacOS tidak bisa dirakit.
2. Harga nya termasuk dalam kategori mahal.
3. Software di MacOS tidak terlalu lengkap.

 

2.         Linux

              Nama “Linux” berasal dari nama pembuatnya, yang diperkenalkan tahun 1991 oleh Linus Torvalds. Sistemnya, peralatan sistem dan pustakanya umumnya berasal dari sistem operasi GNU, yang diumumkan tahun 1983 oleh Richard Stallman. Kontribusi GNU adalah dasar dari munculnya nama alternatif GNU/Linux.

             Linux merupakan system operasi computer bertipe unix, Linux juga merupakan system operasi open source yang popular dikalangan masyarakat dunia dengan tingkat kepopuleran di bawah Windows dan Mac OS. Karena open source Linux dapat dimodifikasi, digunakan dan didistribusikan kembali secara bebas oleh siapa saja.

Beberapa distro linux dari waktu ke waktu:

1.  Red Hat
2.  Debian
3.  Slackware
4.  SuSE
5.  Mandrake
6.  WinLinx
7.  Ubuntu dan turunannya : Sabily (Ubuntu Muslim Edition), Kubuntu, Xubuntu,   Edubuntu, GoBuntu, Gnewsense, ubuntuCE
8.  OpenSUSE
9.  Fedora
10.  BackTrack
11.  Mandriva
12.  Slackware
13.  Debian
14.  PCLinuxOS
15.  Knoppix
16.  Xandros
17.  Sabayon
18.  CentOS
19.  Red Hat
20.  ClearOS
21.  Chrome OS
22.  Gentoo Linux

Kelebihan :

1.  Tidak ada biaya lisensi untuk membeli dan menggunakannya karena open source.
2.  Tingkat keamanan dan kestabilannya tinggi.
3.  Banyak orang yang mengembangkannya , jadi perkembangannya sangat pesat.

Kekurangan :

1.  Tidak semua support hardware cocok di Linux.
2.  Banyak orang yang kesulitan mengunakan Linux, karena tidak terbiasa.
3.  Proses instalasi nya sulit, termasuk software nya.

 

3.         Android

             Android, Inc. didirikan di Palo Alto, California, pada bulan Oktober 2003 oleh Andy Rubin (pendiri Danger), Rich Miner (pendiri Wildfire Communications, Inc.), Nick Sears (mantan VP T-Mobile), dan Chris White (kepala desain dan pengembangan antarmuka WebTV) untuk mengembangkan “perangkat seluler pintar yang lebih sadar akan lokasi dan preferensi penggunanya”.  Kemudian pada tahun 2005 android dibeli oleh perusahaan google.

             Android merupakan system operasi berbasis Linux untuk smartphone. Semua perusahaan vendor smartphone pasti akan menggunakan Android sebagai OSnya  karena sistem operasi ini bersifat open source.

Berikut merupakan perkembangan android dari waktu ke waktu:

Versi	Nama kode	Tanggal rilis	Level API	Distribusi
7.0	Nougat	22 Agustus 2016	24	Kurang dari 0.1%
6.0	Marshmallow	19 Agustus 2015	23
5.x	Lollipop	15 Oktober 2014	21
4.4.x	KitKat	31 Oktober 2013	19	24,5%
4.3.x	Jelly Bean	24 Juli 2013	18	8%
4.2.x	Jelly Bean	13 November 2012	17	20,7%
4.1.x	Jelly Bean	9 Juli 2012	16	25,1%
4.0.3–4.0.4	Ice Cream Sandwich	16 Desember 2011	15	9,6%
3.2	Honeycomb	15 Juli 2011	13
3.1	Honeycomb	10 Mei 2011	12
2.3.3–2.3.7	Gingerbread	9 Februari 2011	10	11,7%
2.3–2.3.2	Gingerbread	6 Desember 2010	9
2.2	Froyo	20 Mei 2010	8	0,7%
2.0–2.1	Eclair	26 Oktober 2009	7
1.6	Donut	15 September 2009
1.5	Cupcake	30 April 2009	3

 

Kelebihan :

1.  Mudah dikustomisasi oleh penggunanya.
2.  Bersifat open source.
3.  Sistemnya fleksibel dan dapat diperbarui.

Kekurangan :

1.  Lebih lambat untuk pembaruan perangkat penggunanya dibandingkan dengan         sistem operasi saingan utamanya yaitu iOS
2. Sangat rentan terkena virus karena sifatnya yang open source.
3. System memakan banyak memori internal.