Anda di halaman 1dari 22


Nama Kelompok :
Abu Umar (G.231.13.0147)
M.Fauzan Affandi (G.231.13.0158)
Muhammad Dicky Rahman (G.231.13.0159)
Anas Marzuki (G.231.13.0183)

7 Prinsip Fundamental Software testing

Sumber 1 :
1) Testing shows presence of defects: Testing can show the defects are present, but cannot prove that
there are no defects. Even after testing the application or product thoroughly we cannot say that the product
is 100% defect free. Testing always reduces the number of undiscovered defects remaining in the software
but even if no defects are found, it is not a proof of correctness.

Testing menunjukkan adanya masalah / error Testing dapat menunjukkan adanya masalah / error, tetapi
tidak bisa menjamin tidak adanya masalah / error. Setelah melakukan testing produk aplikasi secara
menyeluruh kita tidak bisa mengatakan bahwa produk kita 100% tidak memiliki error.Testing akan selalau
mengurangi jumlah error / masalah yang belum ditemukan di dalam software aplikasi, tetapi walaupun
tidak ada error yang ditemukan tetap tidak bisa dibuktikan bahwa software ini bebas error.
2) Exhaustive testing is impossible: Testing everything including all combinations of inputs and
preconditions is not possible. So, instead of doing the exhaustive testing we can use risks and priorities to
focus testing efforts.

Testing secara lengkap / menyeluruh itu tidak mungkin : Menguji segala sesuatu termasuk semua
kombinasi dari input dan kondisi sebelumnya adalah tidak mungkin. Jadi, sebagai ganti melakukan
pengujian secara menyeluruh kita bisa mengambil resiko dan prioritas untuk fokus pada upaya pengujian.
3)Early testing: In the software development life cycle testing activities should start as early as possible
and should be focused on defined objectives.

Dalam pengembangan software life cycle, aktifitas pengujian harus dilakukan sesegera mungkin dan harus
fokus pada tujuan yang sudah ditetapkan.
4)Defect clustering: A small number of modules contains most of the defects discovered during
pre-release testing or shows the most operational failures.

Terjemahan :
Sejumlah kecil modul berisi banyak masalah atau error yang ditemukan selama pengujian pra-rilis atau
menunjukkan kegagalan yang paling operasional.
5)Pesticide paradox: If the same kinds of tests are repeated again and again, eventually the same set of
test cases will no longer be able to find any new bugs. To overcome this Pesticide Paradox, it is really
very important to review the test cases regularly and new and different tests need to be written to exercise
different parts of the software or system to potentially find more defects.
Terjemahan :
Jika jenis pengujian yang sama terus diulang lagi dan lagi, maka pengujian yang sama ini tidak akan
menemukan bug / masalah baru. Untuk mengatasi ini Pesticide Paradox menjadi benar benar sangat
penting untuk meninjau pengujian secara teratur dan baru, dan pengujian yang berbeda diperlukan untuk
ditulis untuk di lakukan pada bagian dari software atau sistem yang lain untuk menemukan masalah lain.
6)Testing is context depending: Testing is basically context dependent. Different kinds of sites are tested
differently. For example, safety critical software is tested differently from an e-commerce site.
Terjemahan :
Pengujian pada dasarnya bergantung pada konteks. Berbagai jenis situs yang berbeda telah diuji secara
berbeda beda. Contohnya, keamanan-software berbahaya telah di uji secara berbeda beda dari situs
7)Absence of errors fallacy: If the system built is unusable and does not fulfil the users needs and
expectations then finding and fixing defects does not help.
Terjemahan :
Tidak adanya kesalahan / Kekeliruan : Jika sistem yang dibuat tidak dapat digunakan dan tidak memenuhi
kebutuah dan harapan pengguna, kemudian dicari dan diperbaiki masalahnya, itu tidak akan membantu.

Sumber 2 :
Software testing is an extremely creative and intellectually challenging task. When testing follows the
principles given below, the creative element of test design and execution rivals any of the preceding
software development steps.

1. Testing shows the presence of bugs

Testing an application can only reveal that one or more defects exist in the application, however, testing
alone cannot prove that the application is error free. Therefore, it is important to design test cases which
find as many defects as possible.

2. Exhaustive testing in impossible

Unless the application under test (UAT) has a very simple logical structure and limited input, it is not
possible to test all possible combinations of data and scenarios. For this reason, risk and priorities are
used to concentrate on the most important aspects to test.

3. Early testing
The sooner we start the testing activities the better we can utilize the available time. As soon as the
initial products, such the requirement or design documents are available, we can start testing. It is
common for the testing phase to get squeezed at the end of the development lifecycle, i.e. when
development has finished, so by starting testing early, we can prepare testing for each level of the
development lifecycle.
Another important point about early testing is that when defects are found earlier in the lifecycle, they
are much easier and cheaper to fix. It is much cheaper to change an incorrect requirement than having to
change a functionality in a large system that is not working as requested or as designed!

4. Defect clustering
During testing, it can be observed that most of the reported defects are related to small number of
modules within a system. i.e. small number of modules contain most of the defects in the system. This is
the application of the Pareto Principle to software testing: approximately 80% of the problems are found
in 20% of the modules.

5. The pesticide paradox

If you keep running the same set of tests over and over again, chances are no more new defects will be
discovered by those test cases. Because as the system evolves, many of the previously reported defects
will have been fixed and the old test cases do not apply anymore. Anytime a fault is fixed or a new
functionality added, we need to do regression testing to make sure the new changed software has not
broken any other part of the software. However, those regression test cases also need to change to reflect
the changes made in the software to be applicable and hopefully fine new defects.

6. Testing is context dependent

Different methodologies, techniques and types of testing is related to the type and nature of the
application. For example, a software application in a medical device needs more testing than a games
software. More importantly a medical device software requires risk based testing, be compliant with
medical industry regulators and possibly specific test design techniques. By the same token, a very
popular website, needs to go through rigorous performance testing as well as functionality testing to
make sure the performance is not affected by the load on the servers.

7. Absence of errors fallacy

Just because testing didnt find any defects in the software, it doesnt mean that the software is ready to
be shipped. Were the executed tests really designed to catch the most defects? or where they designed to
see if the software matched the users requirements? There are many other factors to be considered
before making a decision to ship the software.
Other principles to note are:

Testing must be done by an independent party.

Testing should not be performed by the person or team that developed the software since they tend to
defend the correctness of the program.

Assign best personnel to the task.

Because testing requires high creativity and responsibility only the best personnel must be assigned to
design, implement, and analyze test cases, test data and test results.

Test for invalid and unexpected input conditions as well as valid conditions.

The program should generate correct messages when an invalid test is encountered and should generate
correct results when the test is valid.

Keep software static during test.

The program must not be modified during the implementation of the set of designed test cases.

Provide expected test results if possible.

A necessary part of test documentation is the specification of expected results, even if providing such
results is impractical.


Testing menunjukkan masalah / error

Testing adalah suatu cara untuk menemukan suatu masalah / error dalam suatu software, tetapi
walaupun suatu software telah ditest tetap saja tidak bisa software itu dikatakan bebas error.

Testing Secara Menyeluruh / lengkap itu tidak mungkin.

Maksudnya melakukan testing pada semua bagian dari software aplikasi itu tidak mungkin karena
memerlukan jumlah kombinasi test case sangat besar, dan setiap ditemukan bug dan diperbaiki akan
dilakukan test ulang, jika dilakukan secara menyeluruh tentunya akan memakan waktu yang sangat

Melakukan Testing Sesegera Mungkin

Lakukanlah testing sesegera mungkin, karena semakin cepat ditemukan suatu bug / error dalam suatu
program akan semakin cepat pula penanganannya.

Pengelompokan Kesalahan / Error

Kita perlu melakukan pengelompokan error / masalah yang ditemukan, untuk mempermudah dalam
melakukan perbaikan dan sebagai catatan juga dalam melakukan perbaikan software lain yang
mempunyai kesalahan yang sama.

Pesticide Paradox
Pesticide paradox sangat sangat diperlukan, dalam melakukan pengujian sistem jika kita terus
melakukan pengujian yang sama pada masalah yang sama maka tidak akan ditemukan solusinya, oleh
karena itu diperlukan pesticide paradox yaitu suatu bentuk pengujian yang berbeda.

Testing Butuh Independensi

Testing yang paling efektif adalah yang dilakukan oleh pihak ke 3.

Tidak adanya kesalahan atau errro

Jika sistem yang dibuat tidak sesuai dengan kebutuhan yang di perlukan konsumen maka sekalipun
dilakukan pengujian sistem, dicari kesalahannya dan diperbaiki, maka tidak akan berpengaruh, yang
perlu dilakukan adalah perancangan sistem baru.

Jelaskan tentang SDLC (Software/System Development Life Cycle) !

Contohnya Waterfall cycle & Iterative cycle seperti RAID & Agile.
Sumber 1 :
System Development Life Cycle (SDLC)

atau dalam bahasa Indonesia disebut Siklus Hidup

Pengembangan Sistem adalah istilah yang digunakan untuk menjelaskan proses dalam pengembangan
Sistem Informasi.
Secara umum SDLC terdiri atas tahapan pekerjaan yang digunakan oleh pengembang sistem untuk
merancang, mendesain, membangun, serta menguji sistem informasi. Konsep dari SDLC itu sendiri
dapat mencakup pengaturan dari hardware dan software, suatu sistem dapat,diterapkan untuk hardware
atau software saja, atau dapat merupakan kombinasi dari keduanya.
SDLC itu sendiri bertujuan untuk menciptakan sebuah sistem dengan kualitas yang tinggi. Sistem
yang dimaksud disini adalah sistem yang dapat memenuhi kebutuhan pelanggan sesuai dengan tahapan
yang jelas dalam rentang waktu dan biaya yang sesuai dengan rencana.
Tahapan Pekerjaan Dalam SDLC

SDLC Model
A. Waterfall Model
1. Pengertian/Definisi
Waterfall model merupakan SDLC model yang pertama kali diperkenalkan. Dalam waterfall model,
tahapan-tahapan dalam SDLC disusun secara berurutan. Transisi antar tahapan hanya terjadi bila tahapan
yang sebelumnya sudah sepenuhnya selesai dilaksanakan sehingga tidak ada tahapan yang berjalan secara
2. Diagram

3. Karakteristik
A. Proyek dibagi menjadi


sebelum dengan sesudahnya,

berurutan yang saling berhubungan antar tahapan

dan transisi ke

tahapan berikutnya hanya terjadi bila tahapan

sebelumnya sudah selesai.

B. Terdapat penekanan lebih pada perencanaan dan manajemen waktu pelaksanaan.
C. Terdapat pengendalian secara ketat selama proses pengembangan sistem. Pengendalian ini bisa dari
pencatatan atau dokumentasi sistem terus menerus dan/atau dari ulasan/pertemuan dengan client.
4. Kelebihan
a. Cocok untuk tim sistem analis dan/atau tim manajemen proyek yang kurang berpengalaman atau tim

yang kinerjanya sedang tidak stabil.

b. Tahapan

yang berurutan memudahkan dalam kendali proyek, kecukupan proses dokumentasi, dan

pengulasan desain. Serta, memastikan kualitas hasil sistem yang dikembangkan.

c. Proses pengembangan sistem dapat diukur.
5. Kekurangan
A. Tidak fleksibel.
B. Sukar untuk melakukan proses iterasi. Permasalahan biasanya ditemui pada
analisa, tetapi karena proses yang berjalan maju, akan sukar



untuk melakukan perencanaan atau

analisa ulang.
C. Sistem tidak dapat diuji hingga sistem tersebut selesai dikembangkan.
D. Dokumentasi yang berlebihan.

B. Iterative / Incremental Model

1. Pengertian/Definisi
Iterative model adalah model SDLC yang tahapannya dilakukan berulang kali dimulai dari implementasi
skala kecil yang kemudian terus berevolusi hingga menjadi suatu sistem secara utuh.
2. Diagram

3. Karakteristik

A. Persyaratan dan kebutuhan sistem sudah didefinisikan di awal.

B. Proses pengembangan sistem dibagi menjadi beberapa iterasi dengan waterfall model skala kecil.
C. Iterasi dalam pengembangan sistem dibagi menjadi beberapa tipe dengan kebutuhan

dan / atau

tujuan masing-masing.
D. Setiap iterasi dapat berjalan bersamaan.
E. Teknologi baru sedang dipelajari pada saat pengembangan sistem.

A. Beberapa fungsi dapat dikembangan lebih cepat pada awal dari pengembangan sistem.
B. Hasil didapatkan lebih awal.
C. Perkembangan sistem dapat diukur dan direncanakan.
D. Perubahan masih dapat ditoleransi.
E. Setiap iterasi dapat dianalisa, diuji, dan dikelola dengan mudah, karena skala-nya yang sudah

5. Kekurangan
A. Tidak dapat digunakan pada proyek skala kecil.
B. Tidak cocok bila terjadi perubahan pada persyaratan dan kebutuhan sistem awal secara berkala.
Karena biasanya tidak semua persyaratan dan/atau kebutuhan sistem dapat



C. Manajemen proyek yang lebih kompleks, serta membutuhkan perhatian yang lebih.
D. Karena banyaknya proses iterasi, titik akhir dari proyek sukar untuk diidentifikasi atau ditentukan.

Sumber 2 :
SDLC adalah langkah-langkah dalam pengembangan sistem informasi.

SDLC menyediakan

framework yang lengkap untuk aktivitas rekayasa bentuk dan pembangunan sistem informasi yang formal.
SDLC diperlukan untuk memecahkan berbagai masalah berikut:
1) Bagaimana perencanaan aplikasi sistem informasi.
2) Bagaimana analisis aplikasi sistem informasi.
3) Bagaimana desain aplikasi sistem informasi.
4) Bagaimana implementasi aplikasi sistem informasi.
5) Bagaimana penggunaan aplikasi sistem informasi.
6) Bagaimana teknik-teknik pengembangan sistem informasi.

Dalam perkembangannya SDLC dilengkapi oleh berbagai teknik pengembangan

sistem, diantaranya :
1. Prototyping.
Teknik prototypingadalah proses pembuatan model sederhana untuk softwarefinal yang mengijinkan
pengguna memiliki gambaran dasar tentang program serta melakukan pengujian awal.
Jenis-jenis teknik prototyping adalah:
(a) Trowaway Prototyping.
(b) Evolutionary Prototyping.
(c) Incremental Prototyping.
Keuntungan menggunakan teknikprototyping:
(a) Mengurangi waktu dan biaya.
(b) Meningkatkan keterlibatan pengguna.
(c) Mengurangi kesalahpahaman dan kesalahan interpretasi dengan pengguna.
Kelemahan menggunakan teknikprototyping:.
(a) Analisis kurang.
(b) Biaya untuk membuat prototyping cukup tinggi.

2. Waterfall
Keuntungan menggunakan teknik waterfall:
(a) Proses menjadi teratur
(b) Estimasi proses menjadi lebih baik
(c) Jadwal menjadi lebih menentu
Kelemahan menggunakan teknikwaterfall:
(a) Sifatnya kaku, sehingga susah melakukan perubahan di tengah proses

(b) Membutuhkan daftar kebutuhan yang lengkap di awal, tapi jarang konsumen bisa memberikan
kebutuhan secara lengkap diawal
Solusi: Modified Waterfall.

Sumber 3 :
Agile SDLC model is a combination of iterative and incremental process models with focus on process
adaptability and customer satisfaction by rapid delivery of working software product.
Agile model believes that every project needs to be handled differently and the existing methods need to be
tailored to best suit the project requirements. In agile the tasks are divided to time boxes (small time frames)
to deliver specific features for a release.
Iterative approach is taken and working software build is delivered after each iteration. Each build is
incremental in terms of features; the final build holds all the features required by the customer.
Terjemahan :
Model SDLC Agile adalah kombinasi dari model iterativ dan incremental dengan fokus pada proses
adaptasi dan kepuasan pelanggan dengan penyampaian cepat pada software produk.
Agile model yakin bahwa setiap proyek harus ditangani secara berbeda dan metode yang ada harus
disesuaikan dengan persyaratan projek terbaik. Dalam Agile tugas dibagi ke kotak waktu (kerangka kecil
waktu) untuk memberikan fitur khusus untuk sebuah rilis.
Pendekatan iteratif diambil dan perancangan software kerja disampaikan setelah tiap iterasi. Setiap
membangun incremental dalam hal fitur; rancangan akhir memegang semua fitur yang diperlukan oleh


System Development Life Cycle merupakan suatu kumpulan langkah langkah dalam melakukan
pengembangan sebuah sistem informasi baik untuk merancang, mendesain, membangun serta menguji
sebuah sistem informasi.

Tahapan-Tahapan Dalam SDLC

1. Merencanakan dan menganalisa persyaratan yang dibutuhkan;
2. Memetakan persyaratan dan kebutuhan sistem;
3. Mendesain struktur dari sistem tersebut;
4. Membangun atau mengembangan sistem tersebut;
5. Menguji sistem tersebut;
6. Menerapan sistem tersebut; dan
7. Melakukan perawatan terhadap sistem tersebut secara berkala.

Waterfall Model merupakan tahapan-tahapan dalam SDLC yang disusun secara berurutan. Transisi
antar tahapan hanya terjadi bila tahapan yang sebelumnya sudah sepenuhnya selesai dilaksanakan,
sehingga tidak ada tahapan yang berjalan secara bersamaan.

Iterative model adalah model SDLC yang tahapannya dilakukan berulang kali dimulai dari
implementasi skala kecil yang kemudian terus berevolusi hingga menjadi suatu sistem secara utuh.
Model SDLC Agile adalah kombinasi dari model iterativ dan incremental dengan fokus pada proses
adaptasi dan kepuasan pelanggan dengan penyampaian cepat pada software produk.

Jelaskan tentang STLC (Software Test Life Cycle) !

Sumber 1 :
Software Testing Life Cycle
What is STLC (Software Testing LifeCycle)?
The process of testing a software in a well planned and systematic way is known as software testing
lifecycle (STLC).
Different organizations have different phases in STLC however generic Software Test Life Cycle (STLC)
for waterfall development model consists of the following phases.
1. Requirements Analysis
2. Test Planning
3. Test Analysis
4. Test Design
5. Test Construction and Verification
6. Test Execution and Bug Reporting
7. Final Testing and Implementation
8. Post Implementation
1. Requirements Analysis
In this phase testers analyze the customer requirements and work with developers during the design phase
to see which requirements are testable and how they are going to test those requirements.
It is very important to start testing activities from the requirements phase itself because the cost of fixing
defect is very less if it is found in requirements phase rather than in future phases.
2. Test Planning
In this phase all the planning about testing is done like what needs to be tested, how the testing will be
done, test strategy to be followed, what will be the test environment, what test methodologies will be
followed, hardware and software availability, resources, risks etc. A high level test plan document is
created which includes all the planning inputs mentioned above and circulated to the stakeholders.
Usually IEEE 829 test plan template is used for test planning.
3. Test Analysis
After test planning phase is over test analysis phase starts, in this phase we need to dig deeper into project
and figure out what testing needs to be carried out in each SDLC phase.
Automation activities are also decided in this phase, if automation needs to be done for software product,
how will the automation be done, how much time will it take to automate and which features need to be
Non functional testing areas(Stress and performance testing) are also analyzed and defined in this phase.
4. Test Design

In this phase various black-box and white-box test design techniques are used to design the test cases for
testing, testers start writing test cases by following those design techniques, if automation testing needs to
be done then automation scripts also needs to written in this phase.
5. Test Construction and Verification
In this phase testers prepare more test cases by keeping in mind the positive and negative scenarios, end
user scenarios etc. All the test cases and automation scripts need to be completed in this phase and got
reviewed by the stakeholders. The test plan document should also be finalized and verified by reviewers.
6. Test Execution and Bug Reporting
Once the unit testing is done by the developers and test team gets the test build, The test cases are executed
and defects are reported in bug tracking tool, after the test execution is complete and all the defects are
reported. Test execution reports are created and circulated to project stakeholders.
After developers fix the bugs raised by testers they give another build with fixes to testers, testers do
re-testing and regression testing to ensure that the defect has been fixed and not affected any other areas of
Testing is an iterative process i.e. If defect is found and fixed, testing needs to be done after every defect
After tester assures that defects have been fixed and no more critical defects remain in software the build is
given for final testing.
7. Final Testing and Implementation
In this phase the final testing is done for the software, non functional testing like stress, load and
performance testing are performed in this phase. The software is also verified in the production kind of
environment. Final test execution reports and documents are prepared in this phase.
8. Post Implementation
In this phase the test environment is cleaned up and restored to default state, the process review meetings
are done and lessons learnt are documented. A document is prepared to cope up similar problems in future

Sumber 2 :

What is Software Testing Life Cycle (STLC)

Software Testing Life Cycle refers to a testing process which has specific steps to be executed in a definite
sequence to ensure that the quality goals have been met. In STLC process, each activity is carried out in a
planned and systematic way. Each phase has different goals and deliverables. Different organizations have
different phases in STLC; however the basis remains the same.
Below are the phases of STLC:

Requirements phase
Planning Phase
Analysis phase
Design Phase
Implementation Phase
Execution Phase
Conclusion Phase
Closure Phase

#1. Requirement Phase:

During this phase of STLC, analyze and study the requirements. Have brain storming sessions with other
teams and try to find out whether the requirements are testable or not. This phase helps to identify the
scope of the testing. If any feature is not testable, communicate it during this phase so that the mitigation
strategy can be planned.
#2. Planning Phase:
In practical scenarios, Test planning is the first step of the testing process. In this phase we identify the
activities and resources which would help to meet the testing objectives. During planning we also try to
identify the metrics, the method of gathering and tracking those metrics.
On what basis the planning is done? Only requirements?
The answer is NO. Requirements do form one of the bases but there are 2 other very important factors
which influence test planning. These are:
Test strategy of the organization.
Risk analysis / Risk Management and mitigation.
#3. Analysis Phase:
This STLC phase defines WHAT to be tested. We basically identify the test conditions through the
requirements document, product risks and other test basis. The test condition should be traceable back to
the requirement. There are various factors which effect the identification of test conditions:
Levels and depth of testing
Complexity of the product
Product and project risks
Software development life cycle involved.

Test management
Skills and knowledge of the team.
Availability of the stakeholders.
We should try to write down the test conditions in a detailed way. For example, for an e-commerce web
application, you can have a test condition as User should be able to make a payment. Or you can detail it
out by saying User should be able to make payment through NEFT, debit card and credit card. The most
important advantage of writing the detailed test condition is that it increases the test coverage, since the test
cases will be written on the basis of the test condition, these details will trigger to write more detailed test
cases which will eventually increase the coverage. Also identify the exit criteria of the testing, i.e
determine some conditions when you will stop the testing.
#4. Design Phase:
This phase defines HOW to test. This phase involves the following tasks:
Detail the test condition. Break down the test conditions into multiple sub conditions to increase
Identify and get the test data
Identify and set up the test environment.
Create the requirement traceability metrics
Create the test coverage metrics.
#5. Implementation Phase:
The major task in this STLC phase is of creation of the detailed test cases. Prioritize the test cases also
identify which test case will become part of the regression suite. Before finalizing the test case, It is
important to carry out the review to ensure the correctness of the test cases. Also dont forget to take the
sign off of the test cases before actual execution starts. If your project involves automation, identify the
candidate test cases for automation and proceed for scripting the test cases. Dont forget to review them!
#6. Execution Phase:
As the name suggests, this is the Software Testing Life Cycle phase where the actual execution takes place.
But before you start your execution, make sure that your entry criterion is met. Execute the test cases, log
defects in case of any discrepancy. Simultaneously fill your traceability metrics to track your progress.
#7. Conclusion Phase:
This STLC phase concentrates on the exit criteria and reporting. Depending on your project and
stakeholders choice, you can decide on reporting whether you want to send out a daily report of weekly
report etc. There are different types of reports ( DSR Daily status report, WSR Weekly status reports)
which you can send, but the important point is, the content of the report changes and depends upon whom
you are sending your reports. If Project managers belong to testing background then they are more
interested in the technical aspect of the project, so include the technical things in your report ( number of
test cases passed, failed, defects raised, severity 1 defects etc.). But if you are reporting to upper
stakeholders, they might not be interested in the technical things so report them about the risks that have
been mitigated through the testing.
#8. Closure Phase:
Tasks for the closure activities include the following:

Check for the completion of the test. Whether all the test cases are executed or mitigated deliberately.
Check there are no severity 1 defects opened.
Do lessons learnt meeting and create lessons learnt document.( Include what went well, where are the
scope of improvements and what can be improved)


Software testing life cycle merupakan proses pengujian software dengan cara terencana dan sistematis,
maksudnya dengan menggunakan langkah - langkah spesifik yang akan dieksekusi dalam urutan yang
pasti untuk memastikan bahwa tujuan dan kualitas telah terpenuhi.

Tahapan tahapan dalam STLC

Tahapan persyaratan
Tahap perencanaan
Tahap Analisis
Tahap Desain
Tahap Implementasi
Tahap Eksekusi
Tahap Kesimpulan
Tahap Penutupan