Pengujian black-box yaitu melakukan pemeriksaan atau testing mengenai fungsionalitas dari perangkat lunak tanpa mengetahui keadaan dari kondisi internal sistem (seperti code) atau komponen dan hanya berfokus pada output yang dihasilkan. Pengujian blackbox bertujuan untuk menguji fungsionalitas perangkat lunak sesuai dengan persyaratan dan kebutuhan dalam pengembangan perangkat lunak. Dan ujicoba blackbox bukanlah alternatif dari ujicoba whitebox, yang mana uji coba blackbox melakukan pendekatan dengan cara melengkapi untuk menemukan kesalahan lainnya ketika tidak mmenggunakan metode whitebox. Serta hasil dari testing dengan metode blackbox dapat menghasilkan fungsional dari perangkat lunak yang diuji.
Keuntungan menggunakan uji blackbox adalah:
1. Tidak diperlukan pengetahuan dalam pemrogaman untuk melakukan uji kualitas dengan metode tersebut.
2. Hal ini memungkinkan tester untuk melakukan hampir semua kelas tes atau use case.
3. Membutuhkan sumber daya jauh lebih sedikit.
Ada keuntungan, ada juga kerugiannya, yaitu kita tidak memiliki kemungkinan untuk menguji kualitas codingnya.
Dengan ujicoba blackbox kita dapat menemukan kesalahan dalam beberapa kategori, diantaranya:
1. Fungsi-fungsi yang salah atau hilang
2. Kesalahan interface
3. Kesalahan dalam struktur data atau akses database eksternal
4. Kesalahan performa
5. kesalahan inisialisasi dan terminasi
Rabu, 29 Mei 2013
Melakukan Pengujian Perangkat Lunak/Software
Dalam membangun sebuah perangkat lunak ada saat dimana kita harus melakukan pengujian. Tujuan software testing adalah untuk memberikan stakeholder mengenai informasi tentang kualitas dari produk atau jasa yang diuji. Serta dengan adanya pengujian terhadap perangkat lunak, stakeholder dapat memahami serta mengetahui risiko yang terdapat dalam perangkat lunak yang dilakukan pengujian.
Pengujian disini termasuk dalam UAT (User Acceptance Test), yaitu untuk menguji apakah software yang dibangun melalui proses SDLC telah dapat dikatakan layak digunakan. Lalu kapan sebenarnya kita harus melakukan pengujian/testing? Pengujian sebuah perangkat lunak idealnya dilakukan tersebar sejak awal.
Software testing dapat juga sebagai proses memvalidasi dan memverifikasi bahwa sebuah program komputer / aplikasi / produk:
Pengujian perangkat lunak bergantung pada metode pengujian yang digunakan serta dapat diterapkan pada setiap saat dalam proses pembangunan. Secara tradisional sebagian besar upaya uji terjadi setelah persyaratan telah ditetapkan dan proses pengkodean telah selesai. Dengan begitu, metodologi tes diatur oleh metodologi pengembangan perangkat lunak yang dipilih.
Definisi testing menurut IEEE
1. Proses mengoperasikan sistem atau komponen pada kondisi tertentu, mengamati hasil, dan membuat evaluasi terhadap beberapa aspek dari sistem atau komponen.
2. Proses analisis item perangkat lunak untuk mendeteksi perbedaan antara yang ada dan kondisi yang diperlukan dan mengevaluasi fiturfitur dari item perangkat lunak
Sedangkan menurut Galin :
Pengujian atau testing perangkat lunak adalah proses yang dilakukan oleh tim khusus pengujian yang mana beberapa unit perangkat lunak tersebut terintegrasi atau paket perangkat lunak yang diperiksa secara keseluruhan dengan menjalankan program pada komputer.
nb : Kalian bisa membaca blog post ini untuk mengetahui kenapa kita harus melakukan pengujian sejak awal
Pengujian disini termasuk dalam UAT (User Acceptance Test), yaitu untuk menguji apakah software yang dibangun melalui proses SDLC telah dapat dikatakan layak digunakan. Lalu kapan sebenarnya kita harus melakukan pengujian/testing? Pengujian sebuah perangkat lunak idealnya dilakukan tersebar sejak awal.
Software testing dapat juga sebagai proses memvalidasi dan memverifikasi bahwa sebuah program komputer / aplikasi / produk:
- Sesuai dengan requirement yang ditentukan untuk design dan pengembangannya.
- Bekerja sesuai dengan yang diharapkan.
- Memenuhi kebutuhan stakeholder.
Pengujian perangkat lunak bergantung pada metode pengujian yang digunakan serta dapat diterapkan pada setiap saat dalam proses pembangunan. Secara tradisional sebagian besar upaya uji terjadi setelah persyaratan telah ditetapkan dan proses pengkodean telah selesai. Dengan begitu, metodologi tes diatur oleh metodologi pengembangan perangkat lunak yang dipilih.
Definisi testing menurut IEEE
1. Proses mengoperasikan sistem atau komponen pada kondisi tertentu, mengamati hasil, dan membuat evaluasi terhadap beberapa aspek dari sistem atau komponen.
2. Proses analisis item perangkat lunak untuk mendeteksi perbedaan antara yang ada dan kondisi yang diperlukan dan mengevaluasi fiturfitur dari item perangkat lunak
Sedangkan menurut Galin :
Pengujian atau testing perangkat lunak adalah proses yang dilakukan oleh tim khusus pengujian yang mana beberapa unit perangkat lunak tersebut terintegrasi atau paket perangkat lunak yang diperiksa secara keseluruhan dengan menjalankan program pada komputer.
nb : Kalian bisa membaca blog post ini untuk mengetahui kenapa kita harus melakukan pengujian sejak awal
Apa Pentingnya Menjaga Kualitas Software?
Dalam sebuah pekerjaan, baik itu pekerjaan sekolah, kuliah maupun dalam dunia kerja setiap apa yang dikerjakan selalu ada tuntutan dalam pengerjaannya agar sesuai dengan yang diharapkan. Nah, agar pekerjaan dapat sesuai dengan apa yang diharapkan maka ada pengukuran kualitas yang menjadi pegangan atau referensi. Lalu bagaimana dengan software? Dalam pembuatan software ada yang namanya proses dan alur untuk pembuatannya, yaitu software development life cycle (SDLC). Seperti namanya Development Life Cycle, artinya ada siklus hidup dalam pengembangan software. Ada banyak metode dalam SDLC, kita dapat memilihnya sesuai kebutuhan software yang akan dibuat. Tentu saja, dalam siklus itu ada banyak hal yang tergabung dan berpengaruh untuk hasil akhir sebuah software, mulai dari tim developer, klien dan lain sebagainya yang berkaitan baik langsung dan tidak langsung untuk pembuatan software.
Oke, jadi kalau dalam bayangan kalian untuk membuat sebuah software hanya diperlukan seorang yang dewa yang menguasai banyak bahasa untuk melakukan coding dan buzzz lahirlah sebuah software, maka buang jauh-jauh bayangan tersebut.
Nah, dalam life cycle pembuatan software itulah yang akan menentukan apakah software tersebut bisa dikatakan berkualitas atau tidak.
Dari posting di sini kita bisa tahu penyebab jika sebuah software tidak dimanage dengan baik sehingga menghasilkan kualitas yang buruk. Lalu apa saja dampak jika kita tidak dapat menjaga kualitas dalam life cycle pembuatan sebuah software?
-product fail
-tidak sesuai dengan yang dijanjikan
-terlambat
-kesulitan dan frustasi dalam mengimplementasikannya
Tidak hanya itu saja, ada lagi dampak lanjutannya jika sebuah perusahaan tidak menjaga kualitas softwarenya
-reputasi perusahaan
-kehilangan pelanggan, ini akan sangat buruk terutama jika pelanggan tersebut menyebarkan kepada teman-temannya
-biaya yang membengkak untuk kembali membuat dan memperbaiki software
-selain biaya, waktu juga akhirnya terbuang dan butuh waktu lebih lama
Jadi sekarang kita sama-sama tahu, pentingnya menjaga kualitas software
Oke, jadi kalau dalam bayangan kalian untuk membuat sebuah software hanya diperlukan seorang yang dewa yang menguasai banyak bahasa untuk melakukan coding dan buzzz lahirlah sebuah software, maka buang jauh-jauh bayangan tersebut.
Nah, dalam life cycle pembuatan software itulah yang akan menentukan apakah software tersebut bisa dikatakan berkualitas atau tidak.
Dari posting di sini kita bisa tahu penyebab jika sebuah software tidak dimanage dengan baik sehingga menghasilkan kualitas yang buruk. Lalu apa saja dampak jika kita tidak dapat menjaga kualitas dalam life cycle pembuatan sebuah software?
-product fail
-tidak sesuai dengan yang dijanjikan
-terlambat
-kesulitan dan frustasi dalam mengimplementasikannya
Tidak hanya itu saja, ada lagi dampak lanjutannya jika sebuah perusahaan tidak menjaga kualitas softwarenya
-reputasi perusahaan
-kehilangan pelanggan, ini akan sangat buruk terutama jika pelanggan tersebut menyebarkan kepada teman-temannya
-biaya yang membengkak untuk kembali membuat dan memperbaiki software
-selain biaya, waktu juga akhirnya terbuang dan butuh waktu lebih lama
Jadi sekarang kita sama-sama tahu, pentingnya menjaga kualitas software
Selasa, 28 Mei 2013
Quality of Software
Apabila kita memiliki suatu software yang mana guna untuk dipasang di dalam hardware tentunya membutuhkan software yang berkualitas. Guna nantinya apabila memakai software yg berkualitas maka akan berpengaruh pada kinerja dari software itu sendiri kedepannya. Tentunya dalam suatu perusahaan ketika menggunakan software, diharapkan nantinya tidak menggangu proses bisnis. Dalam pembahasan kali ini, kami akan memaparkan bagaimana software yang berkualitas.
Di dalam software terdapat 4 komponen yang mana meliputi program komputer, prosedur, dokumentasi dan data yang sesuai yang mendukung sistem dalam software. Dan 4 komponen tersebut sangat dibutuhkan guna memastikan kualitas dari sebuah software development maupun ketika maintenance-nya. Suatu software yang berkualitas adalah software yang dapat memenuhi permintaan dari pelanggan yang mana nantinya akan menghasilkan kepuasaan dari pelanggan (Juran,1998), dan tentunya software yang berkualitas akan jauh dari software error, software yang cacat atau memiliki kekurangan dan juga software yang gagal.
Asal-usul dari kegagalan suatu perangkat lunak yaitu kesalahan yang dibuat oleh programmer yang mana, sebuah kesalahan bisa menjadi kesalahan tata bahasa dalam satu atau lebih dari baris kode, atau kesalahan logika dalam memenuhi kebutuhan pelanggan. Namun, tidak semua error yang terjadi dalam perangkat lunak berasal dari kesalahan yang terdapat dalam perangkat lunak. Seperti terdapat kesalahan pada baris kode yang tidak cocok dengan fungsi tertentu sehingga menyebabnya perangkat lunak menjadi gagal. Menurtu buku Galin terdapat 9 penyebab kesalahan perangkat lunak yang mana diklasifikasikan sesuai dengan tahapan proses pengembangan perangkat lunak :
- Kesalahan dalam mendefinisikan kebutuhan, yang mana biasanya klien atau pelanggan lupa dalam mendefinisikan kebutuhannya secara mendetail, sehingga terdapat kebutuhan yang tertinggal untuk didefinisikan dan membuat programmer dalam implementasinya kurang memenuhi permintaan dari pelanggan.
- Kesalah pahaman komunikasi antara pengembang (programer) dengan customer dalam mengubah permintaan menjadi software yang diinginkan.
- Penyipangan yang terjadi karena suatu hal yang disengaja. Seperti ketika pelanggan tidak memiliki dana yang mencukupi untuk menghasilkan perangkat lunak sehingga menyebabkan kebutuhannya dikurangi tanpa adanya analisa terlebih dahulu, kesengajaan yang dilakukan oleh tim pengembang perangkat lunak seperti tidak melakukan persetujuan kepada klien terhadap hasil yang dikerjakan dll. Hal tersebut dapat menyebabkan perangkat lunak tidak stabil.
- Design logika salah yang mana biasanya dilakukan oleh arsitek, analis dan programer perangkat lunak. Hal ini terjadi karena kode yang salah dimasukkan untuk memunculkan permintaan pelanggan, kelalaian dalam memperhitungkan kode operasi yang ilegal dll.
- Kesalahan dalam bahasa pemrograman
- Ketidak sesuaian antara dokumentasi dengan instruksi koding, biasanya terjadi karena kesulitan dalam berkoordinasi dengan tim, memahami posisi masing-masing yang dierjakan di dalam suatu tim.
- Ketika proses testing kurang, yang dimaksud dengan kurang yaitu kurang dalam rencana testing, kurang lengkap dalam mengoreki eror yang menyebabkan gagal dalam dokumentasi dan laporan.
- Eror dalam menjalankan prosedur dalam pengembangan maupun pembuatan
- Eror dalam dokumentasi
Minggu, 26 Mei 2013
SQA Context-Between Industrial product and Software
Di dalam post ini kami akan menjelaskan mengenai SQA yang mana di dasari dengan perbedaan dari produk ndustrial dan pengembangan software.
Dalam pengembangan maupun
pembuatan software tidak ada yang jauh dari kecacatan. Namun kecacatan atau
kekurangan yang didapat dalam pengembangan software maupun pembuatannya tidak
mudah dideteksi jika dibandingkan dengan pembuatan produk industri. Jika dalam
produk idustri kecacatan nya dapat dengan mudah dideteksi dan juga terlihat.
Berikut di bawah merupakan penjabaran mengapa
software lebih sulit untuk dideteksi kekurangan:
- Software merupakan produk yang kompleks karena software memiliki operational mode yang lebih kompleks seperti koding yang berhubungan dengan berbagai macam fungsi didalamnya sehingga lebih rumit untuk dideteksi kekurangannya.
- Bentuk dari software itu sendiri tidak terlihat dengan jelas yang mana software merupakan suatu aplikasi yang ditanamkan di dalam hardware. Lain halnya dengan LCD komputer bentuknya terlihat dengan jelas. Apabila terjadi kecacatan maka akan terlihat dengan jelas kekurangannya
Sehingga dengan begitu dengan adanya kekurangan yang sering terjadi ketika pembuatan dan pengembangan maka dibutuhkan SQA (Software Quality Assurance) . Yang mana SQA merupakan suatu cara atau alat untuk melakukan pemantauan proses rekayasa perangkat lunak dan metode yang digunakan untuk memastikan kualitas dari software itu sendiri. Hal ini dilakukan dengan cara audit sistem manajemen mutu di dalam sistem perangkat lunak yang dibuat. Pemantauan dimulai dari pengembangan perangkat lunak, yang mencakup proses seperti perancangan perangkat lunak, coding, kontrol kode sumber, review kode, manajemen perubahan, manajemen konfigurasi, dan manajemen rilis.
Karakteriktik dari SQA yaitu sebagai berikut:
- Adanya kontrak antara pengembang software dengan klien, yang mana kontrak merupakan komitmen yang digunakan dalam pengembangan software dan maintenance.
- Mengutamakan hubungam pelanggan dengan supplier, hal tersebut digunakan untuk kelanjutan dalam hubungan kerja, agar nantinya apabila dibuthkan pertimbangan perubahan, diskusi perubahan dan penerimaan perubahan akan lebih mudah untuk di bicarakan dan dikerjakan.
- Bekerja sama guna untuk pencapaian target waktu kerja, penggabungan dari macam-macam keahlian yang dimiliki karyawan. Sehingga antar karyawan tim dapat saling membatu dengan keahlian masing-masing.
- Kooperatif dan koordinasi dengan antar team pengembang software dan hardware yang terdapat di dalam organisasi.
Senin, 01 April 2013
Flexibility VS Reusability
Flexibility
Menurut Wikipedia Flexibility adalah bagaimana sebuah software produk diakomodasi pada software lain. Jadi Flexibility menurut metode McCall bisa dikatakan sebagai upaya yang dilakukan untuk melakukan modifikasi dan perubahan supaya bisa disesuaikan dengan kegunaan lainnya.
Contoh:
Reusability
Masih menurut Wikipedia Reusability adalah penggunaan modul software untuk pengembangan produk software lainnya. Reusability berkaitan dengan paket dan lingkup dari fungsi yang dilakukan oleh software tersebut. Tolok ukur yang menggambarkan seberapa banyak bagian dari software tersebut dapat digunakan kembali pada program lainnya.
Contoh:
Untuk flexibility masuk dalam produk revision, sedangkan reusability masuk dalam product transition maka bisa dikatakan bahwa untuk flexibility maka sebuah software dapat dilakukan revisi atau perubahan untuk dapat digunakan kembali. Sedangkan untuk reusability sebuah software dapat dilakukan sebuah transisi penggunaannya untuk pengembangan produk yang lain.
Menurut Wikipedia Flexibility adalah bagaimana sebuah software produk diakomodasi pada software lain. Jadi Flexibility menurut metode McCall bisa dikatakan sebagai upaya yang dilakukan untuk melakukan modifikasi dan perubahan supaya bisa disesuaikan dengan kegunaan lainnya.
Contoh:
- Untuk rancang bangun perangkat lunak pengelolaan surat masuk di Kabupaten Buton Utara dapat dilakukan sedikit modifikasi agar penggunaan perangkat lunak dapat digunakan juga pada pengelolaan surat keluar.
- Penggunaan perangkat lunak pengelolaan surat masuk di Kabupaten Buton Utara juga dapat dilakukan modifikasi untuk digunakan untuk pengelolaan surat masuk pada Kabupaten lain dengan penyesuaian pada beberapa aspek seperti alur,dsb.
- Rekayasa perangkat lunak WinCC oleh Siemens yang digunakan untuk mengkonfigurasi perangkat operator SIMATIC dari seri x70 dan x77 pada PC berbasis HMI dengan WinCC.
Reusability
Masih menurut Wikipedia Reusability adalah penggunaan modul software untuk pengembangan produk software lainnya. Reusability berkaitan dengan paket dan lingkup dari fungsi yang dilakukan oleh software tersebut. Tolok ukur yang menggambarkan seberapa banyak bagian dari software tersebut dapat digunakan kembali pada program lainnya.
Contoh:
- Penggunaan modul software untuk tools programming dalam pembuatan game yang dapat diaplikasikan pada beberapa pembuatan game yang berbeda.
- Modul script gerakan player atau sistem battle pada sebuah game dapat diadopsi pada beberapa game.
- Modul-modul yang digunakan pada software minimarket yang dapat digunakan kembali sesuai kebutuhan yang diperlukan pada setiap software yang berbeda.
Untuk flexibility masuk dalam produk revision, sedangkan reusability masuk dalam product transition maka bisa dikatakan bahwa untuk flexibility maka sebuah software dapat dilakukan revisi atau perubahan untuk dapat digunakan kembali. Sedangkan untuk reusability sebuah software dapat dilakukan sebuah transisi penggunaannya untuk pengembangan produk yang lain.
Senin, 25 Maret 2013
Revisi dan Tambahan Software Quality Factor dalam Perangkat Lunak Pengelolaan Surat Masuk
Sebelumnya saya akan menjelaskan
sedikit mengenai McCalls’s Model. Yang mana kali ini, saya akan melalukan
pembahasan mengenai Software Quality dengan dengan menggunakan McCall’s Model
dan jug nantinya dalam pebejalasan kali ini, saya akan mecoba memberikan contoh
dari judul TA senior saya di Sistem Informasi ITS dengan menggunakan faktor
McCalls’s Model.
Apa itu McCalls’ s Model Software Quality Factor?
Suatu metode dalam kualitas
software yang tertua, yang mana di dalamnya terdapat 11 karakteristik atau
faktor untuk menilai kualitas pada Software. Awalnya model ini dibuat oleh
McCalls pada tahun 1977 untuk Angkatan Udara AS agar dapat menjebatani
kesenjangan antara pengguna dan pengembang.
McCalls’s model memiliki 11 faktor yang mana 11 faktor
tersebut memiliki 3 tipe fakotr software kulitas yaitu product revision, product transisi, dan product operation.
- Product Revision
Faktor yang mengidentiifikasikan
kualitas dari software yang yang nantinya dapat berpengaruh serta
mengubah software yang dinilai , faktornya yaitu:
Maintainability : kemampuan untuk memperbaik
kekurangan pada software
Flexibility : Kemampuan untuk melakukan
perubahan
Testability : Kemampuan untuk validasi
persyartan perangkat lunak
- Product Transition
Faktor yang mengidentifikasi
kualitas dari suatu software yang nantinya dapat berpengaruh terhadap kemampuan beradaptasinya software pada
lingkungan yang baru, faktornya yaitu:
Portability : Interaksi software dengan hardware
Reusability : Tingkat
kemudahan penggunaan software dalam
konteks yg berbeda
Interiperability : Tingkat kemudahan penggunaan software sehingga dapat
digunakan dalam software apa saja
- Product Operation
Faktor yang mengidentifikasikan kualitas dari suatu software dengan
menggunakan faktor yang ada, utnuk
mengetahui sejauh mana software
tellah memenuhi spesifikasi yang ada, faktornya yaitu :
Correctness : Adanya
kesusaian dengan yang dijanjikan
Reliability : Ketika
dibutuhkan sistem tersebut dapat diakses
Eficiency : Sumber daya yang digunakan apakah efisien atau
tidak.
Integrity : Perlindungan
atau keamanan dari software
Usability : Kecepatan dalam memahami software yang dibuat (survey)
Kemudian setelah mengetahui Mc Calls faktor apa saja, disini kami menggunakan hasil TA yang telah dianalisa terlebih dahulu oleh pranata, yaitu mengenai :
Rancang Bangun Perangkat Lunak untuk Workflow Pengelolaan Surat Menyurat Dinas Bagian Surat Masuk Di Kabupaten Buton Utara
Kebutuhan fungsional utama yang akan digunakan
yaitu :
- Sistem dapat menambah data surat masuk.
- Sistem dapat melihat daftar surat masuk.
- Sistem dapat melihat daftar surat masuk yang didisposisikan oleh pejabat atasan.
- Sistem dapat melihat detail surat masuk.
- Sistem dapat melakukan pencarian surat masuk.
- Sistem dapat mengirimkan surat masuk ke pejabat lain.
- Sistem dapat melakukan disposisi surat
- Sistem dapat melihat status surat.
- Sistem dapat mengirim pesan pemberitahuan/notifikasi.
Disamping kebutuhan fungsional utama
yang telah disebutkan di atas, masih terdapat kebutuhan fungsional yang lain,
diantaranya adalah :
- Sistem dapat melihat daftar jabatan.
- Sistem dapat menambah jabatan.
- Sistem dapat mengubah jabatan.
- Sistem dapat menghapus jabatan.
- Sistem dapat melakukan pencarian jabatan.
- Sistem dapat melihat daftar dinas.
- Sistem dapat menambah dinas.
- Sistem dapat mengubah dinas.
- Sistem dapat menghapus dinas.
- Sistem dapat melakukan pencarian dinas.
- Sistem dapat melihat daftar jenis surat.
- Sistem dapat menambah jenis surat.
- Sistem dapat mengubah jenis surat.
- Sistem dapat menghapus jenis surat.
- Sistem dapat melakukan pencarian jenis surat.
- Sistem dapat melihat daftar instansi.
- Sistem dapat menambah instansi.
- Sistem dapat mengubah instansi.
- Sistem dapat menghapus instansi.
- Sistem dapat melakukan pencarian instansi.
- Sistem dapat melihat daftar pengguna.
- Sistem dapat melihat detail data pengguna.
- Sistem dapat menambah pengguna.
- Sistem dapat mengubah pengguna.
- Sistem dapat menghapus pengguna.
- Sistem dapat melakukan pencarian pengguna.
- Sistem dapat mengunduh file surat masuk.
- Sistem dapat memberikan komentar pada surat masuk.
Kebutuhan
Non-Fungsional
Usability
Requirement
- Rancangan antarmuka perangkat lunak yang user friendly.
- Adanya fasilitas pencarian untuk memudahkan pengguna mencari data dengan lebih cepat.
- Adanya fasilitas SMS pemberitahuan sehingga dapat mempercepat proses pemeriksaan surat.
Reliability
and up-time requirement
Safety
requirement
- Hanya administrator yang mempunyai wewenang untuk membuat user yang sesuai dengan peranannya, mengubah peranan user, dan menghapus user.
- Administrator dapat mengubah password user.
1. Proses surat masuk yang menghabiskan banyak waktu
2. Tidak efisiennya penggunaan tenaga kerja
3. Penanganan pekerjaan yang kurang maksimal
4. Bagian administrasi sulit untuk melacak posisi surat dalam waktu cepat
5. Disposisi surat dari pejabat berwenang tidak dapat dilakukan dengan cepat
6. Rute yang telah ditempuh suatu surat tidak tercatat
Berikut di bawah ini merupakan keterkaitan antara aspek fuctional dan non-fuctiona yang dihubungkan dengan Mc Calls Faktor.
No.
|
Aspek
|
Faktor Mc Calls
|
Uraian
|
Bukti
|
1
|
Penerimaan surat
|
Correctness
|
Dapat menambah & melihat daftar
surat masuk
|
Sistem yang dibuat telah sesuai dengan
alur penerimaan dilihat dari kebutuhan fuctional yang telah dibuat.
|
Dapat melihat daftar surat masuk dari
pejabat atas.
|
||||
Dapat melihat detail surat masuk
|
|
|||
Dapat mengirimkan surat masuk ke pejabat
lain
|
||||
2
|
Sumber Daya
|
Efficiency
|
Sistem sumberdaya yang digunakan
merupkna sumber daya yang cukup mudah apabila dilihat dari spesifikasi
wajibnya.
|
|
3
|
Hak Akses
|
Intergrity
|
Demi keamanan pada program, maka
diberikannya hak akses menurut tugas masing-masing dalam mengurus jalannya
surat masuk.
|
|
4
|
Pencarian surat
|
Usability
|
Kemudahan perangkat lunak dapat dilihat
dari penggunaan yang semakin memudahkan dibandingkan dengan cara manual
|
Hal tersebut termasuk dalam quality
factor yang mana dalam quality disebutkan bahwa terjadi masalah dalam melacak
surat. Dan masalah itu selesai setelah menggunakan perangkat lunak ini.
|
Melakukan pelacakan posisi surat dapat
dilakukan dengan mudah
|
||||
5
|
Validasi surat
|
Testability
|
uji validasi dilakukan dengan black boc
testing dengan model desain test case
|
|
6
|
Perangkat lunak
|
Portability
|
Dapat berdaptasi dengan berbagai
lingkungan kerja berbeda
|
|
Dapat dijalankan selain dari windows
server 2003 yaitu redhat
|
||||
Client System dapat dijalankan pada
sistem operasi lain karena fasilitas web browser
|
Non-Fuctional
No.
|
Aspek
|
Faktor Mc Calls
|
Uraian
|
1
|
Kemudahan penggunaan
|
Usability Requirement
|
Rancangan antar mukanya mudah dimengerti
|
terdapat fasilitas pencarian untuk
memudahkan pencarian data
|
|||
Fasilitas SMS pemberitahuan, mempercepat
proses pemeiksaan
|
|||
2
|
Hak akses
|
Safty requirement
|
Hanya admin yang berwenang untuk
membuat,menghapus dan mengubah data user yang sesuai.
|
3
|
Kehilangan data
|
Relibility
|
Tidak dapat kehilangan data
|
Langganan:
Postingan (Atom)







