Prinsip pemilihan bahasa pemrograman

Presentasi berjudul: "Prinsip pemilihan bahasa pemrograman"— Transcript presentasi:

1 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

2 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

3 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

4 (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

5 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

6 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

7 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

8 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

9 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

10 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

11 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

12 HARJANTO SUTEDJO - ATA 2008/2009
IEEE standard 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 Control, Output, Quality factors, Metrics. 5. System Test Input, Process, Control, Output, Quality factors, Metrics. 6. Acceptance Test Input, Process, Control, Output, Quality factors, Metrics. 7. Delivery Input, Process, Control, Output, Quality factors, Metrics. 1. Problem identification 1.1 Input Process 1.3 Control 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 Control, Output, Quality factors, Metrics. 3. Design Input, Process, Control, Output, Quality factors, Metrics. HARJANTO SUTEDJO ATA 2008/2009

13 Fase Perawatan 1: Problem Identification
IEEE 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

14 Fase Maintenance 2: Problem Analysis
IEEE 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

15 Maintenance phase 3: Design
IEEE 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

16 Maintenance phase 4: Implementation
IEEE 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

17 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

18 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

19 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

20 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

21 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

22 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

23 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

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

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

26 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

27 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

28 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

29 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

30 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

31 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

32 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

33 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

34 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

35 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

36 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

37 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