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:09
Anyone in the world

These documentations are maintained by the developers and actual coders. These documents, as a whole, represent information about the code. While writing the code, the programmers also mention objective of the code, who wrote it, where will it be required, what it does and how it does, what other resources the code uses, etc.The technical documentation increases the understanding between various programmers working on the same code. It enhances re-use capability of the code. It makes debugging easy and traceable.There are various automated tools available and some comes with the programming language itself. For example java comes Java Doc tool to generate technical documentation of code.

Associated Kursus: KI142303BKI142303B
Anyone in the world

There are some challenges faced by the development team while implementing the software. Some of them are mentioned below:

  • Code-reuse - Programming interfaces of present-day languages are very sophisticated and are equipped huge library functions. Still, to bring the cost down of end product, the organization management prefers to re-use the code, which was created earlier for some other software. There are huge issues faced by programmers for compatibility checks and deciding how much code to re-use.

  • Version Management - Every time a new software is issued to the customer, developers have to maintain version and configuration related documentation. This documentation needs to be highly accurate and available on time.

  • Target-Host - The software program, which is being developed in the organization, needs to be designed for host machines at the customers end. But at times, it is impossible to design a software that works on the target machines.

Associated Kursus: KI142303BKI142303B
Gambar dari PASCAL MANIRIHO 5116201701
by PASCAL MANIRIHO 5116201701 - Saturday, 24 December 2016, 19:07
Anyone in the world
Validation is process of examining whether or not the software satisfies the user requirements. It is carried out at the end of the SDLC. If the software matches requirements for which it was made, it is validated.
  • Validation ensures the product under development is as per the user requirements.
  • Validation answers the question – "Are we developing the product which attempts all that user needs from this software ?".
  • Validation emphasizes on user requirements.
Associated Kursus: KI142303BKI142303B
Gambar dari PASCAL MANIRIHO 5116201701
by PASCAL MANIRIHO 5116201701 - Saturday, 24 December 2016, 19:06
Anyone in the world
Verification is the process of confirming if the software is meeting the business requirements, and is developed adhering to the proper specifications and methodologies.
  • Verification ensures the product being developed is according to design specifications.
  • Verification answers the question– "Are we developing this product by firmly following all design specifications ?"
  • Verifications concentrates on the design and system specifications.

Targets of the test are :

  • Errors - These are actual coding mistakes made by developers. In addition, there is a difference in output of software and desired output, is considered as an error.

  • Fault - When error exists fault occurs. A fault, also known as a bug, is a result of an error which can cause system to fail.

  • Failure - failure is said to be the inability of the system to perform the desired task. Failure occurs when fault exists in the system

Associated Kursus: KI142303BKI142303B
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
Halaman: () 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 ... 41 ()