Site blog

Halaman: () 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 ... 42 ()
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 : http://swebokwiki.org/Chapter_4:_Software_Testing

 
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 : http://swebokwiki.org/Chapter_4:_Software_Testing

 
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 : https://www.it-jurnal.com/pengertian-rekayasa-perangkat-lunak/

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 : https://id.wikipedia.org/wiki/Pengembangan_perangkat_lunak

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 :

2.jpg

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  : https://aristysaputri3.wordpress.com/

Associated Kursus: KI142303BKI142303B
 
Gambar dari ABD. CHARIS FAUZAN 5116201063
by ABD. CHARIS FAUZAN 5116201063 - Friday, 23 December 2016, 22:53
Anyone in the world

Software evolution is the term used in software engineering (specifically software maintenance) to refer to the process of developing software initially, then repeatedly updating it for various reasons. The aim of software evolution would be to implement (and revalidate) the possible major changes to the system without being able a priori to predict how user requirements will evolve. The existing larger system is never complete and continues to evolve. As it evolves, the complexity of the system will grow unless there is a better solution available to solve these issues. The main objectives of software evolution are ensuring the reliability and flexibility of the system. During the 20 years past, the lifespan of a system could be on average 6–10 years[citation needed]. However, it was recently[when?] found that a system should be evolved once every few months to ensure it is adapted to the real-world environment. This is due to the rapid growth of World Wide Web and Internet Resources that make it easier for users to find related information. The idea of software evolution leads to open source development as anybody could download the source codes and hence modify it. The positive impact in this case is large amounts of new ideas would be discovered and generated that aims the system to have better improvement in variety choices.

Over time, software systems, programs as well as applications, continue to develop. These changes will require new laws and theories to be created and justified. Some models as well would require additional aspects in developing future programs. Innovations and improvements do increase unexpected form of software development. The maintenance issues also would probably change as to adapt to the evolution of the future software. Software process and development are an ongoing experience that has a never-ending cycle. After going through learning and refinements, it is always an arguable issue when it comes to matter of efficiency and effectiveness of the programs.

Associated Kursus: KI142303BKI142303B
 
Gambar dari DESEPTA ISNA ULUMI 5116201018
by DESEPTA ISNA ULUMI 5116201018 - Friday, 23 December 2016, 20:50
Anyone in the world

Software testing adalah aktivitas-aktivitas yang bertujuan untuk mengevaluasi atribut-atribut atau kemampuan sebuah program atau sistem dan penentuan apakah sesuai dengan hasil yang diharapkan.


Teknik melakukan test.

Teknik ini mencoba untuk melakukan break-down sebuah program dengan melakukan skenario tes dan data flow. Teknik ini diklasifikasikan menjadi white-box, jika tes didasarkan pada informasi tentang bagaimana perangkat lunak telah dirancang atau fokus pada kode, atau black box jika tes hanya bergantung pada input / output  perangkat lunak.

1. Based on the Software Engineer's Intuition and Experience
a. Ad Hoc
Adalah tes berdasarkan pengalaman menangani kode yang serupa
b. Exploratory Testing
Adalah tes yang tidak didefinisikan terlebih dahulu dalam pembuatan program, tetapi dirancang secara dinamis

Resouce : http://swebokwiki.org/Chapter_4:_Software_Testing

[ Mengubah: Friday, 23 December 2016, 23:46 ]
 
Anyone in the world

Language processing systems translate a natural or artificial language into another representation of that language and, for programming languages, may  also execute the resulting code. In software engineering, compilers translate an artificial programming language into machine code. Other language-processing systems may translate an XML data description into commands to query a database or to an alternative XML representation. Natural language processing systems may translate one natural language to another e.g., French to Norwegian.

A possible architecture for a language processing system for a programming language is illustrated in Picture 1. The source language instructions define the program to be executed and a translator converts these into instructions for an abstract machine. These instructions are then interpreted by another component that fetches the instructions for execution and executes them using (if necessary) data from the environment. The output of the process is the result of interpreting the instructions on the input data.

The%20architecture%20of%20a%20language%2

Picture 1. The Architecture of a Language Processing System

Of course, for many compilers, the interpreter is a hardware unit that processes machine instructions and the abstract machine is a real processor. However, for dynamically typed languages, such as Python, the interpreter may be a software component.

Programming language compilers that are part of a more general programming environment have a generic architecture (Picture 2.) that includes the following components:

1. A lexical analyzer, which takes input language tokens and converts them to an internal form.
2. A symbol table, which holds information about the names of entities (variables, class names, object names, etc.) used in the text that is being translated.
3. A syntax analyzer, which checks the syntax of the language being translated. It uses a defined grammar of the language and builds a syntax tree.
4. A syntax tree, which is an internal structure representing the program being compiled.
5. A semantic analyzer that uses information from the syntax tree and the symbol table to check the semantic correctness of the input language text.
6. A code generator that ‘walks’ the syntax tree and generates abstract machine code.

Other components might also be included which analyze and transform the syntax tree to improve efficiency and remove redundancy from the generated machine code. In other types of language processing system, such as a natural language translator, there will be additional components such as a dictionary, and the generated code is actually the input text translated into another language.

A%20pipe%20and%20filter%20compiler.JPG

Picture 2. A Pipe and Filter Compiler Architecture


There are alternative architectural patterns that may be used in a language processing system (Garlan and Shaw, 1993). Compilers can be implemented using a composite of a repository and a pipe and filter model. In a compiler architecture, the symbol table is a repository for shared data. The phases of lexical, syntactic, and semantic analysis are organized sequentially, as shown in Picture 2., and communicate through the shared symbol table.

This pipe and filter model of language compilation is effective in batch environments where programs are compiled and executed without user interaction; for example, in the translation of one XML document to another. It is less effective when a compiler is integrated with other language processing tools such as a structured editing system, an interactive debugger or a program pretty printer. In this situation, changes from one component need to be reflected immediately in other components. It is better, therefore, to organize the system around a repository, as shown in Picture 3.

a%20repository%20architcture%20.JPG

Picture 3. A Repository Architecture for A Language Processing System

This figure illustrates how a language processing system can be part of an integrated set of programming support tools. In this example, the symbol table and syntax tree act as a central information repository. Tools or tool fragments communicate through it. Other information that is sometimes embedded in tools, such as the grammar definition and the definition of the output format 
for the program, have been taken out of the tools and put into the repository. Therefore, a syntax-directed editor can check that the syntax of a program is correct as it is being typed and a pretty printer can create listings of the program in a format that is easy to read.

Source : Sommerville, Ian. 2011. Software Engineering. 9th Ed. Boston: Pearson Education, Inc.

Associated Kursus: KI142303BKI142303B
[ Mengubah: Friday, 23 December 2016, 16:21 ]
 
Halaman: () 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 ... 42 ()