Prinsip pemilihan bahasa pemrograman Memiliki sintaks yang jelas
Prinsip pemilihan bahasa pemrograman Memiliki sintaks yang jelas Memiliki semantik yang jelas n Semantic (arti) dari setiap statement program jelas. Precedence operator dlm expresi mudah dimengerti Modular dan Information hiding n n 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 2008/2009 ATA 1
Prinsip pemilihan bahasa pemrograman (cont. ) Abstraksi n Tersedia fasilitas untuk mendefinisikan tipe data baru sbg abstraksi data, maupun abstraksi algoritma. Orthogonal n 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 n Dapat diinstal proses kompilasi pada beberapa jenis mesin dan OS. SUTEDJO - ATA HARJANTO 2008/2009 2
Prinsip pemilihan bahasa pemrograman (cont. ) Structure n n n 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 n Warning untuk variable yg tidak digunakan tp HARJANTO SUTEDJO ATA 2008/2009 sudah dideklarasikan 3
(cont. ) Prinsip pemilihan Bahasa Pemrograman Seragam dalam penggunaan statement Dapat mengantisipasi kondisi exception Mampu menangani proses yg concurrent (bersamaan) -> multithread, parallel processing HARJANTO SUTEDJO 2008/2009 ATA 4
Kategori Aplikasi Paradigma pemrosesan data n Pemrosesan record-record data Paradigma komputasi numerik n Melibatkan perhitungan matematika tingkat tinggi (simulasi dan modelling), graphics, pengolahan citra Paradigma berorientasi proses n ‘real-time programming’ melibatkan pemrosesan record dan proses komputasi, komunikasi interproses HARJANTO SUTEDJO 2008/2009 ATA 5
Kategori Aplikasi Paradigma system-programming n Close to the machine (control-system, embedded system, …. ) Paradigma proses auto-adaptive n Implementasi Artificial Intelligent. HARJANTO SUTEDJO 2008/2009 ATA 6
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 2008/2009 ATA 7
A Typical Maintenance Flow Written: MR’s Customer nominal path Proposed M. R. ’s Help desk Approved M. R. ’s Maintenance engineer Current source & documentation Change control board Modified source & documentation HARJANTO SUTEDJO 2008/2009 MR: Maintenance Request ATA 8
A Typical Maintenance Flow nominal path Customer Marketing Written MR’s Proposed M. R. ’s Maintenance manager Help desk Approved M. R. ’s Maintenance engineer Current source & documentation Change control board Modified source & documentation HARJANTO SUTEDJO 2008/2009 ATA Rejected MR’s 9
Tipe Maintenance Corrective Maintenance n Memperbaiki kesalahan latent w termasuk temporary patches Adaptive Maintenance n Respond terhadap perubahan eksternal w Perubahan hardware platform w Perubahan software dukungan Perfective Maintenance n Meningkatkan mutu sistem yg sdh dikembangkan w user enhancements w Peningkatan efisiensi Preventative Maintenance n Mempermudah perawatan HARJANTO SUTEDJO berikutnya 2008/2009 w Documenting, commenting, etc. ATA 10
Masalah yg dihadapi Lima masalah utama: n n n 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 n Kebanyakan. HARJANTO lebih. SUTEDJO tertarik ke pengembangan ATA sistem 2008/2009 11
4. Implementation IEEE standard 840 -1992 4. 1 Input 1. Problem identification 4. 2 Process 1. 1 Input 1. 2 Process 4. 2. 1 Coding and testing 1. 3 Control 1. 4 Output 4. 2. 3 Risk analysis & review 4. 2. 4 Test-readiness review 1. 5 Quality factors 4. 3 -4. 6 Control, Output, 1. 6 Metrics Quality factors, Metrics. 2. Analysis 5. System Test 2. 1 Input 5. 1 -5. 6 Input, Process, Control, 2. 2 Process Output, Quality factors, Metrics. 6. 2. 2. 1 Feasibility analysis 2. 2. 2 Detailed analysis Acceptance Test 2. 3 -2. 6 Control, Output, 6. 1 -6. 6 Input, Process, Control, Quality factors, Metrics. Output, Quality factors, Metrics. 7. 3. Design Delivery 3. 1 -3. 6 Input, Process, Control, HARJANTO SUTEDJO ATA 7. 1 -7. 6 Input, Process, Control, 2008/2009 12 Output, Quality factors, Metrics.
a. Input IEEE 1219 -1992 Fase Perawatan 1: Problem Identification • 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 e. Selected quality factors f. Selected metrics • MR yang valid • Kejelasan MR • Tingkat kebenaran MR (mis. , type) • Jumlah MR yang diabaikan • Jumlah MR yang dilaksanakan • Jumlah duplikasi MR HARJANTO SUTEDJO ATA • Waktu yang diperlukan untuk menemukan masalah 2008/2009 13
a. Input b. Process c. Control d. Output IEEE 1219 -1992 Fase Maintenance 2: Problem Analysis • Dokumentasi asli Proyek • MR yang sudah tervalidasi di fase identifikasi • Mempelajari fisibilitas MR • Investigasi dampak MR • Analisa detail pekerjaan yang akan dilakukan yg berhubungan dg MR • Menyempurnakan deskripsi MR • Membuat technical review • Verifikasi terhadap … …startegi test yang cocok …dokumentasi yang ter-update • Identifikasi isu keselamatan dan keamanan • 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) HARJANTO SUTEDJO ATA • Elapsed time 2008/2009 14
a. Input b. Process c. Control d. Output IEEE 1219 -1992 Maintenance phase 3: Design • Original project documentation • Analysis from the previous phase • Create test cases • Revise … …requirements …implementation plan • Verify design • Inspect design and test cases • Updated … • Revised … …modification list …detailed analysis …implementation plan …design baseline …test plans e. Selected quality factors • Flexibility (of the design) • Traceability • Reusability • Comprehensibility f. Selected metrics • Effort in person-hours • Elapsed time HARJANTO SUTEDJO ATA • Number of applications of the change 2008/2009 15
a. Input b. Process IEEE 1219 -1992 Maintenance phase 4: Implementation • Original source code • Original project documentation • Detailed design from previous phase • 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 HARJANTO SUTEDJO • Error rate 2008/2009 ATA 16
Pendekatan Maintenance Filosofi Maintenance: n Orang lain yg bertanggung jawab dlm maintenance (bukan pengembang) w maintenance menjadi tantangan dlm reverse engineering Tim pengembang membuat suatu long term komitmen untuk merawat sistem. Proses maintenance Basili: n Quick-fix model w Perubahan pd code semudah mungkin w Degradasi struktur software menurun secara cepat n Iterative enhancement model w Perubahan berdasarkan analisis sistem w Berusaha utk mengontrol kompleksitas dan merancang perawatan dgn baik n Full-reuse model w Memulai dengan requirements utk sistem baru, sedapat mungkin melakukan reengineering sistem yg ada. w Memerlukan suatu budaya reuse yg mature agar sukses dlm SUTEDJOterjadinya ATA perubahan-perubahan). reengineering HARJANTO (meminimumkan 2008/2009 17
Kualitas Maintenance Metrics Maintenance: n n n Number of lines of code under maintenance Person-months to perform various maintenance tasks Defect count HARJANTO SUTEDJO 2008/2009 ATA 18
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 è 2. Standard dan procedure è 3. to help uncover quality problems and to sign-off Software configuration management dan change control è 6. membantu meingkatkan proses pengembangan sistem Review Formal technical pd setiap langkah è 5. membantu meyakini proses pengembangan sistem yg dpt diulang Prosedur Metrics dan pengukuran è 4. membantu dlm meyakinkan kualitas sistem meyakinkan bhw perubahan dilakukan secara terkontrol dan teratur Multi-tiered testing è HARJANTO SUTEDJO ATA membantu dlm mencari kesalahan secara efektif 2008/2009 19
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 pengembangan HARJANTO SUTEDJO - proses ATA sistem. 2008/2009 20
Faktor Kualitas Maintainability (Dapatkah diperbaiki) Flexibility (Dapatkah diubah) Product Testability Revision (Dapatkah diujikan) Portability (Dapatkah dikonversi ke komputer lain) Reusability Product (Beberapa bagianb dpt Translation digunakan lagi) Interoperability (Interaksi dg sistem lain) Product Operation Correctness (Sesuai dgn yg diinginkan) Reliability (Dapat bekerja secara akurat) Efficiency (Proses Komputasi & jml code) Integrity (Keamanan) HARJANTO SUTEDJO ATA 2008/2009 Usability (Mudah digunakan) 21
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: n n n safety security reliability resilience robustness – – – understandability testability adaptability modularity complexity – – – portability usability reusability efficiency learnability è perlu dilakukan pemilihan atribut kualias yg kritis pd tahap awal proses pengembangan. HARJANTO sistem dan merencanakan penentuan SUTEDJO ATA klasifikasi sistem thd atribut 2008/2009 22
Metrics Control metrics – digunakan untuk mengontrol proses pengembangan (mis. , biaya, waktu yg digunakan, penggunaan disk, dll. ) Predictor metrics – untuk memprdiksi kualitas product (mis. , cyclomatic complexity memprediksi kemudahan prawatan ) yg sesuai. External attribute: hanya dapat setelah software digunakan (mis. , kemudahan perawatan) Internal attribute: dapat diukur langsung dari software itu sendiri (mis. , cyclomatic complexity) HARJANTO SUTEDJO 2008/2009 ATA 23
Faktor Kualitas dan Metrics Kualitas HARJANTO SUTEDJO 2008/2009 ATA 24
Functionality, Usability, Reliability, Performance and HARJANTO SUTEDJO ATA Supporotability (FURPS) 2008/2009 metrics 25
Product Quality — Design Quality Metrics Tingkat perawatan komponen perancangan sistem berhubungan ke: n n 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 2008/2009 ATA 26
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 2008/2009 ATA 27
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 2008/2009 ATA 28
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 = wi. Di wi = relative weighting of each Di Program structure: D 1 = 1 jika arsitektur dikembangkan menggunakan metode yg berbeda D 1 = 0 selain itu Subsystem independence: D 2 = 1 - (S 2/S 1) Subsystems not dependent on prior processing: D 3 = 1 - (S 3/S 1) Database size: D 4 = 1 - (S 5/S 4) Database compartmentalization: D 5 = 1 - (S 6/S 4) Subsystem HARJANTO SUTEDJO ATA entrance/exit 2008/2009 characteristic: D 6 = 1 - (S 7/S 1) 29
DSQI S 1 = jumlah subsystem yang didefinisikan dalam arsitektur program S 2 = jumlah subsystem dimana correct function tergantung pd sumber data input atau yang menghasilkan data digunakan di tempat lain. S 3 = jumlah subsystem dimana correct function tergantung pada prses sebelumnya S 4 = jumlah item database (termasuk data objects dan semua atribut yang mendefinisikan obyek) S 5 = jumlah total item database unique S 6 = jumlah segmen database segments (record yg berbeda atau individual objects) S 7 = jumlah subsystem dengan jalur masuk dan keluar tunggal HARJANTO SUTEDJO 2008/2009 ATA 30
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. n 1 = jumlah operators unique pd suatu component n 2 = jumlah operand unique pd suatu component N 1 = jumlah total operators N 2 = jumlah total operands L = N 1+ N 2 (component length) V = L * log 2(n 1 + n 2) (component volume in bits) D = (n 1/2) * (N 2/n 2) (tingkat kesulitan implementasi komponen) E=V *D (effort yg diperlukan untuk implementasi) HARJANTO SUTEDJO 2008/2009 ATA 31
Product Quality — Program Quality Metrics (2) b) Mc. Cabe’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: n Length of code – Length of identifiers n Depth of conditional nesting èPencapaian Standard dapat menghindari component yg complex dan/atau problem penting yg ada di componen HARJANTO SUTEDJO 2008/2009 ATA 32
Product Quality — Pendekatan Formal a) Membuktikan kebenaran spesifikasi sistem. Pembuktian secara logis bhw kebutuhan sudah ditransformasi ke sistem secara benar. (mis. pembuktian assertions programs) b) Statistical Quality Assurance n Pengkategorian dan menentukan penyebab defect sistem n 80 -20 rule 80% defects dapat di telusuri disebabkan oleh 20% n Mengisolir dan memperbaiki 20% penyebab tadi c) The Cleanroom Process n Kombinasi dua pendekatan di atas. HARJANTO SUTEDJO 2008/2009 ATA 33
Capability Maturity Model (CMM) Key Processes in Place Level 3: Defined process Level 1: Initial process Organization Process Focus Organization Process Definition Training Program Integrated Software Management Software Product Engineering Intergroup Coordination Peer Reviews Level 2: Repeatable process Requirements Management Software Project Planning Software Project Tracking & Oversight Software Subcontract Management Software Quality Assurance Software Configuration Management Level 4: Managed process Level 5: Optimizing process Quantitative Process Management Software Quality Management Fault Prevention Technology Change Management HARJANTO SUTEDJO Process Change Management 2008/2009 ATA 34
Process Quality — SEI Capability Maturity Model (CMM) Level 1 Organization: Initial process (ad hoc) n Tidak terdapat: formal procedures, estimasi biaya, perencanaan proyek, mekanisme manajemen untuk meyakini bhw prosedur telah diikuti dg baik. Level 2 Organization: Repeatable process (intuitive) n Pengontrolan Basis project; penggunaan metoda intuitive. Level 3 Organization: Defined process (qualitative) n Pendefinisian proses pengembangan secara institusional. Level 4 Organization: Managed process (quantitative) n Mengukur proses; penguatan process database Level 5 Organization: Optimizing process n Meningkatkan feedback; adanya- analisa HARJANTO SUTEDJO ATA defect-cause dan 2008/2009 pencegahannya. 35
People Quality — People Capability Maturity Model (PCMM) Level 1 – Initial n Tidak ada technical atau management training; staff talent bukan sumber yg kritis; tidak ada organizational loyalitas Level 2 – Repeatable n Focus pd pengembangan praktik kerja dasar; mengutamakan perkrutan, pertumbuhan dan pengembangan staff; training utk meningkatkan skill “gaps”; evaluasi kinerja. Level 3 – Defined n Focus pada penggabungan praktik kerja ke bisnis organisasi; strategic plan untuk melokasikan dan mengembangkan kebutuhan talent; adanya kompensasi terhadap skills-based Level 4 – Managed n Focus pd peningkatan kompetensi pd critical skills; mentoring; team-building; quantitative competence goals; evaluation thd kefektifan work practices Level 5 – Optimizing n Focus pd peningkatan kemampuan team dan individual penggunaan best practices HARJANTO SUTEDJO 2008/2009 ATA 36
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 2008/2009 ATA 37
- Slides: 37