BAB 2 ‐ PROSES PENGEMBANGAN PIRANTI LUNAK Proses : Pandangan Umum DEFINISI : Pembangunan dan Pengggunaan prinsip‐prinsip rekayasa dalam rangka mendapatkan perangkat lunak yang ekonomis yang handal dan bekerja efisien pada komputer yang nyata (Fritz Bauer) IEEE Aplikasi pendekatan sistematik, disiplin, terquantifikasi pada pengembangan, operasi, perawatan perangkat lunak, yaitu aplikasi rekayasa pada perangkat lunak Studi pendekatan‐pendekatan di atas TEKNOLOGI BERLAPIS : Rekaya Piranti Lunak 1. Tools 2. Methods 3. Process Model 4. A “quality” focus PANDANGAN UMUM RPL : Rekayasa : analisis, desain, konstruksi, verifikasi, dan manajemen entitas teknis (dan sosial) Problem apa yang harus diselesaikan ? Karakteristik entitias apa yang digunakan untuk menyelesaikan masalah ? Bagaimana entitas (dan solusinya) direalisasikan ? Bagaimana entitas di konstruksi ? Pendekatan apa yang digunakan untuk menemukankesalahan yang dibuat pada desain dan konstruksi entitas ? Bagaimana entitas didukung dalam jangka panjang, dimana koreksi, adaptasi, dan peningkatan selalu diminta pengguna pada entitas TIGA FASE UMUM RPL : Fase definisi, fokus pada pertanyaan “apa” Fase pengembangan, fokus pada pertanyaan “bagaimana” Fase dukungan, fokus pada “perubahan” : Koreksi Adaptasi Peningkatan Pencegahan BINGKAI KERJA PROSES : Bingkai Kerja Proses Aktivitas Bingkai Kerja Tugas‐tugas Produk‐produk milestones & deliverables QA checkpoints Aktivitas Payung AKTIVITAS BINGKAI KERJA : Komunikasi Perencanaan Pemodelan Analisis Kebutuhan Desain Konstruksi Menyusun kode Pengujian Produksi AKTIVITAS PAYUNG : Manajemen Proyek PL Review Teknik Formal Jaminan Mutu PL Manajemen Konfigurasi PL Persiapan dan Produksi Produk Pekerjaan Manajemen Penggunaan Kembali Pengukuran Manajemen Resiko
MODEL PROSES : Adaptabilitas Aktivitas‐aktivitas bingkai kerja akan selalu diaplikasikan pada setiap project, tetapi …. Tugas‐tugas (dan derajat kekakuan) pada setiap aktivitas akan bervariasi bergantung pada : Tipe proyek Karakteristik proyek Penilaian umum; persetujuan tim proyek CMII : CMMI menentukan setiap area proses dalam hal “tujuan spesifik” dan “langkah‐langkah spesifik” yang dibutuhkan untuk menggapai tujuan‐tujuan tersebut. Tujuan‐Tujuan Spesifik membangun karakteristik‐karakteristik yang harus ada jika aktivitas yang dilakukan sebuah proses adalah efektif. Langkah‐Langkah Spesifik membuat sebuah tujuan menjadi sekelompok aktivitas‐aktivitas yang berkaitan dengan proses. Pola‐Polas Proses : Pola‐pola proses menentukan sekelompok aktivitas, aksi, tugas‐tugas pekerjaan, produk‐produk pekerjaan dan/atau perilaku yang berkaitan Sebuah template digunakan untuk menentukan pattern/pola Contoh‐contoh umum : Komunikasi pelanggan (sebuah aktivitas proses) Analisis (sebuah aksi) Pengumpulan Kebutuhan (sebuah tugas proses) Review sebuah produk kerja (sebuah tugas proses) Model Desain (sebuah produk kerja) ASESMEN PROSES : Sebuah proses harus dinilai untuk memastikan bahwa mereka memenuhi sekumpulan kriteria proses dasar yang penting bagi rekayasa PL yang sukses. Beberapa pilihan penilaian yang tersedia : SCAMPI CBA IPI SPICE ISO 9001:2000 PENILAIAN DAN PENINGKATAN : Software Process
is examined by
identifies modifications to
identifies capabilities and risk of
Software Process Assessment
Software Process Improvement
leads to
leads to
Capability Determination
motivates
PROSES PERSONAL PL (PSP) : Rekomendasi 5 aktivitas bingkai kerja : Perencanaan Desain level tinggi Review Desain level tinggi Pengembangan Postmortem Penekanan pada kebutuhan software engineer untuk mengidentifikasi kesalahan di awal waktu, dan memahami tipe‐tipe kesalahan tersebut PROSES TIM PL (TSP) : Setiap proyek diluncurkan menggunakan sebuah script yang mendefinisikan tugas‐tugas yang harus diselesaikan Tim diarahkan secara mandiri Pengukuran dianjurkan Pengukuran dianailisis dengan tujuan meningkatkan proses tim TUJUAN UTAMA PROSES PL = KUALITAS TINGGI Ingat: Kualitas Tinggi = Proyek pendek Mengapa? Sedikit/Tidak ada Pekerjaan ulang!
BAB 6 – REKAYASA KEBUTUHAN Chapter 7 : Rekayasa Kebutuhan REKAYASA KEBUTUHAN 1 : permulaan—tanya beberapa pertanyaan yang menjelaskan : Pemahaman dasar dari masalah Orang yang membutuhkan solusi Keadaan dari solusi yang diinginkan Efektivitas komunikasi dan kolaborasi awal antara konsumen dengan developer Perolehan—memperoleh kebutuhan dari semua stakeholder Penguraian—membuat model analisis yang mampu melakukan identifikasi kebutuhan data, fungsi dan perilaku Negosiasi—menyepakati sistem penyajian yang realistis bagi konsumen dan developer REKAYASA KEBUTUHAN 2 : Spesifikasi—salah satu dari berikut ini : Dokumen tertulis Sekelompok model Matematika formal Sekumpulan skenario user (use‐cases) Prototipe Validasi—memeriksa mekanisme yang memuat Kesalahan isi atau interpretasi Area dimana klarifikasi dibutuhkan Informasi yang hilang inkonsistensi (masalah utama ketika produk atau sistem besar direkayasa) Kebutuhan yang konflik atau tidak realistis. Manajemen Kebutuhan PERMULAAN : Kenali stakeholder “who else do you think I should talk to?” Kenali beberapa sudut pandang Berusahalah menuju kolaborasi Pertanyaan pertama Siapa di belakang permintaan atas pekerjaan ini ? Siapa yang akan menggunakan solusi ini? Apa keuntungan ekonomi dari solusi yang sukses ? Apakah ada sumber solusi lain yang anda butuhkan? MEMPEROLEH KEBUTUHAN : Pertemuan diadakan dan dihadiri baik oleh software engineer maupun konsumen Aturan persiapan dan partisipasi dibuat Agenda ditawarkan Seorang fasilitator (bisa konsumen, developer atau orang luar) mengendalikan pertemuan Mekanisme definisi digunakan (bisa berupa kertas kerja, grafik, bulletin board elektronik, forum virtual dsb Tujuannya adalah Menemukan permasalahan Mengajukan elemen‐elemen solusi Negosiasi pendekatan yang berbeda Menentukan sekelompok kebutuhan solusi awal PENYEBARAN FUNGSI KUALITAS : Penyebaran fungsi menemukan “nilai” (dalam persepsi konsumen) dalam setiap fungsi yang diperlukan sistem Penyebaran Informasi menentukan event dan objek data Penyebaran Tugas memeriksa perilaku sistem Analisis Nilai menentukan prioritas relatif dari kebutuhan MENDAPATKAN PRODUK KERJA : Sebuah pernyataan kebutuhan dan kemungkinan dikerjakan. Pernyataan terbatas tentang lingkup sistem atau produk. Daftar konsumen, pengguna dan stakeholder lain yang berpartisipasi dalam pengumpulan kebutuhan Deskripsi lingkungan teknis sistem. Daftar kebutuhan (disarankan dikelompokkan berdasar fungsi) dan batasan domain yang diterapkan pada masing‐masing kebutuhan. Sekelompok skenario penggunaan yang menyediakan wawasan pada penggunaan sistem atau produk dalam kondisi operasi yang berbeda. Beberapa prototype yang dikembangkan untuk definisi kebutuhan yang lebih baik. USES‐CASES : Sekelompok skenario pengguna yang menggambarkan alur penggunaan sistem Setiap skenario digambarkan dari sudut pandang “aktor”, seseorang atau piranti yang berinteraksi dengan PL dalam berbagai cara Setiap skenario menjawab pertanyaan‐pertanyaan berikut :: Siapa aktor primer dan sekunder ? Conduc t FA ST m eet ings
Mak e lis t s of f unc t ions , c las s es
Mak e lis t s of c ons t raint s , et c .
f orm al priorit iz at ion?
Eli c i t re q u i re m e n t s
no
y es
Us e QFD t o priorit iz e requirem ent s
def ine ac t ors
inf orm ally priorit iz e requirem ent s
draw us e-c as e diagram
writ e sc enario
Creat e Us e-c as es
c om plet e t em plat e
Apa tujuan aktor ? Prekondisi apa yang harus ada sebelum cerita dimulai? Apa tugas atau fungsi utama yang dilakukan oleh aktor ? Ekstensi apa yang harus diperhatikan ketika cerita digambarkan? Variasi apa yang mungkin pada interaksi aktor? Sistem informasi apa yang dibutuhkan, diproduksi atau diubah aktor ? Apakah aktor harus menginformasikan kepada sistem tentang perubahan di lingkungan luar ? Informasi apa yang diharapkan aktor dari sistem ? Apakah aktor berharap diinformasikan tentang perubahan yang tidak terduga ? Reading commands
Init ializat ion
Sensor Arms/ disarms syst em
Accesses syst em via Int ernet homeow ner
Responds t o alarm event
Encount ers an error condit ion
syst em administ rat or
Reconf igures sensors and relat ed syst em f eat ures
t urn copier “on“
syst em st at us=“not ready” display msg = “please wait ” display st at us = blinking
subsyst ems ready
ent ry/ swit ch machine on do: run diagnost ics do: init iat e all subsyst ems
sensors
name/id type location area characteristics identify() enable() disable() reconfigure ()
not jammed
syst em st at us=“Ready” display msg = “ent er cmd” display st at us = st eady
paper f ull
ent ry/ subsyst ems ready do: poll user input panel do: read user input do: int erpret user input
t urn copier “of f ” st art copies
Making copies copies complet e syst em st at us=“Copying” display msg= “copy count =” display message=#copies display st at us= st eady ent ry/ st art copies do: manage copying do: monit or paper t ray do: monit or paper f low
paper t ray empt y
paper jammed
problem diagnosis syst em st at us=“Jammed” display msg = “paper jam” display message=locat ion display st at us= blinking
load paper syst em st at us=“load paper” display msg= “load paper” display st at us= blinking
ent ry/ paper empt y do: lower paper t ray do: monit or f ill swit ch do: raise paper t ray
not jammed
ent ry/ paper jammed do: det ermine locat ion do: provide correct ivemsg. do: int errupt making copies
Figure 7.6 Preliminary UML st at e diagram for a phot ocopier USE CASE DIAGRAM CLASS DIAGRAM STATE DIAGRAM MEMBANGUN MODEL ANALISIS : Elemen‐elemen model analisis Elemen‐elemen berbasis skenario Fungsional—memproses narasi untuk fungsi PL Use‐case—gambaran interaksi antara aktor dan sistem Elemen‐elemen berbasis Class Dipengaruhi oleh skenario Elemen‐elemen Perilaku/Behavioral State diagram Elemen‐elemen berorientasi aliran Data flow diagram POLA POLA ANALISIS : Nama Pola: sebutan yang mengungkap esensi pola . Maksud: Menggambarkan apa yang dilakukan atau direpresentasikan pola Motivasi: Sebuah skenario yang menggambarkan bagaimana pola dapat digunakan untuk menyelesaikan masalah. Pengaruh dan Konteks: deskripsi isu eksternal yang dapat mempengaruhi bagaimana pola digunakan, dan isu eskternal yang akan diselesaikan ketika pola diterapkan. Solusi: Deskripsi tentang bagaimana pola diterapkan untuk menyelesaikan masalah dengan tekanan pada isu struktural dan perilaku. Konsekuensi: menunjukkan apa yang terjadi apabila pola diterapkan dan apa kerugian yang ada selama aplikasi tersebut dijalankan. Desain: Membahas bagaimana pola analisis dapat diterima melalui penggunakan pola desain (design patterns) yang sudah dikenal. Penggunaan yang sudah dikenal: Contoh penggunaan di dalam sistem aktual. Pola terkait: Satu atau lebih pola analisis yang terkait dengan nama pola yang ada karena (1)secara umum digunakan dengan nama pola;(2)secara struktur mirip dengan nama pola;(3)variasi dari nama pola. NEGOSIASI KEBUTUHAN : Mengenali stakeholder kunci Orang‐orang ini yang akan dilibatkan negosiasi Menentukan “kondisi menang” setiap stakeholder Kondisi kemenangan tidak selalu jelas Negosiasi Bekerja menuju sekumpulan kebutuhan yang merupakan win‐win solution VALIDASI KEBUTUHAN : Apakah setiap kebutuhan konsisten dengan tujuan keseluruhan sistem/produk? Apakah semua kebutuhan telah dispesifikasikan pada tingkat abstraksi yang tepat ? Apakah beberapa kebutuhan pada tingkatakan detail teknis tidak tepat pada level ini ? Apakah kebutuhan benar‐benar diperlukan ataukan dia hanya merupakan fitur tambahan yang tidak esensial bagi tujuan sistem ? Apakah setiap kebutuhan terbatasi dengan baik dan tidak ambigu ? Apakah setiap kebutuhan mempunyai atribut ? Apakah sebuah sumber tercatat untuk setiap kebutuhan ? Apakah setiap kebutuhan konflik dengan kebutuhan lain ? Apakah setiap kebutuhan dapat diterima dalam lingkungan teknik yang menjadi rumah bagi sistem/produk? Apakah setiap kebutuhan dapat diuji, setelah diimplementasi ? Apakah model kebutuhan mencerminkan informasi, fungsi, dan perilaku sistem yang dibangun dengan baik.
Apakah model kebutuhan telah dipartisi sedemikian sehingga menampilkan secara progresif informasi yang lebih detail tentang sistem ? Apakah pola kebutuhan telah digunakan untuk mempermudan model kebutuhan ? Apakah semua pola telah divalidasi? Apakah pola konsisten dengan kebutuhan konsumen ?
BAB 9 – PEMBENTUKAN RANCANGAN ARSITEKTUR Chapter 10 : Desain Arsitektur KENAPA ARSITEKTUR ? Arsitektur bukanlah PL operasional, namun dia merupakan representasi yang memungkinkan pengembang PL untuk : (1)menganalisa efektivitas desain dalam memenuhi kebutuhan, (2) Mengetahui alternatif2x arsitektur pada keadaan dimana membuat perubahan desain masih relatif lebih mudah, dan (3) Mengurangi resiko terkait dengan konstruksi PL. MENGAPA ARSITEKTUR PENTING ? Representasi dari arsitektur PL adalah enabler bagi komunikasi antar pihak (stakeholder) yang tertarik dengan pengembangan sistem berbasis komputer. Arsitketur menyoroti keputusan desain awal yang akan mempunyai pengaruh yang sangat besar pada pekerjaan RPL yang mengikutinya, dan keberhasilan pada entitas sistem operasional. Arsitektur membangun model yang relatif kecil dan mudah digenggam secara intelektual tentang bagaimana sistem distrukturkan dan bagaimana komponen2x bekerja sama [BAS03]. DESAIN DATA : Pada level arsitektur … Desain satu atau lebih database untuk mendukung arsitektur aplikasi Desain method untuk ‘mining’ isi dari berbagai database Navigasi melalui database2x yang ada dalam usaha untuk mengambil informasi level bisnis yang sesuai Desain sebuah data warehouse—sebuah database besar, independen yang mempunyai akses pada data yang disipan dalam database yang melayani sekelompok aplikasi yang dibutuhkan bisnis Pada level komponen … Mengambil objek2x data dan mengembangkan satu set abstraksi data Implementasi atribut2x objek data sebagai satu atau lebih struktur data review struktur data untuk memastikan bahwa relasi yang tepat sudah dibuat Sederhanakan struktur data sesuai dengan kebutuhan 1. Prinsip2x analisis semantik yang diterapkan pada fungsi dan perilaku harus juga dapat berjalan pada data. 2. Seluruh struktur data dan operasi yang akan dilakukan harus dapat diidentifikasi. 3. Sebuah data dictionary harus dibuat dan digunakan untuk menentukan desain program dan data. 4. Keputusan desain data level rendah harus ditunda hingga akhir proses desain. 5. Representasi struktur dara harus diketahui oleh modul yang menggunakannya langsung dalam struktur tersebut (enkapsulasi). 6. Sebuah pustaka struktur data dan operasi yang memungkinkan untuk diterapkan harus dikembangkan. 7. Desain PL dan bahasa pemrograman harus mendukung spesifikasi dan realisasi dari tipe data abstrak. RAGAM GAYA ARSITEKTUR : Masing2x menggambarkan kategori sistem yang menunjukkan : (1) a sekumpulan komponen (mis database, modul komputasi) yang menunjukkan fungsi yan dibutuhkan sistem, (2) sekumpulan connectors yang memungkinkan komunikasi, koordinasi dan kerjasama antar komponen components, (3) batasan yang menentukan bagaimana komponen dapat diintegrasikan untuk membentuk sistem, dan (4) smodel semantik yang memungkinkan desainer untk memahami properti keseluruhan dari sistem dengan menganlisai properti dalam bagian2x di dalamnya. Data‐centered architectures Data flow architectures Call and return architectures Object‐oriented architectures Layered architectures DATA CENTERED ARCHITECTURE : DATA FLOW ARCHITECTURE :
Call and Return Architecture :
Layered Architecture :
PATTERN ARSITEKTURAL : Concurrency—aplikasi harus menangani banyak tugas dalam pola yang mensimulasikan paralelisasi operating system process management pattern task scheduler pattern Persistence—Data ada jika dia bertahan setelah eksekusi proses yang membuatnya. Ada dua pattern umum :: database management system pattern yang menerapkan penyimpanan dan pengambilan dari DBMS kepada arsitektur aplikasi application level persistence pattern yang membangun fitur persistence pada aristektur aplikasi Distribution— pola dimana sistem atau komponen2x di antaranya berkomunkasi dalam lingkungan terdistribusi broker bertindak sebagai orang di tengah antara komponen klient dan komponen server. DESAIN ARSITEKTUR : PL harus ditempatkan pada konteks Desain harus menentukan entitas eksternal (sistem lain, piranti, orang) dimana PL berinteraksi dengannya Sekumpulan arsitektur archetypes harus diidentifikasi archetype adalah abstraksi (mirip dengan class) yang menampilkan satu elemen dari perilaku sistem Desainer menentukan struktur sistem dengan memilih komponen PL yang mengimplmentasi masing2x archetype ARCHETYPES : ARCHITECTURAL CONTEXT : Cont roller
communicat es wit h
Safehome Product
control panel
Internet-based system
target system: Security Function
homeowner
Node
uses
surveillance function
Det ect or
Indicat or
peers
uses
uses
sensors
sensors
Figure 10.7 UML relat ionships f or Saf eHome securit y f unct ion archet ypes
COMPONENT STRUCTURE :
(adapt ed f rom [ BOS00] )
REFINED COMPONENT STRUCTURE :
SafeHome Executive
Ext ernal Communicat ion Management
SafeHome Execut ive
Security
Funct ion select ion
GUI
Internet Interface
Ext ernal Communicat ion Management
Con t ro l
Securit y
GUI
d et ect or m an ag em en t
p an el p roce ssing
Surveillance
Ke y p ad pro cessin g
Home management
Int ernet Int erface
sch ed uler
CP d isp lay fu nct io ns
Cont r ol panel processing
det ect or management
alarm pr ocessing
alarm p roce ssing
ph o ne com m u nicat ion
alarm sen so r se nsor se nso sor sen r se se nnsor sorr se nso senso sor r sen
ANALISIS DESAIN ARSITEKTUR : 1. Kumpulkan semua skenario. 2. Dapatkan kebutuhan2x, batasan2x, dan gambaran lingkungan. 3. Gambarkan pola/gaya arsitektur yang telah dipilih untuk menangani skenario2x dan kebutuhan2x :: • module view • process view • data flow view 4. Evaluasi kualitas atribut2x dengan melihat setiap atribut dalam isolasi. 5. Kenali kualitas atribut untuk setiap atribut arsitektural untuk masing‐masik gaya arsitektur yang spesifik. 6. Lakukkan kritik pada arsitektur2x kandidat (yg dikembangkan pada langkah 3) menggunakan analisis pada langkah 5. METODE DESAIN ARSITEKTUR :
MEMPEROLEH ARSITEKTUR PROGRAM : PARTISI ARSITEKTUR : Partisi “horizontal” dan “vertical” dibutuhkan
PARTISI HORIZONTAL : Tentukan cabang yang terpisah pada hierarki modul untuk setiap fungsi utama Gunakan modul kontrol untuk koodinasi komunikasi antar fungsi2x
PARTISI VERTIKAL : FACTORING Didesain sehingga pengambilan keputusan dan pekerjaan distratifikasi Modul pengambilan keputusan tetap ada di puncak arsitektur MENGAPA ARSITEKTUR TERPARTISI ? Hasilnya adalah PL yang mudah diuji Membawa kepada PL yang lebih mudah dikelola Hasilnya efek samping yang semakin sedikit Hasilnya adalah PL yang lebih mudah dikembangkan DESAIN TERSTRUKTUR : Tujuan : untuk mendapatkan arsitektur program yang terpartisi pendekatan: DFD dipetakan ke arsitektur program PSPEC dan STD digunakan untuk mengindikasikan setiap modul notasi: diagram struktur
KARAKTERISTIK ALIRAN :
PENDEKATAN PEMETAAN UMUM : Isolasi aliran ke dalam dan ke luar batasan; untuk aliran transaksi, isolasi Pusat transaksi Bekerja dari batasan luar, petakan Transformasi DFD ke modul terkait Tambahkan modul kontrol jika dibutuhkan Sempurnakan struktur program Menggunakan konsep modularitas efektif PEMETAAN TRANSFORMASI : FACTORING :
a
b d
h
g
f
e
i
c
direction of increasing decision making
j
typical "decision making" modules
data flow model x1 x2 b
"Transform" mapping x4
x3 c
d
e
f
a
FIRST LEVEL FACTORING :
g
i
h
j
typical "worker" modules
SECOND LEVEL MAPPING :
main
D C control
B
A A B C
mapping from the flow boundary outward TRANSACTION FLOW :
D
TRANSACTION EXAMPLE :
MULAI SLIDE 35 SAMPAI 43 BERBAHASA INGGRIS.. JADI TIDAK DICOPY KESINI.. BACA SENDIRI YA.. ^^
BAB 12 – STRATEGI TESTING Chapter 13 : Software Testing Strategies Coba terjemhin pake google translate + diedit² sendiri..CMIIW ^_^ SOFTWARE TESTING : Pengujian adalah proses latihan program dengan tujuan khusus untuk menemukan kesalahan sebelum pengiriman kepada pengguna akhir. WHAT TESTING SHOW ? Error Persyaratan Kesesuaian Performa Sebuah indikasi kualitas SIAPA YANG MENGETEST SOFTWARE ? Developer(Pengembang) : Memahami sistem tetapi, akan menguji "dengan lembut" dan, didorong oleh "pengiriman" Indepentdent Tester : Harus belajar tentang sistem, tetapi, akan mencoba untuk memecahkannya, dan didorong oleh kualitas STRATEGI TESTING : 1. Unit Test 2. Integration Test 3. System Test 4. Validation Test • Kita mulai dengan 'testing‐in‐the‐small' dan bergerak ke arah 'testing‐in‐the‐large' • Untuk perangkat lunak konvensional : o Modul (komponen) adalah fokus awal kita o Integrasi modul berikutnya • Untuk perangkat lunak OO o fokus kita ketika "testing‐in‐the‐small" perubahan dari modul individu (pandangan konvensional) menuju kelas OO yang meliputi atribut dan operasi dan menyiratkan komunikasi dan kolaborasi Isu Strategi : Menentukan tujuan testing secara eksplisit Memahami pengguna software dan mengembangkan sebuah profil untuk setiap kategori pengguna. Mengembangkan rencana pengujian yang menekankan "pengujian siklus cepat." Membangun perangkat lunak “kuat” yang dirancang untuk menguji sendiri Menggunakan tinjauan teknis formal yang efektif sebagai filter sebelum pengujian Melakukan tinjauan teknis formal untuk menilai strategi tes dan kasus tes itu sendiri. Mengembangkan pendekatan perbaikan terus‐menerus untuk proses pengujian. UNIT TESTING : Interface (Antarmuka) Software Engineer Æ Modul yang akan di tes Æ Hasil Struktur data lokal ↑ boundary conditions Test Case independent paths error handling paths UNIT TEST ENVIRONTMENT :
INTEGRATION TESTING STRATEGY : Options: • pendekatan “big bang” • strategi pembangunan bertahap
TOP DOWN INTEGRATION
SANDWICH TESTING
BOTTOM UP INTEGRATION
OBJECT ORIENTED TESTING : dimulai dengan mengevaluasi kebenaran dan konsistensi dari model OOA dan OOD pengujian perubahan strategi konsep 'unit' diperluas karena enkapsulasi integrasi memfokuskan pada kelas dan pelaksanaannya di sebuah 'thread' atau dalam konteks skenario penggunaan validasi menggunakan metode konvensional kotak hitam (Black Box) desain uji kasus menarik pada metode konvensional, tapi juga meliputi fitur‐fitur khusus
BROADENING THE VIEW OF “TESTING” Dapat dikatakan bahwa analisis OO review dan model desain ini sangat berguna karena konstruksi semantik yang sama (misalnya, kelas, atribut, operasi, pesan) muncul di analisis, desain, dan tingkat kode. Oleh karena itu, masalah dalam definisi atribut kelas yang ditemukan selama analisis akan menghindari efek samping yang mungkin terjadi jika masalah tersebut tidak ditemukan sampai desain atau kode (atau bahkan iterasi berikutnya analisis). MENGETES CRC MODEL : 1. Kembali model CRC dan model hubungan obyek‐. 2. Periksa deskripsi dari setiap kartu indeks CRC untuk menentukan apakah tanggung jawab didelegasikan adalah bagian dari definisi kolaborator itu. 3. Balikkan sambungan untuk memastikan bahwa setiap kolaborator yang diminta untuk layanan ini menerima permintaan dari sumber yang masuk akal. 4. Menggunakan koneksi terbalik diperiksa dalam langkah 3, menentukan apakah kelas‐kelas lain mungkin dibutuhkan atau apakah tanggung jawab dengan benar dikelompokkan antara kelas. 5. Menentukan apakah tanggung jawab yang diminta secara luas mungkin digabung menjadi tanggung jawab tunggal. 6. Langkah 1 sampai 5 diterapkan secara iterasi ke tiap kelas dan melalui setiap evolusi dari model OOA. OOT STRATEGY kelas pengujian adalah setara dengan unit pengujian usaha dalam kelas diuji perilaku state dari kelas diperiksa integrasi diterapkan tiga strategi yang berbeda thread‐pengujian berbasis ‐ mengintegrasikan set kelas yang dibutuhkan untuk merespon satu input atau peristiwa use‐pengujian berbasis ‐mengintegrasikan set kelas yang dibutuhkan untuk merespon gunakan salah satu kasus cluster pengujian‐mengintegrasikan set kelas diminta untuk menunjukkan satu kolaborasi
SMOKE TESTING • Pendekatan umum untuk menciptakan "daily‐builds" untuk produk perangkat lunak produk Langkah‐langkah : • Komponen Perangkat Lunak yang telah diterjemahkan ke dalam kode yang terintegrasi ke dalam "build" o Sebuah “build” termasuk semua file data, libraries, modul dapat digunakan kembali, dan komponen rekayasa yang diperlukan untuk melaksanakan satu atau lebih fungsi produk. • Serangkaian tes ini dirancang untuk mengekspos kesalahan yang akan terus membangun dari benar melakukan fungsinya. o Tujuan harus untuk menemukan "tutupnya menunjukkan" kesalahan yang memiliki kemungkinan tertinggi melemparkan proyek software di belakang jadwal. • Build terintegrasi dengan build lainnya dan seluruh produk (dalam bentuk sekarang) adalah smoke tested daily. o Pendekatan integrasi dapat top down atau bottom up.
HIGH ORDER TSETING Validation testing Focus pada kebutuhan software System testing Focus pada integrasi sistem Alpha/Beta testing Focus is on penggunaan pelanggan Recovery testing Memaksa software untuk gagal dalam berbagai cara dan memverifikasi bahwa pemulihan dilakukan dengan benar Security testing memverifikasi bahwa mekanisme perlindungan yang dibangun ke dalam sistem akan, pada kenyataannya, melindunginya dari penetrasi tidak benar Stress testing menjalankan sistem dengan cara yang menuntut sumber dalam jumlah abnormal, frekuensi, atau volume Performance Testing uji kinerja run‐time dari perangkat lunak dalam konteks sistem terpadu DEBUGGING : Sebuah Proses Diagnosis PROSES DEBUGGING : DEBUGGING EFFORT :
GEJALA DAN PENYEBAB • • • • • • KONSEKUENSI BUG
Gejala dan penyebab mungkin secara geogrfis terpisah Gejala mungkin hilang ketika masalah lain sudah fix Disebabkan mungkin karena sebuah kombinasi dari non‐error Disebabkan mungkin karena sistem / compiler error Disebabkan mungkin karena asumsi yang dipercayai setiap orang Gejala mungkin berselang
Bug Categories: function‐related bugs, system‐related bugs, data bugs, coding bugs, design bugs, documentation bugs, standards violations, etc.
TEKNIK DEBUGGING : • brute force / testing • backtracking • induction • deduction DEBUGGING : PEMIKIRAN FINAL 1. tidak lari setengah memiringkan, pikirkan tentang gejala yang Anda lihat 2. menggunakan alat (misalnya, debugger dinamis) untuk mendapatkan wawasan yang lebih 3. Jika pada sebuah kebuntuan, mendapatkan bantuan dari orang lain 4. benar‐benar yakin untuk melakukan pengujian regresi ketika Anda melakukan "memperbaiki" bug