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 IMATERI 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 proporsional1.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 produk2. 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 LunakAplikasi 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 proporsional2. 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 IIPARADIGMA RPL

2.1 MetodeMetode 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 estimasi2. Analisis kebutuhan sistem dan software3. Rancangan struktur data, yang terdiri dari 3:

Variabel Elementary data : Int, char, string, dll Struktur data : record, file, array, string

4. Arsitektur Program5. Algoritma prosedur6. Coding7. Testing

2.2 Alat BantuTools-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 Komputer1. 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 FormalModel 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 estimasi2. Analisis kebutuhan sistem dan software3. Rancangan struktur data, yang terdiri dari 3:

Variabel Elementary data : Int, char, string, dll Struktur data : record, file, array, string

4. Arsitektur Program5. Algoritma prosedur6. Coding7. 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 IVOBSERVASI 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 PROYEKTujuan 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 LUNAKPenentuan 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. Masing-masing sumber daya ditentukan dengan empat karakteristik :o Deskripsi sumber dayao Statemen ketersediaano Waktu kronologis sumber daya diperlukano 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 PERTANYAANSoal: 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 VKONSEP KUALITAS

5.1 KualitasAmerican 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 KualitasKontrol 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 KualitasJaminan 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 KualitasBiaya 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 SQAJaminan 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 VIHIRAKI 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 WVREKAYASA 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-Proses-

Output.

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.

Membuat urutan untuk setiap use-case.

Membangun state diagram untuk sistem.

Review model behavioral untuk memverifikasi akurasi dan konsistensi

7.5 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 kesalahan2. Test case yang baik adalah test case yang memiliki probabilitas tinggi untuk menemukan

kesalahan yang belum pernah ditemukan sebelumnya3. 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. semua pengujian harus dapat ditelusuri sampai ke persyaratan pelanggan, maksudnya mengungkap kesalahan dari cacat yang menyebabkan program gagal.

B. Pengujian harus direncanakan lama sebelum pengujian itu mulai, maksudnya semua pengujian dapat direncanakan dan dirancang sebelum semua kode dijalankan.

C. Prinsip Pareto berlaku untuk pengujian perangkat lunak, maksudnya dari 80% kesalahan yang ditemukan selama pengujian dapat ditelusuri sampai 20% dari semua modul program.

D. 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.

E. Pengujian yang mendalam tidak mungkin karena tidak mungkin mengeksekusi setiap kombinasi jalur skema pengujian dikarenakan jumlah jalur permutasi untuk program menengah pun sangat besar.

F. 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 PATHUji 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, E1 = E2, E1 < E2

c. 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 ‘>’, ‘=’. ‘<’ maka batasan C3 :

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 XIITEKNIK 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 sekurang-kurangnya 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 ALPHAApabila 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 BetaDilakukan 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 rumah-

rumah 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 on-

line. 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 on-

Batch interfaceMenambah Barang

Menghapus Barang

Permintaan Laporan Infentori Barang

Menu

Tampilan Infentori

Tampilan Deskripsi

line 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.

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,

File Pilihan Barang

Tabel Pilihan Barang

Batch Interface

Laporan Infentori Barang

Laporan Kontrol Pilihan

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 Jumlah (Rp)1 Studi Kelayakan 1.000.000,-2 Desain Fungsi 2.500.000,-3 Pemrograman 10.000.000,-4 Pengujian 1.500.000,-5 Pelatihan 2.000.000,-6 Pemeliharaan 600.000,-7 Dokumentasi 5.000.000,-Jumlah Total 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 Peranan Posisi Informasi Kontak

Pande Gede

Angga

Project

Manager

Magneto,

Project Managerpandegedeangga@gmail.com

Wulan Dewi

PrihandaniAnggota Tim

Magneto,

Software Analyst dan

Riset Lapangan

dwulan93@yahoo.com

Sagotri

MahadewiAnggota tim

Magneto,

Software Developer

(programmer)

geknia93@yahoo .com

Kadek Intan

RusmayanthiAnggota Tim

Magneto,

Software Developer

(programmer)

intanrusmaynti@yahoo.com

Hafizh Affan

BahaqiAnggota Tim

Representatif klien dan

Riset Lapangan HaffanHafiz@yahoo.com

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-manajemen-

resiko/

http://sitinoerbayana.blogspot.com/2010/01/manajemen-proyek.html