INFORMATION SYSTEMS DEVELOPMENT

Capability Maturity Model (CMM) Yaitu suatu kerangka standarisasi untuk menilai tingkat kematangan (maturity) pengembangan sistem pada suatu organisasi/ perusahaan, proses menajemen dan produk Level : Permulaan / initial => anarki/kekacauan Tidak mengikuti proses yang konsisten, tidak dapat ditebak atau diulang Menggunakan peralatan dan metode sendiri Keberhasilan/kegagalan adalah fungsi ketrampilan dan pengalaman Banyak krisis, biaya membengkak dan terlambat Dokumen sporadis/tidak konsisten dari proyek ke proyek

Level CMM Dapat diulang/repeatabe Terdefinisikan/defined Proses dan praktik manajemen proyek dibentuk untuk melacak biaya, jadwal, & fungsionalitas proyek Mengikuti proses pengembangan sistem => bervariasi dari proyek ke proyek Keberhasilan dan kegagalan adalah fungsi ketrampilan dan pengalaman tim Fokus pada manajemen proyek Terdefinisikan/defined Proses pengembangan sistem standar/metodologi => stabil, dapat diduga dan dikembangkan Semua proyek menggunakan versi

Level CMM Terkelola/ managed Teroptimalisasi/optimized Proses pengembangan sistem standar/metodologi Kualitas dan produktifitas terjaga => database Berusaha memperbaiki proyek individual berdasarkan data terkumpul Lebih proaktif Teroptimalisasi/optimized Proses pengembangan terstandarisasi secara berkesinambungan, dimonitor dan perbaiki berdasarkan ukuran-ukuran dan analisis data yang dibentuk di tingkat 4 Termasuk pengubahan teknologi

Capability Maturity Model (CMM)

Representative System Development Methodologies Architected Rapid Application Development (Architected RAD) Dynamic Systems Development Methodology (DSDM) Joint Application Development (JAD) Information Engineering (IE) Rapid Application Development (RAD) Rational Unified Process (RUP) Structured Analysis and Design eXtreme Programming (XP)

Principles of System Development Get the system users involved (melibatkan). Use a problem-solving approach.  Establish (membuat) phases (tahapan) and activities. Document through development. Establish standards. Manage the process and projects  Justify systems as capital investments. Don’t be afraid to cancel or revise (meninjau ulang) scope.  Divide and conquer. Design systems for growth and change.

Use a problem-solving approach. Classical Problem-solving approach Study and understand the problem, its context, and its impact. Define the requirements yg harus dipenuhi by any solution. Identify candidate solutions that fulfill the requirements, and select the “best” solution. Design and/or implement the chosen solution. Observe and evaluate the solution’s impact, and refine the solution accordingly.

Manage the process and projects Process management – aktifitas terus menerus yang mendokumentasikan, memanage, mengawasi penggunaan dan memeperbaiki metodologi yang digunakan untuk pengembangan concerned with phases, activities, deliverables, and quality standards should be consistently applied to all projects. Project management is the process of scoping, planning, staffing, organizing, directing, and controlling a project to develop an information system at a minimum cost, within a specified time frame, and with acceptable quality.

Where Do Systems Development Projects Come From? Problem – situasi yang tidak diinginkan yang menghalangi organisasi untuk mencapai visi, misi tujuan dan sasarannya Opportunity – kesempatan untuk memperbaiki Directive – persyaratan/permintaan baru yang diberikan oleh manajemen, pemerintah atau beberapa pengaruh luar

Where Do Systems Development Projects Come From? Planned Projects information systems strategy plan telah memeriksa bisnis secara menyeluruh untuk mengidentifikasi proyek pengembangan SI yang akan mengembalikan nilai strategis (jangka panjang) terbesar ke bisnis business process redesign telah menganalisis proses bisnis secara menyeluruh untuk menghilangkan redundancy dan birokrasi serta memperbaiki efisiensi dan nilai yang ditambahkan

Where Do Systems Development Projects Come From? Unplanned projects Dipicu oleh adanya masalah khusus, kesempatan atau perintah Steering committee – administrative body dari system owners dan IT executives yang memprioritaskan dan menyetujui calon proyek pengembangan Backlog – a repository of project proposals yang tidak disetujui

The PIECES Problem-Solving Framework P the need to improve performance I the need to improve information (and data) E the need to improve economics, control costs, or increase profits C the need to improve control or security E the need to improve efficiency of people and processes S the need to improve service to customers, suppliers, partners, employees, etc.

Pengembangan SI

Scope Definition Menentukan ukuran, batasan, visi, partisipan, anggaran dan jadwal. Problem statement – pandangan umum yang diungkapkan dengan jelas dan singkat tentang masalah, kesempatan dan perintah yang memicu proyek, termasuk batasan dan visi awal untuk solusi Synonyms: preliminary study and feasibility assessment. Constraint – banyak faktor, pembatas atau pengekang yang mungkin membatasi solusi atau proses pemecahan masalah Contoh : anggaran, tenggat waktu, sdm, kebijakan bisnis/pemerintah, standart teknologi

Scope Definition Scope creep – suatu fenomena tempat persyaratan dan harapan sebuah proyek meningkat , sering tanpa menghiraukan anggaran dan jadwal. Statement of work – kontrak dengan manajemen dan komunitas pengguna untuk mengembangkan/meningkatkan SI; mendefinisikan vision, scope, constraints, high-level user requirements, schedule, and budget. Synonyms include project charter, project plan, and service-level agreement.

Problem analysis Mempelajari sistem yang ada dan temuan-temuan Apakah keuntungan > biaya Produk : tujuan pengembangan yang mendefinisikan kriteria bisnis tempat SI baru akan dievaluasi (tidak mendefinisikan I-P-O) Contoh : mempercepat waktu proses pesan dan pengepakan menjadi 3 hari Mengurangi kerugian kredit bermasalah sampai 45%

Requirement analysis Mendefinisikan dan memprioritaskan persyaratan-persyaratan bisnis Mengidentifikasi kebutuhan dan prioritas, validasi persyaratan bisnis (wawancara, kuisioner, pertemuan terfasilitasi)

Logical Design Logical design – penerjemhan business user requirements ke dalam system model yang menggambarkan persyaratan bisnis dan bukan desain teknis atau implmentasi dari tersyaratan tersebut. synonyms include conceptual design and essential design. System model – gambar sistem yang mewakili kenyataan atau sistem yang diinginkan.

Logical Design Analysis paralysis – istilah yang mendefinisikan kondisi proyek dimana sistem dimodelkan (kondisi yang memperlambat perkembangan implementasi solusi perbaikan/ pengembangan sistem)

Decision Analysis Pertanyaan yang harus dijawab pada fase ini : Otomatisasi seberapa besar ? Beli or buat Internal or web Teknologi apa? Tujuan : Mengidentifikasi solusi teknis Menganalisa solusi untuk kepraktisan Merekomendasikan sistem calon sebagai solusi target Produk : proposal sistem

Decision Analysis Candidate solutions evaluated in terms of: Technical feasibility – apakah solusi tersebut secra teknis praktis? Apakah ada staf yang memiliki keahlian untuk mendesain dan membangunnya? Operational feasibility – Apakah solusi tsb sesuai dg persyaratan ? Pada tingkatan apa? Bagaimana solusi tersebut akan mengubah lingkungan kerja user? Bagaimana perasaan user terhadap solusi tersebut? Economic feasibility – Is the solution cost-effective? Schedule feasibility – Can the solution be designed and implemented within an acceptable time? Risk feasibility – What is the probability of a successful implementation using the technology and approach?

Physical Design & Integration Physical design – penerjemahan business user requirements ke dalam a system model yang menggambarkan technical implementation dari users’ business requirements. Common synonyms include technical design or implementation model.

Physical Design & Integration Two extreme philosophies of physical design Design by specification – physical system models and detailed specification are produced as a series of written (or computer-generated) blueprints for construction. Design by prototyping – Incomplete but functioning applications or subsystems (called prototypes) are constructed and refined based on feedback from users and other designers.

Construction & testing Tujuan : Membangun dan menguji sebuah sistem yang memnuhi persyaratan bisnis dan spesifikasi desain fisik Mengimplementasikan interface antara sistem baru dan lama Dokumentasi (sistem help, manual pelatihan, help desk, instruksi kontrol, dll) Intalasi s/w yang dibeli

Construction & testing Database OLTP (online transaction processing) => untuk mendukung transaksi bisnis sehari-hari ODS ( operational data store) => untuk mendukung laporan dan permintaan sehari-hari Data warehouse => untuk mendukung kebutuhan analisis data dan keputusan Paket s/w komersial dan atau s/w yang dibuat sendiri User Interface dan sistem

Installation & delivery Menyediakan transisi sistem lama ke baru (instal, konversi file dan database yang ada, pengujian sistem) Membantu user menghadapi masalah start-up yang normal & akibatnya (user manual, control produksi, training) Produk : system operastional

System operational & maintenance System support Dukungan teknik yang berkesinambungan seperti perawatan yang diperlukan untuk menghadapi error, penghilangan (crash program) atau persyaratan baru yang muncul

Cross Life-Cycle Activities Cross life-cycle activity (SIKLUS HIDUP SILANG)– aktifitas apapun yang saling menggantikan banyak atau semua fase proses pengembangan sistem Fact-finding/Information gathering /Data collection the formal process of using research, interviews, meetings, questionnaires, sampling, and other techniques to collect information about system problems, requirements,and preferences/pilihan

Cross Life-Cycle Activities Documentation and presentation Documentation – aktifitas kerkesinambungan of recording facts and specifications for a systems for current and future reference. Presentation – aktifitas berkesinambungan of communicating findings, recommendations, and documentation for review by interested users and mangers. Repository – a database and/or file directory where system developers store all documentation, knowledge, and artifacts for one or more information systems or projects. Feasibility analysis Ukuran seberapa besar keuntungan pengembangan sebuah sistem informasi pada suatu organisasi Mensyaratkan teknik Estimasi/ guesstimation – predisksi terkalkulasi biaya dan usaha yang diperlukan untuk pengembangan sistem

Cross Life-Cycle Activities Process and project management Proses manajement – aktifitas berkesinambungan yang mendokumntasikan, mengajarkan, pengawasi penggunaaan dan memperbaiki metodologi terpilih untuk pengembangan si. Berhubungan dengan fase, aktifitas, produk jadi dan standarkualitas yang harus secara konsisten diterapkan ke semua proyek Project manajement – proses melingkup, merencanakan, menyeiakan staff, mengorganisasikan, mengarahkan dan mengontrol sebuah proyek untuk mengembangkan si dengan biaya minimal, tepat waktu dan kualitas dapat diterima.

Rute dan strategi alternatif

Metodologi dan rute dapat mendukung opsi builds solution atau buy solution Metodologi preskriptif ( sentuh semua dasar; ikuti semua aturan), metodologi adaptif (ubah seperlunya dalam garis pedoman tertentu) Metodologi model driven (buat gambar sistem, fokus pada teknologi berorientasi object) a product driven (bangun produk dan lihat reaksi user, prototiping, extreme programming)

Model-Driven Development Strategy Model-driven development – suatu strategi pengembangan sistem yang menekankan pada pembuatan model-model sistem untuk membantu visualisasi dan analisis masalah, mendefinisikan persyaratan bisnis dan mendesain sistem informasi Process modeling – suatu teknik yang berpusat pada proses yang merupakan metodologi secara terstruktur dalam melakukan analisis dan desain sistem yang menggunakan model business process requirements untuk mendesain s/w sistem

Data modeling – Suatu teknik yang berpusat pada data yang digunakan untuk memodelkan business data requirements (persyaratan) dan mendesain sistem database yang memenuhi persyaratan tersebut. Contoh model data ERD Object modeling – Suatu teknik yang menggabungkan data dan proses dalam satu konsepsi tunggal yang disebut objek. Model-model objek adalah suatu diagram yang mendokumenasikan sistem dalam arti objek dan interaksinya

Model driven development strategy

Rapid Application Development Strategy Rapid application development (RAD) – suatu strategi pengembangan sistem yang menekankan paada kecepatan pengembangan melalui keterlibatan pengguna yang ekstensif dalam konstruksi, berulang dan penambahan seri konstruksi dari functioning prototypes suatu sistem yang pada akhirnya membentuk final system Prototype – suatu model berskala kecil , representatif atau model kerja dari users’ requirements atau proposed design untuk sebuah sistem informasi Timeboxing – pembebanan periode waktu yang tidak dapat diperpanjang (60-90 days) dimana versi pertama sistem harus dikirimkan ke operational.

RAD Development strategy

Commercial Application Package Implementation Strategy Commercial application package – suatu s/w aplikasi yang dapat dibeli dan di customized untuk menentukan kebutuhan bisnis sebagian besar organisasi atau industri tertentu. (disebut juga commercial off-the-shelf (COTS) system) Request for proposal (RFP) – dokumen formal yang mengkomunikasikan persyaratan bisnis, teknik dan dukungan application software package ke vendor-vendor yang ingin bersaing dipenjualan aplikasi dan layanan.

Request for quotation (RFQ) – suatu dokumen formal yang mengkomunikasikan persyaratan bisnis, teknik dan dukungan application software package pada vendor tunggal yang telah ditentukan dan mampu menyuplai aplikasi dan layanan tersebut Gap analysis – suatu perbandingan persyaratan-persyaratan bisnis dan teknik paket aplikasi komersial terhadap kemampuan-kemampuan dan fitur-fitur paket aplikasi komersial spesifik dengan tujuan mendefinisikan persyaratan bisnis yang tidak dapat dipenuhi.

Commercial Application Package Implementation Strategy

Tool for System Development

Extreme Programming (XP) Proses tangguh yang paling luas digunakan, yang dipelopori oleh Kent Beck Perencanaan XP Mulai dari “keinginan user” Tim memeriksa setiap keinginan dan menyebutkan harga Keinginan2x tersebut dikelompokkan untuk proses penyelesaian yang bertahap Komitmen dibuat pada tanggal penyajian Setelah tahap pertama, “kecepatan proyek” digunakan untuk membantu menentukan tanggal berikutnya bagi tahapan yang lain

Extreme Programming (XP) XP Design Mengikuti prinsip KIS Mendorong penggunaan kartu CRC Untuk permasalahan desain yang sukar, menyarankan penggunaan “spike solutions” sebuah desain prototipe Mendorong “refactoring”—sebuah perbaikan iteratif terhadap desain program internal XP Coding Merekomendasikan konstruksi tes unit sebelum coding dimulai Mendorong “pair programming” XP Testing Semua tes unit dieksekusi setiap hari “tes penerimaan” ditentukan oleh konsumen dan dieksekusi untuk melihat fungsionalitas konsumen nyata

Extreme Programming (XP)

Pengembangan PL Adaptif Dipelopori oleh Jim Highsmith ASD — karakter yang membedakan Perencanaan berbasis misi Fokus berbasis komponen Menggunakan “time-boxing” Konsideran eksplisit pada resiko Menekankan kolaborasi bagi pengumpulan kebutuhan Menekankan pembelajaran melalui proses

Adaptive Software Development

Dipromosikan oleh konsorsium DSDM (www.dsdm.org) Metode Pengembangan Sistem Dinamis (Dynamic Systems Development Method) Dipromosikan oleh konsorsium DSDM (www.dsdm.org) DSDM—karakter yang membedakan Mirip dalam banyak dengan XP dan/atau ASD Sembilan prinsip-prinsip panduan : Pelibatan user secara aktif adalah keharusan. Tim DSDM harus diberdayakan untuk mengambil keputusan. Fokus pada penyajian produk sesering mungkin. Penerimaan dari tujuan bisnis adalah kriteria esensial untuk penerimaan penyajian. Pengembangan bertahap dan berulang dibutuhkan untuk fokus pada solusi bisnis yang akurat. Semua perubahan selaman pengembangan dapat dibalik. Kebutuhan adalah dasar pada level tinggi Pengujian terintegrasi dalam siklus kehidupan.

Dynamic Systems Development Method DSDM Life Cycle (with permission of the DSDM consortium)

Scrum Diusulkan oleh Schwaber dan Beedle Scrum—Karakter yang membedakan Kerja pengembangan dipartisi menjadi “paket” Pengujian dan dokumentasi berjalan seiring dengan konstruksi produk Kerja terjadi dalam “Sprint” dan diturunkan dari “backlog” kebutuhan yang ada Pertemuan sangat pendek dan beberapa kali diadalah tanpa kursi “Demo” ditunjukkan pada konsumen dengan alokasi time-box

Scrum

Crystal Diusulkan Cockburn dan Highsmith Crystal—karakter yang membedakan Secara aktual sebuah model proses keluarga yang memungkinkan manuver berdasar karakteristik permasalahan Komunikasi tatap muka ditekankan Menyarankan penggunaan workshop refleksi untuk review kebiasaan kerja tim

Feature Driven Development Diusulkan oleh Peter Coad et al FDD—karakter yang membedakan Penekanan pada definisi “features” a feature “is a client-valued function that can be implemented in two weeks or less.” Menggunakan template feature <action> the <result> <by | for | of | to> a(n) <object> Daftar feature dibuat dan “perencanaan berdasar “feature” dilakukan Desain dan konstruksi bergabung dalam FDD

Feature Driven Development Reprinted with permission of Peter Coad

Agile Modeling Diusulkan oleh Scott Ambler Menyarankan prinsip2x agile modeling Model dengan sebuah tujuan Menggunakan banyak model Isi lebih penting dari representasi Mengetahui model dan tool yang digunakan untuk membuatnya Beradaptasi secara lokal