Prinsip pemilihan bahasa pemrograman Memiliki sintaks yang jelas Memiliki semantik yang jelas Semantic (arti) dari setiap statement program jelas. Precedence operator dlm expresi mudah dimengerti Modular dan Information hiding Model Integrasi sub-modul yang dapat di-link oleh beberapa sub-modul lain secara independent Setiap sub-modul yg di-link tsb menjadikan suatu model abstraksi utk information hiding HARJANTO SUTEDJO - ATA 2008/2009

Prinsip pemilihan bahasa pemrograman (cont.) Abstraksi Tersedia fasilitas untuk mendefinisikan tipe data baru sbg abstraksi data, maupun abstraksi algoritma. Orthogonal Hanya ada satu cara dalam mengekspresikan suatu action, tidak bergantung tehadap komponen lain (tipe data composite dan return function sesuai tipe data yg diinginkan) Portability Dapat diinstal proses kompilasi pada beberapa jenis mesin dan OS. HARJANTO SUTEDJO - ATA 2008/2009

Prinsip pemilihan bahasa pemrograman (cont.) Structure Control flow Name scope (bagaimana menggunakan referensi variable) -> pointer Typing (static, dynamic) Compiler dapat mendeteksi error melalui check yang konsisten. Kesalah yg umum seperti pemberian nama alias untuk suatu variable -> tidak konsisten; type-checking; Efisiensi Warning untuk variable yg tidak digunakan tp sudah dideklarasikan HARJANTO SUTEDJO - ATA 2008/2009

(cont.) Prinsip pemilihan Bahasa Pemrograman Seragam dalam penggunaan statement Dapat mengantisipasi kondisi exception Mampu menangani proses yg concurrent (bersamaan) -> multithread, parallel processing HARJANTO SUTEDJO - ATA 2008/2009

HARJANTO SUTEDJO - ATA 2008/2009 Kategori Aplikasi Paradigma pemrosesan data Pemrosesan record-record data Paradigma komputasi numerik Melibatkan perhitungan matematika tingkat tinggi (simulasi dan modelling), graphics, pengolahan citra Paradigma berorientasi proses ‘real-time programming’ melibatkan pemrosesan record dan proses komputasi, komunikasi inter-proses HARJANTO SUTEDJO - ATA 2008/2009

HARJANTO SUTEDJO - ATA 2008/2009 Kategori Aplikasi Paradigma system-programming Close to the machine (control-system, embedded system, ….) Paradigma proses auto-adaptive Implementasi Artificial Intelligent. HARJANTO SUTEDJO - ATA 2008/2009

Perawatan Sistem (Sistem Maintenance) Melakukan modifikasi aplikasi (SW) setelah digunakan/dipakai. Biasanya tidak melakukan perubahan besar terhadap arsitektur sistem. Perubahan-perubahan terjadi melalui modifikasi komponen yg ada dan/atau penambahan komponen baru ke sistem. HARJANTO SUTEDJO - ATA 2008/2009

A Typical Maintenance Flow Written: MR’s Proposed M. R.’s nominal path Customer Help desk Approved M. R.’s Current source & documentation Maintenance engineer Change control board Modified source & documentation MR:Maintenance Request HARJANTO SUTEDJO - ATA 2008/2009

A Typical Maintenance Flow Marketing nominal path Written MR’s Proposed M. R.’s Customer Maintenance manager Help desk Approved M. R.’s Current source & documentation Maintenance engineer Change control board Modified source & documentation Rejected MR’s HARJANTO SUTEDJO - ATA 2008/2009

HARJANTO SUTEDJO - ATA 2008/2009 Tipe Maintenance Corrective Maintenance Memperbaiki kesalahan latent termasuk temporary patches Adaptive Maintenance Respond terhadap perubahan eksternal Perubahan hardware platform Perubahan software dukungan Perfective Maintenance Meningkatkan mutu sistem yg sdh dikembangkan user enhancements Peningkatan efisiensi Preventative Maintenance Mempermudah perawatan berikutnya Documenting, commenting, etc. HARJANTO SUTEDJO - ATA 2008/2009

HARJANTO SUTEDJO - ATA 2008/2009 Masalah yg dihadapi Lima masalah utama: Rendahnya kualitas dokumentasi Banyak permintaan user utk peningkatan dan perluasan Banyak menyita waktu utk maintenance Sulit menentukan komitmen waktu schedule pertemuan Pertukaran susunan organisasi Keterbatasan pemahaman Moral Kebanyakan lebih tertarik ke pengembangan sistem HARJANTO SUTEDJO - ATA 2008/2009

HARJANTO SUTEDJO - ATA 2008/2009 IEEE standard 840-1992 4. Implementation 4.1 Input 4.2 Process 4.2.1 Coding and testing 4.2.3 Risk analysis & review 4.2.4 Test-readiness review 4.3-4.6 Control, Output, Quality factors, Metrics. 5. System Test 5.1-5.6 Input, Process, Control, Output, Quality factors, Metrics. 6. Acceptance Test 6.1-6.6 Input, Process, Control, Output, Quality factors, Metrics. 7. Delivery 7.1-7.6 Input, Process, Control, Output, Quality factors, Metrics. 1. Problem identification 1.1 Input 1.2 Process 1.3 Control 1.4 Output 1.5 Quality factors 1.6 Metrics 2. Analysis 2.1 Input 2.2 Process 2.2.1 Feasibility analysis 2.2.2 Detailed analysis 2.3-2.6 Control, Output, Quality factors, Metrics. 3. Design 3.1-3.6 Input, Process, Control, Output, Quality factors, Metrics. HARJANTO SUTEDJO - ATA 2008/2009

Fase Perawatan 1: Problem Identification   IEEE 1219-1992 Fase Perawatan 1: Problem Identification a. Input Maintenance Request (MR) (Permintaan Perawatan) b. Process Mementukan jumlah perubahan Kalsifikasi berdasarkan tipe dan severity etc. Menerima atau menolak perubahan Membuat estimasi perhitungan awal biaya maintenance Prioritas c. Control Identifikasi MR sec. unique Memasukkan MR kedalam kegiatan kerja d. Output MR yang valid e. Selected quality factors Kejelasan MR Tingkat kebenaran MR (mis., type) f. Selected metrics Jumlah MR yang diabaikan Jumlah MR yang dilaksanakan Jumlah duplikasi MR Waktu yang diperlukan untuk menemukan masalah HARJANTO SUTEDJO - ATA 2008/2009

Fase Maintenance 2: Problem Analysis   IEEE 1219-1992 Fase Maintenance 2: Problem Analysis  a. Input Dokumentasi asli Proyek MR yang sudah tervalidasi di fase identifikasi b. Process Mempelajari fisibilitas MR Investigasi dampak MR Analisa detail pekerjaan yang akan dilakukan yg berhubungan dg MR Menyempurnakan deskripsi MR c. Control Membuat technical review Verifikasi terhadap … …startegi test yang cocok …dokumentasi yang ter-update Identifikasi isu keselamatan dan keamanan d. Output Laporan fisibilitas Laporan detail analisis, termasuk dampak yang mungkin terjadi Requirement yg ter-update List modifikasi awal Rencana Implementation Perubahan Strategi Test e. Selected quality factors Comprehensibility of the analysis f. Selected metrics Number of requirements that must be changed Effort (required to analyze the MR) Elapsed time HARJANTO SUTEDJO - ATA 2008/2009

Maintenance phase 3: Design   IEEE 1219-1992 Maintenance phase 3: Design Original project documentation Analysis from the previous phase a. Input Create test cases Revise … …requirements …implementation plan b. Process c. Control Verify design Inspect design and test cases d. Output Revised … …modification list …detailed analysis …implementation plan Updated … …design baseline …test plans Flexibility (of the design) Traceability Reusability Comprehensibility e. Selected quality factors Effort in person-hours Elapsed time Number of applications of the change f. Selected metrics HARJANTO SUTEDJO - ATA 2008/2009

Maintenance phase 4: Implementation   IEEE 1219-1992 Maintenance phase 4: Implementation a. Input Original source code Original project documentation Detailed design from previous phase b. Process Make code changes and additions Perform unit tests Review readiness for system testing c. Control Inspect code Verify CM control of new code Traceability of new code d. Output Updated … …software …unit test reports …user documents e. Selected quality factors Flexibility Traceability Comprehensibility Maintainability Reliability f. Selected metrics Lines of code Error rate HARJANTO SUTEDJO - ATA 2008/2009

Pendekatan Maintenance Filosofi Maintenance: Orang lain yg bertanggung jawab dlm maintenance (bukan pengembang) maintenance menjadi tantangan dlm reverse engineering Tim pengembang membuat suatu long term komitmen untuk merawat sistem. Proses maintenance Basili: Quick-fix model Perubahan pd code semudah mungkin Degradasi struktur software menurun secara cepat Iterative enhancement model Perubahan berdasarkan analisis sistem Berusaha utk mengontrol kompleksitas dan merancang perawatan dgn baik Full-reuse model Memulai dengan requirements utk sistem baru, sedapat mungkin melakukan reengineering sistem yg ada. Memerlukan suatu budaya reuse yg mature agar sukses dlm reengineering (meminimumkan terjadinya perubahan-perubahan). HARJANTO SUTEDJO - ATA 2008/2009

HARJANTO SUTEDJO - ATA 2008/2009 Kualitas Maintenance Metrics Maintenance: Number of lines of code under maintenance Person-months to perform various maintenance tasks Defect count HARJANTO SUTEDJO - ATA 2008/2009

HARJANTO SUTEDJO - ATA 2008/2009 Quality Assurance Quality assurance terdiri dari procedures, techniques, dan tools yang digunakan utk meyakinkan bahwa sistem sesuai atau melampaui standards yang sudah ditentukan pd saat proses pengembangan sistem. Terdiri dari semua teknik yg digunakan untuk meningkatkan kualitas sistem: 1. Metode dan alat untuk menentukan System Requirements, System Analysis, System Design, Implementation and Testing membantu dlm meyakinkan kualitas sistem 2. Standard dan procedure membantu meyakini proses pengembangan sistem yg dpt diulang 3. Prosedur Metrics dan pengukuran membantu meingkatkan proses pengembangan sistem 4. Review Formal technical pd setiap langkah to help uncover quality problems and to sign-off 5. Software configuration management dan change control meyakinkan bhw perubahan dilakukan secara terkontrol dan teratur 6. Multi-tiered testing membantu dlm mencari kesalahan secara efektif HARJANTO SUTEDJO - ATA 2008/2009

Prinsip Kualitas Assurance 1. Adanya standards dan atribut kualitas yang harus dipenuhi oleh sistem. memenuhi tujuan yg harus dicapai. 2. Adanya pengukuran kualitas sistem. Cara utk menentukan seberapa baik sistem sesuai dengan atribut dan standar kualitas. 3.Perhitungan terhadap nilai atribut kualitas. Menilai seberapa baik pengembangan sistem yg sudah dilakukan. 4.Penggunaan informasi kualitas sistem digunakan utk meningkatkan kualitas sistem berikutnya. Terdapat feedback terhadap proses pengembangan sistem. HARJANTO SUTEDJO - ATA 2008/2009

HARJANTO SUTEDJO - ATA 2008/2009 Faktor Kualitas Portability (Dapatkah dikonversi ke komputer lain) Reusability (Beberapa bagianb dpt digunakan lagi) Interoperability (Interaksi dg sistem lain) Maintainability (Dapatkah diperbaiki) Flexibility (Dapatkah diubah) Testability (Dapatkah diujikan) Product Revision Product Translation Product Operation Correctness (Sesuai dgn yg diinginkan) Reliability (Dapat bekerja secara akurat) Efficiency (Proses Komputasi & jml code) Integrity (Keamanan) Usability (Mudah digunakan) HARJANTO SUTEDJO - ATA 2008/2009

HARJANTO SUTEDJO - ATA 2008/2009 Faktor Kualitas Yang menentukan kualitas sistem: Sisi customer -> sesuai spesifikasi Sisi pengembang -> mudah melakukan perawatan dan test Kualitas sistem ditentukan juga oleh beberapa faktor lain: Atribut lain untuk kualitas sistem: safety – understandability – portability security – testability – usability reliability – adaptability – reusability resilience – modularity – efficiency robustness – complexity – learnability perlu dilakukan pemilihan atribut kualias yg kritis pd tahap awal proses pengembangan sistem dan merencanakan penentuan klasifikasi sistem thd atribut HARJANTO SUTEDJO - ATA 2008/2009

HARJANTO SUTEDJO - ATA 2008/2009 Metrics Control metrics – digunakan untuk mengontrol proses pengembangan (mis., biaya, waktu yg digunakan, penggunaan disk, dll.) Predictor metrics – untuk memprdiksi kualitas product yg sesuai. (mis., cyclomatic complexity memprediksi kemudahan prawatan ) External attribute: hanya dapat setelah software digunakan (mis.,kemudahan perawatan) Internal attribute: dapat diukur langsung dari software itu sendiri (mis., cyclomatic complexity) HARJANTO SUTEDJO - ATA 2008/2009

Faktor Kualitas dan Metrics Kualitas HARJANTO SUTEDJO - ATA 2008/2009

HARJANTO SUTEDJO - ATA 2008/2009 Functionality, Usability, Reliability, Performance and Supporotability (FURPS) metrics HARJANTO SUTEDJO - ATA 2008/2009

Product Quality — Design Quality Metrics Tingkat perawatan komponen perancangan sistem berhubungan ke: Cohesion – tingkat hubungan fungisonal komponen? Coupling – tingkat ketergantungan antar komponen. Understandability – tingkat kemudahan pemahaman apa yang dilakukan oleh komponen? Adaptability – tingkat kemudahan merubah komponen Kebanyakan faktor tersebut tidak dapat diukur secara langsung, tetapi hal tsb beralasan untuk menyatakan bahwa terdapat hubungan antara atribut dan kompleksitas komponen. measure complexity HARJANTO SUTEDJO - ATA 2008/2009

Product Quality — Design Quality Metrics (2) a) Structural fan-in/fan-out fan-in – jumlah panggilan ke suatu komponen (dari luar) fan-out – jumlah komponen yg terpanggil (diluar) b) Informational fan-in/fan-out Mempertimbangkan jml parameter yang dikirim ditambah pengaksesan ke struktur data yg di share. complexity = length x (fan-in x fan-out)2 sudah tervalidasi pd sistem Unix merupakan prediktor effort yg diperlukan untuk implementasi HARJANTO SUTEDJO - ATA 2008/2009

Software Maturity Index SMI = [MT - (Fa + Fc + Fd)]/ MT MT = jumlah subsystem pd current release Fc = jumlah subsystem pd current release yang diubah Fa = jumlah subsystem pd current release yang ditambahkan Fd = jumlah subsystem pd release sebelumnya yg dihilangkan di current release. HARJANTO SUTEDJO - ATA 2008/2009

Design structure quality index—DSQI IEEE Standard 982.1-1988 Digunakan untuk membandingkan dengan perancangan sebelumnya; jika DSQI terlalu rendah, perancangan dan review lebih lanjut masih diperlukan. Range (0 – 1) DSQI = wiDi wi = relative weighting of each Di Program structure: D1 = 1 jika arsitektur dikembangkan menggunakan metode yg berbeda D1 = 0 selain itu Subsystem independence: D2 = 1 - (S2/S1) Subsystems not dependent on prior processing: D3 = 1 - (S3/S1) Database size: D4 = 1 - (S5/S4) Database compartmentalization: D5 = 1 - (S6/S4) Subsystem entrance/exit characteristic: D6 = 1 - (S7/S1) HARJANTO SUTEDJO - ATA 2008/2009

HARJANTO SUTEDJO - ATA 2008/2009 DSQI S1 = jumlah subsystem yang didefinisikan dalam arsitektur program S2 = jumlah subsystem dimana correct function tergantung pd sumber data input atau yang menghasilkan data digunakan di tempat lain. S3 = jumlah subsystem dimana correct function tergantung pada prses sebelumnya S4 = jumlah item database (termasuk data objects dan semua atribut- atribut yang mendefinisikan obyek) S5 = jumlah total item database unique S6 = jumlah segmen database segments (record yg berbeda atau individual objects) S7 = jumlah subsystem dengan jalur masuk dan keluar tunggal HARJANTO SUTEDJO - ATA 2008/2009

Product Quality — Program Quality Metrics a) Halstead’s Software Science Melihat operators dan operands dalam suatu komponen dan menghitung nilai volume component, V, tingkat kesulitan component, D, dan effort, E, yg diperlukan untuk implementasi komponen. n1 = jumlah operators unique pd suatu component n2 = jumlah operand unique pd suatu component N1 = jumlah total operators N2 = jumlah total operands L = N1+ N2 (component length) V = L * log2(n1 + n2) (component volume in bits) D = (n1/2) * (N2/n2) (tingkat kesulitan implementasi komponen) E = V * D (effort yg diperlukan untuk implementasi) HARJANTO SUTEDJO - ATA 2008/2009

Product Quality — Program Quality Metrics (2) b) McCabe’s Complexity Metric Merujuk kepada control flow suatu komponen Cyclomatic Complexity –> mengukur kompleksitas logical komponen suatu indikasi tingkat kesulitan pengujian suatu komponen c) Metrics kualitas yg lain: Length of code – Length of identifiers Depth of conditional nesting Pencapaian Standard dapat menghindari component yg complex dan/atau problem penting yg ada di componen HARJANTO SUTEDJO - ATA 2008/2009

Product Quality — Pendekatan Formal Membuktikan kebenaran spesifikasi sistem. Pembuktian secara logis bhw kebutuhan sudah ditransformasi ke sistem secara benar. (mis. pembuktian assertions programs) b) Statistical Quality Assurance Pengkategorian dan menentukan penyebab defect sistem 80-20 rule  80% defects dapat di telusuri disebabkan oleh 20% Mengisolir dan memperbaiki 20% penyebab tadi c) The Cleanroom Process Kombinasi dua pendekatan di atas. HARJANTO SUTEDJO - ATA 2008/2009

Capability Maturity Model (CMM) Key Processes in Place Level 1: Initial process Level 2: Repeatable process Requirements Management Software Project Planning Software Project Tracking & Oversight Software Subcontract Management Software Quality Assurance Software Configuration Management Level 3: Defined process Organization Process Focus Organization Process Definition Training Program Integrated Software Management Software Product Engineering Intergroup Coordination Peer Reviews Level 4: Managed process Quantitative Process Management Software Quality Management Level 5: Optimizing process Fault Prevention Technology Change Management Process Change Management HARJANTO SUTEDJO - ATA 2008/2009

Process Quality — SEI Capability Maturity Model (CMM) Level 1 Organization: Initial process (ad hoc) Tidak terdapat: formal procedures, estimasi biaya, perencanaan proyek, mekanisme manajemen untuk meyakini bhw prosedur telah diikuti dg baik. Level 2 Organization: Repeatable process (intuitive) Pengontrolan Basis project; penggunaan metoda intuitive. Level 3 Organization: Defined process (qualitative) Pendefinisian proses pengembangan secara institusional. Level 4 Organization: Managed process (quantitative) Mengukur proses; penguatan process database Level 5 Organization: Optimizing process Meningkatkan feedback; adanya analisa defect-cause dan pencegahannya. HARJANTO SUTEDJO - ATA 2008/2009

People Quality — People Capability Maturity Model (PCMM) Level 1 – Initial Tidak ada technical atau management training; staff talent bukan sumber yg kritis; tidak ada organizational loyalitas Level 2 – Repeatable Focus pd pengembangan praktik kerja dasar; mengutamakan perkrutan, pertumbuhan dan pengembangan staff; training utk meningkatkan skill “gaps”; evaluasi kinerja. Level 3 – Defined Focus pada penggabungan praktik kerja ke bisnis organisasi; strategic plan untuk melokasikan dan mengembangkan kebutuhan talent; melokasikan dan mengembangkan kebutuhan talent; adanya kompensasi terhadap skills-based Level 4 – Managed Focus pd peningkatan kompetensi pd critical skills; mentoring; team-building; quantitative competence goals; evaluation thd kefektifan work practices Level 5 – Optimizing Focus pd peningkatan kemampuan team dan individual penggunaan best practices HARJANTO SUTEDJO - ATA 2008/2009

HARJANTO SUTEDJO - ATA 2008/2009 SQA — The Bottom Line Suatu organisasi harus memiliki manual kualitas manual yaitu dokumentasi prosedur quality assurance Setiap proyek harus memiliki quality plan yaitu himpunan quality attributes yang dianggap penting Memiliki dokumentasi yang standard Terdapat mekanisme (processes) pemantauan pemenuhan kebutuhan kualitas pd organisasi . Adanya reviews terhadap quality assurance Metrics yang dapat digunakan utk menghindari bagian anomalous software yang memiliki permasalahan kualitas HARJANTO SUTEDJO - ATA 2008/2009