BAB I
SOFTWARE DAN HARDWARE ENGINEERING
Selama tiga dekade pertama dari era komputerisasi, tantangan utama adalah mengembangkan hardware komputer yang dapat mengurangi biaya pengolahan dan penyimpanan data. Selama dekade tahun 1980 an, kemajuan yang pesat dari mikro elektronik menghasilkan kemampuan komputer yang lebih baik pada tingkat biaya yang lebih rendah.
Tantangan utama adalah mengurangi biaya dan memperbaiki kualitas solusi berbasis komputer (Solusi yang diimplementasikan dengan mempergunakan software). Software merupakan faktor kunci dalam keberhasilan suatu usaha, software dapat membedakan satu perusahaan dari perusahan saingannya.
Definisi Software
Suatu program yang terdiri atas sekumpulan instruksi yang berguna untuk mengendalikan komputer sehingga komputer dapat melakukan tindakan sesuai yang dikehendaki pembuatnya.
Merupakan program-program komputer dan dokumentasi yang berkaitan,
Produk Software dikembangkan untuk :
¾ Generik - dibuat untuk dijual ke suatu kumpulan pengguna yang berbeda
¾ Bespoke (custom) - dibuat untuk suatu pengguna tunggal sesuai dengan spesifikasinya.
Karakteristik Software
1. Software merupakan elemen sistem logik (bukan elemen sistem fisik seperti hardware)
2. Elemen-elemen atau fungsi-fungsi software dapat permanen
3. Elemen software dapat dimodifikasi, ditambah ataupun dikurangi (customisasi) bukan dibuat di pabrik seperti hardware
4. Software dapat diistallasi
5. Software merupakan produk atau tools yang dapat digunakan untuk mengembangkan produk lainnya
6. Secara umum software berbentuk BeSpoke
Atribut Software
Software seharusnya memberikan pengguna kebutuhan fungsionalitas dan unjuk kerja yang dapat di rawat, berguna :
Maintability, harus dapat memenuhi perubahan kebutuhan
Dependability, harus dapat dipercaya
Efficiently, harus efisien dalam penggunaan resource
Usability, harus dapat digunakan sesuai dengan yang direncanakan
Kegagalan Software
Standish Group, CHAOS Report 2000 :
o 26% of Proyek Software berhasil o 74% gagal
Permasalahan yang umum
1950 1960 1970 1980 1990 2000
o Featuritis
o
Miscommunication (antara team dan customer, antara team)EVOLUSI SOFTWARE
Tahun-tahun awal :
◊ Batch orientation
◊ Limmited distribution
◊ Custummer software
Era kedua :
◊ Multi user
◊ Real time
◊ Database
Era ketiga
◊ Distibuted system
◊ Embedded intellegence
◊ Low cost hardware
◊ Consumer infact
Era keempat :
◊ Expert system
◊ A I Machine
◊ Parallel architecture
Tahun pertama
◊ Batch Orientation
Suatu orientasi di mana proses dilakukan setelah data dikumpulkan dalam satuan waktu tertentu, atau proses dilakukan setelah data terkumpul, lawan dari batch adalah ONLINE atau Interactive Process.
Keuntungan dari Interactive adalah mendapatkan data yang selalu up to date.
◊ Limmited distribution
Suatu penyebaran software yang terbatas pada perusahaan-perusahaan tertentu.
◊ Custom software
Software yang dikembangkan berdasarkan perusahaan-perusahaan tertentu.
Era kedua
◊ Multi user
Suatu sistem dimana satu komputer digunakan oleh beberapa user pada saat yang sama.
◊ Real Time
Suatu sistem yang dapat mengumpulkan, menganalisa dan mentransformasikan data dari berbagai sumber, mengontrol proses dan menghasilkan output dalam mili second.
◊ Database
Perkembangan yang pesat dari alat penyimpan data yang OnLine menyebabkan muncul generasi pertama DBMS (DataBase Management System).
Adalah software yang dikembangkan untuk dijual kepada masyarakat luas.
Era Ketiga
◊ Distributed system
Suatu sistem yang tidak hanya dipusatkan pada komputer induk (Host computer), daerah atau bidang lainnya yang juga memiliki komputer yang ukurannya lebih kecil dari komputer induk. Lawan dari distributed system adalah Centralized System.
◊ Embedded Intelegence
Suatu product yang diberi tambahan “Intellegence” dan biasanya ditambahkan mikroprocessor yang mutakhir. Contohnya adalah automobil, robot, peralatan diagnostic serum darah.
◊ Low Cost Hardware
harga hardware yang semakin rendah, ini dimungkinkan karena munculnya Personal Computer.
◊ Consummer Inpact
Adanya perkembangan komputer yang murah menyebabkan banyaknya software yang dikembangkan, software ini memberi dampak yang besar terhadap masyarakat.
Era Keempat
◊ Expert system
Suatu penerapan A.I. (Artificial Intellegence) pada bidang-bidang tertentu, misalnya bidang kedokteran, komunikasi, dan lain-lain.
◊ AI Machine
Suatu mesin yang dapat meniru kerja dari sebagian otak manusia. Misalnya mesin robot, komputer catur.
◊ Parallel Architecture
Arsitektur komputer yang memungkinkan proses kerja LAN paralel, yang dimungkinkan adanya prosesor berbeda dalam satu komputer
Rekayasa Software:
Adalah suatu disiplin rekayasa yang berkonsentrasi terhadap seluruh aspek produksi Software.
Mengadopsi pendekatan yang sistematis dan terorganisir terhadap pekerjaannya dan menggunakan tool yang sesuai serta teknik yang ditentukan berdasarkan masalah yang akan dipecahkan, kendala pengembangan dan sumber daya yang tersedia
Biaya rekayasa Software
• Sekitar 60% untuk biaya pengembangan, 40% biaya pengujian. Untuk Software berbasis pengguna (custom), biaya evolusi biasanya melebihi biaya pengembangan.
• Biaya beragam tergantung pada tipe sistem yang akan dikembangkan dan kebutuhan sistem seperti unjuk kerja dan kehandalan sistem,
BAB II
MODEL APLIKASI SOFTWARE
1. Sistem Software
Adalah sekumpulan program yang ditulis sebagai layanan atau menunjang program lainnya. Beberapa sistem software seperti Compiler, Editor, Sistem Operasi, driver dan Software Prosessor Telekomunikasi.
2. Real Time Software
Software yang berfungsi untuk mengukur, menganalisis dan mengontrol aktivitas sesungguhnya terjadi dalam dunia nyata. Elemen-elemen terdiri dari :
a. Komponen data collector yang mengumpulkan dan menyusun informasi dari lingkungan external.
b. Komponen analisis yang mentransformasikan informasi dari aplikasi c. Komponen kontrol yang memberikan respon pada lingkungan external
d. Komponen monitor yang mengkoordinasikan komponen-komponen lainnya, sampai respons real time yang berkisar 1 milisecond sampai 1 menit dapat dipertahankan.
Perlu dicatat bahwa istilah real time berbeda dari istilah interactive atau time sharing. Sistem real time harus memberikan respons pada waktu yang ditentukan, sedangkan pada sistem interactive atau time sharing respons time biasanya melebihi batas waktu yang ditentukan tanpa merusak hasil.
3. Business Software
Software yang paling banyak digunakan dalam bidang aplikasi software. Software ini digunakan oleh manajemen untuk mengambil keputusan (Decision Making) dalam bidang bisnis. Contoh :
◊ Dac Easy Accounting
◊ Finance Manager
4. Engineering and Scientific Software
Software dengan algoritma numerik, aplikasinya berkisar dari astronomi sampai vulkanologi, dari analis ketegangan otomotif sampai dinamika orbit ruang angkasa. Software ini banyak digunakan dalam bidang engineering dan science. Contoh :
◊ CAD / CAM ( Computer Aided Design / Computer Aided Manufacture - Simulasi sistem)
◊ Matlab, SPSS, Maple, CPlex 5. Emdebed Software
Suatu software disimpan dalam memori tetap - ROM - Read Only Memory, dan digunakan untuk mengontrol product dan sistem software ini dijalankan dengan berbagai fungsi terbatas.
6. PC software (Personal Computer)
Software yang banyak digunakan di komputer pribadi (PC). Contoh :
◊ Word Processing : Wordstar, CiWriter, MS Word, WordPad, NotePad
◊ Spreadsheet : Lotus, Supercalc, Symphony, Excel
◊ Computer Graphics : Printshop,Print Magic,Adobe
Photoshop,CorelDraw,Autocad, Paint, Flash
◊ Games : Paoman, Load Runner
◊ DBMS : DBase III+,DBase IV, Foxbase, FoxPro, Clipper, MS. Access
◊ Network : LAN, Novell
7. Artificial Inteligence software
system. Bidang aplikasi lain dari software AI adalah pengenalan citra dan suara ( image and voice pattern recognition ), teorema pembuktian dan permainan / games.
Krisis Software
Masalah yang ditemukan dalam pengembangan software komputer, masalahnya tidak hanya terbatas pada software yang tidak berfungsi sebagaimana mestinya, tetapi krisis software ini terdiri dari masalah yang berhubungan dengan :
1. Bagaimana mengembangkan software
2. Bagaimana memelihara software yang ada, yang berkembang dalam jumlah besar 3. Bagaimana mengimbangi permintaan software yang makin besar.
Masalah
Krisis software dengan beberapa persoalan sebagai berikut :
1. Estimasi jadwal dan biaya yang sering tidak tepat (tidak terjamin)
2. Produktivitas developer yang tidak dapat mengimbangi permintaan software 3. Kualitas software yang kurang baik (tidak sesuai)
Penyebab ini disebabkan oleh beberapa hal : 1. Karakteristik software itu sendiri
Software yang bersifat logika dibandingkan fisik, oleh karena itu sulit mengukur untuk memberikan suatu parameter. Software yang bersifat tidak aus ini menyebabkan kesalahan yang terjadi pada software. Umumnya terjadi pada tahap pengembangan. Manajer tingkat menengah dan tingkat atas yang tidak mempunyai latar belakang software, seringkali diberi tanggung jawab untuk mengembangkan software. Padahal tidak semua manajer itu dapat me-manage semua proyek.
Praktisnya : software programmer atau software engineering mendapatkan latihan formal yang sedikit dalam hal teknik baru pengembangan software.
2. Kegagalan pengembangan software (mundur dari proyek).
Mitos Software
1. Mitos managements
A. Kita tidak perlu mengubah pendekatan terhadap pengembangan software, karena jenis pemrograman yang kita lakukan sekarang ini sudah kita lakukan 10 tahun yang lalu.
Realitasnya : Walau hasil program sama, produktivitas dan kualitas software harus ditingkatkan dengan menggunakan pendekatan software developments
B. Kita sudah mempunyai buku yang berisi standarisasi dan prosedur untuk pembentukan software.
Realitasnya : Memang buku tersebut ada, tetapi apakah buku tersebut sudah dibaca atau buku tersebut sudah ketinggalan jaman ( out of date ).
C. Jika kita tertinggal dari jadwal yang ditetapkan, kita menambah beberapa programmer saja. Konsep ini sering disebut Mongolian harde concept.
2. Mitos Langganan / Customer
A. Pernyataan tujuan umum sudah cukup untuk memulai penulisan program. Penjelasan yang lebih rinci akan menyusul kemudian.
B. Kebutuhan proyek yang terus menerus berubah dapat dengan mudah diatasi karena software itu bersifat fleksibel. Kenyataannya memang benar bahwa kebutuhan software berubah, tetapi dampak dari perubahan berbeda dari waktu ke waktu.
Kesimpulan : Jika perubahan mendekati akhir penyelesaian, maka biaya akan lebih besar.
3. Mitos Praktisi
A. Tidak ada metode untuk analisis disain dan testing terhadap suatu pekerjaan, cukup menuju ke depan terminal dan mulai coding.
Realitasnya : Metode untuk analisis desain dan testing diperlukan dalam pengembangan software.
B. Segera setelah software digunakan, pemeliharaan dapat diminimalisasikan dan diatasi dengan cara “CATCH AS CATCH CAM”.
BAB III
PENDUKUNG SISTEM KOMPUTER
Rekayasa Sistem Komputer (Computer system engineering) terdiri atas 2 bagian yaitu : hardware engineering, software engineering. Setiap disiplin ini berusaha menunjukkan pengembangan sistem berbasis komputer tehnik engineering. Untuk hardware komputer telah sedemikian maju dan relatif jenuh. Sebaliknya software komputer mulai berkembang, dan saat ini menggantikan peranan hardware sebagai elemen sistem yang sulit direncanakan, sedikit kemungkinan untuk berhasil dengan biaya rendah dan waktu yang cepat, serta paling sukar untuk dikelola.
Apa Sistem itu ?
Sistem adalah sekumpulan elemen yang saling berinteraksi untuk mencapai suatu tujuan. Sedangkan Computer Based System diorganisir untuk mendapatkan beberapa metode, prosedur atau pengontrolan dengan cara mengelola informasi.
Elemen-elemen sistem berbasis komputer berupa :
1. Software
Program komputer, struktur data dan dokumentasi yang saling berhubungan dan memberikan efek pada metode, prosedur dan kontrol yang diinginkan.
2. Hardware
Peralatan elektronik, (misalnya CPU, memory) yang memberikan kemampuan komputasi serta peralatan elektromedia (misalnya sensor, motor, pompa) yang memberikan fungsi external.
3. People / Brainware
User dan operator dari hardware dan software
4. Database
Sekumpulan informasi yang besar, yang diorganisir agar dapat diakses oleh software dan merupakan bagian integral dari fungsi sistem.
5. Prosedur
Langkah-langkah yang menetapkan pemakaian khusus untuk setiap elemen sistem.
Keterangan :
Computer system engineering adalah suatu aktifitas pemecahan masalah fungsi sistem yang diinginkan, ditemukan, dianalisis, dan dialokasikan ke elemen-elemen sistem individu.
Computer System Engineering disebut juga Sistem Analis, dimulai dengan : 1. Penetapan tujuan customer
Segera setelah fungsi performance, hambatan dan interface ditetapkan, system engineering selanjutnya melakukan pekerjaan alokasi. Selama pengalokasian fungsi diserahkan kepada satu / lebih elemen sistem (misalnya software, hardware, people, Dan lain-lain) seringkali alokasi alternatif diusulkan dan dievaluasi. Fungsi yang dialokasikan maksudnya adalah menentukan mana yang masuk ke hardware, ke software dan ke brainware
Kriteria pemilihan konfigurasi sistem dilakukan berdasarkan alokasi fungsi dan performance elemen sistem :
1. Project Consideration (Pertimbangan Proyek). Dapatkah konfigurasi dihasilkan dengan biaya dan jadual yang ditetapkan lebih awal ?
2. Business Consideration (Pertimbangan Bisnis). Dapatkah konfigurasi memberikan solusi yang paling menguntungkan ? Dapatkah dipasarkan dengan sukses ?
ª Pertimbangan ini yang paling penting.
3. Technical Consideration (Pertimbangan teknik). Apakah ada tehnologi untuk mengembangkan semua elemen sistem ? Dapatkah fungsi performance dijamin ? Dapatkah konfigurasi dipelihara dengan cukup baik ?
4. Manufacturing Evaluation (Evaluasi Pabrik). Apakah fasilitas dan peralatan manufaktur tersedia ?
Apakah ada komponen yang diperlukan dengan segera ?. Apakah jaminan kualitas dapat dipercaya ?
5. Human Issues (Karakter manusia). Apakah tenaga kerja terlatih untuk pengembangan dan manufaktur tersedia ? Apakah customer mengerti dengan apa yang akan dicapai oleh sistem ?
6. Environmental Interface (lingkungan antar muka). Apakah konfigurasi yang diusulkan sudah cukup berhubungan dengan lingkungan external dari sistem ? Apakah komunikasi mesin Î manusia dan manusia Î mesin sudah ditangani dengan baik ?
7. Legal Consideration (Pertimbangan hukum). Apakah pertimbangan yang dihasilkan sudah dilindungi oleh hukum ?
PERTIMBANGAN HARDWARE
Computer System Engineering selalu mengalokasikan satu / lebih fungsi sistem ke hardware komputer.
Elemen-elemen hardware
1. CPU - Cenral Processing Units
2. Adalah unit yang melakukan pekerjaan aritmatik, logika, dan fungsi pengontrol serta berinteraksi dengan komponen lainnya. Sekarang ini, beberapa arsitektur komputer ditambahkan ko-prosesor untuk melakukan fungsi pengolahan khusus ( fungsi kalkulasi ) sehingga performance CPU dapat ditingkatkan.
3. BUS
4. Adalah alat komunikasi yang menghubungkan elemen satu dengan elemen lainnya untuk pengiriman instruksi, data dan informasi pengontrolan.
5. Memory
Memory terbagi menjadi 2 bagian, yaitu :
A. Memori Primer / Primary Memory / Main Memory
Adalah memory yang terdapat di dalam komputer, terdiri atas 2 bagian yaitu : i. RAM - Random Access Memory
Untuk menyimpan data / instruksi yang bersifat temporary ii. ROM - Read Only Memory / Firmware
Untuk menyimpan perintah dan / atau data yang permanen. ROM terbagi atas 2 golongan
a. PROM - Programmabel Read Only Memory
Memory ROM yang dapat ditulis / diprogram dan dapat dihapus dengan cara :
EEPROM - Eraseble Electrical Programmabel ROM Dihapus dengan kejutan listrik tertentu
UVPROM - Ultra Violet Programmabel ROM Dihapus dengan sinar ultra violet
b. MASK ROM
ROM yang terjual sudah diprogram pada saat dibuat oleh pabriknya. B. Memory Sekunder
Sifat yang menonjol dari memory jenis ini adalah : i. Waktu akses lambat
ii. Kapasitas besar sekali dibandingkan dengan memory primer
iii. Waktu akses berkisar milidetik dengan kapasitas antara 400.000 sampai 1 billion byte
iv. Contoh : Floppy disk, harddisk, hardcard, optical disk
Aplikasi Software
Dapat dikelompokan dalam 3 bagian besar, yaitu : 1. Software pengelolahan informasi
BAB IV
DINAMIKA PROSES SISTEM
Definisi Proses
Merupakan Rangka kerja (framework) yang berisi sehimpunan aktivitas-aktivitas yang saling berasosiasi untuk menghasilkan produk Software.
Terdapat 4 aktivitas generic proses software adalah:
• Spesifikasi apa yang harus dilakukan agar batasan/ kendala pengembangannya terdefenisi
• Pengembangan bentuk produksi proses dari sistem Software
• Bentuk validasi pengujian software yang kustomisasi
• Evolusi-perubahan karakteristik software yang kustomisasi
Suatu proses model adalah suatu representasi abstrak suatu model. Proses model menampilkan suatu deskripsi suatu proses dari beberapa perspektif tertentu, proses Software merupakan aktifitas yang saling terkait (koheren) untuk menspesifikasikan, merancang, implementasi dan pengujian sistem Software.
Proses Software memberikan suatu kerangka kerja dimana rencana komprehensip bagi pengembangan PL yang dapat dibangun dengan
- Sejumlah kumpulan tugas yang berbeda, kemampuan penyampaian dan jaminan kualitas
- Aktifitas pelindung, jaminan kualitas Software, manajemen konfigurasi Software dan pengukuran
Bentuk Proses Software
Suatu representasi proses software yang disederhanakan, dipresentasikan dari perspektif secara khusus, contoh perspektif proses:
• Perspektif Alur-kerja (workflow) (untuk kegiatan)
• Perspektif Alur Data (Data flow) (untuk informasi)
• Perspektif Aksi (System Event)
Model proses software :
1. Sekuensial Linier
System Development Life Cycle / model air terjun/ model spiral 2. Prototipe
Perencanaan yang dilakukan berdasarkan flatform disain suatu konstruksi. 3. Rapid Aplication Development (RAD)
Model sekuensial linier yang menekankan SDLC dalam jangka pendek dan pendekatan konstruksi berbasis komponen
4. Increemental (Pertambahan)
Menggabung elemen-elemen model sekuensial linier dengan prototype iterative khusus untuk staffing
5. Spiral
Merangkai sifat prototype iterative dengan cara kontrol sekunsial linier
6. Rakitan Komponen
Paradigma orientrasi obyek (OOP dan OOD) menekankan kreasi kelas yang mengenkapsulasi data dan algoritma yang dipakai untuk memanipulasi data (gabungan dengan karakter spiral)
Requirements definition
System and software design
Implementation and unit testing
Integration and system testing
Operation and maintenance
Sering dipakai untuk mengembangkan aplikasi client server Aktivitas dibagi menjadi :
- dimensi sistem : desain, assembly dan pemakai - dimensi komponen : desain dan realisasi 8. Metode Formal
Mengkhususkan, mengembangkan, dan menverifikasi sistem berbasis komputer dengan notasi matematis yang tepat (Clean room RPL)
9. Teknik Generasi
Serangkaian alat bantu PL yang secara otomatis memunculkan kode sumber yang berdasarkan pada spesifikasi perekayasaan 1, 2 dan 3 (konvensional) sisanya evolusioner. Harus ditentukan model paling banyak memawakili pelanggan, karakteristik produk dan lingkungan proyek
Model Air Terjun (Water Fall)
Fase Model Air Terjun
1. Analisis kebutuhan dan penentuan bahan
2. Perancangan sistem dan Software (pembuatan coding) 3. Implementasi dan unit testing
4. Integrasi dan pengujian sistem 5. Pengoperasian dan perawatan
Proses kembali ke state sebelumnya untuk mengantisipasi perubahan setelah proses menuju ke suatu state di bawahnya adalah sangat sulit.
Masalah pada Model Air Terjun :
• Partisi projek dalam stages yang berbeda tidak fleksibel.
• Sering mengakibatkan sulitnya merespon perubahan kebutuhan pengguna
• Sistem ini cocoknya digunakan orang yang mengerti detail proses tersebut
Pengembangan berevolusi (Evolutionary Development) Pengembangan yang berdasarkan penyidikan
Tujuannya untuk mengaktifkan pengguna dan memperolah model final berasal dari initial spesifikasi awal. Seharusnya diawali dengan kebutuhan yang sudah dimengerti,
Throw-away prototyping
Validation Final
definition specificationFormal transformationFormal
Integration and Permasalahan dalam model pengembangan yang berevolusi:
• Kekurangan visibilitas proses
• Model sistem biasanya tidak terstruktur
• Membutuhkan kemampuan khusus (mis.: bahasa pemrograman untuk rapid prototyping).
Pemakaian model pengembangan yang berevolusi
• Untuk sistem interaktif yang kecil atau menengah
• Untuk salah satu bagian dari sistem yang besar (mis. User Interface)
• Untuk sistem yang digunakan tidak terlalu lama (short lifetime).
Pendekatan pengembangan sistem Formal
Berbasiskan pada transformasi spesifikasi secara matematik melalui representasi yang berbeda untuk suatu program yang dapat dieksekusi, trasformasi menyatakan spesifikasi program menggunakan pendekatan ‘Cleanroom’ untuk pengembangan prangkat lunak.
Pengembangan menggunakan konsep Re-use (Penggunaan Ulang)
Proses dengan metode Iterasi
Model Iterasi dapat digunakan pada setiap model proses generic Terdapat dua pendekatan:
• Pengembangan Incremental
Risk
Prototype 3 Opera-tional protoype
requirements Assign requirements to increments
System incomplete
Final system
Model Pengembangan Incremental
Pengembangan sistem berdasarkan model sistem yang dipecah sehingga model pengembangannya secara increament/bertahap. Kebutuhan pengguna diprioritaskan dan priritas tertinggi dimasukkan dalam awal increment Setelah pengembangan suatu increment dimulai, kebutuhan dibekukan dulu hingga increment berikutnya dimulai
Keuntungan
Nilai penggunan dapat ditentukan pada setiap increament sehingga fungsionalitas sistem disediakan lebih awal, increment awal berupa prototype untuk membantu memahami kebutuhan pada increment berikutnya, memiliki risiko lebih rendah terhadap keseluruhan pengembagan sistem, prioritas tertinggi pada pelayanan sistem adalah yang paling diuji.
Model Pengembangan Spiral
Proses direpresentasikan sebagai model spiral (bukan berupa barisan aktfitas yang dapat ditrack mundur)
Sektor pada model Spiral : 1. Menentukan Tujuan
2. Mengidentifikasikan spesifikasi tujuan setiap fase 3. Menilai Resiko dan Pengurangannya
4. Resiko dinial dan aktifitas ditempatkan untuk mengurangi resiko kunci 5. Pengembangan dan validasi
6. Suatu model pengembangan sistem dipilih dari model generic 7. Perencanaan
8. Project di review dan fase spiral berikutnya direncanakan
Spesifikasi Software
Proses untuk menentukan pelayanan (servis) apa yang dibutuhkan dan kendala-kendala pengoperasian sistem serta pengembangannya, proses rekayasa kebutuhan
• Studi Kelayakan
• Analisis kebutuhan
• Spesifikasi Kebutuhan
BAB V
PERENCANAAN PROYEK SOFTWARE
Definisi
Merupakan manajemen proses proyek software dimulai kegiatan project planning (perencanaan proyek) sampai akhir proyek. Aktivitas awal adalah estimation (perkiraan) terhadap resiko yang inheren (resiko yang muncul dari diri sistem itu sendiri) yang kemungkinan resiko berdampak ketidakpastian. Aspek yang mempengaruhi estimasi :
- Project Complexity (kompleksitas proyek) - Project Size (ukuran proyek)
- Structure Uncertainty (ketidakpastian struktural)
Tujuan :
Mempersiapkan suatu kerangka kerja yang memungkinkan bagi para developer dapat mengestimasi berbagai hal yang mungkin muncul baik berupa alokasi resource (SDM, waktu penyelesaian project (jadwal), biaya) secara sistematis.
Struktur Perencanaan Proyek Isi dari perencanaan proyek :
Pengenalan Proyek Æ secara singkat menjelaskan tujuan dan ruang lingkup
proyek serta kendala (biaya dan waktu) yang memperngaruhi manajemen proyek.
Organisasi Proyek Æ bagaimana susuna tim Software diorganisasikan, siapa orangnya dan apa perannya dalam proyek.
Analisa Resiko Æ Menggambarkan dampak-dampak negatif proyek kemungkinan terjadinya resiko, dan strategi mereduksi resiko
Permintaan Hardware dan Software Æ Menggambarkan berbagai kebutuhan
perangkat keras dan Software yang digunakan untuk penyelesaian proyek dengan pertimbangan skal prioritas. Perangkat keras atau Software yang berkaitan dengan perkirakan biaya dan jadwal pembelian maka salah solusi dapat berupa pembelian, peminjaman, hibah.
Perincian KerjaÆ Menggambarkan detail aktivitas, keterhubungannya satu sama lain dan identifikasi milestones dan deliverables bidang yang harus ada untuk tiap aktivititas.
Penjadwalan Proyek Æ Menggambarkan kebergantungan antar aktivitas dan perkirakan waktu yang dibutuhkan untuk tiap pekerjaan beserta penempatan para pelaku sistem (handler)
Mekanisme Pengawasan dan Pelaporan Æ Merupakan laporan-laporan yang
harus dihasilkan dan mekanisme pengawasan yang akan digunakan
Aktivitas Perencanaan Proyek Software 1. Ruang lingkup Software
2. Estimasi resources
Ruang Lingkup Software
Ruang lingkup Software menggambarkan : data dan kendali yang di proses, fungsi, kinerja, batasan, interface dan reliabilitas. Fungsi yang digambarkan dalam statemen ruang lingkup dievaluasi untuk memberikan awalan yang lebih detail pada saat dimulai estimasi.
Informasi yang dibutuhkan (awal pertemuan antara pelanggan dan developer)
* Pertanyaan berfokus pada pelanggan, tujuan keseluruhan sistem serta keuntungan. - Siapa di belakang permintaan kerja ini?
- Siapa yang akan memakai sistem ini?
- Apakah keuntungan ekonomi dari sistem yang sukses? - Adakah sumber daya lain bagi sistem ini?
* Pertanyaan memungkinkan analisis masalah tentang sebuah solusi
- Bagaimana pelanggan menngenal output yang akan dihasilkan dengan suatu solusi?
- Masalah apa yang diinginkan solusi ini?
- Dapatkah anda menggambarkan lingkungan dimana solusi akan dipakai? - Adakah batasan atau isu kinerja khusus yang akan mempengaruhi
Software berinteraksi dengan sistem berbasis komputer. Konsep interface diinterpretasi untuk menentukan :
1. Hardware yang mengeksekusi Software dan device yang dikontrol secara tidak langsung oleh Software
2. Software yang sudah ada dan harus dihubungkan dengan Software yang baru 3. Manusia yang menggunakan Software melalui keyboard atau perangkat I/O lain 4. Prosedur
SUMBER DAYA 1. Manusia
2. Software
Kategori yang diusulkan BEUNATAN - Komponen Off-the-self
- Komponen Full-Experience - Komponen Partial-Experience - Komponen Baru
3. Lingkungan (Software Engineering Environment-SEE), menggabungkan Perangka Luak dan Perangkat Keras.
Estimasi biaya dan usaha dapat dilakukan dengan cara :
1. Mengakumulasi biaya mulai awal sampai akhir proyek setelah proyek tersebut selesai dilakukan
2. Berdasarkan estimasi biaya pada proyek yang mirip sebelumnya.
3. Menggunakan ”teknik dekomposisi” yang relatif sederhana untuk estimasi biaya dan usaha proyek.
4. Menggunakan satu atau lebih model empiris bagi estimasi usaha dan biaya erangkat lunak
Akurasi estimasi proyek perangkat didasarkan pada :
1. Tingkat dimana perencanan telah dengan tepat mengestimasi ukuran produk yang akan dibuat.
2. Kemampuan mengestimasi ukuran ke dalam kerja manusia, waktu kalender, dan modal.
3. Tingkat dimana rencana proyek mencerminkan kemampuan tim Software
Langkah perencanaan sebagai berikut : 1. Pendefinisian masalah
2. Pengembangan strategi (problem solving) 3. Rencana proses pengembangan.
A. Pendefinisian Masalah
1. Penotasian masalah jelas dan tegas, termasuk didalamnya batasan masalah dan sasaran yang ingin dicapai. Pernyataan masalah ditetapkan dalam sudut pandang pelanggan.
• Pernyataan masalah dari sudut pelanggan misalnya : masalah penggajian, masalah inventory, atau masalah pengendalian lalu lintas udara
• Pernyataan masalah dalam sudut pengembang misalnya : masalah relational data bases, masalah algoritma sorting (indeks), algoritma searching, masalah visual display, sikuensi (urutan) proses.
• Teknik-teknik yang digunakan untuk mendapatkan data/ informasi kebutuhan pelanggan meliputi : wawancara dengan pelanggan, pengamatan terhadap gugus tugas yang bermasalah, kinerja sebenarnya dari gugus tugas.
2. Penetapan strategi solusi berbasis komputer.
• Solusi harus ekonomis dan dapat diterima secara sosial maupun secara politik.
• Solusi yang ekonomis adalah sistem komputerisasi yang memberikan pelayanan dan informasi yang sama dengan sistem lama tetapi membutuhkan waktu dan personal yang lebih sedikit dalam pengoperasiannya.
• Sistem baru mungkin akan mengurangi keterlibatan personal; hal ini mungkin akan menimbulkan dampak sosial, bahkan politik.
3. Identifikasi resource (Hardware, Software, Brainware)
• Tiga subsistem dalam sistem komputerisasi adalah : perangkat keras, Software, dan personal. Identifikasi juga keterkaitan antar ketiga subsistem tersebut.
• Subsistem perangkat keras meliputi perangkat keras beserta periferalnya, dan dalam beberapa kasus juga meliputi peralatan lain seperti sensor kendali proses, antena, dan radar.
• Subsistem Software meliputi Software yang akan dikembangkan ditambah dengan Software yang ada yang boleh jadi digunakan seadanya atau dalam versi modifikasinya.
• Subsistem personal meliputi para operator, pemelihara, dan end user.
4. Penetapan sasaran dan prasyarat, baik untuk proses pengembangan maupun produk.
• Sasaran adalah tujuan yang ingin dicapai. Sasaran digunakan sebagai dasar bagi kerangka kerja proyek pengembangan Software, baik dalam proses pengembangan maupun untuk produk kerja.
• Sasaran dapat dinyatakan secara kualitatif maupun kuantitatif. Contoh :
♦ Proses (kualitatif) : harus meningkatkan keterampilan personal
♦ Proses (kuantitatif) : sistem harus selesai dalam 12 bulan
♦ Produk (kualitatif) : sistem harus membuat pekerjaan user maikin menarik
♦ Produk (kuantitatif) : sistem harus mengurangi biaya transaksi sebesar 25%.
• Prasyarat menetapkan spesifikasi kemampuan sistem dalam menyelesaikan masalah.
• Prasyarat mencakup aspek : fungsional, kinerja, perangkat keras, Software, personalia dan interface.
• Kalau memungkinkan, nyatakan persyaratan secara kuantitaif untuk menghindari ketidakjelasan dan perselisihan antara pengembang dengan pelanggan.
♦ Akurasi sudut fase harus berada pada kisaran 0.5 derajat
♦ Tanggapan maksimum terhadap interrup adalah 0.25 detik
♦ Space maksimum yang digunakan sistem adalah 50 KB memori utama, tidak termasuk space untuk file-file buffer
♦ Sistem harus dapat beroperasi dengan kemampuan 95% ketika dioperasikan selama 24 jam penuh
• Contoh Prasyarat kualitatif :
♦ Akurasi harus cukup tinggi
♦ Sistem harus mempunyai tanggapan yang baik
♦ Sistem harus hemat dalam penggunaan memori utama
♦ Keandalan sistem harus 99%
• Sasaran dan persyaratan dapat juga ditetapkan melalui atribut-atribut kualitas yang harus dimiliki sistem, di antaranya : portability (S/W tidak bergantung mesin), realiability (kemampuan program melakukan fungsi yang diinginkan), efficiency (menggunakan sumber daya minimal), accuracy (ukuran besarnya error), robustness/integrity (kemampuan bekerja dengan baik walau mendapat input yang tidak benar), correctness (hasil sesuai dengan yang diharapkan). 5. Tetapkan kriteria penerimaan sebuah sistem
• Kriteria harus dinyatakan sedemikian rupa sehingga tidak akan menimbulkan perselisihan antara pengembang dan pelanggan. Kriteria harus dapat diverfikasi dengan suatu metoda baku seperti : peninjauan langsung, analisa, atau serangkaian uji, terhadap produk yang dihasilkan.
B. Pengembangan Strategi Solusi (Problem Solving)
• Kecenderungan mengarah pada buah pikiran sebagai masalah utama dalam perekayasaan software, ini tidak memberi peluang terhadap solusi lain yang sebenarnya masih mungkin untuk dipertimbangkan.
• Pengembangan strategi solusi secara rinci untuk setiap modul
• Menetapan langkah-langkah pengembangan strategi solusi adalah sebagai berikut : 1. Penguraian strategi solusi tanpa memperdulikan batasan-batasan apapun
2. Melakukan studi kelayakan terhadap masing-masing. Perhatikan bahwa an unreasonable idea will lead to other ideas, some of which may be very reasonable.
3. Rekomendasikan sebuah strategi solusi, beri catatan mengapa solusi lain ditolak 4. Membuat daftar prioritas baik kerja maupun produk. Daftar ini penting jika
kondisi tidak memungkinkan untuk mengimplementasikan seluruh kemampuan produk yang diinginkan seperti yang telah ditentukan sebelumnya.
C. Perencanaan Proses Pengembangan
1. Buat model system development life-cycle(SDLC) dan struktur organisasi proyek. 2. Buat konfigurasi manajemen, jaminan kualitas dan validasi
3. Siapkan tools untuk setiap fase proyek 4. Buat perkiraan biaya
5. Buat jadwal pengembangan
6. Buat perkiraan susunan personalia proyek
7. Buat perkiraan resource yang akan mengoperasikan dan memelihara sistem 8. Buat daftar istilah
BAB VI
JAMINAN KUALITAS SOFTWARE
Jaminan kualitas Software (Software Quality Assurance [SQA]) adalah aktivitas
pelindung yang diaplikasikan pada seluruh proses Software. SQA meliputi : 1. Pendekatan manajemen kualitas
2. Teknologi rekayasa Software yang efektif (metode dan peranti)
3. Kajian teknik formal yang diaplikasikan pada keseluruhan proses Software 4. Strategi pengujian multitiered (deret bertingkat)
5. Kontrol dokumentasi Software dan perubahan
6. Prosedur untuk menjamin kesesuaian dengan standar pengembangan Software 7. Mekanisme pengukuran dan pelaporan.
Tujuan jaminan kualitas adalah :
Untuk memberikan data yang diperlukan oleh manajemen untuk menginformasikan masalah kualitas produk, sehingga dapat memberikan kepastian dan konfidensi bahwa kulitas produk dapat memenuhi sasaran.
KUALITAS SOFTWARE
Kualitas Software 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 Software dikembangkan secara profesional.
Definisi tersebut berfungsi untuk menekankan tiga hal penting, yaitu:
1. Kebutuhan Software merupakan fondasi yang melaluinya kualitas diukur. 2. Standar yang telah ditentukan menetapkan serangkaian kriteria pengembangan
yang menuntun cara Software direkayasa.
3. Ada serangkaian kebutuhan implisit yang sering dicantumkan (misalnya kebutuhan akan kemampuan pemeliharaan yang baik).
Kontrol kualitas merupakan serangkaian pemeriksaan, kajian, dan pengujian yang digunakan pada keseluruhan siklus pengembangan untuk memastikan bahwa setiap produk memenuhi persyaratan yang ditetapkan.
Konsep kunci kualitas kontrol adalah bahwa semua produk kerja memiliki spesifikasi yang telah ditentukan dan dapat diukur dimana kita dapat membandingkan output dari setiap proses.
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 : a. Pencegahan
b. Penilaian c. Kegagalan.
a) Biaya pencegahan meliputi :
• Kajian teknis formal
• Perlengkapan pengujian
• Pelatihan
b) Biaya penilaian meliputi :
• Inspeksi in-proses dan interproses
• Pemeliharaan dan kalibrasi peralatan
• Pengujian c) Biaya kegagalan
Biaya kegagalan adalah biaya yang akan hilang bila tidak ada cacat yang muncul sebelum produk disampaikan kepada pelanggan.
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.
Biaya kegagalan eksternal meliputi:
• Resolusi keluhan
• Penggantian dan pengembalian produk
• Dukungan help line
• Kerja jaminan
Biaya relatif mendapatkan dan membetulkan cacat bertambah secara dramatis pada saat kita melangkah dari pencegahan ke pendeteksian dan dari kegagalan internal ke kegagalan eksternal.
BAB VII
PRINSIP DAN KONSEP DESAIN
Desain adalah langkah pertama dalam fase pengembangan bagi setiap produk atau sistem yang direkayasa. Perancangan merupakan penghubung antara spesifikasi kebutuhan dan implementasi.
Tujuan perancangan Software :
Memperbaiki kualitas produk software, meningkatkan produktivitas serta memuaskan teknisi Software.
Menghasilkan model atau representasi entitas yang akan dibangun.
Terdapat tiga karakteristik yang berfungsi sebagai pedoman bagi evaluasi suatu desain yang baik, yaitu :
1. Desain harus mengimplementasikan keseluruhan persyaratan eksplisit yang dibebankan dalam model analisis dan harus mengakomodasi semya persyaratan implicit yang diinginkan pelanggan
2. Desain harus menjadi panduan yang dapat dibaca, dipahami abgi mereka yang menghasilkan kode dan yang menguji serta memelihara Software
3. Desain harus memberikan suatu gambaran lengkap mengenai Software yang menekankan data, dan domain perilaku dari perspektif implementasi
Evolusi Perancangan
Suatu proses kontinu yang terus berlangsung selama tiga dekade.
Kerja desain awal dikonsentrasikan pada kriteria untuk pengembangan program moduler dan metode-metode untuk menyaring arsitektur Software dalam cara top-down.
Aspek procedural dari definisi desain yang tercakup dalam suatu filosofi disebut pemrograman terstruktur.
Usaha selanjutnya mengusulkan metode-metode translasi aliran data atau struktur data ke dalam definisi desain.
Fungsi Proses Perancangan
Pengembangan spesifikasi Software
Penjabaran fungsi software
Penjabaran implementasi spesifikasi Software
Prinsip Desain Menurut Davis :
1. Proses desain tidak boleh menderita karena “tunnel vision” (kaca mata kuda) 2. Desain harus dapat ditelusuri sampai model analisis
3. Desain tidak boleh “berulang”
4. Meminimalkan “kesenjangan intelektual” diantara software dan masalah yang ada di dunia nyata
5. Desain harus mendeskripsikan keseragaman dan integrasi 6. Desain harus terstruktur dan dapat mengakomodasi perubahan.
7. Desain harus terstruktur untuk berdegradasi berbagai persoalan dengan baik, bahkan pada saat data dan event-event menyimpang, atau menghadapi kondisi operasi.
8. Desain bukanlah pengkodean dan pengkodean bukanlah desain
9. Desain harus dinilai kualitasnya pada saat desain dibuat, bukan setelah jadi 10.Desain harus dikaji untuk meminimalkan berbagai kesalahan konseptual
Konsep Desain Abstraksi
Saat mempertimbangkan solusi modular terhadap setiap masalah, banyak tingkat abtraksi yang dapat diperoleh.
Abstrak Data adalah nama koleksi data yang menggambarkan objek data
Abstrak Prosedur adalah nama rangkaian tindakan yang telah memiliki fungsi terbatas dan khusus.
Abstrak Kendali abstrak koordinasi aktivitas.
Stepwise Refinement (Penghalusan)
Modularitas
Perangakt lunak monolitik (yankti program besar yang terdiri dari modul tunggal) tidak dapat dipahami dengan mudah oleh pembaca.
Software diorganisasikan secara modular agar dapat diatur.
Arsitektur Software
Mencakup struktur keseluruhan Software dan cara di mana struktur memberikan integrasi konseptual bagi suatu sistem.
Arsitektur program struktural adalah pengorganisasian komponen program secara hirarki, sehingga pada pengorganisasian itu komponen program dapat berinteraksi dan menyatakan struktur data yang dipakai oleh komponen.
Hirarki Kendali
Merepresentasikan organisasi(seringkali secara hirarkis) komponen program (modul) serta mengimplikasikan suatu hirarki kontrol.
Hubungan kontrol di antara modul diekspresikan dengan cara :
9 Modul yang mengontrol modul lain disebut superordinat
9 Modul yang dikontrol disebut dengan subordinat
Partisi Struktural
Jika arsitektur program bersifat hirarki, struktur program dapat dipartisi secara horisontal ataupun vertikal. Partisi horizontal mendefinisikan modul yang berbeda menjadi fungsi utama program. Partisi vertikal mendefinisikan modul kendali
Partisi Horisontal. Cara mudah mempartisi horisontal adalah membagi struktur program menjadi fungsi input, transformasi dan output.
Partisi Vertikal. Sering disebut factoring, terdapat modul kontrol dan modul pekerja didistribusikan secara top-down.
Struktur Data
Representasi dari hubungan logis antara elemen-elemen data infividual.
Struktur data menentukan Organisasi, metode akses, tingkat asosiativitas dan alternatif pemrosesan untuk informasi.
Prosedur
Berfokus pada detail-detail pemrosesan dari masing-masing modul secara individual.
Prosedur harus memberikan spesifikasi yang terliti terhadap pemrosesan, mencakup urutan event, poin keputusan nyata, operasi repetitif dan bahkan organisasi/struktur data.
Penyembunyian Informasi
Penyembunyian informasi mengimplikasikan bahwa modularitas efektif dapat dicapai dengan menetapkan serangkaian modul yang independen yang berkomunikasi satu dengan yang lainnya di mana hanya informasi itu yang diperlukan untuk mencapai fungsi Software.
BAB VIII
METODE DESAIN SISTEM
1. Desain Data
Desain data adalah aktivitas pertama dari empat aktivitas desain yang dilakukan selama perancangan Software.
Memilih representasi logis dari objek data (struktur data) yang diidentifikasi selama tahap definisi, persyaratan dan spesifikasi.
Sesuai dengan struktur program/ modularitas serta dapat mengurangi kompleksitas procedur
Mentransformasikan domain informasi pada struktur data yang digunakan untuk implementasi program, ERD yang dibuat dalam fase analisa sebagai basis untuk mendisain data
Hasil disain data berupa :
Struktur Data
Basis Data
Prosedur/ operasi data / Algoritma
2. Desain Arsitektur Tujuan :
Membangun struktur program modular dan merepresentasikan hubungan antar modul.
Integrasi struktur program sesuai dengan struktur data dan pendefinisian interface untuk menjamin aliran data terdistribusi pada seluruh modul program
Pada perancangan arsitektur memuat proses yaitu merubah aliran dari aliran informasi (DFD) menjadi struktur P/L (Structure Chart)
3. Desain Interface
Software dapat berkomunikasi baik pada dirinya sendiri, sistem lain dan pengguna.
Area desain interface adalah :
9 Antara modul Software
9 Software dengan produser atau konsumen.
9 User dan Komputer
Jenis antarmuka yang diperlukan
Untuk input parameter-parameter proses
Untuk output proses
Untuk input data
Untuk output data
Untuk pesan-pesan
Hal penting dalam perancangan antarmuka
Pelihara konteks visual
Pesan kesalahan harus berarti
Minimalkan jumlah aksi masukan yang diperlukan
Perancangan antar muka dapat dilakukan secara :
Manual, dilakukan pada kertas
Bantuan alat berupa software
Hasil dari perancangan antarmuka, yaitu :
Definisi antarmuka modul yang siap untuk deprogram
Definisi/format rancangan yang siap diimplementasikan
4. Desain Prosedural
Tahapan akhir dari perancangan
Membentuk algoritma yang memenuhi aspek berikut : Struktur data diterapkan pada perancangan data
Struktur modul kendali pada struktur chart hasil perancangan arsitektur
Rancangan menu dan format outputrancangan
Tanpa ada ambiguitas
Pengembangan teknik ke arah pemrograman terstruktur
Dua hal yang perlu di perhatikan pada perancangan ini, yaitu :
Coupling merupakan ukuran kekuatan yang saling ketergantungan diantara modul-modul software
Cohesion merupakan ukuran kekuatan modul-modul software secara fungsional relatif terhadap modul software itu sendiri
Tools yang dapat digunakan : - Flowchart (Bagan Alur)
- Algoritma berupa pseudocode atau program design language
Masalah umum pada desain : Waktu respon sistem
Fasilitas Help
Penanganan Error
Label Instruksi
Contoh :
DFD Level 0
DFD Level 1: Proses Pembayaran Biaya Pendidikan
Perancangan File
1. Rancangan File Pendaftaran
NDCS Nama Tg_lahir Tp_lahir Jk Agama Alamat Kelas
NDCS = 1{karakter}9 Nama = 1{karakter}30 Tg_lahir = *date*
Tp_lahir = 1{karakter}30 Jk = 1{karakter}
Agama = 1{karakter}10 Alamat = 1{karakter}35 Kelas = 1{karakter}10
2. Rancangan File Biaya Pendaftaran
NDCS Nama Biaya
NDCS = 1{karakter}9 Nama = 1{karakter}30 Biaya = 1{numeric}7 Alamat = 1{karakter}35 Telp = 1{Karakter}12
3. Daftar Nilai
NIS PELAJARAN…. ………. PELAJARAN…
NIS = 1 {karakter} 9
PELAJARAN… = 1 {numerik}2
Data Siswa
NIS Nama Tg_lahir Tp_lahir Jk Agama Alamat Telp Kelas
NIS = 1{karakter}9 Nama = 1{karakter}30 Tg_lahir = *date*
Tp_lahir = 1{karakter}30 Jk = 1{karakter}
4. Biaya Sekolah
NIS Nama Biaya
NIS = 1{karakter}9 Nama = 1{karakter} 30 Biaya = 1{numerik} 7 Alamat = 1{karakter} 35 Telp = 1{karakter} 12
Laporan Pendaftaran Siswa
Laporan Data Pendaftaran Siswa Baru Tahun: xxxx/9999
Nomor Daftar Calon Siswa
Nama Tanggal lahir
Tempat lahir
Jenis
Kelamin Agama Alamat Kelas
Laporan Pembayaran Biaya Pendaftaran
Laporan Pembayaran Biaya Pendaftaran Siswa Baru Tahun: xxxx/9999
NDCS Nama Biaya Kelas
Laporan Nilai
Laporan Nilai Siswa Tahun: xxxx/9999
Laporan Data Siswa
Laporan Data Siswa Tahun: xxxx/9999
NIS Nama Tanggal
Lahir
Tempat Lahir
Jenis
Kelamin Agama Alamat Telp Kelas
Laporan Pembayaran Uang Sekolah
Laporan Pembayaran Uang Sekolah Tahun: xxxx/9999
NIS Nama Biaya Kelas
Data uang pendaftaran
Data siswa
BAB IX
PENGUJIAN SOFTWARE
Definisi
Pengujian adalah proses pemeriksaan atau evaluasi sistem atau komponen sistem secara manual atau otomatis untuk memverifikasi apakah sistem memenuhi kebutuhan yang di spesifikasikan atau mengidentifikasikan perbedaan-perbedaan antara yang diharapkan dengan hasil yang terjadi baik ketangguhan ataupun kelemahan.
Proses eksekusi suatu program dengan maksud menemukan kesalahan
Merupakan elemen kritis dari jaminan kualitas Software dan merepresentasikan kajian pokok dari spesifikasi, desain dan pengkodean.
Meningkatnya visibilitas Software sebagai suatu elemen sistem dan “biaya” yang muncul akibat kegagalan Software memotivasi di lakukan perencanaan yang baik melalui pengujian yang teliti.
Pengujian meliputi tiga konsep :
Demonstrasi validitas software pada masing-masing tahap di siklus pengembangan system
Penentuan validitas sistem akhir dikaitkan dengan kebutuhan pemakai
Pemeriksaan perilaku sistem dengan mengeksekusi sistem pada data sample pengujian
Dasar pengujian software
Sebelum proses software, developer membangun dari konsep abstrak ke implementasi yang dapat dilihat, baru kemudian dilakukan pengujian.
Perekayasa menciptakan Test Case untuk “membongkar” Software yang sudah di bangun.
Tahap pengujian ini pada dasarnya di anggap destruktif dari pada konstruktif
Uji coba software terdapat 2 masalah pokok yaitu : A. Teknik uji software
B. Strategi uji software
Sasaran dan Prinsip Pengujian
Menurut Glen Myers Sasaran Pengujian, yaitu :
1. Pengujian proses eksekusi program untuk menemukan kesalahan.
2. Test case yang baik adalah yang memiliki probabilitas dalam menemukan kesalahan yang belum pernah ditemukan sebalumnya.
3. Pengujian yang sukses adalah bila dapat mengungkap semua kesalahan baik sifatnya implisit maupun eksplisit
Prinsip Pengujian menurut Davis :
• Semua pengujian harus dapat ditelusuri sampai ke persyaratan pelanggan.
• Pengujian harus direncanakan lama sebelum pengujian itu dimulai.
• Prinsip Pareto berlaku untuk pengujian software. Prinsip Pareto mengimplikasikan 80% dari semua kesalahan yang ditemukan selama pengujian sepertinya akan dapat ditelusuri sampai 20% dari semua modul program.
• Pengujian harus mulai "dari yang kecil" dan berkembang ke pengujian "yang besar".
• Pengujian yang mendalam tidak mungkin.
Sub-system
Motivasi Pengujian : Acceptance Testing
Defect Testing.
Tahap Pengujian : Perencanaan Pengujian
Perancangan Pengujian
Eksekusi Pengujian
Analisis Hasil Pengujian
Kesalahan Pengujian :
Kesalahan fungsional (functional error) : program bertindak di luar perencanaan
Kesalahan kehilangan (missed error) : fungsi yang diperlukan tidak ada/ tidak tersedia
Kesalahan memanifestasi (manifestation error) : terjadi penghentian program tidak normal
Proses Pengujian
Unit Testing : pengujian komponen yang bersifat individu
Modul Testing : pengujian komponen yang saling berhubungan,
Sub-system Testing : pengujian modul yang berhubungan khususnya interface.
System Testing : pengujian keseluruhan sistem,
Acceptance Testing : pengujian sistem yang dapat diterima dan kemudahan penggunaannya (easy of use).
Component testing :
Pengujian komponen program
Pengujian komponen developer (kecuali system kritis) Integration testing :
Pengujian kelompok komponen yang terintegrasi yang membentuk sub-system serta aspek pendukungnya
Pengujian tim penguji (independent)
Pengujian spesifikasi sistem User Testing
Design test Proses Defect Testing
Test cases : penggunaan input yang sesuai untuk menguji sistem dan memprediksi output sesuai dengan spesifikasi.
Test data : pengujian Input yang digunakan sistem.
Test Results : output yang ada sesuai dengan pemrosesan input
Test Reports : Laporan sesuai dengan pemrosesan input menjadi output
Testabilitas
Maksudnya adalah seberapa mudah program dapat diuji sehingga perlu diupayakan trik untuk membuat pengujian menjadi mudah.
Karakteristik Software yang diuji :
• Operabilitas, semakin baik dia bekerja semakin efisien dia dapat diuji.
• Observabilitas, apa yang anda lihat adalah apa yang anda uji.
• Kontrolabilitas, semakin baik kita dapat mengontrol PL semakin banyak pengujian yang adapat diotomatisasi dan dioptimalkan.
• Dekomposabilitas, dengan mengontrol ruang lingkup pengujian kita dapat lebih cepat mengisolasi masalah dan melakukan pengujian kembali.
• Kesederhanaan, semakin sedikit yang diuji semakin cepat pengujian.
• Stabilitas, semakin sedikit perubahan semakin sedikit gangguan pengujian.
• Kemampuan dipahami, semakin banyak informasi yang dimiliki semakin detail pengujiannya.
Atribut Pengujian Yang Baik :
• Memiliki probabilitas yang tinggi menemukan kesalahan.
• Tidak redundan.
• Harusnya ‘jenis terbaik’.
• Tidak boleh terlalu sederhana atau terlalu kompleks.
Desain Test Case
Terdapat bermacam-macam rancangan metode test case yang dapat digunakan, semua menyediakan pendekatan sistematis untuk uji coba, yang terpenting metode menyediakan kemungkinan yang cukup tinggi menemukan kesalahan.
Terdapat 2 macam test case:
1. Pengetahuan fungsi yang spesifik dari produk yang telah dirancang untuk diperlihatkan, test dapat dilakukan untuk menilai masing-masing fungsi apakah telah berjalan sebagaimana yang diharapkan.
2. Pengetahuan tentang cara kerja dari produk, test dapat dilakukan untuk
TEKNIK PENGUJIAN
Dua macam pendekatan test yaitu : 1. Black Box Testing
Merupakan fungsi software tentang cara beroperasi, apakah input data sesuai (relevan) dengan output serta informasi yang tersimpan sesuai fakta sistem berjalan.
2. White Box Testing
Merupakan aktivitas meramal (estimasi) tentang cara kerja software secara rinci berdasarkan logical path (jalur logika). Software ditest dengan menyediakan test case yang mengerjakan kumpulan kondisi ataupun pengulangan. Dengan demikian bahwa white box testing merupakan petunjuk untuk mendapatkan running program yang benar secara 100%.
PENGUJIAN WHITE BOX
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
1. Pengujian Basis Path
Uji coba basis path adalah teknik uji coba white box yang diusulkan Tom McCabe yang memungkinkan perancang test case mendapatkan ukuran kekompleksan logical dari perancangan prosedural dan sebagai petunjuk mendefinisikan basis set dari jalur pengerjaan. Test case yang didapat digunakan untuk mengerjakan basis set yang menjamin pengerjaan setiap perintah minimal satu kali selama uji coba.
Notasi diagram alir
Sebelum metode basis path dapat diperkenalkan, notasi sederhana untuk representasi aliran kontrol yang disebut diagram alir (atau grafik program) harus diperkenalkan. Pada gambar dibawah ini masing-masing lingkaran disebut simpul grafik alir, yang merepresentasikan satu atau lebih statemen prosedural. Anak panah pada grafik alir tersebut yang disebut edges atau links, merepresentansikan aliran kontrol dan analog dengan anak panah bagan alir. Edges harus berhenti pada suatu simpul, meskipun bila simpul tersebut tidak merepresentasikan statemen prosedural (seperti if-then-else). Area yang dibatasi oleh edge dan simpul disebut region.
Sequence if while until case
Untuk menggambarkan pemakaian diagram alir diberikan contoh perancangan prosedural dalam bentuk flowchart
Selanjutnya diagram alir di atas dipetakan ke grafik alir Gambar Grafik Alir
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 yang dibatasi oleh edge dan node. Termasuk daerah diluar grafik alir.
Contoh menterjemahkan pseudo code ke grafik alir 1: do while record masih ada
baca record 2: if record ke 1 = 0 3: then proses record
simpan di buffer naikan kounter 4: else if record ke 2 = 0 5 then reser kounter 6 proses record
simpan pada file 7a: endif
endif 7b: enddo 8 : end
2. Pengujian Struktur Kontrol
3. Pengujian Kondisi
Merupakan sebuah metode desain test case yang menggunakan kondisi logis yang ada pada suatu program. Kondisi sederhana adalah variable Boolean atau suatu persamaan hubungan, dapat didahului dengan satu operator NOT.
Bila terdapat suatu kondisi tidak benar, maka paling tidak satu komponen dari kondisi tersebut salah. Dengan demikian tipe kesalahan dalam kondisi meliputi :
• Kesalahan operator Boolean (ada operator Boolean yang salah/hilang/ekstra)
• Kesalahan variable Boolean
• Kesalahan tanda kurung Boolean
• Kesalahan operator relasional
• Kesalahan persamaan aritmatika
Metode pengujian kondsi berfokus pada pengujian masing-masing kondisi dalam program. Metode ini mempunyai dua keuntungan yaitu :
• Pengukuran kupasan pengujian dari satu kondisi adalah sederhana
• Cakupan pengujian terhadap kondisi di dalam suatu program memberikan pedoman untuk melkaukan pengujian tambahan untuk program tersebut.
Tujuan pengujian kondisi adalah mendeteksi tidak hanya kesalahan di dalam kondisi program, tetapi juga kesalahan lain pada program.
4. Pengujian Aliran Data
Metode ini memilih jalur pengujian dari suatu program sesuai dengan lokasi definisi dan menggunakan variable-variabel pada program.
Strategi pengujian aliran data berguna untuk memilih jalur pengujian dari suatu program yang berisi statemen if dan loop yang tersarang
Pengujian Loop
Algoritma yang diimplementasikan pada software merupakan teknik pengujian white-box ekslusif untuk validitas konstruksi loop. Empat kelas loop yang didefinisikan :
• Loop sederhana
• Loop terangkai
• Loop tersarang (nested loop)
• Loop tidak terstruktur
PENGUJIAN BLACK-BOX
Pengujian black-box berfokus pada persyaratan fungsional PL. Pengujian inimemungkinkan analis system memperoleh kumpulan kondisi input yang akan mengerjakan seluruh keperluan fungsional program.
Tujuan metode ini mencari kesalaman pada:
• Fungsi yang 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.
Pengujian dirancang untuk menjawab pertanyaan sbb:
• Bagaimana validitas fungsional diuji?
• Apa kelas input yang terbaik untuk uji coba yang baik?
• Apakah sistem sangat peka terhadap nilai input tertentu?
• Bagaimana jika kelas data yang terbatas dipisahkan?
• Bagaimana volume data yang dapat ditoleransi oleh sistem?
• Bagaimana pengaruh kombinasi data terhadap pengoperasian system?
1. EQUIVALENCE PARTITIONING
Equivalence partitioning adalah metode pengujian black-box yang memecah atau membagi domain input dari program ke dalam kelas-kelas data sehingga test case dapat diperoleh.
Perancangan test case equivalence partitioning berdasarkan evaluasi kelas equivalence untuk kondisi input yang menggambarkan kumpulan keadaan yang valid atau tidak. Kondisi input dapat berupa nilai numeric, range nilai, kumpulan nilai yang berhubungan atau kondisi Boolean.
Contoh :
Pemeliharaan data untuk aplikasi bank yang sudah diotomatisasikan. Pemakai dapat memutar nomor telepon bank dengan menggunakan mikro komputer yang terhubung dengan password yang telah ditentukan dan diikuti dengan perintah-perintah. Data yang diterima adalah :
Kode area : kosong atau 3 digit
Prefix : 3 digit atau tidak diawali 0 atau 1 Suffix : 4 digit
Password : 6 digit alfanumerik
Perintah : check, deposit, dan lain-lain
Selanjutnya kondisi input digabungkan dengan masing-masing data elemen dapat ditentukan sbb :
Kode area : kondisi input, Boolean – kode area mungkin ada atau tidak kondisi input, range – nilai ditentukan antara 200 dan 999 Prefix : kondisi input range > 200 atau tidak diawali 0 atau 1 Suffix : kondisi input nilai 4 digit
Password : kondisi input boolean – pw mungkin diperlukan atau tidak kondisi input nilai dengan 6 karakter string
2. BOUNDARY VALUE ANALYSIS
Untuk permasalahan yang tidak diketahui dg jelas cenderung menimbulkan kesalahan pada domain outputnya. BVA merupakan pilihan test case yang mengerjakan nilai yang telah ditentukan, dgn teknik perancangan test case melengkapi test case equivalence partitioning yang fokusnya pada domain input. BVA fokusnya pada domain output.
Petunjuk pengujian BVA :
1. Jika kondisi input berupa range yang dibatasi nilai a dan b, test case harus dirancang dgn nilai a dan b.
2. Jika kondisi input ditentukan dgn sejumlah nilai, test case harus dikembangkan dgn mengerjakan sampai batas maksimal nilai tsb.
3. Sesuai petunjuk 1 dan 2 untuk kondisi output dirancang test case sampai jumlah maksimal.
4. Untuk struktur data pada program harus dirancang sampai batas kemampuan.
PENGUJIAN UNTUK APLIKASI DAN LINGKUNGAN KHUSUS PENGUJIAN GUI
Grafical User Interface(GUIs) menyajikan tantangan yang menarik bagi para perekayasa. Karena komponen reusable berfungsi sebagai bagian dari lingkungan pengembangan GUS, pembuatan interface pemakai telah menjadi hemat waktu dan lebih teliti.
Pertanyaan berikut ini dapat berfungsi sebagai panduan untuk serangkaian pengujian generik untuk GUI :
Untuk Windows
o Apakah window akan membuka secara tepat berdasarkan tipe yang sesuai
atau perintah berbasis menu ?
o Dapatkan windows di resize digerakkan, atau digulung ?
Untuk Menu Pull-down
o Apakah menu bar yang sesuai ditampilkan di dalam konteks yang sesuai ? o Apakah menu bar aplikasi menampilkan fitur-fitur yang terkait dengan
sistem (misal tampilan jam) ?
o Apakah operasi menu pull down bekerja secara tepat ?
o Apakah menu breakway, palette, dan tool bar bekerja secara tepat ? o Apakah semua fungsi menu dan subfungsi pull-down didaftar secara tepat o Mungkinkah memanggil masing-masing fungsi menu dengan menggunakan
perintah berbasis teks alternatif ?
o Apakah help dapat diperoleh untuk masing-masing item menu, apakah dia
sensitif terhadap konteks ?
o Apakah operasi mouse dikenali dengan baik pada seluruh konteks interaktif
?
Entri Data
o Apakah entri data alfanumeris dipantulkan dan diinput ke sistem ? o Apakah mode grafik dari entri data bekerja dengan baik ?
o Apakah data invalid dikenali dengan baik ?
Apakah pesan input data sangat pintar ?
BAB X
Strategi uji coba PL memudahkan para perancang untuk menentukan keberhasilan system yang telah dikerjakan. Hal yang harus diperhatikan adalah langkah-langkah perencanaan dan pelaksanaan harus direncanakan dengan baik dan berapa lama waktu, upaya dan sumber daya yang diperlukan.
Strategi uji coba mempunyai karakteristik sbb :
• Pengujian mulai pada tingkat modul yang 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 Software 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 (Vdan V).
Verifikasi : Kumpulan aktifitas yang menjamin penerapan PL benar-benar sesuai dgn fungsinya.
Validasi : Kumpulan aktivitas yang berbeda yang memastikan bahwa PL yang dibangun dapat memenuhi keperluan pelanggan.
Dengan kata lain :
Verifikasi : “ Apakah kita membuat produk dgn benar?”
Validasi : “ Apakah kita membuat benar-benar suatu produk?”
Definisi dari VdanV meliputi berbagai aktivitas yang kita rujuk sebagai jaminan kualias PL (SQA).
Pengujian merupakan salah satu tugas yang ada dlm arus siklus pengembangan system yang dapat digambarkan dalam bentuk spiral :
1. PENGUJIAN UNIT
Unit testing (uji coba unit) fokusnya pada usaha verifikasi pada unit terkecil dari desain PL, yakni modul. Uji coba unit selalu berorientasi pada white box testing dan dapat dikerjakan paralel ayau beruntun dengan modul lainnya.
Pertimbangan Pengujian Unit
Modul
Struktur data loka l Kon disi batas Jalur independe n
Jalur penanganan ke sal ahan
yang ditentukan untuk membatasi pemrosesan. Semua jalur independen(jalur dasar) yang melalui struktur control dipakai sedikirnya satu kali. Dan akhirnya penanganan kesalan diuji.
Myers mengusulkan checklist untuk pengujian interface:
• Apakah jumlah parameter input sama dengan jumlah argumen?
• Apakah antara atribut dan parameter argumen sudah cocok?
• Apakah antara sistem satuan parameter dan argumen sudah cocok?
• Apakah jumlah argumen yang ditransmisikan ke modul yang dipanggil sama dengan jumlah parameter?
• Apakah atribut dari argumen yang ditransmisikan ke modul yang dipanggil sama dengan atribut parameter?
• Apakah sistem unit dari argumen yang ditransmisikan ke modul yang dipanggil sama dengan sistem satuan parameter?
• Apakah jumlah atribut dari urutan argumen ke fungsi-fungsi built-in sudah benar?
• Adakah referensi ke parameter yang tidak sesuai dengan pain entri yang ada?
• Apakah argumen input-only diubah?
• Apakah definisi variabel global konsisten dengan modul?
• Apakah batasan yang dilalui merupakan argumen?
Bila sebuah modul melakukan I/O ekstemal, maka pengujian interface tambahan harus dilakukan.
• Atribut file sudah benar?
• Pemyataan OPEN/CLOSE sudah benar?
• Spesifikasi format sudah cocok dengan pernyataan I/O?
• Ukuran buffer sudah cocok dengan ukurn rekaman?
• File dibuka sebelum penggunaan?
• Apakah kondisi End-of-File ditangani?
• Kesalahan I/O ditangani?
• Adakah kesalahan tekstual di dalam informasi output?
Kesalahan yang umum di dalam komputasi adalah:
• Kesalah-pahaman atau prosedur aritmatik yang tidak benar
• Operasi mode yang tercampur
• Inisialisasi yang tidak benar
• Inakurasi ketelitian
• Representasi simbolis yang tidak benar dari sebuah persamaan.
Test case harus mengungkap kesalahan seperti
• Perbandingan tipe data yang berbeda
• Pengharapan akan persamaan bila precision error membuat persamaan yang tidak mungkin
• Perbandingan atau variabel yang tidak benar
• Penghentian loop yang tidak ada atau tidak teratur
• Kegagalan untuk keluar pada saat terjadi iterasi divergen
• Variabel loop yang dimodifikasi secara tidak teratur.
Prosedur Pengujian Unit
Program sumber telah dikembangkan, ditunjang kembali dan diverifikasi untuk sintaksnya, maka perancangan test case dimulai. Peninjauan kembali perancangan informasi akan menyediakan petunjuk untuk menentukan test case. Karena modul bukan program yang berdiri sendiri maka driver (pengendali) dan atau stub PL harus dikembangkan untuk pengujian unit.
Driver adl program yang menerima data untuk test case dan menyalurkan ke modul yang diuji dan mencetak hasilnya.
Stub melayani pemindahan modul yang akan dipanggil untuk diuji.
2. PENGUJIAN INTEGRASI
Pengujian terintegrasi adl teknik yang sistematis untuk penyusunan struktur program, pada saat bersamaan dikerjakan uji coba untuk memeriksa kesalahan yang nantinya digabungkan dengan interface.
Metode pengujian
• Top down integration
• Buttom up integration
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 yang menggantikan seluruh modul yang secara langsung berada di bawah modul kontrol utama.
• Tergantung pada pendekatan perpaduan yang dipilih (depth / breadth)
• Uji coba dilakukan selama masing-masing modul dipadukan
• Pada penyelesaian masing-masing uji coba stub yang lain dipindahkan dgn modul sebenarnya.
• Uji coba regression yaitu pengulangan pengujian untuk mencari kesalahan lain yang mungkin muncul.
Bottom Up Integration
Pengujian buttom up dinyatakan dgn penyusunan yang dimulai dan diujicobakan dgn atomic modul (yi modul tingkat paling bawah pd struktur program). Karena modul dipadukan dari bawah ke atas, proses yang diperlukan untuk modul subordinat yang selalu diberikan harus ada dan diperlukan untuk stub yang akan dihilangkan.
Strategi pengujian :
