DESAIN PROSEDURAL REKAYASA PERANGKAT LUNAK

Februari 20, 2008

 

PENDAHULUAN

Desain prosedural terjadi setelah data, desain arsitektur, dan interface, dibangun.Dalam dunia yang ideal, spesifikasi prosedural diperlukan untuk menetapkan detail algoritma yang akan dinyatakan dalam suatu bahasa ibu seperti bahasa inggris. Akan tetapi, semua anggota organisasi pengembangan perangkat lunak menggunakan bahasa ibu (paling tidak secara teori), orang di luar domain perangkat lunak dapat lebih memahami spesifikasi tersebut dan tidak ada pelajaran baru yang di perlukan.

Sayangnya ada satu masalah kecil, desain prosedural harus menentukan detail desain prosedural tanpa ada ambiguitas, dan tidak ada ambiguitas. Di dalam bahasa ibu bukan merupakan hal hal wajar. Dengan menggunakan suatu bahasa ibu, kita dapat menuliskan serangkaian langkah prosedural dalam begitu banyak cara yang berbeda. Kita kerap kali bersandar pada konteks untuk mendapatkan fakta penting. Kita sering menulis seolah-olah ada dialog dengan pembaca (sebenarnya tidak). Karena alasan tersebut dan hal lainnya, harus digunakan mode yang lebih terbatas untuk mempresentasikan detail prosedural

PEMROGRAMAN TERSTUKTUR REKAYAS PERANGKAT LUNAK

Definisi – definisi mendasar dari pemrograman yang terstruktur adalah sebagai berikut :

  • Teori pemrograman terstruktur memperlakukan pengkorversian diagram alir besar dan kompleks ke dalam bentuk standar sedemikian rupa sehingga mereka dapat dipresentasikan dengan iterasi dan nesting (pengumpulan) sejumlah kecil struktur logika kontrol dasar dan standar (H.D. Mills, Chief Programmer Teams:Principle and Procedures).
  • Pemrograman terstruktur adalah cara pengorganisasian dan pengkodean program-program yang kompleks dan membuat program tersebut lebih mudah dipahami dan dimodifikasi (J.R.Donaldson,Struktured programming
  • Konsep dasar [dari pemrograman terstuktur] adalah suatu pembuktian kebenaran, (R.A.Karp)
  • Pemrograman terstuktur bukanlah obat mujarab-ia benar-benar terdiri dari suatu atribut yang biasanya tidak inherent (menjadi sifat) dalam pemrograman atau sebarang jenis yang lain (D.Butterworrth)

Prof E.W Dykstra pada tahun 1960 dalam papernya mengusulkan bahwa pernyataan Go To,seharusnya tidak dipergunakan didalam program terstuktur. Oleh karena itu sering disebut pemrograman terstruktur sebagai pemrograman tanpa GOTO (GOTO less programming).

Definisi yang lain oleh H.D. Mills adalah pemrograman terstuktur tidak harus dicirikan secara panjang lebar dengan absennya go to,melainkan timbulnya terstruktur.

Sedangkan definisi yang lebih akurat lagi dinyatakan oleh N. Wirth bahwa pemrograman terstuktur adalah formulasi program secara hierarkis,struktur berkelompok dari pernyataan-pernyataan dan objek-objek komputasi. Pernyataan Wirth sendiri bukanlah mendefininisikan perangkat atau konstruksi kontrol logika yang dapat digunakan, atau tidak membatasi teknik formulasi terstuktur yang tersedia untuk desain program.

Prinsip utama dari pemrograman yang terstuktur adalah bahwa jika urutan suatu proses telah sampai pada suatu baris sintaks tertentu, maka proses selanjutnya tidak boleh melompat mundur kebaris sebelumnya, kecuali untuk proses dengan struktur kontrol repetition/looping. Modifikasi akan sulit dilakukan terhadap suatu program, jika kode programnnya yang dibuat tidak terstruktur dengan baik. Biasanya para pemrogram (programmer) akan merasa sangat perlu untuk memahami metodologi perancangan program yang terstruktur, jika mereka sedang membuat program yang besar dan komplek.

Pemrograman terstruktur dipandang oleh banyak pemrogram sebagai sinonim untuk pemrogramman modular atau top-down. Sebenarnya pemrograman modular adalah suatu sub kelas dari metodologi perancangan dalam suatu kelas umum dari metodologi penyederhanaan persoalan yang diketahui sebagai pemrograman terstruktur.

Pemrograman terstuktur dapat divisualisasikan sebagai aplikasi dan metode penyederhananaan persoalan dasar untuk menyusun terstruktur persoalan hierarki yang bisa dikelola.Untuk memperolah suatu pengetahuan yang lebih besar dari perbedaan antara sub kelas berbagai metodologi yang terkandung dalam pemrograman terstruktur, pertama kita harus memandang tujuan dari proses kemurnian. Kita diberikan suatu persoalan, biasanya kita menspesifikasi kedalam bahasa kita, dan mensyaratkan untuk menunjukan suatu penyelesaian persoalan tersebut ke dalam suatu bahasa pemrograman tingkat tinggi.

Bila persoalan tidak lebih dari”menghitung jumlah dari A dan B”, persoalan ini akan langsung diterjemahkan kedalam RESULT = A+B. Jika persoalan besar atau rumit, maka sistem yang didefinisikan untuk menyelesaikan persoalan tersebut haruslah disederhanakan menjadi sub sistem dimana setelah sejumlah penyederhanaan, secara hierarkis menjadi modul-modul. Setelah penyederhanaan tambahan, hasilnya merupakan suatu program yang terstruktur. Masing-masing sub kelas metodologi dapat digambarkan dengan:

  • Jangkauan proses keaslian yang padanya metodologi menjadi efektif.
  • Pendekatannya ke proses keaslian.
  • Aplikasi yang berguna
CIRI-CIRI PROGRAM TERSTUKTUR
Program yang baik/terstuktur mempunyai ciri-ciri sebagai berikut :
  • Dapat dijalankan dengan baik dan benar (sesuai dengan keinginan pemrogram).
  • Dapat dijalankan secara efisien dan efektif dengan tidak banyak menggunakan sintaks yang tidak perlu (menghasilkan output yamg tepat dan benar dalam waktu yang singkat).
  • Mudah dibaca dan dipahami oleh orang lain maksud dan tujuan objek yang akan ditampilkan (memiliki logika perhitungan yang tepat dalam memecahkan masalah, dan ditulis dalam bahasa yang standar yaitu bahasa Indonesia/Inggris terstuktur,sehingga tidak menimbulkan arti ganda).
  • Mudah diperbaiki, jika terjadi kesalahan (semua operasi yang dilakukan harus terdefinisi dengan jelas dan berakhir setelah sejumlah langkah dilakukan).
  • Biaya pengujian yang dibutuhkan rendah
  • Memiliki dokumentasi yang baik
  • Biaya perawatan dan dokumentasi yang dibuthkan rendah
  • Program hanya terdiri dari tiga struktur kontrol, yaitu stuktur urut,stuktur seleksi, dan struktur repetisi/iterasi

LANGKAH-LANGKAH PENGEMBANGAN PROGRAM

Suatu program yang baik membutuhkan suatu standar, sehingga akan memudahkan pemrogram untuk merancang, dan merawat program. Sehingga perlu dipahami beberapa langkah yang harus dilakukan dalam merancang suatu program yang terstruktur. Langkah –langkah tersebut adalah sebagai berikut:

1.  Definisikan Masalah

Pemahaman permasalahan merupakan suatu hal yang sangat penting bagi sipemrogram. Sipemrogram perlu memahami permasalahan yang dihadapi dan yang akan diselesaikan oleh pemesan program, agar hasil pendefinisian masalah tidak menyimpang dari masalah yang sedang dihadapi.

Setelah menyamakan persepsi tentang suatu masalah yang dihadapi dan akan diselesaikan, maka pemrogram dapat mengidentifikasi permasalahan tersebut secara rinci, dan menentukan ruang lingkup permasalahan yang akan diselesaikan terlebih dahulu, dan kemungkinan kendala-kendala yang akan dihadapi, lalu berapa lama proses penyelesaian masalah tersebut. Pemrograman harus membuat langkah-langkah penyelesaian masalah berdasarkan ruang lingkup permasalahan yang ditentukan, sehingga pekerjaan pembuatan program terarah dan terjadwal dengan baik.

Masalah yang perlu didefinisikan adalah komponen input dari suatu program yang akan dirancang tersebut apa saja yang akan terjadi didalam menyelesaikan program tersebut dan menampilkan hasilnya, yang terakhir adalah komponen output yang diinginkan seperti apa, dan formatnya bagaimana.

2.  Merancang Outline Pemecahan Masalah

Dalam merancang outline pemecahan masalah pemrogram perlu membuat rincian proses secara rinci (meliputi proses apa saja yang terjadi pada menu utama, lalu masing-masing sub menu dalam menu utama tesebut akan mengerjakan berapa proses,setiap proses yang terjadi berinteraksi dengan file apa saja, dan berapa file yang terlibat dalam proses tersebut).

Setelah rincian proses dan file yang berinteraksi diketahui, pemrogram menentukan berapa bentuk stuktur kontrol yang terlibat dalam satu proses,dan jenis stukturnya apa saja dan berapa banyak, misalkan baris 1-10 menggunakan struktur urut atau seleksi, dan baris 11-20 menggunakan struktur repetisi repeat-until atau for-do, dst.

Judul dari setiap proses (modul) apa saja, dan deklarasikan seluruh variable yang akan digunakan dalam setiap proses (modul), baik variable lokal maupun variable global. Setelah itu tentukan deskripsi dari proses (modul) tersebut. Setelah outline selesai, maka transformasikan outline tersebut kedalam algoritma, dengan menggunakan pseudecode yang dapat ditulis dengan struktur Indonesia (bahasa Indonesia terstuktur) atau struktur Inggris (bahasa Inggris tersrtuktur).

Desain algoritma yang dibuat haruslah sama dengan langkah-langkah penyelesaian masalah yang ditentukan, karena algoritma dibuat untuk menyelesaikan masalah yang dihadapi oleh pemrogram.

Algoritma yang telah dibuat tersebut perlu dilakukan pengujian agar output yang dihasilkan nantinya dapat sesuai dengan keinginan sipemrogram. Disamping pengujian juga perlu dibuat format input / output yang jelas, serta komentar untuk setiap baris yang dapat membantu pemrogram dalam mengingat tujuan dari perintah tersebut.Pengujian algoritma tersebut dapat dilakukan dengan menggunakan diagram overview dan diagram rinci HIPO (HIRARKI Plus Input dan Output).

3.  Pengkodean Program

Algoritma yang telah selesai dilakukan pengujian,dapat langsung ditransformasikan kedalam salah satu bahasa pemrograman yang diinginkan atau yang dikuasai oleh sipemrogram. Bahasa pemrograman yang baik harusalah dapat dipakai pada berbagai jenis komputer yang berbeda-beda dan berbaai jenis sistem informasi, hal ini dikenal dengan portabilitas. Pemrogram juga haruslah menentukan batas waktu minimum dalam penulisan suatu modul program, dari awal hingga siap dioperasikan.

Tujuan pengkodean adalah terjadinya efisiensi terhadap memori yang akan digunakan, efisiensi perintah dalam setiap modul program,serta efisiesi terhadap penggunaan fasilitas input dan output yang akan berpengaruh langsung terhadap porseor ataupun terhadap pengguna.

4.  Eksekusi Program

Pekerjaan komputer (prosesor) pada dasarnya hanya dua yaitu fetch (membaca instruksi/ program dari memori), lalu execute (mengeksekusi instruksi/program tesebut) dan menampilkan hasilnya ke media output seperti printer, monitor dll.Untuk memperoleh eksekusi program dengan kecepatan maksimum, maka perlu diperhatikan beberapa faktor, seperti jenis bahasa pemrograman yang dipilih apakah sanggup mengangkat data yang akan diproses, dan spesifikasi perangkat keras yang digunakan.

5. Dokumentasi Dan Pemeliharaan Program

Penulisan program yang kompleks harus selalu didokumentasikan setiap kurun waktu tertentu, jadwal dokumentasi juga perlu dibuat demi menjaga keamanan terhadap program dan data dari orang-orang yang tidak bertanggung jawab.

Pemeliharaan program berfungsi untuk menjabarkan aktivitas dari hasil analisis terhadap sistem dan dilakukan setelah program diimplementasikan dan telah digunakan beberapa saat oleh pemakai. Pemeliharaan mencangkup:

  1. Format tampilan yang disesuaikan dengan keinginan pengguna
  2. Fungsi-fungsi yang tidak sesuai dengan keinginan pengguna
  3. Adaptasi dengan spesifikasi prosesor yang baru dan ssistem operasi yang baru.
  4. Dan lain-lain.

KOMPONEN PEMROGRAMAN TERSTUKTUR

Pemrograman terstuktur memiliki tiga komponen utama yaitu :.

1.  Pemrograman Top-Down

Teknik Top-Down didefinisikan sebagai suatu masalah yang kompleks dibagi-bagi kedalam beberapa kelompok masalah yang lebih kecil. Dari kelompok masalah yang kecil tersebut dianalisis. Apabila dimungkinkan, maka masalah tersebut akan dipilah-pilah lagi menjadi sub bagian yang lebih kecil, dan setelah itu mulai disusun langkah-langkah untuk menyelesaikan secara detail.

Bila ada masalah yang kompleks, maka pemecahan masalah dilakukan dengan menggabungkan prosedur-prosedur yang ada menjadi satu kesatuan program guna menyelesaikan masalah tersebut, teknik ini dikenal dengan Teknik Bottom-Up yang sudah mulai ditinggalkan pemrogram karena kurang efektif.

2.  Pemrograman Modular

Pada teknik top-down masalah yang besar dan kompleks dibagi-bagi kedalam kelompok masalah yang lebih kecil. Kelompok masalah yamg lebih kecil tersebut dinamakan modul. Satu modul akan mewakili satu rincian proses detail yang sudah mewakili media penyimpanan dan struktur data yang jelas.

Teknik pemrograman terstruktur yang digunakan untuk mengimplemetasikan langkah-langkah pemecahan masalah pada kelompok masalah yang kecil tersebut dinamakan teknik pemrograman modular.

Modul program didefinisikan sebagai sekumpulan instruksi yang memiliki operasi-operasi dan data yang didefinisikan; memiliki stuktur internal yang tidak tergantung pada subprogram yang lain, dan merupakan satu kesatuan yang utuh yang akan dieksekusi secara berulang-ulang.

3.  Teorema Struktur / Struktur Kontrol

Perancangan program terstruktur tidak dipengaruhi oleh kelebihan dan keunggulan salah satu bahasa pemrograman yang sedang populer pada saat itu, namun lebih dipengaruhi oleh tiga teorema struktur / struktur kontrol yang akan digunakan. Karena pada dasarnya algoritma dari program yang telah terstuktur akan dapat ditransformasikan kedalam bahasa pemrograman dan jenis sistem informasi apa saja. Terdapat tiga teorema struktur yaitu:

  1. Struktur Urut
  2. Struktur Seleksi
  3. Struktur Repetisi/pengulangan.

DAFTAR BACAAN

Al-Bahra bin Ladjamuddin. B, Pemrograman Terstruktur, Perguruan Tinggi Raharja, 2004

Al-Bahra bin Ladjamuddin. B, Analisis dan Desain Sistem Informasi, Perguruan Tinggi Raharja, 2005

Al-Bahra bin Ladjamuddin. B, Rekayasa Perangkat Lunak, Perguruan Tinggi Raharja, 2006

Roger S. Pressman., Software Engineering, A Beginner’s Guide, Mc. Graw Hill, 1998.

Usaha untuk mengatasi permasalahan rekayasa perangkat lunak

Februari 18, 2008

Masalah perangkat lunak (software engineering) biasanya dipilih berdasarkan 3 aspek antara lain sifat dari proyek dan aplikasi, metode dan alat bantu yang digunakan serta kontrol dan output yang dibutuhkan. Perekayasaan perangkat lunak berupa penggunaan metode pengembangan perangkat lunak berkualitas tinggi secara ekonomi dan handal. Dari usaha-usaha tersebut dihasilkan alternatif paradigma, alternatif metodologi dan perangkat bantu komputer.

1. Siklus Hidup

Pengesetan dan piranti teknik serta metode yang digunakan oleh para ahli software dalam proyek disebut Metodologi Proyek. Metodologi proyek diterapkan dalam konteks tahap-tahap pengembangan software (software live cycle) , yang disebut fase, yang merupakan tahapan yang harus dilalui oleh produk software dari konsep awal sampai tahap akhir. Model tahap-tahap tersebt merupakan enyajian dari tahap-tahap pengembangan software yang juga dapat berisikan alur informasi, saat penentuan keputusan, dan sebagainya.

Langkah-langkah dari model tahapan penyusunan dapat merupakan fase temoporal yang membentuk urutan dalam waktu atau fase logis yang menunjukkan tahap-tahap bukan membentuk urutan temporal. Sebagai contoh implementasi secara logis akan mendahului pengujian, namun bagian fase implementasi dan pengujian dapat terjadi secara serempak. Jadi moedl tahapan yang menggunakan fase logis dapat memiliki fase implementasi sebelum fase pengujian, sedangkan model yang menggunakan fase temporal mungkin fase-fase ini kan bertumpang tindih.

2. Model Spiral

Permodelan dalam suatu perangkat lunak merupakan suatu hal yang dilakukan di tahapan awal. Di dalam suatu rekayasa dalam perangkat lunak sebenarnya maih memungkinkan tanpa melakukan suatu permodelan. Hal ini tidak dapat lagi dilakukan dalam suatu industri perangkat lunak. Permodelan dalam perangkat lunak merupakan suatu yang harus ikerjakan di bagian awal dari rekayasa, dan permodelan ini akan mempengaruhi pekerjaan-pekerjaan dalam rekayasa perangkat lunak tersebut. dalam prakteknya, setiap langkah sering tumpang tindih dan sering memberi informasi satu ama lain.

Proses perangkat lunak tidak linier dan sederhana tapi mengandung urutan iterasi dari aktivitas pengembangan. Selama langkah terakhir, perangkat lunak telah digunakan. Kesalahan dan kelalaian dalam menentukan kebutuhan perangkat lunak original dapat diatasi.

Namun sayang, model yang banyak mengandung iterasi sehingga membuat kesulitan bagi pihak manajemen untuk memeriksa seluruh rencana dan laporan. Maka dari itu, seteleh sedikit iterasi, biasanya bagian yang telah dikembangkan akan dihentikan dan dilanjutkan dengan keinginan user. Mungkin juga sistem terstruktur secara jelek yang sebenarnya merupakan masalah desain akan dibiarkan karena terkalahkan oleh trik implementasi.

3. Pendekatan Waterfall

Model waterfall menawarkan cara pembuatan perangkat lunak secara lebih nyata. Langkah-langkah yang penting dalam model ini adalah :

  • Penentuan dan analisis spesifikasi
  • Desain sistem dan perangkat lunak
  • Implementasi dan ujicoba unit
  • Integrasi dan uji coba sistem
  • Operasi dan pemeliharaan

Masalah pendekatan waterfall adalah ketidakluwesan pembagian project ke dalam langkah yang nyata atau jelas. Sistem yang disampaikan kadang-kadang tidak dapat digunakan sesuai keinginan customer. Namun demikian model waterfall mencerminkan kepraktisan engineering. Konsekwensinya, model proses perangkat lunak yang bredasarkan pada pendekatan ini digunakan dalam pengembangan sistem perangkat lunak dan hardware yang luas.
4. Pendekatan Evolusioner

Pendekatan evolusioner ini berdasarkan pada ide pengembangan dan implementasi awal yang akan menghasilkan komentar pemakai sehingga dapat dilakukan perbaikan melalui banyak versi sampai sistem yang mencukupi dapat dikembangkan. Selain memiliki kegiatan-kegiatan terpisah model ini memberikan umpan balik dengan cepat dan serempak. Ada 2 tipe pada model ini yaitu :

a. Pemrogramaman evolusioner

    Tujuan proses adalah bekerja sama dengan cusomer untuk menghasilakan kebutuhan-kebutuhan dan menyampaikan sistem akhir kepada pemakai/ customer. Pengembangan dimulai dengan bagian-bagian sistem yang dimengerti. Sistem dikembangkan melalui penambahan features sesuai yang diusulkan oleh customer. 2.

    b. Pemodelan

    Pemrograman evolusioner penting saat sulit untuk membuat spesifikasi sistem secara rinci. Beberapa orang mungkin setuju bahwa semua sistem masuk dalam tipe ini. Namun, pemrograman evolusioner banayk digunakan dalam pengembangan sistem pakar (artifacial intelegence) yang berusaha untuk menyamai kemampuan manusia.

    Kita tidak mungkin membuat spesifikasi yang rinci untuk perangkat lunak yang menyamai manusia karena kita tidak mengerti bagaimana biasanya manusia menjalankan tugas-tugasnya. Pendekatan evolusioner biasanya lebih efektif daripada pendekatan waterfall untuk hal pengembangan perangkat lunak yang harus dengan segera dapat memenuhi kebutuhan customer. Namun, daris egi teknik dan manajemen, model ini mempunyai masalah mendasar yaitu :

    • proses tidak visibel
    • sistem biasanya kurang terstruktur
    • ketrampilan khusus jarang dimiliki

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

      Oleh karena masalah-masalah tersebut, sistem dengan skala besar biasanya tidak dikembangkan melalui cara ini. Pengembangan evolusioner lebih tepat untuk pengembangan yang relatif kecil. Masalah-masalah mengenai perubahan sistem yang ada dihindari dengan mengimplementasikan ulang sistem keseluruhan kapanpun perubahan yang signifikan diperlukan. Jika permodelan digunakan, tidak terlalu mahal. Pengembangan sistem yang memiliki masa hidup yang relatif singkat.

      5. Spiral Boehm

      Boehm (1988) mengusulkan sebuah model yang secara eksplisit menjelaskan bahwa resiko yang disadari mungkin membentuk dasar model umum. Model yang diusulkan oleh Boehm ini berbentuk spiral. Tak ada tahap yang ditetapkan dalam model ini. Manajemen harus memutuskan bagaimana membentuk proyek ke dalam tahap-tahap. Perusahaan biasanya bekerja dengan beberapa model umum dengan tambahan untuk proyek khusus atau ketika masalah-masalah ditemukan selama pembuatan proyek. Setiap loop dibagi dalam 4 sektor yaitu :

      • Pembuatan tujuan

      Tujuan, hambatan dalam proses ataupun produk serta resiko-resiko proyek yang ditentukan. Rencana rinci manajemen juga ditulis lengkap. Pembuatan strategi-strategi alternatif direncanakan sesuai dengan resiko yang ada.

      • 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 persayaratan-persyaratan tidak tepat maka sebuah model mungkin dapat dikembangkan.

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

      Jika diputuskan untuk melanjutkan pada loop spiral berikutnya, maka prosyek yang dibicarakan kembalai dan rencana perlu dibuat untuk tahap selanjutnya. Tidak perlu untuk menggunakan satu model tunggal pada setiap loop spiral bahkan dalam keseluruhan sistem perangkat lunak. Model spiral encompasses model lainnya. Pemodelan digunakan pada salah satu spiraluntuk memecahkan masalah kebutuhan.

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

      DAFTAR BACAAN

      Adri Kristianto, Rekayasa Perangkat Lunak (Konsep Dasar), Gava Media Yogyakarta, 2004

      Al Bahra bin Ladjamuddin, Rekayasa Perangkat Lunak, Graha Ilmu, Yogyakarta, 2004

      Barbee Teasley Mynatt, Software Engineering with Student Project Guidance, Prentice Hall Int. 1990.