TUGAS REKAYASA PERANGKAT LUNAK
Oleh Kelompok 11 : Putu Wulan Dewi Prihandani (1104505071) Kadek Intan Rusmayanthi (1104505078) I Gst Ag Sagotri Mahadewi (1104505099) Hafizh Affan Baihaqi (1104505103) Pande Gd Angga Priardhi Putra (1104505104)
JURUSAN TEKNOLOGI INFORMASI FAKULTAS TEKNIK UNIVERSITAS UDAYANA 2011/2012
BAB I MATERI PENGANTAR 1.1
Definisi Rekayasa Perangkat Lunak ( RPL ) 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. Perangkat lunak (PL) atau software adalah sebuah perangkat yang terdiri dari item-item / objek-objek yang merupakan konfigurasi dari : Program : perintah (program komputer) yang bila dieksekusi memberikan fungsi dan unjuk kerja seperti yang diinginkan Dokumen : menggambarkan operasi dan kegunaan program Data : struktur data yang memungkinkan program memanipulasi informasi secara proporsional 1.2 Pengertian Perangkat Lunak ( PL ) Perangkat lunak adalah istilah umum untuk data yang diformat dan disimpan secara digital, termasuk program komputer,dokumentasinya, dan berbagai informasi yang bisa dibaca dan ditulis oleh komputer. Dengan kata lain, bagian sistem komputer yang tidak berwujud. Istilah ini menonjolkan perbedaan dengan perangkat keras komputer. 1.3 Karakteristik Perangkat Lunak ( PL ) Karakteristik PL, yaitu : 1. PL merupakan suatu produk, sekaligus sarana untuk membangun suatu produk 2. PL dibangun dan dikembangkan (engineered, not manufactures). Berbeda dengan perangkat keras (hardware), PL dibuat dengan suatu perancangan yang kemudian setelah jadi dapat dikembangkan lebih lanjut. Biaya untuk PL dikonsentrasikan pada pengembangan. 3. PL tidak pernah usang (wear out) namun memburuk (deteriorate). PL tidak pernah usang karena adanya perawatan memungkinkan pengembangan PL untuk menyesuaikan dengan kebutuhan baru. Namun sekali PL rusak, maka tidak dapat diganti dengan PL lain, namun harus dilakukan pembuatan ulang karena tidak ada suku cadang dalam PL (berbeda dengan hardware). 4. Sampai saat ini kebanyakan PL masih dibuat menurut pesanan (custom built) 1.4 Tujuan RPL Tujuan RPL, yaitu : 1. Memperoleh biaya produksi perangkat lunak yang rendah. 2. Menghasilkan pereangkat lunak yang kinerjanya tinggi, andal dan tepat waktu. 3. Menghasilkan perangkat lunak yang dapat bekerja pada berbagai jenis platform. 4. Menghasilkan perangkat lunak yang biaya perawatannya rendah. 1.5 Aplikasi-Aplikasi Perangkat Lunak
Aplikasi PL, yaitu : Kandungan dan determinasi informasi merupakan faktor penting dalam menentukan sifat aplikasi PL. Kandungan informasi merujuk pada arti dan bentuk informasi yang masuk dan keluar. Determinasi informasi merujuk pada prediktabilitas urutan dan timing informasi.Aplikasi PL, yaitu : 1. System software : melayani program-program yang lain, contoh :kompiler, editor, prosesor telekomunikasi, sistem operasi, driver. Areanya ditandai dengan eratnya interaksi dengan hardware komputer, penggunaan oleh banyak user, operasi konkuren yang membutuhkan penjadwalan, tukar-menukar sumber dan pengaturan proses yang canggih serta struktur data yang kompleks dan interface eksternal yang ganda. 2. Real-time software : program-program yang memonitor / menganalisis / mengontrol kejadian dunia nyata ketika kejadian tersebut terjadi. Elemen-elemennya meliputi komponen pengumpul data (mengumpulkan dan memformat informasi dari lingkungan eksternal), komponen analisis (mentransformasikan informasi ketika dibutuhkan oleh aplikasi), komponen kontrol / output (memberi respon real-time). 3. Business software : merupakan area aplikasi PL yang paling luas. Sistem diskrit (contoh : penggajian/payroll, account receivable, inventory) telah mengembangkan PL SIM yang mengakses satu atau lebih database besar yang berisi informasi bisnis. Aplikasi dalam area ini menyusun kembali struktur data yang ada dengan suatu cara tertentu untuk memperlancar operasi bisnis atau pengambilan keputusan manajemen. 4. Engineering / scientific software : ditandai dengan algoritma numerik (number crunching). Memiliki jangkauan aplikasi mulai astronomi sampai vulkanologi, analisis otomatif sampai dinamika orbit pesawat ruang angkasa, dan biologi molekular sampai pabrik yang sudah diotomatisasi. Namun aplikasi baru dalam area teknik atau ilmu pengetahuan sedang bergerak menjauhi algoritma numerik yang konvensional. 5. Embedded software : ada dalam ROM, digunakan untuk mengontrol hasil serta sistem untuk keperluan konsumen dan pasar industri. Dapat melakukan fungsi terbatas serta fungsi esoterik (contoh : key pad control microwave yang bisa mematikan otomatis sesuai waktu) atau memberikan kemampuan kontrol dan fungsi penting (contoh : fungsi digital dalam sebuah automobil seperti kontrol bahan bakar, autopilot, penampilan dashboard, sistem rem). 6. PC software, contoh :pengolah kata, manajemen database, multimedia, hiburan aplikasi keuangan bisnis dan personal, dll. 7. AI software : menggunakan algoritma non-numerik untuk menyelesaikan masalah kompleks yang tidak sesuai untuk perhitungan maupun analisis secara langsung. Contoh : sistem pakar, aplikasi dengan jaringan syaraf tiruan, image dan suara, pembuktian teorema, permainan game. 8. Aplikasi web : aplikasi berbasis web yang mendukung kegiatan-kegiatan bisnis maupun kegiatan lain, contoh : e-commerce, search engine. Pertanyaan :
1. Jelaskan tentang Rekayasa Perangkat Lunak & Perangkat Lunak ! Jawaban : 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. Perangkat lunak (PL) atau software adalah sebuah perangkat yang terdiri dari item-item / objek-objek yang merupakan konfigurasi dari : Program : perintah (program komputer) yang bila dieksekusi memberikan fungsi dan unjuk kerja seperti yang diinginkan Dokumen : menggambarkan operasi dan kegunaan program Data : struktur data yang memungkinkan program memanipulasi informasi secara proporsional 2. Sebutkan tujuan dari RPL ! Jawaban : Tujuan RPL, yaitu : 1. Memperoleh biaya produksi perangkat lunak yang rendah. 2. Menghasilkan pereangkat lunak yang kinerjanya tinggi, andal dan tepat waktu. 3. Menghasilkan perangkat lunak yang dapat bekerja pada berbagai jenis platform. 4. Menghasilkan perangkat lunak yang biaya perawatannya rendah.
BAB II PARADIGMA RPL 2.1
Metode Metode dapat diartikan sebagai menyediakan cara bagaimana secara teknis membangun perangkat lunak yang harus berada pada sebuah komitmen dasar menuju kualitas. Metode ini menyangkut serangkaian tugas yang luas yaitu : 1. Perencanaan proyek dan estimasi 2. Analisis kebutuhan sistem dan software 3. Rancangan struktur data, yang terdiri dari 3: Variabel Elementary data : Int, char, string, dll Struktur data : record, file, array, string 4. Arsitektur Program 5. Algoritma prosedur 6. Coding 7. Testing 2.2 Alat Bantu
Tools-tools rekayasa perangkat lunak memberikan topangan yang otomatis, ataupun semi otomatis pada proses dan metode-metode yang ada seperti Computer Aided Software Engineering (CASE) yang terdiri dari : 1. DFD(Data Flow Diagram) 2. Entity Relationship for Windows(ERWIN) 3. Entitiy Relationship Diagram(ERD) Fungsi dari CASE adalah mengkombinasikan/ menggabungkan perangkat lunak, perangkat keras, dan software engineering database untuk mencipatakan lingkungan rekayasa perangkat lunak yang analog dengan CAD/CAE(Computer Aided Design/Computer Aided Engineering) untuk perangkat keras. 2.3 Prosedur Prosedur merupakan penggabungan antara metode dengan alat bantu. Prosedur mendefenisikan urutan(sequence) metode yang akan digunakan oleh seorang enginer. Prosedur juga mendefenisikan kontrol yang membantu keyakinan kualitas dan perubahan koordinasi, dan mendefenisikan keluaran (berupa : dokumen, laporan, dan formulir yang dibutuhkan). 2.4 Usaha untuk mengatasi permasalahan RPL Perekayasaan perangkat lunak berupa penggunaan metode pengembangan perangkat lunak yang dapat menghasilkan perangkat lunak berkualitas tinggi secara ekonomis dan handal. Usaha tersebut menghasilkan Alternatif paradigma Alternatif Metodologi Perangkat Bantu Komputer 1. Siklus hidup Set dari piranti teknik serta metode yang digunakan oleh insinyur software dalam proyek software disebut metodologi proyek. Metodologi proyek diterapkan dalam konteks tahap-tahap pengembangan software yang disebut fase, yang merupakan tahapan yang harus dilalui oleh produk software yang juga dapat berisikan alur informasi saat penentuan keputusan dan sebagainya. 2. Model Spiral Pemodelan dalam suatu rekayasa perangkat lunak merupakan suatu hal yang dilakukan ditahapan awal. Proses perangkat lunak tidak linear dan sederhana tapi mengandung urutan iterasi dari aktifitas pengembangan. Selama di langkah terakhir, perangkat lunak telah digunakan. Kesalahan dan kelalaian dalam menentukan kebutuhan perangkat lunak original dapat diatasi. 3. Pendekatan waterfall Model ini diperoleh dari proses engineering lainnya. Model ini menwarkan cara pembuatan perangkat lunak secara lebih nyata. Laporan langkah yang penting dalam model ini adalah : Penentuan dan analisis spesifikasi Desain sistem dan perangkat lunak Implementasi dan ujicoba unit Integrasi dan ujicoba sistem Operasi dan pemeliharaan
Masalah pendekatan waterfall adalah ketidakluwesan pembagian projek ke dalam langkah yang nyata atau jelas. Sistem yang disampaikan kadang-kadang tidak dapat digunakan sesuai keinginan costumer. Namun demikian model waterfall mencerminkan kepraktisan engineering.
2.5
Prototyping, sekuensial linear, RAD, Evolusioner, teknik formal, teknik generasi keempat 1. Model Prototyping ( Model Prototipe )
Model Prototipe (Prototype Paradigma) dimulai dengan pengumpulan kebutuhan. Pengembang dan pelanggan bertemu dan mendefinisikan obyektif keseluruhan dari perangkat lunak, mengidentifikasi segala kebutuhan yang diketahui, dan area garis besar di mana definisi lebih jauh merupakan keharusan kemudian dilakukan perancangan kilat. Perancangan kilat membawa kepada konstruksi sebuah prototipe yang kemudian dievaluasi oleh pelanggan/pemakai dan dipakai untuk menyaring kebutuhan pengembang perangkat lunak. 2. Linear Sequential Model ( Model Sekuensial Linear )
Model ini pertama kali dikemukakan oleh Royce. Model ini sering disebut model klasik atau waterfall. Model ini menyarankan pendekatan pengembangan secara sekuen dan sistematik untuk pengembangan perangkat lunak. Model ini merupakan model yang tertua. Model ini
terdiri atas beberapa tahap yaitu: rekayasa dan pemodelan sistem/informasi, analisis kebutuhan perangkat lunak, desain, generasi kode, pengujian dan pemeliharaan. 3. Rapid Application Development (RAD) Model
RAD adalah sebuah model proses perkembangan perangkat lunak sekuensial linier yangn menekankan siklus perkembangan yang sangat pendek. Model RAD merupakan adaptasi “berkecepatan tinggi” dari linear sequential model dimana pengembangan yang cepat dapat diperoleh dengan menggunakan pendekatan konstruksi berbasis komponen. 4. Evalutionary Software Process Model ( Evolusioner Model ) a. Model evolusioner adalah model perulangan. Model ini dicirikan dengan pengembang mengembangkan versi-versi sistem yang lebih lengkap sedikit demi sedikit. Model telah mempertimbangkan untuk mengakomodasikan evolusi produk secara lengkap. Model ini terdiri dari: b. Incremental model, model ini mengkombinasikan antara linear sequential model dengan filosofi iteratif pada prototyping. Pada masing-masing sekuen linear menghasilkan perangkat lunak yang semakin meningkat kompleksitasnya. c. Spriral model, model ini diusulkan oleh Boehm. Model ini menggabungkan antara sifat alami iterasi dari prototyping dengan aspek sistematik dan terkendali dari linear sequential model. Model ini memberi peluang untuk pengembangan cepat. d. Model rakitan komponen, model rakitan komponen menggabungkan beberapa karakter model spiral. Model ini bersifat evolusioner, sehingga membutuhkan pendekatan iteratif untuk menciptakan perangkat lunak. Tetapi model rakitan komponen merangkai aplikasi dari komponen perangkat lunak sebelum dipaketkan (kadang-kadang disebut “kelas”). e. Concurent development model, model perkembangan konkuren disebut juga rekayasa konkuren. Model proses yang konkuren dapat disajikan secara skematis sebagai sederetan aktivitas teknis mayor, tugas-tugas dan keadaannya yang lain. 5. Model Teknik Formal Model formal mencakup sekumpulan aktivitas yang membawa kepada spesifikasi matematis perangkat lunak komputer. Model ini memungkinkan perekayasa perangkat lunak untuk mengkhususkan, mengembangkan, dan memverifikasi sitem berbasis komputer dengan menggunakan notasi matematis yang tepat. 6. Teknik Generasi Keempat
Bentuk “teknik generasi keempat“ (4GT) mencakup serangkaian alat bantu perangkat lunak yang luas yang secara umum memiliki satu hal: masing-masing memungkinkan perekayasa perangkat lunak untuk mengkhususkan beberapa karakteristik perangkat lunak pada suatu tingkat yang tinggi. Alat bantu tersebut kemudian secara otomatis memunculkan kode sumber yang berdasarkan pada spesifikasi perekayasa. Meskipun jumlah tahapan dalam SDLC dalam berbagai literatur berbeda-beda, namun pada prinsipnya secara keseluruhan semua proses yang dilakukan sama saja. Tahapan-tahapan dalam SDLC adalah sebagai berikut : a. Analisis Sistem, tahapan ini dimulai karena adanya permintaan terhadap sistem baru. Tujuan utama analisis sistem adalah untuk menetukan hal-hal detail tentang yang akan dikerjakan oleh sistem yang diusulkan (dan bukan bagaimana caranya). Analisis sistem mencakup studi kelayakan dan analisis kebutuhan. b. Desain Sistem.
Tahapan ini dibagi kedalam dua subtahapan, yakni perancangan
konseptual dan perancangan fisik.
Target akhir tahapan ini adalah menghasilkan
rancangan yang memenuhi kebutuhan yang ditentukan selama tahapan analisis sistem. Hasil akhirnya berupa spesifikasi rancangan yang sangat rinci sehingga mudah diwujudkan pada saat pemrograman. c. Implementasi Sistem, pada tahap ini programmer harus mampu mengimplementasikan desain sistem kedalam bahasa pemrograman, untuk kemudian dilakukan pengujian. d. Pengembangan dan Pemeliharaan Sistem, tahap ini dilakukan untuk mendeteksi kesalahan-kesalahan sistem yang tidak terdeteksi pada masa pengujian sistem. Pertanyaan
:
1. Jelaskan metode dari paradigma RPL ! Jawaban
:
Metode dapat diartikan sebagai menyediakan cara bagaimana secara teknis membangun perangkat lunak yang harus berada pada sebuah komitmen dasar menuju kualitas. Metode ini menyangkut serangkaian tugas yang luas yaitu : 1. Perencanaan proyek dan estimasi 2. Analisis kebutuhan sistem dan software 3. Rancangan struktur data, yang terdiri dari 3: Variabel Elementary data : Int, char, string, dll Struktur data : record, file, array, string
4. 5. 6. 7.
Arsitektur Program Algoritma prosedur Coding Testing
BAB III MANAJEMEN PROYEK PERANGKAT LUNAK
3.1
Pengertian Manajemen Proyek Manajemen Proyek adalah kegiatan merencanakan, mengorganisasikan, mengarahkan
dan mengendalikan sumber daya organisasi perusahaan untuk mencapai tujuan tertentu dalam waktu tertentu dengan sumber daya tertentu pula. Manajemen proyek sangat cocok untuk suatu lingkungan bisnis yang menuntut kemampuan akuntansi, fleksibilitas, inovasi, kecepatan, dan perbaikan yang berkelanjutan. 3.2
Spektrum Manajemen Proyek Manajemen proyek Perangkat Lunak (PL) yang efektif berfokus pada 3P, dimana harus
berurut yaitu : a. PEOPLE
:
Elemen terpenting dari suksesnya proyek
b. PRODUCT / PROBLEM
:
Software yang dikembangkan
c. PROCESS
:
Suatu kerangka kerja dari suatu aktifitas dan
kumpulan tugas untuk 3.3
Manusia ( People ) SEI telah mengembangkan suatu model kematangan kemampuan manajemen manusia
(People Management Capability Manurity Model ( PM – CMM ) ) untuk mempertinggi kesiapan organisasi PL dalam membuat aplikasi yang semakin kompleks sehingga menarik, menumbuhkan, memotivasi, menyebarkan dan memelihara bakat yang dibutuhkan untuk mengembangkan kemapuan mengembankan PL mereka.
3.4
Masalah ( Problem )
Analisis yang mendetail mengenai kebutuhan PL akan memberikan informasi untuk menghitung perkiraan kuantitatif & perencanaan organisasi. 3.5
Proses ( Process ) Proses PL memberikan suatu kerangka kerja dimana rencana komprehensip bagi
pengembangan PL yang dapat dibangun dengan
:
Sejumlah kumpulan tugas yang berbeda, kemampuan penyampaian & jaminan kualitas
Aktifitas pelindung, jaminan kualitas PL, manajemen konfigurasi PL & pengukuran
Pertanyaan
:
1. Sebut dan jelaskan dari 3P dari Manajemen Proyek Perangkat Lunak ! Jawaban
:
Manajemen proyek Perangkat Lunak (PL) yang efektif berfokus pada 3P, dimana harus berurut yaitu : a. PEOPLE
:
Elemen terpenting dari suksesnya proyek
b. PRODUCT / PROBLEM :
Software yang dikembangkan
c. PROCESS
Suatu kerangka kerja dari suatu aktifitas dan
:
kumpulan tugas untuk
BAB IV OBSERVASI PADA ESTIMASI Estimasi yang diperlukan dalam perancangan proyek perangkat lunak di antaranya adalah sumber daya, biaya, dan jadwal sebagai usaha dalam pengembangan perangkat lunak, mengakses informasi historis yang baik, dan keberanian untuk melakukan pengukuran kuantitatif bila hanya data kualitatif saja yang ada. Berikut adalah yang menimbulkan ketidakpastian dalam estimasi : - Project complexity (kompleksitas proyek) berpengaruh kuat terhadap ketidakpastian yang inheren dalam perencanaan. Komplekitas ini merupakan pengukuran relatif yang dipengaruhi oleh kebiasaan dengan usaha yang dilakukan sebelumnya. - Project size (Ukuran proyek) Merupakan faktor penting yang dapat mempengaruhi akurasi estimasi. Bila ukuran bertambah maka ketergantungan di antara berbagai elemen perangkat lunak akan meningkat dengan cepat. - Structural uncertainty (Ketidakpastian struktural) Tingkat ketidakpastian strutural juga berpengaruh dalam risiko estimasi. Dengan melihat kembali, kita dapat mengingat lagi hal-hal yang terjadi dan dapat menghindari tempat-tempat dimana masalah muncul. Risiko diukur melalui tingkat ketidakpastian pada estimasi kuantitatif yang dibuat untuk sumber daya, biaya, dan jadwal.Bila ruang lingkup proyek atau syarat proyek tidak dipahami dengan baik, maka risiko dan ketidakpastian menjadi sangat tinggi. Perencana perangkat lunak harus melengkapi fungsi, kinerja, dan definisi interface(yang diisikan ke dalam spesifikasi sistem). Pendekatan-pendekatan rekayasa perangkat lunak modern (seperti model proses evolusioner) memakai pandangan pengembangan yang interaktif. Dengan pandangan semacam ini dimungkinkan untuk melihat estimasi dan merevisinya bila customer mengubah kebutuhannya. 4.1 TUJUAN PERENCANAAN PROYEK Tujuan perencanaan proyek perangkat lunak adalah untuk menyediakan sebuah kerangka kerja yang memungkinkan manajer membuat estimasi yang dapat dipertanggungjawabkan mengenai sumber daya, biaya dan jadwal. Tujuan perencanaan dicapai melalui suatu proses penemuan informasi yang menunjuk ke estimasi yang dapat dipertanggungjawabkan. 4.2 RUANG LINGKUP PERANGKAT LUNAK Penentuan ruang lingkup perangkat lunak merupakan aktivitas pertama dalam perencanaan proyek perangkat lunak. Ruang lingkup perangkat lunak menggabarkan fungsi, kinerja, batasan, interface dan reliabilitas. Fungsi yang digambarkan dalam statmen ruang
lingkup dievaluasi dan disaring untuk memberikan awalan yang lebih detail pada saat estimasi dimulai. Pertimbangan kinerja melingkupi pemrosesan dan kebutuhan waktu respon. Batasan ini mengidentifikasi dari batas yang ditempatkan pada perangkat lunak oleh perangkat keras eksternal, memori, atau sistem informasi yang ada. 4.3 SUMBER DAYA Mengestimasi sumber daya yang dibutuhkan untuk menyelesaikan usaha pengembangan perangkat lunak yang meliputi manusia, komponen perangkat lunak, dan peranti perangkat keras/perangkat lunak. Piramida di atas memperlihatkan sumber daya pengembangan sebagai sebuah piramid. Peranti perangkat keras dan perangkat lunak berada pada fondasi dari piramida di atas dan menyediakan infrastruktur untuk mendukung usaha pengembangan(lingkungan pengembang). Dalam tingkat yang lebih tinggi terdapat komponen perangkat lunak reuseable – blok bangungan perangkat lunak yang dapat mengurangi biaya pengembangan secara dramatis dan mempercepat penyampaian. Dan di puncak terdapat sumber daya utama yaitu manusia. Masingmasing sumber daya ditentukan dengan empat karakteristik : o Deskripsi sumber daya o Statemen ketersediaan o Waktu kronologis sumber daya diperlukan o Durasi waktu sumber daya diaplikasikan 4.3.1 Sumber daya manusia Perencanaan sumber daya manusia memulai dengan mengevaluasi ruang lingkup serta memilih kecakapan yang dibutuhkan untuk mnyelesaikan pengembangan. Baik posisi organisasi maupun specialty. Jumlah orang yang diperlukan untuk sebuah proyek perangkat lunak dapat ditentukan setelah estimasi usaha pengembangan dibuat. 4.3.2 Sumber daya perangkat lunak reusable Kreasi dan penggunaan kembali blok bangunan perangkat lunak yang seharusnya dikatalog menjadi referensi yang mudah, distandarisasi untuk aplikasi yang mudah, dan divalidasi untuk integrasi yang mudah. Ada empat kategori sumber daya perangkat lunak yang harus dipertimbngkan pada saat perencanaan berlangsung, yaitu : - Komponen off-the-self Perangkat lunak yang ada dapat diperoleh dari bagian ketiga atau telah dikembangkan secara internal untuk proyek sebelumnya. - Komponen full-experience Spesifikasi, kode, desain atau pengujian data yang sudah ada yang dikembangkan pada proyek yang lalu yang serupa dengan perangkat lunak yang akan dibangun pada proyek saat ini. - Komponen partial-experience Aplikasi, kode, desain, atau data pengujiaan yang ada pada proyek yang lalu yang dihubungkan dengan perangkat lunak yang dibangun untuk proyek saat ini, tetapi akan membutuhkan modifikasi substansial.
- Komponen baru Komponen perangkat lunak yang harus dibangun oleh tim perangkat lunak khususnya adalah untuk kebutuhan proyek sekarang . Lebih baik mengkhususkan syarat sumber daya perangkat lunak dari awal. Dengan cara ini evaluasi teknis dari semua alternatif dapat dilakukan dan akuisisi secara berkala dapat terjadi. 4.3.3 Sumber daya lingkungan Lingkungan yang mendukung poyek perangkat lunak, yang disebut juga software engineering environment (SEE), menggabungkan perangkat lunak dan perangkat keras. Karena sebagian besar organisasi perangkat lunak memiliki konstituen ganda yang memerlukan akses ke SEE, maka perencana proyek harus menentukan jendela waktu yang dibutuhkan bagi perangkat keras dan perangkat lunak serta membuktikan bahwa sember-sumber daya tersebut dapat diperoleh. Pada saat sebuah sistem berbasis komputer akan direkayasa, tim perangkat lunak mungkin membutuhkan akses ke elemen perangkat keras yang sedang dikembangkan oleh tim rekayasa yang lain. 4.4 PERTANYAAN Soal: apa saja 4 karakteristik yg diperlukan oleh sumber daya diatas..?? Jawab : Deskripsi sumber daya Statemen ketersediaan Waktu kronologis sumber daya diperlukan Durasi waktu sumber daya diaplikasikan
BAB V KONSEP KUALITAS 5.1 Kualitas American Heritage Dictionary mendefinisikan kata kualitas sebagai “sebuah karakteristik atau atribut dari sesuatu.” Sebagai atribut dari sesuatu, kualitas mengacu pada karakteristik yang dapat diukur, sesuatu yang dapat kita bandingkan dengan standar yang sudah diketahui, seperti panjang, warna, sifat kelistrikan, kelunakan, dsb. Tetapi perangkat lunak, yang sebagian besar merupakan entitas intelektual, lebih menantang untuk dikarakterisasi daripada objek fisik. Pengukuran karakteristik program benar-benar ada. Properti tersebut mencakup kompleksitas siklomatik, kohesi, jumlah function point, baris kode, dll. Bila kita mengamati sebuah item dengan didasarkan pada sifat pengukurannya, ada dua jenis kualitas yang ada, yaitu kualitas desain dan kualitas konformansi.
Kualitas desain mengacu pada karakteristik yang ditentukan oleh desainer terhadap suatu item tertentu. Nilai material, toleransi, dan spesifikasi kinerja, semua memberikan kontribusi terhadap kualitas desain. Karena material dengan nilai yang lebih tinggi digunakan dan toleransi yang lebih ketat serta tingkat kinerja yang lebih baik ditentukan, maka kualitas desain dari suatu produk bertambah, bila produk dihasilkan sesuai dengan spesifikasi yang ditentukan. Kualitas konformansi adalah tingkat dimana spesifikasi desain terus diikuti selama pembuatan. Semakin tinggi tingkat konformansi, semakin tinggi tingkat kualitas konformansi. 2. Kontrol Kualitas Kontrol kualitas merupakan serangkaian pemeriksaan, kajian, dan pengujian yang digunakan pada keseluruhan siklus pengembangan untuk memastikan bahwa setiap produk memenuhi persyaratan yang ditetapkan. Kontrol kualitas mencakup loop (kalang) umpan balik pada proses yang menciptakan produk kerja. Kombinasi pengukuran dan umpan balik memungkinkan kita memperbaiki proses bila produk kerja yang diciptakan gagal memenuhi spesifikasi mereka. Pendekatan tersebuut memandang kontrol kualitas sebagai bagian dari proses pemanufakturan. 3. Jaminan Kualitas Jaminan kualitas terdiri atas fungsi auditing dan pelaporan manajemen. Tujuan jaminan kualitas untuk memberikan data yang diperlukan oleh manajemen untuk menginformasikan masalah kualitas produk, sehingga dapat memberikan kepastian dan konfidensi bahwa kualitas produk dapat memenuhi sasaran. 4. Biaya Kualitas Biaya kualitas menyangkut semua biaya yang diadakan untuk mengejar kualitas atau untuk menampilkan kualitas yang berhubungan dengan aktivitas. Studi tentang biaya kualitas dilakukan untuk memberikan garis dasar bagi biaya kualitas yang sedang digunakan, untuk mengidentifikasi kemungkinan pengurangan biaya kualitas serta memberikan basis perbandingan yang ternormalisasi. Biaya kualitas dapat dibagi ke dalam biaya-biaya yang dihubungkan dengan pencegahan, penilaian, dan kegagalan. Biaya pencegahan meliputi : · Perencanaan kualitas · Kajian teknis formal · Perlengkapan pengujian · Pelatihan
Biaya penilaian meliputi aktivitas untuk memperoleh wawasan mengenai kondisi produk “pertama kali” pada masing-masing proses. Contoh biaya penilaian meliputi : · Inspeksi in-proses dan interproses · Pemeliharaan dan kalibrasi peralatan · Pengujian Biaya kegagalan adalah biaya yang akan hilang bila tidak ada cacat yang muncul sebelum produk disampaikan kepada pelanggan. Biaya kegagalan dapat dibagi lagi ke dalam biaya kegagalan internal dan eksternal. Biaya kegagalan internal adalah biaya yang diadakan bila kita mendeteksi suatu kesalahan dalam produk sebelum produk dipasarkan. Biaya kegagalan internal meliputi : · Pengerjaan kembali · Perbaikan · Analisis mode kegagalan Biaya kegagalan eksternal adalah biaya yang berhubungan dengan cacat yang ditemukan setelah produk disampaikan kepada pelanggan. Contoh biaya kegagalan eksternal meliputi : · Resolusi keluhan · Penggantian dan pengembalian produk · Dukungan help line · Kerja jaminan 5.2 PERGERAKAN KUALITAS Pada masa sekarang ini, para manajer senior diseluruh dunia industrymengetahui bahwa kualitas produk yang tinggi diterjemahkan kedalam penghematan biaya dan peningkatan garis dasar. Tetapi kasusnya tidak selaludemikian. Pergerakan kualitas dimulai sekitar tahun 1940 dengan kerja seminaldari W. Edward Deming dan melalui pengujian yang pertama kali di jepang.Dengan menggunakan gagasan Deming sebagai dasar, orang ± orang jepangmengembangkan sebuah pendekatan sistematis untuk mengeliminasi penyebabcacat produk. Selama tahun 1970-an dan 1980-an, pemikiran mereka menyebar kedunia barat dan disebut Total Quality Manajement ( TQM ). Meskipun istilahyang digunakan perusahaan dan penulis berbeda ± beda, ada empat langkahkemajuan dasar yang biasa ditemui dan menjadi fondasi dari banyak programTQM yang baik.Langkah pertama disebut kaizen dan mengacu pada
system peningkatan proses yang kontinu. Tujuan dari kaizen adalah mengembangkan sebuah proses( dalam hal ini adalah proses perangkat lunak ) yang kelihatan, dapat diulang, dandapat diukur. 5.3 JAMINAN KUALITAS PERANGKAT LUNAK Kualitas perangkat lunak didefinisikan sebagai : Konformansi terhadap kebutuhan fungsional dan kinerja yang dinyatakan secara eksplisit, standar perkembangan yang didokumentasikan secara eksplisit, dan karakteristik implisit yang diharapkan bagi semua perangkat lunak yang dikembangkan secara profesional. Definisi tersebut berfungsi untuk menekankan tiga hal penting, yaitu : · Kebutuhan perangkat lunak merupakan fondasi yang melaluinya kualitas diukur. Kurangnya penyesuaian terhadap kebutuhan juga menunjukkan rendahnya kualitas. · Standar yang telah ditentukan menetapkan serangkaian kriteria pengembangan yang menuntun cara perangkat lunak direkayasa. Jika kriteria tersebut tidak diikuti, hampir pasti menimbulkan kualitas yang kurang baik. · Ada serangkaian kebutuhan implisit yang sering tidak dicantumkan (misalnya kebutuhan akan kemampuan pemeliharaan yang baik). Bila perangkat lunak dapat berhasil menyesuaikan dengan kebutuhan eksplisitnya, tetapi gagal memenuhi kebutuhan implisitnya, maka kualitas perangkat lunak tersebut perlu diragukan. Aktivitas SQA Jaminan kualitas perangkat lunak terdiri dari berbagai tugas yang berhubungan dengan dua konstituen yang berbeda, perekayasa perangkat lunak yang mengerjakan kerja teknis dan kelompok SQA yang bertanggung jawab terhadap perencanaan jaminan kualitas, kesalahan, penyimpanan rekaman, analisis, dan pelaporan. Tugas kelompok SQA adalah membantu tim rekayasa perangkat lunak dalam pencapaian produk akhir yang berkualitas tinggi. The Software Engineering Institute merekomendasikan serangkaian aktivitas SQA yang menekankan rencana jaminan kualitas, kesalahan, penyimpanan rekaman, analisis, dan pelaporan. Berikut ini aktivitas yang dilakukan (difasilitasi) oleh kelompok SQA yang independen : 1. Menyiapkan rencana SQA untuk suatu proyek. Rencana itu dikembangkan selama perencanaan proyek dan dikaji oleh semua kelompok yang tertarik. Aktivitas jaminan kualitas yang dilakukan oleh tim rekayasa perangkat lunak dan kelompok SQA diatur oleh rencana.
Rencana tersebut mengidentifikasi hal-hal berikut : · Evaluasi yang dilakukan · Audit dan kajian yang dilakukan · Standar yang dapat diaplikasikan pada proyek · Prosedur untuk pelaporan dan penelusuran kesalahan · Dokumen yang dihasilkan oleh kelompok SQA · Jumlah umpan balik yang diberikan pada tim proyek perangkat lunak 2. Berpartisipasi dalam pengembangan deskripsi proses pengembangan proyek. Tim rekayasa perangkat lunak memilih sebuah proses bagi kerja yang akan dilakukan. 3. Mengkaji aktivitas rekayasa perangkat lunak untuk memverifikasi pemenuhan proses perangkat lunak yang sudah ditentukan. Kelompok SQA mengidentifikasi, mendokumentasi, dan menelusuri deviasi proses dan membuktikan apakah koreksi sudah dilakukan. 4. Mengaudit produk kerja perangkat lunak yang ditentukan untuk membuktikan kesesuaian dengan produk kerja yang ditentukan tersebut sebagai bagian dari proses perangkat lunak. 5. Memastikan bahwa deviasi pada kerja dan produk kerja perangkat lunak didokumentasi dan ditangani sesuai prosedur pendokumentasian. 6. Mencatat ketidak-sesuaian dan melaporkannya kepada manajemen senior. Item-item yang tidak sesuai ditelusuri sampai item itu diubah. 5.4 PERTANYAAN Soal : Apa aja contoh biaya kegagalan eksternal : Jawab : Resolusi keluhan Penggantian dan pengembalian produk Dukungan help line Kerja jaminan
BAB VI HIRAKI REKAYASA SISTEM Hirarki Rekayasa Sekumpulan metode top-down dan bottom-up yang biasanya dimulai dengan WV. Sistem keseluruhan dokumen bisnis dan produk diuji untuk memastikan dapat dibangun WV REKAYASA SISTEM Rekayasa sistem adalah aktivitas untuk menetapkan kebutuhan-kebutuhan pada tingkat sistem, kemudian mengalokasikan beberapa bagian dari kebutuhan-kebutuhan tersebut ke satu
atau beberapa komponen rekayasa, misalnya perangkat lunak. Rekayasa sistem dapat membantu menerjemahkan kebutuhan pelanggan menjadi model sistem tertentu, sehingga dapat memberikan gambaran bagaimana interaksi antara satu elemen sistem dengan elemen sistem lainnya. REKAYASA INFORMASI § Rekayasa informasi, yaitu rekayasa sistem yang konteks pekerjaan rekayasanya berfokus pada perusahaan bisnis (business enterprise), meliputi pengumpulan kebutuhan-kebutuhan untuk tingkat bisnis strategis dan tingkat area bisnis. REKAYASA PRODUK § Rekayasa produk (sering disebut juga dengan rekayasa sistem), yaitu rekayasa sistem yang merupakan aktivitas penyelesaian masalah. Data, fungsi, dan perilaku produk yang diinginkan dicari, dianalisis, dibuat model kebutuhannya, kemudian dialokasikan ke komponen rekayasa. Selanjutnya komponen-komponen ini disatukan dengan infrastruktur pendukungnya sampai produk tersebut jadi. Pemodelan arsitektur system Setiap sistem berbasis komputer dapat dimodelkan sebagai sebuah pemindahan informasi dengan menggunakan arsitektur input-pemrosesan- output. Hartley dan Pirbai. Memperluas arsitektur ini dengan menambahkan 2 fitur tambahan yaitu pemrosesan antarmuka pemakai dan pemrosesan self-test. Meskipun dua fitur tambahan ini tidak selalu dipakai tetapi fitur tambahan ini umum dipakai pada pemodelan sistem berbasis komputer yang membuat model sistem menjadi lebih baik. Model sistem ini menjadi dasar bagi analisis kebutuhan dan langkah desain selanjutnya. Untuk memodelkan sistem maka digunakan model template arsitekturyang mengalokasikan elemen sistem menjadi 5 bagian pemrosesan yaitu 1. antarmuka pemakai, 2.input, 3. fungsi dan kontrol sistem, 4.output dan 5. pemeliharaan dan self-test Seperti halnya pemodelan pada rekayasa sistem dan perangkat lunak, template arsitektur memungkinkan analis membuat herarki sistem secara detail. Diagram konteks arsitektur menggambar sistem pada level paling atas. Diagram konteks ini membangun batas informasi diantara sistem yang akan diimplementasikan dengan lingkungan dimana sistem akan dioperasikan. Dari diagram konteks diatas dapat saring kembali menjadi subsistem- subsistem atau modul-modul sistem dengan aliran informasi yang penting antar modul tersebut dengan menggunakan model diagram aliran arsitektur (architecture flow diagram). Diagram aliran arsitektur ini masih membagi pemrosesan sub sistem ke dalam lima elemen pemrosesn seperti diagram konteks arsitektur. Pada tingkat ini, masing-masing dari subsistem dapat beris satu elemen sistem atau lebih (perangkat keras, perangkat lunak, manusia). Diagram aliran arsitektur yang awal menjadi puncak dari hirarki diagram aliran arsitektur. Masing-masing bujursangkar pada diagram aliran arsitektur dapat diperluas atau didetailkan lagi ke dalam template arsitektur yang lain.
PEMODELAN SISTEM DAN SIMULASI Sistem dan Model • Sistem adalah sekumpulan unsur dari suatu realitas yang terbatas yang menjadi objek telaahan. Sistem bersifat relatif karena tergantung pada tujuan mempelajari sistem tersebut. • Model adalah penyederhanaan dari sistem dengan hanya memperhatikan faktor-faktor yang dianggap penting serta mengabaikan faktor-faktor yang dianggap tidak penting pada telaahan yang dilakukan. Jenis-jenis model :. Mathematical dan logical model. •
Melalui model suatu sistem kita pelajari.
•
Model Deskriptif
• Ditentukan sekumpulan kondisi input dan strategi operasi, model ini akan memprediksi apa yang akan terjadi (model input-output) •
Model Preskriptif
• Ditentukan sekumpulan kondisi, model ini akan memberikan anda suatu solusi terbaik untuk suatu kondisi tertentu •
Model Statis Vs. Dinamis
•
Model statis menangkap tingkah laku sistem pada sebuah titik waktu tertentu
•
Rata-rata tingkat pengembalian tahunan dari suatu investasi
•
Total penggunaan bahan bakar pada suatu trip
•
Model dinamis menggambarkan tingkah laku sistem sepanjang waktu tertentu
•
Tingkat inventori suku cadang dari suatu sistem manufaktur
• Banyaknya orang yang menunggu sepanjang waktu untuk dilayani pada suatu sistem layanan pelanggan •
Model Deterministik vs. Stokastik
•
Model Deterministik mengabaikan keragaman acak (random variation)
•
Model Stokastik secara eksplisit memperhatikan adanya keacakan (randomness)
•
Contoh-contoh keacakan yang menjadi perhatian dalam suatu model, meliputi
•
Lamanya suatu operasi
•
Lamanya menunggu
•
Frekuensi kegagalan
•
Waktu antar kedatangan pelanggan
Simulasi Komputer • Simulasi komputer adalah suatu proses perancangan model logika matematika dari suatu sistem nyata dan bereksperimentasi dengan model ini secara abstrak pada komputer. • Dengan dimungkinkannya kita melakukan suatu eksperimentasi secara abstrak tentang suatu sistem, maka dimungkinkan diperoleh suatu kesimpulan berkenaan dengan sistem tersebut dengan ciri: • Tanpa harus membangun sistem, jika kita ingin mengevaluasi suatu sistem yang belum ada. • Tanpa mengganggu sistem, jika kita ingin mempelajari sistem yang tengah beroperasi dan melakukan suatu eksperimen pada sistem amatlah mahal ataupun berbahaya. • Tanpa harus menghancurkan sistem, misalnya kita mempunyai tujuan untuk menentukan limit tekanan pada suatu sistem. Langkah-langkah dalam studi simulasi : - Metode Penelitian Sistem - Simulasi Sistem Antrian •
Model suatu proses pemeriksaan dalam manufacturing suatu produk tertentu
•
Produk disampaikan pada petugas pemeriksa pada suatu daerah pemeriksaan
•
Petugas pemeriksa melakukan pemeriksaan terhadap produk itu
•
Setelah proses pemeriksaan, produk akan meninggalkan daerah pemeriksaan.
•
Tiga aspek pada sistem tersebut:
Proses kedatangan produk pada daerah pemeriksaan.
Proses antrian produk untuk diperiksa. Aktifitas pemeriksaan produk. SPESIFIKASI SISTEM Spesifikasi sistem merupakan dokumen yang berfungsi menggambarkan fungsi dan kinerja sistem berbasis komputer yang akan dikembangkan, membatasi elemen-elemen sistem yang telah dialokasikan, serta memberikan indikasi mengenai perangkat lunak dan konteks sistem keseluruhan dan informasi data dan kontrol yang dimasukkan dan dikeluarkan oleh sistem yang telah digambarkan dalam diagram aliran arsitektur. Berikut salah satu format dokumen dari spesifikasi sistem yang bisa anda gunakan.
Apakah model proses perangkat lunak ? Model Mengambil kegiatan dasar seperti spesifikasi,air terjun (waterfall) pengembangan, validasi, dan evolusi dan merepresentasikannya sebagai fase-fase proses yang berbeda seperti spesifikasi persyaratan, perancangan perangkat lunak, implementasi, pengujian dan seterusnya. Pengembangan Pendekatan ini berhimpitan dengan kegiatan spesifikasi,evolusioner pengembangan, dan validasi. Sistem awal dikembangkan dengan cepat dari spesifikasi abstrak. Sistem ini kemudian di perbaiki dengan masukan dari pelanggan untuk menghasilkan sistem yang memuaskan kebutuhan pelanggan. Pendekatan ini menghasilkan suatu Pengembangan Sistem Formal sistem matematis yang formal dan mentransformasikan spesifikasi ini, dengan menggunakan metode matematik menjadi sebuah program. Pengembangan Teknik ini menganggap bahwa berdasarkan pemakaian ulang (Reusable) bagian-bagian sistem sudah ada. Proses pengembangan sistem terfokus pada pengintegrasian bagian-bagian sistem dan bukan pengembangannya dari awal.
BAB VII KONSEP DAN PEMODELAN ANALISIS
7.1
Alat Bantu Perancangan Terstruktur 1. Bagan Arus Dokumen Bagan Arus Dokumen ialah : Bagan yang menunjukan documen apasaja yang bergerak didalam suatu sistem. 2. Bagan Arus Olah Bagan Arus Olah ialah : Bagan yang menampilkan hubungan antara Input-ProsesOutput. 3. ICAM Definitation Methode ICAM Definitation Methode ialah : menampilkan proses yg terjadi dalam suatu organisasi (IDEF Flowchart). Bagi user IDEF merupakan alat analisa sistem yang paling komunikatif. 4. Diagram Arus Data (DAD) Diagram Arus Data (DAD) ialah : Bagan yang menampilkan kegiatan sistem lengkap dengan komponen-komponen yang menunjukan secara tegas file-file yang dipakai,unsur sember atau tujuan data, serta aliran data dari satu proses ke proses yang lain. Mirip dengan IDEF, DAD juga dapat dirinci secara hirarkis dari yang sifatnya secara garis besar sampai tingkat keterincian yang diperlukan.
7.2
Pemodelan Data Pemodelan data adalah metode yang digunakan untuk menentukan dan menganalisis
persyaratan data yang diperlukan untuk mendukung proses bisnis suatu organisasi. Data yang dibutuhkan adalah dicatat sebagai data model konseptual dengan definisi data yang terkait. Realisasi penerapan model konseptual yang disebut model data logis. Untuk menerapkan satu model konseptual data mungkin membutuhkan beberapa model data logis. pemodelan data mendefinisikan elemen tidak hanya data, tapi struktur dan hubungan antara mereka teknik pemodelan data dan metodologi yang digunakan untuk model data dengan cara yang standar yang konsisten, dapat diprediksi untuk mengelolanya sebagai sumber daya.
7.3
Pemodelan Fungsional Dan Aliran Data Informasi ditransformasikan pada saat dia mengalir melalui sebuah sistem berbasis
komputer. Sistem tersebut menerima input dengan berbagai cara dan menghasilkan suatu output. Akibatnya kita dapat menciptakan suatu model aliran bagi setiap sistem berbasis komputer tanpa melihat ukuran dan kompleksitasnya. 1. Diagram Aliran Data/ Data Flow Diagram (DFD) Merupakan sebuah teknik grafis yang menggambarkan aliran informasi dan transformasi yang diaplikasikan pada saat data bergerak dari input menjadi output. Dikenal juga dengan sebutan grafik aliran data atau buble chart.
Komponen-komponen DFD :
Proses : menunjukkan apa yang dikerjakan oleh sistem. Setiap proses memiliki nama yang unik dan nomor yang ditempatkan dalam simbol.
External entity adalah di luar sistem, tetapi mereka merupakan salah satu bagian yang memberikan input data ke dalam sistem atau digunakan oleh output sistem
Data Flow adalah tempat penyimpanan data
Data Store : Proses dapat menempatkan data ke dalam data store atau mengambil / mendapatkan data store. Setiap data store mempunyai nama yang unik External Entity
7.4
Pemodelan Tingkah Laku
Model prilaku menggambarkan bagaimana PL merespon event atau stimulan eksternal. Untuk model tersebut, anlisis harus melakukan langkah-langkah sebagai berikut:
Evaluasi semua use-case untuk mendapatkan pemahaman menyeluruh tentang urutan interaksi di dalam sistem.
Mengenali event yang mengendalikan urutan interaksi dan memahami bagaimana event mempunyai relasi terhadap objek spesifik.
7.5
Membuat urutan untuk setiap use-case.
Membangun state diagram untuk sistem.
Review model behavioral untuk memverifikasi akurasi dan konsistensi
Kamus Data Kamus data adalah suatu daftar data elemen yang terorganisir dengan definisi yang tetap
dan sesuai dengan sistem, sehingga user dan analis sistem mempunyai pengertian yang sama tentang input, output, dan komponen data strore.
Kamus data ini sangat membantu analis
sistem dalam mendefinisikan data yang mengalir di dalam sistem, sehingga pendefinisian data itu dapat dilakukan dengan lengkap dan terstruktur. Pembentukan kamus data dilaksanakan dalam tahap analisis dan perancangan suatu sistem.
Pada tahap analisis, kamus data merupakan
alat komunikasi antara user dan analis sistem tentang data yang mengalir di dalam sistem, yaitu tentang data yang masuk ke sistem dan tentang informasi yang dibutuhkan oleh user. Sementara itu, pada tahap perancangan sistem kamus data digunakan untuk merancang input, laporan dan database. Pembentukan kamus data didasarkan atas alur data yang terdapat pada DFD. Pertanyaan : 1. Jelaskan pengertian dari pemodelan data? Pemodelan data adalah metode yang digunakan untuk menentukan dan menganalisis persyaratan data yang diperlukan untuk mendukung proses bisnis suatu organisasi. Data yang dibutuhkan adalah dicatat sebagai data model konseptual dengan definisi data yang terkait. Realisasi penerapan model konseptual yang disebut model data logis. Untuk menerapkan satu model konseptual data mungkin membutuhkan beberapa model data logis. pemodelan data mendefinisikan elemen tidak hanya data, tapi struktur dan hubungan antara mereka teknik pemodelan data dan metodologi yang digunakan untuk model data dengan cara yang standar yang konsisten, dapat diprediksi untuk mengelolanya sebagai sumber daya.
BAB VIII KONSEP DAN PRINSIP DESAIN
8.1
Desain Perangkat Lunak Dan Rekayasa Perangkat Lunak Desain perangkat lunak berada pada inti teknik dari proses rekayasa perangkat lunak dan
diaplikasikan tanpa memperhatikan model proses perangkat lunak yang digunakan. Begitu persyaratan perangkat lunak telah mulai dianalisis dan ditentukan, maka desain perangkat lunak menjadi yang pertama dari tiga aktivitas teknik – desain, pembuatan kode dan pengujian – yang diperlukan untuk membangun dan menguji perangkat lunak. Persyaratan perangkat lunak, yang dimanifestasi oleh data, fungsional, dan model-model perilaku, mengisi langkah desain. Dengan menggunakan satu dari sejumlah metode desain, langkah desain menghasilkan : a. Desain data b. Desain arsitektur c. Desain interface d. Desain procedural
8.2
Prinsip Desain& Proses Desain Desain perangkat lunak berupa model dan proses. Proses desain adalah serangkaian
langkah iteratif yang memungkinkan desainer menggambarkan semua aspek perangkat lunak yang dibangun. Model desain adalah ekivalen rencana arsitek untuk sebuah “rumah”, yang dimulai dengan menyajikan totalitas dari hal yang akan dibangun. Prinsip desain dasar memungkinkan perekayasa perangkat lunak untuk mengendalikan proses desain. a. Proses desain tidak boleh menderita karena “tunnel vision” b. Desain harus dapat ditelusuri sampai model analisis. c. Desain tidak boleh berulang. d. Desain harus “meminimalkan kesenjangan intelektual” di antara perangkat lunak dan masalah yang ada di dunia nyata. e. Desain harus mengungkap keseragaman dan integrasi. f. Desain harus terstruktur untuk mengakomodasi perubahan. g. Desain harus terstruktur untuk berdegradasi dengan baik, bahkan pada saat data dan event-
event menyimpang, atau menghadapi kondisi operasi. h. Desain bukanlah pengkodean, dan pengkodean bukanlah desain. i. Desain harus dinilai kualitasnya pada saat desain dibuat, bukan setelah jadi. j. Desain harus dikaji untuk meminimalkan kesalahan-kesalahan konseptual (semantik). Pertanyaan : 1. Apa saja langkah desain perangkat lunak? a. Desain data b. Desain arsitektur c. Desain interface d. Desain procedural
BAB X METODE DESAIN
10.1
Desain Data Desain data adalah aktivitas pertama ( dan beberapa sering mengatakan yang terpenting ) dari empat aktivitas desain yang dilakukan selama rekayasa perangkt lunak. Proses desain data dirangkum oleh Wasserman[WAS80]: Aktivitas utama selama desain data adalah memilih representasi logis dari objek data (struktur data) yang didefinisikan selama tahap definisi persyaratan dan spesifikasi. Proses pemilihan dapat melibatkan analisis algoritmik terhadap struktur alternative untuk menentukan desain yang pling efisien atau hanya melibatkan penggunaan serangkaian modul (sebuah paket) yang memberikan operasi yang diperlukan pada beberapa reprsentsi suatu objek. Wasserman [WAS80] mengusulkan serangkaian prinsip yang dapat digunakan untuk menentkan dan mendesain data. Serangkaian prinsip itu adalah sebagai berikut; 1. Prinsip analisis sistematik yang di apliksikan pada fungsi dan perilaku seharusnya diaplikasikan juga pada data. 2. Semua struktur data dan operasi yang akan dilakukan pada masing – masing struktur data harus diidentifikasi.
3. Kamus data harus dibangun dan digunakn untuk menentukan baik data maupun desain program. 4. Keputusan desain data tingkat rendah harus ditunda sampai akhir proses desain. 5. Representasi struktur data hanya boleh diketahui oleh modul – modul yang harus menggunkan secara langsung data yang didisikan didalam struktur tersebut. 6. Pustaka struktur data danoperasi yang digunakan yang dapat diaplikasikan pada struktur data tersebut harus dikembangkan. 7. Desain perangkat lunak dan bahasa pemerograman harus mendukung spesifikasi dan realisasi dari tipe – tipe data abstrak.
10.2 Desain Arsitektur Desain arsitektur adalah untuk mengembangkan struktur program modular dan merepresentasikan hubungan control antar modul. Metode desain yang disajikan pada bagian ini mendorong prekayasa perangkat lunak untuk berkosentrasi pada desain arsitektur sebelum mencemaskan masalah perpipaan.
10.3 Proses Desain Arsitertur Desain yang berorientasi pada aliran data merupakan suatu metode desain arsitektur yang mengijinkan transisi yang baik dari model analisis ke deskripsi desain dari struktur program. Trnsisi dari aliran informasi (yang ditujukan sebagai diagram aliran data) kestruktur dilakukan bagian dari proses 5 langkah: 1.
Tipe aliran informasi dibangun.
2.
Batas aliran diindikasikan.
3.
DFD dipetakan didalam struktur program.
4.
Hirarki kontrol ditentukan dengan pemfaktoran.
5.
struktur resultan disaring atau diperhalus dengan menggunakan pengukuran desain dan heuristik.
10.4
Desain Interface Desain interface memfokuskan diri pada 3 area perhtian: 1.
Desain interface antara modul – modul perangkat lunak.
2.
Desain interface antara perangkat lunak dan produser dan konsumen informasi bukan manusia lainnya (yakni entitas eksternal lainnya).
3.
Desain interface antara pemakai dan komputer.
10.5
Desain Prosedural Mengubah elemen struktural dari arsitektur program menjadi deskripsi prosedural dari komponen perangkat lunak.
Pertanyaan : 1. Jelaskan pengertian desain arsitektur? Desain arsitektur adalah untuk mengembangkan struktur program modular dan merepresentasikan hubungan control antar modul.
BAB XI TEKNIK PENGUJIAN PERANGKAT LUNAK
11.1 DASAR-DASAR PENGUJIAN PERANGKAT LUNAK Adalah elemen kritis dari jaminan kualitas perangkat lunak dan merepresentasikan kajian pokok dari spesifikasi, desain, dan pengkodean. Pentingnya pengujian perangkat lunak dan implikasinya yang mengacu pada kualitas perangkat lunak tidak dapat terlalu ditekan karena melibatkan sederetan aktivitas produksi di mana peluang terjadinya kesalahan manusia sangat besar dan arena ketidakmampuan manusia untuk melakukan dan berkomunikasi dengan sempurna maka pengembangan perangkat lunak diiringi dengan aktivitas jaminan kualitas. Meningkatnya visibilitas (kemampuan) perangkat lunak sebagai suatu elemen sistem dan “biaya” yang muncul akibat kegagalan perangkat lunak, memotivasi dilakukannya perencanaan yang baik melalui pengujian yang teliti. Pada dasarnya, pengujian merupakan satu langkah dalam proses rekayasa perangkat lunak yang dapat dianggap sebagai hal yang merusak daripada membangun. Sejumlah aturan yang berfungsi sebagai sasaran pengujian pada perangkat lunak adalah: 1. Pengujian adalah proses eksekusi suatu program dengan maksud menemukan kesalahan 2. Test case yang baik adalah test case yang memiliki probabilitas tinggi untuk menemukan kesalahan yang belum pernah ditemukan sebelumnya 3. Pengujian yang sukses adalah pengujian yang mengungkap semua kesalahan yang belum pernah ditemukan sebelumnya Sasaran itu berlawanan dengan pandangan yang biasanya dipegang yang menyatakan bahwa pengujian yang berhasil adalah pengujian yang tidak ada kesalahan yang ditemukan. Data yang dikumpulkan pada saat pengujian dilakukan memberikan indikasi yang baik mengenai reliabilitas perangkat lunak dan beberapa menunjukkan kualitas perangkat lunak secara keseluruhan, tetapi ada satu hal yang tidak dapat dilakukan oleh pengujian, yaitu pengujian tidak dapat memperlihatkan tidak adanya cacat, pengujian hanya dapat memperlihatkan bahwa ada kesalahan perangkat lunak. 11.2 DESAIN TASE CARE Sebelum mengaplikasikan metode untuk mendesain test case yang efektif, perekayasa perangkat lunak harus memahami prinsip dasar yang menuntun pengujian perangkat lunak, yaitu:
A. B. C.
D.
E.
F.
semua pengujian harus dapat ditelusuri sampai ke persyaratan pelanggan, maksudnya mengungkap kesalahan dari cacat yang menyebabkan program gagal. Pengujian harus direncanakan lama sebelum pengujian itu mulai, maksudnya semua pengujian dapat direncanakan dan dirancang sebelum semua kode dijalankan. Prinsip Pareto berlaku untuk pengujian perangkat lunak, maksudnya dari 80% kesalahan yang ditemukan selama pengujian dapat ditelusuri sampai 20% dari semua modul program. Pengujian harus mulai “dari yang kecil” dan berkembang ke pengujian “yang besar”, Selagi pengujian berlangsung maju, pengujian mengubah focus dalam usaha menemukan kesalahan pada cluster modul yang terintegrasi dan akhirnya pada sistem. Pengujian yang mendalam tidak mungkin karena tidak mungkin mengeksekusi setiap kombinasi jalur skema pengujian dikarenakan jumlah jalur permutasi untuk program menengah pun sangat besar. Untuk menjadi paling efektif, pengujian harus dilakukan oleh pihak ketiga yang independent
Dalam lingkungan yang ideal, perekayasa perangkat lunak mendesain suatu program computer, sebuah sistem atau produk dengan testabilitas dalam pikirannya. Hal ini memungkinkan individu yang berurusan dengan pengujian mendesain test case yang efektif secara lebih mudah. Testabilitas adalah seberapa mudah sebuah program computer dapat diuji. Karena sangat sulit, perlu diketahui apa yang dapat dilakukan untuk membuatnya menjadi lebih mudah. Procedural dan menggunakannya sebagai pedoman untuk menetapkan basis set dari jalur eksekusi. Sasaran utama desain test case adalah untuk mendapatkan serangkaian pengujian yang memiliki kemungkinan tertinggi di dalam pengungkapan kesalahan pada perangkat lunak. Untuk mencapai sasaran tersebut, digunakan 4 kategori yang berbeda dari tehnik desain test case: Pengujian white-box, pengujian black-box, Integrasi Bottom-Up dan Integrasi Top-Down. 11.3 PENGUJIAN BASIS PATH Uji coba basis path adalah teknik uji coba white box yg diusulkan Tom McCabe. Metode ini memungkinkan perancang test case mendapatkan ukuran kekompleksan logical dari perancangan prosedural dan menggunkan ukuran ini sbg petunjuk untuk mendefinisikan basis set dari jalur pengerjaan. Test case yg didapat digunakan untuk mengerjakan basis set yg menjamin pengerjaan setiap perintah minimal satu kali selama uji coba.
11.3.1 Notasi diagram alir
Untuk menggambarkan pemakaian diagram alir diberikan contoh perancangan prosedural dalam bentuk flowchart
Lingkaran/node : menggambarkan satu/lebih perintah prosedural. Urutan proses dan keputusan dapat dipetakan dalam satu node. Tanda panah/edge : menggambarkan aliran kontrol. Setiap node harus mempunyai tujuan node Region : adalah daerah yg dibatasi oleh edge dan node. Termasuk daerah diluar grafik alir.
11.4 PENGUJIAN STRUKTUR KONTROL Adalah sebuah metode disain test case yang menggunakan kondisi logis yang ada pada suatu program. Contoh : Kondisi sederhana dari persamaan relasional E1 (Operator relasional) E2 E1 dan E2 merupakan persamaan matematika
Operator Relasional adalah sasalah satu dari operator berikut ini : <, ≤, =, ≠ ( - = ), >, ≥ Operator Boolean : OR („│‟), AND („&‟), NOT („-„) Yang termasuk strategi pengujian kondisi adalah : a.
Pengujian Cabang Strategi pengujian kondisi yang paling sederhana.
Untuk suatu kondisi gabungan C, cabang-cabang True dan False dari C dan setiap kondisi pada C perlu dieksekusi paling tidak satu kali. b.
Pengujian Domain
Membutuhkan tiga atau empat pengujian yang dilakukan untuk sebuah persamaan relasional. E1 > E2, c.
E1 = E2,
E1 < E2
Pengujian BRO (Branch and Relational Operator) Menggunakan batasan kondisi C.
Batasan kondisi C dengan n kndisi sederhana (D1, D2, …. Dn) dimana Di (0 < i ≤ n) merupakan batasan akhir dari kondisi C. Contoh 1 : C1 : B1 & B2 Dimana B1 dan B2 adalah variabel Boolean. Batasan kondisi C1 adalah bentuk (D1,D2) dimana D1 dan D2 adalah „t‟ atau „f‟. Nilai (t,f) adalah batasan kondisi C1 sehingga harga B1 menjadi true (t), dan harga B2 menjadi false (f), dan menghasilkan himpunan batasan {(t,t), (t,f), (f,t)} dicakup oleh eksekusi C. Contoh 2 : C2 : B1 & (E3 = E4) B1 adalah variabel Boolean. E3 dan E4 adalah persamaan matematika/aritmatika.
Batasan kondisi C2 adalah bentuk (D1,D2) dengan D1 adalah „t‟ atau „f „, dan D2 adalah „>‟, „=‟, „<‟ C2 adalah persamaan relasional dengan memodifikasi himpunan pembatas {(t,t), (f,t), (t,f)}. „t‟ untuk (E3=E4) mengimplikasikan „=‟ „f „ untuk (E3=E4) mengimplikasikan „<‟ atau „>‟ Dengan menggantikan (t,t) (t, =) (f,t) (f, =) (t,f) (t, <) atau (t, <>) atau (t, > ) Maka hasil himpunan batasan untuk C2 adalah : { (t, =), (f, =), (t, >), (t, <) } Contoh 3 : C3 : (E1 > E2) & (E3 = E4) E1, E2, E3, E4 adalah persamaan aritmatika C3 batasan kondisinya berbentuk (D1,D2) dengan D1&D2 adalah batasan C3 :
„>‟, „=‟. „<‟ maka
11.5 PERTANYAAN SOAL : Apa yg dimaksud dengan UJI COBA BASIS PATH...??
JAWAB : Metode ini memungkinkan perancang test case mendapatkan ukuran kekompleksan logical dari perancangan prosedural dan menggunkan ukuran ini sbg petunjuk untuk mendefinisikan basis set dari jalur pengerjaan
BAB XII TEKNIK PENGUJIAN
12.1 PENGUJIAN BLACK BOX Test case ini bertujuan untuk menunjukkan fungsi PL tentang cara beroperasinya, apakah pemasukan data keluaran telah berjalan sebagaimana yang diharapkan dan apakah informasi yang disimpan secara eksternal selalu dijaga kemutakhirannya. Pengujian black-box berfokus pada persyaratan fungsional PL. Pengujian inimemungkinkan analis system memperoleh kumpulan kondisi input yg akan mengerjakan seluruh keperluan fungsional program. Tujuan metode ini mencari kesalaman pada:
Fungsi yg salah atau hilang Kesalahan pada interface Kesalahan pada struktur data atau akses database Kesalahan performansi Kesalahan inisialisasi dan tujuan akhir
Metode ini tidak terfokus pada struktur kontrol seperti pengujian white-box tetapi pada domain informasi.
12.2 PENGUJIAN WHITE BOX Adalah meramalkan cara kerja perangkat lunak secara rinci, karenanya logikal path (jalur logika) perangkat lunak akan ditest dengan menyediakan test case yang akan mengerjakan kumpulan kondisi dan atau pengulangan secara spesifik. Secara sekilas dapat diambil kesimpulan white box testing merupakan petunjuk untuk mendapatkan program yang benar secara 100%. Uji coba white box adalah metode perancangan test case yang menggunakan struktur kontrol dari perancangan prosedural untuk mendapatkan test case. Dengan rnenggunakan metode white box, analis sistem akan dapat memperoleh test case yang:
menjamin seluruh independent path di dalam modul yang dikerjakan sekurang-kurangnya sekali mengerjakan seluruh keputusan logikal mengerjakan seluruh loop yang sesuai dengan batasannya mengerjakan seluruh struktur data internal yang menjamin validitas
12.3 PERTANYAAN SOAL : Sebutkan 3 analisis sistem yg akan dapat memperoleh test case...?? JAWABAN : menjamin seluruh independent path di dalam modul yang dikerjakan sekurangkurangnya sekali, mengerjakan seluruh keputusan logikal, mengerjakan seluruh loop yang sesuai dengan batasannya.
BAB XIII STRATEGI PENGUJIAN PERANGKAT LUNAK 13.1 PENDEKATAN STRATEGIS KE PENGUJIAN PERANGKAT LUNAK Strategi uji coba PL memudahkan para perancang untuk menentukan keberhasilan system yg telah dikerjakan. Hal yg harus diperhatikan adalah langkah-langkah perencanaan dan pelaksanaan harus direncanakan dengan baik dan berapa lama waktu, upaya dan sumber daya yg diperlukan. Strategi uji coba mempunyai karakteristik sbb :
Pengujian mulai pada tingkat modul yg paling bawah, dilanjutkan dgn modul di atasnya kemudian hasilnya dipadukan. Teknik pengujian yang berbeda mungkin menghasilakn sedikit perbedaan (dalam hal waktu) Pengujian dilakukan oleh pengembang perangkat lunak dan (untuk proyek yang besar) suatu kelompok pengujian yang independen. Pengujian dan debugging merupakan aktivitas yang berbeda, tetapi debugging termasuk dalam strategi pengujian.
Pengujian PL adalah satu elemen dari topik yang lebih luas yang sering diacu sebagai verifikasi dan validasi (V& V). Verifikasi : Kumpulan aktifitas yg menjamin penerapan PL benar-benar sesuai dgn fungsinya. Validasi
: Kumpulan aktivitas yang berbeda yang memastikan bahwa PL yang dibangun dapat memenuhi keperluan pelanggan.
Dgn kata lain : Verifikasi : “ Apakah kita membuat produk dgn benar?”
Validasi
: “ Apakah kita membuat benar-benar suatu produk?”
Definisi dari V&V meliputi berbagai aktivitas yang kita rujuk sebagai jaminan kualias PL (SQA).
Pengujian merupakan salah satu tugas yg ada dlm arus siklus pengembangan system yg dapat digambarkan dalam bentuk spiral :
13.2 MASLAH MASALAH STRATEGIS 13.3 PENGUJIAN INTEGRASI Pengujian terintegrasi adl teknik yg sistematis untuk penyusunan struktur program, pada saat bersamaan dikerjakan uji coba untuk memeriksa kesalahan yg nantinya digabungkan dengan interface. Metode pengujian
top down integration buttom up integration
13.3.1 TOP DOWN INTEGRATION Merupakan pendekatan inkrmental untuk penyusunan struktur program. Modul dipadukan dgn bergerak ke bawah melalui kontrol hirarki dimulai dari modul utama. Modul subordinat ke modul kontrol utama digabungkan ke dalam struktur baik menurut depth first atau breadth first.
Proses integrasi:
modul utama digunakan sebagai test driver dan stub yg menggantikan seluruh modul yg secara langsung berada di bawah modul kontrol utama. Tergantung pada pendekatan perpaduan yg dipilih (depth / breadth) Uji coba dilakukan selama masing-masing modul dipadukan Pada penyelesaian masing-masing uji coba stub yg lain dipindahkan dgn modul sebenarnya. Uji coba regression yaitu pengulangan pengujian untuk mencari kesalahan lain yg mungkin muncul.
13.3.2 BOTTOM UP INTEGRATION Pengujian buttom up dinyatakan dgn penyusunan yg dimulai dan diujicobakan dgn atomic modul (yi modul tingkat paling bawah pd struktur program). Karena modul dipadukan dari bawah ke atas, proses yg diperlukan untuk modul subordinat yg selalu diberikan harus ada dan diperlukan untuk stub yg akan dihilangkan. Strategi pengujian : Modul tingkat bawah digabungkan ke dalam cluster yg memperlihatkan subfungsi PL Driver (program kontrol pengujian) ditulis untuk mengatur input test case dan output Cluster diuji Driver diganti dan cluster yg dikombinasikan dipindahkan ke atas pada struktur program
13.4 PENGUJIAN VALIDASI Setelah semua kesalahan diperbaiki maka langkah selanjutnya adalah validasi terting. Pengujian validasi dikatakan berhasil bila fungsi yg ada pada PL sesuai dgn yg diharapkan pemakai. Validasi PL merupakan kumpulan seri uji coba black box yg menunjukkan sesuai dgn yg diperlukan. Kemungkinan kondisi setelah pengujian: 1. Karakteristik performansi fungsi sesuai dgn spesifikasi dan dapat diterima. 2. Penyimpangan dari spesifikasi ditemukan dan dibuatkan daftar penyimpangan.
13.4.1 PENGUJIAN BETA DAN ALPHA Apabila PL dibuat untuk pelanggan maka dapat dilakukan aceeptance test sehingga memungkinkan pelanggan untuk memvalidasi seluruh keperluan. Test ini dilakukan karena memungkinkan pelanggan menemukan kesalahan yg lebih rinci dan membiasakan pelanggan memahami PL yg telah dibuat.
A ) Pengujian Alpha Dilakukan pada sisi pengembang oleh seorang pelanggan. PL digunakan pada setting yg natural dgn pengembang “yg memandang” melalui bahu pemakai dan merekam semua kesalahan dan masalah pemakaian. B ) Pengujian Beta Dilakukan pada satu atau lebih pelanggan oleh pemakai akhir PL dalam lingkungan yg sebenarnya, pengembang biasanya tidak ada pada pengujian ini. Pelanggan merekan semua masalah (real atau imajiner) yg ditemui selama pengujian dan melaporkan pada pengembang pada interval waktu tertentu.
13.5 PENGUJIAN SISTEM Pada akhirnya PL digabungkan dgn elemen system lainnya dan rentetan perpaduan system dan validasi tes dilakukan. Jika uji coba gagal atau di luar skope dari proses daur siklus pengembangan system, langkah yg diambil selama perancangan dan pengujian dapat diperbaiki. Keberhasilan perpaduan PL dan system yg besar merupakan kuncinya. Sistem testing merupakan rentetan pengujian yg berbeda-beda dgn tujuan utama mengerjakan keseluruhan elemen system yg dikembangkan.
13.5.1 Recovery Testing Adalah system testing yg memaksa PL mengalami kegagalan dalam bermacam-macam cara dan memeriksa apakah perbaikan dilakukan dgn tepat.
13.5.2 Security Testing Adalah pengujian yg akan melalukan verifikasi dari mekanisme perlindungan yg akan dibuat oleh system, melindungi dari hal-hal yg mungkin terjadi.
13.5.3 Strees Testing Dirancang untuk menghadapi situasi yg tidak normal pada saat program diuji. Testing ini dilakukan oleh system untuk kondisi seperti volume data yg tidak normal (melebihi atau kurang dari batasan) atau frkkuensi.
13.6 PERTANYAAN SOAL : Apa yg dimaksud security testing..?? JAWABAN : Adalah pengujian yg akan melalukan verifikasi dari mekanisme perlindungan yg akan dibuat oleh system, melindungi dari hal-hal yg mungkin terjadi.
STUDY KASUS
Judul Proyek
: Sistem Pengontrolan Alat – Alat Bangunan Secara Online
Tanggal Mulai Proyek
: 1 Februari 2011
Tanggal Akhir Proyek
: 2 Mei 2011
Nomor Kontrak
: ........
Informasi Anggaran
: Terlampir.
Manajer Proyek
: Pande Gede Angga Priardhi P
Tujuan Proyek
: Membuat suatu sistem pengontrolan barang secara online .Hal ini bertujuan untuk menghemat pemakaian sumber daya manusia.Disamping itu juga bertujuan untuk mengurangi adanya kesalah menghitung item yang rusak ataupun item baru yang masuk.Tujuan memudahkan pekerjaan administrator gudang serta mendapatkan informasi barang secara cepat dan akurat, dan memudahkan bila ada item baru yang masuk ataupun hilang.
Pendekatan:
Melakukan pertemuan langsung dengan klien (pihak perusahaan Bahan Bangunan) untuk mendapatkan requirement-requirement yang dibutuhkan.
Melakukan survery ke Perusahaan Bangunan tentang sistem yang pantas diterapkan untuk menangani permasalahan meningkatnya volume transaksi.
Melakukan pembuatan sistem yang nantinya akan diterapkan pada perusahaan bahan bangunan yang sangat perlu system ini.
Melakukan percobaan terhadap sistem tersebut sebelum diterbitkan secara luas.
Mengembangkan sistem tersebut dengan pendekatan iteratif, mengumpulkan umpan balik dari user dan lain sebagainya.
1. Introduction/Background Perusahaan bahan bangunan merupakan sebuah perusahaan yang bergerak dalam persewaan peralatan tangga-tangga besi (scaffolding) untuk mendukung pembangunan, perbaikan maupun renovasi rumahrumah dan gedung-gedung. Setidaknya ada 18 atau lebih
jenis item barang yang direntalkan
oleh Perushaan Bangunan, seperti pipe support (TS-70, TS-90), main frame (t-190, t-170), stair, cat walk, jack base (t-60, t-40), U-Head (t-60, t-40), cross brace (p-200, p-193), join pin, leader frame (90, 60), swimple clamp, horry beam dan pipe 6 meter. Mengingat banyaknya item yang harus dikelola oleh bagian gudang (inventory), berkaitan dengan keluar-masuknya barang akibat transaksi peminjaman, pengembalian, penambahan item baru, pengurangan barang akibat rusak maupun hilang, maka perlu kiranya dibuat sistem kontrol barang “on-line” sehingga kondisi terbaru (terakhir) mulai dari jumlah barang tersisa, jumlah barang tersewa, jumlah barang rusak maupun tambahan barang baru bisa diketahui secara cepat dan akurat.
2. Business Objective Hingga kini, sistem penyewaan alat bangunan di sebuah Perushaan Bangunan pada umumnya masih dilayani oleh seorang administrator. Untuk memudahkan melakukan pengecekan barang yang di beli, penambahan barang , pengurangan barang serta barang yang baru dan bisa juga mendapatkan informasi barang seacara cepat dan akurat. Sistem ini juga diharapkan nantinya dapat mengurangi pekerjaan administrator gudang, karena bisa mendapatkan informasi barang secara online. Dalam sistem ini, konsumen diberikan sebuah alamat web, dimana web tersebut memiliki fungsi mirip dengan pembelian barang secara langsung. Web ini berfungsi sebagai alat penghubung antara konsumen dengan barang yang akan dibeli di sebuah Perushaan bahan bangunan . Dengan adanya web ini, konsumen tidak perlu datang langsung ke perushaan tersebut karena sistem yang di web akan mengerjakan hal tersebut.
3. Current Situation and Problem/Opportunity Statement sebenarnya kebanykan perusahan masih banyak yang belum memiliki sistem inventory yang belum online. Namun seiring dengan perkembangan bisnisnya yang kian maju, menyebabkan volume transaksi bisnisnya kian meningkat, sehingga pihak pemilik (owner) memandang perlu untuk mengubah sistem inventory yang ada menjadi sistem yang bersifat “on-line” dengan kemampuan sebagai berikut : -Mendapatkan laporan (report) yang dikehendaki secara on-line -Menampilkan inventaris barang-barang secara on-line -Menampilkan deskripsi barang-barang secara on-line
-File maintenance secara on-line. Untuk itulah pengembang merasa bahwa pengimplementasian sistem ini adalah merupakan salah satu cara yang tepat untuk mengatasi kasalahan pengecekan barang \mengurangi ketidak efektifan penghitungan secara manual yang menmungkinakan terjadinya kesalahan penghitungan oleh karyawan , serta membantu dalam kemudahan melakukan penghitungan item yang ada di sebuah perusahaan bahan bangunan.
4. Critical Assumption and Constraints Mengingat kendala berbagai macam media penyimpanan (storage), kinerja (performance) dan waktu responnya (time response), master file barang yang sudah ada tidak akan digunakan dalam sistem online yang baru. Namun sistem lama tersebut masih dipakai dalam batch system. Sebagai gantinya, beberapa bagian file tersebut disimpan dalam File Pilihan Barang. Barang-barang yang terdapat dalam file ini akan dipilih dari master file barang dan biasanya sering diakses.
Batch Interface
Laporan Kontrol Pilihan
Tabel Pilihan Barang
File Pilihan Barang Menambah Barang
Menu Batch interface
Menghapus Barang
Tampilan Infentori
Permintaan Laporan Infentori Barang
Tampilan Deskripsi Laporan Infentori Barang
Diagram Alir Sistem Gudang On- Line
Dalam sistem gudang on-line yang akan dibuat, pengguna dapat mengetahui informasi barang yang ada seperti persediaan barang tertentu, jumlah barang dipesan, tanggal dipesan dsb. Juga tersedia fasilitas untuk menambahkan barang baru maupun menghapus barang yang sudah tidak dikehendaki ke File Pilihan Barang. Kedua operasi terakhir dilakukan melaluiTabel Pilihan Barang yang menghubungkan item-item
yang
ada
di File
Pilihan
Barang ke master dan
mengontrol
suatu
perhitungan record terakhir. Suatu Laporan Inventory Barang bisa disajikan dalam sistem Pengontrolan ini. Laporan ini bisa diminta melalui terminal operator. Laporan ini minimal terdiri dari header dan rincian yang. memuat daftar barang persediaan dan yang dipesan. Laporan Kontrol Pilihan juga bisa diberikan untuk membuat daftar semua perubahan pada File Pilihan Barang akibat transaksi bisnis yang terjadi. Laporan ini terdiri dari bagian rincian dan ringkasan. Bagian rincian berisi penambahan barang, penghapusan barang dan jumlah permintaan yang salah. Sedangkan bagian ringkasan berisi rekapitulasi jumlah barang yang ditambahkan maupun dihapus, laporan ukuran dan status terakhirnya.
5. Analysis of Options and Recommendation Terdapat tiga opsi untuk oportuniti tersebut: 1. Jika menggunakan sistem ini dapat menghemat pemakaian sumber daya manusia, mengurangi adanya kesalahan penghitungan. Seperti telah dijelaskan sebelumnya, banyak sekali keuntungan yang dapat diperoleh oleh pihak Perusahaan yang menggunakan sistem ini, karena pada dasarnya sistem ini mengutamakan keefektifan dan efisiensi baik itu dalam hal sumber daya manusia maupun tenaga yang diperlukan untuk mengaplikasikan sistem ini. Opsi lain yang ditawarkan adalah keuntungan dan kemudahan yang akan didapatkan oleh konsumen apabila sistem ini diaplikasikan pada Perushaan tersebut. 2. Jika tidak menggunakan sistem ini, tidak akan mempengaruhi kinerja sistem sebelumnya. Apabila ada pihak Perusahaan yang kami tawarkan tidak menggunakan sistem ini, tidak akan sangat mempengaruhi kinerja sistem sebelumnya yang telah berlangsung di Perusahaan tersebut karena pada dasarnya sistem ini memberikan banyak kemudahan jika dibandingkan dengan sistem sebelumnya, tetapi apabila tidak diterapkan tidak akan berdampak besar. 3. Untuk menunjang sistem Pengontrolan Alat – Alat Bangunan ini diperlukan beberapa aplikasi seperti perangkat keras dan perangkat lunak yang compatible. Beberapa rekomendasi perangkat yang dapat kami sebutkan sehingga sistem ini dapat berjalan sempurna merupakan perangkat yang sudah teruji kecanggihannya serta memiliki nama baik terkait dengan kualitas perangkat tersebut.
6. Preliminary Project Requirements
Fitur utama dari proyek Pengontrolan Alat – Alat Bangunan Secara Online mencakup: 1. Penggunaan Pengontrolan Alat – Alat Bangunan Secara Online dapat memudahkan transaksi yang dilakukan oleh pelanggan.. Sehingga, pelanggan tidak perlu datang ke perusahaan tersebut , namun cukup dengan menggakses web yang disediakan oleh perusahaan tersebut . Hal ini diharapkan akan membuat proses transaksi menjadi lebih efisien dan lebih cepat. 2. Penggunaan Pengontrolan Alat – Alat Bangunan Secara Online membantu memanajemen barang yang ada di perushaan tersebut karena sistem ini berbasis komputerisasi yang memiliki database pada komputer untuk menghindari kesalahan penghitungan. 3. Pengefektifan bisnis pada Perusahaan bangunan, karena dapat menghemat biaya penggajian karyawan. Dengan menggunakan sistem Pengontrolan Alat – Alat Bangunan Secara Online proses pembelian barang kini hanya dilakukan oleh pelanggan saja.
7. Budget Estimate and Financial Analysis Estimasi biaya proyek sebesar Rp 70.000.000,-. Kisaran tersebut didasarkan pada waktu yang diluangkan anggota tim (termasuk project manager) untuk mengerjakan proyek 3 jam per hari selama 3 bulan dengan bayaran Rp 300.000,-/hari (untuk project manager) dan Rp 200.000,-/hari untuk 4 staf lainnya : = Pembuatan software + Uji coba software = (85 hari x (Rp.300.000,- + Rp.100.000,-)) + (6 hari x (Rp.200.000,- + Rp.100.000,-)) = Rp.34.000.000,- + Rp.1.800.000 = Rp.35.800.000,-
NoKegiatan 1 Studi Kelayakan 2 Desain Fungsi 3 Pemrograman 4 Pengujian 5 Pelatihan 6 Pemeliharaan 7 Dokumentasi Jumlah Total
Jumlah (Rp) 1.000.000,2.500.000,10.000.000,1.500.000,2.000.000,600.000,5.000.000,22.600.000,-
8. Schedule Estimate User menginginkan proyek diselesaikan dalam waktu 3 bulan, tapi terdapat beberapa fleksibilitas dalam jadwal.
Catatan :
-
Pada setiap awal kegiatan, jadwal yang lebih rinci akan didiskusikan di antara para anggota tim. Pada setiap akhir kegiatan, laporan kemajuan akan disiapkan oleh pimpinan tim untuk memberikan gambaran tentang status proyek kepada pihak-pihak yang berkepentingan
9. Potential Risks Terdapat beberapa risiko pada proyek ini. Risiko terbesar adalah gangguan jaringan internet. Apabila putus, tidak dapat mengakses.
Adanya ketidaksetujuan dari pihak perushaan
atau juga tidak
tersosialisasikannya sistem dengan baik menimbulkan masalah – masalah yang berkaitan dengan pengguna sistem gudang online .
Peranan dan Tanggung Jawab Nama Pande Gede Angga Wulan Dewi Prihandani
Sagotri Mahadewi
Kadek Intan Rusmayanthi
Peranan Project Manager
Posisi Magneto, Project Manager
Informasi Kontak
[email protected]
Magneto, Anggota Tim
Software Analyst dan
[email protected]
Riset Lapangan Magneto, Anggota tim
Software Developer
[email protected]
(programmer) Magneto, Anggota Tim
Software Developer (programmer)
[email protected]
Nama Hafizh Affan Bahaqi
Peranan
Posisi
Informasi Kontak
Representatif klien dan Anggota Tim
Riset Lapangan
[email protected]
Daftar Pustaka http://lengarifika.blogspot.com/2012/01/rekayasa-perangkat-lunak-rpl.html http://id.wikipedia.org/wiki/Perangkat_lunak http://blog.its.ac.id/dyah03tc/2007/10/02/perangkat-lunak-software/ http://irmanurulblog.blogspot.com/2012/01/tujuan-rekayasa-perangkat-lunak.html http://furqan-it-world.blogspot.com/2010/09/paradigma-rekayasa-perangkat-lunak.html http://sisfo08.blog.com/2011/10/metodologi-pengembangan-sistem-informasi/ http://adeapri89.wordpress.com/2011/09/27/pengertian-manajemen-proyek-dan-manajemenresiko/ http://sitinoerbayana.blogspot.com/2010/01/manajemen-proyek.html
