Site blog

Page: () 1 ... 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 ... 45 ()
Picture of OZZY SECIO RIZA 5116201030
by OZZY SECIO RIZA 5116201030 - Thursday, 22 December 2016, 5:50 PM
Anyone in the world

Multidimensional scaling (MDS) is a classical approach to the problem of finding underlying attributes or dimensions, which influence how subjects evaluate a given set of objects or stimuli. Multidimensional scaling (MDS) has become more and more popular as a technique for both multivariate and exploratory data analysis. MDS is a set of data analysis methods, which allow one to infer the dimensions of the perceptual space of subjects. The raw data entering into an MDS analysis are typically a measure of the global similarity or dissimilarity of the stimuli or objects under investigation. The primary outcome of an MDS analysis is a spatial configuration, in which the objects are represented as points.

The goal of an MDS analysis is to find a spatial configuration of objects when all that is known is some measure of their general (dis)similarity. The spatial configuration should provide some insight into how the subject(s) evaluate the stimuli in terms of a (small) number of potentially unknown dimensions. Once the proximities are derived (cf. section 1) the data collection is concluded, and the MDS solution has to be determined using a computer program.

Many MDS programs make a distinction between classical and nonmetric MDS. Classical MDS assumes that the data, the proximity matrix, say, display metric properties, like distances as measured from a map. Thus, the distances in a classical MDS space preserve the intervals and ratios between the proximities as good as possible. For a data matrix consisting of human dissimilarity ratings such a metric assumption will often be too strong. Nonmetric MDS therefore only assumes that the order of the proximities is meaningful. The order of the distances in a nonmetric MDS configuration reflects the order of the proximities as good as possible while interval and ratio information is of no relevance. In order to gain a better understanding of the MDS outcome, a brief introduction to the basic mechanisms of the two MDS procedures, classical und nonmetric MDS, might be helpful.

Classical MDS

The classical MDS algorithm rests on the fact that the coordinate matrix X can be derived by eigenvalue decomposition from the scalar product matrix B = XX0. The problem of constructing B from the proximity matrix P is solved by multiplying the squared proximities with the matrix J = I − n−1110. This procedure is called double centering.


The following steps summarize the algorithm of classical MDS:

  1. Set up the matrix of squared proximities P(2) = [p2].
  2. Apply the double centering:  using the matrix J = I − n−111’, where n is the number of objects.
  3. Extract the m largest positive eigenvalues λ1 . . . λm of B and the corresponding m eigenvectors e1 . . . em.
  4. A m-dimensional spatial configuration of the n objects is derived from the coordinate matrix , where Em is the matrix of m eigenvectors and Λ m is the diagonal matrix of m eigenvalues of B, respectively

Nonmetrics MDS

The core of a nonmetric MDS algorithm is a twofold optimization process. First the optimal monotonic transformation of the proximities has to be found. Secondly, the points of a configuration have to be optimally arranged, so that their distances match the scaled proximities as closely as possible. The basic steps in a nonmetric MDS algorithm are:

  1. Find a random configuration of points, e. g. by sampling from a normal distribution.
  2. Calculate the distances d between the points.
  3. Find the optimal monotonic transformation of the proximities, in order to obtain optimally scaled data f(p).
  4. Minimize the stress between the optimally scaled data and the distances by finding a new configuration of points.
  5. Compare the stress to some criterion. If the stress is small enough then exit the algorithm else return to 2
Associated Course: KI142303BKI142303B


    Anyone in the world

    Construction Models

    Berbagai macam model yang telah dibuat  untuk membangun software, beberapa diantaranya lebih menekankan pada perancangan daripada (model) yang lainnya

    Construktion Planning

    Pemilihan dari metode construction adalah sebuah aspek terpenting (key aspect) dalam aktivitas construction planning.

    Pendekatan construction mempengaruhi kemampuan proyek untuk mengurangi kerumitan, mengantisipasi perubahan, dan untuk verifikasi.

    Construction planning juga menjelaskan susunan komponen yang dibuat dan digabungkan, kualitas manajemen proses dari software, alokasi dari pengerjaan tugas pada software teknik yang spesifik, dan tugas lainnya, termasuk pada metode yang dipilih.

    Construction measurement

    Banyak aktivitas construction dan buatan manusia (artifact) dapat ditentukan/dipilih, termasuk pengembangan code, pengubahan code, penggunaan kembali code (code reuse), penghapusan code, kerumitan code, statistika pemeriksaan code, perbandingan fault-fix dan fault-find, usaha, dan penjadwalan.

    Measurement dapat menjadi sangat berguna untuk tujuan pengontrolan construction, menjamin  kualitas selama construction, memperbaiki proses construction

    Practical Considerations

    1. Construction Design

    Beberapa proyek mengalokasikan lebih banyak pada aktivitas desain daripada construction. Sebagai pekerja construction, membangun struktur fisik  harus beradaptasi dengan membuat modifikasi small-scale sebagai laporan untuk rencana pembangunan (builder’s plan). Pekerja construction software harus membuat modifikasi dalam skala yang lebih besar atau skala yang lebih kecil untuk detail desain software selama construction.

    2. Construction Languages

    Linguistic notations dibedakan dalam hal penggunaan kata atau string dari text untuk menjelaskan software construction yang komplek, dan gabungan kata / string ke dalam pola – pola yang mempunyai sintax kalimat. Visual notation mengandalkan banyak kekurangan pada text oriented notation dari kedua bahasa dan penyusun formal, dan mengandalkan secara langsung interprestasi visual dan penempatan dari entitas visual yang merepresentasikan pokok software.

    Penyusunan secara visual cenderung agak terbatas karena hanya menggunakan pergerakan dari entitas visual pada sebuah display.

    3. Coding

    Beberapa pertimbangan yang dipergunakan pada proses penyusunan pengkodingan software :

    • Teknik untuk pembuatan source code yang dapat dipahami, termasuk penamaan dan susunan source code.
    • Mempergunakan pengkelasan, enumerated types, variable, penamaan konstanta dan yang lain entitas yang mirip.
    • Mempergunakan struktur control.
    • Penanganan kondisi error
    • Pencegahan pelanggaran sekuriti level kode (Sebagai contoh : buffer yang melebihi indek sebuah array).
    • Penggunaan sebuah resource melalui penggunaan mekanisme pengeluaran dan tata cara pengaksesan penggunaan resourse yang dapat dipergunakan kembali (termasuk peng-lock-an thread atau database).
    • Pengorganisasian source code ( menjadi statement-statement, fungsi-fungsi, kelas-kelasm paket-paket atau struktur yang lainnya).
    • Dokumentasi kode.
    • Perbaikan kode

    4. Construction Testing

    Proses penyusunan memiliki dua bentuk untuk pengetesan, dimana sering dipergunakan oleh software engineer yang membuat kode tersebut :

    • Unit testing,
    • Integration testing.
    • Tujuan penyusunan proses pengetesan ini untuk mengurangi batasan diantara waktu adanya kesalahan pada code dan waktu kesalahan dideteksi.
    • Dalam banyak kasus, proses pengetesan ini dicoba setelah proses penulisan kode selesai. Dalam kasus yang lain, pengetesan dibuat sebelum kode ditulis.

    5. Reuse

    Tugas-tugas yang terkait dalam penggunan kembali penyusunan konstruksi sebelum pengkodingan dan pengetesan adalah:

    • Seleksi unit, database, atau tes data reusability,
    • Evaluasi kode atau tes reusability,
    • Laporan informasi yang dipergunakan dalam kode baru, test prosedur atau test data.


    Associated Course: KI142303BKI142303B


      Picture of OZZY SECIO RIZA 5116201030
      by OZZY SECIO RIZA 5116201030 - Thursday, 22 December 2016, 5:48 PM
      Anyone in the world

      Data-flow testing is a white box testing technique that can be used to detect improper use of data values due to coding errors. Errors are inadvertently introduced in a program by programmers. For instance, a software programmer might use a variable without defining it. Additionally, he/she may define a variable, but not initialize it and then use that variable in a predicate.

      In data-flow testing, the first step is to model the program as a control flow graph. This helps to identify the control flow information in the program. In step 2, the associations between the definitions and uses of the variables that is needed to be covered in a given coverage criterion is established. In step 3, the test suite is created using a finite number of paths from step 2.

      Data-flow testing monitors the lifecycle of a piece of data and looks out for inappropriate usage of data during definition, use in predicates, computations and termination (killing). It identifies potential bugs by examining the patterns in which that piece of data is used. For example, A pattern which indicates usage of data in a calculation after it has been killed is certainly a bug which needs to be addressed.

      To examine the patterns, we need to construct a control flow graph of the code. A control flow graph is a directed graph where the nodes represent the processing statements like definition, computation and predicates while the edges represent the flow of control between processing statements. Since data-flow testing closely examines the state of the data in the control flow graph, it results in a richer test suite than the one obtained from traditional control flow graph testing strategies like all branch coverage, all statement coverage, etc.



      Data flow anomalies are represented using two characters based on the sequence of actions. They are defined (d), killed (k), and used (u). There are nine possible combinations based on these 3 sequence of actions which are dd, dk, du, kd, kk, ku, ud, uk, uu.


      In addition to the above two-letter situations, there are six single letter situations with preceding dash or succeeding dash. Preceding dash with letters d, k, u indicate that nothing special occurs prior to the action along the entry-exit path considered. Succeeding dash with letters d, k, u indicate that nothing special occurs after the action along the entry-exit path considered. Meaning of six single letter situations with preceding dash or succeeding dash are explained below. 




      Janvi Badlaney, Rohit Ghatol, Romit Jadhwani. “An Introduction to Data-Flow Testing”. 2006. NCSU CSC TR-2006-22

      Associated Course: KI142303BKI142303B


        Picture of OZZY SECIO RIZA 5116201030
        by OZZY SECIO RIZA 5116201030 - Thursday, 22 December 2016, 5:44 PM
        Anyone in the world

        Black Box Testing, also known as Behavioral Testing, is a software testing method in which the internal structure/ design/ implementation of the item being tested is not known to the tester. These tests can be functional or non-functional, though usually functional.

        This method is named so because the software program, in the eyes of the tester, is like a black box; inside which one cannot see. This method attempts to find errors in the following categories:

        • Incorrect or missing functions
        • Interface errors
        • Errors in data structures or external database access
        • Behavior or performance errors
        • Initialization and termination errors




        Following are some techniques that can be used for designing black box tests.

        • Equivalence partitioning: It is a software test design technique that involves dividing input values into valid and invalid partitions and selecting representative values from each partition as test data.
        • Boundary Value Analysis: It is a software test design technique that involves determination of boundaries for input values and selecting values that are at the boundaries and just inside/ outside of the boundaries as test data.
        • Cause Effect Graphing: It is a software test design technique that involves identifying the cases (input conditions) and effects (output conditions), producing a Cause-Effect Graph, and generating test cases accordingly.


        • Tests are done from a user’s point of view and will help in exposing discrepancies in the specifications.
        • Tester need not know programming languages or how the software has been implemented.
        • Tests can be conducted by a body independent from the developers, allowing for an objective perspective and the avoidance of developer-bias.
        • Test cases can be designed as soon as the specifications are complete.



        • Only a small number of possible inputs can be tested and many program paths will be left untested.
        • Without clear specifications, which is the situation in many projects, test cases will be difficult to design.
        • Tests can be redundant if the software designer/ developer has already run a test case.
        • Ever wondered why a soothsayer closes the eyes when foretelling events? So is almost the case in Black Box Testing.




        Associated Course: KI142303BKI142303B
        [ Modified: Thursday, 22 December 2016, 5:45 PM ]


          Picture of OZZY SECIO RIZA 5116201030
          by OZZY SECIO RIZA 5116201030 - Thursday, 22 December 2016, 5:43 PM
          Anyone in the world

          Back-to-Back testing ensures that two different instances of an implementation have the same structural behavior. A typical use case in a model-based development process is comparing the model (MIL) which is considered to be an “executable specification” against the production code (SIL).



          Scenario of Back-to-Back Testing

          1. The aim of testing is defined. Test cases are designed.
          2. The checking is performed with the usage of test cases. Specialists launch applications or systems and record the results of their work.
          3. Obtained results are automatically compared.
          4. Testers make the difference report that contains the results of comparison.


          There can be some misinterpretations of the notion ‘the difference report’. Actually, everything is very simple. The difference report contains necessary data to demonstrate the problems that may happen among the various system versions.

          Here is one more explanation of back-to-back testing. This checking type is executed in the presence of two identical transformers. One of these transformers remains open and the other one – loaded.

          It is cheaper to perform back-to-back testing when the system or application have some modifications. There is no need to execute usability testing or performance testing one more time. Tester may just compare the work of system versions.

          In other words, back-to-back testing is more effective during mobile application testing and website testing.



          Associated Course: KI142303BKI142303B


            Picture of NAHYA NUR 5116201035
            by NAHYA NUR 5116201035 - Thursday, 22 December 2016, 2:41 PM
            Anyone in the world

            Requirements traceability matrix (RTM)  merupakan alat yang digunakan untuk mengetahui kebutuhan pada pengembangan perangkat lunak pada fase testing. Disini RTM berguna melakukan verifikasi apakah kebutuhan tersebut sudah terpenuhi atau belum. RTM ini berupa daftar-daftar kebutuhan yang nantinya dapat memudahkan dalam melakukan testing. Matrix ini menghubungkan antara kebutuhan pada tingkat yang paling tinggi, spesifikasi desain, kebutuhan testing, dan coding. Karena matrix ini menyediakan link yang diperlukan berguna menentukan informasi yang dibutuhkan. Dengan adanya RTM juga sebagai alat untuk memastikan adanya penjaminan kualitas software, karena RTM memastikan bahwa kebutuhan yang diinginkan customers telah sesuai. Reqirement Treacibility Matrix digunakan dalam Quality Assurance sehingga dapat memastikan bahwa kebutuhan klien terpenuhi, dan perangkat lunak sesuai dengan yang diminta.


            Kesuksesan project tidak akan tercapai tanpa manager proyek yang memiliki kemampuan organisasai yang baik. Dokumentasi requirement klien yang baik akan sangat membantu pengerjaan proyek. Manager yang baik harus mempu mengidentifikasikan requirement yang berhasil ataupun berpotensi gagal. Requirement treacibility matrix merupakan salah satu tools yang berguna untuk menelusuri informasi requirement.


            Tujuan dari RTM yaitu ;

            1. Memastikan bahwa seluruh test case yang ada harus sesuai dengan kebutuhan.
            2. Memastikan bahwa ketentuan yang telah disetujui sudah mencakup semua pada fase pengembangan. Dari spesifikasi kebutuhan, pengembangan perangkat lunak, testing, sampai perangkat lunak itu jadi.



            Bagaimana Kriteria RTM yang baik?

            1. Buat sebuah template RTM yang mudah dipahami oleh seluruh anggota proyek
            2. Usahakan kolom-kolom yang ada pada RTM urut sesuai dengan fase proyek yang ada. Contoh: Biasanya testing dilakukan di akhir, maka kolom untuk tescase diletakkan di akhir tabel.
            3. Berikan ID untuk setiap requirement
            4. Untuk proses selanjutnya, usahakan ada keterkaitan dalam penamaan ID, hal ini akan memudahkan kita dalam melakukan trace RTM





            Associated Course: KI142303BKI142303B


              Picture of NAHYA NUR 5116201035
              by NAHYA NUR 5116201035 - Thursday, 22 December 2016, 2:39 PM
              Anyone in the world

              Grey Box Testing adalah sebuah metodologi kombinasi dari Black Box dan White Box Testing, menguji software berdasarkan spesifikasi tetapi menggunakan cara kerja dari dalam. Grey Box dapat di gunakan dengan baik dalam software testing.

              Grey box testing mengacu pada teknik pengujian sistem dengan pengetahuan yang terbatas (limited knowledge) dari internal sistem. Grey box testing memiliki akses ke desain dokumen dengan rinci melalui informasi di luar persyaratan dokumen. Grey box testing yang dihasilkan berdasarkan informasi tersebut sebagai state-based models atau architecture diagrams of the target system.

              Menurut Saleh (2009, p225) grey box mengasumsikan bahwa arsitektur software dan dokumentasi desain tersedia untuk tester. Grey box juga berdasarkan design document dan functional specifications. Dari beberapa definisi tersebut, dapat disimpulkan bahwa grey box testing adalah teknik pengujian sistem dengan pengetahuan yang terbatas (limited knowledge) dari internal sistem yang memiliki akses ke dokumen desain rinci. Pengujian grey box juga berdasarkan design document dan functional specifications dari suatu sistem.


              Grey Box Testing biasa di gunakan pada software berorientasi object, dimana object – object tersebut adalah unit terpisah yang memiliki kode eksekusi atau data. Contoh aplikasi yang membutuhkan Grey Box Testing :

              • Architectural model
              • Unified Modeling Language – UML Design Model
              • Finite-state machine – State Model.


              Teknik yang ada ada Grey Box Testing :

              • Matrix Testing: menyatakan laporan atau status proyek
              • Regression testing: menyatakan status apakah terjadi perubahan pada kasus uji yang baru dibuat.
              • Pattern Testing: memverifikasi aplikasi yang baik untuk desain atau arsitektur dan pola.
              • Orthogonal array testing: digunakan sebagai bagian dari semua kemungkinan kombinasi.


              Efek penggunaan Grey Box Testing :

              Efek Positif

              • Offers combined benefits : Mengambil kelebihan dari 2 kombinasi testing dan melakukan percobaan terhadap testing.
              • Non Intrusive : Hal ini didasarkan pada spesifikasi fungsional, tampilan arsitektur.
              • Intelligent Test Authoring : Grey Box Testing menangani scenario uji coba, misalnya tipe data, protocol komunikasi, dan penanganan eksepsi.
              • Unbiased Testing : terlepas dari semua keuntungan diatas, Grey Box Testing mempertahankan batas terhadapa pengujian Antara tester dan developer.

              Efek Negatif

              • Partial Code Coverage : Dalam pengujian Grey Box, sumber kode dan binary akan hilang karenga akses yang terbatas pada struktur internal atau aplikasi akan menghasilkan akses terbats terhadap kode path traversal.
              • Defect Identification : Dalam aplikasi terdistribusi, sulit untuk mengidetifikasi cacat atau bug. Namun, pengujian di grey box dapat mengetahui bagaimana system cacat dalam lingkungan layana web.



              • Pengujian Grey Box ini cocok untuk Aplikasi WEB. Aplikasi Web telah didistribuasikan jaringan atau system, karena tidak adanya sumber kode atau binary, tidak mungkin untuk menggunakan pengujian, white-box. Pengujian Black-box juga tidak digunakan karena hanya melakukan kontrak Antara pelanggan dan pengembang, sehinggal lebih efisien menggunakan Grey-box testing sebagai informasi penting yang tersedia dalam Web Service Definition Language (WSDL).
              • Pengujian Grey Box cocok untuk pengujian fungisonal atau domain bisnis. Pengujian fungsional dilakaukan pada dasarnya tes interaksi pengguna dengan system. Ini juga membantu untuk mengkonfirmasi software yangn memenuhi persyaratan yang di tetapkan untuk perangkat lunak.




              Associated Course: KI142303BKI142303B


                Picture of NAHYA NUR 5116201035
                by NAHYA NUR 5116201035 - Thursday, 22 December 2016, 2:38 PM
                Anyone in the world

                Pengujian white box adalah pengujian yang didasarkan pada pengecekan terhadap detail perancangan, menggunakan struktur kontrol dari desain program secara procedural untuk membagi pengujian ke dalam beberapa kasus pengujian. Secara sekilas dapat diambil kesimpulan white box testing merupakan petunjuk untuk mendapatkan program yang benar secara 100%.


                Penggunaan metode pengujian white box dilakukan untuk :

                • Memberikan jaminan bahwa semua jalur independen suatu modul digunakan minimal satu kali
                • Menggunakan semua keputusan logis untuk semua kondisi true atau false
                • Mengeksekusi semua perulangan pada batasan nilai dan operasional pada setiap kondisi.
                • Menggunakan struktur data internal untuk menjamin validitas jalur keputusan.


                Persyaratan dalam menjalankan strategi White Box Testing

                • Mendefinisikan semua alur logika
                • Membangun kasus untuk digunakan dalam pengujian
                • Mengevaluasi semua hasil pengujian
                • Melakukan pengujian secara menyeluruh


                Pengujian White Box Testing

                Pengujian ke white box testing adalah menguji yang di dasarkan kepada pengecekkan ke dalam detail rancangan, penggunaan yang di lakukan struktur control dari suatu desain pemograman untuk dapat membagi pengujian ke beberapa kasus pengujian. Dan di dapat bahwasanya white box testing menggungakan petunjuk untuk menghasilkan program yang di harapkan dan efisien.


                Metode pengujian pada white box testing ini sering di lakukan untuk

                • Memberikan dan membuat suatu jaminan bahwa seluruh jalur-jalur yang independen hanya menggunakan modul minimal satu kali.
                • Keputusan yang sifatnya logis dapat di gunakan di semua kondisi true (benar) atau false (salah).
                • Mengeksekusi seluruh perulangan yang ada ke pada batas nilai dan operasional di setiap situasi dan kondisi.


                Kelebihan Yang Terdapat Di White Box Testing

                • Kesalahan Logika

                Menggunakan sintax ‘if’ dan sintax pengulangan. Dan langkah selanjutnya metode white box testing ini akan mencari dan mendeteksi segala kondisi yang di percaya tidak sesuai dan mencari kapan suatu proses perulangan di akhiri.

                • Ketidaksesuaian Asumsi

                Menampilkan dan memonitori beberapa asumsi yang di yakini tidak sesuai dengan yang di harapkan atau yang akan di wujudkan, untuk selanjutnya akan di analisa kembalai dan kemudian di perbaiki.

                • Kesalahan Pengetikan

                Mendeteksi dan mencarian bahasa-bahasa pemograman yang di anggap bersifat case sensitif.


                Kelemahan White Box Testing

                Pada perangkat lunak yang jenisnya besar, metode white box testing ini dianggap boros karena melibatkan banyak sumberdaya untuk melakukannya.





                Associated Course: KI142303BKI142303B


                  Picture of NAHYA NUR 5116201035
                  by NAHYA NUR 5116201035 - Thursday, 22 December 2016, 2:37 PM
                  Anyone in the world

                  Black Box Testing adalah metode pengujian perangkat lunak yang tes fungsionalitasnya dari aplikasi yang bertentangan dengan struktur internal atau kerja. Pengetahuan khusus dari kode aplikasi / struktur internal dan pengetahuan pemrograman pada umumnya tidak diperlukan. Uji kasus dibangun di sekitar spesifikasi dan persyaratan, yakni, aplikasi apa yang seharusnya dilakukan.Menggunakan deskripsi eksternal perangkat lunak, termasuk spesifikasi, persyaratan, dan desain untuk menurunkan uji kasus. Tes ini dapat menjadi fungsional atau non-fungsional, meskipun biasanya fungsional. Perancang uji memilih input yang valid dan tidak valid dan menentukan output yang benar. Tidak ada pengetahuan tentang struktur internal benda uji itu.


                  Metode ujicoba blackbox memfokuskan pada keperluan fungsional dari software. Karna itu ujicoba blackbox memungkinkan pengembang software untuk membuat himpunan kondisi input yang akan melatih seluruh syarat-syarat fungsional suatu program. Ujicoba blackbox bukan merupakan alternatif dari ujicoba whitebox, tetapi merupakan pendekatan yang melengkapi untuk menemukan kesalahan lainnya, selain menggunakan metode whitebox. Ujicoba blackbox berusaha untuk 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


                  Dekomposisi kebutuhan  untuk dites secara  sistematis  :

                  • Untuk dapat membuat test cases  yang efektif, harus dilakukan dekomposisi dari tugas-tugas testing suatu sistem ke aktivitas-aktivitas yang lebih kecil dan dapat dimanajemeni, hingga tercapai test case individual.
                  • Tentunya, dalam disain test case juga digunakan mekanisme untuk memastikan bahwa test case yang ada telah cukup mencakup semua aspek dari sistem.
                  • Pendisainan test case dilakukan secara manual, tidak ada alat bantu otomasi guna menentukan test cases yang dibutuhkan oleh sistem, karena tiap sistem berbeda, dan alat bantu tes tak dapat mengetahui aturan benar-salah dari suatu operasi.
                  • Desain tes membutuhkan pengalaman, penalaran dan intuisi dari seorang tester.






                  Associated Course: KI142303BKI142303B


                    Picture of NAHYA NUR 5116201035
                    by NAHYA NUR 5116201035 - Thursday, 22 December 2016, 2:36 PM
                    Anyone in the world

                    Kualitas merupakan salah satu factor utama yang menunjang suatu bisnis dimana ia dianggap sebagai pembeda yang khas dengan 2 kriterianya yakni :

                    1. Kualitas harus terukur (mempunyai standar ukuran).
                    2. Kualitas sebisa mungkin dapat diprediksikan.

                    Sedangkan software itu sendiri adalah komponen di dalam suatu computer berupa data elektronik, yang nantinya akan membantu kinerja dalam proses input output.

                    Jadi, pengertian dari software quality itu sendiri adalah bagaimana dan seperti apa  suatu software memiliki suatu kualitas (pembeda) sehingga nantinya software tersebut benar-benar useful dalam pengaplikasianya di setiap bidang,baik itu bisnis maupun organisasi lainnya. Dimana kualitas itu sendiri, bisa dipecah kembali ke beberapa bagian sesuai spesifikasi si software itu sendiri.

                    Mengapa kualitas itu penting? Kaitannya dengan konsumen, kualitas disini benar-benar menjadi sebuah permintaan yang juga menjadi sebuah ‘alat’ dalam mencapai sukses dan bisa survive dari pesaing yang ada. Karena sejatinya kualitas adalah kepuasan konsumen. Untuk itulah, kualitas haruslah direncanakan ke dalam suatu struktur projek, lalu secara konstan dievaluasi dan

                    Bila kualitas adalah suatu prioritas, maka disini kualitas dari sebuah software harus direncanakan dan dibuat ke dalam suatu project lalu kemudian diatur dan dilolah menjadi suatu produk dan dimonitor bukan hanya melalui taksiran tetapi juga melalui evaluasi dari hasil kombinasi antara interaksi atau hubugan timbal balik antara software dan produk yang ada.

                    Sebuah software memiliki karakteristik sebagai berikut :

                    1. Software dikembangkan dan direncanakan dan software bukan merupakan hasil sebuah manufaktur klasik seperti biasanya,sehingga bisa digunakan untuk mempertahankan konsumen dan meningkatkan keuntugan perusahaan.
                    2. Untuk itu,software haruslah berkualitas,karena kualitas itu adalah sebuah ‘hallmark’ dari sebuah bisnis secara global.


                    Software Quality Assurance

                    Tujuan dari software quality assurance adalah untuk memastikan bahwa software yang dibuat dapat memenuhi standar kwalitas sebuah software. Software Quality Assurance menyediakan ukuran-ukuran atau patokan-patokan yang didesain untuk memasatikan suatu software berjalan sesuai fungsinya secara konsisten dana modifikasi terhadap software tersebut tidak menghasilkan suatu masalah yang besar. Patokan tersebut harus dipakai sepanjang pengembangan software secara sistematik, mulai testing, dokumentasi, sampai eksekusi suatu software dan saat pemeliharaan software.


                    Alur dari software quality assurance adalah :

                    1. Rencana atau rancangaan ditetapkan sesuai standar.
                    2. Prosedur dilaksanakan sesuai rencana.
                    3. Produk diimplementasikan menurut standar.





                    Associated Course: KI142303BKI142303B


                      Page: () 1 ... 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 ... 45 ()