Selasa, 19 Juni 2012

Function Point

Function Point (FP) merupakan suatu ukuruan yang digunakan untuk menentukan berapa jumlah fungsi yang ada pada code. Kegunaan lainnya adalah untuk mengestimasi biaya proyek dan mengetahui ukuran dari business functionality.

FP relevan digunakan ketika history sudah ada dan ketika estimasi komleksitas sudah ada

Tantangan dari FP adalah bagaimana mencari sistem yang sudah dibuat, menganalisa masalah, dan FP ini berhubungan dengan design dan requirement, sehingga jika tidak ada dokumentasinya, developer akan susah menghitung FP.

Untuk menghitung FP, maka caranya adalah :

  • Pertama, kita hitung Crude Function Point (CFP), caranya dengan menganalisis software system yang tertera dalam diagaram DFD (Data Flow Diagram). Tentukan 
    • number of user inputs
    • number of user outputs
    • number of user online queries
    • number of logical files
    • number of external interface
    • kemudian tentukan masing-masing derajat kompleksitas dari setiap komponen pada kelima number    tersebut, apakah termasuk simple, average, atau kompleks.Setelah itu, masukkan dalam tabel perhitungan CFP seperti di bawah ini:




  • Selanjutnya, setelah didapatkan CFP, maka hitunglah Relative Comlplexity Adjustment Factor (RCAF).  Untuk menentukan RCAF, dilakukan pembobotan setiap komponen, berikut ini komponen-komponen yang dinilai dalam RCAF.

  • Selanjutnya, kita dapat menentukan FP dengan formula sebagai berikut :
            FP = CFP x [0,65 + 0,01 x RCAF)



Project Progress Control

Dalam membangun sebuah software, terkadang terdapat kegagalan yang disebabkan oleh beberapa hal, diantaranya :

  • terlalu optimis dalam menentukan schedule dan budgeting
  • adanya ketidakprofesionalan dalam menggunakan software manajemen proyek
  • tertundanya identifikasi dari kesulitan budget dan schedule
Hal-hal tersebut dapat dihindari dengan memaksimalkan contract review, dan project planning tool untuk penyebab pertama, dan untuk penyebab kedua dan ketiga dapat dihindari dengan project progress control.

Manfaat Project Progress Control adalah untuk mendeteksi secara dini kejadian-kejadian yang tak terduga

Komponen dari Project Progress Control adalah
  • Mengontrol aktifitas manajemen resiko
  • mengontrol jadwal / schedule proyek
  • mengontrol sumberdaya proyek
  • mengontrol budget dari proyek

Staff Training and Certification

Staff training and certification bertujuan untuk :

  • membangun dan meningkatkan kemampuan dan pengetahuan staff yang baru yang diperlukan untuk melakukan pembangunan dan maintainanc software
  • memastikan bahwa staff baru dapat membuat desain dan code software sesuai dengan standart yang ditetapkan perusahaan
  • memperbarui pengetahuan dan keterampilan dari staff lama
  • menyalurkan pengetahuan mengenai prosedur SQA
  • memastikan bahwa calon pemangku posisi penting terkualifikasi dengan baik
Untuk melakukan training dan sertifikasi, maka terdapat proses yang harus dilalui, yaitu :
  1. menentukan requirements pengetahuan profesional yang dibutuhkan untuk setiap posisi
  2. menentukan kebutuhan untuk proses training dan update profesional
  3. merencanakan program training profesional
  4. merencanakan program updating profesional
  5. menentukan posisi yang membutuhkan sertifikasi
  6. merencanakan proses sertifikasi
  7. menyampaikan dan melaksanakan program training, updating, dan sertifikasi
  8. menampilkan hasil follow up dari staff yang telah ditraining dan disertifikasi

Documentation Control

Documentation Control merupakan proses mengendalikan segala dokumen yang terdapat pada pembangunan perangkat lunak.

  • dokumen yang terkontrol dan catatan kualitas
    • bagaimana caranaya, dokumen harus sesuai dengan requirement dengan customer, sehingga kualitasnya terpenuhi
  • list dokumen yang terkontrol
    • dokumen-dokumen yang dikontrol adalah seluruh dokumen yang terdapat pada komponen SQA. 
  • persiapan kontrol dokumen
    • menentukan terlebih dahulu dokumen yang akan dikontrol
    • menentukan level dan bobot
  • masalah dalam kontrol dokumen
    • memutuskan dokumen mana yang sesuai dengan kualitas
    • memutuskan level kontrol
    • menganalisa penemuan-peneuman dan updating dari dokumen


Supporting Quality Device

Terdapat tempalate dan checklist untuk mendukung kualitas perangkat lunak.

Template merupakan suatu format yang dibuat oleh units atau organisasi untuk digunakan dalam menyusun dokumentasi atau report.

Adanya template memberikan keuntungan bagi development team dan review team.

Keuntungan bagi development team adalah :

  • hemat waktu dan energi, karena dalam membuat laporan sudah ada formatnya
  • format yang didapatkan dari template ini lebih lengkap
  • lebih mudah untuk diintegrasikan
  • dapat direview dengan lebih simple
Sedangkan keuntungan bagi review tean adalah lebih mudah untuk menemukan lokasi informasi untuk perawatan.

Kelemahan dari template adalah :
  • tidak semua orang di dalam organisasi aware terhadap template ini
  • penambahan dan peningkatan dari format suatu template harus diselesaikan dengan review dari tim profesional


Checklist
Merupakan list dari item-item yang dibuat untuk setiap dokumen yang harus diselesaikan

Tujuan checklist:
  1. menyediakan list item secara lengkap untuk diverifikasi
  2. mendokumentasikan penemuan dari performa yang dicek 

Configuraton Management


Manajemen Konfigurasi merupakan suatu pengelolaan konfigurasi dokumentasi dari proyek perangkat lunak. Konfigurasi ini dilakukan untuk menghindari kebungungan yang dapat merugikan.

Sebagai contoh, ketika kita menyimpan dokumen plan, kemudian terdapat revisi, maka dokumen tersebut disimpan kembali dengan nama yang berbeda. Nama-nama penyimpanan ini harus diatur sedemikian rupa sehingga tidak membingungkan. Hal ini merupakan salah satu contoh dari manajemen konfigurasi.

Tujuan-tujuan dari Manajemen Konfigurasi adalah :

  1. Untuk mengidentifikasikan perubahan
  2. Untuk mengontrol perubahan
  3. Untuk memastikan bahwa perubahan diimplementasikan dengan benar
  4. Untuk melaporkan perubahan kepada orang-orang yang berkaitan
Perubahan apa yang diatur ??
  1. Software code
  2. Data, yang terdiri dari test data dan database file
  3. Dokumen, yang terdiri dari dokumen SRS, Design, Project Schedule, test plan, test result
Faktor-faktor yang mempengaruhi persetujuan dari perubahan yang diajukan adalah
  1. kontribusi yang diharapkan
  2. urgency
  3. perubahan dari project timetable
  4. perubahan operational
  5. assurance effort
Baseline merupakan:
  • Kontrol pusat dari proyek
  • Ciptaan dari baseline biasanya berupa milestone
  • setiap orang menggunakan baseline awal yang sama
  • untuk mengganti baseline, butuh proses formal



Requirement Traceability Matrix

Requirement Traceability Matrix


Untuk membuat perangkat lunak, pembuat harus menentukan apa saja kebutuhan dari user yang melatarbelakangi pembuatan perangkat lunak tersebut. Setelah merinci kebutuhan yang didapat dari user, maka pembuat harus menentukan functional requirement yang merupakan hasil dari pengumpulan kebutuhan user. Selanjutnya, dari functional requirement tersebut, pembuat perangkat lunak harus mendokumentasikan desain yang meliputi use case, desain modul, dan sequence. Setelah desain dibuat, perangkat lunak dibangun. Untuk melakukan validasi, maka perangkat lunak yang sudah jadi tersebut harus dites. Setelah hasil tes benar-benar sesuai dengan yang diharapkan, maka perangkat lunak siap diluncurkan.


Agar menghasilkan dokumentasi yang sesuai, maka pembuat perangkat lunak harus dapat menggambarkan requirement traceability matrix yang benar-benar sesuai dengan proses pembuatan perangkat lunak yang disebutkan pada paragraf pertama. RTM berfungsi memastikan apakah perangkat lunak dapat memenuhi kebutuhan yang ditentukan di awal dengan menyelaraskan kebutuhan dengan hasil testing perangkat lunak. Jika ada kebutuhan yang tidak dapat dipenuhi, maka perangkat lunak tersebut tidak mampu menjawab kebutuhan dan perlu diperbaiki. Begitu juga, jika ada kebutuhan yang tidak selaras dengan hasil desain dan testing dari perangkat lunak, maka RTM dari perangkat lunak tersebut kurang baik, sehingga pembuat perangkat lunak tersebut harus memperbaiki dokumentasi perangkat lunaknya.


Berikut ini contoh dari RTM



Development and Quality Plan

Development dan Quality Plan termasuk dalam tahap Preproject Component pada Arsitektur SQA.
Development Plan memiliki beberapa komponen, diantaranya adalah :
  1. Project cost
  2. Project human resource
  3. Project time
  4. Project scope
  5. Project risk
  6. Project quality
  7. Project procurement
  8. Project integration
  9. Project communication
  10. Project interface
  11. software development standart dan development tools
  12. mapping of development process
  13. project milestone
  14. develoment facilities
  15. metode kontrol
(nomor 1 sampai 9 merupakan 9 knowledge area dalam Manajemen Proyek Teknologi Informasi)

Quality Plan memiliki beberapa komponen, diantaranya adalah :
  1. Tujuan kualitas
  2. Review aktifitas perencanaan, diantaranaya termasuk scope, type, procedure, schedule
  3. Rencana Pengujian (test) perangkat lunak
  4. Rencana acceptence test untuk pembangunan software eksternal
  5. Configuration management, meliputi pengelolaan kontrol perubahan

SQA Component


Komponen yang terdapat dalam SQA yaitu :
·         Pre-project SQA components
Komponen ini merupakan komponen awal yang terdiri dari kontrak awal dan perencanaan dalam pembangunan dan kualitas

·         Project life cycle SQA components
Komponen ini merupakan siklus dari pembangunan perangkat lunak. Siklus ini dibagi menjadi dua tahap. Tahap pertama adalah tahap siklus pembangunan. Terdapat berbagai metode siklus pembangunan dalam tahap ini, salah satunya adalah metode waterfall yang telah dijelaskan pada bab sebelumnya. Tahap berikutnya adalah siklus operasional dan perawatan perangkat lunak. Pernagkat lunak yang sudah jadi harus tetap dikontrol operasionalnya dan secara rutin dilakukan perawatan.

·         Quality infrastructure components
Komponen ini bertujuan untuk mencegah dan mengurangi kegagalan perangkat lunak serta meningkatkan produktifitas perangkat lunak. Komponen ini terdiri dari prosedur dan intruksi kerja sebagai acuan dalam kinerja proyek, template dan checklist yang disediakan untuk mempermudah dan menyempurnakan dokumentasi, staff training untuk melatih kinerja karyawan dalam implementasi perangkat lunak yang dibuat, aksi-aksi korektif dan preventif menghadapi kesalahan produk yang sudah dikirim ke pelanggan, manajemen konfigurasi untuk mengatur konfigurasi dokumentasi dan produk agar mudah dianalisa, dan kontrol dokumen yang digunakan untuk mengawasi dokumen pembangunan dan pengembangan proyek perangkat lunak agar dapat ditelusuri secara lengkap.

·         Quality management
Komponen ini terdiri dari project progrss control yang digunakan untuk mengawasi kesepakatan dalam jadwal proyek, manajemen resiko, dan budget. Selain itu, komponen ini juga terdiri dari Software Quality Metrics yang merupakan alat ukur kualitas dari perangkat lunak berdasarkan berbagai macam aspek dan Software Quality Cost yang merupakan alat ukur dari biaya yang dikeluarkan dalam penjaminan kualitas perangkat lunak ini.

·         Standards
Standar berfungsi untuk melakukan utilisasi pengetahuan dari pihak luar sehingga pengembang perangkat lunak dapat mengetahui apakah produk yang dihasilkan sesuai dengan standar yang banyak  digunakan oleh profesional. Standar kualitas dibagi menjadi dua. Yang pertama adalah standar manajemen kualitas. Standar ini digunakan untuk mengatur pembangunan dan perawatan perangkat lunak. Contoh standar ini adalah ISO 9001 yang dikeluarkan oleh International Standard Organization. Yang kedua adalah standar poses proyek. Standar ini lebih mengutamakan pada kinerja tim dalam pembangunan perangkat lunak. Contohnya adalah IEC 12207.

·         Organizational base-human components
Komponen ini bertujuan untuk mendukung implementasi dari SQA. Faktor kunci dari implementasi SQA adalah faktor manusia. Sehingga kinerja sumber daya manusia perlu ditingkatkan baik pada level manajer maupun personel lini bawah.

Senin, 18 Juni 2012

Faktor-Faktor Kualitas Perangkat Lunak

Menurut McCall’s, terdapat 11 faktor kualitas yang terbagi menjadi 3 kategori

  • Product Operation Factor : faktor – faktor ini berhubungan dengan requirement yang secara langsung       mempengaruhi operasi sehari-hari perangkat lunak. Faktor-faktor ini adalah:
    • Correctness : kondisi ketika program memenuhi segala sepesifikasi yang ditentukan 
    • Reliability : kondisi program yang tidak gagal menyediakan layanan, berfungsi dengan semestinya.
    • Efficiency : penggunaan sumberdaya dan line of code yang efisien
    • Integrity : faktor ini berhubungan dengan sistem keamanan perangkat lunak 
    • Usability : dapat digunakan dengan baik dan mudah oleh manusia
  • Product Revision Factors : faktor ini terdiri dari
    • Maintainability : upaya untuk memelihara perangkat lunak dengan mengidentifikasi kegagalan, memperbaiki kegagalan, dan memverifikasi keberhasilan koreksi
    • Flexibility : kemampuan perangkat lunak untuk dapat dimodifikasi dan dimaintain
    • Testability : berhubungan dengan testing IT untuk dapat melihat ada tidaknya kerusakan
  • Product Transition Factors : faktor ini terdiri dari
    • Portability : kemampuan adaptasi dari perangkat lunak terhadap lingkungan yang terdiri dari Hardware dan Sistem Operasi yang berbeda-beda
    • Reusability : berhubungan dengan transfer modul atau program untuk dibuat dan digunakan di aplikasi lain.
    • Interoperability : kemampuan untuk membangun interface dengan perangkat lunak lain.

Kamis, 07 Juni 2012

Software Testing : Antara Black Box dan White Box (part1)


  • Terdapat dua macam Software Testing yaitu Black Box testing dan White Box Testing

  • BlackBox testing merupakan software testing yang dilakukan terhadap struktur internal dari software. Lebih ditekankan pada fungsional setiap code, baik berdasarkan usecase maupun berdasarkan modul. Testing ini digunakan untuk memverifikasi apakah aplikasi yang telah dibuat telah berjalan tanpa error.

  • WhiteBox testing merupakan testing yang lebih menekankan pada kegunaan dari software yang telah diuat. Apakah sudah menghasilkan solusi yang tepat terhadap kebutuhan customer. Sehingga lebih menganalisa dampak software apakah diterima atau tidak oleh pengguna. Sehingga software tersebut dapat dikatakan valid atau tidak sesuai dengan pencapaian objektifnya.


Minggu, 03 Juni 2012

Sekilas Mengenai Komponen Arsitektur SQA





Komponen Software terdiri dari : data, code, procedure, documentation

Tantangan (challenge) SW :
==> uniqueness of SW development proces : complexity(large number of operational mode), visibility of product (invisible), nature of develpment and production process (kesalahan hanya dapat diketahui di fase developmnt saja)

==>lingkungan pembangunan metode SQA
pupils, hobbies, engineer-economics-mngmnt, profesional SW development
contrak kondisinya, butuh teamwork
buth relasi customer suplier
cooperation and coordination dg SW team lain
interface dg SW sistem lain
butuhnya lanjutkan project meski anggota berubah
butuhnya maintain SW pd periode tertentu

==>mengapa perlu quality : karena quality itu perlu untuk menhgindari SW error

==>SW Quality : derajat dimana sistem, komponen, atw prosess sesuai dg requiremenmt yg dispesifikasikan dan kebutuhan customer and user

==> quality faktor Mc Call :
correctness,->kebutuhan benar
reliability,-> batas min kegagalan
efficiency-> resource need
integrity-> security, autorization
usability-> kemampuan user atw staff untuk operasikan SW
maintenability->
flexibility-> user nya flexibel
testability
portability--> dpt adaptasi atw dijalankan di 2 kondisi
reusability->
interoperability-> interface dg other SW system,

==>SQA Komponen
      =>preproject SQA components : contract review, developmnet and quality plan
      =>komponen PLC:
  fase development :
review (formal design review==> melibatkan pihak external team, dan peer review==> beruntun,       internal team)
expert opinion==> untuk penilaian kualitas
software testing ==>
whitebox (ke dalam, code) blackbox(tampilan)
SW maintanence
external participant(sub contrak)
fase operatipnal and maintenence:
Sw maintenence

==>MACAM TESTING
unit testing==> per unit software atau hardware tertentu
modul testing ==> per modul
integration testing==> integrasi anatar modul software dan hardware, apakah seirama
system and functional testing==> secara keseluruhan apakah sesuai dg requirment awal
acceptance==>apakah sesuai dg custemer requirement, cocok apa gak
beta testing==> ad hoc,meibatkan user customer
Regression ==> cek jika ada perubahan, apakah tetep sesuai track awal
tools testing ==> RTM,

==>element development plan===> 9 knowledge area : cost, time, risk, procurement, quality, humen resourece, communication, scope, integration
===> PLC : inisiasi, planning, execution(req, desain, testing), closing=>produk, reengineering
===> SDLC : waterfall===> req definition, analisis, design, coding, system test, installation and
convertion, operation and maintenance
       
=>quality infrastructure componen
procedure, W.I
supporting device : template, checklist
training instruction : staff training, retraining, certificating
preventif action , corrective,
configuration management==> tools nya auudit, dependency tracking, reporting and support change rule, versioning, req tracing, repository, support linier evolution and tree

=>quality management
        => standart' components
        =>organizational base-human components