Software Project Management and Software Metrics

Cara koordinasi dan berkomunikasi dalam tim

• Formal, pendekatan impersonal termasuk dokumentasi software dan produk kerja (termasuk kode sumber), teknikal memo, tonggak proyek, jadwal, dan tools pengendalian proyek , permintaan perubahan dan dokumentasi terkait, laporan pelacakan kesalahan, dan data repositori.
• Formal, prosedur interpersonal fokus pada kegiatan Quality Assurance diterapkan untuk produk kerja software. Hal ini menyangkut pertemuan status dan desain dan kode inspeksi.
• Informal, prosedur interpersonal termasuk pertemuan kelompok untuk penyebaran informasi dan pemecahan masalah dan "alokasi kebutuhan dan pengembangan staf."
• Electronic Communication meliputi surat elektronik, papan buletin elektronik, dan tidak ekstensi, sistem konferensi berbasis video.
• Jaringan interpersonal termasuk diskusi informal dengan anggota tim dan orang-orang di luar proyek yang mungkin memiliki pengalaman atau wawasan yang dapat membantu anggota tim.

Problem Decomposition

• pertimbangkan karakteristik proyek
• menentukan tingkat ketelitian yang dibutuhkan
• mendefinisikan tugas untuk setiap kegiatan software engineering

Ada 3 faktor yang mempengaruhi Kualitas Perangkat Lunak menurut McCall yang dikenal dengan “McCall’s Triangle of Quality”. 

• Product Operation

1. Correctness: sejauh mana suatu software memenuhi spesifikasi dan mission objective dari users
2. Reliability:  sejauh mana suatu software dapat diharapkan untuk melaksanakan fungsinya dengan ketelitian yang diperlukan
3. Integrity: sejauh mana akses ke software dan data oleh pihak yang tidak berhak dapat dikendalikan
4. Efisiensi: banyaknya sumber daya komputasi dan kode program yang dibutuhkan suatu software untuk melakukan fungsinya
5. Usability: usaha yang diperlukan untuk mempelajari, mengoperasikan, menyiapkan input, dan mengartikan output dari software

• Product Revision

1. Maintainability: usaha yang diperlukan untuk menemukan dan memperbaiki kesalahan (error) dalam software
2. Flexibility: usaha yang diperlukan untuk melakukan modifikasi terhadap software yang operasional
3. Testability: usaha yang diperlukan untuk menguji suatu software untuk memastikan apakah melakukan fungsi yang dikehendaki atau tidak

• Product Transition

1. Portability: kemampuan program yang dibuat untuk berjalan diberbagai landasan, seperti dapat berjalan di Sistem Operasi yg berbeda (windows, linux, Mac)
2. Reuseability: sejauh mana suatu software (atau bagian software) dapat digunakan ulang pada aplikasi lainnya
3. Interoperatebility: kemampuan aplikasi untuk dapat berkomunikasi dengan program lainnya seperti dapat berkomunikasi dengan database atau program lain yang bersangkutan

Function Point: adalah sebuah perhitungan yang digunakan untuk menentukan harga suatu program, semakin banyak fungsi yang dibutuhkan oleh program maka akan semakin mahal harganya dan fungsi2 tersebut memiliki nilainya sendiri. Fungsi yang sulit dibuat akan memiliki harga lebih mahal dari fungsi yang mudah. Berbeda dengan LOC (Line of Code) yang nilai programnya ditentukan dari berapa baris code yang ada dalam program tersebut

F

Contoh function point

Software Maturity Index (SMI)

yang memberikan indikasi stabilitas produk software (berdasarkan perubahan yang terjadi untuk setiap rilis produk)

SMI=  (MT - (Fa - Fc - Fd))/MT

MT= jumlah seluruh modul

Fa  = jumlah modul yang ditambahkan

Fc  = jumlah modul yang diganti

Fd  = jumlah modul yang dihapus

Measuring Quality

• Correctness: sejauh mana program beroperasi sesuai dengan spesifikasi / permintaan user
• Maintainability: sejauh mana program ini bisa menerima perubahan
• Integrity: sejauh mana program tahan terhadap serangan dari luar
• Usability: sejauh mana program mudah dipahami cara penggunaannya oleh user

Defect Removal Efisiensi

DRE = E / (E+D)

E = jumlah error yang ada sebelum diperbaiki

D = jumlah cacad yang muncul setelah perbaikan error

Formal Modeling and Software Configuration Management

Cleanroom Software Engineering

• Increment Planning: menyusun rencana tambahan
• Requirment Gathering: mendefinisikan deskripsi dari level customer requirment
• Box Structure Spesification: menjelaskan spesifikasi fungsional
• Design Formal: Spesifikasi (BlackBox) yang iteratif halus untuk menjadi analog dengan desain arsitektur dan prosedural.
• Verifikasi Kebenaran Software
• Code Generation: spesifikasi struktur kotak, diwakili dalam bahasa khusus, ditransmisikan ke dalam bahasa pemrograman yang sesuai.
• Statistical Test Planning: statistik dari test case
• Statistical Usage Planning: mengeksekusi serangkaian tes yang berasal dari sampel statistik 
• Sertifikasi

Cleanroom Testing

• statistical use testing: menguji penggunaan aktual dari program
• menentukan “usage probability distribution”

• menganalisis spesifikasi untuk mengidentifikasi sebuah pergerakan
• pergerakan menyebabkan perangkat lunak untuk mengubah perilaku
• buat skenario pengunaan
• menetapkan probabilitas penggunaan untuk setiap pergerakan
• uji kasus dihasilkan untuk setiap pergerakan sesuai dengan distribusi penggunaan probabilitas 

Certification

1. Harus ada skenario pengunaan
2. Spesifikasikan profile pemakaian
3. Test case dihasilkan dari profile
4. Tes dieksekusi dan data kegagalan dicatat dan dianalisis
5. Reliability dihitung dan bersertifikat 

Certification Model

• Sampling model
• Component model
• Certification model

Formal Method

Formal Method yang digunakan dalam mengembangkan sistem komputer secara matematis untuk menggambarkan sifat sistem properties. Formal metode seperti menyediakan kerangka kerja di mana orang dapat menentukan, mengembangkan, dan memverifikasi sistem secara sistematis, bukan secara ad hoc.

Formal Spesification

• Desired Properties: konsistensi, kelengkapan, dan kurangnya ambiguitas adalah tujuan dari semua metode spesifikasi.
• Formal syntax: spesifikasi bahasa memungkinkan persyaratan atau desain untuk ditafsirkan hanya dengan satu cara, menghilangkan ambiguitas yang sering terjadi pada bahasa normal (misalnya, bahasa Inggris) atau notasi grafis harus ditafsirkan
• Fasilitas deskriptif set teori dan notasi logika memungkinkan pernyataan yang jelas dari fakta-fakta
• Konsistensi dipastikan dengan matematis membuktikan bahwa fakta-fakta awal dapat secara resmi dipetakan (menggunakan aturan inferensi) ke dalam laporan kemudian dalam spesifikasi.

Formal Methode Concept

• data invariant: suatu kondisi yang benar di seluruh pelaksanaan sistem yang berisi kumpulan data
• state
• operation: suatu tindakan yang terjadi dalam suatu sistem dan membaca atau menulis data ke state

Object Constraint Language (OCL)

• notasi formal dikembangkan sehingga pengguna dari UML dapat menambahkan lebih presisi dengan spesifikasi mereka
• Semua kekuatan logika dan diskrit matematika tersedia dalam bahasa tersebut
• Namun para perancang OCL memutuskan bahwa hanya karakter ASCII (bukan notasi matematika konvensional) harus digunakan dalam laporan OCL

OCL Overview

• Seperti bahasa pemrograman berorientasi objek, ekspresi OCL melibatkan operator yang beroperasi pada objek.
• Namun, hasil dari ekspresi lengkap harus selalu menjadi Boolean, yaitu benar atau salah.
• Object dapat contoh dari OCL Collection class, Set dan Squence adalah dua subclass.

Baseline merupakan tonggak dalam pengembangan perangkat lunak yang ditandai dengan pengiriman item konfigurasi satu atau lebih perangkat lunak dan persetujuan SCIs ini yang diperoleh melalui review teknis formal

Repository Features

• Versioning: memberikan versi pada program dan melakukan perubahan versi saat ada perubahan
• Dependency tracking and change management: repositori mengelola berbagai hubungan antara elemen data yang tersimpan di dalamnya.
• Requirment Tracing: menyediakan kemampuan untuk melacak semua desain dan konstruksi komponen dan kiriman yang dihasilkan dari spesifikasi kebutuhan spesifik
• Configuration Management: Melacak serangkaian konfigurasi yang mewakili tonggak proyek atau rilis produksi tertentu. manajemen versi menyediakan versi yang diperlukan, dan manajemen link melacak saling ketergantungan.
• Audit Trails: menetapkan informasi tambahan tentang kapan, mengapa, dan oleh siapa perubahan yang dibuat.

SCM Elements

• Component elements: seperangkat alat digabungkan dalam sistem manajemen file (misalnya, database) yang memungkinkan akses dan pengelolaan setiap item konfigurasi perangkat lunak.
• Process elements: koleksi prosedur dan tugas-tugas yang menentukan pendekatan yang efektif untuk mengubah manajemen (dan kegiatan terkait) untuk semua konstituen yang terlibat dalam manajemen, teknik dan penggunaan perangkat lunak komputer.
• Construction elements: suatu tools yang mengotomatiskan pembangunan software dengan memastikan bahwa set dari komponen divalidasi (yaitu, versi yang benar) telah dirakit.
• Human elements: untuk menerapkan SCM yang efektif, tim pembuaat software menggunakan suatu tools dan fitur proses (meliputi elemen CM lainnya).

Version Control ada 4hal yang harus diperhatikan dalam version control

• Project Database (repository) yang menyimpan semua konfigurasi objek yang relevan
• kemampuan manajemen versi yang menyimpan semua versi dari objek konfigurasi (atau memungkinkan versi yang akan dibangun menggunakan perbedaan dari versi terakhir);
• membuat fasilitas yang memungkinkan insinyur perangkat lunak untuk mengumpulkan semua konfigurasi object yang relevan dan membangun versi tertentu dari perangkat lunak.
• masalah pelacakan (juga disebut bug tracking) kemampuan yang memungkinkan tim untuk merekam dan melacak status dari semua isu yang beredar terkait dengan setiap konfigurasi object.

Prototyping Product or Service

Prototyping adalah sebuah model dari suatu produk yang digunakan untuk mempermudah user dalam mengenali produk, prototype juga mempermudah developer mengubah design pada suatu produk.

Design Attitude adalah sebuah ilmu yang digunakan untuk memecahkan suatu masalah atau menciptakan sesuatu yang baru untuk melihat peluang yang lebih dan kemungkinan untuk mengembangkan produk.

Untuk menguasai design attitude manger harus menguasai

• Kemampuan menanyakan asumsi dasar
• Mengetahui kapan balik modal dan dapat keuntungan
• Leading the Unknown
• Membuat produk jadi nyata

Cara membuat Prototype

• Membuat Sketch
• Masukan ke Model Canvas
• Dari model kanvas diubah jadi ke bisnis case (ada hitung2 keuangan)
• Melakukan Test di lapangan

Testing Convetional and OO Application

Software Testing Fudamental

Testability

• Operability: dapat dioperasikan dengan rapih
• Observebility: setiap hasil dari test case langsung dapat diamati
• Controllability: sejauh mana pengujian dapat dioptimalkan
• Decomposability: pengujian dapat ditargetkan
• Simplicity: mengurangi arsitektur kompleks dan logika untuk menyederhanakan tes
• Stability: beberapa perubahan yang diminta selama pengujian
• Understandability: design dapat dipahami

What is a "Good Test"?

• Sebuah tes yang baik memiliki probabilitas tinggi untuk menemukan kesalahan
• Sebuah tes yang baik adalah tidak berlebihan.
• Sebuah tes yang baik harus "dapat terus dikembangkan"
• Sebuah tes yang baik harus tidak terlalu sederhana atau terlalu rumit

Internal dan External Testing

Test Case Design adalah test yang dilakukan untuk mencari bug yang ada pada program. Biasanya bug terdapat pada sudut - sudut program, jadi kita harus melakukan pengetesan hingga bagian - bagian kecil program juga. Contoh simple saat bermain game terdapat bug hingga player dapat menembus tembok itu terjadi karena ada bug di sudut program.

Contoh Bug pada sudut program

Exhaustive Testing adalah tehnik pengetesan yang cukup melakukan pengetesan sekali jalan saja untuk menghemat waktu testing dan cepatnya penyelsaian produk. Pada contoh dibawah ada looping sebanyak 20 kali nah kita tidak perlu melakukan 20x cukup 3x saja juga sudah bagus tujuannya untuk menghemat waktu

Contoh Exhausting Loop

Selective Testing adalah testing yang dilakukan untuk setiap jalur selection yang ada pada program

Contoh Selective Testing

Software Testing terbagi menjadi 2 yaitu

• Blackbox testing: test yang biasa dilakukan dengan memanggil end user atau seorang tester, dalam blackbox testing pengguna tidak mengetahui apa isi code program yang ada di dalamnya pengguna hanya perlu tahu fungsi - fungsi dari program. Contoh: ada program melakukan sorting, pengguna tidak perlu tahu tehnik sorting apa yang digunakan dia hanya perlu tahu hasil dari sorting tersebut benar atau salah.
• Whitebox testing: test yang biasa dilakukan oleh sang developer, perbedaannya dengan blackbox adalah orang yang melakukan test mengetahui apa saja code yang digunakan untuk melakukan fungsi - fungsi tersebut. Contoh: ada program melakukan sorting, ketika menguji dia perlu mengetahui tehnik apa yang digunakan dan apa hasilnya akan lebih cepat.

Basis Path Testing

Sebenernya gua bingung jelasinnya gimana yang pasti pertama kita cari path tertutup buat cari V(G) gatau apa itu artinya

Path tertutup biasanya selection atau looping jadi tinggal liat aja dari gambar ada berapa jumlah while atau if nya kira - kira gitu. Digambar ada 3 symbol condition maka P=3

V(G) = P + 1 = 3+1=4

P = jumlah path tertutup

terus tentuin jalur yang dilalui karena V(G) ada 4 maka jalurnya ada 4

Path 1: 1,2,4,7,8

Path 2: 1,2,3,5,7,8

Path 3: 1,2,3,6,7,8

Path 4: 1,2,4,7,1,2,3,5,7,8

yang terpenting setiap path pernah dilalui minimal sekali

Control Structure Testing

• Condition Testing: kasus uji yang menguji semua logic condition yang ada pada modul program
• Data Flow Testing: menguji semua data yang ada apakah fungsi - fungsinya sudah sesuai dengan yang ada pada data flow diagram dan juga variabelnya

Loop Testing

• Simple Loop: loopingnya simple kaya for sekali aja
• Nested Loop: ada looping didalam looping. Contoh: ada "do while" dalam "do while"
• Concatenated Loops: setelah looping yang satu selesai baru masuk ke kondisi looping lainnya
• Unstructured Loops: Don't try this at home. yang ini mungki dia kebanyakan pake jump to pas looping jadi loncat - loncat loopnya

Contoh Loop Testing

Object Oriented Testing

• definisi pengujian harus diperluas untuk mencakup teknik penemuan error diterapkan berorientasi obyek analisis dan desain model
• strategi untuk unit dan pengujian integrasi harus berubah secara signifikan
• desain kasus uji harus memperhitungkan karakteristik unik dari perangkat lunak OO

Menentukan Kebenaran OO model

• Selama analisis dan desain, kebenaran semantik dapat dinilai berdasarkan kesesuaian model untuk masalah dunia nyata.
• Jika model akurat mencerminkan seperti di dunia nyata maka itu adalah semantik benar.
• Untuk menentukan apakah model tersebut sesuai pada kenyataannya, mencerminkan persyaratan dunia nyata, itu harus disampaikan kepada ahli yang akan memeriksa definisi kelas dan hirarki untuk kelalaian dan ambiguitas.
• hubungan antar kelas dievaluasi untuk menentukan apakah mereka secara akurat mencerminkan koneksi objek dunia nyata.

Testing Methode

• Fault Based Testing: tester mencari kesalahan masuk akal (yaitu, aspek pelaksanaan sistem yang dapat mengakibatkan cacat). Untuk menentukan apakah kesalahan ini ada, test case dirancang untuk menguji desain atau kode.
• Class Testing dan Class Hirarki: Melakukan pengujian dengan melihat kecocokan hubungan antara class dan apakah attribute dalam class sudah benar. Lalu baru melakukan integration testing.
• Scenario Based Test Design: pengujian berbasis skenario berkonsentrasi pada apa yang pengguna lakukan, bukan apa produk lakukan. Ini berarti menangkap tugas (melalui use-case) bahwa apa yang pengguna harus lakukan, kemudian menerapkan mereka dan varian mereka sebagai tes.

Product or Service Development

Pada sesi ini kita akan membahas tentang New Product Development lagi - lagi kewirausahaan :D

Apa itu New Product Development? adalah sebuah istilah yang digunakan untuk menggambarkan proses lengkap membawa produk baru ke pasar.

Tantangan dalam mengembangkan produk baru

• Mendefinisikan spesifikasi produk
• Masalah waktu dan sumber daya
• Interaksi dari kelompok Pengembangan Produk dengan perusahaan yang ada

Cara mengatasi tantangan ini adalah

• Menaksir nilai financial project sebelum memulai pembangunan.
• Memprioritaskan proyek sesuai dengan kriteria yang jelas.
• Biarkan seorang marketing profesional yang memasarkan.
• Menentukan pasar dan spesifikasi upfront produk.
• Melibatkan semua fungsi dari perusahaan pada tahap pemilihan produk.
• Menyelaraskan target dan sumber daya proyek.

Penyebab kegagalan produk

• Tidak memenuhi kebutuhan atau keinginan konsumen
• Terlalu tinggi dari ukuran pasar
• Masalah bentuk produk
• Adanya kesalahan posisi pemasaran, harga, promosi, atau produknya
• Tetap memaksa memulai usaha walau market researchnya tidak baik
• Biaya pengembangan melebihi budget
• Tanggapan competitive

Dari mana ide  membuat produk datang?

• Customer
• Competitor
• Distributor
• Supplier
• Teman kerja

Hal yang perlu diperhatikan dalam menemukan ide baru

• Ukuran pasar
• Harga
• Waktu pengembangan dan biaya
• Biaya manufaktur
• Hasil balik modal

Product Development

• Mengembangkan produk menjadi prototype
• Perlu bantuan loncatan besar dari investasi
• Menguji dan menyempurnakan prototipe sampai produk melewati konsumen dan pengawasan hukum.

Comersialisasi

• Peluncuran luas produk dari hasil tes pasar yang positif.
• Menentukan waktu peluncuran harus tepat.
• Memiliki rencana peluncuran yang potensial.

Software Quality Assurance and Software Testing Strategies

Comment on Quality

• Menyiapkan rencana SQA untuk sebuah proyek.
• Berpartisipasi dalam pengembangan deskripsi proses software proyek.
• Review kegiatan software engineering untuk memverifikasi sesuai dengan proses perangkat lunak didefinisikan.
• Audit produk perangkat lunak untuk memverifikasi apakah sudah sesuai dengan yang didefinisikan sebagai bagian dari proses perangkat lunak.
• Memastikan bahwa penyimpangan dalam pekerjaan perangkat lunak dan kerja produk didokumentasikan dan ditangani sesuai dengan prosedur terdokumentasi.
• Mencatat setiap ketidak penyesuaian dan laporan kepada manajemen senior.

SQA Goals

• Persyaratan kualitas. Kebenaran, kelengkapan, dan konsistensi dari model persyaratan akan memiliki pengaruh yang kuat pada kualitas semua produk.
• Kualitas desain. Setiap elemen dari model desain harus dinilai oleh tim Software Engineer untuk memastikan bahwa hal itu menunjukkan kualitas tinggi dan desain itu sesuai dengan persyaratan.
• Kualitas koding. Source code dan produk kerja terkait (misalnya, informasi deskriptif lainnya) harus sesuai dengan standar lokal dan karakteristik pameran yang akan memfasilitasi pemeliharaan.
• Efektivitas kualitas kontrol. Sebuah tim perangkat lunak harus menerapkan sumber daya yang terbatas dengan cara yang memiliki kemungkinan tertinggi mencapai hasil berkualitas tinggi.

Six Sigma

• Definisikan requirment customer (tujuan proyek)
• Menentukan perhitungan kinerja saat ini
• Analisa kecacatan dan penyebab utamanya
• Perbaiki masalah dari akarnya
• Memastikan tidak ada cacat yang sama seperti sebelumnya

Software Realibility adalah ukuran sederhana reabilitas Mean Time Between Failure atau rata - rata kegagalan yang terjadi dalam hitungan waktu (bulan / tahun juga bisa), berikut adalah cara menghitungnya

MTBF = MTTF + MTTR

Software Availability adalah ketersediaan yang harus diberikan oleh software dalam jangka waktu yang ditentukan. Contoh server harus menyala 99,99% selama setahun yang artinya hanya boleh non aktif selama 0,01% dalam waktu setahun karena jika server mati melebihi ketersediaan yang ditentukan perusahaan dapat mengalami kerugian.

Availability = (MTTF/MTBF) * 100%

Software safety adalah kegiatan jaminan kualitas perangkat lunak yang berfokus pada identifikasi dan penilaian potensi bahaya yang dapat mempengaruhi software negatif dan menyebabkan seluruh sistem gagal.

Software Testing adalah proses pengujian program dengan maksud tertentu untuk menemukan kesalahan sebelum diberikan ke end user.

Orang yang melakukan pengetesan awal biasanya developer dan tester yang handal, biasanya developer melakukan test dengan santai karena sudah tau isi program tersebut atau sudah malas karena sudah menyelsaikan programnya. Tester biasanya lebih giat mencari bug yang ada dalam program karena mereka memang dibayar hanya untuk melakukan itu.

Verifikasi adalah melihat apakah cara pembuatan program sudah benar

Validasi adalah melihat apakah hasil dari produk sudah benar

Testing Strategy

• memulai dengan testing bagian - bagian modul yang kecil kemudian menjadi test keseluruhan (dipakai untuk prosedural)
• memulai dengan melakukan pengetesan pada class - class yang ada (untuk object oriented)

Strategic Issues

1. Tentukan requirment produk
2. Nyatakan tujuan pengujian
3. Pahami keinginan user
4. Buat planning
5. Pakai error handling
6. Review kembali produk
7. Buat kasus uji
8. Kembangkan perbaikan

Macam - macam testing

• Unit testing biasanya menguji semua modul - modul penting yang ada dalam program
• Regresion testing melakukan pengujian ulang hal yang telah di tes
• Smoke testing menguji program atau modul yang telah dibuat pada hari itu juga (bisa juga dilakukan seminggu sekali atau 3hari sekali tidak nunggu program jadi)
• Integration testing melakukan pengujian antara modul yang saling berhubungan

High Order Testing

• Validation testing: melakukan test untuk mengetahui apa produk sesuai keinginan customer
• System testing: melakukan test system keseluruhan
• Alpha/Beta testing: test alpha dilakukan oleh orang - orang developer, tester atua orang sekitarnya. Test beta telah dilakukan peluncuran program dan end user dapat mencoba program dan memberi komentar jika terjadi kesalahan terhadap program yang digunakan
• Recovery testing: dilakukan dengan memaksa software untuk gagal
• Stress testing: test seberapa kuat program menahan user yang banyak
• Performance testing: test seberapa cepat kinerja program

Cara melakukan Debug

• Pikirkan - sebelum Anda bertindak untuk memperbaiki
• Gunakan tools untuk mendapat wawasan baru
• Jika Anda berada di jalan buntu, dapatkan bantuan dari orang lain
• Setelah memperbaiki bug, gunakan pengujian regresi untuk mengungkap efeknya

Quality Concept and Review Techniques

Quality Concept

Software Quality

• Quality Design: meliputi persyaratan, spesifikasi, dan desain sistem.
• Quality of Conformance: adalah masalah utama yang difokuskan pada implementasi.
• Kepuasan pelanggan: kepuasan pelanggan menandakan kualitas software anda.

Macam - macam pandangan tentang kualitas

• Transcendental view:  kualitas itu adalah sesuatu yang kita kenali, tetapi tidak dapat secara eksplisit ditentukan.
• User view: melihat kualitas dari segi tujuan tertentu end user. Jika sebuah produk memenuhi tujuan tersebut, hal itu menunjukkan kualitas.
• Manufacturer view: mendefinisikan kualitas dalam hal spesifikasi asli dari produk. Jika produk sesuai dengan spec, hal itu menunjukkan kualitas.
• Product view: menyarankan kualitas yang dapat dikaitkan dengan karakteristik yang melekat (misalnya, fungsi dan fitur) dari produk.
• Value based view: kualitas ditentukan dari seberapa banyak orang yang membeli product tersebut.

Software Quality Dilemma

• Jika Anda menghasilkan sistem perangkat lunak yang memiliki kualitas mengerikan, anda kalah saing karena tidak ada yang akan mau membelinya.
• Jika di sisi lain Anda menghabiskan waktu yang tak terbatas, usaha yang sangat besar, dan uang dalam jumlah besar untuk membangun software yang benar-benar sempurna, maka itu akan begitu lama untuk diselesaikan dan harganya akan sangat mahal hal itu dapat membuat Anda keluar dari bisnis juga.
• Anda tidak tahu entah Anda melewatkan jendela pasar, atau Anda hanya habis semua sumber daya Anda.

Good Enough Software: memberikan fungsi berkualitas tinggi dan fitur yang sesuai keinginan pengguna, tetapi pada saat yang sama memberikan fungsi dan fitur yang mengandung bug dikenal lebih jelas atau khusus lainnya.

Cost of Quality

• Prevention cost: kualitas perencanaan, ulasan teknis formal, alat uji, dan pelatihan
• Internal failure cost: pengerjakan ulang, perbaikan, kesalahan model analisis
• External failure cost: penyelesaian keluhan, pengembalian produk, help-line support, garansi

Quality and Risk: Orang mempertaruhkan pekerjaan mereka, kenyamanan mereka, keselamatan mereka, hiburan mereka, keputusan mereka, dan sangat hidup mereka pada perangkat lunak komputer. Itu lebih baik menjadi benar.

Quality and Security: keamanan software sangat penting dan benar-benar menentukan kualitas software anda. Anda harus berpikir tentang keamanan, keandalan, ketersediaan, kehandalan-di awal, dalam desain, arsitektur, tes, dan fase coding, sepanjang siklus hidup perangkat lunak [proses]. Karena pelanggan akan merasa lebih nyaman jika dirinya aman.

Review Techniques

Apa itu review?

penilaian teknis dari produk kerja yang diciptakan selama proses Software Engineering.

Apa saja yang kita perhatikan?

• Error and Defect: error(kesalahan); masalah kualitas yang kita temukan sebelum sampai ke end user dan defect(kecacatan); masalah yang ditemukan pada tahap beta software
• Perbedaan ini dibuat karena kesalahan dan cacat memiliki ekonomi yang sangat berbeda, bisnis, psikologis, dan dampak manusia.

Informal Review

• Melakukan pengecekan sederhana dari program yang dikerjakan, bisa dengan rekan kerja atau orang yang mengerti tentang software juga
• Casual meeting (melibatkan lebih dari 2 orang) untuk tujuan meninjau produk kerja
• Review orientasi aspek dari pair programming

Formal Technical Review

Tujuan:

• untuk mengungkap kesalahan dalam fungsi, logika, atau penerapan untuk setiap representasi software
• untuk memverifikasi bahwa software dikaji memenuhi persyaratan
• untuk memastikan bahwa software sudah sesuai dengan standar yang telah ditetapkan
• untuk mencapai perangkat lunak yang dikembangkan secara seragam
• untuk membuat proyek lebih mudah dikelola

Cara melakukan

• Review produknya, bukan produsen.
• Menetapkan agenda dan atur itu.
• Batasi perdebatan dan bantahan.
• Mengucapkan area masalah, tapi jangan mencoba untuk memecahkan setiap masalah yang dicatat.
• Buat catatan tertulis
• Membatasi jumlah peserta dan menuntut persiapan awal.
• Checklist setiap produk yang mungkin ditinjau.
• Mengalokasikan sumber daya dan jadwal waktu untuk pertemuan.
• Melakukan pelatihan bagi semua pemberi review.
• Mereview kembali review sebelumnya.