Site blog

Halaman: () 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 ... 41 ()
Gambar dari PASCAL MANIRIHO 5116201701
by PASCAL MANIRIHO 5116201701 - Saturday, 24 December 2016, 19:06
Anyone in the world
Testing can either be done manually or using an automated testing tool:
  • Manual - This testing is performed without taking help of automated testing tools. The software tester prepares test cases for different sections and levels of the code, executes the tests and reports the result to the manager.

    Manual testing is time and resource consuming. The tester needs to confirm whether or not right test cases are used. Major portion of testing involves manual testing.

  • Automated This testing is a testing procedure done with aid of automated testing tools. The limitations with manual testing can be overcome using automated test tools.

A test needs to check if a webpage can be opened in Internet Explorer. This can be easily done with manual testing. But to check if the web-server can take the load of 1 million users, it is quite impossible to test manually.There are software and hardware tools which helps tester in conducting load testing, stress testing, regression testing

Associated Kursus: KI142303BKI142303B
Gambar dari PASCAL MANIRIHO 5116201701
by PASCAL MANIRIHO 5116201701 - Saturday, 24 December 2016, 19:04
Anyone in the world
CLI has been a great tool of interaction with computers until the video display monitors came into existence. CLI is first choice of many technical users and programmers. CLI is minimum interface a software can provide to its users.CLI provides a command prompt, the place where the user types the command and feeds to the system. The user needs to remember the syntax of command and its use. Earlier CLI were not programmed to handle the user errors effectively. A command is a text-based reference to set of instructions, which are expected to be executed by the system. There are methods like macros, scripts that make it easy for the user to operate. CLI uses less amount of computer resource as compared to GUI
Associated Kursus: KI142303BKI142303B
Gambar dari MAURICE NTAHOBARI 5116201702
by MAURICE NTAHOBARI 5116201702 - Saturday, 24 December 2016, 19:03
Anyone in the world

Requirements Elicitation
In requirements engineering, requirements elicitation is the practice of collecting the requirements of
a system from users, customers, and other stakeholders. The practice is also sometimes referred to as
requirements gathering.
The term elicitation is used in books and research to raise the fact that good requirements cannot just be
collected from the customer, as would be indicated by the name requirements gathering. Requirements
elicitation is non-trivial because you can never be sure you get all requirements from the user and customer by just asking them what the system should do. Requirements elicitation practices include interviews:

1.  Questionnaires

2. User observation

3. workshops


4.Use cases

5.Role playing

6. Prototyping.

Before requirements can be analyzed, modeled, or specified they must be gathered through an elicitation
process. Requirements elicitation is a part of the requirements engineering process, usually followed by
analysis and specification of the requirements. Commonly used elicitation processes are the stakeholder meetings or interviews. For example, an important first meeting could be among software engineers and customers where they discuss their perspective of the requirements.



Associated Kursus: KI142303KI142303
[ Mengubah: Saturday, 24 December 2016, 19:10 ]
Gambar dari DESEPTA ISNA ULUMI 5116201018
by DESEPTA ISNA ULUMI 5116201018 - Friday, 23 December 2016, 23:52
Anyone in the world

3 Code-Based Techniques

a. Control Flow-Based Criteria


Control flow-based coverage criteria are aimed at covering all the statements, blocks of statements, or specified combinations of statements in a program. The strongest of the control flowbased criteria is path testing, which aims to execute all entry-to-exit control flow paths in a program’s control flow graph. Since exhaustive path testing is generally not feasible because of loops, other less stringent criteria focus on coverage of paths that limit loop iterations such as statement coverage, branch coverage, and condition/ decision testing. The adequacy of such tests is measured in percentages; for example, when all branches have been executed at least once by the tests, 100% branch coverage has been achieved.

b. Data Flow-Based Criteria


In data flow-based testing, the control flow graph is annotated with information about how the program variables are defined, used, and killed (undefined). The strongest criterion, all definition- use paths, requires that, for each variable, every control flow path segment from a definition of that variable to a use of that definition is executed. In order to reduce the number of paths required, weaker strategies such as all-definitions and all-uses are employed.

c. Reference Models for Code-Based Testing


Although not a technique in itself, the control structure of a program can be graphically represented using a flow graph to visualize codebased testing techniques. A flow graph is a directed graph, the nodes and arcs of which correspond to program elements (see Graphs and Trees in the Mathematical Foundations KA). For instance, nodes may represent statements or uninterrupted sequences of statements, and arcs may represent the transfer of control between nodes.


Resource :

Gambar dari DESEPTA ISNA ULUMI 5116201018
by DESEPTA ISNA ULUMI 5116201018 - Friday, 23 December 2016, 23:49
Anyone in the world

2. Input Domain-Based Techniques

a.  Equivalence Partitioning


Equivalence partitioning involves partitioning the input domain into a collection of subsets (or equivalent classes) based on a specified criterion or relation. This criterion or relation may be different computational results, a relation based on control flow or data flow, or a distinction made between valid inputs that are accepted and processed by the system and invalid inputs, such as out of range values, that are not accepted and should generate an error message or initiate error processing. A representative set of tests (sometimes only one) is usually taken from each equivalency class.

b. Pairwise Testing


Test cases are derived by combining interesting values for every pair of a set of input variables instead of considering all possible combinations. Pairwise testing belongs to combinatorial testing, which in general also includes higher-level combinations than pairs: these techniques are referred to as t-wise, whereby every possible combination of t input variables is considered.

c. Boundary-Value Analysis


Test cases are chosen on or near the boundaries of the input domain of variables, with the underlying rationale that many faults tend to concentrate near the extreme values of inputs. An extension of this technique is robustness testing, wherein test cases are also chosen outside the input domain of variables to test program robustness in processing unexpected or erroneous inputs.

d. Random Testing


Tests are generated purely at random (not to be confused with statistical testing from the operational profile, as described in Operational Profile in section 3.5). This form of testing falls under the heading of input domain testing since the input domain must be known in order to be able to pick random points within it. Random testing provides a relatively simple approach for test automation; recently, enhanced forms of random testing have been proposed in which the random input sampling is directed by other input selection criteria [11]. Fuzz testing or fuzzing is a special form of random testing aimed at breaking the software; it is most often used for security testing.


Resource :

Anyone in the world

Rekayasa perangkat lunak telah berkembang sejak pertama kali diciptakan pada tahun 1940-an hingga kini. Focus utama pengembangannya adalah untuk mengembangkan praktek dan teknologi untuk meningkatkan produktivitas para praktisi pengembang perangkat lunak dan kualitas aplikasi yang dapat digunakan oleh pemakai.

Istilah software engineering digunakan pertama kali pada akhir 1950-an dan awal 1960-an. Saat itu, masih terdapat perdebatan tajam mengenai aspek engineering dari pengembangan perangkat lunak. Pada tahun 1968 dan 1969, komite sains NATO mensponsori dua konferensi tentang rekayasa perangkat lunak, yang memberikan dampak kuat terhadap pengembangan rekayasa perangkat lunak. Banyak yang menganggap dua konferensi inilah yang menandai awal resmi profesi rekayasa perangkat lunak.

Pada tahun 1960-an hingga 1980-an, banyak masalah yang ditemukan para praktisi pengembangan perangkat lunak. Banyak project yang gagal, hingga masa ini disebut sebagai krisis perangkat lunak. Kasus kegagalan pengembangan perangkat lunak terjadi mulai dari project yang melebihi anggaran, hingga kasus yang mengakibatkan kerusakan fisik dan kematian. Salah satu kasus yang terkenal antara lain meledaknya roket Ariane akibat kegagalan perangkat lunak. Selama bertahun-tahun, para peneliti memfokuskan usahanya untuk menemukan teknik jitu untuk memecahkan masalah krisi perangkat lunak.

Berbagai teknik, metode, alat, proses diciptakan dan diklaim sebagai senjata pamungkas untuk memecahkan kasus ini. Mulai dari pemrograman terstruktur, pemrograman berorientasi objek, perangkat pembantu pengembangan perangkat lunak (CASE tools), berbagai standar, UML hingga metode formal diagung-agungkan sebagai senjata pamungkas untuk menghasilkan software yang benar, sesuai anggaran dan tepat waktu. Pada tahun 1987, Fred Brooks menulis artikel No Silver Bullet, yang berproposisi bahwa tidak ada satu teknologi atau praktek yang sanggup mencapai 10 kali lipat perbaikan dalam produktivitas pengembanan perngkat lunak dalam tempo 10 tahun.

Istilah Reakayasa Perangkat Lunak (RPL) secara umum disepakati sebagai terjemahan dari istilah Software engineering. Istilah Software Engineering mulai dipopulerkan pada tahun 1968 pada software engineering Conference yang diselenggarakan oleh NATO. Sebagian orang mengartikan RPL hanya sebatas pada bagaimana membuat program komputer. Padahal ada perbedaan yang mendasar antara perangkat lunak (software) dan program komputer.

Perangkat lunak adalah seluruh perintah yang digunakan untuk memproses informasi. Perangkat lunak dapat berupa program atau prosedur. Program adalah kumpulan perintah yang dimengerti oleh komputer sedangkan prosedur adalah perintah yang dibutuhkan oleh pengguna dalam memproses informasi (O’Brien, 1999).

RPL sendiri adalah suatu disiplin ilmu yang membahas semua aspek produksi perangkat lunak, mulai dari tahap awal yaitu analisa kebutuhan pengguna, menentukan spesifikasi dari kebutuhan pengguna, disain, pengkodean, pengujian sampai pemeliharaan sistem setelah digunakan. Dari pengertian ini jelaslah bahwa RPL tidak hanya berhubungan dengan cara pembuatan program komputer. Pernyataan ”semua aspek produksi” pada pengertian di atas, mempunyai arti semua hal yang berhubungan dengan proses produksi seperti manajemen proyek, penentuan personil, anggaran biaya, metode, jadwal, kualitas sampai dengan pelatihan pengguna merupakan bagian dari RPL.

Sumber :

Associated Kursus: KI142303BKI142303B
Anyone in the world

Pengembangan perangkat lunak (juga disebut pengembangan aplikasi, desain perangkat lunak, merancang perangkat lunak, pengembangan aplikasi perangkat lunak, pengembangan aplikasi perusahaan, atau pengembangan platform) adalah pengembangan suatu produk perangkat lunak. Istilah "pengembangan perangkat lunak" bisa dipakai untuk menyebut aktivitas pemrograman komputer, yaitu proses menulis dan mengelola kode sumber, namun dalam artian luas istilah ini mencakup semua hal yang terlibat antara penciptaan perangkat lunak yang diinginkan melalui pewujudan akhir perangkat lunak, idealnya dalam proses yang terencana dan terstruktur.Karena itu, pengembangan perangkat lunak bisa mencakup penelitian, pengembangan baru, purwarupa, modifikasi, pemakaian kembali, rekayasa ulang, pengelolaan, atau aktivitas lain yang menghasilkan produk perangkat lunak.

Perangkat lunak bisa dikembangkan untuk berbagai tujuan, tiga tujuan paling umum adalah memenuhi kebutuhan klien/bisnis tertentu (perangkat lunak kustom), memenuhi persepsi kebutuhan sejumlah pengguna potensial (perangkat lunak komersial dan terbuka), atau memenuhi kebutuhan pribadi (misalnya seorang ilmuwan menulis perangkat lunak untuk mengotomasikan sebuah tugas yang rumit). Pengembangan perangkat lunak tertanam adalah pengembangan perangkat lunak tertanam seperti yang dipakai untuk mengontrol produk konsumen, membutuhkan proses pengembangan yang terintegrasikan dengan pengembangan produk fisik yang dikontrol.

Perlunya pengawasan kualitas yang lebih baik pada proses pengembangan perangkat lunak menciptakan disiplin teknik perangkat lunak, yang bertujuan menerapkan pendekatan sistematis yang tercantum dalam paradigma teknik hingga proses pengembangan perangkat lunak.

Sumber :

Associated Kursus: KI142303BKI142303B
Anyone in the world

Menurut Mulyanto, ruang lingkup dalam rekayasa perangkat lunak dapat dibagi menjadi : 

  1. Software requirements berhubungan dengan spesifikasi kebutuhan dan persyaratan perangkat lunak.
  2. Software design mencakup proses penentuan arsitektur, komponen, antarmuka, dan karakteristik lain dari perangkat lunak.
  3. Software construction berhubungan dengan detil pengembangan perangkat lunak, termasuk algoritma, pengkodean, pengujian, dan pencarian kesalahan. 
  4. Software testing meliputi pengujian pada keseluruhan perilaku perangkat lunak.
  5. Software maintenance mencakup upaya-upaya perawatan ketika perangkat lunak telah dioperasikan.
  6. Software configuration management berhubungan dengan usaha perubahan konfigurasi perangkat lunak untuk memenuhi kebutuhan tertentu.
  7. Software engineering management berkaitan dengan pengelolaan dan pengukuran RPL, termasuk perencanaan proyek perangkat lunak.
  8. Software engineering tools and methods mencakup kajian teoritis tentang alat bantu dan metode RPL.
  9. Software engineering process berhubungan dengan definisi, implementasi,pengukuran, pengelolaan, perubahan dan perbaikan proses RPL.
  10. Software quality menitikberatkan pada kualitas dan daur hidup perangkat lunak.
Associated Kursus: KI142303BKI142303B
Anyone in the world

Jenis kebutuhan perangkat lunak dapat dibagi dalam 2 jenis,

  1. Kebutuhan Fungsional ( Functional Requirement)
  2. Kebutuhan Non Fungsional (Non Functional Requirement)

Functional Requirement
Mendeskripsikan layanan, fitur atau fungsi yang disediakan atau diberikan oleh sistem bagi penggunanya. Kebutuhan fungsional awal merupakan fungsi atau layanan yang merepresentasikan goal dari pengguna ketika hendak menggunakan sistem.
Contoh pada Sistem Mesin ATM :

  • Mengecek saldo
  • Menarik uang
  • Mentransfer uang
  • Melakukan pembayaran

Non-Functional Requirement
Mendeskripsikan sekumpulan batasan, karakteristik dan properti pada sistem, baik dalam lingkungan pengembangan maupun operasional, atau atribut kualitas yang harus dipenuhi oleh sistem. Contoh pada mesin ATM :

Pengguna baru membutuhkan waktu belajar maksimal 10 menit untuk dapat menggunakan fungsi-fungsi utama sistem
Sistem harus tetap berfungsi minimal 10 jam setelah pasokan listrik dari PLN terhenti
Waktu yang dibutuhkan untuk kembali beroperasi setelah sistem mati minimal 2 menit

IEEE 803:1993 mengelompokkan kebutuhan non-fungsional ke dalam sejumlah kategori kualitas dari suatu perangkat lunak.
Kategori tsb secara umum dibagi dalam 2 kelompok, yaitu :

Faktor kualitas eksternal perangkat lunak. Kategori kualitas yang bisa diobservasi atau menjadi ketertarikan utama dari pelanggan. Diantaranya :

  • Ketepatan (correctness)
  • Robustness
  • Unjuk Kerja (performance)
  • Ketersediaan dan kualitas antarmuka(interface)
  • Keandalan(Reability)
  • Ketersediaan (Availability)
  • Faktor kualitas internal perangkat lunak.

Kategori kualitas yang bisa diobservasi atau menjadi ketertarikan utama dari pengembang. Diantaranya :

  • Kemudahan membaca/memahami struktur perangkat lunak(readibility)
  • Kemampuan untuk dilakukan pengujian (testability)
  • Ketersediaan dan kualitas dokumentasi (documentation)
  • Kemudahan pemeliharaan(maintainability)
  • Adaptasi terhadap lingkungan berbeda (portability)
Associated Kursus: KI142303BKI142303B
Anyone in the world

Daur hidup perangkat lunak (software life cycle – SLC) terdiri dari dua siklus kehidupan utama, yaitu :

  • Daur hidup pengembangan perangkat lunak (Software Development Life Cycle – SDLC)
  • Daur hidup pengoperasian perangkat lunak (Software Operational Life Cycle – SOLC).

Kedua siklus perangkat lunak tersebut dihubungkan oleh dua proses, yaitu proses studi kelayakan (feasibility study) dan proses peluncuran (deployment). Secara umum dapat kita ilustrasikan seperti berikut :


Penelitian Hofmann dan Lehner (2001) merekomendasikan langkah-langkah yang dilakukan untuk meningkatkan keberhasilan tahapan spesifikasi kebutuhan, diantaranya :

  1. Lakukan aktivitas dalam spesifikasi kebutuhan sepanjang durasi proyek
  2. Gunakan anggota lepas waktu untuk mendukung anggota penuh waktu (sumber daya yang memiliki kompetensi khusus).
  3. Terapkan kombinasi proses prototype dan berbasis model untuk membantu pemangku kepentingan (terutama pelanggan dan penggguna), untuk mendapatkan gambaran dari solusi yang diajukan.
  4. Sesering mungkin lakukan umpan balik dari pemangku kepentingan, mengevaluasi artifak dan material asal dari sistem lama atau yang sedang berjalan, serta sesering mungkin menggunakan panduan dari ahli
  5. Gunakan metoda pemodelan terkini (misalnya object Oriented atau Aspect Oriented) yang dikombinasikan dengan model-model dasar (seperti ERD, diagram transisi status, dan Petri-Net)
  6. Lakukan perbaikan evolusioner terhadap spesifikasi dengan menggunakan mock-ups, prototipe, peer reviews, walkyhtough, dan skenario, serta ibatkan pengguna (end user), pelanggan dan ahli teknis maupun ranah permasalahan. Rata-rata iterasi dari proses spesifikasi kebutuhan yang efektif adalah 3 iterasi.

Contoh tujuan bisnis dari proyek pembuatan Automatic Teller Machine (ATM) yang menjadi abstraksi solusinya :

  1. Peningkatan kepuasan pelanggan dalam hal melakukan transaksi perbankan 24 jam
  2. Pengurangan kasir
  3. Perluasan jaringan perbankan dengan cara yang ekonomis

Sumber  :

Associated Kursus: KI142303BKI142303B
Halaman: () 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 ... 41 ()