Tugas Kelompok ke-2
Minggu 2Team 4Agung Dwi W.(1801437565)
Audia Inayah (1801437691)
David Frans S(1801437634)
R. Anandika(1801437716)
Sholeh Hidayat(1801437691)
JURNAL SISTEM INFORMASI MANAJEMENPENDEKATAN UNTUK MEMBANGUN SISTEM
Dosen Pengampu: Yuniadi Mayowan, S.SOS.MAB
Anggota Kelompok 4:
Agung Dwi W.(1801437565)
Audia Inayah (1801437691)
David Frans S(1801437634)
R. Anandika(1801437716)
Sholeh Hidayat(1801437691)
KEMENTRIAN PENDIDIKAN DAN KEBUDAYAAN
UNIVERSITAS BRAWIJAYA
FAKULTAS ILMU ADMINISTRASI
Jalan. MT. Haryono 163, Malang 65145, Jawa Timur, Indonesia
Telp. +62-341-553737, 568914, 558226 Fax. +62-341-558227
E-mail: [email protected] Website: http://fia.ub.ac.idKATA PENGANTAR
Segala puji bagi Allah SWT yang telah melimpahkan rahmat dan hidayah-Nya, sehingga penulisan makalah yang berjudul PENDEKATAN UNTUK MEMBANGUN SISTEM ini dapat diselesaikan. Penulis mengucapkan terima kasih kepada seluruh pihak-pihak yang telah membantu dalam pembuatan makalah ini baik secara langsung maupun tidak langsung.
Penulisan makalah ini dalam rangka untuk memenuhi tugas Sistem Informasi Manajemen dan diharapkan dengan adanya makalah ini pembaca dapat menambah wawasan tentang kekuasaan, politik dan kepemimpinan.Penulis menyadari dalam penulisan makalah ini masih kurang sempurna. Oleh karena itu, segala kritik yang bersifat membangun akan penulis terima dengan tangan terbuka.
Malang, Mei 2015 Penulis
DAFTAR ISI
HALAMAN SAMPUL
i
KATA PENGANTAR
ii
DAFTAR ISI
iii
BAB I : PENDAHULUAN
1.1 Latar Belakang
11.2 Rumusan Masalah
11.3 Tujuan
2BAB II : PEMBAHASAN
2.1 Menilai Alternatif Membangun Sistem
32.1.1 Pengertian Sistem Informasi
3
2.1.2 Rumusan Sistem Informasi
32.1.3 Analisis Sistem
42.1.4 Prinsip Dasar Desain Sistem
52.1.5 Langkah- Langkah Dalam Desain sistem
52.1.6 Perancangan Sistem
62.2 Pendekatan Pengembangan Sistem
62.3 Menilai Solusi Ke Permasalahan Yang Diciptakan Oleh Pendekatan 102.4 Alat Yang Digunakan Dalam Metodologi Pengembangan Sistem 12BAB III : PENUTUP
3.1 Kesimpulan
15
3.2 Saran
15 DAFTAR PUSTAKA
16BAB I
PENDAHULUAN
1.1 Latar Belakang
Di era yang dinamis dan modern ini Sistem Informasi merupakan salah satu hal vital dalam membatu perkembangan suatu organisasi. Sistem Informasi Manajemen merupakan sebuah sisitem informasi berbasis komputer yang digunakan oleh suatu organisasi atau perusahaan untuk memberikan informasi-informasi yang dibutuhkan guna membaru manajer maupun non-manajer dalam pembuatan keputusan untuk organisasi tersebut.
Salah satu komponen utama Sistem Informasi dapat berjalan dengan baik adalah perangkat komouter, namun di sisi lain koponen utama yang juga menjadi penunjang sitem informasi yang baik adalah sumber daya manusi yang mempergunakan sistem informasi tersebut yakni manajer. Seorang manajer harus memilki keterampilan dan kemampuan penguasaan Sistem Informasi dengan baik guna dapat membatunya dalam mengambil keputusan dnegan cepat dan tepat.
Namun sampai saat ini masih banyak penggunan Sistem Informasi yang belu maksimal dikarenakan banyak faktor penghalangnya yakni berupa masih banyaknya perencanaan sisitem yang belum memadai, sumber daya manusia yang memanfaatkan masih belu maksimal, serta masih banyaknya organisasi-organisasi yang masih tidak wajar. Hal inilah yang membuat manfaat SIM belum dapat dimaksimalkan dalam membatu pengembangan perusahaan. Untuk mencapai sebuah keselarsan anatara sebuah sistem informasi dan organisasi maka diperlukan beberapa pendekatan-pendekatan baru untuk mendesain ulang sistem dalam suatu organisasi.
1.2 Rumusan Masalah
Beberapa ruusan masalah yang akan dibahas dalam makalah Sistem Informasi Pendekatan Untuk Membangun Sistem adalah:
1. Bagaimana menilai alternatif membangun sistem?
2. Apakah kekuatan dan kelemahan tentang pendekatan yang dipakai?
3. Bagaimana solusi ke permasalahan yang diciptakan oleh pendekatan?
4. Apa saja alat yang digunakan dalam metodologi pengembangan sistem?
1.3 Tujuan
Adapun tujuan yang diharapkan dalam pembahasan rumusan masalah di atas antara lain:
1. Untuk mengetahui cara-cara alternatif membangun sistem.
2. Untuk mengetahui kekuatan dan kelemahan tentang pendekatan yang dipakai.
3. Untuk mengetahui solusi ke permasalahan yang diciptakan oleh pendekatan.
4. Untuk mengetahui alat yang digunakan dalam metodologi pengembangan sistem.
BAB II
PEMBAHASAN
2.1 Menilai Alternatif Membangun Sistem
2.1.1 Pengertian Sistem Informasi
Beberapa pengertian Sistem Informasi Manajemen menurut para ahli :
a. Menurut Barry E.Cushing, SIM adalah :
Suatu sistem informasi manajemen adalah Kumpulan dari manusia dan sumber daya modal di dalam suatu organisasi yang bertanggung jawab mengumpulkan dan mengolah data untuk mengahasilkan informasi yang berguna untuk semua tingkatan manajemen di dalam kegiatan perencanaan dan pengendalian
b. Menurut Frederick H.Wu SIM adalah :
Sistem Informasi Manajemen adalah kumpulan-kumpulan dari sistem-sistem yang menyediakan informasi untuk mendukung manajemen
c. Menurut L. James Havery , SIM adalah:
prosedur logis dan rasional untuk merancang suatu rangkaian komponen yang berhubungan satu dengan yang lainnya dengan maksud untuk berfungsi sebagai suatu kesatuan dalam usaha mencapai suatu tujuan yang telah ditentukan. Sistem Informasi merupakan sebuah sarana vital atau penting dalam suatu perusahaan dikarekan SIM dapat membantu manajer suatu perusahaan atau organisasi untuk membuat keputusan dalam menyelesaikan masalah di manajemen bisnis yang semakin rumit dan dinamis ini.
2.1.2 Rumusan Sistem Informasi
Suatu sistem sangatlah dibutuhkan dalam suatu perusahaan atau instansi pemerintahan , karena sistem sangatlah menunjang terhadap kinerja perusahaan atau instansi pemerintah , baik yang berskala kecil maupun besar.Runag lingkup sistem informasi berlandaskan pada tiga istilah pemebentuknya yakni sistem, informasi, manajemen.
Sistem kumpulan dari elemen-elemen yang berinteraksi untuk mencapai suatu tujuan tertentu. dalam istilah tersebut yang dimaksud dengan elemen dari suatu sistem adalah departemen internal seperti persedian barang mentah, persediaaan barang jadi, produksi, pemasaran serta departemen eksternal yang terdiri dari supplier dan konsumen yang saling memebutuhkan satu sama lain untuk melakukan proses usaha.
Informasi adalah hasil pemrosesan data yang diperoleh dari setiap elemen sistem tersebut menjadi bentuk yang mudah dipahami dan merupakan pengetahuan yang relevan yang dibutuhkan oleh orang untu menambah pemahamannya terhadap fakta-fakta yang ada.Manajemen adalah Manajemen terdiri dari proses atau kegiatan yang dilakukan oleh pengelola perusahaan seperti merencanakan (menetapkan strategi, tujuan dan arah tindakan), mengorganisasikan, memprakarsai, mengkoordinir dan mengendalikan operasi untuk mencapai tujuan yang telah ditetapkan.
Dari ketiga istilah dasar di atas dapat disimpulkan bahwa sistem informasi manajemen adalah suatu suatu sistem yang berbasis komputer yang dipergunakan oleh suatu kelompok organisasi atau suatu perkumpulan formal untuk menyediakan informasi-informasi guna membantu manajer ataupun non manajer untuk mengambil keputusan.
2.1.3 Analisis Sistem
Pengertian analisis sistem adalah Penguraian dari suatu sistem informasi yang utuh kedalam bagian-bagian komponennya dengan maksud untuk mengidentifikasi dan mengevaluasi permasalahan-permasalahan , kesempatan-kesempatan, hambatan-hambatan yang terjadi dan kebutuhan-kebutuhan yang diharapkan sehingga dapat diusulkan perbaikan-perbaikannya. Tahap analisis sistem merupakan tahap yang kritis dan sangat penting , karena kesalahan didalam tahap ini akan menyebabkan kesalahan ditahap berikutnya.Alasan perlunya dilakukan analisis sistem :
a. Problem-solving: sistem lama tidak berfungsi sesuai dengan kebutuhan. Untuk itu analisis diperlukan untuk memperbaiki sistem sehingga dapat berfungsi sesuai dengan kebutuhan.
b. Kebutuhan baru: adanya kebutuhan baru dalam organisasi atau lingkungan sehingga diperlukan adanya modifikasi atau tambahan sistem informasi untuk mendukung organisasi.
c. Mengimplementasikan ide atau teknologi baru.
d. Meningkatkan performansi sistem secara keseluruhan
2.1.4 Prinsip Dasar Desain Sistem
Ada 2 prinsip dasar desain:
1. Desain sistem monolitik. Ditekankan pada integrasi sistem. Resource mana yang bisa diintegrasikan untuk memperoleh sistem yang efektif terutama dalam cost.
2. Desain sistem modular. Ditekankan pada pemecahan fungsi-fungsi yang memiliki idependensi rendah menjadi modul-modul (subsistem fungsional) yang terpisah sehingga memudahkan kita untuk berkonsentrasi mendesain per modul.
2.1.5 Langkah- Langkah Dalam Desain sistem
1. Mendefinisikan tujuan sistem (defining system goal), tidak hanya berdasarkan informasi pemakai, akan tetapi juga berupa telaah dari abstraksi dan karakteristik keseluruhan kebutuhan informasi sistem.
2. Membangun sebuah model konseptual (develop a conceptual model), berupa gambaran sistem secara keseluruhan yang menggambarkan satuan fungsional sebagai unit sistem.
3. Menerapkan kendala-kendala organisasi (applying organizational contraints). Menerapkan kendala-kendala sistem untuk memperoleh sistem yang paling optimal. Elemen organisasi merupakan kendala, sedangkan fungsi-fungsi yang harus dioptimalkan adalah: performance, reliability, cost, instalation schedule, maintenability, flexibility, grouwth potensial, life expectancy. Model untuk sistem optimal dapat digambarkan sebagai sebuah model yang mengandung: kebutuhan sistem dan sumber daya organisasi sebagai input; faktor bobot terdiri atas fungsi-fungsi optimal di atas; dan total nilai yang harus dioptimalkan dari faktor bobot tersebut.
4. Mendefinisikan aktifitas pemrosesan data (defining data processing activities).
5. Menyiapkan proposal sistem desain. Proposal ini diperlukan untuk manajemen apakah proses selanjutnya layak untuk dilanjutkan atau tidak.
2.1.6 Perancangan Sistem
Desain berkonsentrasi pada bagaimana system dibangun untuk memenuhi kebutuhan pada fase analisis.
Elemen-elemen pengetahuan yang berhubungan dengan proses desain system :
Sumber daya organisasi: bertumpu pada 5 unsur organisasi, yaitu: man, machines, material, money dan methods.
Informasi kebutuhan dari pemakai: informasi yang diperoleh dari pemakai selama fase analisis sistem.
Kebutuhan sistem: hasil dari analisis sistem.
Metode pemrosesan data, apakah: manual, elektromechanical, puched card, atau computer base.
Operasi data. Ada beberapa operasi dasar data, a.l: capture, classify, arrange, summarize, calculate, store, retrieve, reproduce dan disseminate.
Alat bantu desain, seperti: dfd, dcd, dd, decision table.2.2 Pendekatan Pengembangan Sistem
Terdapat beberapa pendekatan untuk mengembangkan sistem, yaitu:
a. Pendekatan Klasik
Pendekatan Klasik (classical approach) disebut juga dengan Pendekatan Tradisional (traditional approach) atau Pendekatan Konvensional (conventional approach). Metodologi Pendekatan Klasik mengembangkan sistem dengan mengikuti tahapan-tahapan pada System Life Cycle. Pendekatan ini menekankan bahwa pengembangan akan berhasil bila mengikuti tahapan pada System Life Cycle.
Permasalahan-permasalahan yang dapat timbul pada Pendekatan
Klasik adalah sebagai berikut :
1. Pengembangan perangkat lunak akan menjadi sulit
Pendekatan klasik kurang memberikan alat-alat dan teknik-teknik di dalam mengembangkan sistem dan sebagai akibatnya proses pengembangan perangkat lunak menjadi tidak terarah dan sulit untuk dikerjakan oleh pemrogram. Lain halnya dengan pendekatan terstruktur yang memberikan alat-alat seperti diagram arus data (data flow diagram), kamus data (data dictionary), tabel keputusan (decision table). Diagram IPO, bagan terstruktur (structured chart) dan lain sebagainya yang memungkinkan Pengembangan Sistem Informasipengembangan perangkat lunak lebih terarah berdasarkan alat-alat dan teknik-teknik tersebut .
2. Biaya perawatan atau pemeliharaan sistem akan menjadi mahal Mahalnya biaya perawatan pada pendekatan sistem klasik disebabkan karena dokumentasi sistem yang dikembangkan kurang lengkap dan kurang terstruktur.Dokumentasi ini merupakan hasil dari alat-alat dan teknik -teknik yang digunakan. Karena pendekatan klasik kurang didukung oleh alat-alat dan teknik-teknik, maka dokumentasi menjadi tidak lengkap dan walaupun ada tetapi strukturnya kurang jelas, sehingga pada waktu pemeliharaan sistem menjadi kesulitan.
3. Kemungkinan kesalahan sistem besar
Pendekatan klasik tidak menyediakan kepada analis sistem cara untuk melakukan pengetesan sistem, sehingga kemungkinan kesalahan-kesalahan sistem akan menjadi lebih besar.
4. Keberhasilan sistem kurang terjamin
Penekanan dari pendekatan klasik adalah kerja dari personil-personil pengembang sistem, bukan pada pemakai sistem, padahal sekarang sudah disadari bahwa dukungan dan pemahaman dari pemakai sistem terhadap sistem yang sedang dikembangkan merupakan hal yang vital untuk keberhasilan proyek pengembangan sistem pada akhirnya.
b. Pendekatan Terstruktur Pendekatan terstruktur akan dilengkapi dengan alat-alat dan teknik-teknik yang dibutuhkan dalam pengembangan sistem, sehingga hasil akhir dari sistem yang dikembangkan akan didapatkan sistem yang strukturnya didefinisikan dengan baik dan jelas. Melalui pendekatan struktur,permasalahan yang kompleks dalam organisasi dapat dipecahkan dan hasil dari produktifitas dan kualitasnya lebih baik ( bebas kesalahan ).
Keuntungan pendekatan terstruktur :
Mengurangi kerumitan masalah
Konsep mengarah pada sistem yang ideal
Standarisasi
Orientasi kemassa datang
Mengurangi ketergantungan pada desainer
Kekurangan:
SSAD berorientasi utama pada proses, sehingga mengabaikan kebutuhan non-fungsional.
Sedikit sekali manajemen langsung terkait dengan SSAD.
Prinsip dasar SSAD merupakan pengembangan non-iterasi (waterfall)
Interaksi antara analisis atau pengguna tidak komprehensif, karena sistem telah didefinisikan dari awal, sehingga tidak adaptif terhadap perubahan (kebutuhan-kebutuhan baru).
Selain dengan menggunakan desain logic dan DFD, tidak cukup tool yang digunakan untuk mengkomunikasikan dengan pengguna, sehingga sangat sulit bagi pengguna untuk melakukan evaluasi.
c. Dari Bawah Ke Atas (Bottom-up Approach)
Pendekatan ini dimulai dari level bawah organisasi, yaitu level operasional dimana transaksi dilakukan. Pendekatan ini dimulai dari perumusan kebutuhan-kebutuhan untuk menangani transaksi dan naik ke level atas dengan merumuskan kebutuhan informasi berdasarkan transaksi tersebut. Pendekatan ini ciri-ciri dari pendekatan klasik. Pendekatan dari bawah ke atas bila digunakan pada tahap analisis sistem disebut juga dengan istilah data analysis, karena yang menjadi tekanan adalah data yang akan diolah terlebih dahulu, informasi yang akan dihasilkan menyusul mengikuti datanya.
d. Pendekatan Dari Atas Ke Bawah (Top-down Approach)
Pendekatan Dari Atas Ke Bawah (Top-down Approach) dimulai dari level atas organisasi, yaitu level perencanaan strategi. Pendekatan ini dimulai dengan mendefinisikan sasaran dan kebijaksanaan organisasi. Langkah selanjutnya dari pendekatan ini adalah dilakukannya analisis kebutuhan informasi. Setelah kebutuhan informasi ditentukan, maka proses turun ke pemrosesan transaksi, yaitu penentuan output, input, basis data, prosedur-prosedur operasi dan kontrol. Pendekatan ini juga merupakan ciri-ciri pendekatan terstruktur. Pendekatan atas-turun bila digunakan pada tahap analis sistem disebut juga dengan istilah decision analysis, karena yang menjadi tekanan adalah informasi yang dibutuhkan untuk pengambilan keputusan oleh manajemen terlebih dahulu, kemudian data yang perlu diolah didefinisikan menyusul mengikuti informasi yang dibutuhkan.
e. Pendekatan Sepotong (piecemeal approach)
Pengembangan yang menekankan pada suatu kegiatan/aplikasi tertentu tanpa memperhatikan posisinya di sistem informasi atau tidak memperhatikan sasaran organisasi secara global (memperhatikan sasaran dari kegiatan atau aplikasi itu saja).
f. Pendekatan Sistem (systems approach)
Memperhatikan sistem informasi sebagai satu kesatuan terintegrasi untuk masing-masing kegiatan/aplikasinya dan menekankan sasaran organisasi secara global.
g. Pendekatan Sistem menyeluruh (total-system approach)
Pendekatan pengembangan sistem serentak secara menyeluruh, sehingga menjadi sulit untuk dikembangkan (ciri klasik).
h. Pendekatan Moduler (modular approach)
Pendekatan dengan memecah sistem komplek menjadi modul yang sederhana, sehingga sistem lebih mudah dipahami dan dikembangkan, tepat waktu, mudah dipelihara (ciri terstruktur)
i. Pendekatan Lompatan jauh (great loop approach)
Pendekatan yang menerapkan perubahan menyeluruh secara serentak menggunakan teknologi canggih, sehingga mengandung resiko tinggi, terlalu mahal, sulit dikembangkan karena terlalu komplek.
j. Pendekatan Berkembang (evolutionary approach)
Pendekatan yang menerapkan teknologi canggih hanya untuk aplikasi-aplikasi yang memerlukan saja dan terus dikembangkan untuk periode berikutnya mengikuti kebutuhan dan teknologi yang ada.
2.3 Menilai Solusi Ke Permasalahan Yang Diciptakan Oleh Pendekatan
Dalam pengembangan sebuah sistem, kita mengenal konsep SDLC (system development life cycle). Dapat dikatakan dalam SDLC merupakan usaha bagaimana sebuah sistem informasi dapat mendukung kebutuhan bisnis, rancangan & pembangunan sistem serta delivering-nya kepada pengguna. Secara umum, tahapan SDLC meliputi proses perencanaan, analisis, desain dan implementasi.
a. Planning
Proses perencanaan biasanya lebih menekankan pada alasan mengapa sebuah sistem harus dibuat.
b. Analysis
Tahapan perencanaan ini kemudian dilanjutkan dengan proses analisis yang lebih menekankan pada siapa, apa, kapan dan dimana sebuah sistem akan dibuat.
c. Design
Sedangkan pada proses desain lebih menekankan kepada bagaimana sistem akan berjalan.
e. Implementation Tahap terakhir dilanjutkan dengan fase implementasi yaitu proses delivery-nya kepada pengguna.
Beberapa metodologi yang biasa dikenal antara lain Structural Design, Rapid Application Development (RAD) dan Agile Development,
a. Structural Design
Merupakan sebuah metode pengembangan sistem dimana antara satu fase ke fase yang lain dilakukan secara berurutan. Keuntungan menggunakan metodologi ini requirement harus didefinisikan lebih mendalam sebelum proses coding dilakukan, sesedikit mungkin perubahan dilakukan pada saat proyek berlangsung. Kelemahannya, desain harus komplit sebelum programming dimulai, serta jika terjadi fase yang terlewati, maka biaya yang akan ditimbulkan akan lumayan besar.
b. Rapid Application Development (RAD)
Metodologi ini melakukan beberapa penyesuaian terhadap SDLC pada beberapa bagian sehingga lebih cepat untuk sampai ke tangan pengguna. Beberapa kategori RAD yaitu :
Phased Development membagi sistem secara keseluruhan menjadi beberapa versi sistem. Setelah desain untuk versi pertama selesai maka akan dilanjutkan ke implementasi. Setelah versi pertama terselesaikan, maka pengembang akan memulai lagi ke versi selanjutnya.
Metodologi prototyping melakukan analisis, desain dan implementasi secara bersamaan, kemudian dilakukan secara berulang-ulang untuk mendapat review dari pengguna. Sebuah prototiping adalah sebuah sistem dalam fungsi yang sangat minimal.
Throwaway Prototyping hampir sama dengan metodologi Prototyping. Perbedaannya bahwa pada metodologi ini, analisis dilakukan lebih mendalam lagi.
Untuk memilih metodelogi yang paling baik digunakan dalam suatu organisasi harus dialukan beberapa pertimbangan yang matang. Pasalnya tidak semua organiasi bisa sesuai atau cocok dengan metodelogi yang ada. Beberapa pertimbangan yang harus dicermati sebelu memilih metodelogi yang diterapkan adalah : kejelasan kebutuhan pengguna, penguasaan teknologi, tingkat kerumitan sistem, tingkat kehandalan sistem , waktu pelaksanaan dan visibilitas jadwal pelaksanaan.
Lima tahapan yang dapat disebutkan menurut Laudon (1991) untuk pemecahan masalah:
1) Mengidentifikasi dan menganalisis masalah,
2) Menyelidiki dan memahami masalah,
3) Memilih opsi terbaik,
4) Mendesain solusi, dengan teknik desain fisik atau lagis,
5) Mengimplementasikan solusi.
2.4 Alat Yang Digunakan Dalam Metodologi Pengembangan Sistem
Dalam suatu metodologi pengembangan sistem dibutuhkan alat dan teknik. Alat yang biasanya digunakan untuk metodologi sistem adalah gambar, grafik, kamus data, struktur inggris, pseudocode atau formulir-formulir untuk mencatat atau menyajikan data.
1. Alat yang digunakan untuk metodologi pengembangan sistem salah satnya adalah grafik yang meliputi :
Diagram HIPO ( Hierarchy plus Input-Proses-Output ), Untuk mempresentasikan hierarki modul-modul program tidak termasuk dokumentasi interface antar modul
Diagram aliran data ( DFD/ data Flow Diagram )
Diagram keterhubungan entitas ( ERD/ Entity Relationship Diagram )
Diagram perubahan status ( STD/ State Transaction Diagram )
Structured Chart, Untuk mempresentasikan hirarki modul-modul program termasuk interface antar modul.
Diagram SATD ( Structure Analysis and desaign Techniques )
Diagram Warnier/ Orr, Untuk mempresentasikan struktur program dari gambaran umum sampai detail.
Diagram Jackson . Alat yang berbentuk grafik yang umum dapat digunakan dalam semua metodologi antaralain bagan alir system, bagan alir program, bagan alir proses, bagan organisasi dll.
2. Teknik Pengembangan Sistem yang dapat digunakan pada semua metodologi:
Teknik Manajemen Proyek, yaitu CPM ( Critical Path Metode ) dan PERT (Program Evaluation dan Review Techniques ), teknik ini digunakan untuk penjadwalan proyek.
Teknik menemukan fakta, yaitu teknik yang dapat digunakan untuk mengumpulkan data dan menemukan fakta dalam kegiatan mempelajari sistem yang ada. Teknik ini antara lain wawancara, observasi, kuesioner dan pengumpulan sample.
Teknik analisis biaya/manfaat adalah suatu teknik yang digunakan untuk menghitung biaya yang berhubungan dengan pengembangan sistem informasi seperti, biaya pengadaan, biaya persiapan, biaya proyek dan biaya operasi.
Teknik untuk menjalankan rapat . Tujuan dari rapat dalam pengembangan sistem diantaranya adalah untuk : mendefinisikan masalah , mengumpulkan ide-ide ,memecahkan permasalahan dan konflik , menganalisis kemajuan proyek, mengumpulkan data atau fakta
Teknik Inspeksi/walkthrough. Proses dari analisis dan desain sistem harus diawasi. Pengawasan ini dapat dilakukan dengan cara memverifikasi hasil dari setiap tahap pengembangan sistem. Verifikasi hasil kerja secara formal disebut dengan inspeksi sedangkan yang tidak formal disebut walkthrough.
BAB III
PENUTUP
3.1 KesimpulanSistem informasi manajemen adalah suatu suatu sistem yang berbasis komputer yang dipergunakan oleh suatu kelompok organisasi atau suatu perkumpulan formal untuk menyediakan informasi-informasi guna membantu manajer ataupun non manajer untuk mengambil keputusan. Di era saat ini masih banyak perusahaan tau organisasi yang masih belum bisa memaksimalkan penggunaan sistem informasi. Oleh sebab itu perlu adanya analisi pendekatan sistem kembali untuk menyesuaikan dengan kebutuhan organisasi tersebut.
Terdapat beberapa pendekatan untuk mengembangkan sistem, yaitu:Pendekatan Klasik, Pendekatan Terstruktur, pendekatan dari bawah ke atas, pendekatan dari atas ke bawah, pendekatan sistem, pendekatan sepotong, pendekatan sistem menyeluruh, pendekatan moduler, pendekatan lompatan jauh, pendekatan berkembang.
Dalam pengembangan sebuah sistem, kita mengenal konsep SDLC (system development life cycle). Secara umum, tahapan SDLC meliputi proses perencanaan, analisis, desain dan implementasi. Beberapa metodologi yang biasa dikenal antara lain Structural Design, Rapid Application Development (RAD) dan Agile Development.
Dalam suatu metodologi pengembangan sistem dibutuhkan alat dan teknik. Alat yang biasanya digunakan untuk metodologi sistem adalah gambar, grafik, kamus data, struktur inggris, pseudocode atau formulir-formulir untuk mencatat atau menyajikan data.3.2 SaranDengan adanya analisi desin baru suatu sistem perusahaan atau organisasi diharapkan sistem baru tersebut dapat membantu tugas manjer dalam membuat keputusan. Selain sistem dirancang dengan desain baru, SDM yang mengelola sistem juga harus memilki kemampuan yang mumpuni.REFERENSI
Chr. Jimmy L.Gaol. Sistem Informasi Manajemen: Pemahaman dan Aplikasi. Grasindo
http://saifulrahman.lecture.ub.ac.id/?s=pendekatan++membangun+sistemhttp://jemeinulle.blogspot.com/2010/11/pendekatan-pengembangan-sistem.htmlhttp://fizzulhaq.blogspot.com/2009/11/pengertian-sistem-informasi-manajemen.html
DAFTAR ISI
Abstrak.1
Pendahuluan.1
Identifikasi Masalah.2
Ruang Lingkup.2
Tujuan dan Manfaat.............................................................................................................3
Extreme Programming.........................................................................................................3
Requirements engineering...4Material Requirements Planning (MRP).4
Perkembangan XP5
Analisis Penambahan Fase Requirements Management..................................7
Perhitungan Kategori Agile.................................................................................................9
Penerapan XP.10Aktifitas Requirement11
Metodologi Penelitian....14Profil Perusahaan...15Kesimpulan....16Saran..17
Daftar Pustaka18
Daftar Riwayat Hidup20REQUIREMENTS MANAGEMENT PADA EXTREME PROGRAMMING
ABSTRAKMetodologi pengembangan perangkat lunak yang berkembang saat ini telah beralih ke metodologi yang lebih sederhana. Metodologi yang dikenal sebagai agile methods ini mengutamakan fleksibilitas terhadap perubahan-perubahan yang terjadi selama pengembangan. Bahkan perubahan ataupun penambahan pada saat fase terakhir pun teratasi apabila menggunakan metodologi ini. Salah satu yang paling popuper yaitu eXtreme Programming. Metodologi ini memiliki keunikan yang sebenarnya juga bisa menjadi kelemahannya, yaitu tanpa dokumentasi formal. Makalah ini akan mencoba memasukkan dokumentasi sederhana pada extreme programming sebagai requirements management. Selanjutnya hasil penambahan sebagai fase requirements management tersebut diuji dengan distribusi normal untuk menunjukkan bahwa penambahan tersebut mempertahankan eXtreme Programming dalam batas-batas agile method.
Kata kunci: Agile methods, eXtreme Programming, requirements management.PENDAHULUAN
Bidang pengembangan perangkat lunak berkembang sangat pesat dewasa ini. Dalam perkembangannya ini tidak terlepas dari peran metodologi yang digunakan untuk membangun. Jika kita lihat kembali ke belakang, berbagai metodologi untuk mengembangkan perangkat lunak telah cukup banyak diperkenalkan. Mulai dari model waterfall sampai dengan model-model incremental. Semua metodologi yang berkembang sebelumnya tidak mampu menangani kemungkinan perubahan atau penambahan requirements yang terjadi pada saat pengembangan dilaksanakan atau bahkan pada waktu fase terakhir pengembangan. Hal inilah yang mendorong munculnya metodologi atau model pengembangan perangkat lunak yang baru yang mampu mengatasi kekurangan tersebut.
Pada dekade 90-an diperkenalkan metodologi baru yang dikenal dengan nama agile methods. Metodologi ini sangat revolusioner perubahannya jika dibandingkan dengan berbagai metode sebelumnya. Agile Methods dikembangkan karena pada metodologi tradisional terdapat banyak hal yang membuat proses pengembangan tidak dapat berhasil dengan baik sesuai tuntutan user. Saat ini metodologi ini sudah cukup banyak berkembang, di antaranya adalah :
eXtreme Programming (XP)
Scrum Methodology
Crystal Family
Dynamic Systems Development Method (DSDM)
Adaptive Software Development (ASD)
Feature Driven Development (FDD)
Jika kita lihat, agile bisa berarti tangkas, cepat, atau ringan. Agility merupakan metode yang ringan dan cepat dalam pengembangan perangkat lunak. Agile Alliance mendefinisikan 12 prinsip untuk mencapai proses yang termasuk dalam agility:
1. Prioritas tertinggi adalah memuaskan pelanggan melalui penyerahan awal dan berkelanjutan perangkat lunak yang bernilai.
2. Menerima perubahan requirements meskipun perubahan tersebut diminta pada akhir pengembangan.
3. Memberikan perangkat lunak yang sedang dikerjakan dengan sering, beberapa minggu atau beberapa bulan, dengan pilihan waktu yang paling singkat.
4. Pihak bisnis dan pengembang harus bekerja sama setiap hari selama pengembangan berjalan.
5. Bangun proyek dengan individu-individu yang bermotivasi tinggi dengan memberikan lingkungan dan dukungan yang diperlukan, dan mempercayai mereka sepenuhnya untuk menyelesaikan pekerjaannya.
6. Metode yang paling efektif dan efisien dalam menyampaikan informasi kepada tim pengembangan adalah dengan komunikasi langsung face-to-face.
7. Perangkat lunak yang dikerjakan merupakan pengukur utama kemajuan.
8. Proses agile memberikan proses pengembangan yang bisa ditopang. Sponsor, pengembang, dan user harus bisa menjaga ke-konstanan langkah yang tidak pasti.
9. Perhatian yang terus menerus terhadap rancangan dan teknik yang baik meningkatkan agility.
10. Kesederhanaan seni untuk meminimalkan jumlah pekerjaan adalah penting.
11. Arsitektur, requirements, dan rancangan terbaik muncul dari tim yang mengatur sendiri.
12. Pada interval reguler tertentu, tim merefleksikan bagaimana menjadi lebih efektif, kemudian menyesuaikannya.
Identifikasi Masalah
Extreme Programming mempunyai beberapa kerugian seperti developer harus selalu siap dengan perubahan karena perubahan akan selalu diterima, tidak bisa membuat kode yang detail di awal (prinsip simplicity dan juga anjuran untuk melakukan apa yang diperlukan hari itu juga.
Ruang Lingkup
Adapun batasan masalah dalam penulisan ini adalah sebagai berikut :
1. mengurangi dampak kerugian-kerugian yang akan dihadapi
2.mengefektifkan dan mengefisienkan dalam menyampaikan informasi kepada tim pengembangan
3.Aplikasi akan dikembangkan sampai dengan tahap prototipe sistem
4.Metode XP merupakan yang terpopuler dari beberapa metodologi pengembangan software yang dipakai untuk mengimplementasikan proyek pengembangan perangkat lunak
5.Ruang lingkup Requirement Management Plan ini hanya terbatas pada proyek sistem informasi manajemen keuangan
Tujuan dan Manfaat
Tujuan dari penulisan ini adalah :
1.mengetahui cara menurunkan biaya dari adanya perubahan software2.untuk mendefinisikan skema kebutuhan sistem dan atribut-atributnya
3.untuk melakukan pencarian, pengorganisasian dan dokumentasi kebutuhan sistem
Manfaat dari penulisan ini adalah :
1.Mendapat gambaran bagaimana melakukan perencanaan yang benar
2.menjelaskan bagaimana kebutuhan ditata dan dicatat dalam proyek
3.menjelaskan proses pengelolaan perubahan kebutuhan-kebutuhan yang adaExtreme ProgrammingExtreme Programming (XP) adalah metode pengembangan perangkat lunak yang ringan dan termasuk salah satu agile methods.( Beck, 2000, p5).Menurut Beck (2000,p7) tujuan jangka pendek individu sering berbenturan dengan tujuan sosial jangka panjang. Karena itu dibuatlah values yang menjadi aturan, hukuman, dan juga penghargaan. Keempat values tersebut adalah :
1. Komunikasi (Communication)
Tugas utama developer dalam membangun suatu sistem perangkat lunak adalah mengkomunikasikan kebutuhan sistem kepada pengembang perangkat lunak. 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. Tujuannya untuk memberikan pandangan pengembang sesuai dengan pandangan pengguna sistem.2. Kesederhanaan (Simplicity)
XP mencoba untuk mencari solusi paling sederhana dan praktis. Perbedaan metode ini dengan metodologi pengembangan sistem konvensional lainnya terletak pada proses desain dan coding yang terfokus pada kebutuhan saat ini daripada kebutuhan besok, seminggu lagi atau sebulan lagi. Lebih baik melakukan hal yang sederhana dan mengembangkannya besok jika diperlukan.
3. Umpan Balik (Feedback)
Hal ini diperlukan untuk mengetahui kemajuan dari proses dan kualitas dari aplikasi yang dibangun. Informasi ini harus dikumpulkan setiap interval waktu yang singkat secara konsisten. Ini dimaksudkan agar hal-hal yang menjadi masalah dalam proses pengembangan dapat diketahui sedini mungkin. Setiap feed back ditanggapi dengan melakukan tes, unit test atau system integration dan jangan menunda karena biaya akan membengkak (uang, tenaga, waktu).
4. Keberanian (Courage)
Berani mencoba ide baru. Berani mengerjakan kembali dan setiap kali kesalahan ditemukan, langsung diperbaiki. Contoh dari courage adalah komitmen untuk selalu melakukan design dan coding untuk saat ini dan bukan untuk esok. Ketika ada kode yang terlalu rumit, sulit dibaca dan dipahami, tidak sesuai dengan kemauan pelanggan, dll maka seharusnya kode program seperti itu di refactor (kalau perlu dibangun ulang). Hal ini menjadikan pengembang merasa nyaman dengan refactoring program ketika diperlukan.
Requirements engineeringMenurut Zave (1997,pp315-321), secara sederhana requirements engineering adalah cabang dari software engineering yang terkait dengan tujuan di dunia nyata untuk fungsi dan batasan pada system software.
Menurut Nuse (2000,p145) secara luas, software systems requirements engineering (RE) adalah proses untuk menemukan suatu himpunan requirement yang tepat sehingga suatu perangkat lunak dapat memenuhi kegunaannya.
Proses ini dilakukan dengan cara mengenali para stakeholder serta kebutuhan mereka serta mendokumentasikannya di dalam bentuk yang dapat digunakan untuk analisa, komunikasi, dan implementasi yang mengikutinya
Material Requirements Planning (MRP)
Metode MRP merupakan metode perencanaan dan pengendalian pesanan dan inventori untuk item-item dependent demand. Item-item tersebut adalah bahan baku (raw materials), subrakitan (subassemblies), rakitan (assemblies), bagian-bagian (parts) yang semuanya disebut manufacturing inventories. (sumber; Skripsi-Herlina, 2005, p19). Menurut National Conference (2008) untuk dapat mengatur suatu tingkat persediaan optimal yang dapat memenuhi kebutuhan akan bahan baku dalam jumlah, mutu dan pada waktu yang tepat dengan jumlah biaya yang rendah maka diperlukan suatu sistem perencanaan yang tepat pula, sistem perencanaan yang tepat itu adalah Material Requirement Planning (MRP).
Perkembangan XP
Sebagai sebuah metodologi untuk mengembangkan peragkat lunak XP tentu memiliki siklus hidup. Siklus hidup pada XP ini terdapat lima fase yaitu :1. Exploration Phase2. Planning Phase3. Iteration to Release Phase4. Productionizing Phase5. Maintenance Phase6. Death PhaseMeskipun para developer mungkin memiliki practices yang berbeda namun secara mendasar XP memiliki 12 practices utama yaitu:1Planning Game7Pair Programming
2Small Releases8Collective Ownership
3Metaphor9Continuous Integration
4Simple Design1040-hour week
5Testing11On-site Customer
6Refactoring12Coding Standard
Pada practice Planning Game sendiri memiliki tiga fase yaitu exploration phase, commitment phase, dan steering phase. Planning game ini adalah pertemuan antara dua pihak, yaitu dari pihak developer dan pihak bisnis, dibahas mulai membuat story oleh on-site customer sampai re-estimate oleh pihak development.
NOPHASEBUSINESSDEVELOPMENT
IExploration phaseWrite story-
-Estimate story
Split story-
IICommitment phaseSort by value-
-Sort by risk
-Sort by velocity
Choose scope-
IIISteering phaseIteration-
-Recovery
New storyRe-estimate
Tabel 1: Fase pada planning game (sebelum modifikasi)Pada fase-fase XP tidak terdapat sebuah fase ataupun bagian dari satu fase yang melakukan dokumentasi formal selama proses pengembangan. Satu-satunya dokumentasi adalah penulisan requirements pada index card yang disebut dengan stories. Stories ini ditulis pada fase exploration, di mana satu function yang akan diimplementasikan akan ditulis dalam satu index card. Selanjutnya pada proses pengembangan apabila satu function pada stories telah berhasil diimplementasikan, index card-nya akan dibuang. Ini bisa menjadi kelemahan XP karena tanpa dokumentasi formal maka proses pengembangan ini akan kembali seperti proses yang tidak terpola dan primitif. Apabila ditarik kepada model CMM (Capability Maturity Model) maka proses yang tanpa dokumentasi formal ini akan masuk ke level paling bawah yaitu lebel initial. Namun jika terdapat dokumentasi formal yang cukup berat, diperkirakan metodologi ini tidak menjadi ringan lagi sehingga tidak masuk dalam kategori agile.ANALISIS PENAMBAHAN FASE REQUIREMENTS MANAGEMENT
Pada bagian ini akan dilakukan penambahan fase pada XP yaitu dengan menyisipkan sebuah fase yang disebut requirements management phase. Fase ini disisipkan tidak sekuensial tapi paralel dengan fase planning. Tujuan penyisipan secara paralel ini adalah mengurangi kemungkinan XP keluar dari lingkup agile. Tiga hal yang dilakukan yaitu:1.Penambahan Requirements ManagementRequirements management akan dijadikan sebuah fase tersendiri namun kronologis pelaksanaannya adalah paralel dengan fase planning. Hal ini dimaksudkan agar penambahan fase ini tidak akan berpengaruh secara signifikan terhadap waktu pengembangan secara keseluruhan. Penambahan anggota tim juga tidak diperlukan untuk melakukan proses requirements management ini.
2.Pendokumentasian sederhana (simple documenting)
Ini merupakan implementasi dari fase requirements management. Pihak development melakukan peringkasan stories (summarize stories) ke dalam dokumen sederhana (simple document) dari pihak bisnis. Teknis pelaksanaannya dilakukan tidak menggunakan komputer tapi ditulis tangan. Ini dimaksudkan agar metodologi ini tetap ringan. Penulisan dengan menggunakan komputer bisa dilakukan setelah proses pengembangan berakhir. Requirements yang ditulis hendaknya mencantumkan identitas dari stories yang didokumentasikan yaitu nomor story pada index card. Ini diperlukan sebagai trace karena requirements yang ditulis pada simple document tidak serinci pada story, namun sudah dirangkum menjadi sebuah feature. Jika requirements yang dirangkum tersebut mengalami perubahan maka pada perubahan itu juga harus ada trace-nya untuk mengetahui asal requirement-nya.
3. Mempertahankan index card yang telah diimplementasi dengan baikPada metode XP, index card akan dibuang apabila story yang terdapat di dalamnya telah berhasil diimplementasikan dengan baik. Namun pada modifikasi ini index card tidak perlu dibuang, karena selain sebagai bahan dokumentasi, index card adalah bukti dari requirements pada simple document. Pada requirements tersebut terdapat satu atribut yang mengarah ke index card, yaitu story asal dari requirements tersebut yang tertulis lebih rinci.
Gambar 2: Fase pada eXtreme Programming setelah modifikasi
Setelah dilakukan modifikasi terdapat beberapa pengaruh pada practice-nya. Dari dua belas practice yang terdapat pada XP, ada empat buah practice yang mempunyai singgungan kuat dengan requirements management yaitu planning game, metaphor, 40-hour week, On-site customer. Dari keempatnya planning game-lah yang paling besar keterkaitannya dengan requirements. Pada bagian ini akan dipaparkan yang terjadi pada keempat practice tersebut setelah dilakukan modifikasi pada XP tersebut.
1. Planning GameBerikut ini adalah tabel setelah dilakukan perubahan pada siklus:
NOPHASEBUSINESSDEVELOPMENT
IExploration phaseWrite story-
-Estimate story
Split story-
-Summarize stories (simple documenting)
IICommitment phaseSort by value-
-Sort by risk
-Sort by velocity
Choose scope-
IIISteering phaseIteration-
-Recovery
New storyRe-estimate
-Summarize stories (update simple document)
Tabel 2: Fase pada planning game (setelah modifikasi)
Sebelum modifikasi, pada exploration phase terdapat tiga kegiatan yaitu write story, estimate story, dan split story. Setelah dilakukan modifikasi satu kegiatan lagi yang dikerjakan oleh pihak development adalah summarize stories into simple document. Pihak bisnis melakukan split story menjadi dua atau lebih story apabila pihak development tidak dapat mengestimasi story, atau story yang ditulis terlalu kompleks. Sebaliknya pihak development melakukan summarize story yaitu story dirangkum menjadi sebuah requirements yang menjadi sebuah feature pada sistem yang akan diimplementasikan. Proses ini dikerjakan langsung pada waktu customer selesai menulis story, tidak perlu menunggu sampai semua stories selesai ditulis.
Demikian juga pada steering phase yang pada awalnya hanya terdiri atas kegiatan-kegiatan iteration, recovery, new story, dan re-estimate, setelah modifikasi ditambah satu lagi yaitu update simple document. Proses ini sebenarnya sama dengan summarize stories pada exploration phase, perbedaannya pada steering phase adalah untuk mengantisipasi adanya new story yang dikerjakan oleh pihak bisnis.
2. MetaphorPractice berikutnya yang bersinggungan dengan requirements adalah metaphor. Metaphor merupakan panduan (guidance) dalam melakukan pengembangan secara keseluruhan. Metaphor di sini memerlukan penjelasan rinci. Requirements yang diperoleh melalui proses summarize stories tersebut berperan sebagai metaphor, sedangkan penjelasan rincinya ada pada story awal. Karena alasan tersebut index card yang story-nya telah berhasil diimplementasikan tidak perlu dibuang. Jika terjadi perubahan pada requirements tersebut maka untuk melacak story awalnya harus melihat ke index card, sehingga requirements pada simple document tersebut menjadi metaphor yang memandu proses pengembangan agar berjalan sesuai keinginan3. 40-hour weekStory yang telah selesai ditulis oleh customer langsung dirangkum ke dalam simple document pada fase requirements management. Sementara fase tersebut berlangsung secara paralel dengan fase planning. Perangkumannya adalah dengan ditulis tangan, tidak melalui komputerisasi. Model dokumennya juga dibuat sesederhana mungkin agar semua pihak dapat mengerti dengan mudah. Dengan proses tersebut di atas maka tidak akan terjadi penambahan waktu secara signifikan.4. On-site CustomerKomunikasi dengan on-site customer tetap dilakukan terus, termasuk dalam melakukan summarize stories. Dokumentasi yang sederhana juga akan dapat dimengerti dengan mudah oleh customer, karena sifatnya hanya merangkum story ke dalam requirements yang akan menjadi feature pada sistem yang dibuat. Untuk menjaga berbagai kemungkinan agar keinginan user cukup representative maka pada saat requirements gathering sebaiknya minimal ada dua customer. Satu orang menulis stories yang bersifat fungsional, yang lainnya menulis stories yang non-fungsional. Stories yang bersifat fungsional adalah stories yang berhubungan dengan core business-nya, sedangkan yang non-fungsional adalah yang berhubungan dengan support dari bisnisnya.PERHITUNGAN KATEGORI AGILEDalam perhitungan batas-batas agile ada 14 unsur yang akan dinilai yaitu 4 practice yang paling bersinggungan yaitu planning game, metaphor, 40 hour week, dan onsite customer. Untuk planning game akan dibagi 3 langsung yaitu exploration phase, commitment phase, dan steering phase. Selain itu terdapat 10 unsur untuk menilai kategori agile yaitu communication, simplicity, feedback, courage, embrace change, number of person, iterative development and design, emergence, adaptation, software first. Penilaian untuk setiap unsur adalah 0-3, di mana semakin kecil berarti pengaruh penambahan tersebut tidak terlalu signifikan dalam mengganggu ke-agil-annya.
Unsur-unsur tersebut pembobotannya akan dibagi lagi dari 1-5. Pembobotan yang tertinggi ada pada fase-fase planning game.BOBOTINDIKATOR
5Planning game : exploration, commitment, and steering phase
4Metaphor, 40 hour week, On-site customer
3Communication, simplicity, feedback, embrace change, number of person
2Adaptation
1Courage, iterative development and design, emergence, software first
Tabel 3: Pembobotan untuk penilaian agile.Penilaian yang dilakukan adalah dengan mengalikan nilai pada setiap unsur dengan masing-masing bobot yang dimilikinya. Kemudian hasil perkalian unsurunsur tersebut dijumlahkan sehingga diperoleh hasilnya.Penerapan XPBeberapa hal yang harus dipertimbangkan sebelum seseorang masuk dalam dunia XP adalah sebagai berikut:1. User harus memahami konteks bisnis yang akan dikembangkan sistemnya, sehingga developer dapat menangkap sistem secara aplikatif dan dapat mengusulkan teknologi apa yang dapat dikembangkan dalam sistem barunya.
2. Akan lebih efektif apabila developer pernah menangani proyek pengembangan sistem yang sejenis sehingga dapat memberikan usulan model sistem baru, di samping alasan bahwa developer telah memiliki template aplikasi sistem tersebut untuk dijadikan prototype sistem baru. Hal ini akan berimplikasi kepada kemudahan dalam konstruksi sistem karena dikembangkan berdasarkan template yang sudah ada.
3. Extreme programming menuntut komunikasi antar developer dan user secara intensif dan komunikasi internal antar developer secara komprehensif, sehingga akan lebih representatif apabila tahap pengembangan sistem dilakukan di lokal yang mendukung proses komunikasi tersebut.
XP adalah suatu bentuk pembangunan perangkat lunak yang berbasis nilai kemudahan, komunikasi, umpan balik, dan keberanian. Bekerja dalam whole team bersama-sama dengan praktek yang mudah. Adapun inti penerapannya adalah:
1. Planning Game
2. Small, frequent releases
3. System metaphors
4. Simple design
5. Testing (unit testing & TDD)
6. Frequent refactoring
7. Pair programming
8. Collective code ownership
9. Continuous integration
10. Sustainable pace
11. Whole team together
12. Coding standards
Keuntungan XP:
Menjalin komunikasi yang baik dengan client.
Meningkatkan komunikasi dan sifat saling menghargai antar developer.Kerugian XP:
Developer harus selalu siap dengan perubahan karena perubahan akan selalu diterima.
Tidak bisa membuat kode yang detail di awal (prinsip simplicity dan juga anjuran untuk melakukan apa yang diperlukan hari itu juga).
Aktifitas Requirement
Requirements ElicitationAdalah proses mengumpulkan dan memahami requirements dari user. Kadang masalah yang muncul berakar dari gap masalah knowledge domain (perbedaan disiplin ilmu yang dimiliki). Customer adalah expert pada domain yang softwarenya ingin dikembangkan (domain specialist), dilain pihak sang pengembang (requirements analyst) adakalanya sama sekali buta terhadap knowledge domain tersebut, meskipun tentu memahami dengan benar bagaimana sebuah software harus dikembangkan. Gap knowledge domain tersebut yang diharapkan bisa diatasi dengan adanya interaksi terus menerus dan berulang (iterasi) antara pengembang dan customer. Proses interaksi tersebut kemudian dimodelkan menjadi beberapa teknik dan metodologi diantaranya adalah interviewing, brainstorming, prototyping, use case, dsb.
Requirements SpecificationSetelah masalah berhasil dipahami, pengembang mendeskripsikannya dalam bentuk dokumen spesifikasi dokumen. Spesifikasi ini berisi tentang fitur dan fungsi yang diinginkan oleh customer, dan sama sekali tidak membahas bagaimana metode pengembangannya. IEEE mengeluarkan standard untuk dokumen spesifikasi requirements yang terkenal dengan nama IEEE Recommended Practice for Software Requirements Specifications [IEEE-830]. Dokumen spesifikasi requirements bisa berisi functional requirements, performance requirements, external interface requirements, design constraints, maupun quality requirements.
Requirements Validation and Verification
Setelah spesifikasi requirements berhasil dibuat, perlu dilakukan dua usaha: Validation (validasi), yaitu proses untuk memastikan bahwa requirements yang benar sudah ditulis. Verification (verifikasi), yaitu proses untuk memastikan bahwa requirements sudah ditulis dengan benar. Proses validasi dan verifikasi ini melibatkan customer (user) sebagai pihak yang menilai dan memberi feedback berhubungan dengan requirements.
Tujuan Requirement:
- Menetapkan dan menjaga kesepakatan dengan customer dan stakeholder lain tentang apa yang harus dilakukan oleh system
- Untuk memberikan pemahaman yang lebih baik kepada pengembang system tentang kebutuhan system
- Menetapkan batasan system
- Untuk menyediakan dasar perencanaan teknis
- Untuk menyediakan dasar perkiraan biaya dan waktu pengembangan system
- Untuk mendefinisikan user interface system
Sering terjadi salah kaprah dalam Requirement Engineering (RE), mereka terlalu menyederhanakan RE, mereka beranggapan bahwa RE dimulai dari bertanya pada stakeholder tentang keinginan mereka (requirement elicitation), mempelajari hasilnya hingga dimengerti (requirement analysis), menulis kebutuhan ke dalam dokumen (requirement specification), dan bertanya pada custumer apakah yang dikerjakan sudah benar (requirement validation). Namun sayangnya, yang dilakukan diatas tersebut belum tentu benar, karena keempat hal tersebut adalah pekerjaan(tasks), bukan urutan yang sequensial, Kesalahpahaman tersebut dapat menjurus kedalam ketidak lengkapan serta ketidak suksesan proyek. Dalam tulisan ini kedepan akan dibahas tentang pengenalan dari semua pekerjaan utama dalam RE.
Kekompakan dalam tim RE harus dipastikan diawal, setiap anggota tim harus bisa saling bekerja sama secara efektif. Komposisi tim pun harus diperhitungkan dari background yang bisa berhubungan dengan stakeholder serta mampu memperhitungkan feasibilitas dari sebuah requirement. Ada beberapa pekerjaan RE yang bisa dilakukan untuk memperoleh RE sesuai yaitu
BUSINESS ANALYSISMenganalisa context dari bisnis yang akan dikembangkan sistemnya. Terdiri atas beberapa proses : Analyze the customer organizations business enterprise, Analyze the competitor organizations, Analyze current and potential/planned marketplace, Analyze critical technologies, Analyze current and intended future user communitie, Analyze the stake holder, dan Develop a business caseVISIONINGBersama stakeholder menghasilkan visi dari sistem baru yang akan dikembangkan. Mulai dari menentukan misi, masalah dalam bisnis dan kesempatan, kebutuhan dari stakeholder, tujuaan serta fungsionalitas selain itu juga batasan-batasannya.
REQUIREMENTS IDENTIFICATIONMengidentifikasikan requirement yang potensial. Prosesnya terdiri atas identify sources of requirement,elicit needs, goals, desires, and requirement, gather potential requirement, invent new requirement transform stakeholder desires, expectation, and needs into informal, textual, potential requirement.REQUIREMENTS REUSEMengunakan ulang semua atau sebagian requirement yang sudah ada. Melibatakan beberapa proses yaitu mengidentifikasikan requiremen yang potensial untuk di reusable, mengevaluasi requirement yang relevan, menyesuaikan requirement agas sesuai dengan kebutuhan, mengunakan requirement yang telah disesuaikan.
REQUIREMENT ANALYSISTim RE menganalisa requirement yang telah diidentifikasi dan requirement yang digunakan kembali. Pekerjaan yang harus dilakukan adalah Study, categorize, decompose and organize , model, quantify, refine, prioritize, justify, and trace each requirement, transform informal tekstual requirement, negotiate the prioritization of requirement, verify, transform potential raw requirement, ensure the requirement well unsterstood.REQUIREMENTS PROTOTYPINGMenciptakan RE Prototypes, meliputi pembuatan satu atau lebih prototype, mengevaluasinya, dan mengunakan prototype tersebut.
REQUIREMENT SPECIFICATIONMembuat dan mempublikasi requirement yang telah dianalisa dan divalidasi dalam bentuk dokumen, langkah-langkahnya meliputi menciptakan dokumen, mendistribusikannya serta memperbaiki jika terdapat feedback terhadap dokumen tersebut.
REQUIREMENT MANAGEMENTMengelola semua kebutuhan, meliputi Record and store the requirement, control acess (CRUD) the requirement, negotiate with stakeholder, report the status, dan trace the requirement.REQUIREMENT VALIDATIONMemvalidasi kebenaran dari requirement yang telah dianalisa bersama dengan stakeholder dan melakukan koreksi yang diperlukan. Meliputi identify a stakeholder to validate the requirement, ensure these stakeholder validate the correctness of the requirement, iterate to fix requirement problem, certify an acceptable requirement.Terdapat tiga pekerjaan yang secara teknik dan logika dipunyai oleh bidang lain, namun sangat kritikal terhadap kesuksesan RE, adalah Scope Management, Requirement Verification , Requirement Configuration Control. RE seharusnya tidak dianggap sebagai fase awal dalam Waterfall development cycle. RE harusnya dilakukan dalam iterative, incremental, concurrent , dan time-box. Iterative dalam arti pekerjaan RE biasanya perlu dilakukan perulangan untuk memperbaiki kekurangan dan membuat peningkatan,incremental Karena dalam pembuatan sistem yang besar sangat sulit membuat requirement yang lengkap dan benar pada permulaan proyek, sehingga baiknya dilakukan dengan metode top-down, dan layer by layer.Concurrent berarti RE dilaksanakan bersamaan dengan disiplin yang lain. Time-boxed berarti penyelesaian RE tetap harus dijadwalkan.METODOLOGI PENELITIAN
Tabel 1.Desain Penelitian
Keterangan :
1. T-1 : Untuk mengetahui jumlah material yang diperlukan dari masing masing komponen yang dibutuhkan PT. Yubi Citra Karyadikara untuk menyelesaikan seluruh pesanan kursi OX 830 sebanyak 950 unit kursi.
2. T-2 : Untuk mengetahui total biaya material yang optimal yang dibutuhkan PT. Yubi Citra Karyadikara untuk menyelesaikan keseluruhan pesanan kursi OX 830.
3. T3 : Untuk mengetahui pengaruh penerapan sistem MRP (Material Requirement Planning) terhadap total persediaan (terutama yang terdiri dari biaya penyimapanari dan pemesanan) pada PT. Yubi Citra Karyadikara.
Jenis penelitian yang akan digunakan dalam penelitian ini adalah deskriptif dan metode penelitiannya adalah studi kasus dan survey yang menganalisis tentang perencanaan bahan baku material dengan menggunakan metode Material Requirement Planning (MRP) serta unit analisisnya adalah PT. Yubi Citra Karyadikara
Profil Perusahaan
PT. Yubi Citra Karyadikara adalah perusanaan industri swasta yang bergerak dalam bidang industri mebel yaitu memproduksi office chairs atau kursi _kursi kantor yang memiliki pabrik berlokasi di jalan peternakan II no.15, Kapuk Jagal jakarta 11720 dan letak kantornya di jalan tanjung duren barat 1 no.31.
Ditinjau dari segi hukum PT. Yubi Citra Karyadikara telah berdiri sejak tahun 1989 dengan no SIUP 7237/09.03/PM/VIII/1991. Perusahaan ini sudah berjalan selama 18 tahun, dengan modal awal adalah sebesar Rp 300.000.000. Perusahaan sebelumnya tidak hanya di bidang industri offrice chairs saja, tetapi memproduksi mebel lainnya seperti lemari, meja meja tetapi karena produk tersebut kurang diminati oleh pelanggan, maka perusahaan hanya menciptakan kursi kursi kantor, karena perusahaan bekerja sama dengan beberapa kantor juga, sehingga sudah memilki pelanggan tetap. Banyak perkembangan dalam perusahaan ini, perusahaan terus menciptakan produk produk baru, sehingga perusahaan memiliki banyak sekali jenis dan model kursi- kursi dengan fungsinya yang berbeda.
PT. Yubi Citra Karyadikara banyak memproduksi kursi-kursi kantor yang mempunyai tipe dan model pilihan yaitu staff chair, secretary chair, executive secretary chair, bar chair, manager chair, executive manager chair, director chair, executive director chair, meeting chair, salon chair dan visitor chair.Master Production Schedule (MPS)
Dalam Master Production Schedule ini menyatakan bahwa adanya pesanan untuk produk kursi OX 830 secara keseluruhan adalah sebanyak 950 unit kursi, untuk memproduksi kursi tersebut memerlukan waktu 10 menit per-unit. Kursi yang sudah diproduksi harus di proses lebih lanjut ke dalam proses finishing yang memerlukan waktu 2 menit Iamanya dan proses finishing ini akan dimulai di menit ke-8 dan selesai pada menit ke-10. Jika perusahaan menerima banyak pesanan maka perusahaan akan menambah waktu lembur. Biasanya dalam sehari perusahaan bisa memproduksi sebanyak 60 - 80 unit, tetapi jika menambah waktu lembur maka dalam sehari perusahaan bisa memproduksi sebanyak 100-120 unit.KESIMPULAN
Secara garis besar penambahan fase requirements management pada eXtreme Programming sangat membantu untuk lebih menstrukturkan metode ini. Requirements Management yang disisipkan terutama difokuskan dalam hal dokumentasi. Pendokumentasian pada eXtreme Programming ini tidak akan mengganggu proses secara keseluruhan karena dilaksanakan secara paralel dengan planning phase.
Hasil pengukuran yang dilaksanakan terhadap penambahan fase requirements management yang paralel dengan planning phase pada siklus hidup eXtreme Programming menunjukkan bahwa metodologi ini tetap pada posisi agile. Pengukuran yang dilakukan dengan menggunakan statistik yaitu dengan menilai indikator-indikator agile-nya yang kemudian diklasifikasikan dengan menggunakan distribusi normal memperoleh empat klasifikasi. Klasifikasi itu adalah A untuk posisi sangat agile, B untuk posisi agile, C untuk posisi cukup agile, dan D untuk posisi tidak agile. Setelah pengukuran, penambahan fase ini menunjukkan berada pada posisi B. Dengan hasil tersebut berarti penambahan fase requirements management tidak menjadikan eXtreme Programming keluar dari metodologi Agile.
Mempunyai RE yang bagus adalah penting karena dampaknya mampu mengurangi biaya proyek, dan diterimanya sistem oleh stakeholder sehingga bisa mengarah kepada keuntungan yang tinggi. Namun juga harus diakui dibutuhkan tenaga dan waktu yang tidak sedikit untuk berinvestasi dalam pembuatan requirement yang benar-benar bagus. Untuk mendapatkan requirement yang bagus, ada banyak pekerjaan/tasks harus dilakukan, untuk itu tim RE tidak hanya bekerja pada awal dari proyek namun bekerja melalui tahap pengembangan sampai tahap delivery untuk memastikan requirement benar-benar sesuai.Dengan dilakukannya penelitian mengenai penerapan metode Material Ruirement Planning dalam perencanaan kebutuhan material kursi OX 830 pada PT. Yubi Citra Karyadikara maka dapat disimpulkan bahwa :1. Dalam memenuhi pesanan pelanggan akan permintaan produkJcursi OX 830 sebanyak 950 unit , maka PT. Yubi Citra Karyadikara memerlukan komponen komponen sebagai berikut, komponen papan dudukan sebanyak 950 unit, papan senderan sebanyak 950 unit, kaki cakar lima sebanyak 950 unit, busa atau foam dudukan sebanyak 950 unit, seat mechanis sebanyak 950 unit, busa atau foam senderan sebanyak 950 unit, kote kote sebanyak 950 unit, roda castor sebanyak 4750 unit, gas lift atau hydraulic sebanyak 950 unit, kain alabama sebanyak 1900 unit, dan list karet sebanyak 1900 unit.
2. Dalam memproduksi seluruh pesanan pelanggan akan permintaan kursi OX 830 sebanyak 950 unit maka setelah diperhitungkan biaya biaya yang akan dikeluarkan oleh perusahaan dibagi menjadi 2 yaitu total biaya material berdasarkan perencanaan kebutuhan material (MRP) yaitu sebesar Rp 298.775.000 dan total biaya material berdasarkan analisis sistem berjalan yaitu s.'-tesar Rp 302.899.994. Jadi dapat disimpulkan bahwa untuk memproduksi pesanan kursi OX 830 sebanyak 950 unit sebaiknya perusahaan menerapkan sistem Material Reqiurement Planning (MRP) karena total biaya material yang dikeluarkan perusahaan lebih minimal sehingga biaya biaya yang dikeluarkan untuk memproduksi oleh perusahaan tidak besar dan memberikan keuntungan bagi perusahaan.SARANPerusahaan perusahaan sekarang sebaiknya menerapkan sistem MRP karena sistem ini sangat berpengaruh terhadap total biaya yang dikeluarkan oleh perusahaan karena dengan sistem MRP pada kebutuhan material didapatkan total biaya material yang dikeluarkan lebih minimal dari pada total biaya berdasarkan analisis sistem berjalan, sehingga hal ini dapat memberikan keuntungan bagi perusahaan jika perusahaan menggunakan sistem MRP ini dalam perencanaan kebutuhan material.
REFERENSI
Abrahamsson, Pekka., Salo, Outi., Ronkainen, Jussi and Juhani Warsta. Agile Software Development Methods: Review and Analysis. VTT Publication 478. Finland
Assauri, Sofjan. (2004).Manajemen Produksi dan Operasi edisi revisi. FEUI, JakartaBeck, Kent., Jeffries, Ron., and Ward Cunningham. (2000). Extreme Programming: Embrace Change.Addison-Wesley.
Dean Leffingwell and Don Widrig. (2000). Managing Software Requirements: A Unified Approach, Addison Wesley
Donald G. Firesmith , Requirement Engineering Tasks , Journal of Object Technology , vol. 5 , no. 8, November-December 2006, pp 21-29
Fagan, Mary Helen. Compiring Traditional and Agile Development Approach: The Case of Extreme Programming.Issues in Information Systems. Volume VI No.2, 2005
Hayes, Steve. An Introduction to Extreme Programming. http://www.khatovartech.com. Khatovar Technology. 2001
Hayes, Steve and Martin Andrews. An Introduction to Agile Methods. http://www. khatovartech.com. Khatovar Technology. 2001.Hongren, Datar, Foster. (2005). Akuntansi Biaya Penekanan Manajerial. PT. Indeks
Kelompok Gramedia, Jakarta
Indrajit, Richardus Eko dan Richardus Djokopranoto.(2003). Manajemen Persediaan.
Grasindo, Jakarta
Leffingwell, Dean., and Don Widrig. (2000). Managing Software Requiremnents: A Unified Approach. Addison-Wesley. BostonNasution, Hakim, Arman. (2003). Perencanaan dan Pengendalian Produksi. Edisi Pertama. Institut Teknologi Sepuluh November. Guna Widya, Surabaya
Pamela Zave. (1997). Classification of Research Efforts in Requirements Engineering, ACM Computing Surveys, 29(4), pp. 315-321Paulk, Mark C.( 2001). Extreme Programming from a CMM Perspective.
Pressman, Roger.(2005). Software Engineering: A Practitioners Approach. 6th Edition. McGraw-Hill.
Romi Satria Wahono and Jingde Cheng. (2002). Extensible Requirements Patterns of Web Application, IEEE International Symposium on Cyber Worlds (CW 2002), Japan
Romi Satria Wahono. (2003). Analyzing Requirements Engineering Problems, IECI Japan Workshop 2003 (IJW-2003), Japan
Sekaran, Uman. (2006). Research Methods for Business (Metodologi Penelitian Untuk
Bisnis). Edisi 4. Salemba Empat, JakartaThe Standish Group, Charting the Seas of Information Technology Chaos, The Standish Group International, 1994
Zulfikarizan. (2005). Manajemen Persediaan. Universitas Muhmmadiyah. Malang.
Sumayang, Lalu. (2003). Dasar-dasar Manajemen Produksi dan Operasi. Salemba Empat, Jakartahttp://digilib.stiekesatuan.ac.id/gdl.pho?mod=browse&op=read&id=jbptstiek-http://distians.wordpress.com/)
http://www.geocities.com/visiweb)
http://library.usu.ac.id/download/fe/akuntansi-erlina3.pdf)
MAKALAH SISTEM INFORMASI MANAJEMENREKAYASA PERANGKAT LUNAK
Dosen Pengampu: Yuniadi Mayowan, S.SOS.MAB
Anggota Kelompok 4:
Agung Dwi W.(1801437565)
Audia Inayah (1801437691)
David Frans S(1801437634)
R. Anandika(1801437716)
Sholeh Hidayat(1801437691)
KEMENTRIAN PENDIDIKAN DAN KEBUDAYAAN
UNIVERSITAS BRAWIJAYA
FAKULTAS ILMU ADMINISTRASI
Jalan. MT. Haryono 163, Malang 65145, Jawa Timur, Indonesia
Telp. +62-341-553737, 568914, 558226 Fax. +62-341-558227
E-mail: [email protected] Website: http://fia.ub.ac.idREKAYASA PERANGKAT LUNAK
(SOFTWARE ENGINEERING)I. PENDAHULUAN
Rekayasa perangkat lunak telah berkembang sejak pertama kali ddiciptakan pada tahun 1940-an hingga kini. Focus utama pengembangannya adalah untuk mengembangkan praktek dan teknologi untuk meningkatkan produktivitas para praktisi pengembang perangkat luank dan kualitas aplikasi yang dapat digunakan oleh pemakai.
I.1 Sejarah Software Engineering
Istilah software engineering digunakan pertama kali pada akhir 1950-an dan awal 1960-an. Saat itu, masih terdapat perdebatan tajam mengenai aspek engineering dari pengembangan perangkat lunak. Pada tahun 1968 dan 1969, komite sains NATO mensponsori dua konferensi tentang rekayasa perangkat lunak, yang memberikan dampak kuat terhadap pengembangan rekayasa perangkat lunak. Banyak yang menganggap dua konferensi inilah yang menandai awal resmi profesi rekayasa perangkat lunak.
Pada tahun 1960-an hingga 1980-an, banyak masalah yang ditemukan para praktisi pengembangan perangkat lunak. Banyak project yang gagal, hingga masa ini disebut sebagai krisis perangkat lunak. Kasus kegagalan pengembangan perangkat lunak terjadi mulai dari project yang melebihi anggaran, hingga kasusu yang mengakibatkan kerusakan fisik dan kematian. Salah satu kasus yang terkenal antara lain meledaknya roket Ariane akibat kegagalan perangkat lunak. Selama bertahun-tahun, para peneliti memfokuskan usahanay untuk menemukan teknik jitu untuk memecahkan masalah krisi perangkat lunak. Berbagai teknik, metode, alat, proses diciptakan dan diklaim sebagai senjata pamungkas untuk memecahkan kasus ini. Mulai dari pemrograman terstruktur, pemrograman berorientasi objek, pernagkat pembantu pengembangan perangkat lunak (CASE tools), berbagai standar, UML hingga metode formal diagung-agungkan sebagai senjaat pamungkas untuk menghasilkan software yang benar, sesuai anggaran dan tepat waktu. Pada tahun 1987, Fred Brooks menulis artikel No Silver Bullet, yang berproposisi bahwa tidak ada satu teknologi atau praktek yang sanggup mencapai 10 kali lipat perbaikan dalam produktivitas pengembanan perngkat lunak dalam tempo 10 tahun.
Sebagian berpendapat, no silver bullet berarti profesi rekayasa perangkat lunak dianggap telah gagal. Namun sebagian yang lain justru beranggapan, hal ini menandakan bahwa bidang profesi rekayasa perangkat lunak telah cukup matang, karena dalam bidang profesi lainnya pun, tidak ada teknik pamungkas yang dapat digunakan dalam berbagai kondisi.
I.2 Pengertian Dasar
Istilah Reakayasa Perangkat Lunak (RPL) secara umum disepakati sebagai terjemahan dari istilah Software engineering. Istilah Software Engineering mulai dipopulerkan pada tahun 1968 pada software engineering Conference yang diselenggarakan oleh NATO. Sebagian orang mengartikan RPL hanya sebatas pada bagaimana membuat program komputer. Padahal ada perbedaan yang mendasar antara perangkat lunak (software) dan program komputer.
Perangkat lunak adalah seluruh perintah yang digunakan untuk memproses informasi. Perangkat lunak dapat berupa program atau prosedur. Program adalah kumpulan perintah yang dimengerti oleh komputer sedangkan prosedur adalah perintah yang dibutuhkan oleh pengguna dalam memproses informasi (OBrien, 1999).
Pengertian RPL sendiri adalah suatu disiplin ilmu yang membahas semua aspek produksi perangkat lunak, mulai dari tahap awal yaitu analisa kebutuhan pengguna, menentukan spesifikasi dari kebutuhan pengguna, disain, pengkodean, pengujian sampai pemeliharaan sistem setelah digunakan. Dari pengertian ini jelaslah bahwa RPL tidak hanya berhubungan dengan cara pembuatan program komputer. Pernyataan semua aspek produksi pada pengertian di atas, mempunyai arti semnua hal yang berhubungan dengan proses produksi seperti manajemen proyek, penentuan personil, anggaran biaya, metode, jadwal, kualitas sampai dengan pelatihan pengguna merupakan bagian dari RPL.
II. TUJUAN REKAYASA PERANGKAT LUNAK
Secara umunmm tujuan RPL tidak berbeda dengan bidang rekayasa yang lain. Hal ini dapat kita lihat pada Gambar di bawah ini.
Gambar 1. Tujuan RPL
Dari Gambar di atas dapat diartikan bahwa bidang rekayasa akan selalu berusaha menghasilkan output yang kinerjanya tinggi, biaya rendah dan waktu penyelesaian yang tepat. Secara leboih khusus kita dapat menyatakan tujuan RPL adalah:
a. memperoleh biaya produksi perangkat lunak yang rendah
b. menghasilkan pereangkat lunak yang kinerjanya tinggi, andal dan tepat waktu
c. menghasilkan perangkat lunak yang dapat bekerja pada berbagai jenis platform
d. menghasilkan perangkat lunak yang biaya perawatannya rendah
III. RUANG LINGKUP
Sesuai dengan definisi yang telah disampaikan sebelumnya, maka ruang lingkup RPL dapat digambarkan sebagai berikut:
Gambar 2. Ruang lingkup RPL (Abran et.al., 2004).
software Requirements berhubungan dengan spesifikasi kebutuhan dan persyaratan perangkat lunak
software desain mencakup proses penampilan arsitektur, komponen, antar muka, dan karakteristik lain dari perangkat lunak
software construction berhubungan dengan detail pengembangan perangkat lunak, termasuk algoritma, pengkodean, pengujian dan pencarian kesalahan
software testing meliputi pengujian pada keseluruhan perilaku perangkat lunak
software maintenance mencakup upaya-upaya perawatan ketika perangkat lunak telah dioperasikan
software configuration management berhubungan dengan usaha perubahan konfigurasi perangkat lunak untuk memenuhi kebutuhan tertentu
software engineering management berkaitan dengan pengelolaan dan pengukuran RPL, termasuk perencanaan proyek perangkat lunak
software engineering tools and methods mencakup kajian teoritis tentang alat bantu dan metode RPL
software engineering process berhubungan dengan definisi, implementasi pengukuran, pengelolaan, perubahan dan perbaikan proses RPL
software quality menitik beratkan pada kualitas dan daur hidup perangkat lunak
IV. REKAYASA PERANGKAT LUNAK DAN DISIPLIN ILMU LAIN
Cakupan ruang lingkup yang cukup luas, membuat RPL sangat terkait dengan disiplin dengan bidang ilmu lain. tidak saja sub bidang dalam disiplin ilmu komputer namun dengan beberapa disiplin ilmu lain diluar ilmu komputer.
Hubungan keterkaitan RPL dengan ilmu lain dapat dilihat pada gambar dibawah ini
Gambar 3. Keterkaitan RPL dengan bidang ilmu lain. bidang ilmu manajemen meliputi akuntansi, finansial, pemasaran, manajemen operasi, ekonomi, analisis kuantitatif, manajemen sumber daya manusia, kebijakan, dan strategi bisnis
bidang ilmu matematika meliputi aljabar linier, kalkulus, peluang, statistik, analisis numerik, dan matematika diskrit
bidang ilmu manajemen proyek meliputi semua hal yang berkaitan dengan proyek, seperti ruang lingkup proyek, anggaran, tenaga kerja, kualitas, manajemen resiko dan keandalan, perbaikan kualitas, dan metode-metode kuantitatif
bidang ilmu ergonomika menyangkut hubungan ( interaksi) antar manusia dengan komponen-komponen lain dalam sistem komputer
bidang ilmu rekayasa sistem meliputi teori sistem, analisis biaya-keuntungan, pemodelan, simulasi, proses, dan operasi bisnis
V. PERKEMBANGAN REKAYASA PERANGKAT LUNAK
Meskipun baru dicetuskan pada tahun 1968, namun RPL telah memiliki sejarah yang cukup yang panjang. Dari sisi disiplin ilmu, RPL masih reklatif muda dan akan terus berkembang.
Arah perkembangan yang saat ini sedang dikembangkan antara lain meliputi :
TahunKejadian
1940anKomputer pertama yang membolehkan pengguna menulis kode program langsung
1950anGenerasi awal interpreter dan bahasa macro Generasi pertama compiler
1960anGenerasi kedua compiler Komputer mainframe mulai dikomersialkan Pengembangan perangkat lunak pesanan
Konsep Software Engineering mulai digunakan
1970anPerangkat pengembang perangkat lunak Perangkat minicomputer komersial
1980anPerangkat Komputer Personal (PC) komersial Peningkatan permintaan perangkat lunak
1990anPemrograman berorientasi obyek (OOP) Agile Process dan Extreme Programming Peningkatan drastis kapasitas memori Peningkatan penggunaan internet
2000anPlatform interpreter modern (Java, .Net, PHP, dll) Outsourcing
VI. METODE REKAYASA PERANGKAT LUNAK
Pada rekayasa perangkat lunak, banyak model yang telah dikembangkan untuk membantu proses pengembangan perangkat lunak. Model-model ini pada umumnya mengacu pada model proses pengembangan sistem yang disebut System Development Life Cycle (SDLC) seperti terlihat pada Gambar berikut ini.
Gambar 4. System Development Life Cycle (SDLC).
Kebutuhan terhadap definisi masalah yang jelas. Input utama dari setiap model pengembangan perangkat lunak adalah pendefinisian masalah yang jelas. Semakin jelas akan semakin baik karena akan memudahkan dalam penyelesaian masalah. Oleh karena itu pemahaman masalah seperti dijelaskan pada Bab 1, merupakan bagian penting dari model pengembangan perangkat lunak.
Tahapan-tahapan pengembangan yang teratur. Meskipun model-model pengembangan perangkat lunak memiliki pola yang berbeda-beda, biasanya model-model tersebut mengikuti pola umum analysis design coding testing - maintenance
Stakeholder berperan sangat penting dalam keseluruhan tahapan pengembangan. Stakeholder dalam rekayasa perangkat lunak dapat berupa pengguna, pemilik, pengembang, pemrogram dan orang-orang yang terlibat dalam rekayasa perangkat lunak tersebut. Dokumentasi merupakan bagian penting dari pengembangan perangkat lunak. Masing-masing tahapan dalam model biasanya menghasilkan sejumlah tulisan, diagram, gambar atau bentuk-bentuk lain yang harus didokumentasi dan merupakan bagian tak terpisahkan dari perangkat lunak yang dihasilkan. Keluaran dari proses pengembangan perangkat lunak harus bernilai ekonomis. Nilai dari sebuah perangkat lunak sebenarnya agak susah di-rupiah-kan. Namun efek dari penggunaan perangkat lunak yang telah dikembangkan haruslah memberi nilai tambah bagi organisasi. Hal ini dapat berupa penurunan biaya operasi, efisiensi penggunaan sumberdaya, peningkatan keuntungan organisasi, peningkatan image organisasi dan lain-lain.VII. TAHAPAN REKAYASA PERANGKAT LUNAK
Meskipun dalam pendekatan berbeda-beda, namun model-model pendekatan memiliki kesamaan, yaitu menggunaka pola tahapan analysis design coding(construction) testing maintenance.
1. Analisis sistem adalah sebuah teknik pemecahan masalah yang menguraikan sebuah sistem menjadi komponen-komponennya dengan tujuan mempelajari seberapa bagus komponen-komponen tersebut bekerja dan berinteraksi untuk meraih tujuan mereka.Analisis mungkin adalah bagian terpenting dari proses rekayasa perangkat lunak. Karena semua proses lanjutan akan sangat bergantung pada baik tidaknya hasil analisis. Ada satu bagian penting yang biasanya dilakukan dalam tahapan analisis yaitu pemodelan proses bisnis.2. Model proses adalah model yang memfokuskan pada seluruh proses di dalam sistem yang mentransformasikan data menjadi informasi (Harris, 2003). Model proses juga menunjukkan aliran data yang masuk dan keluar pada suatu proses. Biasanya model ini digambarkan dalam bentuk Diagram Arus Data (Data Flow Diagram / DFD). DFD meyajikan gambaran apa yang manusia, proses dan prosedur lakukan untuk mentransformasi data menjadi informasi.3. Disain perangkat lunak adalah tugas, tahapan atau aktivitas yang difokuskan pada spesifikasi detil dari solusi berbasis computer (Whitten et al, 2004).Disain perangkat lunak sering juga disebut sebagai physical design. Jika tahapan analisis sistem menekankan pada masalah bisnis (business rule), maka sebaliknya disain perangkat lunak fokus pada sisi teknis dan implementasi sebuah perangkat lunak (Whitten et al, 2004).Output utama dari tahapan disain perangkat lunak adalah spesifikasi disain. Spesifikasi ini meliputi spesifikasi disain umum yang akan disampaikan kepada stakeholder sistem dan spesifikasi disain rinci yang akan digunakan pada tahap implementasi. Spesifikasi disain umum hanya berisi gambaran umum agar stakeholder sistem mengerti akan seperti apa perangkat lunak yang akan dibangun. Biasanya diagram USD tentang perangkat lunak yang baru merupakan point penting dibagian ini. Spesifikasi disain rinci atau kadang disebut disain arsitektur rinci perangkat lunak diperlukan untuk merancang sistem sehingga memiliki konstruksi yang baik, proses pengolahan data yang tepat dan akurat, bernilai, memiliki aspek user friendly dan memiliki dasar-dasar untuk pengembangan selanjutnya.
Desain arsitektur ini terdiri dari desain database, desain proses, desain user interface yang mencakup desain input, output form dan report, desain hardware, software dan jaringan. Desain proses merupakan kelanjutan dari pemodelan proses yang dilakukan pada tahapan analisis.4. Konstruksi adalah tahapan menerjemahkan hasil disain logis dan fisik ke dalam kode-kode program komputer.
5. Pengujian sistem melibatkan semua kelompok pengguna yang telah direncanakan pada tahap sebelumnya. Pengujian tingkat penerimaan terhadap perangkat lunak akan berakhir ketika dirasa semua kelompok pengguna menyatakan bisa menerima perangkat lunak tersebut berdasarkan kriteria-kriteria yang telah ditetapkan.6. Perawatan dan Konfigurasi. Ketika sebuah perangkat lunak telah dianggap layak untuk dijalankan, maka tahapan baru menjadi muncul yaitu perawatan perangkat lunak. Ada beberapa tipe perawatan yang biasa dikenal dalam dunia perangkat lunak seperti terlihat pada diagram di Gambar di bawah ini :
Gambar 5. Tipe-tipe perawatan.
Tipe perawatan corrective dilakukan jika terjadi kesalahan atau biasa dikenal sebagai bugs. Perawatan bisa dilakukan dengan memperbaiki kode program, menambah bagian yang dirasa perlu atau malah menghilangkan bagian-bagian tertentu.
Tipe perawatan routine biasa juga disebut preventive maintenance dilakukan secara rutin untuk melihat kinerja perangkat lunak ada atau tidak ada kesalahan.
Tipe perawatan sistem upgrade dilakukan jika ada perubahan dari komponen-komponen yang terlibat dalam perangkat lunak tersebut. Sebagai contoh perubahan platform sistem operasi dari versi lama ke versi baru menyebabkan perangkat lunak harus diupgrade.REFERENSIIEEE Xplore - Software Engineering, IEEE Transactions on.
http://ieeexplore.ieee.org/xpl/RecentIssue.jsp?punumber=32. Diakses pada tanggal 25 Mei 2009 jam 23.05 WIB
Mulyanto, Aunur R. 2008. Rekayasa Perangkat Lunak Jilid 1 untuk SMK. Direktorat Pembinaan Sekolah Menengah Kejuruan, Direktorat Jenderal Manajemen Pendidikan Dasar dan Menengah, Departemen Pendidikan Nasional : Jakarta
Pengertian Software Engineering.
http://www.total.or.id/info.php?kk=Software%20Engineering. Diakses pada tanggal 25 Mei 2009 jam 22.50 WIB
Wikipedia, the free encyclopedia - Software engineering .
http://en.wikipedia.org/wiki/Software_engineering. Diakses pada tanggal 25 Mei 2009 jam 23.00 WIBUNIVERSITAS
BINA NUSANTARA
HYPERLINK "http://images.google.co.id/imgres?imgurl=http://mediarilis.files.wordpress.com/2009/03/logo_binus.jpg&imgrefurl=http://mediarilis.wordpress.com/2009/03/18/jadwal-dan-agenda-kamis-19-maret-2007/&usg=__SfmEMfoaMRj5ecVC5MvgQ1oYSFI=&h=203&w=372&sz=9&hl=id&start=1&um=1&tbnid=bipXnQnU-qHLwM:&tbnh=67&tbnw=122&prev=/images%3Fq%3Dlogo%2Bbinus%26hl%3Did%26sa%3DN%26um%3D1" INCLUDEPICTURE "http://tbn3.google.com/images?q=tbn:bipXnQnU-qHLwM:http://mediarilis.files.wordpress.com/2009/03/logo_binus.jpg" \* MERGEFORMATINET
Agung Dwi W.(1801437565)
Audia Inayah (1801437691)
David Frans S(1801437634)
R. Anandika(1801437716)
Sholeh Hidayat(1801437691)
REQUIREMENTS MANAGEMENT PADA EXTREME PROGRAMMING
Nama: Hendrik
Nim: 1000874374
Jurusan: Sistem Informasi
Dosen: Agus Putranto
Alamat blog: http://ndrik.blog.binusian.org/
Universitas Bina Nusantara
2009
Exploration
Planning
Iteration to Release
Productionizing
Maintenance
Death
Requirements Management
![[TA2] PascaSidang Rev3](https://static.cupdf.com/doc/110x72/55cf8c945503462b138de537/ta2-pascasidang-rev3.jpg)
![[TA2] PascaSidang Rev4](https://static.cupdf.com/doc/110x72/55cf8c945503462b138de548/ta2-pascasidang-rev4.jpg)
