Auditing

AUDITING

Definisi Dasar Auditing

Auditing dalam arti luas dapat didefinisikan sebagai berikut :

“Suatu proses sistematis untuk memperoleh dan mengevaluasi bukti secara objektif mengenai asersi-asersi tentang kegiatan dan kejadian ekonomi untuk menetapkan derajat kesesuaian antara asersi-asersi tersebut dengan kriteria yang telah ditetapkan sebelumnya serta penyampaian hasil-hasilnya kepada pihak-pihak yang berkepentingan.”

Kata asersi mempunyai arti khusus dalam auditing, asersi merupakan representasi oleh manajemen yang dimuat dalam komponen, catatan, atau sistem laporan keuangan.

Fungsi Audit

Mengapa Belajar Auditing ?

1.      Banyak mahasiswa akuntansi yang memilih karir di bidang auditing baik dalam bidang akuntansi publik, industri, atau pemerintahan.

2.      Banyak orang di dunia bisnis mengandalkan  jasa auditor.

3.      Pelajaran auditing mengembangkan keahlian yang dapat dikembangkan digunakan di sejumlah disiplin ilmu bisnis dan pemerintahan seperti pemahaman tentang pengendalian keuangan, penilaian resiko, dan evaluasi bisnis.

4.      Auditing merupakan bagian yang tak terpisahkan dari bisnis dan pemerintahan. Oleh karena itu apabila bekerjasama dengan para auditor diperlukan pemahaman yang baik tentang tugas-tugas auditor.

Perbedaan antara Akuntansi dan Auditing

Akuntansi adalah proses yang menghasilkan informasi dalam bentuk laporan keuangan dan data keuangan lainnya. Fungsi akuntansi merupakan tanggung jawab manajemen perusahaan.

Auditing adalah proses yang mengevaluasi dan menghasilkan kesimpulan-kesimpulan tentang informasi tersebut berdasarkan kriteria yang telah ditetapkan.

Contoh :

Akuntan mencatat produk yang dikirim kepada pelanggan dan mencatatmya sebagai penjualan kredit.

Auditor tidak mencatat transaksi tersebut, tetapi mengumpulkan dan mengevaluasi bukti dan menyatakan kesimpulan apakah penjualan kredit tersebut telah secara benar ditunjukkan dalam laporan keuangan.

Jenis-jenis Audit

-                Audit Laporan Keuangan

Merupakan kegiatan mengumpulkan bukti tentang asersi-asersi  laporan keuangan sebuah entitas dan menggunakan bukti tersebut untuk menetapkan apakah asersi-asersi tersebut telah sesuai dengan prinsip-prinsip akuntansi yang berlaku umum atau dasar akuntansi komprehensif lainnya.

-           Audit Kepatuhan

Adalah pengumpulan bukti untuk menetapkan apakah kegiatan seseorang atau entitas telah sesuai dengan hukum dan peraturan.

-                Audit Operasional

Merupakan sebuah review sistematis dari  suatu kegiatan organisasi (atau bagian tertentu dari kegiatan organisasi ) dalam hubungannya dengan tujuan tertentu dari penetapan kinerja, pengidentifikasian peluang untuk perbaikan, dan pengembangan rekomendasi untuk perbaikan atau untuk kegiatan yang akan datang.

Jenis-jenis Auditor

1.      Auditor Eksternal yaitu auditor independen yang bersertifikasi akuntansi publik, di luar entitas / organisasi yang akan diaudit, yang menawarkan jasa audit independen mereka berdasarakan kontrak.

2.      Auditor Internal merupakan seorang pegawai dari suatu entias atau organisasi yang mengevalusi dan memeriksa aktivitas entitas atau organisasinya sebagai suatu jasa bagi entitas atau organisasinya.

3.      Auditor Pemerintah yaitu auditor yang dipekerjakan di berbagai kantor pemerintahan di tingkat federal, negara bagian, dan lokal yang mengaudit beberapa fungsi organisasional untuk alasan tertentu.

Susunan Teoritis Auditing

Beberapa elemen penting dari susunan teoritis auditing , yaitu :

1.      Data yang diaudit dapat dibuktikan

Suatu audit mensyaratkan pengumpulan bukti yang kuantitas dan kualitasnya sesuai sehingga untuk mendukungnya dibutuhkan data. Contonhya laporan keuangan terdiri dari akun neraca dan akun transaksi yang dapat dibuktikan.

2.   Konflik jangka pendek mungkin terjadi antara manajer yang menyiapkan data dengan auditor yang memeriksa data.

Manajer merasa diharuskan membuat data keuangan sesuai dengan kepentingannya (biasanya penghasilan tinggi) sedangkan auditor harus membuktikan data yang benar, tidak berpihak kepada manajer

3.   Auditor harus independen dan mempunyai kebebasan dari paksaan manajer.

Auditor harus mengumpulkan bukti dan harus melaporkan hasil audit secara objektif kepada pihak yang ingin mengetahui hasilnya.

4.   Suatu audit menguntungkan publik

Audit dapat mencegah salah pengertian, penipuan, atau pandangan yang salah juga dapat memberi keuntungan yang berasal dari biaya yang terselamatkan atau dari pendeteksian penipuan.

Mengapa Laporan Keuangan Diaudit ?

Ada empat kondisi yang menyebabkan perlunya auditing:

1.      Ada potensi konflik antara penyedia informasi dan pemakai informasi.

2.      Informasi kemungkinan mempunyai konsekuensi ekonomi yang substansial bagi pengambil keputusan.

3.      Para ahli sering  diminta untuk menyiapkan dan mengklarifikasi informasi.

4.      Para pengguna informasi sering mempertanyakan kualitas informasi.

Secara khusus audit laporan keuangan dilakukan untuk alasan-alasan :

1.      Kebutuhan dari Kreditor dan Investor

Auditor independen mempunyai tugas untuk menyediakan kreditor dan investor  pendapat yang tidak bias tentang apakah laporan keuangan telah secara benar disajikan. Para investor dan kreditor menganggap auditor sebagai penjaga integritas dari laporan keuangan perusahaan.

2.   Teori Kepengurusan atau Keagenan

Sebuah penjelasan dari permintaan untuk audit yang menyatakan bahwa manajer sebuah perusahaan menginginkan audit karena kepercayaan yang sebuah audit tambah ke laporan keuangan representasi.

3.   Teori Motivasi

Menurut teori ini penilaian yang mengandung motivasi dari suatu audit akan menambah nilai dari informasi yang terkandung dalam laporan keuangan.

BATASAN SEBUAH AUDIT

1.  Beberapa kesimpulan audit dibuat atas pemeriksaan atas contoh dari bukti yang ada. Biasanya laporan keuangan didukung oleh ribuan bahkan jutaan dokumen. Proses audit biasanya terbentur dengan biaya dan waktu dan membutuhkan sebuah pemeriksaan yang mendukung pengungkapan laporan keuangan. Beberapa contoh dapat memberikan keterbatasan untuk dipertimbangkan, meskipun demikian, kesimpulan dapat ditarik dari pemeriksaan contoh bukti yang ada sebagai subjek ketidakpastian.

2.   Beberapa bukti yang mendukung laporan keuangan harus didapatkan dari perwakilan manajemen meskipun auditor dapat memperoleh bukti yang menguatkan atau bahkan tidak menguatkan. Oleh sebab itu dibutuhkan kepercayaan penuh kepada perwakilan manajemen. Jika integritas manajemen kurang, maka auditor dapat memberikan pendapat yang tidak benar atas laporan keuangan

3. Kelemahan manusia seperti halnya kelelahan & kecerobohan dapat menyebabkan auditor tidak melihat bukti-bukti yang berhubungan, memeriksa jenis bukti yang salah atau menarik kesimpulan yang salah atas laporan keuangan yang diaudit.

INTEGRITAS AUDITOR

Auditor harus membuat keputusan dan pendapat berdasarkan pemeriksaan. Dengan demikian, auditor harus memiliki ketajaman atas integritas tanpa mengenyampingkan kepentingan sebagai akuntan publik.

Integritas merupakan sikap yang mandiri dalam menjaga sifat profesionalnya. Tak ada sikap yang lebih baik daripada keinginan auditor untuk menarik kesimpulan  berdasarkan audit atas laporan keuangan klien yang mengikuti pelatihan akuntansi yang dapat diterima tetapi dapat dipertanggungjawabkan.

SEJARAH AUDITING

þ   Auditing Primitif  → Mesir dan Babylonia

Penguasa Mesir kuno menggunakan catatan kerja terpisah satu sama lain untuk memeriksa catatan keuangan.

þ   Auditing di Yunani Kuno dan Romawi Kuno

Audit telah menjadi tradisi/ kebudayaan masyarakat barat terutama di Yunani Kuno dan Romawi Kuno, dimana para penguasa menyerahkan tata buku mereka kepada auditor yang ditunjuk.

þ   Auditing pada Abad Pertengahan

Audit menjadi makin rumit karena para pegawai mampu melakukan perhitungan independen atas uang yang dikumpulkan para polisi daerah kepada kerajaan.

þ   Auditing pada Masa Revolusi Industri

Revolusi merupakan titik tonggak pertama atas profesi audit, karena pemisahan fungsi antara pemilik dengan manajer yang semakin nyata sehingga semakin dibutuhkannya audit.

þ   Auditing Awal di AS

Berkembang pada akhir abad ke-19 dan awal abad 20, dimana menekankan pemeriksaannya pada stewardship manajemen dan mendeteksi kesalahan. Audit di AS terutama pada Balance Sheet, karena tujuan dari audit adalah untuk menjamin keuangan kepada bank.

UML dan Waterfall

Unified Modelling Language (UML)

Definisi Unified Modelling Language (UML) adalah sebuah "bahasa" yg telah menjadi standar dalam industri untuk visualisasi, merancang dan mendokumentasikan sistem piranti lunak.UML menawarkan sebuah standar untuk merancang model sebuah sistem.

1. Composite Structure Diagram Diagram struktur komposit adalah digunakan menunjukkan struktur internal dari sebuah kelas.contoh composite structure diagram: 
2.  Activity Diagram Diagram aktivitas mewakili alur kerja dengan cara grafis. Mereka dapat digunakan untuk menggambarkan alur kerja bisnis atau alur kerja operasional dari setiap komponen dalam sistem. Terkadang diagram aktivitas digunakan sebagai alternatif untuk diagram mesin Negara. Contoh activity diagram: 
3. 3. Timing Diagram Diagram waktu sangat mirip dengan diagram urutan.Mereka mewakili perilaku objek dalam jangka waktu tertentu. Jika hanya satu objek diagram lurus ke depan tetapi jika lain satu objek yang terlibat, mereka dapat digunakan untuk menunjukkan interaksi objek selama kerangka waktu itu juga.contoh timing diagram: 
4. Communication Diagram Diagram Komunikasi disebut kolaborasi diagram di UML . Hal ini mirip dengan diagram urutan namun fokusnya adalah pada pesan lewat antara objek. Informasi yang sama dapat direpresentasikan dengan menggunakan diagram urutan dan objek yang berbeda.contoh communicatioan diagram: 
5. Package Diagram Seperti namanya diagram paket menunjukkan dependensi antara paket yang berbeda dalam sistem.pengecekan artikel ini untuk mempelajari lebih lanjut tentang dependensi dan unsur-unsur yang ditemukan di paket diagram.contoh package diagram: 
6. Deployment Diagram Sebuah diagram penyebaran menunjukkan perangkat keras sistem dan perangkat lunak dalam perangkat keras tersebut. Diagram penyebaran berguna ketika solusi perangkat lunak dikerahkan di beberapa mesin dengan masing-masing memiliki konfigurasi yang unik. Berikut adalah contoh diagram penyebaran. 
7. Class Diagram Diagram kelas yang bisa dibilang tipe UML diagram yang paling sering digunakan. Ini adalah blok bangunan utama dari setiap solusi berorientasi objek. Ini menunjukkan kelas dalam sistem, atribut dan operasi dari setiap kelas dan hubungan antara masing-masing kelas. Dalam alat pemodelan yang paling kelas memiliki tiga bagian, nama di atas, atribut di tengah dan operasi atau metode di bagian bawah. Dalam sistem yang besar dengan banyak kelas kelas terkait dikelompokkan bersama-sama untuk membuat diagram kelas. Hubungan yang berbeda antara diagram yang menunjukkan oleh berbagai jenis Panah . Di bawah ini adalah contoh gambar dari diagram kelas. 
8. Profile Diagram Diagram Profil adalah jenis diagram baru yang diperkenalkan di UML . Ini adalah jenis diagram yang sangat jarang digunakan dalam spesifikasi apapun. Contoh profile diagram: 
9. Use Case Diagram Paling dikenal diagram jenis diagram UML perilaku, Gunakan diagram kasus memberikan gambaran grafis dari aktor yang terlibat dalam sistem, fungsi yang berbeda yang dibutuhkan oleh aktor-aktor dan bagaimana fungsi-fungsi yang berbeda berinteraksi. Ini adalah titik awal untuk diskusi proyek karena Anda dapat dengan mudah mengidentifikasi pelaku utama yang terlibat dan proses utama dari sistem. Mengklik untuk membaca lebih lanjut tentang elemen diagram use case dan template.contoh use case diagram: 
10.  10 .Object Diagram Obyek Diagram, kadang-kadang disebut sebagai diagram Instance sangat mirip dengan diagram kelas. Seperti diagram kelas mereka juga menunjukkan hubungan antara obyek, tetapi mereka menggunakan contoh-contoh dunia nyata. Mereka digunakan untuk menunjukkan bagaimana sistem akan terlihat seperti pada waktu tertentu. Karena ada data yang tersedia di objek mereka sering digunakan untuk menjelaskan hubungan yang kompleks antara objek.contoh object diagram:
11. Component diagram Sebuah diagram komponen menampilkan hubungan struktural komponen dari sistem software. Ini kebanyakan digunakan ketika bekerja dengan sistem yang kompleks yang memiliki banyak komponen. Komponen berkomunikasi satu sama lain menggunakan antarmuka.antarmuka yang terhubungkan menggunakan konektor. Di bawah gambar menunjukkan diagram komponen.
12. State Machine Diagram Mesin negara diagram mirip dengan diagram aktivitas meskipun notasi dan penggunaan perubahan sedikit. Mereka kadang-kadang dikenal sebagai negara diagram atau mulai diagram grafik juga. Ini sangat berguna untuk menjelaskan perilaku objek yang bertindak berbeda menurut negara mereka adalah pada saat ini. Negara mesin diagram di bawah ini menunjukkan dasar Serikat dan tindakan.
13. Sequence Diagram Urutan diagram di UML menunjukkan bagaimana objek berinteraksi satu sama lain dan urutan interaksi tersebut terjadi. Sangat penting untuk dicatat bahwa mereka menunjukkan interaksi untuk skenario tertentu. Proses diwakili vertikal dan interaksi adalah menunjukkan sebagai panah.
14. Interaction Overview Diagram Interaksi diagram gambaran adalah sangat mirip dengan diagram aktivitas. Sementara diagram aktivitas menunjukkan urutan diagram gambaran proses Interaksi menunjukkan urutan diagram interaksi. Dalam istilah sederhana mereka bisa disebut koleksi diagram interaksi dan urutan mereka terjadi. Seperti disebutkan sebelumnya ada tujuh jenis diagram interaksi, sehingga salah satu dari mereka dapat menjadi node dalam sebuah diagram gambaran interaksi.contohnya: 

Pemodelan Dalam Rekayasa Perangkat Lunak 

Pemodelan dalam suatu rekayasa perangkat lunak merupakan suatu hal yang dilakukan di tahapan awal.Di dalam suatu rekayasa dalam perangkat lunak sebenarnya masih memungkinkan tanpa melakukan suatu pemodelan.Hal itu tidak dapat lagi dilakukan dalam suatu industri perangkat lunak. Pemodelan delam perangkat lunak merupakan suatu yang harus dikerjakan di bagian awal dari rekayasa, dan pemodelan ini akan mempengaruhi perkerjaan-pekerjaan dalam rekayasa perangkat lunak tersebut. 

Proses 

Di dalam suatu industri dikenal berbagai macam proses, demikian juga halnya dengan industri perangkat lunak. Perbedaan proses yang digunakan akan menguraikan aktivitas-aktivitas proses dalam cara-cara yang berlainan. Perusahaan yang berbeda menggunakan proses yang berbeda untuk menghasilkan produk yang sama. Tipe produk yang berbeda mungkin dihasilkan oleh sebuah perusahaan dengan menggunakan proses yang berbeda. Namun beberapa proses lebih cocok dari lainnya untuk beberapa tipe aplikasi. Jika proses yang salah digunakan akan mengurangi kualitas kegunaan produk yang dikembangkan. 

Karena banyaknya variasi dalam model proses yang digunakan maka tidak mungkin menghasilkan gambaran-gambaran yang reliabel untuk alokasi biaya dalam aktivitas-aktivitas ini. 

Modifikasi perangkat lunak biasanya lebih dari 60 % dari total biaya pembuatan perangkat lunak. Presentasi ini terus bertambah karena lebih banyak perangkat lunak dihasilkan dan dipelihara.Pembuatan perangkat lunak untuk suata perubahan adalah penting. Proses perangkat lunak komplek dan melibatkan banyak aktivitas. 

Seperti produk, proses juga memiliki atribut dan karakteristik seperti :

 • Understandability, yaitu sejauh mana proses secara eksplisit ditentukan dan bagaimana kemudahan definisi proses itu dimengerti. 

• Visibility, apakah aktivitas-aktivitas proses mencapai titik akhir dalam hasil yang jelas sehingga kemajuan dari proses tersebut dapat terlihat nyata/jelas 

• Supportability, yaitu sejauh mana aktivitas proses dapat didukung oleh CASE

• Acceptability, apakah proses yang telah ditentukan oleh insinyur dapat diterima dan digunakan dan mampu bertanggung jawab selama pembuatan produk perangkat lunak 

• Reliability, apakah proses didesain sedikian rupa sehingga kesalahan proses dapat dihindari sebelum terjadi kesalahan pada produk.

• Robustness, dapatkah proses terus berjalan walaupun terjadi masalah yang tak diduga 

• Maintainability, dapatkah proses berkembang untuk mengikuti kebutuhan atau perbaikan 

• Rapidity, bagaimana kecepatan proses pengiriman sistem dapat secara lengkap memenuhi spesifikasi. 

Model 

Tidak mungkin untuk mengoptimalkan semua atribut proses secara serentak. Contohnya, jika pengembangkan proses cepat dilakukan mungkin kita perlu mengurangi visibility proses karena pembuatan proses yg nyata berarti pembuatan dokumen secara teratur. Ini akan memperlambat proses. 

Model proses perangkat lunak masih menjadi object penelitian, tapi sekarang ada banyak model umum atau paradigma yang berbeda dari pengembangan perangkat lunak, antara lain: 

• Pendekatan Waterfall Berisi rangkaian aktivitas proses seperti yang telah diuraikan diatas dan disajikan dalam proses yang terpisah, seperti spesifikasi kebutuhan, implementasi desain perangkat lunak, uji coba dst. Setelah setiap langkah didefinisikan, langkah tersebut di sign off dan pengembangan dilanjutkan pada langkah berikutnya. 

• Pengembangan secara evolusioner Pendekatan ini interleaves aktivitas spesifikasi, pengembangan dan validasi. Sistem awal dengan cepat dikembangkan dari kastamer untuk memproduksi sistem yang memenuhi kebutuhan kastamer.Kemudian sistem disampaikan.Sistem itu mungkin diimplementasikan kembali dengan pendekatan yang lebih terstruktur untuk menghasilkan sistem yang kuat dan maintable. 

• Transformasi formal Pendekatan ini berdasarkan pembuatan spesifikasi sistem formal secara matematik dan transformasi spesifikasi dengan menggunakan metode matematik atau dengan suatu program.Transformasi ini adalah correctnesspreserving ini berarti bahwa kita dapat yakin program yang dikembangkan sesuai dengan spesifikasi. 

• Penggabungan sistem dengan menggunakan komponen-komponen yang dapat digunakan kembali. Teknik ini menganggap bagian-bagian dari sistem sudah ada. Proses pengembangan sistem lebih berfokus pada penggabungan bagian-bagian daripada pengembangan tiap bagian. 

Dua pertama dari pendekatan-pendekatan diatas yaitu waterfall dan pengembangan evolusioner, saat ini banyak digunakan dalam pengembangan sistem.Beberapa sistem sudah dibuat dengan menggunakan transformasi correctness preserving tapi ini masih menjadi penelitian. 

Metode penggunaan kembali (reuse) umum di jepang. Metode ini sekiranya akan diakui oleh Eropa dan Amerika Utara. Di US metode ini dimulai 1995 dengan anggaran 150 million dolars. Bagaimanapun juga reuse masih suatu penelitian, terlalu cepat untuk berkomentar tentang keefektifannya. 

Waterfall 

Model ini telah diperoleh dari proses engineering lainnya. Model ini menawarkan cara pembuatan perangkat lunak secara lebih nyata. 

 Langkah-langkah yang penting dalam model ini adalah 

 • Penentuan dan analisis spesifikasi Jasa, kendala dan tujuan dihasilkan dari konsultasi dengan pengguna sistem.Kemudian semuanya itu dibuat dalam bentuk yang dapat dimengerti oleh user dan staf pengembang. 

• Desain sistem dan perangkat lunak Proses desain sistem membagi kebutuhan-kebutuhan menjadi sistem perangkat lunak atau perangkat keras. Proses tersebut menghasilkan sebuah arsitektur sistem keseluhan. Desain perangkat lunak termasuk menghasilkan fungsi sistem perangkat lunak dalam bentuk yang mungkin ditransformasi ke dalam satu atau lebih program yang dapat dijalankan. 

• Implementasi dan ujicoba unit Selama tahap ini desain perangkat lunak disadari sebagai sebuah program lengkap atau unit program.Uji unit termasuk pengujian bahwa setiap unit sesuai spesifikasi.

 • Integrasi dan ujicoba sistem Unit program diintegrasikan dan diuji menjadi sistem yang lengkap untuk menyakinkan bahwa persyaratan perangkat lunak telah dipenuhi. Setelah ujicoba, sistem disampaikan ke kastamer 

• Operasi dan pemeliharaan 

Normalnya, ini adalah phase yang terpanjang.Sistem dipasang dan digunakan. Pemeliharaan termasuk pembetulan kesalahan yang tidak ditemukan pada langkah sebelumnya.Perbaikan implementasi unit sistem dan peningkatan jasa sistem sebagai kebutuhan baru ditemukan. 

Gambar 1. Pemodelan Waterfall 

Dalam prakteknya, setiap langkah sering tumpang tindih dan saling memberi informasi satu sama lain. Proses perangkat lunak tidak linier dan sederhana tapi mengandung urutan iterasi dari aktivitas pengembangan. Selama di langkah terakhir, perangkat lunak telah digunakan.Kesalahan dan kelalaian dalam menentukan kebutuhan perangkat lunak original dapat diatasi. 

Sayangnya, model yang banyak mengandung iterasi sehingga membuat sulit bagi pihak manajemen untuk memeriksa seluruh rencana dan laporan. Maka dari itu, setelah sedikit iterasi, biasanya bagian yang telah dikembangkan akan dihentikan dan dilanjutkan dengan langkah pengembangan selanjutnya. 

Masalah-masalah selama resolusi selanjutnya, dibiarkan atau diprogram. Pemberhentian yang prematur dari persyaratan akan berarti bahwa sistem tidak akan sesuai dengan keinginan user. Mungkin juga sistem terstruktur secara jelek yang sebenarnya merupakan masalah desain akan dibiarkan karena terkalahkan oleh trik implementasi. 

Masalah pendekatan waterfall adalah ketidakluwesan pembagian project ke dalam langkah yang nyata/jelas.Sistem yang disampaikan kadang-kadang tidak dapat digunakan sesuai keinginan kastamer. Namun demikian model waterfall mencerminkan kepraktisan engineering. Konsekuensinya, model proses perangkat lunak yang berdasarkan pada pendekatan ini digunakan dalam pengembangan sistem perangkat lunak dan hardware yang luas. 

 Pengembangan Evolusioner 

Model ini berdasarkan pada ide pengembangan pada implementasi awal yang akan menghasilkan komentar pemakai sehingga dapat dilakukan perbaikan melalui banyak versi sampai sistem yang mencukupi dapat dikembangan. Selain memiliki aktivitas-aktivitas yang terpisah model ini memberikan feedback dengan cepat dan serentak 

Terdapat 2 tipe pada model ini 

 1. Pemprograman evolusioner Dimana tujuan proses adalah bekerjasama dengan kastamer untuk menghasilkan kebutuhan-kebutuhan dan menyampaikan sistem akhir kepada pemakai/kastamer. Pengembangan dimulai dengan bagian-bagian sistem yang dimengerti. Sistem dikembangkan melalui penambahan features sesuai yang diusulkan oleh kastamer. 

 2. Pemodelan Dimana tujuan pengembangan evolusioner pada tipe ini adalah mengetahui kebutuhan-kebutuhan kastamer dan mengembangkan difinisi kebutuhan yang lebih baik untuk sistem.Model/contoh difikuskan pada penelitian bagian-bagian kebutuhan kastamer yang kurang dimengerti. 

Pemprograman evolusioner penting saat sulit untuk membuat spesifikasi sistem secara rinci.Beberapa orang mungkin setuju bahwa semua sistem masuk dalam tipe ini.Namun, pemprograman evolusioner banyak digunakan dalam pengembangan sistem AI (artificial intelligence) yang berusaha untuk menyamai kemampuan manusia.

Kita tidak mungkin membuat spesifikasi yang rinci untuk perangkat lunak yang menyamai manusia karena kita tidak mengerti bagaimana manusia menjalankan tugas-tugas mereka. 

Pendekatan evolusioner biasanya lebih efektif daripada pendekatan waterfall untuk hal pengembangan perangkat lunak yang harus dengan segera dapat memenuhi kebutuhan kastamer. 

Namun, dari segi teknik dan manajemen, model ini memiliki masalah mendasar yaitu: • Proses tidak visibel.

 Manager-manager membutuhkan "deliverables" yang teratur untuk mengukur kemajuan. Jika sistem dikembangkan dengan cepat akan terjadi pemborosan pada pembuatan dokumen yang menggambarkan setiap versi sistem. 

• Sistem-sistem biasanya kurang terstruktur 

Kecenderungan perubahan yang terus menerus akan mengurangi stuktrur dari perangkat lunak. Evolusi perangkat lunak terlihat sulit dan mahal. 

• Ketrampilan khusus jarang dimiliki 

Tidak jelas batasan ketrampilan yang normal dalam rekayasa perangkat lunak yang mungkin dapat digunakan secara efektif dalam model pengembangan ini. Kebanyakan sistem yang dikembangkan melalui cara ini telah diimplementasikan oleh kelompok kecil yang memiliki ketrampilan yang tinggi dan motivasi yang kuat. 

Untuk memecahkan masalah-masalah tersebut, kadang-kadang tujuan dari pengembangan evolusioner adalah mengembangkan contoh sistem.Contoh ini digunakan untuk mengerti dan mevalidasikan spesifikasi sistem. Disinilah pengembangan evolusioner merupakan bagian dari beberapa proses yang lebih luas. ( seperti model waterfall ).

 Karena masalah-masalah tersebut, sistem dengan skala besar biasanya tidak dikembangkan melalui cara ini. Pengembangan evolusioner lebih tepat untuk 

Pengembangan sistem yang relatif kecil.

 Masalah-masalah mengenai perubahan sistem yang ada dihindari dengan meimplementasi ulang sistem keseluruhan kapanpun perubahan yang signifikan diperlukan.Jika pemodelan digunakan, tidak terlalu mahal. 

Pengembangan sistem yang memiliki masa hidup yang relatif singkat. 

Disini, sistem dikembangkan untuk mendukung beberapa aktivitas yang dibatasi oleh waktu.Contohnya, sebuah sistem yang mungkin dikembangkan secara khusus untuk peluncuran produk baru. 

Pengembangan sistem atau bagian-bagian dari sistem yang besar dimana tidak memungkinkan untuk menyatakan spesifikasi secara rinci. Contohnya, sistem AI dan interfaces pemakai. 

 Spiral Boehm 

Model proses nyata waterfall yang berorientasi dokumen telah diambil sebagai standar umum oleh banyak agen pemerintah dan pembuat perangkat lunak. Jadi, tidak mudah melupakan model tersebut walaupun masih terdapat masalah-masalah yang ditimbulkan dalam model tersebut. Kita membutuhkan sebuah proses yang lebih baik untuk manajemen yang dapat menggunakan semua model umum seperti yang telah kita bicarakan sebelumnya. Model perbaikan tersebut juga harus memenuhi kebutuhan-kebutuhan pembuat perangkat lunak.Pendekatan alternatif diusulkan oleh Boehm (1988). Boehm mengusulkan sebuah model yang secara eksplisit menjelaskan bahwa resiko yang disadari mungkin membentuk dasar model proses umum. 

 Model Boehm bebrbentuk spiral. Setiap loop mewakili sebuah tahap dari proses perangkat lunak. 

 Tidak ada tahap yang tetap dalam model ini.Manajemen harus memutuskan bagaimana membentuk proyek kedalam tahap-tahap.Perusahaan biasanya bekerja dengan beberapa model umum dengan tahap tambahan untuk proyek khusus atau ketika masala-masalah ditemukan selama pembuatan proyek.

 Setiap loop dibagi dalam 4 sektor 

 1. Pembuatan tujuan 

Tujuan, hambatan dalam proses ataupun produk serta resiko-resiko proyek 

ditentukan. Rencan rinci manajemen juga ditulis lengkap.Pembuatan strategi-strategi alternatif direncanakan sesuai dengan resiko yang ada. 

2. Perkiraan dan pengurangan resiko

 Untuk setiap resiko yang telah diidentifikasi, akan dibuat analisis rincinya. Kemudian diambil langkah-langkah untuk mengurangi resiko.contohnya, jika ada resiko bahwa persyaratan-persyaratan tidak tepat maka sebuah model contoh mungkin dapat dikembangkan. 

 3. Pengembangan dan validasi

 Setelah evaluasi resiko, sebuah model pengembangan untuk sistem dipilih. Misalnya, jika resiko interface pengguna yang dominan maka model pengembangan yang tepat mungkin pengembangan evolusioner dengan menggunakan model contoh (prototipe) Jika resiko keselamatan yang diutamakan, model pengembangan yang sesuai adalah transformasi formal dan seterusnya.Model waterfall mungkin tepat digunakan jika resiko yang diutamakan adalah integrasi sistem. 

4. Perencanaan 

Jika diputuskan untuk melanjutkan pada loop spiral berikutnya maka proyek dibicarakan kembali dan rencana dibuat untuk tahap selanjutnya. 

Tidak perlu untuk menggunakan satu model tunggal pada setiap loop spiral bahkan dalam keseluruhan sisten perangkat lunak. Model spiral encompasses model lainnya. Pemodelan digunakan pada salah satu psiral untuk memecahkan masalah kebutuhan.Kemudian dapat diikuti oleh model konvensional, waterfall. Transformasi formal digunakan untuk mengembangkan bagian-bagian sistem yang memiliki persyaratan keselamatan yang tinggi dan pendekatan reuse digunakan untuk pengimplementasian bagian-bagian lain dari sistem data manajemen. 

 Pada implementasinya, model spiral ini juga banyak digunakan, tetapi biasanya dikombinasikan dengan model yang lain. Pemodelan waterfall, yang sangat bagus dalam menentukan millestones dan pemodelan spiral, yang sangat bagus dengan menggunakan prototyping, merupakan kombinasi yang sering dipakai di dalam kontrak-kontrak untuk perangkat lunak dewasa ini. 

Manajemen Resiko

 Perbedaan yang mendasar antara model spiral dengan model lainnya adalah bahwa model spiral dengan eksplisit menyadari resiko-resiko yang ada.Resiko adalah konsep yang sulit didefinisikan secara tepat.Secara informal resiko adalah sesuatu yang sederhana yang dapat menyebabkan kesalahan.Contohnya, jika bertujuan menggunakan pemprograman bahasa baru (new programming language), resiko yang mungkin adalah alat pengumpul yang digunakan tidak reliabel dan tidak menghasilkan code objek yang efesien. 

Resiko adalah sebagai hasil ketidakcukupan informasi.Resiko tersebut dapat dipecahkan dengan pengenalan beberapa kegiatan yang dapat menutupi informasi yang kurang menyakinkan. Dalam contoh diatas, resiko mungkin dapat diatasi dengan survey pasar untuk menemukan alat pengumpul mana yang dapat digunakan dan bagaimana kebaikan alat tersebut. Jika sistem ternyata tidak sesuai maka keputusan untuk menggunakan bahasa baru harus diubah.

 Siklus spiral dimulai dengan penguraian tujuan-tujuan seperti performance, kegunaan, dan seterusnya. Cara alternatif dalam pencapaian tujuan dan hambatan dipergunakan dengan sebaik-baiknya kemudian diperhitungkan.Setiap alternatif diperhitungan bertentangan dengan tujuan.Ini biasanya menghasilkan identifikasi sumber resiko proyek.Langkah selanjutnya adalah mengevaluasi resiko-resiko ini dengan aktivitas seperti analisis yang lebih detail, pembuatan model/contoh, simulasi dan seterusnya.Untuk menggunakan model spiral, Boehm menyarankan sebuah bentuk umum yang dipenuhi dalam setiap daerah spiral. Bentuk ini mungkin dilengkapi pada sebuah level abtrak atau perkiraan rinci yang imbang dari pengembangan produk.