BAB 2 PROSES PENGEMBANGAN PIRANTI LUNAK Proses : Pandangan Umum

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