Category Archives: Rekayasa Perangkat Lunak

Analisa Kebutuhan Perangkat Lunak (SRS)

SRS sendiri merupakan sebuah dokumentasi dari hasil analisa kebutuhan yang bertujuan untuk menyamakan visi antara pengembang perangkat lunak dengan pengguna mengenai perangkat lunak yang akan dibuat. IEEE mendefinisikan SRS sebagai dokumentasi dari kebutuhan pokok (fungsi, kinerja hambatan desain dan atribut) dari perangkat lunak dan antar muka eksternal dari perangkat lunak tersebut.

SRS sendiri sebagai hasil dari analisa kebutuhan perangkat lunak harus memperlihatikan lima hal penting didalamnya :

  1. Fungsi dari perangkat lunak
    Apa yang nanti akan dilakukan oleh perangkat lunak tersebut dan apakah fungsi utama yang diharapkan muncul di dalam SRS.
  2. Antar muka eksternal

Bagaimanakan hubungan perangkat lunak dengan pengguna, perangkat keras yang akan digunakan serta pengaruh dengan perangkat lunak lainnya.

  1. Kinerja

Bagaimana kinerja yang diharapkan dari perangkat lunak tersebut, baik dari sisi keamanan, kecepatan, kemampuan serta waktu respon terhadap masalah yang ditimbulkan.

  1. Atribut

Bagaimana dengan atribut yang terkait dalam perangkat lunak tersebut, dari sisi pemeliharaan ataupun kebenaran dari input serta output yang diharapkan.

  1. Kendala Desain

Apakah terdapat batasan khusus yang harus ada di dalam desain perangkat lunak, seperti masalah kultur, peraturan oraganisasi dan keterbatasan perangkat keras.

Setelah selesai memahami mengenai pentingnya melakukan analisa kebutuhan perangkat lunak dan hasil apa yang harus dikeluarkan setelah proses analisa selesai, maka selanjutnya adalah mempelajari sekilas mengenai cara atau metode analisa. Model yang digunakan dalam analisa kebutuhan perangkat lunak sangatlah beragam.

Sebelum melangkah ke pembahasan model analisa, patut diperhatikan dengan seksama bahwa model apapun yang nanti digunakan di dalam analisa kebutuhan sistem selalu membutuhkan informasi yang akurat di dalamnya. Informasi tersebut dapat dengan beragam cara dan wajib memenuhi syarat-syarat berikut ini agar layak dijadikan modal dalam melakukan analisa kebutuhan sistem :

  1. Dimensi waktu

Informasi yang baik untuk dianalisa harus dikeluarkan tepat waktu dalam artian informasi tersebut adalah informasi yang tidak “basi” dalam organisasi tersebut. Selain itu, informasi harus merupakan informasi yang dapat disampaikan dalam waktu yang tidak terlalu lama.

  1. Dimensi isi

dari segi isi informasi yang disampaikan oleh pengguna dan kemudian diolah ulang oleh analis sistem, maka informasi tersebut haruslah akurat dan “cukup”. Untuk mendapatkan informasi yang “cukup”, berarti informasi tersebut tidak boleh berlebihan serta relevan dengan kebutuhan perangkat lunak yang akan dibuat.

  1. Dimensi format

Secara umum, sesungguhnya tidak ada sebuah format informasi yang baku dalam lingkup analisa kebutuhan, tetapi format yang diharapkan “keluar” dari kumpulan informasi adalah format yang jelas, serta dapat dipahami (dan juga disepakati) oleh kedua belah pihak (dari pengembang maupun pengguna).

Dalam ruang lingkup RPL, umumnya model analisa terbagi menjadi dua jenis yakni model klasik dan model modern. Model klasik merupakan model yang lebih berdasarkan kepada urutan analisa dari pihak pengembang perangkat lunak yang kemudian diterjemahkan ke dalam model tertentu sehingga dapat menjadi bahan untuk melakukan perancangan perangkat lunak. Sedangkan model modern umumnya diasumsikan sebagai model analisa yang melakukan penerjemahan sistem ke dalam komponen yang saling berkaitan atau juga lazim disebut sebagai analisa berorientasi obyek.

Model klasik yang banyak digunakan untuk analisa kebutuhan data adalah ER (Entitiy Relationship) Diagram. ER Diagram yang menggambarkan struktur tabel serta relasi antar tabel dalam sebuah database, hingga saat ini merupakan “senjata utama” bagi para pengembang perangkat lunak, khususnya perangkat lunak jenis sistem informasi.

Model berikutnya adalah DFD (Data Flow Diagram) yang lebih fokus terhadap aliran data dalam sebuah perangkat lunak yang akan dibangun. DFD merupakan gambaran dari proses bisnis yang terjadi di dalam desain perangkat lunak.

Sedangkan model analisa yang dianggap lebih baru dan modern adalah dengan menggunakan UML (Unified Modeling Language). UML terdiri dari beberapa komponen diagram tersebut sering kali hanya diambil komponen terpenting (dan juga paling umum) yakni use case modeling.

            Inti dari penggunaan model use case dalam analisa kebutuhan perangkat lunak adalah memilah komponen-komponen yang terlibat dalam proses prosedural perangkat lunak, sehingga dapat didetailkan (break down) ke dalam diagram lain yang bersifat lebih teknis. Hasil dari diagram-diagram tersebut nantinya yang menjadi dasar bagi proses desain perangkat lunak selanjutnya.

Selain menggunakan model-model analisa yang telah dijelaskan tersebut, analisa kebutuhan perangkat lunak juga membutuhkan studi kelayakan (feasibility study) sebagai salah satu rangkaian kegiatan penting di dalamnya. Studi kelayakan merupakan sebuah gabungan dari berbagai disiplin ilmu, baik dari akuntansi maupun manajemen. Karena umumnya, studi kelayakan dalam lingkup analisa kebutuhan perangkat lunak, lebih fokus kepada kelayakan finansial. Dengan satu pertanyaan besar, apakah proyek perangkat telah ditetapkan. Sehingga studi kelayakan lebih menghasilkan jawaban mengenai langkah apa yang akan dikerjakan oleh pihak pengembang dalam menerima (atau tidak menerima) proyek perangkat lunak yang dimaksud.

Sebagai lanjutan “kecil” dari proses analisa kebutuhan, studi kelayakan memiliki empat pertanyaan besar yang harus dijawab oleh seorang analis sistem. Jawaban dari pertanyaan-pertanyaan tersebut yang nanti akan menjadi dasar penerimaan sebuah proyek perangkat lunak. Pertanyaan-pertanyaan yang dimaksud adalah :

  • Berapa : Merupakan pertanyaan awal yang sangat vital, yakni berapa anggaran yang telah atau harus dialokasikan dalam pembuatan proyek perangkat lunak tersebut
  • Apa : Patut pula diketahui tujuan utama dari pembuatan perangkat lunak tersebut. Apakah nanti perangkat lunak merupakan sebuah kebutuhan pokok yang mendesak atau hanya berupa               “aksesori” yang menempel ke sebuah sistem yang
  • Bagaimana : Yang dimaksud dengan pertanyaan “bagaimana” adalah mengenai prosedur dan proses bisnis yang terlibat dalam perangkat lunak tersebut.
  • Kapan : Pertanyaan yang terakhir adalah mengenai penjadwalan dan alokasi waktu yang  disediakan untuk membangun perangkat lunak tersebut

 

Analisa Perencanaan Apa Saja Ya?

Merangkum dalam buku Software Enginnering, Edisi 9, Penulis,Ian Sommerville. Halaman 623 – 626 mengenai Project Planning (23).

Dalam proyek pembangunan rencana proyek menetapkan sumber daya yang tersedia untuk proyek rincian pekerjaan, dan jadwal untuk melaksanakan pekerjaan. Rencana mengidentifikasi risiko untuk proyek dan perangkat lunak dalam pengembangan, dan pendekatan yang diambil manajemen risiko. Rincian spesifik dari perencanaan proyek sangat tergantung pada jenis organisasi yang diaplikasikan, perencanaan proyek mencakup sebagai berikut:

  1. Introduction :

            Secara singkat menjelaskan tujuan dari proyek dan menetapkan batasan (misalnya anggaran, waktu, dll) yang mempengaruhi manajemen proyek.

  1. Project Organization :

            Menggambarkan cara di mana tim pengembangan mengatur orang yang terlibat, dan setiap peran dalam tim

  1. Risk Analysis:

            Menggambarkan kemungkinan risiko proyek akan timbul, dan strategi untuk pengurangan manajemen risiko yang diusulkan.

  1. Hardware and software Resource Requirement :

            Menentukan Software dan Hardware yang diperlukan untuk melaksanakan proyek. Jika Hardware dan Software telah didapat, maka perkiraan harga dan jadwal pengiriman dapat disertakan.

  1. Work Breakdown :

            Rincian proyek dalam kegiatan dan mengidentifikasi yang terjadi (milestones)  dan penyerahan yang terkait dengan setiap aktivitas. Milestones  adalah kunci utama tahap dalam proyek dapat dinilai.

  1. Project Schedule :

            Menunjukkan hubungan antar kegiatan, perkiraan waktu yang diperlukan untuk mencapai tujuan masing-masing, dan alokasi orang untuk kegiatan.

  1. Monitoring and Reporting Mechanisms :

            Mendefinisikan laporan manajemen yang harus dijalankan dan mekanisme proyek untuk digunakan pengawasan.

Selain perencanaan proyek utama, yang harus fokus pada risiko untuk proyek dan jadwal proyek dapat dikembangkan sejumlah tambahan rencana untuk mendukung kegiatan proses lainnya seperti manajemen pengujian. Contoh rencana tambahan yang mungkin ditampilkan gambar 1.1.

Gambar 1.1 The Project Planning Process

Proses Perencanaan

Perencanaan proyek adalah suatu proses berulang yang dimulai ketika membuat awal rencana proyek selama fase startup proyek. Gambar 1.1 adalah UML activity  diagram yang menunjukkan workflow untuk sebuah proyek proses perencanaan. Perubahan rencana bisa terjadi. Sebagai informasi lebih lanjut tentang sistem dan tim proyek menjadi tersedia selama proyek teratur harus mengganti rencana persyaratan, jadwal, dan risiko perubahan. Mengubah tujuan juga menyebabkan perubahan dalam rencana proyek.

Pada awal proses perencanaan, harus menilai kendala-kendala yang mempengaruhi proyek tersebut. Milestones adalah titik dalam jadwal yang Anda dapat menilai kemajuan, misalnya, penyerahan sistem untuk pengujian. Deliverables adalah proses kerja yang disampaikan kepada pelanggan contohnya dokumen persyaratan untuk sistem.

Proses memasuki pengulangan (looping). Menyusun jadwal perkiraan proyek dan kegiatan-kegiatan yang lain. Setelah itu melihat kemajuan dan perbedaan dari jadwal yang direncanakan. Perencanaan proyek diperkirakan  berubah ke rencana semula.

Jika ada masalah serius dengan pembangunan yang mungkin menyebabkan penundaan, Diperlukan melakukan tindakan risiko untuk mengurangi risiko kegagalan proyek.

Hasil peninjauan keputusan untuk membatalkan proyek ini mungkin hasil dari kegagalan teknis. Waktu pengembangan untuk sebuah proyek perangkat lunak sering berjalannya waktu. Tujuan bisnis pasti berubah, perubahan-perubahan tersebut berarti perangkat lunak tidak lagi diperlukan atau persyaratan proyek tidak bisa digunakan. Manajemen mungkin memutuskan untuk menghentikan pengembangan perangkat lunak atau membuat perubahan besar untuk proyek supaya mencerminkan perubahan dalam tujuan organisasi.

 

BACA YUK! Penjelasan Konsep Dasar Rekayasa Perangkat Lunak

Roger R. Pressman: Rekayasa Perangkat Lunak adalah pengubahan perangkat lunak itu sendiri guna mengembangkan, memelihara, dan membangun kembali dengan menggunakan prinsip reakayasa untuk menghasilkan perangkat lunak yang dapat bekerja lebih efisien dan efektif untuk pengguna.

Tujuan Rekayasa Perangkat Lunak yaitu :

  • Memperoleh biaya produksi perangkat lunak yang rendah.
  • Menghasilkan perangkat lunak yang kinerjanya tinggi, andal dan tepat waktu
  • Menghasilkan perangkat lunak yang dapat bekerja pada berbagai jenis platform
  • Menghasilkan perangkat lunak yang biaya perawatannya rendah

 

Ruang Lingkup Rekayasa Perangkat Lunak :

  • Software Requirements berhubungan dengan spesifikasi kebutuhan dan persyaratan perangkat lunak.
  • Software design 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.

 

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.

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.

 

Lapisan Perangkat Lunak secara umum :

  • A Quality Focus

Awal dari membangun aplikasi yaitu mengetahui sasaran target pengguna, kualitas aplikasi seperti apa, infrastruktur bagaimana dll. Programmer akan mengetahui tingkatan fokus kualitas aplikasi yang ingin di bangun.

  • Process

Alur program harus mengetahui proses yang harus dijalani secara terurut dan tepat agar tidak terjadi kesalahan pada saat aplikasi selesai.

  • Method

Metode merupakan langkah-langkah dan tindakan yang sesuai dijalankan dengan metode yang ada, metode tersebut harus disesuaikan dengan perangkat lunak yang dibangun.

  • Tools

Tools atau alat bantu untuk menyelesaikan proyek yang dibuat. Berbagai tools seperti multimedia, animasi. Misalnya axure, adobe, x3d.

 

Sumber :

Presman, Rouger S, Software Enigineering, 4th Edition, Mc. Graw Hill,1997.

http://fairuzelsaid.com/konsep-dasar-rekayasa-perangkat-lunak-rpl/

Software Layer (Lapisan Perangkat Lunak)