Presentasi sedang didownload. Silahkan tunggu

Presentasi sedang didownload. Silahkan tunggu

Prinsip pemilihan bahasa pemrograman Memiliki sintaks yang jelas Memiliki semantik yang jelas Semantic (arti) dari setiap statement program jelas. Precedence.

Presentasi serupa


Presentasi berjudul: "Prinsip pemilihan bahasa pemrograman Memiliki sintaks yang jelas Memiliki semantik yang jelas Semantic (arti) dari setiap statement program jelas. Precedence."— 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 1 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. 2 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 3 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 4 HARJANTO SUTEDJO - ATA 2008/2009

5 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 5 HARJANTO SUTEDJO - ATA 2008/2009

6 Kategori Aplikasi Paradigma system-programming Close to the machine (control-system, embedded system, ….) Paradigma proses auto-adaptive Implementasi Artificial Intelligent. 6 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. 7 HARJANTO SUTEDJO - ATA 2008/2009

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

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

10 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. 10 HARJANTO SUTEDJO - ATA 2008/2009

11 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 11 HARJANTO SUTEDJO - ATA 2008/2009

12 IEEE standard 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 Feasibility analysis Detailed analysis Control, Output, Quality factors, Metrics. 3. Design Input, Process, Control, Output, Quality factors, Metrics. 4. Implementation 4.1 Input 4.2 Process Coding and testing Risk analysis & review 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. 12 HARJANTO SUTEDJO - ATA 2008/2009

13 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 13 HARJANTO SUTEDJO - ATA 2008/2009

14 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 14 HARJANTO SUTEDJO - ATA 2008/2009

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

16 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 16 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). 17 HARJANTO SUTEDJO - ATA 2008/2009

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

19 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 19 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. 20 HARJANTO SUTEDJO - ATA 2008/2009

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

22 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 22 HARJANTO SUTEDJO - ATA 2008/2009

23 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) 23 HARJANTO SUTEDJO - ATA 2008/2009

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

25 Functionality, Usability, Reliability, Performance and Supporotability (FURPS) metrics 25 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 26 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 27 HARJANTO SUTEDJO - ATA 2008/2009

28 Software Maturity Index SMI = [M T - (F a + F c + F d )]/ M T M T =jumlah subsystem pd current release F c =jumlah subsystem pd current release yang diubah F a =jumlah subsystem pd current release yang ditambahkan F d =jumlah subsystem pd release sebelumnya yg dihilangkan di current release. 28 HARJANTO SUTEDJO - ATA 2008/2009

29 Design structure quality index—DSQI IEEE Standard DSQI =  w i D i w i = relative weighting of each D i 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 entrance/exit characteristic: D 6 = 1 - (S 7 /S 1 ) Digunakan untuk membandingkan dengan perancangan sebelumnya; jika DSQI terlalu rendah, perancangan dan review lebih lanjut masih diperlukan. Range (0 – 1) 29 HARJANTO SUTEDJO - ATA 2008/2009

30 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- 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 30 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. 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) 31 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 32 HARJANTO SUTEDJO - ATA 2008/2009

33 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 Pengkategorian dan menentukan penyebab defect sistem rule  80% defects dapat di telusuri disebabkan oleh 20% Mengisolir dan memperbaiki 20% penyebab tadi c)The Cleanroom Process Kombinasi dua pendekatan di atas. 33 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 34 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. 35 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 36 HARJANTO SUTEDJO - ATA 2008/2009

37 SQA — The Bottom Line 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 Suatu organisasi harus memiliki manual kualitas manual yaitu dokumentasi prosedur quality assurance 37 HARJANTO SUTEDJO - ATA 2008/2009


Download ppt "Prinsip pemilihan bahasa pemrograman Memiliki sintaks yang jelas Memiliki semantik yang jelas Semantic (arti) dari setiap statement program jelas. Precedence."

Presentasi serupa


Iklan oleh Google