KONSEP DAN PRINSIP ANALISIS

KONSEP DAN PRINSIP ANALISIS

1. ANALISIS KEBUTUHAN PERANGKAT LUNAK
       Analisis kebutuhan adalah sebuah tugas rekayasa perangkat lunak yang menjembatani jurang antara alokasi. Perangkat lunak tingkat sistem dan perancangan perangkat lunak. Analisis persyaratan memungkinkan perekayasa system menentukan fungsi dan kinerja perangkat lunak, menunjukkan interface perangkat lunak dengan elemen – elemen system yang lain, dan membangun batasan yang harus dipenuhi oleh perangkat lunak. Analaisi persyaratan perangkat lunak mengijinkan perekayasa perangkat lunak (dlm peran ini sering disebut analisis) utk memperhalus alokasi perangkat lunak dan membangun model – model data fungsional, dan domain tingkah laku yang akan di proses oleh perangkat lunak. Analisis persyaratan memberikan model – model yang akan diterjemahkan ke dalam data, arsitektur, interface, dan desain procedural kepada perancang perangkat lunak. Akhirnya, spesifikasi persyaratan memberikan cara kepada pengembang dan pelanggan untuk menilai kualitas perangkat lunak yang telah di bangun.

Analisis persyaratan perangkat lunak dapat dibagi menjadi 5 area kerja :
• Pengenalan masalah
• Evaluasi dan Sintesis
• Pemodelan
• Spesifikasi
• Kajian



Pada awalnya, analisis mempelajari spesifikasi system (bila ada) dan rencana proyek peangkat lunak. Penting untuk memahami perangkat lunak dalam suatu konteks system dan mengkaji ruang lingkup perangkat lunak yang telah digunakan untuk memunculkan estimasi perencanaan. Selanjutnya, adalah membangun komunikasi untuk analisis untuk menjamin pengenalan masalah. Tujuan analisis adalah mengenali elemen masalah dasar seperti dirasakan oleh pemakai / pelanggan.
Sintesis evaluasi dan pemecahan masalah adalah area mayor selanjutnya dari kerja analisis. Analisis harus membatasi semua objek data yang dapat di observasi secara eksternal, mengevaluasi aliran dan muatan informasi; mendefinisikan dan menguraikan semua fungsi perangkat lunak; memahami tingkah laku perangkat lunak dalam konteks kejadian yang mempengaruhi system; membangun karakteristik interface system; dan menemukan batasan desain tambahan. Masing – masing dari tugas tersebut berfungsi untuk menjelaskan masalah sehingga pendekatan atau penyelesaian keseluruhan dapat disintesis.
Sebagai contoh, pemasok besar suku cadang kendaraan bermotor membutuhkan system control inventaris. Analisis mendapatkan bahwa masalah yang berhubungan dengan system manual yang ada meliputi :
Ketidakmampuan untuk dengan cepat memperoleh status suatu komponen
Dua atau tiga hari berkali – kali memperbaharui suatu file kartu
Pemesanan kembali secara bertingkat kepada penjual yang sama karena tidak ada cara untuk menghubungkan para penjual dengan komponen dan sebagainya.
Sekali masalah di identifikasi, maka analisis menentukan informasi apa yang akan dihasilkan oleh system baru dan data apa yang akan diberikan kepada system. ¹Misalnya pelanggan menginginkan laporan harian yang menunjukkan suku cadang yang diambil dari inventaris dari beberapa jumlah suku cadang yang sama yang masih ada. Pelanggan menunjukkan bahwa petugas inventaris akan mencatat nomor identifikasi dari masing – masing suku cadang pada saat suku cadang tersebut keluar dari area inventarisasi.
Setelah mengevaluasi masalah yang ada dan juga informasi yang diperlukan (input – output), analis akan mulai mensintesa satu penyelesaian atau lebih. Untuk memulainya, data, fungsi – fungsi pemrosesan, dan tingkah laku system, di definisikan secara detail. Sekali informasi itu dibangun, maka arsitektur dasar pengimplementasian dipertimbangkan. Pendekatan klien / server tampaknya akan sesuai, tetapi apakah kebutuhan pemakai / pelanggan untuk hubungan itu dibenarkan? Proses evaluasi dan sintesis berlangsung sampai analisis dan pelanggan yakin bahwa perangkat lunak dapat ditentukan untuk langkah – langkah pengembangan selanjutnya.
Melalui sintesis analisis dan evaluasi, focus utama analisis adalah pada “apa” (what), bukan “bagaimana” (how). Data apakah yang diproduksi dan konsumsi, batasan apakah yang dipakai?
Selama aktifitas sintesis evaluasi dan solusi, analis menciptakan model – model system untuk lebih memahami aliran data dan control, operasi behavioral dan pemrosesan fungsional, serta muatan informasi. Model tersebut berfungsi sebagai pondasi bagi desain perangkat lunak dan sebagai dasar untuk membuat spesifikasi perangkat lunak.

2. TEKNIK KOMUNIKASI
Analisis persyaratan perangkat lunak selalu dimulai dengan komunikasi antara dua bagian atau lebih. Seorang pelanggan memiliki masalah yang dapat di pertanggung jawabkan melalui pemecahan berbasis komputer. Pengembang merespon permintaan bantuan (help) dari pelanggan. Komunikasi sudah dimulai. Tetapi sperti ditulis sebelumnya, jalan dari komunikasi ke pemahaman kadang – kadang penuh dengan lobang.

2.1  MENGAWALI PROSES
Teknis analisis paling umum digunakan utnuk menjembatani jurang komunikasi antara pelanggan dan pengembang dan sekaligus untuk memulai proses komunikasi, adalah dengan melakukan pertemuan pendahuluan atau wawancara. Pertemuan pertama antara perekayasa perangkat lunak (analis) dengan pelanggan dapat disamakan dengan kakunya kencan pertama antara dua remaja. Keduanya tidak tahu apa yang akan mereka katakana atau tanyakan; keduanya merasa mengkhawatirkan yang mereka katakana akan disalah artikan; keduanya berpikir kemana arah mereka (keduanya memiliki pengharapan yang sangat berbeda); keduanya ingin pertemuan itu segera berakhir; tetapi pada saat yang sama, keduanya ingin berhasil.
Akan tetapi, komunikasi harus diawali. Gause dan Weinberg [GAU89] menyarankan agar analis memulainya dengan mengajukan pertanyaan – pertanyaan bebas konteks, yaitu serangkaian pertanyaan yang akan mengarah kepada pemahaman yang mendasar atas masalah, orang yang menginginkan penyelesaian, sifat penyelesaian yang dinginkan, dan efektivitas pertemuan pertama itu sendiri. Rangkaian pertama dari pernyataan bebas konteks berfokus pada pelanggan, tujuan keseluruhan, dan keuntungan. Sebagai contoh, analis dapat bertanya :
¤ Siapa dibalik permintaan untuk pekerjaan ini ?
¤ Siapa yang akan menggunakan pemecahan ini ?
¤ Apa keuntungan ekonomi dari pemecahan yang berhasil ?
¤ Apakah ada sumber lain untuk pemecahan yang anda inginkan ?
Rangkaian pertanyaan berikutnya memungkinkan analis mendapatkan pemahaman yang lebih baik mengenai masalah dan pelanggan, untuk menyatakan persepsinya terhadap suatu pemecahan :
Bagaimana anda akan menandai output yang baik yang akan didapatkan oleh pemecahan yang berhasil ?
Masalah apakah yang akan diselesaikan oleh pemecahan ini ?
Dapatkah anda memperlihatkan kepada saya (atau menjelaskan) lingkungan dimana pemecahan tersebut akan digunakan ?
Adakah masalah atau batasan kinerja yang khusus yang akan mempengaruhi cara pemecahan tersebut didekati?
Rangkaian pertanyaan yang terakhir berfokus pada efektivitas pertemuan. Gause dan Weinberg [GAU89] membuat pertanyaan – pertanyaan mengusulkan daftar berikut ini :
Apakah anda adalah orang yang tepat untuk menjawab pertanyaan – pertanyaan ini ? apakah jawaban anda bersifat resmi ?
Apakah pertanyaan saya ini bersifat relevan dengan masalah yang anda hadapi ?
Apakah anda mengajukan terlalu banyak pertanyaan ?
Apakah ada orang lain yang dapat memberikan informasi tambahan ?
Apakah ada hal lain yang harus saya tanyakan kepada anda ?
Pertanyaan – pertanyaan tersebut (dan lainnya) akan membantu anda “memecahkan es” dan mengawali komunikasi yang perlu untuk berhasilnya analisis. Tetapi format pertemuan Tanya jawab bukan merupakan pendekatan yang sudah berhasil. Pada dasarnya, sesi Q&A seharusnya digunakan hanya pada pertemuan pertama dan kemudian diganti dengan format pertemuan yang mengkombinasikan elemen – elemen pemecahan masalah, negoisasi, dan spesifikasi. Pendekatan terhadap pertemuan – pertemuan tipe tersebut akan dibahas pada bagian selanjutnya.
2.2 Teknik Spesifikasi Aplikasi yang Terfasilitasi

Pelanggan dan pengembang perangkat lunak, tanpa mereka sadari, sering memiliki mind set “kita dan mereka”. Kedua konstituen tersebut bukannya bekerja sebagai tim, tetapi malah membatasi “daerah kekuasaan” mereka sendiri dan berkomunikasi melalui serangkaian memo, surat resmi, dokumen, dan sesi tanya jawab. Sejarah menunjukkan bahwa pendekatan tersebut tidak bekerja dengan baik. Kesalahpahaman, hilangnya informasi penting, dan hubungan kerja yang berhasil tidak pernah dapat terjalin.
Karena masalah itulah maka sejumlah peneliti independen mengembangkan pendekatan time – oriented untuk mengumpulkan kebutuhan yang di aplikasikan selama masa awal analisis dan spesifikasi. Disebut facilitated application specification techniques (FAST), pendekatan itu mendorong munculnya tim gabungan antara pelanggan dan pengembang yang bekerja yang bekerja bersama untuk mengidentifikasi masalah, mengusulkan elemen pemecahan, menegoisasi pendekatan yang berbeda, dan mengkhususkan rangkaian persyaratan pemecahan awal [ZAH90]. Sekarang FAST digunakan terutama oleh masyarakat system informasi, walau teknik tersebut juga menawarkan potensi untuk komunikasi yang berkembang pada semua jenis aplikasi.
Banyak pendekatan yang berbeda terhadap FAST telah diusulkan. Masing – masing pendekatan menggunakan scenario yang sangat berbeda, tetapi semuanya menerapkan beberapa variasi tuntunan dasar berikut ini :
Peretemuan dilakukan di sisi netral dan dihadiri baik oleh pengembang maupun pelanggan.
Aturan main untuk persiapan dan partisipasi dibuat.
Sebuah agenda yang cukup formal diusulkan untuk mencakupkan semua hal penting tetapi tidak terlalu formal agar dapat mengalirkan gagasan bebas.
Seorang fasilisator (dapat dari pelanggan, pengembang, atau orang luar) untuk mengontrol pertemuan.
Sebuah “mekanisme definisi” (dapat merupakan sebuah lembar kerja, diagram flip, stiker dinding, atau papan tembok) digunakan.
Tujuannya adalah untuk mengidentifikasi masalah, mengusulkan elemen pemecahan, menegoisasikan pendekatan yang berbeda, dan mengkhususkan rangkaian persyaratan pemecahan awal dalam suatu atmofsir yang kondusif terhadap pencapaian tujuan.
Untuk memahami secara lebih baik terhadap aliran kejadian pada saat mereka bertemu dalam pertemuan FAST tertentu, disajikan scenario pendek yang menjadi garis besar bagi urutan kejadian yang mengarrah kepada pertemuan, yang terjadi selama pertemuan, dan mengikuti perttemuan tersebut.
Pertemuan awal antara pengembang dan pelanggan (subbab 11.2.1) terjadi dan pertanyaan dan jawaban dasar akan membantu untuk membangun ruang lingkup masalah dan persepsi keseluruhan dari suatu pemecahan. Sebelum pertemuan awal tersebut, pengembang dan pelanggan menulis “permintaan produk” sebanyak satu atau dua halaman. Tempat pertemuan, waktu dan tanggal untuk FAST ditentukan, fasilitator dipilih. Perwakilan baik dari organisasi pengembang maupun organisasi pelanggan di undang untuk dating. Permintaan produk di edarkan ke semua undangan sebelum tanggal pertemuan.
Sambil mengkaji permintaan sebelum dimulainya pertemuan tersebut, masing – masing peserta FAST diminta untuk membuat daftar objek yang merupakan bagian dari lingkungan yang mengelilingi system, objek lain yang dihasilkan oleh system, dan objek yang dihasilkan oleh system untuk melakukan fungsi – fungsinya. Sebagai tambahan, masing – masing peserta diminta membuat daftar yang lain mengenai pelayanan (proses dan fungsi) yang memanipulasi atau berinteraksi dengan objek. Akhirnya, daftar mengenai batasan (misalnya, biaya ukuran, berat) dan criteria kerja (misalnya, kecepatan, akurasi) juga dikembangkan. Para peserta diberitahu bahwa daftar tersebut tidak perlu sempurna, tetapi diharapkan dapat mencerminkan persepsi masing – masing orang terhadap system yang ada.
Sebagai contoh, diasumsikan bahwa tim FAST yang bekerja untuk perusahaan produk konsumen telah memberikan deskripsi produk sebagai berikut :
Penelitian kami menunjukkan bahwa pasar untuk system keamanan rumah berkembang pada laju 40 persen per tahun. Kami ignin memasuki pasar tersebut dengan membangun sebuah system keamanan rumah berbasis mikroprosesor yang akan melindungi dari dan atau mengenali berbagai situasi yang tidak di inginkan, sperti pemasukan illegal, api, banjir, dan lain sebagainya. Produk tersebut secara tentative disebut Safe Home dan akan menggunakan sensor sesuai untuk mendeteksi setiap keadaan, dapat deprogram oleh pemilik rumah, dan akan secara otomatis menelpon sebuah agen pemonitor jika berhasil mendeteksi suatu keadaan.
Pada dasarnya, lebih banyak lagi informasi yang akan diberikan pada tahap ini. Akan tetapi, sekalipun ada informasi tambahan, ambiguitas akan tetap ada, penghilangan tetap saja aka nada, dan kesalahan (error) tetap akan terjadi. Untuk saat ini, deskripsi produk tersebut cukup memadai.
Tim FAST terdiri dari perwakilan dari bagian pemasaran, rekayasa perangkat lunak, rekayasa perangkat keras, dan pemanufakturan. Seorang fasilitator dari luar akan digunakan.
Masing – masing person pada tim FAST (Gambar 11.2) mengembangkan daftar tersebut. Objek yang digambarkan untuk Safe Home dapat meliputi detector asap, sensor pintu dan jendela, detector gerakan, sebuah alarm, sebuah kejadian (sebuah sensor yang telah diaktivasi), sebuah panel control, display, nomor telepon, panggilan telepon, dan sebagainya. Daftar layanan dapat meliputi setting alarm, pemonitoran sensor, pemencetan nomor telepon, pemograman control panel, dan pembacaan display (perhatikan bahwa layanan bertindak menurut objek). Dengan cara yang sama, masing – masing undangan FAST akan mengembangkan daftar batasan (misalnya, system harus memiliki biaya pembuatan kurang dari $200, harus user friendly, dan harus berinterface langsung dengan sambungan telepon standar) serta criteria kinerja (misalnya, sebuah kejadian sensor harus dikenali dalam waktu satu detik; skema prioritas kejadian harus di implementasikan).
Pada saat pertemuan dimulai, topic pertama diskusi adalah kebutuhan akan justifikasi untuk produk baru – setiap orang harus setuju bahwa pengembangan produk (atau akuisisi) dijustifikasi. Sekali persetujuan dibuat, masing – masing partisipan menyajikan daftar mereka yang akan digunakan untuk diskusi. Daftar tersebut dapat ditempel di dinding ruangan dengan menggunakan sembarang kertas yang besar, atau dengan kertas lainnya, atau ditulis pada papan. Idealnya, masing – masing entri daftar harus dapat dimanipulasi secara terpisah sehingga daftar tersebut dapat digabungkan, dihapus, dan dapat ditambah. Pada tahap ini kritik dan debat tidak diperbolehkan.
Setelah daftar individual disajikan dalam satu area topic, maka kelompok kemudian membuat daftar gabungan. Daftar gabungan akan mengurangu entri yang acak dan menambahkan gagasan baru yang muncul selama presentasi, tetapi tidak akan menghapus apapun. Setelah daftar gabungan untuk semua topic dari semua area dibuat, diskusi – dipimpin oleh fasilitator. Daftar gabungan tersebut kemudian dipersingkat, diperpanjang, atau dirumuskan lagi hingga dapat secara tepat mencerminkan produk / system yang akan dikembangkan. Sasaran akan mengembangkan daftar konsesus pada setiap area topic (objek, pelayanan, batasan, dan kinerja). Daftar tersebut kemudian dikesampingkan pada kegiatan selanjutnya.
Begitu daftar consensus telah dilengkapi, tim tersebut terbagi ke dalam subtim yang lebih kecil; masing – masing bekerja untuk mengembangkan sebuah spesifikasi-mini untuk satu entri atau lebih pada setiap daftar. Spesifikasi-mini adalah suatu tambahan dari kata atau frase yang dimasukkan pada daftar. Misalnya, Spesifikasi-mini untuk control panel objek Safe Home dapat berupa :
§ Dipasang di dinding,
§ Ukurannya kira – kira 9×5 inci,
§ Berisi 12 papan ketik dan kunci khusus,
§ Berisi display LCD dari bentuk yang diperlihatkan pada sket [tidak ada disini],
§ Semua interaksi pelanggan terjadi melalui kunci yang digunakan untuk mengaktifkan dan mematikan system,
§ Perangkat lunak untuk memberikan panduan interaksi, echo, dll yang dihubungkan ke semua sensor.
Masing – masing subtim kemudian menyajikan spesifikasi mininya ke semua undangan FAST untuk di diskusikan. Penambahan, penghapusan, dan penambahan lebih jauh lagi dilakukan. Dalam banyak kasus, pengembangan spesifikasi mini akan membuka objek, pelayanan, batasan, atau persyaratan kinerja baru yang akan ditambahkan ke daftar orisinil. Selama diskusi, tim dapat memunculkan suatu masalah yang tidak dapat dipecahkan selama pertemuan. Daftar masalah dikumpulkan agar gagasan – gagasan tersebut dapat di tindak lanjuti kemudian.
Setelah spesifikasi mini ini dilengkapi, masing – masing undangan FAST membuat daftar kinerja validasi untuk produk / system dan menyajikan adfatar tersebut kepada tim. Daftar konsensus mengenai criteria validasi kemudian dibuat. Akhirnya, satu partisipan atau lebih (atau orang luar) diberi tugas untuk menulis draft spesifikasi lengkap dengan menggunakan semua input dari pertemuan FAST.
FAST bukanlah obat bagi masalah yang dihadapi dalam pengumpulan awal berbagai persyaratan, tetapi pendekatan tim memberikan keuntungan dari banyak sudut pandang, diskusi sesaat, dan penyaringan, serta merupakan langkah maju yang konkrit ke arah pengembangan spesifikasi.
2.3  Penyebaran Fungsi Kualitas
Penyebaran fungsi kualitas / Quality Function Deployment (QFD) adalah teknik manajemen kualitas yang menerjemahkan kebutuhan pelanggan ke dalam persyaratan teknis bagi perangkat lunak. Pertama kali dikembangkan di Jepang dan pertama kali digunakan di Kobe Shipyar of Mitsubishi Heavy Industries, Ltd. Pada awal tahun 1970-an, QFD “berkonsentrasi pada pemaksimalan kepuasan pelanggan” [ZUL92]. Untuk melakukannya, QFD menekankan pemahaman mengenai apa yang berharga bagi pelanggan dan kemudian menyebarkannya ke seluruh proses rekayasa.
QFD mengidentifikasi tiga tipe persyaratan [ZUL92] :
Persyaratan Normal. Sasaran dan tujuan dinyatakan bagi sebuah produk atau system selama pertemuan dengan pelanggan. Bila persyaratan ini ada, maka pelanggan akan menjadi puas. Contoh persyaratan normal adalah tipe tampilan grafis yang diminta, fungsi system spesifik, dan tingkat kinerja yang didefinisikan.
Persyaratan yang diharapkan. Persyaratan ini implicit terhadap produk atau system dan sangat fundamental sehingga pelanggan tidak menyatakannya secara eksplisit. Ketidakhadirannya akan menyebabkan ketidakpuasan yang mendalam. Contoh persyaratan yang diharapkan adalah mudahnya interaksi manusia dengan mesin, reabilitas dan kebenaran operasional keseluruhan, dan mudahnya instalasi perangkat lunak.
Exciting requirement. Persyaratan ini sangat diharapkan oleh pelanggan dan terbukti sangat memuaskan bila ada. Misalnya, perangkat lunak pengolah kata diharapkan dengan fitur standar. Produk yang disampaikan berisi sejumlah kemampuan layout halaman yang sangat menyenangkan dan tidak terduga.
Dalam kenyataan, QFD melingkupi seluruh proses rekayasa [AKA90]. Tetapi banyak konsep QFD dapat diaplikasikan ke dalam masalah komunikasi pelanggan yang dihadapi oleh perekayasa perangkat lunak selama tahap awal analisis persyaratan. Kami menyajikan sebuah kajian hanya dari konsep – konsep ini (disesuaikan untuk perangkat lunak computer) pada paragraph selanjutnya.
Dalam pertemuan dengan pelanggan, penyebaran fungsi digunakan untuk menentukan nilai dari masing – masing fungsi yang dibutuhkan bagi system. Penyebaran informasi mengidentifikasi baik objek data maupun event yang harus diambil dan dihasilkan oleh system. Keduanya diikatkan pada fungsi. Terakhir penyebaran tugas menguji tingkah laku system atau produk dalam konteks lingkungannya. Analisis nilai dilakukan untuk menentukan prioritas relative dari persyaratan yang ditentukan selama masing – masing dari tiga penyebaran tersebut.
QFD menggunakan wawancara dan observasi pelanggan, survai, dan pengujian data historis (misalnya, pelaporan masalah) sebagai data kasar bagi aktivitas pengumpulan persyaratan. Data – data itu kemudian diterjemahkan ke dalam table persyaratan – disebut consumer’s voice table – yang dikaji dengan pelanggan. Berbagai diagram, metrics, dan metode evaluasi kemudian digunakan untuk menyarikan persyaratan yang diharapkan dan untuk mendapatkan kebutuhan yang sangad diharapkan.

3. PRINSIP – PRINSIP ANALISIS
Lebih dari dua decade terakhir, para peneliti mengidentifikasi masalah – masalah analisis dan penyebab – penyebabnya, serta mengembangkan berbagai notasi pemodelan dan serangkaian penelitian yang sesuai untuk menanggulanginya. Masing – masing metode analisis memiliki titik pandang yang unik. Tetapi semua metode analisis dihubungkan oleh serangkaian prinsip operasional :
Dominan informasi dari suatu masalah harus direpresentasikan dan dipahami.
Fungsi – fungsi yang akan dilakukan oleh perangkat lunak harus di definisikan.
Tingkah laku perangkat lunak (sebagai suatu urutan kejadian eksternal) harus diwakilkan.
Model – model yang menggambarkan informasi, fungsi, dan tingkah laku harus dipecah – pecah dalam suatu cara yang membongkar suatu detail dalam bentuk lapisan (atau hirarki).
Proses analisis harus bergerak dari informasi dasar ke detail implementasi.
Sebagai tambahan untuk prinsip analisis operasional tersebut, Davis [DAV95a] mengusulkan serangkaian5 prinsip panduan untuk “rekayasa persyaratan”:
Mengembangkan prototype yang memungkinkan seorang pemakai memahami bagaimana interaksi manusia dengan mesin terjadi. Karena persepsi mengenai kualitas prangkat lunak sering di dasarkan pada persepsi “friendliness” interface, maka prototyping (dan terasi yang dihasilkan) sangatlah dianjurkan.
Merekam asal dan alas an untuk setiap persyaratan. Hal ini merupakan langkah pertama dalam membangun kemampuan penelusuran kembali ke pelanggan.
Menggunakan pandangan persyaratan bertingkat. Pembangunan data, fungsional, dan model tingkah laku member perekayasa perangkat lunak tiga pandangan berbeda. Hal ini mengurangi kemungkinan bahwa inkonsistensi akan diketahui.
Memprioritaskan persyaratan. Batas waktu yang tegas dapat menghalangi implementasi setiap persyaratan perangkat lunak. Bila model proses inkremental (Bab2) diaplikasikan, maka persyaratan yang disampaikan dalam inkremental pertama harus di identifikasi.
Berusaha mengurangi ambiguitas. Karena sebagian besar persyaratan di gambarkan dalam bahasa natural, kemungkinan untuk terjadinya ambiguitas selalu ada. Penggunaan kajian teknis formal merupakan satu – satunya cara untuk mengurangi ambiguitas tersebut.
Perekayasa perangkat lunak yang mempercayai prinsip tersebut akan dapat lebih mengembangkan spesifikasi perangkat lunak yang kemudian akan menjadi dasar yang kuat bagi desain.

4. PROTOTYPING PERANGKAT LUNAK
Analisis harus dilakukan tanpa mengabaikan pardigma rekayasa perangkat lunak yang di aplikasikan; tetapi bentuk yang di ambil oleh analisis akan bermacam – macam. Dalam situasi yang lain, dilakukan pengumpulan persyaratan (melalui FAST, QFD, atau teknik “cuci otak” yang lain [JOR89], pengaplikasian prinsip analisis, dan penyusunan model perangkat lunak yang akan di bangun yang disebut prototype, untuk penilaian pelanggan dan pengembang.

4.1 Pemilihan Pendekatan Prototyping
Paradigma protyping dapat terbatas atau tidak terbatas. Pendekatan terbatas sering disebut throwaway prototyping. Dengan menggunakan pendekatan tsb, prototype melulu sebagai sebuah demonstrasi kasar dari persyaratan. Pendekatan tidak terbatas, yang disebut juga evolutionary prototyping, menggunakan prototype sebagai bagian pertama dari aktivitas analisis yang akan diteruskan kedalam desain dan kontruksi. Prototipe perangkat lunak merupakan evolusi pertama dari system yang diselesaikan.
Secara umum, sembarang aplikasi yang menciptakan tampilan visual yang dinamis, berinteraksi erat dengan pemakai manusia, atau membutuhkan algoritma atau pemrosesan kombinatorial yang harus dikembangkan dalam sebuah gaya evolusioner, adalah calon untuk prototyping

4.2 Metode dan peranti prototyping
Supaya prototyping perangkat lunak efektif, maka harus dikembangkan suatu prototype dengan cepat sehingga pelanggan dapat menilai hasil dan perubahan yang di rekomendasi. Untuk melakukan prototyping secara cepat, ada tiga kelas metode dan peranti generic: teknik generasi keempat, komponen perangkat lunak reusable, spesifikasi formal, dan lingkungan prototyping.
Teknik Generasi Keempat (4GT). Teknik generasi keempat meliputi suatu array yang luas dari query database dan bahasa pelaporan, program dan generator aplikasi, serta bahasa nonprocedural. Karena 4GT memungkinkan perekayasa perangkat lunak memunculkan kode yang dapat dieksekusi dengan cepat, maka 4GT ideal untuk prototyping yang cepat.
Komponen Perangkat Lunak Reusable. Pendektan lain ke rapid prototyping adalah dengan memasang, bukan membangun, prototype dengan menggunakan serangkaian komponen perangkat lunak yang ada.Pada setiap kasus, komponen perangkat lunak harus dirancang dengan cara terntentu sehingga memungkinkannya untuk dipakai kembali tanpa harus mempunyai pengetahuan yang mendetail mengenai kerja internalnya. Perlu di catat bahwa sebuah produk perangkat lunak yabg ada dapat digunakan sebagai sebuah prototype bagi produk kompetitif yang “baru dan telah dikembangkan”. Dengan cara tertentu, hal tsb merupakan suatu bentuk dari reusabilitas untuk prototyping perangkat lunak.
Lingkungan Prototyping dan Spesifikasi Formal. Selama dua decade terakhir, sejumlah bahasa spesifikasi formal dan peranti telah dikembangkan sebagai pengganti bagi teknik spesifikasi bahasa natural. Sekarang pengembang bahasa formal itu berada dalam proses pengembangan lingkungan interaktif yang (1) memungkinkan seorang analisis untuk secara interaktif menciptakan spesifikasi system atau perangkat lunak yang berdasarkan pada bahasa, (2) memanggil peranti otomatis yang menerjemahkan spesifikasi berdasarkan bahasa kedalam kode yang dapat di eksekusi, dan (3) memungkinkan pelanggan untuk menggunakan kode prototype yang dapat di eksekusi untuk menyaring persyaratan – persyaratan formal.




Sumber :
https://indrahimessi.wordpress.com/2010/12/21/konsep-dan-prinsip-analisis-rpl/

PENGENALAN REKAYASA PERANGKAT LUNAK

PENGENALAN REKAYASA PERANGKAT LUNAK

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. 

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.

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 (O’Brien, 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.

Referensi

http://studyrelaxx.blogspot.co.id/

1. Konsep Dasar Rekayasa Perangkat Lunak

1. Apa itu perangkat lunak?

Perangkat lunak merupakan program komputer yang berfungsi menghubungkan antara pengguna dan komputer yang digunakan. dapat dibilang perangkat lunak merupakan sebagai media penerjemah perintah yang diberikan oleh pengguna kepada komputer untuk selanjutnya diproses melalui perangkat keras komputer tersebut.Perangkat lunak umumnya digunakan untuk mengontrol perangkat keras yang biasa disebut sebagai device driver, melakukan proses penghitungan, berinteraksi dengan perangkat lunak yang lebih mendasar lainnya, seperti sistem operasi dan bahasa pemrograman.

Secara umum ada tiga jenis perangkat lunak yang diketahui hingga saat ini yaitu sistem operasi yang merupakan sebuah penghubung antara pengguna dari komputer dengan perangkat keras komputer. Kedua yaitu perangkat lunak bahasa pemrograman seperti java. Dan yang ketiga yaitu perangkat lunak aplikasi yang merupakan penrangkat yang digunakan untuk membantu dan memudahkan pekerjaan seseorang misalnya saja Microsoft Excel, Word, dan Power Point

2. Apa itu Rekayasa Perangkat Lunak?

Rekayasa atau teknik merupakan penerapan ilmu dan teknologi untuk menyelesaikan permasalahan manusia. Hal ni diselesaikan lewat pengetahuan, matematika, dan pengalaman praktis yang diterapkan untuk mendesain objek atau proses yang berguna. Para praktisi teknik professional disebut perekayasa.

            

Rekayasa perangkat lunak atau Software engineering dalam bahasa inggris merupakan bidang ilmu yang mempelajari tentang segala aspek perangkat lunak, seperti  cara-cara pengembangan, pemeliharaan , pembuatan, serta manajemen kualitas perangkat lunak.

     

Rekayasa perangkat lunak jugamerupakan disiplin rekayasa dengan perangkat lunak yang dikembangkan. Biasanya proses melibatkan penemuan pada keinginan klien, menyusunnya didalam daftar kebutuhan, merangcang arsitektur yang mampu mendukung semua kebutuhan, perancangan, pengodean, pengujian, dan pengintegrasian bagian yang terpisah, menguju keseluruhan, penyebaran, dan pemeliharaan perangkat lunak.  

3. Apa perbedaan Rekayasa Perangkat Lunak dengan Ilmu Komputer?

Perbedaan antara rekayasa perangkat lunak dengan ilmu koputer sudah terlihat dari Bahasa Inggrisnya rekayasa perangkat lunak dalam Bahasa Inggris disebut sebagai software engineering , sedangkan ilmu komputer dalam bahasa inggris disebut science.  Dari segi ilmu yang dipelajari rekayasa perangkat lunak merupakan bidang ilmu yang mempelajari tentang perangkat lunak, sedangkan ilmu komputer mempelajari tentang komputasi, perangkat keras, serta beragam topic yang berkaitan dengan komputer.serta ilmu komputer lebih menekankan pada pemrograman komputer sedangkan rekayasa perangkat lunak tidak. Selain itu rekayasa perangkat lunak lebih mengedepankan prakteknya, sedangkan ilmu komputer lebih mengedepankan teori.

4. Apa perbedaan rekayasa perangkat lunak dengan  rekayasa sistem?

            

Perbedaan antara rekayasa perangkat lunak dengan rekayasa sistem adalah apabila rekayasa sistem itu merupakan sebuah kumpulan komponen, konsep, serta alat bantu untuk merancang dan menginstalasi sebuah sistem perangkat lunak, sedangkan rekayasa perangkat lunak itu merupakan ilmu yang mempelajari tentang segala aspek perangkat lunak, seperti  cara-cara pengembangan, pemeliharaan , pembuatan, serta manajemen kualitas perangkat lunak. Jadi dapat disimpulkan bahwa rekayasa perangkat lunak merupakan bagian dari rekayasa sistem karena RPL ilmu yang mempelajari tentang pembuatan perangkat lunak sedangkan rekayasa sistem merupakan kumpulan komponen, konsep, serta alat bantu untuk merancang dan menginstalasi perangkat lunak.

  

5. Apa yang dimaksud dengan proses perangkat lunak?

            

Proses perangkat lunak merupakan proses bagaimana sebuah perangkat lunak itu dapat terbentuk yang dilakukan oleh perekayasa perangkat lunak, proses proses tersebut diantaranya adalah :

A. Proses spesifikasi perangkat lunak. Pada proses ini fungsi,kemampuan operasi perangkat lunak yang akan dibuat harus diketahui terlebih dahulu.

B.Proses pengembangan perangkat lunak. Setelah diketahui fungsi  serta kemampuan perangkat lunak yang akan dibuat selanjutnya perangkat lunak yang telah memenuhi spesifikasi diproduksi.

C. Proses validasi perangkat lunak. Pada proses validasi ini perangkat lunak yang telah diproduksi akan divalidasi sebagai bukti perangkat lunak yang diproduksi berguna sesuai kebutuhan yang diperlukan.

D. Evolusi perangkat lunak. Dengan berkembangnya jaman perangkat lunak yang sudah diproduksipun haruslah berevolusi agar tetap dapat berguna untuk memenuhi kebutuhan pelanggan.  

6. Apakah model  proses perangkat lunak?

            

Model proses perangkat lunak merupakan cara untuk memproses sebuah perangkat lunak dari nol menjadi sebuah perangkat lunak yang siap untuk digunakan. Berikut merupakan beberapa contoh model proses perangkat lunak yang biasa digunakan

A. Waterfall Model atau Model Air Terjun

Model air terjun ini merupakan model klasik yang bersifat sistematis dalam membuat suatu perangkat lunak dan juga paling sering digunakan. 

Pada fase analisis fungsi,kemampuan operasi perangkat lunak yang akan dibuat harus diketahui terlebih dahulu. Kemudian apabila analisi telah selesai dilakukan maka didesainlah perangkat lunak yang akan dibuat. Setelah desain selesai lalu desain tersebut diterjemahkan kedalam kode-kode dengan bahasa pemrograman yang diinginkan, misalnya saja C++. Setelah kode selesai dibuat diadakanlah proses pengetesan terhadap perangkat lunak yang baru dibuat agar diketahui apakah perangkat yang dibuat bisa berjalan dengan benar atau tidak.

2. Model Spiral

Model spiral ini dikembangkan oleh Boehm pada tahun 1988 berdasarkan pada pengalamannya dengan berbagai perbaikan atas model air terjun yang diaplikasikan pada proyek pemerintah, khususnya perangkat lunak yang besar. Model ini dititikberatkan pada pembuatan prototype dan manajemen resiko yang sangat fleksibel jika dibandingkan dengan model air terjun. Kebanyakan aplikasi komprehensif dari model ini ada pada pengembangan TRW-Software Productivity System yang dijabarkan oleh Boehm. Konsep spiral dan focus manajemen risiko telah memperolah pengakuan di industry rekayasa perangkat lunak dan manajemen proyek pada tahun-tahun terakhir.

      

Keuntungan apabila menggunakan model spiral diantaranya :

A. Jangkauan atas pilihan mengakomodasi fitur yang baik untuk proses model perangkat lunak yang sudah ada.

B. Fokus awalnya ada pada pilihan yang melibatkan penggunaan ulang perangkat lunak yang ada. Pilihan ini mendukung karena identifikasi awa; dengan evaluasi dari alternative-alternatif adalah  kunci di setiap siklus spiral.

C. Model spiral juga menyediakan mekanisme untuk tujuan kualtias dan perangkat lunak gabungan kepengembangan produk perangkat lunak.

D. Model spiral mempunyai focus untuk mengeliminasi kesalahn

E. Model spiral menyediakan pendekatan terpisah untuk pengembangan dan pemasangan perangkat lunak.

F. Model spiral menyediakan kerangka kerja aktif untuk pengembangan sistem perangkat keras dan perangkat lunak yagn terintegrasi.

      

Sedangkan kerugian apabila menggunakan model spiral diantaranya :

A. Kebanyakan perangkat lunak yang menggunakan model spiral menitikberatkan pada control, titik periksa, yang merupakan keunggulan dari model air terjun.

B. Karena model spiral ini bersifat fleksibel serta dinamis maka langkah spiral ini harus diteliti lebih lanjut untuk mendapatkan konsistensi, penjajakan, dan control yang diinginkan. Penelitian dan control sangat penting , khususnya untuk area analisis resiko dan manajemen.

7. Berapa biaya Rekayasa Perangkat Lunak?

            

Biaya untuk rekayasa perangkat lunak bervariasi tergantung pada jenis sistem yang akan dibuat ,atribut perangkat serta kinerja dan kehandalan perangkat yang akan dibuat, contohnya saja sistem yang berskala internasional tentunya memerlukan biaya yang lebih mahal apabila dibandingkan dengan sistem yang berskala nasional. Tabel dibawah ini menjelaskan perkiraan pengeluaran rekayasa perangkat lunak

   

Akurasi Manajemen Proyek (dari PMBOK edisi 3, PMI, 2004)		Akurasi pengembangan perangkat lunak(dari rapid development, McConnell, 1996)
Konseptual	30% kebawah sampai 50% keatas	75% kebawah hingga 300% keatas	Konsep Produk Awal
Persiapan	20% kebawah hingga 30% keatas	50% kebawah hingga 100% keatas	Definisi produk yang disetujui
Kepastian	15% kebawah hingga 20% keatas	33% kebawah hingga 50% keatas	Spesifikasi Kebutuhan
Kontrol	10% kebawah hingga 15% keatas	20% kebawah hingga 25% keatas	Spesifikasi rancangan proyek

8. Apa saja metode-metode RPL?

            

Metode-metode dalam rekayasa perangkat lunak merupakan cara yang dilakukan untuk mengembangkan perangkat lunak yang meliputi deskripsi model sistem, aturan, rekomendasi, panduan proses, dan bimbingan. Deskripsi model sistem merupakan model sistem yang akan digunakan contohnya model waterfall. Aturan merupakan batasan yang diberikan kepada model sistem yang telah ditentukan, misalnya setiap entitas pada model sistem diharuskan memiliki nama entitas yang berbeda antara satu entitas dengan entitas lainnya. Rekomendasi berupa saran yang diberikan agar dapat membentuk perancangan yang baik dan sesuai fungsinya. Panduan proses merupakan aktifitas yang bisa diikuti untuk mengembangkan model sistem. Proses bimbingan yaitu serangkaian kegiatan yang akan diikutin untuk mengembangkan model sistem.

  

9. Apa yang dimaksud dengan CASE(Computer Aided Software Engineering)?

            

Yang dimaksud dengan CASE(Computer Aided Software Engineering) adalah serangkaian aplikasi dan metode untuk perangkat lunak yang otomatis dapat memberikan dukungan untuk kegiatan proses perangkat lunak. Ada dua jenis CASE yaitu upper-CASE yaitu alat untuk mendukung kegiatan proses awal persyaratan dan lower-CASE yaitu alat yang mendukung kegiatan yang selanjutnya seperti pemrograman, pengujian , debugging.

10. Apakah atribut perangkat lunak yang baik?

Atribut perangkat lunak yang baik diantaranya :

A. Maintainability yaitu perangkat lunak harus bisa di pelihara demi memenuhi kebutuhan pelanggan yang semakin lama menginginkan kemudahan.

B. Dependability, yaitu perangkat lunak harus dapat diandalkan dan dipercaya dan tidak mengecewakan penggunanya.

C. Acceptability, yaitu perangkat lunak yang sudah diproduksi harus diterima sepenuhnya oleh pengguna yang memesannya. Ini berarti perangkat harus dapat dapat digunakan dengan mudah oleh pengguna.

D. Usability , perangkat lunak yang harus dapat digunakan sesuai dengan fungsi awal yang telah ditentukan oleh penggunanya.

E. Efisien, yaitu perangkat lunak haruslah efisien baik dalam penggungannya maupun sumber daya yang digunakan.

11. Apa tantangan kunci yang dihadapi Rekayasa Perangkat Lunak?

Tantangan kunci yang dihadapi rekayasa perangkat lunak diantaranya :

A. Tantangan pengiriman, yaitu tantangan untuk mempercepat waktu pengiriman perangkat lunak tanpa mengurangi kualitas sistemnya.

B. Tantangan pemeliharaan, yaitu tantangan dalam melakukan pemeliharaan dan peng-updatean perangkat lunak agar biaya yang digunakan dapat di minimalisir sesedikit mungkin.   

C. Tantangan heterogenitas , yaitu tantangan dalam pengembangan untuk membangun perangkat lunak yang dapat diandalkan dan flexible untuk menghadapi heterogenitas yang ada.

D. Adanya killer application yang bisa lebih dikostumisasi, interaktif, dinamis, dan penuh gaya

E. User power an authority, dimana pengguna bisnis dan pengguna individu adalah pihak yang lebih kuat, berpengalaman dan selektif.

F. Adanya market share dimana pesaing menjadi lebih agresif, dan inovatif.

Referensi

http://okaampas.blogspot.co.id/

2. Tanggung Jawab Profesional dan Etika

        Secara umum para profesional yang bergerak dalam bidang apapun memiliki kode etik dan tanggungjawab dalam menjalankan aktivitas atau pekerjaannya masing-masing. Setiap bidang tentu saja memiliki keunikan sesuai dengan karakteristik pekerjaannya. Hal ini juga berlaku pula dalam dunia teknologi informasi khususnya dalam dunia komputasi, rekayasa perangkat lunak maupun sistem informasi. Seorang Profesional komputasi pada prinsipnya memiliki kewajiban etis bagi klien, atasan, profesional lainnya, dan masyarakat dalam memenuhi tanggung jawab profesiona. Kewajiban-kewajiban tersebut dituangkan dalam kode etik, yang dapat digunakan untuk membuat keputusan tentang masalah etika dalam dunia komputasi atau teknologi informasi.

       Profesional berasal dari kata PROFESI yaitu suatu yang melekat pada seseorang yang memberikan jasa atau keterampilan yang dimilikinya bagi orang lain, maka profesional merupakan sebutan pelakunya. Dalam hal kaitannya dengan Profesional komputasi termasuk didalamnya desainer hardware, software engineer, database administrator, analis sistem, dan ilmuwan komputer

       Kode etik adalah sistem norma, nilai dan aturan profesional tertulis yang secara tegas menyatakan apa yangbenar dan baik dan apa yang tidak benar dan tidak baik bagi profesional.Tujuan kode etik agar profesional memberikan jasa sebaik-baiknya kepada pemakai atau kliennya.Adanya kode etik akan melindungi perbuatan yang tidak profesional.Kode etik disusun oleh organisasi profesi sehingga masing-masing profesi memiliki kode etik tersendiri.Ketaatan tenaga profesional terhadap kode etik merupakan ketaatan naluriah yang telah bersatu dengan pikiran, jiwa dan perilaku tenaga profesional. 

Referensi

http://slideplayer.info/user/6404548/

3. Siklus Hidup Perangkat Lunak (SWDLC/Software Development Life Cycle)

SDLC (Systems Development Life Cycle, Siklus Hidup Pengembangan Sistem) atau Systems Life Cycle (Siklus Hidup Sistem), dalam rekayasa sistem dan rekayasa perangkat lunak, adalah proses pembuatan dan pengubahan sistem serta model dan metodologi yang digunakan untuk mengembangkan sistem-sistem tersebut. Konsep ini umumnya merujuk pada sistem komputer atau informasi. SDLC juga merupakan pola yang diambil untuk mengembangkan sistem perangkat lunak, yang terdiri dari tahap-tahap: rencana(planning),analisis (analysis), desain (design), implementasi (implementation), uji coba (testing) dan pengelolaan (maintenance).[1] Dalam rekayasa perangkat lunak angsyat Ä, konsep SDLC mendasari berbagai jenis metodologi pengembangan perangkat lunak. Metodologi-metodologi ini membentuk suatu kerangka kerja untuk perencanaan dan pengendalian pembuatan sistem informasi, yaitu proses pengembangan perangkat lunak. Terdapat 3 jenis metode siklus hidup sistem yang paling banyak digunakan, yakni: siklus hidup sistem tradisional(traditional system life cycle), siklus hidup menggunakan prototyping (life cycle using prototyping), dan siklus hidup sistem orientasi objek (object-oriented system life cycle).
Adapun kegunaan utama dari SDLC adalah mengakomodasi beberapa kebutuhan. Kebutuhan-kebutuhan itu biasanya berasal dari kebutuhan pengguna akhir dan juga pengadaan perbaikan sejumlah masalah yang terkait dengan pengembangan perangkat lunak. Kesemua itu dirangkum pada proses SDLC yang dapat berupa penambahan fitur baru baik itu secara modular maupun dengan proses instalasi baru. Dari proses SDLC juga berapa lama umur sebuah perangkat lunak dapat diperkirakan untuk dipergunakan yang dapat diukur atau disesuaikan dengan kebijakan dukungan dari pengembang perangkat lunak terkait.

Sejarah SDLC

Siklus hidup sistem (SLC) adalah metodologi yang digunakan untuk menggambarkan proses untuk membangun sistem informasi , dimaksudkan untuk mengembangkan sistem informasi dalam cara yang sangat disengaja, terstruktur dan teratur, mengulangi setiap tahap siklus hidup . Pengembangan sistem siklus hidup, menurut Elliott & Strachan & Radford (2004), “berasal pada tahun 1960, untuk mengembangkan skala besar fungsional sistem bisnis di zaman skala besar konglomerat bisnis . Sistem informasi kegiatan berkisar berat pengolahan data dan angka-angka rutinitas “.
Beberapa kerangka kerja pengembangan sistem telah sebagian didasarkan pada SDLC, seperti analisis sistem terstruktur dan metode desain (SSADM) diproduksi untuk pemerintah Inggris Kantor Pemerintah Commerce pada 1980-an. Sejak saat itu, menurut Elliott (2004), “pendekatan siklus kehidupan tradisional untuk pengembangan sistem telah semakin digantikan

dengan alternatif pendekatan dan kerangka kerja, yang berusaha mengatasi beberapa kekurangan yang melekat pada SDLC tradisional”.
SDLC adalah proses yang digunakan oleh analis sistem untuk mengembangkan sistem informasi , termasuk persyaratan, validasi kepemilikan (stakeholder), pelatihan, dan pengguna. Setiap SDLC harus menghasilkan sistem berkualitas tinggi yang memenuhi atau melebihi harapan pelanggan, mencapai selesai dalam waktu dan perkiraan biaya, bekerja secara efektif dan efisien di saat ini dan direncanakan Teknologi Informasi infrastruktur , dan murah untuk mempertahankan dan biaya-efektif untuk meningkatkan. sistem komputer yang kompleks dan sering (terutama dengan munculnya baru-baru arsitektur berorientasi layanan ) link beberapa sistem tradisional berpotensi disediakan oleh vendor perangkat lunak yang berbeda. Untuk mengelola tingkat kompleksitas, sejumlah model SDLC atau metodologi telah diciptakan, seperti ” air terjun “;” spiral “;” Agile pengembangan perangkat lunak “;” prototipe cepat “;” incremental “; dan” sinkronisasi dan menstabilkan “.
Model SDLC dapat dijelaskan sepanjang spektrum gesit untuk iteratif untuk berurut. metodologi Agile , seperti XP dan scrum , fokus pada proses ringan yang memungkinkan untuk perubahan yang cepat di sepanjang siklus pengembangan. Iteratif metodologi, seperti kesatuan proses rasional dan dinamis pengembangan sistem metode , fokus pada lingkup proyek terbatas dan memperluas atau memperbaiki produk oleh beberapa iterasi. Sequential atau besar-desain-up-depan (BDUF) model, seperti Air Terjun , fokus pada perencanaan lengkap dan benar untuk membimbing proyek-proyek besar dan risiko untuk hasil yang sukses dan dapat diprediks. Model-model lain, seperti Pembangunan Anamorphic , cenderung fokus pada bentuk pembangunan yang dipandu oleh ruang lingkup proyek dan iterasi pengembangan fitur adaptif.
Dalam manajemen proyek proyek dapat didefinisikan baik dengan siklus hidup proyek (PLC) dan SDLC, selama kegiatan yang sedikit berbeda terjadi. Menurut Taylor (2004) “siklus hidup proyek mencakup semua kegiatan proyek , sedangkan siklus hidup pengembangan sistem berfokus pada produk menyadari persyaratan “.

Tahapan SDLC

SDLC terdiri dari beberapa tahapan-tahapan berdasarkan analisa kebutuhan yang ada . Dimulai dari analisa kebutuhan perangkat lunak akan dibuat terlebih dahulu desain dari kebutuhan tersebut untuk mempermudah dalam pengerjaannya. Kemudian segala kebutuhan tersebut di implementasikan dengan dua tahap yaitu tahap analisa dan tahap evaluasi (User Acceptance Test). Setelah melakukan implementasi, maka proses tersebut akan dikembalikan kembali ke dalam tahap desain untuk pengembangan kembali perangkat lunak ke versi yang terbaru.

Tahap – tahap SDLC dalam pembangunan sistem informasi Web :
1) Plaining
Plaining (perencanaan) adalah feasibility dan wawancara , observasi, Quesener. Jika pada tahap Feasibility hasilnya baik maka langsung ketahap investigasi dan diberi form kepada client untuk

mencatat kebutuhan client. Dalam sistem investigasi, dapat berupa wawancara, kuosiener atau observation. Dalam tahap ini hal yang pertama dilakukan adalah memberikan form ke user yang digunakan untuk mengetahui permintaan user.

2) Analisa
a. Analisa TeknologiMemerlukan data penyimpanan secara informasi produk, Informasi Berita digunakan database seeprti Mysql, MSAccess.. Menganalisis teknologi apa yang digunakan pemilik desain Web seperti menggunakan desain grafis maka memerlukan teknologi seperti Adobe Photoshop, Macromedia Flash, Dreamweaver.
b. Analisa informasi. Mengenai informasi data yang akan menjadi data tetap dan data dinamis, kategori informasi data tetap adalah : profile perusahaan, visi dan misi, sejarah perusahaan, latar belakang perusahaan. Informasi dinamis adalah informasi yang selalu berubah dalam setiap periodik dapat setiap hari atau setiap jam. Informasi dinamis dalam sistem ini adalah :
1) Informasi persediaan ( stock ) produk
2) Informasi Harga Produk dan diskon
3) Informasi Artikel, tips dan trik
4) Informasi dari masing keunggulan Produk atau produk yang sedang trend
3) Desain
a. Desain Informasi. Dalam tahap ini dimodelkan informasi link dari setiap halaman, jika dalam sistem tersebut terdapat database maka digunakan tahap development dan database disain..
b. Desain Grafis. Dalam tahap ini disesuaikan dari warna, layout, gambar dan graphic.
c. Database Application
d. Model Development Database Design PHP Library Development. Tahap untuk memodelkan seluruh peruses yang ada,seperti peruses penyimpanan data,update artikel, dan menampilkan data dari database.
4) Implementasi
a. Penulisan Program dan Instalasi. Merupakan tahap penulisan program yang telah dianalisis dan diesain semua maka perogeram yang digunakan adalah PHP dan database yang digunakan MySql
b. Desain Review. Dalam tahap ini tidak hanya menguji desain yang digunakan namun menguji semua sistem yang telah diterapkan seperti tidak ada lokasi lingk, image yang salah, pengujian sistem seperti penyimpanan data, update artikel dan lain-lain.
c. Pemilihan Sumber daya Hardware dan Software. Dalam tahap ini software dan hardware digunakan untuk Web server.
d. Pengujian Web dan Dokumen Web. Menguji Web dengan berbagai teknologi browser yang ada, serta pemeriksaan dokumen Web.
Siklus hidup pengembangan sistem mempunyai beberapa tahapan, yaitu :
1) Analisis sistem, merupakan tahap awal dari SDLC, merupakan orang yang dididik khusus untuk mengembangkan sistem secara profesional.
2) Perancangan sistem memiliki dua tujuan utama, yaitu memberikan perancangan sistem logika atau perancangan sistem secara umum (general system design), dan memberikan perancangan sistem secara terinci (detail system design).
3) Implimentasi system, proses mengganti atau meninggalkan sistem yang lama dengan sistem baru.
4) Operasi dan perawatan beberapa kelebihan dan kekurangan. Kelebihannya yaitu menyediakan tahapan yang dapat digunakan sebagai pedoman mengembangkan sistem, dan akan memberikan hasil sistem yang lebih baik. Kemudian kekurangnnya, yaitu hanya menyediakan tahapan-tahapan saja, hasil dari metode ini sangat tergantung ari hasil di tahap, analisis, membuthkan waktu yang lama, membutuhkan biaya yang relatif lebih besar, dan hasilnya tidak luwes untuk dimodifikasi.

Supaya pengembangan sistem dapat bekerja dengan efisien dan efektif, maka metodologi pengembangaan sistem perlu diketahui.

Metodologi pengembangan sistem yang populer dan banyak digunakan adalah metodologi pengembangan sistem terstruktur, yang memberikan cara top down dan cara dekomposisi dan beberapa abit pengembangan sistem.

Model SDLC atau Sekuensial Linier sering disebut juga Model Air Terjun. Model ini mengusulkan sebuah pendekatan perkembangan perangkat lunak yang sistematik dan sekunsial yang dimulai pada tingkat dan kemajuan sistem pada seluruh analisis, desain, kode, pengujian, dan pemeliharaan.

Model ini disusun bertingkat, setiap tahap dalam model ini dilakukan berurutan, satu sebelum yang lainnya. Model ini biasanya digunakan untuk membuat sebuah software dalam skala besar dan yang akan dipakai dalam waktu yang lama. Sangat cocok untuk pengembangan sistem yang besar.

1. Kelebihan

v Mudah diaplikasikan.

v Memberikan template tentang metode analisis, desain, pengkodean, pengujian, dan pemeliharaan.

2. Kekurangan

v Jarang sekali proyek riil mengikuti aliran sekuensial yang dianjurkan model karena model ini bisa melakukan itersi tidak langsung.

v Pelanggan sulit untuk menyatakan kebutuhan secara eksplisit sehingga sulit untuk megakomodasi ketidakpastian pada saat awal proyek.

v Pelanggan harus bersikap sabar karena harus menunggu sampai akhir proyrk dilalui. Sebuah kesalahan jika tidak diketahui dari awal akan menjadi masalah besar karenaharus mengulang dari awal.

v Pengembang sering malakukan penundaan yang tidak perlu karena anggota tim proyek harus menunggu tim lain untuk melengkapi tugas karena memiliki ketergantungan hal ini menyebabkan penggunaan waktu tidak efesien.

Referensi

https://joulisinolungan.wordpress.com