Bab 16 Trend Baru dalam Pengembangan Sistem

Judul Buku: Systems Analysis and Design in a Changing World, Edisi 4

Bab 16 Trend Baru dalam Pengembangan Sistem

(Slide 1 s.d 3 berisi tujuan pembelajaran)

GAMBARAN UMUM

  • Disiplin IS selalu dinamis dan berubah
  • Kebutuhan sistem yang lebih kompleks mengharuskan semua tools baru

–          The Unified Process (UP)

–          Radikal, pendekatan adaptif, mencakup Agile Development, Extreme Programming, dan Scrum

–          Arsitektur Model-Driven untuk sistem level perusahaan

–          Kerangka dan komponen objek meningkatkan produktivitas dan kualitas

Prinsip-Prinsip Software dan Latihan

  • Di mana pun, komputerisasi merupakan trend baru di masyarakat kita

–          Menggunakan teknologi komputer dalam setiap aspek hidup kita

  • Usaha mengembangkan solusi baru banyak banyak persyaratannya
  • Trend-trend baru dalam modeling dan proses pengembangan menggunakan lima prinsip-prinsip penting
  • Abstraksi

–          Proses mengekstrak prinsip-prinsip utama dari sejumlah fakta atau statement

–          Contoh: metamodels menggambarkan karakteristik model lain

  • Model dan Modeling

–          Abstraksi sesuatu dalam dunia nyata, merepresentasikan sejumlah properties tertentu

  • Patterns

–          Solusi standar untuk suatu masalah atau template yang dapat digunakan untuk mengatasi masalah

  • Reuse

–          Membangun solusi dan komponen standar yang bisa digunakan berkali-kali

  • Metodologi

–          Proses—mencakup aturan, panduan, dan teknik—yang menentukan bagaimana sistem dibangun

Pendekatan Adaptif untuk Pengembangan

  • Berbeda dengan spektrum akhir dari pendekatan prediktif (lihat Bab 2)
  • Memungkinkan ketidaktentuan
  • Menggunakan kontrol empiris, bukan kontrol prediktif

–          Menggambarkan proses-proses, yakni yang bersifat variabel dan tidak terprediksi

–          Memonitor kemajuan dan membuat koreksi sambil jalan

Pendekatan Adaptif untuk Pengembangan—Karakteristik

  • Kurang perhatian pada analisis, desain, dan dokumentasi di muka sekali
  • Lebih fokus pada pengembangan inkremental
  • Lebih banyak keterlibatan user dalam tim proyek
  • Mengurangi perencanaan detail

–          Digunakan hanya untuk fase-fase near-term work

  • Schedule kontrol yang padat dengan menyesuaikan pekerjaan ke dalam boks waktu diskrit
  • Lebih banyak menggunakan tim-tim kerja kecil yang mengorganisir sendiri

The Unified Process (UP)

  • Metodologi pengembangan sistem berorientasi objek (proses pengembangan sistem)
  • Ditawarkan oleh Rational/IBM, UP dikembangkan oleh Booch, Rumbaugh, dan Jacobson
  • UP harus disesuaikan dengan kebutuhan-kebutuhan organisasi dan proyek
  • Siklus hidup iteratif tinggi
  • Proyek akan menjadi use-case driven and modeled using UML

Siklus Hidup Proses Terintegrasi

  • UP life cycle

–          Mencakup empat fase yang terdiri atas iterasi-iterasi

–          Iterasi adalah “mini-projects”

  • Insepsi: mengembangkan dan menyempurnakan visi sistem
  • Elaborasi: menentukan kebutuhan dan desain serta mengimplementasikan arstektur utama
  • Konstruksi: melanjutkan desain da n implementasi rutin, bagian-bagian yang tidak terlalu berisiko
  • Transisi: memindahkan sistem ke dalam mode operasional

Siklus hidup Pemrosesan Teintegrasi: slide 12

Fase dan Tujuan UP

Fase UP Tujuan
Insepsi Mengembangkan visi perkiraan dari sistem, membuat kasus bisnis, menentukan skupnya, dan membuat estimasi kasar untuk biaya dan schedule
Elaborasi Menyempurnakan visi, mengidentifikasi dan menggambarkan semua kebutuhan, memastikan skup, desain dan mengimplementasikan arsitekur dan fungsi-fungsi utama, menyelesaikan risiko tinggi, dan membuat estimasi realistis untuk biaya dan schedule
Konstruksi Secara iteratif mengimplementasikan elemen-elemen dengan risiko ringan yang tersisa, terprediksi, dan lebih mudah serta persiapan untuk deployment
Transisi Menyelesaikan tes dan deployment beta sehingga para user memiliki sistem yang sudah siap pakai untuk mendapatkan keuntungan yang diharapkan

Disiplin UP

  • UP menentukan disiplin-disiplin yang digunakan pada setiap fase
  • Disiplin—sejumlah aktivitas pengembangan yang terhubung secara fungsional
  • Tiap iterasi mencakup aktivitas-aktivitas dari semua disiplin
  • Aktivitas-aktivitas pada tiap disiplin menghasilkan artifacts—models, dokumen, source code, dan executables
  • Mengkaji CIS/MIS berarti mengkaji berbagai teknik dari disiplin-disiplin ini
  • Enam disiplin utama dari pengembangan UP

–          Pemodelan, kebutuhan, desain, implementasi, testing, dan deployment bisnis

  • Tiga disiplin support tambahan

–          Manajemen, konfigurasi, dan manajemen perubahan, serta lingkungan proyek

Disiplin UP yang digunakan dalam jumlah yang berbeda di tiap iterasi: slide 16

Model siklus hidp UP: slide 17

FILOSOFI DAN PEMODELAN PENGEMBANGAN CERDAS

Agile Development

  • Sebuah filosofi dan sejumlah panduan untuk mengembangkan software dalam lingkungan yang tidak diketahui dan berubah cepat

–          Membutuhkan kecerdasan—mampu mengubah arah dengan cepat, bahkan di tengah-tengah proyek

  • Agile Modeling

–          Sebuah filosofi tentang bagaimana membangun berbagai model, sebagian bersifat formal dan detail, serta yang lainnya sederhana dan minimalis

Filosofi dan nilai-nilai pengembangan cerdas

  • Merespon perubahan yang terjadi pada perencanaan

–          Proyek cerdas adalah chaordic—chaotic and ordered (semrawut dan rapi)

  • Individual dan interaksi di atas proses dan tools
  • Menjalankan software di atas dokumentasi komprehensif
  • Kolaborasi pelanggan di atas negosiasi kontrak

Metodologi Adaptif menggunakan Agile Modeling: slide 20

Prinsip-prinsip Agile Modeling

AM mengerjakan jenis pemodelan yang benar pada level detail yang benar untuk tujuan-tujuan yang benar

  • Menggunakan model-model sebagai akhir pembangunan dan penyelesaian nya
  • Tidak mendikte yang mana model yang akan dibangun atau seberapa formal membangun model-model tersebut
  • Memiliki prinsip-prinsip dasar untuk mengekspresikan bahwa para developer harus memiliki sikap seperti mereka yang mengembangkan software

Prinsip-prinsip Agile Modeling

  • Mengembangkan software sebagai tujuan utama anda
  • Memungkinkan usaha selanjutnya sebagai tujuan kedua anda
  • Meminimalisir aktivitas pemodelan anda—sedikit dan sederhana
  • Mencakup perubahan, dan berubah secara inkremental
  • Model dengan sebuah tujuan
  • Membangun berbagai model
  • Membangun model-model berkualitas tinggi dan mendapatkan feedback secara cepat
  • Fokus pada konten daripada representasi
  • Belajar dengan komunikasi terbuka
  • Mengetahui model-model anda dan bagaimana menggunakannya
  • Beradaptasi terhadap kebutuhan-kebutuhan proyek yang spesifik

Latihan Agile Modeling

  • Iterative and incremental modeling

–          Menggunakan model-model yang benar

–          Menciptakan beberapa model paralel

–          Iterasi yang sering

–          Model dalam inkreman kecil

  • Teamwork

–          Model dengan yang lainnya

–          Melibatkan user dan stakeholder lain

–          Berbagai kepemilikan model

–          Mempublikasikan model

  • Simplicity

–          Menciptakan konten sederhana

–          Menggambarkan model secara sederhana

–          Menggunakan tools sederhana

  • Validation

Membuktikannya dengan code

  • Documentation

–          Membuang model temporer

–          Merumuskan model-model kontrak

–          Hanya mengupdate ketika model rusak

  • Motivation

–          Model untuk berkomunikasi

–          Medel untuk memahami

Extreme Programming (XP)

  • Adaptif, metodologi pengembangan cerdas diciptakan pada pertengahan tahun 1990
  • Membuktikan praktek terbaik industri dan fokus padanya secara intens
  • Mengkombinasikan praktek-praktek terbaik itu (dalam bentuk intensnya) dalam cara baru untuk memproduksi hasil yang lebih besar dari jumlah bagian-bagiannya

Nilai-nilai Inti XP

  • Komunikasi

Terbuka, sering diskusi verbal

  • Simplicity

Dalam mendesain dan mengimplementasikan solusi-solusi

  • Feedback

Pada fungsionalitas, syarat/kebutuhan, desain, dan code

  • Courage

Dalam menghadapi pilihan seperti membuang bad code atau bertahan terhadap schedule yang sangat padat

Praktek-Praktek XP

  • Planning

Para user mengembangkan sejumlah cerita untuk menggambarkan apa yang harus sistem lakukan

  • Testing

Tes ditulis sebelum solusi-solusi diimplementasikan

  • Pair Programming

Dua programmer bekerja sama dalam mendesain, coding, dan testing

  • Simple Designs

“KISS” dan desain berkelanjutan

  • Refactoring

Memperbaiki code tanpa mengubah yang ada

  • Memiliki code secara kolektif

Sebagian orang dapat memodifikasi beberapa bagian code

  • Continuous integration

Bagian-bagian kecil dari code yang diintegrasikan ke dalam sistem secara harian atau lebih sering daripada itu

  • System metaphor

Membimbing para anggota menuju visi sistem

  • On-Site Customer

Interaksi user/pelanggan yang intensif itu dibutuhkan

  • Small releases

Memproduksi release yang kecil dan sering untuk user/pelanggan

  • Forty-hour work week

Proyek harus dimanage untuk menghindari kegagalan

  • Coding standards

Mengikuti coding standards untuk meyakinkan fleksibilitas

Nilai-nilai inti XP dan Latihan

XP Core Values XP Practices
Komunikasi Perencanaan
Kesederhanaan Pengujian
Timbal balik Pair programming
Keberanian Desain sederhana
Refactoring the code
Memiliki code secara kolektif
Integrasi berkelanjutan
On-Site Customer
Metafora sistem
Release kecil
Fortu-hour week
Standar pengkodean

Aktivitas Proyek XP

  • System-level activities

–          Terjadi sekali selama masing-masing proyek pengembangan

–          Melibatkan penciptaan cerita-cerita user untuk merencanakan release

  • Release-level activities

–          Siklus dengan banyak waktu—sekali untuk tiap release

–          Dikembangkan dan diuji dalam satu periode tidak lebih dari beberapa minggu atau bulan

  • Iteration-level activities

Melakukan pengkodean dan menguji subset fungsional spesifik dalam beberapa hari atau minggu

Pendekatan pengembangan XP: slide 31

SCRUM

  • Metodologi pengembangan yang cepat, adaptif, dan self-organizing

Dinamai setelah rugby’s system untuk mendapatkan out-of-play ball into play

  • Merespon situasi baru secepat dan sepositif mungkin
  • Pendekatan kontrol empiris yang sebenarnya terhadap pengembangan software

Filosofi Srum

  • Responsif terhadap perubahan cepat, lingkungan dinamis
  • Sangat fokus pada level tim

Tim menggunakan kontrol total di atas organisasi dan proses pekerjaannya

  • Menggunakan backlog produk sebagai mekanisme kontrol dasar

Memprioritaskan daftar kebutuhan user harus dipilih dan dikerjakan  selama proyek scrum

Organisasi Scrum

  • Product owner

–          Client stakeholder untuk yang membangun sistem

–          Memelihara daftar backlog produk

  • Scrum master

Orang dalam memimpin proyek scrum

  • Scrum team or teams

–          Kelompok kecil dari para pengembang

–          Menyusun tujuan-tujuannya dan mendistribusikan perkejaan di antara mereka

Praktek Scrum

  • Sprint

–          Proses pekerjaan dasar dalam scrum

–          A time-controlled mini-project

–          Firm 30-day time box dengan tujuan spesifik atau deliverable

  • Bagian-bagian dari Sprint

–          Mulai dengan sesi perencanaan satu hari

–          Pertemuan scrum harian yang singkat untuk kemajuan laporan

–          Berakhir dengan review setengah hari terakhir

Proses pengembangan software scrum: lihat slide 36

MANAJEMEN PROYEK DAN METODOLOGI ADAPTIF

  • Manajemen waktu proyek

–          Skup lebih kecil dan fokus pada tiap iterasi

–          Schedule pekerjaan realistis

  • Manajemen skup proyek

–          Users dan clients bertanggung jawab terhadap skup itu

–          Scope control terdiri atas pengawasan sejumlah iterasi

  • Manajemen pembiayaan proyek

–          Lebih sulit diprediksi karena tidak diketahui

  • Manajemen komunikasi proyek

Kritis karena komunikasi verbal terbuka dab pekerjaan kolaboratif

  • Manajemen kualitas proyek

Testing and refactoring berkelanjutan harus dijadwalkan

  • Manajemen risiko proyek

Aspek-aspek risiko tinggi dialamatkan pada iterasi-iterasi awal

  • Manajemen sumber daya manusia proyek

Tim mengorganisirnya sendiri

  • Manajemen procurement proyek

–          Mengintegrasikan elemen-elemen yang diperoleh ke dalam proyek menyeluruh

–          Memverifikasi kualitas komponen-komponen

–          Meyakinkan komitmen kontraktual

Model-Driven Architecture—menggeneralisir solusi-solusi

  • Model-Driven Architecture (MDA) adalah inisiatif OMG (Object Management Group)

–          Dibangun pada prinsip-prinsip abstraksi, pemodelan, penggunaan kembali, dan patterns

–          Menyediakan perusahaan kerangka untuk mengidentifikasi dan mengklasifkasikan semua pekerjaan pengembangan sistem yang dikerjakan dalam sebuah perusahaan

  • MDA mengekstrak  features dan informasi sistem baru dan mengkombinasikannya ke dalam platform independent model (PIM)
  • Platform-independent model (PIM)

–          Menggambarkan karakteristik sistem yang tidak spesifik untuk beberapa diagram deployment

–          Menggunakan UML

  • Platform-specific model (PSM)

–          Menggambarkan karakteristik sistem yang mencakup kebutuhan deployment platform

  • Sejumlah transformasi standar dengan OMG mengubah PSM menjadi PIM

Pengembangan Sistem dan MDA: lihat slide 42

Metamodels and Transitions di antara PIM, PSM, dan Code: slide 43

Partial Metamodel of UML Class Diagram: slide 44

Kerangka Objek

  • Sejumlah kelas yang didesain untuk dipergunakan kembali dalam varian program
  • Kelas-kelas di dalam kerangka objek yang disebut kelas-kelas fundamen

–          Dapat diorganisir ke dalam satu atau lebih hirarki warisan

–          Kelas-kelas khusus aplikasi dapat diambil dari kelas-kelas fundamen yang ada

Jenis Kerangka Objek

  • User-interface classes

Biasanya digunakan objek-objek dalam GUI

  • Generic data structure classes

Linked lists, binary trees, dan lain-lain, dan operasi pemrosesan terkait

  • Relational database interface classes

Kelas-kelas untuk menciptakan dan melakukan operasi pada tabel-tabel

  • Classes specific to an application area

Untuk penggunaan industri dan jenis aplikasi khusus

Dampak pada desain dan implementasi

  • Frameworks harus dipilih di awal sebuah proyek
  • Desain sistem harus sesuai dengan asumsi-asumsi spesifik tentang struktur dan operasi program aplikasi yang frame hadapi
  • Personil desain dan pengembangan harus dilatih untuk menggunakan Frameworks secara efektif
  • Berbagai Frameworks mungkin dibutuhkan, memerlukan kompatibilitas dan pengujian integrasi dahulu

Komponen-Komponen

  • Modul-modul software yang disusun secara lengkap dan siap guna

Reusable packages of executable code

  • Memiliki interface yang baik untuk mengkoneksikannya ke clients atau komponen-komponen lian

Public interfaces and encapsulated implementation

  • Standardized and interchangeable

Mengupdate komponen-komponen tunggal yang tidak membutuhkan relinking, recompiling, and redistributing aplikasi keseluruhan

Standar Komponen dan Infrastruktur

  • Interoperabilitas komponen-komponen yang membutuhkan standar untuk dikembangkan sehingga siap guna
  • Komponen-komponen mungkin juga membutuhkan infrastruktur support standar

Komponen-komponen software lebih fleksibel ketika bergantung  pada pelayanan infrastruktur standar untuk menemukan komponen-komponen lain

  • Standar jaringan dibutuhkan untuk komponen-komponen di lokasi yang berbeda

CORBA and COM+

  • CORBA (Common Object Request Broker Architecture) adalah standar untuk koneksi dan interkasi komponen software yang dikembangkan oleh OMG

–          Object request broker (ORB) menyediakan direktori komponen dan pelayanan-pelayanan komunikasi

–          Internet Inter-ORB Protocol (IIOP) digunakan untuk berkomunikasi antar objek  dan ORBs

  • Component Object Model Plus (COM+) adalah standar untuk koneksi dan interkasi komponen software yang dikembangkan oleh Microsoft

Enterprise JavaBeans

  • Bagian dari framework objek ekstensif bahasa pemrograman Java (JDK)
  • JavaBean dapat berjalan pada sebuah server dan berkomunikasi  dengan clients dab komponen lain menggunakan CORBA

–          JavaBean mengimplementasikan metode komponen yang dibutuhkan dan menindaklanjuti konvensi penamaan yang dibutuhkan  dari standar JavaBean

  • Platform independent

Komponen-komponen dan siklus hidup pengembangan

  • Pengadaan dan penggunaan kembali komponen merupakan pendekatan viable untuk penyelesaian kecepatan sistem

–          Komponen yang diadakan dapat membentuk semua atau sebagian sistem baru yang dikembangkan atau diimplementasikan kembali

–          Komponen dapat didesain in-house dan disebar dalam sistem baru yang dikembangkan dan diimplementasikan kembali

Menggunakan komponen-komponen yang tersedia—implikasi

  • Software standar dan support dari komponen yang tersedia harus menjadi bagian dari penentuan kebutuhan teknis
  • Kebutuhan support teknis  komponen membatasi pertimbangan pilihan selam desain arsitektur software

Monitoring System Performance

  • Menguji desain berbasis komponen untuk mengestimasi pattern dan demand traffic jaringan pada hardware komputer
  • Menguji kapasitas server yang ada dan infrastruktur jaringan untuk menentukan kemampuannya mengakomodasi komunikasi antar komponen
  • Mengupgrade kapasista jaringan dan server terlebih dahulu sebelum pengembangan dan testing
  • pengujian system performance selama pengembangan dan membuat penyesuaian yang dibutuhkan
  • Monitoring System Performance berkelanjuran setelah deployment untuk mendeteksi permasalahan merging
  • Redeploy components, upgrade kapasitas server, dan mengupgrade kapasitas jaringan untuk merefleksikan kondisi-kondisi perubahan

Pelayanan

  • Metode baru dari penggunaan kembali software mungkin dilakukan dengan Internet—pelayanan eksternal yang diidentifikasi dan digunakan untuk aplikasi-aplikasi
  • Disebut layanan web dan arsitektur berorientasi pelayanan
  • Microsoft .NET merupakan standar berbasis SOAP
  • Java 2 Web Services (J2WS) merupakan standar layanan dalam Java

Komunikasi komponen menggunakan SOAP: slide 57

RANGKUMAN

Metodologi pengembangan adaptif

  • Unified Process (UP)
  • Agile Modeling and Agile Development

Fleksibilitas dalam dunia bisnis yang tidak terprediksi

  • Extreme Programming (XP)

Test ditulis dahulu; programmer bekerja secara pair

  • Scrum

Menentukan tujuan spesifik yang dapat diselesaikan dalam empat minggu

  • Model-Driven Architecture (MDA)

Menyediakan teknik-teknik untuk organisasi besar guna mengintegrasikan semua software dan semua pengembangan software melintasi seluruh perusahaan

  • Penggunaan kembali user merupakan pendekatan fundamental untuk pengembangan cepat

–          Kerangka objek menyediakan tujuan dari penggunaan kembali software yang ada melalui warisan

–          Komponen merupakan unit-unit executable code yang dapat digunakan kembali dan berperans sebagai objek-objek terdistribusi

TERJEMAHAN INI BELUM DIEDIT

Sumedang, 4 September 2010

One response to “Bab 16 Trend Baru dalam Pengembangan Sistem

  1. Pingback: Archive for Satzinger -riandragon89

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s