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.

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.

Software Quality Models

7 7 mkti4

View more PowerPoint from kamalbaktir

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.

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

Software Quality Metrics

Analisa Software Quality Factor

Tugas analisa faktor kualitas

View more presentations from kamalbaktir.

SOFTWARE

DEFINISI SOFTWARE

Menurut International Encyclopedy of Information Science (1997), software merupakan bagian dari komponen sistem komputer yang diprogram yang memungkinkan komputer untuk mencocokkan perintah yang diterima untuk memenuhi kebutuhan pengguna. Definisi ini juga mengkategorikan software ke dalam 3 kategori, yaitu :

Software sebagai sistem yang berperan mengendalikan jalannya perangkat komputer dan komponen software lain yang menunjang operasional komputer. Software dalam kategori ini dikenal sebagai sistem operasi, contohnya Windows, Linux, dan Mac.Intosh

Software sebagai program aplikasi yang berperan memenuhi tugas atau perintah tertentu dari sistem. Software dalam kategori ini dikenal sebagai software aplikasi, contohnya Microsoft Office untuk kebutuhan perkantoran, Adobe Photoshop untuk aplikasi gambar dan design, dan Mozilla Firefox untuk aplikasi penelusuran halaman web

Software sebagai perangkat yang menunjang pengembangan dan pembuatan software sebagai aplikasi. Software ini dikenal sebagai software pemrograman, yaitu software bahasa pemrograman seperti PHP, dan HTML.

Menurut Muffatto (2006), software merupakan rangkaian perintah yang dijalankan oleh komputer dimana software berjalan dalam perangkat keras komputer. Muffatto juga mengkontraskan software dengan hardware. Ia berpendapat software merupakan perintah dan sarana dalam menerjemahkan kebutuhan pengguna terhadap komputer, sedangkan hardware merupakan kamar dan pabrik pengolahan perintah tersebut.

PENYEBAB SOFTWARE ERROR

Terdapat sembilan penyebab software error, antara lain :

1.      Faulty requirement definition

2.      Client-developer communication failures

3.      Deliberate deviation from SW requirements

4.      Logical design errors

5.      Coding errors

6.      Non-compliance with documentation and coding instructions

7.      Shortcomings of the testing process

8.      Procedure errors

9.      Documentation errors

Sumber : Software Quality Assurance (Daniel Gallin)

Oleh Kelompok :

Achmad Kamal 5208100137

Innike Desy Kristianty DK 5209100034

Software Quality Factor

ANALISA SOFTWARE QUALITY FACTOR PADA

"PERANCANGAN DAN PEMBUATAN SISTEM INFORMASI AKUNTANSI PADA PERUSAHAAN MITRA PRODUKSI SIGARET"

Perusahaan Mitra Produksi Sigaret sudah menggunakan pencatatan transaksi dan pembuatan laporan akuntansi dengan sistem yang terkomputerisasi. Beberapa kekurangan yang ditemui pada sistem lama yaitu tampilan sistem belum berbasis graphic user interface (GUI) dan sistem belum mendukung Client-Server.

Sehingga, pada Tugas Akhir ini akan dibuat perangkat lunak sistem informasi akuntansi berbasis graphic user interface (GUI), mendukung teknologi Client-Server, sistem backup-restore, portabilitas dan konsolidasi laporan keuangan.

Hasil dari pembuatan Tugas Akhir ini berupa sistem informasi akuntansi dengan dukungan portabilitas sehingga aplikasi dapat digunakan baik terhubung dengan server (online

mode – server database) atau tidak terhubung dengan server (offline mode – virtual database). Aplikasi juga mampu menampilkan laporan keuangan konsolidasi yang merupakan gabungan dari laporan keuangan kantor cabang.

Analisa Faktor Usability oleh McCall :

·        Pengertian Usability

Usaha yang diperlukan untuk mempelajari, mengoperasikan, menyiapkan masukan dan mengartikan keluaran program.

·        Analisa Tugas Akhir

Seperti yang dipaparkan di atas bahwa Tugas Akhir ini memiliki tahapan yang harus dilalui untuk , yaitu : Requirement analysis, Analysis/preliminary design, Detailed design, dan Implementation, Pembuatan Aplikasi, dan Pengujian Aplikasi

·        Resume
Pada tahap requirement analysis terdapat 4 proses yang dilakukan, yaitu :

o   Functional requirements : mendefinisikan apa yang seharusnya sistem dapat lakukan. Functional requirements meliputi kebutuhan fungsional dan non-fungsional yang diperoleh dari informasi tentang legacy system yang dikembangkan dan analisis survei pihak terkait

o   Domain modeling : menyaring dan memperbaharui entitas sepanjang projek dan merefleksikan pemahaman “ruang masalah”. Domain modeling bertujuan menyelesaikan masalah komunikasi pada projek dengan menetapkan vocabulary umum yang didapat dari ruang masalah. Domain modeling merupakan pencegahan pertama jika terjadi kebutuhan yang ambigu

o   Behavioral requirements : mendefinisikan bagaimana user dan sistem akan berinteraksi

o   Milestone 1 : Requirements : memastikan bahwa use case sesuai dengan harapan customer dengan meninjau ulang functional requirements

Pada tahap analysis/preliminary design terdapat 3 proses yang dilakukan, yaitu :

o   Robustness analysis

o   Memperbaharui domain model

o   Milestone 2

Pada tahap detailed design terdapat 4 proses yang dilakukan, yaitu :

o   Sequence diagramming : menjelaskan proses yang terjadi pada sistem dalam mengolah object. Perancangan sequence diagram mengacu pada use case diagram yang telah didefinisikansebelumnya.

o   Membuat class diagram : class diagram memiliki semua entitas yang ada pada robustness diagram, memiliki fungsi-fungsi operasi yang ada pada sequence diagram, dan memiliki atribut yang ada pada GUI

o   Membersihkan model statis : langkah akhir sebelum melakukan tinajuan ulang terhadap detail desain. Dengan demikian pekerjaan harus sesuai dengan proses bisnis, kebutuhan proyek, aplikasi desain framework, topology Deployment, dan seterusnya

o   Milestone 3 : Critical design review : proses ini bertujuan untuk memastikan bagaimana desain lebih detil sesuai dengan apa yang dispesifikasikan kebutuhan, meninjau ulang kualitas desain, memeriksa kelanjutan pesan dari diagram sequence.

Pada tahap implementation terdapat 3 proses yang dilakukan, yaitu :

o   Coding/unit testing : menulis kode program dan melakukan pengujian unit

o   Integration and scenario testing : melakukan pengujian integrasi pada use case dengan scenario basic course dan alternate course

o   Code review and model update : meninjau ulang kode program dan memperbaharui model untuk langkah pengembangan selanjutnya.

Pada tahap pembuatan aplikasi rancangan yang telah ditentukan sebelumnya akan digunakan untuk membuat aplikasi. Kemudian untuk tahap pengujian apliaksi dilakukan pengujian aplikasi apakah semua fungsi yang ada dapat berjalan di aplikasi. Pengujian program yang telah dibuat, apakah sudah sesuai atau belum dengan tujuan tugas akhir. Lalu Analisis hasil output dari program, apakah output yang dihasilkan sudah tepat. Bila ada fungsi yang belum berjalan, maka perlu dilakukan revisi aplikasi sehingga semua fungsi dari aplikasi dapat berjalan semua

Analisa Faktor Portabilitas :

Pengertian Portabilitas

• Persyaratan Portabilitas cenderung menekankan pada kemampuan adaptasi dari sistem perangkat lunak untuk lingkungan lainnya yang terdiri dari hardware yang berbeda, sistem operasi yang berbeda, dan sebagainya. Persyaratan ini memungkinkan untuk terus menggunakan perangkat lunak yang sama dalam situasi yang beragam atau untuk menggunakannya secara bersamaan dalam situasi perangkat keras dan sistem operasi yang beragam.

Analisa Portabilitas pada Tugas Akhir ini :

• Aplikasi yang dirancang dan dibangun ini merupakan aplikasi dengan menggunakan bahasa pemrograman Visual Basic .Net dan database MySQL. Berdasarkan abstrak dari Laporan Tugas Akhir ini, pembuatan aplikasi dimulai dengan membuat desain dari sistem informasi akuntansi. Desain proses aplikasi serta desain database menggunakan UML. Sistem informasi akuntansi ini mempunyai dukungan portabilitas sehingga dapat digunakan baik terhubung dengan server (online mode – server database) atau tidak terhubung dengan server (offline mode – virtual database). Aplikasi yang dibuat ini juga dapat menampilkan laporan keuangan konsolidasi yang merupakan gabungan dari laporan keuangan kantor cabang.
  Setelah menganalisa Tugas Akhir ini, dapat kami temukan bahwa terdapat keunggulan dari Quality Factor Software pada bagian Portability. Pada Laporan Tugas akhir ini, dijelaskan bahwa aplikasi ini menggunakan Pemrograman ADO.NET pada XML. Pemrograman ADO.NET pada XML digunakan untuk dukungan portabilitas, yaitu mengaktifkan fitur Offline mode pada aplikasi aSIA Project. Dalam keadaan standart (Online mode), aplikasi berjalan dengan mengambil data dari database server (MySQL). Sedangkan jika aplikasi tidak terhubung dengan database server, aplikasi      ini berjalan dengan menggunakan database virtual. Database virtual adalah teknologi pemrograman ADO.NET pada XML dengan memadukan XML Schema dan XML File. Selain itu, kelebihan dari fitur Offline mode yaitu user dapat menginputkan transaksi tanpa harus terhubung dengan server dan cukup meng-import file transaksi (XML File) untuk memperbaharui database server. Dijelaskan pula bahwa user harus terlebih dahulu meng-export file transaksi terakhir dari database server agar dapat menggunakan fitur offline mode dan hasil dari export file transaksi berupa XML File yang kemudian digunakan sebagai sumber data dan media penyimpanan saat menjalankan fitur Offline mode.
  
  Dari penjelasan laporan tersebut, dapat kami analisis, bahwa aplikasi ini memenuhi Faktor Kualitas Perangkat Lunak yaitu Portability, karena dapat dijalankan pada kondisi offline mode dan juga online mode.

Sumber :

• Laporan Tugar Akhir dengan judul : Perancangan dan Pembuatan Sistem Informasi Akuntansi pada Perusahaan Mitra Produksi Sigaret.
• Software Quality Assurance (Daniel Galin)

Nama Kelompok :

Achmad Kamal 5208100137

Innike Desy Kristianti DK 5209100034

Study Kasus Faulty Requirement Definition

Pengertian Faulty Requirement Definition

Salah satu penyebab error pada software adalah Faulty Requirement Definition (Kesalahan Definisi Kebutuhan). Faulty Requirement Definition ini biasanya dibuat oleh klien. Error paling umum dari jenis ini adalah :

• Erroneous definition of requirements. 
• Tidak adanya persyaratan penting.
• Ketidaklengkapannya ketentuan dari persyaratan. Misalnya, salah satu persyaratan dari sistem software pajak lokal kotamadya mengacu diskon diberikan kepada berbagai segmen penduduk: warga senior, orang tua dari keluarga besar, dan sebagainya. Namun, diskon yang diberikan kepada siswa tidak termasuk dalam dokumen persyaratan.
• Pencantuman persyaratan yang tidak perlu, fungsi yang tidak diharapkan atau diperlukan dalam waktu dekat

Studi Kasus Faulty Requirement Definition

"Kegagalan Sistem Field Data Collection Automation"

Pada sensus penduduk tahun 2000 ke bawah, Biro Sensus Amerika Serikat telah mengimplementasikan system perangkat lunak TIGER (Topologically Integrated Geographic Encoding and Referencing). System ini menyediakan data lengkap mengenai alamat penduduk beserta wilayah geografisnya seperti peta jalan, badan air, kerata api, dll. Sehingga, Biro Sensus hanya perlu mengirimkan surat ke seluruh penduduk amerika serikat via Pos dengan data alamat yang didapat pada TIGER. Penduduk Amerika Serikat mengembalikan surat sensus yang telah diisi ke Biro Sensus melalui Pos juga. Petugas Sensus hanya mendatangi rumah penduduk untuk melakukan pengambilan data hanya pada penduduk yang tidak mengirim feedback. Proses ini berjalan dengan sukses, namun dirasa kurang efektif, karena justru melibatkan banyak pihak di luar biro sensus, seperti Pos dan Industri system Informasi Geografis.

Pada tahun 2000, Biro Sensus Amerika Serikat berinisiatif untuk melakukan gebrakan metode sensus penduduk dengan menggunakan system FDCA (Field Data Collection Automation) dengan proyek yang dipesan ke perusahaan Harris Corporation.

FDCA merupakan sistem mobile yang akan memungkinkan enumerator bekerja di lapangan untuk mengumpulkan dan mengirimkan data kembali ke kantor, sehingga dapat mengotomatisasi pengumpulan data lapangan. Proses kerjanya adalah, dengan software FDCA ini, para petugas sensus mendatangi penduduk untuk melakukan wawancara, dan data langsung diinputkan ke Sistem FDCA ini secara mobile menggunakan hardware yang disediakan. Sehingga data akan langsung masuk ke server pada saat itu juga. Biro merencanakan untuk menggunakan sistem ini tidak hanya untuk mengumpulkan dan mengirimkan data selama menyisir dan wawancara, tetapi juga untuk mengelola operasi lapangan dan terintegrasi juga dengan TIGER. Sehingga, dengan adanya Software FDCA ini, data hasil wawancara langsung dapat diterima pusat dan diolah secara otomatis untuk menghasilkan informasi yang diperlukan dengan waktu yang singkat dan efisien.

Pada 1 Mei 2008, Sistem ini diuji coba untuk melakukan sensus penduduk, namun hasil penelitian menunjukkan bahwa komputer genggam bergerak lambat, kadang-kadang membeku, dan tidak mengirimkan data secara konsisten. Selain itu, tes menunjukkan masalah dengan program yang dirancang untuk mengelola operasi di lapangan. Biro tersebut mengumumkan bahwa mereka akan perlu untuk memperpanjang jadwal pengembangan software ini dan mengalokasikan dana lebih jauh untuk menyelesaikan proyek. Pada bulan Agustus 2009, diumumkan bahwa enumerator akan menurunkan penggunaan perangkat mobile dengan system FDCA ini selama proses wawancara dan bergantung secara eksklusif pada operasi berbasis kertas. Kontrak baru hanya akan mengimplementasikan untuk update alamat berbasis genggam, dan bahkan dengan ruang lingkup sangat berkurang, biayanya adalah $ 200 juta lebih tinggi dari anggaran asli untuk seluruh system.

Kantor Government Accountability Officer (GAO) USA menganalisa kegagalan Software ini,

Proyek ini gagal karena:

• Kegagalan untuk mengidentifikasi penyampaian (deliverable) dan tonggak(milestone) kunci proyek.
• Kegagalan untuk mendapatkan pemangku kepentingan membeli pada rencana proyek, termasuk parameter proyek utama seperti estimasi biaya dan jadwal.
• Kegagalan untuk memvalidasi kebutuhan utama proyek.
• Kegagalaann untuk menetapkan tanggung jawab atas risiko dan untuk mempersiapkan rencana mitigasi.
• Kegagalan untuk mendefinisikan metrik kunci untuk pelacakan kontrak dan kekeliruan eksekutif

Selain itu,

•       Inspektur Jenderal Departemen Perdagangan menyatakan penyebab masalah ini adalah :

–      "kegagalan manajer senior Biro Sensus di tempat pada saat untuk mengantisipasi persyaratan TI yang kompleks, yang terlibat dalam mengotomatisasi sensus."

•      Biro sensus sering mengubah persyaratan kebutuhan proyek software ini, sehingga reqirement dari biro sensus terhadap FDCA ini sering berubah-ubah ditengah jalan ketika proyek sudah berjalan dan setiap ada perubahan, biaya kontrak dengan Harris Corporation selalu meningkat

Sehingga, menjadi pelajaran, bahwa terdapat Faulty Requirement Definition terhadap Software ini yang menyebabkan Software error. Seharusnya, kedua belah pihak harus menyepakati requirement yang telah didefinisikan bersama. Berubah-ubahnya kebutuhan ditengah jalan proyek menunjukkan bahwa pendefinisian kebutuhan di awal proyek belum jelas dan belum fix, sehingga menerjemahkannya ke dalam proyek pembuatan software pun tidak benar dan sesuai dengan yang dibutuhkan.

Hal ini menjadi bahan evaluasi kita, jika memiliki proyek untuk membuat software, bahwa perlu secara jelas mendefinisikan kebutuhan perangkat lunak agar terjadi kesepakatan yang jelas antara pihak customer dengan developer software.

Sumber : Ethics in Information Technology 3^rd Edition (George W. Reynolds)
Nama Kelompok :
Achmad Kamal 5208100137
Innike Desy Kristianti DK 5209100034

Software Quality Challenge

The Challenge of Software Quality on Prezi