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