Gallery

Senin, 21 Mei 2018
TIME 05.40
no image


The Open Group Architecture Framework (TOGAF) adalah sebuah framework untuk arsitektur enterprise yang menyediakan sebuah pendekatan komprehensif untuk mendesain, merencanakan, menerapkan dan mengelola arsitektur informasi enterprise.

1.Apa itu Sertifikasi TOGAF?


sertifikasi TOGAF adalah suatu program sertifikasi yang berupa pelatihan untuk validasi bahwa anda mempunyai pengetahuan, mampu menganalisa dan menerapkan pengetahuan TOGAF tersebut. Adapun fokus pada sertifikasi ini yaitu penerapan serta analisa pengetahuan dan pemahaman. Program pelatihan ini terakreditasi baik.

2.Mengapa Sertifikasi TOGAF itu penting?


Arsitektur TI memperoleh pengakuan yang semakin meningkat di seluruh perusahaan untuk kebutuhan bisnis. TOGAF adalah kerangka kerja, standar industri terbuka 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 TOGAF memungkinkan organisasi besar (baik swasta maupun sektor publik) membakukan metode terbuka ini untuk Arsitektur TI. Ini merupakan langkah penting dalam membuat  Arsitektur TI yang diakui, dan dalam memperkenalkan ketelitian dalam pengadaan alat dan layanan untuk Arsitektur TI.



3.Apa Saja Isi Sertifikasi TOGAF?


1. Introduction (Pengenalan)

    1.1. Certification Document Structure

    1.2. The Certification Process

2. Preliminary Phase (Tahap Awal)

    2.1. Scope the Enterprise Organizations Impacted

    2.2. Confirm Governance and Support Frameworks

    2.3. Define and Establish the Enterprise Architecture Team and Organization

    2.4. Identify and Establish Architecture Principles

    2.5. Tailor TOGAF and, if any, Other Selected Architecture Frameworks

    2.6. Implement Architecture Tools

3. Phase A: Architecture Vision (Visi Arsitektur)

    3.1. Establish the Architecture Project

    3.2. Identify Stakeholders, Concerns, and Business Requirements

    3.3. Confirm and Elaborate Business Goals, Business Drivers, and Constraints

    3.4. Evaluate Business Capabilities

    3.5. Assess Readiness for Business Transformation

    3.6. Define Scope

    3.7. Confirm and Elaborate Architecture Principles, including Business Principles

    3.8. Develop Architecture Vision

    3.9. Define the Target Architecture Value Propositions and KPIs

    3.10. Identify the Business Transformation Risks and Mitigation Activities

    3.11. Develop Statement of Architecture Work; Secure Approval

4. Phase B: Business Architecture (Arsitektur Bisnis)

    4.1. Select Reference Models, Viewpoints, and Tools

    4.2. Develop Baseline Business Architecture Description

    4.3. Develop Target Business Architecture Description

    4.4. Perform Gap Analysis

    4.5. Define Candidate Roadmap Components

    4.6. Resolve Impacts across the Architecture Landscape

    4.7. Conduct Formal Stakeholder Review

    4.8. Finalize the Business Architecture

    4.9. Create the Architecture Definition Document

5. Phase C: Information Systems Architectures (Arsitektur Sistem Informasi.)

    5.1. Considerations for the Implementation Order

6. Phase C: Data Architecture (Arsitektur Data)

    6.1. Select Reference Models, Viewpoints, and Tools

    6.2. Develop Baseline Data Architecture Description

    6.3. Develop Target Data Architecture Description

    6.4. Perform Gap Analysis

    6.5. Define Candidate Roadmap Components

    6.6. Resolve Impacts Across the Architecture Landscape

    6.7. Conduct Formal Stakeholder Review

    6.8. Finalize the Data Architecture

    6.9. Create Architecture Definition Document

7. Phase C: Application Architecture (Arsitektur Aplikasi)

    7.1. Select Reference Models, Viewpoints, and Tools

    7.2. Develop Baseline Application Architecture Description

    7.3. Develop Target Application Architecture Description

    7.4. Perform Gap Analysis

    7.5. Define Candidate Roadmap Components

    7.6. Resolve Impacts Across the Architecture Landscape

    7.7. Conduct Formal Stakeholder Review

    7.8. Finalize the Application Architecture

    7.9. Create Architecture Definition Document

8. Phase D: Technology Architecture (Arsitektur Teknologi)

    8.1. Select Reference Models, Viewpoints, and Tools

    8.2. Develop Baseline Technology Architecture Description

    8.3. Develop Target Technology Architecture Description

    8.4. Perform Gap Analysis

    8.5. Define Candidate Roadmap Components

    8.6. Resolve Impacts Across the Architecture Landscape

    8.7. Conduct Formal Stakeholder Review

    8.8. Finalize the Technology Architecture

    8.9. Create Architecture Definition Document

9. Phase E: Opportunities & Solutions (Peluang & Solusi)

    9.1. Determine/Confirm Key Corporate Change Attributes

    9.2. Determine Business Constraints for Implementation

    9.3. Review and Consolidate Gap Analysis Results from Phases B to D

    9.4. Review Consolidated Requirements Across Related Business Functions

    9.5. Consolidate and Reconcile Interoperability Requirements

    9.6. Refine and Validate Dependencies

    9.7. Confirm Readiness and Risk for Business Transformation

    9.8. Formulate Implementation and Migration Strategy

    9.9. Identify and Group Major Work Packages

    9.10. Identify Transition Architectures

    9.11. Create the Architecture Roadmap & Implementation and Migration Plan

10. Phase F: Migration Planning (Perencanaan Migrasi)

    10.1. Confirm Management Framework Interactions for the Implementation and Migration Plan

    10.2. Assign a Business Value to Each Work Package

    10.3. Estimate Resource Requirements, Project Timings, and Availability/Delivery Vehicle

    10.5. Prioritize the Migration Projects through the Conduct of a Cost/Benefit Assessment and Risk Validation

    10.6. Confirm Architecture Roadmap and Update Architecture Definition Document

    10.7. Generate the Implementation and Migration Plan

    10.8. Complete the Architecture Development Cycle and Document Lessons Learned

11. Phase G: Implementation Governance (Pemerintahan Implementasi)
 
    11.1. Confirm Scope and Priorities for Deployment with Development Management

    11.2. Identify Deployment Resources and Skills

    11.3. Guide Development of Solutions Deployment

    11.4. Perform Enterprise Architecture Compliance Reviews

    11.5. Implement Business and IT Operations

    11.6. Perform Post-Implementation Review and Close the Implementation

12. Phase H: Architecture Change Management (Ubah Manajemen)

    12.1. Establish Value Realization Process

    12.2. Deploy Monitoring Tools

    12.3. Manage Risks

    12.4. Provide Analysis for Architecture Change Management

    12.5. Develop Change Requirements to Meet Performance Targets

    12.6. Manage Governance Process

    12.7. Activate the Process to Implement Change

13. ADM Architecture Requirements Management (Persyaratan Manajemen ADM)

    13.1. The Inputs to the Requirements Management Process

    13.2. The Steps and Their Correspondence to Phases

    13.3. Corresponding Requirements Management Steps to ADM Phases

    13.4. The Purpose of the Outputs of Requirements Management

14. Iteration and Levels (Level dan Perulangan)

    14.1. The Concept of Iteration

    14.2. Factors Influencing the Use of Iteration

    14.3. Iteration Cycles

    14.4. Classes of Architecture Engagement

    14.5. Mapping TOGAF Phases to Iteration Cycles

    14.6. Applying the ADM across the Architecture Landscape

15. Security (Keamanan)

    15.1. Adapting the ADM for Security

    15.2. Security Input/Output Summary

16. SOA (Arsitektur Berorientasi Layanan)

    16.1. SOA as an Architectural Style

    16.2. Enterprise Architecture and SOA

    16.3. Adapting the ADM for SOA

17. Architecture Content Framework (Kerangka Kerja Arsitektur)

    17.1. The Content Framework and the TOGAF ADM

    17.2. Why do we Need a Metamodel?

    17.3. Components of the Content Metamodel

    17.4. Core Metamodel Concepts

18. Architecture Partitioning (Partisi Arsitektur)

    18.1. Applying Classification to Partitioned Architectures

    18.2. Applying Partitioning to the ADM

19. Architecture Repository (Pemaketan Arsitektur)

    19.1. The Repository in Detail

    19.2. Relationship to Other Parts of TOGAF

20. The Technical Reference Model (TRM)

    20.1. Structure of the TRM

    20.2. Th e TRM in Detail

    20.3. Taxonomy of Application Platform Services

    20.4. Taxonomy of Application Platform Service Qualities

    20.5. Using the TRM

21. Integrated Information Infrastructure (Infrastruktur Informasi Terpadu)

    21.1. Reference Model (III-RM)

    21.2. Drivers for Boundaryless Information Flow

    21.3. How the III-RM Fulfi lls the Solution Space

    21.4. The High-Level Structure of the III-RM

    21.5. Components of the III-RM

22. Architecture Governance (Tata Kelola Arsitektur)

    22.1. Architecture Governance and the ADM

    22.2. Key Success Factors

    22.3. Setting up the Architecture Board

    22.4. Operating an Architecture Board

23. Architecture Maturity Models (Model Kematangan Arsitektur)

    23.1. Capability Maturity Models

    23.2. Capability Maturity Model Integration (CMMI)

    23.3. ACMM

    23.4. Maturity Assessments and the ADM

24. Architecture Skills Framework (Kerangka Kerja Arsitektur)

    24.1. Purpose

    24.2. Benefits

    24.3. EA Roles, Skills Categories, and Proficiency Levels

4. Berapa Hari Untuk Mengikuti Sertifikasi Dan Berapa Biayanya?
Untuk Mengikuti Sertifikasi Hanya Membutuhkan Waktu 1 Hari, Dengan Biaya Yang Cukup Bervariasi,Biaya Nya Sebagai Berikut:
  • 4.050.000,- (Pendaftaran 3 Orang / Lebih, Pembayaran 1 Minggu Sebelum Pelatihan)
  • 4.300.000,- (Reg 2 Minggu Sebelum Pelatihan, Pembayaran 1 Minggu Sebelum Pelatihan)
  • 4.750.000,- (On The Spot, Pembayaran Di Akhir Pelatihan)
  • 5.145.000,- (Full Fare)
5. Jadwal Sertifikasi TOGAF Di Indonesia Sepanjang 2018?
Jadwal Sertifikasi TOGAF Di Indonesia Tahun 2018,Jadwal Nya Sebagai Berikut:

  • 09 – 10 Februari 2018 |Rp. 5.145.000,- Di Ashely Hotel/ Amaris La Codefin Kemang, Jakarta
  • 30 – 31 Mei 2018 | Rp. 5.145.000,- Di Ashely Hotel/ Amaris La Codefin Kemang, Jakarta
  • 17 – 18 September 2018 | Rp. 5.145.000,- Di Ashely Hotel/ Amaris La Codefin Kemang, Jakarta
  • 02 – 03 November 2018 | Rp. 5.145.000,- Di Ashely Hotel/ Amaris La Codefin Kemang, Jakarta

Filled
0
Unknown
Read More
Jumat, 20 April 2018
TIME 05.03
no image

Pada postingan kali ini, saya akan memberikan pembahasan mengenai Apa itu, Manfaat , Bagian bagian dan Mengapa harus memakai  The Open Group Architecture Framework (TOGAF).

TOGAF atau The Open Group Architecture Framework adalah suatu kerangka kerja arsitektur perusahaan yang memberian pendekatan komprehensif untuk desain, perencanaan, implementasi, dan tata kelola arsitektur informasi perusahaan. Arsitektur ini biasanya dimodelkan dengan empat tingkat atau domain; bisnis, aplikasi, data, dan teknologi.

TOGAF (The Open Group Architecture Framework) muncul dengan cepat dan merupakan kerangka kerja serta metode yang dapat diterima secara luas dalam pengembangan arsitektur perusahaan. Berawal dari Technical Architecture for Information Management atau (TAFIM) di Departemen Pertahanan Amerika Serikat, kerangka kerja itu diadopsi oleh Open Group pada pertengahan 1990an. Spesifikasi pertama TOGAF diperkenalkan pada tahun 1995, dan TOGAF 8 (Enterprise Edition) dirilis pada awal 2004. Pada saat ini sudah ada TOGAF 9 yang secara keseluruhan melengkapi versi sebelumnya. TOGAF memberikan metode yang detil tentang bagaimana membangun dan mengelola serta mengimplementasikan arsitektur enterprise dan sistem informasi yang disebut dengan ADM (Architecture Development Method).

 

MENGAPA PERLU MENGGUNAKAN TOGAF ?

Pada saat penyusunan arsitektur sistem informasi di organisasi yang cukup besar dan memiliki proses yang cukup rumit, kita harus menggunakan tools, tidak bisa hanya menggunakan keinginan sendiri.Dengan semakin berkembangnya teknologi IT dan best practice, ada banyak template yang dapat kita gunakan untuk menyusun strategi IT kita.Kebanyakan industri menggunakan framework yang general seperti TOGAF ini.Suatu framework itu lebih baik bisa mengcover satu framework yang lain atau memiliki interoperabilitas antar framework. Saling melengkapi satu framework dengan framework lainnya.

TOGAF memiliki pandangan sendiri, yang dapat ditentukan baik sebagai deskripsi formal dari suatu sistem, atau rencana rinci  dari  sistem  pada  tingkat  komponen  untuk  memandu  pelaksanaan,  atau  sebagai struktur  komponen,  hubungannya, prinsip-prinsip dan pedoman yang mengatur desain dan evolusi.

 

PADA SAAT BAGAIMANA TOGAF DIPERLUKAN ?

Togaf diperlukaan saat dimana perusahaan membutuhkan sebuah perencanaan strategis sistem informasi untuk menjawab permasalahan permasalahan yang saat ini masih terjadi pada perusahaan tersebut. Dengan bagian inti TOGAF, yaitu TOGAF ADM (Architecture Development Method). Dengan ini menghindarkan dari kepanikan pada saat membuat arsitektur yang kompleks, sistematis, terdapat fungsi-fungsi baseline resource, dan memberikan starting point untuk pembuatan arsitekturnya.

 

MANFAAT MENGGUNAKAN TOGAF ?

Setiap organisasi berusaha untuk mendesain dan implementasi arsitektur enterprise untuk mendukung aplikasi bisnis mission-critical, dengan menggunakan blok bangunan sistem terbuka.

Suatu perusahaan yang merancang dan mengimplementasikan arsitektur enterprise menggunakan TOGAF dipastikan bahwa desain dan spesifikasi pengadaan yang akan sangat memudahkan implementasi sistem terbuka, dan akan memungkinkan manfaat dari sistem terbuka bertambah untuk organisasi mereka dengan menurunkan risiko.

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

 

BAGIAN BAGIAN DARI TOGAF ?

TOGAF Architecture Development Method (ADM)

yang menjelaskan cara untuk mendapatkan suatu arsitektur enterprise organisasi-spesifik yang membahas kebutuhan bisnis. ADM menyediakan :

Views arsitektur yang memungkinkan arsitek untuk memastikan bahwa permasalahan kompleks dapat ditangani

Dapat diandalkan, terbukti dapat mengembangkan arsitekturKaitan dengan studi kasus praktis

Pedoman alat untuk pengembangan arsitektur

The Enterprise Continuum, yang merupakan “gudang virtual” dari semua aset arsitektur, model, pola, deskripsi arsitektur, dll – yang ada baik di dalam perusahaan dan di industri TI pada umumnya, dimana perusahaan yang menganggap dirinya telah tersedia untuk mengembangkan arsitektur

Resource Base, terdapat informasi mengenai guidelines, templates, checklists, dan latar belakng informasi. Selain itu, terdapat material pendukung yang dapat membantu arsitek di dalam penggunaan ADM.

 

PENDAPAT SAYA TENTANG TOGAF ?

Menurut saya Togaf merupakan sebuah framework dan metode terperinci sekumpulan perangkat pendukung untuk mengembangkan sebuah arsitektur teknologi informasi perusahaan . Togaf menjadi pelengkap dengan framework lainnya seperti Zachman, FEEAF, Gartner dan lainnya. Sebagai gudang best practice juga Vendor, tools dan teknologi. Framework dan metode yang mencapai boundaryless information flow.

Filled
0
Unknown
Read More
Minggu, 18 Maret 2018
TIME 20.36
no image

Ini Adalah Hasil Rangkuman Kuliah Enterprise Architecture Di Prodi Sistem Informasi UTM (Universitas Trunojoyo Madura). Jadi Disini Saya Akan Menjelaskan Tentang 4 Macam Enterprise Architectute Framework (EAF) yaitu: Zachman Framework ,The Open Group Architecture Framework (TOGAF) ,Federal Enterprise Architecture Framework (FEAF) ,Gartner Framework ,Sebelum membahas ke empat framework tersebut mari kita bahas dulu apa itu Enterprise Architectute Framework (EAF).

Enterprise Architectute Framework (EAF)

Dalam Pengembangan Sebuah Enterprise Architecture Akan Lebih Baik Dan Lebih Mudah Jika Mengikuti Sebuah Kerangka Berpikir Tertentu. Kerangka Berpikir Dalam Pengembangan Enterprise Architecture Tersebut Dikenal Dengan Istilah Enterprise Architecture Framework (Ea Framework). Enteprise Architecture Framework Adalah Suatu Alat Yang Bisa Digunakan Untuk Mengembangkan Cakupan Luas Dari Arsitektur-Arsitektur Yang Berbeda (Cio Council, 2001). Architecture Framework Harus Mendeskripsikan Sebuah Metode Untuk Merancang Sistem Informasi Dalam Term Kumpulan Building Block Dan Memperlihatkan Bagaimana Building Block Tersebut Sesuai Antara Satu Dengan Yang Lainnya. Penggunaan Ea Framework Akan Mempercepat Dan Menyederhanakan Pengembangan Arsitektur, Memastikan Cakupan Yang Lengkap Dari Solusi Desain Dan Memastikan Arsitektur Yang Terpilih Akan Memungkinkan Pengembangan Di Masa Depan Sebagai Respon Terhadap Kebutuhan Binis (Setiawan, Iwan, 2009)

Zachman Framework

merupakan framework enterprise architecture untuk sebuah arsitektur enterprise, dimana framework tersebut memberikan sebuah cara formal dan sangat terstruktur untuk melihat dan mendefinisikan sebuah enterprise. Framework tersebut berisikan matrik klasifikasi 2 dimensional berdasarkan pada interseksi dari 6 pertanyaan komunikasi ( What, Where, When, Why, Who, dan How ) dengan 6 baris untuk ratifikasi transformasi.

Framework Zachman merupakan skema untuk mengorganisir artifak arsitektur ( dengan kata lain, desain document, spesifikasi, dan model ) dimana dibagi menjadi target arfifak ( contoh, pemilik bisnis dan pembangun ) dan beberapa isu ( contoh, data dan fungsionalitas )

TOGAF ( The Open Group Architecture Framework )

merupakan sebuah framework untuk arsitektur enterprise dimana menyediakan pendekatan secara komprehensif untuk mendesain, merencanakan, mengimplementasi dan melakukan control dengan otoritas pada sebuah informasi arsitektur enterprise.

Togaf adalah pendekatan secara holistic untuk mendesain, dimana biasanya dimodelkan dengan 4 tingkat : business, aplikasi, data dan teknologi. Hal tersebut memberikan kelayakan secara menyeluruh sebagai model awal yang dipergunakan sebagai information arsitek, dimana dapat dibangun nantinya. Merupakan modularisasi, standarisasi dan telah tersedia, perbaikan teknologi dan produk.

Federal enterprise architecture ( FEA )

merupakan sebuah arsitektur enterprise dari federal government. FEA menyedikan methodology umum untuk akusisi informasi teknologi, penggunaan dan disposisi dari federal government.

Enterprise architecture ( EA ) merupakan praktek management untuk mengalihkan resource untuk dapat memperbaiki performa bisnis dan membantu agensi pemerintah secara lebih baik di dalam menjalankan misi utama. EA mendeskripsikan tingkat yang ada dan tingkat masa depan untuk agensi, dan memperlihatkan rencana untuk mentransisikan dari tingkat sekarang pada tingkat masa depan. Federal Enterprise Architecture merupakan sebuah pekerjaan yang berkelanjutan untuk mencapai tujuan.

Gartner

Gartner merupakan sebuah riset informasi teknologi dan perusahaan yang menyediakan teknologi yang berhubungan dengan kapasitas pencarian fakta terselubung. Riset yang diberikan oleh gartner bertarget pada CIO dan pemimpin IT senior pada industry dimana menyertakan agen pemerintah, high-technology dan telecom enterprise, professional service firm dan technology inventor. Pelanggan gartner menyertakan korporasi besar, agensi pemerintah, perusahaan teknologi dan komunitas investasi. Perusahaan Gartner berisikan riset, program eksekutif, konsultasi dan acara, memberikan informasi riset, praktek terbaik dan trend.

Perbandingan Dari Ke Empat EA Framework di atas 

Terdapat 12 Kriteria yang digunakan untuk mengevaluasi methodology yang biasa dipergunakan oleh organisasi, beberapa penilaian

Dan Perlu diketahui bahwa penilaian untuk perbandingan tidak selalu cocok, penilaian ini merupakan penilaian pada salah satu jurnal Microsoft

Penilaian dilakukan dengan skala likert ….

Sangat BurukTidak MemadaiBaikSangat Baik

Taxonomy completeness

Mereferensi bagaimana anda dapat menggunakan methodology untuk mengklasifikasi beberapa artefak arsitektural. Merupakan focus keseluruhan zachman. Methodology lain tidak memfokuskan banyak hal pada area ini.

Process completeness

Mereferensi bagaimana methodology memberikan pengarahan kepada anda melalui proses langkah demi langkah di dalam membuat sebuah arsitektur enterprise. Merupakan focus TOGAF pada Architecture Development Method (ADM).

Reference-model guidance

Mereferensi bagaimana kegunaan methodology dapat membantu anda di dalam membangun sebuah kumpulan yang relevan dari model referensi. Merupakan focus dari FEA. TOGAF menyediakan dukungan.

Practice guidance

Mereferensi bagaimana methodology dapat menolong anda di dalam assimilasi pola pikir dari arsitektur enterprise ke dalam organisasi dan membangun kultur/budaya dimana itu bernilai dan dipergunakan. Merupakan Gartner’s practice architectural.

Maturity model

Mereferensi seberapa banyak pengarahan methodology untuk dapat memberikan sebuah penilaian untuk efektifitas dan kematangan dari organisasi lain, dimana pengalaman organisasi di dalam penggunaan arsitektur enterprise.

Business focus

Mereferensi methodology mana yang berfokus pada penggunaan teknologi untuk mendorong nilai bisnis, dimana nilai bisnis merupakan secara spesifik didefinisikan untuk mereduksi pengeluaran dan meningkatkan penerimaan.

Governance guidance

Mereferensi seberapa banyak methodology dapat dengan mudah dimengerti dan membuat sebuah model governance secara efektif untuk enterprise architecture.

Partitioning guidance

Mereferensi bagaimana methodology dapat membantu anda ke dalam efektif otonomi partisi dari enterprise, dimana merupakan pendekatan yang sangat penting untuk mengelolan kompleksitas.

Prescriptive catalog

Mereferensi seberapa baik methodology membantu anda di dalam pengaturan katalog dari asset arsitektural dimana dapat dipergunakan kembali di dalam aktifitas di masa depan.

Vendor neutrality

Mereferensi bagaimana seharusnya dapat dikunci ke dalam organisasi consulting spesifik dengan mengadopsi methodology tersebut. Rating yang tinggi mengindikasi bagaimana low vendor lock-in.

Information availability

Merupakan jumlah dan kualitas untuk informasi gratis atau tidak terlalu mahal mengenai methodology.

Time to value

Mereferensi untuk rentang waktu yang biasa digunakan menggunakan methodology sebelum memulai menggunakan methodology tersebut untuk membangun solusi untuk memberikan nilai bisnis yang tinggi.

 Kesimpulan

Berita baik dari methodology tersebut ialah dapat menjadi komplemen atau pelengkap satu sama lainnya. Untuk beberapa organisasi, pilihan terbaik yang dapat dipilih dari metodologi tersebut ialah menggabungkan secara bersamaan dimana methodology tersebut dapat berjalan seiring dengan keterkaitan organisasi tersebut. Memberikan tempat yang baik untuk memahami nilai dari setiap methodology dan bagaimana methodology tersebut melengkapi satu dengan yang lainnya.

Apapun rute yang anda pilih, ialah anda harus mengingat arsitektur enterprise merupakan jalan, bukan merupakan tujuan. Sebuah arsitektur enterprise tidak memiliki nilai namun akan bernilai ketika dapat memberikan nilai secara cepat terhadap organisasi. Satu dari tujuan yang penting dari arsitektur enterprise adalah memberikan sisi bisnis dan sisi teknoloogi secara bersama, sehingga keduanya dapat berjalan secara efektif pada tujuan yang sama.

 

Filled
0
Unknown
Read More
Minggu, 26 November 2017
TIME 04.03
no image

Di postingan ini ,saya akan membahas tentang perbedaan seputar metode dalam pengembangan sebuah perangkat lunak.Oke langsung saja scroll kebawah gan.

Proses Pengembangan Perangkat Lunak (Software Development Process) adalah suatu penerapan struktur pada pengembangan suatu Perangkat Lunak (Software), yang bertujuan untuk mengembangkan sistem dan memberikan panduan untuk menyukseskan proyek pengembangan sistem melalui tahapan-tahapan tertentu. Dalam prosesnya, terdapat beberapa model pengembangan sistem perangkat lunak, diantaranya :

        1.AGILE SOFTWARE DEVELOPMENT METHODOLOGY

Agile Development Methods adalah sekelompok metodologi pengembangan perangkat lunak yang didasarkan pada prinsip-prinsip yang sama atau pengembangan sistem jangka pendek yang memerlukan adaptasi cepat dari pengembang terhadap perubahan dalam bentuk apapun. Agile development methods merupakan salah satu dari Metodologi pengembangan perangkat lunakyang digunakan dalam pengembangan perangkat lunak. Agile memiliki pengertian bersifat cepat, ringan, bebas bergerak, dan waspada.

Beberapa model dari agile development methods,yaitu :

  • Acceptance Test Driven Development (ATDD)
  • Agile Modeling
  • Adaptive Software Development (ASD)
  • Agile Unified Process (AUP)
  • Continuous integration (CI)
  • Crystal Clear
  • Crystal Methods
  • Dynamic Systems Development Method (DSDM)
  • Extreme Programming (XP)
  • Feature Driven Development (FDD)
  • Graphical System Design (GSD)
  • Kanban
  • Lean software development
  • Rational Unified Process (RUP)
  • Scrum
  • Scrum-ban
  • Story-driven modeling
  • Test-driven development (TDD)
  • Velocity tracking
  • Software Development Rhythms
Fitur-fitur yang diberikan oleh Agile Software Development adalah sebagai berikut:
  1. Iterasi yang cepat dan pengiriman software yang berfungsi secara reguler memastikan kepuasan pelanggan.
  2. Perubahan yang telat dapat ditangani dengan mudah dan juga diterima secara terbuka.
  3. Perkembangan dinilai berdasarkan implementasi software.
  4. Komunikasi pelanggan dan pengguna ditekankan secara bertatap muka.
  5. Setiap pertemuan dengan anggota tim dilakukan secara bertatap muka.
  6. Setiap anggota tim pengembang adalah orang yang berkomitmen dan bermotivasi tinggi serta kompeten dan dapat dipercaya.
800px-Generic_diagram_of_an_agile_methodology_for_software_development
Diagram Metodologi Agile
Poin penting dari Metodologi Agile :
  1. Interaksi dan personel lebih penting dari pada proses dan alat. di dalam agile interaksi antar anggota tim sangatlah penting, karena tanpa adanya interaksi yang baik maka proses pembuatan perangkat lunak tidak akan berjalan sesuai rencana.
  2. Perangkat lunak yang berfungsi lebih penting daripada dokumentasi yang lengkap. saat melakukan proses demonstrasi kepada klien, perangkat lunak yang berfungsi dengan baik akan lebih berguna daripada dokumentasi yang lengkap.
  3. Kolaborasi dengan klien lebih penting dari pada negosiasi kontrak. salah satu ciri dari agile adalah klien menjadi bagian dari tim pengembangan perangkat lunak. Kolaborasi yang baik dengan klien saat proses pembuatan perangkat lunak sangatlah penting ketika menggunakan agile. Karena fungsi-fungsi dari perangkat lunak yang dikembangkan harus terus menerus dibicarakan dan diimprovisasi disesuaikan dengan keinginan klien
  4. Respon terhadap perubahan lebih penting daripada mengikuti rencana. agile development methods berfokus terhadap kecepatan respon tim ketika klien menginginkan perubahan saat proses pembuatan perangkat lunak.
Waktu Penggunaan
Metode Agile cocok untuk proyek yang memberikan kepuasan pelanggan karena resiko kegagalan yang kecil dan lebih cepat dalam penyelesaian software serta perubahan yang cepat dari software yang dibangun untuk meningkatkan kualitas software yang lebih baik.
Kelebihan
  1. Meningkatkan rasio kepuasan pelanggan.
  2. Bisa melakukan review pelanggan mengenai software yang dibuat lebih awal.
  3. Mengurangi resiko kegagalan implementasi software dari segi non-teknis.
  4. Besar kerugian baik secara material atau imaterial tidak terlalu besar jika terjadi kegagalan.
Kekurangan
  1. Total lama pengembangan menjadi lebih lama.
  2. Meningkatkan resiko kesalahan teknis.
  3. Proses pengembangan menjadi agak kurang terorganisir.

      2. RAPID APPLICATION DEVELOPMENT

Rapid application development  (RAD) atau rapid prototyping adalah model proses pembangunan perangkat lunak yang tergolong dalam teknik incremental (bertingkat). RAD menekankan pada siklus pembangunan pendek, singkat, dan cepat.
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, tapi itu awalnya ditujukan untuk menggambarkan suatu proses pembangunan yang melibatkan application prototyping dan iterative development.

MODEL RAD

https://murtri.files.wordpress.com/2014/08/5.jpg?w=634
Berikut adalah Tahapan – tahapan Proses Pengembangan dalam Model Rapid Application Development (RAD), yaitu :
a) Bussiness modeling Aliran informasi di antara fungsi – fungsi bisnis dimodelkan dengan suatu cara untuk menjawab pertanyaan – pertanyaan berikut :
informasi apa yang mengendalikan proses bisnis?
  • Informasi apa yang di munculkan?
  • Siapa yang memunculkanya?
  • Ke mana informasi itu pergi?
  • Siapa yang memprosesnya?
 
b)Data modeling
  • Aliran informasi yang didefinisikan sebagai bagian dari fase business
  • modeling disaring ke dalam serangkaian objek data yang dibutuhkan untuk menopang bisnis tersebut.
  • Karakteristik (disebut atribut) masing – masing objek diidentifikasi dan hubungan antara objek – objek tersebut didefinisikan.
  • Bagian dari pemodelan bisnis yang didefinisikan ke dalam sekumpulan objek data.
  • Karakteristik (atribut) dari setiap objek diidentifikasikan dan hubungannya .
 
c)Prosess modelling
  • Aliran informasi yang didefinisikan di dalam fase data modeling ditransformasikan untuk mencapai aliran informasi yang perlu bagi implementasi sebuah fungsi bisnis.
  • Gambaran pemrosesan diciptakan untuk menambah, memodifikasi, menghapus, atau mendapatkan kembali sebuah objek data.
  • Objek data akan diimplementasikan pada fungsi bisnis.
  • Deskripsi proses dibangun untuk penambahan modifikasi, penghapusan, atau pengambilan kembali objek data.
 
d)Application generation
  • RAD mengasumsikan pemakaian teknik generasi ke empat. Selain menciptakan perangkat lunak dengan menggunakan bahasa pemrograman generasi ketiga yang konvensional
  • Pada semua kasus, alat – alat bantu otomatis dipakai untuk memfasilitasi konstruksi perangkat lunak.
  • Melakukan penggunaan kembali komponen yang ada (jika mungkin).
  • Atau membuat kembali penggunaan kembali komponen jika dibutuhkan.
 
e)Testing and turnover
  • Karena proses RAD menekankan pada pemakaian kembali,banyak komponen program telah diuji. Hal ini mengurangi keseluruhan waktu pengujian.
  • Tetapi komponen baru harus di uji dan semua interface harus dilatih secara penuh.
 
Kelebihan RAD (Rapid Application Development)
  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 sudah
    ada dan waktu yang lebih singkat maka membuat biaya menjadi lebih rendah
    dalam menggunakan RAD
Kekurangan RAD (Rapid Application Development)
  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 METHODOLOGY (DSDM)

Dynamic System Development Model Methodology (DSDM) adalah pada dasarnya merupakan suatu metodologi pengembangan perangkat lunak pada awalnya didasarkan pada Aplikasi Rapid Development metodologi. Pada tahun 2007 DSDM menjadi pendekatan umum untuk proyek pengiriman manajemen dan solusi. DSDM adalah iteratif dan inremental pendekatan yang menekankan pengguna kontinu / keterlibatan pelanggan.Tujuannya adalah untuk memberikan proyek-proyek tepat waktu dan menyesuaikan anggaran sementara untuk perubahan kebutuhan sepanjang jalan. DSDM adalah salah satu dari sejumlah metode Agile untuk mengembangkan perangkat lunak dan non-IT solusi, dan itu merupakan bagian dari Aliansi Agile.
 Hasil gambar untuk Dynamic System Development Model Methodology
Ada 9 prinsip yang penting untuk implementasi DSDM,yaitu :
1) Keterlibatan pengguna aktif – Imperatif.
2) Tim harus diberdayakan untuk mengambil keputusan.
3) Fokus pada pengiriman yang sering.
4) Kriteria untuk deliverable diterima (Fitness for Business).
5) Perkembangan Iteratif dan inkremental – Wajib.
6) Semua perubahan selama pengembangan harus reversibel.
7) Persyaratan dasar dilapisi pada tingkat tinggi.
8) Pengujian terintegrasi sepanjang siklus hidup.
9) Pendekatan kolaboratif dan kooperatif.
Waktu Penggunaan
Dynamic Sofware Development Method (DSDM) cocok untuk proyek yang membutuhkan waktu singkat dan tidak memerlukan kinerja tinggi, ini karena DSDM berdasar pada model RAD.
 Kelebihan Dynamic Software Development Method (DSDM)
  1. Menyajikan kerangka kerja (framework) untuk membangun dan memelihara sistem dalam waktu yang terbatas melalui penggunaan prototypingyang incremental dalam lingkungan yang terkondisikan
  2. Membangun softwaredengan cepat
  3. DSDM dapat dikombinasikan dengan XP menghasilkan kombinasi model proses yang mengikuti DSDM dan praktek yang sejalan dengan XP
Kelemahan Dynamic Software Development Method(DSDM)
  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 backupand recovery, system performance dan system security kurang/tidak diperhatikan dan sering terlupakan

4. EXTREME PROGRAMING METHODOLOGY

Extreme Programming (XP) merupakan salah satu metodologi dalam rekayasa perangkat lunak dan juga merupakan satu dari beberapa agile software development methodologies yang berfokus pada coding sebagai aktivitas utama di semua tahap pada siklus pengembangan perangkat lunak (software development lifecycle). Metodologi ini mengedepankan proses pengembangan yang lebih responsive terhadap kebutuhan customer (”agile”) dibandingkan dengan metode-metode tradisional sambil membangun suatu software dengan kualitas yang lebih baik.
Hasil gambar untuk penjelasan tahapan Extreme Programing Methodology

Tahapan Dalam Etreme (XP) Programming, yaitu:
Aktivitas planning dimulai dengan membentuk user stories. Anggota XP team kemudian menilai setiap story dan menentukan cost — diukur dalam development week.
Planning. Customer dan XP team bekerja bersama untuk memutuskan bagaimana grup story untuk release berikutnya (software increment berikutnya) untuk dibangun oleh XP team. Jika komitmen telah dibuat, XP team akan membangun story-story dengan cara :
Semua story segera diimplemetasikan (dalam beberapa minggu)
1. Story dengan value tertinggi akan dipindahkan dari jadwal dan dimplementasikan pertama.
2. Story dengan resiko paling tinggi akan diimplemetasikan terlebih dulu. Setelah project pertama direlease dan didelivery, XP team memperhitungkan kecepatan project. Selama development, customer dapat menambah story, merubah value, membagi story atau menghapusnya.
Design. XP menggunakan CRC card, untuk mengenali dan mengatur object oriented class yang sesuai dengan software increment.
Coding. Sebelum membuat code, lebih baik membuat unit test tiap story untuk dimasukkan dalam software increment. XP menyarankan agar dua orang bekerja bersama pada satu komputer workstation untuk membuat code dari satu story (pair programming), untuk menyediakan real time problem solving dan jaminan real time quality. Setelah pair programming selesai, code diintegrasikan dengan kerja laiinnya (continuous integration).
Testing. Unit test yang telah dibuat harus diimplementasikan menggunakan suatu framework dan diatur ke dalam universal testing suite, integrasi dan validasi sistem dapat dilakukan setiap hari. Customer test (acceptance test) dilakukan oleh customer dan fokus pada keseluruhan fitur dan fungsional sistem. Acceptance test diperoleh dari customer stories yang telah diimplemetasikan sebagai bagian dari software release.
 Waktu Penggunaan
Penerapan dari Extreme Programing (XP) cocok untuk teknologi atau prototipe baru, dimana persyaratan berubah dengan cepat, atau beberapa pengembangan diperlukan untuk menemukan masalah pelaksanaan yang tak terduga.
Kelebihan Extreme Programming, yaitu:
  1. Meningkatkan kepuasan kepada klien
  2. Pembangunan system dibuat lebih cepat
  3. Menjalin komunikasi yang baik dengan client.
  4. Meningkatkan komunikasi dan sifat saling menghargai antar developer.
Kelemahan Extreme Programming, yaitu:
  1. Cerita-cerita yang menunjukkan requirements dari pelanggan kemungkinan besar tidak lengkap sehingga 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).
  3. XP tidak memiliki dokumentasi formal yang dibuat selama pengembangan. Satu-satunya dokumentasi adalah dokumentasi awal yang dilakukan oleh user.

5.SCRUM DEVELOPMENT METHODOLOGY

Metodologi Scrum termasuk ke dalam kumpulan metode Pengembangan Perangkat Lunak Agile (Agile Software Development).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.
PRINSIP METODOLOGI SCRUM
 
· Ukuran tim yang kecil melancarkan komunikasi, mengurangi biaya, dan memberdayakan satu sama lainProses dapat beradaptasi terhadap perubahan teknis dan bisnis
· Proses menghasilkan beberapa software increment
· Pembangunan dan orang yang membangun dibagi dalam tim yang kecil
· Dokumentasi dan pengujian terus menerus dilakukan setelah software dibangun
· Proses scrum mampu menyatakan bahwa produk selesai kapanpun diperlukan

 https://ranjaniryan.files.wordpress.com/2015/12/image.png?w=634
Berikut ini uraian dari tahap-tahap pengembangan perangkat lunak dengan menggunakan metode Scrum :
1. Product Backlog
Bagian pertama ini adalah kumpulan dari hal-hal yang diperlukan dan yang harus tersedia dalam produk. Produk backlog berada dalam tanggung jawab product owner. Product Backlog adalah daftar utama dari semua fungsi yang diinginkan dalam produk. Metodologi Scrum tidak mengharuskan dokumentasi semua persyaratan pada awal proyek.
2. Sprint Backlog
Perencanaan Sprint dilakukan dalam pertemuan atau meeting antara pemilik produk dan tim developer yang akan berkolaborasi untuk memilih product backlog untuk dimasukan kedalam proses sprint. Hasil dari pertemuan tersebut adalah Sprint Backlog.
3. Sprint
Sprint adalah sebuah kerangka waktu yang berdurasi maksimal 1 bulan untuk mengembangkan produk yang berpontensi untuk dirilis. Dalam Sprint terdapat 2 bagian pekerjaan, yaitu :
a. Pertemuan Harian (Daily Standup Meeting)
Merupakan pertemuan dimana setiap 24 jam (1 hari), tim pengembangan bertemu untuk membahas proses pengembangan produk.
b. Refleksi Sprint
Merupakan pertemmuan yang dilakukan setiap bulannya, yang bertujuan untuk membahas hal dari Sprint Backlog yang telah berjalan dan telah berhasil dikerjakan, serta dapat memperbaiki dan meningkatkan kualitas produk pada Sprint yang berikutnya.
4. Increment
Increment merupakan hasil dari seluruh hal dalam Product Backlog yang telah selesai dikerjakan pada seluruh Sprint. PAda akhir Sprint, Increment harus sudah benar-benar selesai, yang berarti harus dalam keadaan yang useable.
Waktu Penggunaan
Scrum Development Methodology digunakan ketika tim programmer sedikit, yaitu 5-9 orang dan ketika pelanggan tidak terlalu paham dengan apa yang diinginkan.
Kelebihan dari scrum
  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 kapan pun diperlukan.
Kekurangan sari scrum
  1. Developer harus selalu siap dengan perubahan karena perubahan akan selalu diterima.
  2. Lemah dalam perencanaan arsitektur
Terima kasih para reader yang sudah mengunjungi blog saya ini ,semoga artikel kali ini bermanfaat ,ya meskipun saya hanya copas dari blog lain ,tapi apa salahnya berbagi informasi kan. Sekian dari saya ,Salam Tekno.
Filled
0
Unknown
Read More
Langganan: Postingan (Atom)