MODUL REKAYASA PERANGKAT LUNAK

(CMC 102)

MODUL PERTEMUAN 03
AKTIVITAS PROSES PEMBANGUNAN PERANGKAT LUNAK

DISUSUN OLEH
Dr. Fransiskus Adikara, S.Kom, MMSI

UNIVERSITAS ESA UNGGUL

2020

Universitas Esa Unggul

http://esaunggul.ac.id
0 / 16
 AKTIVITAS PROSES PEMBANGUNAN PERANGKAT LUNAK
TAHAP PERENCANAAN DAN PERANCANGAN

A. Kemampuan Akhir Yang Diharapkan

Setelah mempelajari modul ini, diharapkan mahasiswa mampu :

1. Memahami aktivitas dasar proses perangkat lunak untuk tahap
Perencanaan dan Perancangan;
2. Memahami hasil dari setiap aktivitas dasar proses perangkat lunak untuk
tahap Perencanaan dan Perancangan;
3. Menyusun aktivitas dasar untuk membangun perangkat lunak untuk
tahap Perencanaan dan Perancangan;

B. Uraian dan Contoh

Proses perangkat lunak nyata adalah urutan yang saling terkait teknis,
kolaboratif, dan kegiatan manajerial dengan tujuan keseluruhan untuk
menentukan, merancang, mengimplementasikan, dan menguji sistem
perangkat lunak. Pengembang perangkat lunak menggunakan berbagai
perangkat lunak yang berbeda alat dalam pekerjaan mereka. Alat sangat
berguna untuk mendukung pengeditan yang berbeda jenis dokumen dan
untuk mengelola volume besar informasi terperinci yang dihasilkan dalam
proyek perangkat lunak besar.
Empat proses dasar kegiatan spesifikasi, pengembangan, validasi, dan
evolusi diatur secara berbeda dalam berbagai proses pembangunan. Di air
terjun model, mereka disusun secara berurutan, sedangkan dalam
pengembangan tambahan mereka disisipkan. Bagaimana kegiatan ini
dilakukan tergantung pada jenis perangkat lunak, orang, dan struktur
organisasi yang terlibat. Dalam pemrograman ekstrim, misalnya, spesifikasi
tertulis di kartu. Tes dapat dieksekusi dan dikembangkan sebelum program
itu sendiri. Evolusi dapat melibatkan restrukturisasi atau refactoring sistem
yang substansial.

Universitas Esa Unggul

http://esaunggul.ac.id
1 / 16
1. Spesifikasi Perangkat Lunak
Spesifikasi perangkat lunak atau rekayasa persyaratan adalah proses
pemahaman dan mendefinisikan layanan apa yang diperlukan dari sistem
dan mengidentifikasi kendala pada operasi dan pengembangan sistem.
Rekayasa persyaratan adalah khususnya tahap kritis dari proses perangkat
lunak karena kesalahan pada tahap ini tidak bisa dihindarimenyebabkan
masalah kemudian dalam desain dan implementasi sistem.
Proses rekayasa persyaratan (Gambar 2.4) bertujuan untuk
menghasilkan yang disepakati dokumen persyaratan yang menentukan
sistem yang memenuhi persyaratan pemangku kepentingan. Persyaratan
biasanya disajikan pada dua tingkat detail. Pengguna akhir dan pelanggan
membutuhkan pernyataan persyaratan tingkat tinggi; pengembang sistem
membutuhkan lebih banyak spesifikasi sistem terperinci.
Ada empat kegiatan utama dalam proses rekayasa persyaratan:
1. Studi kelayakan Perkiraan dibuat dari apakah kebutuhan pengguna
yang diidentifikasi mungkin puas menggunakan perangkat lunak
dan teknologi perangkat keras saat ini. Studi ini
mempertimbangkan apakah sistem yang diusulkan akan hemat
biaya dari sudut pandang bisnis dan jika dapat dikembangkan
dalam batasan anggaran yang ada. Kelayakan belajar harus relatif
murah dan cepat. Hasilnya harus menginformasikan keputusan
apakah akan melanjutkan dengan analisis yang lebih rinci.
2. Persyaratan penjelasan dan analisis Ini adalah proses untuk
menurunkan sistem persyaratan melalui pengamatan sistem yang
ada, diskusi dengan potensi pengguna dan pengadaan, analisis
tugas, dan sebagainya. Ini mungkin melibatkan pengembangan dari
satu atau lebih model sistem dan prototipe. Ini membantu Anda
memahami sistem yang akan ditentukan.
3. Spesifikasi persyaratan Spesifikasi persyaratan adalah kegiatan
penerjemahan informasi yang dikumpulkan selama kegiatan
analisis menjadi dokumen yang mendefinisikan seperangkat

Universitas Esa Unggul

http://esaunggul.ac.id
2 / 16
 persyaratan. Dua jenis persyaratan dapat dimasukkan dalam ini
dokumen. Persyaratan pengguna adalah pernyataan abstrak dari
persyaratan sistem untuk pelanggan dan pengguna akhir sistem;
persyaratan sistem adalah deskripsi yang lebih rinci tentang fungsi
yang akan disediakan.
4. Validasi persyaratan. Kegiatan ini memeriksa persyaratan untuk
realisme, konsistensi, dan kelengkapan. Selama proses ini,
kesalahan dalam dokumen persyaratan pasti ditemukan. Kemudian
harus dimodifikasi untuk memperbaiki masalah ini.

Tentu saja, kegiatan dalam proses persyaratan tidak hanya dilakukan

dalam urutan yang ketat. Analisis persyaratan berlanjut selama definisi dan
spesifikasi dan persyaratan baru terungkap sepanjang proses. Karena itu,
kegiatan PT analisis, definisi, dan spesifikasi saling terkait. Dalam metode
tangkas, seperti ekstrim pemrograman, persyaratan dikembangkan secara
bertahap sesuai dengan prioritas pengguna dan elisitasi persyaratan berasal
dari pengguna yang merupakan bagian dari tim pengembangan.

2. Software design and implementation

Tahap implementasi pengembangan perangkat lunak adalah proses
konversi spesifikasi sistem menjadi sistem yang dapat dieksekusi. Itu selalu
melibatkan proses perangkat lunak desain dan pemrograman tetapi, jika

Universitas Esa Unggul

http://esaunggul.ac.id
3 / 16
 pendekatan tambahan untuk pengembangan adalah digunakan, mungkin
juga melibatkan penyempurnaan spesifikasi perangkat lunak.
Desain perangkat lunak adalah deskripsi struktur perangkat lunak yang
akan diimplementasikan, model data dan struktur yang digunakan oleh
sistem, antarmuka antara komponen sistem dan, terkadang, algoritma yang
digunakan. Desainer tidak sampai pada suatu selesai desain segera tetapi
kembangkan desain iteratif. Mereka menambahkan formalitas dan detail
sebagai mereka mengembangkan desain mereka dengan backtracking
konstan untuk memperbaiki desain sebelumnya.

Gambar 2.5 adalah model abstrak dari proses ini yang menunjukkan
input ke desain proses, proses kegiatan, dan dokumen yang dihasilkan
sebagai hasil dari proses ini. Diagram menunjukkan bahwa tahapan proses
desain berurutan. Faktanya, kegiatan proses desain saling terkait. Umpan
balik dari satu tahap ke tahap lainnya dan pengerjaan ulang desain
konsekuen tidak bisa dihindari dalam semua proses desain.
Sebagian besar antarmuka perangkat lunak dengan sistem perangkat
lunak lain. Ini termasuk operasi sistem, basis data, middleware, dan sistem
aplikasi lainnya. Ini membentuk perangkat lunak ‘platform ’, lingkungan di
mana perangkat lunak akan dieksekusi. Informasi tentang platform ini

Universitas Esa Unggul

http://esaunggul.ac.id
4 / 16
 merupakan input penting untuk proses desain, karena desainer harus
memutuskan caranya terbaik untuk mengintegrasikannya dengan
lingkungan perangkat lunak. Spesifikasi persyaratannya adalah deskripsi
fungsi yang harus disediakan oleh perangkat lunak dan kinerjanya dan
persyaratan ketergantungan. Jika sistem memproses data yang ada, maka
deskripsinya dari data tersebut dapat dimasukkan dalam spesifikasi
platform; jika tidak, deskripsi data harus menjadi input untuk proses desain
sehingga sistem data organisasi harus didefinisikan.
Aktivitas dalam proses desain bervariasi, tergantung pada jenis sistem
yang sedang digunakan dikembangkan. Sebagai contoh, sistem waktu nyata
memerlukan desain waktu tetapi mungkin tidak termasuk database sehingga
tidak ada desain database yang terlibat. Gambar 2.5 menunjukkan empat
kegiatan yang dapat menjadi bagian dari proses desain untuk sistem
informasi:
1. Desain arsitektur, di mana Anda mengidentifikasi keseluruhan
struktur sistem komponen utama (kadang-kadang disebut sub-
sistem atau modul), hubungannya, dan bagaimana mereka
didistribusikan.
2. Desain antarmuka, tempat Anda menentukan antarmuka antara
komponen sistem. Spesifikasi antarmuka ini harus jelas. Dengan
antarmuka yang tepat, komponen dapat digunakan tanpa komponen
lain harus tahu bagaimana itu diimplementasikan. Setelah
spesifikasi antarmuka disetujui, komponennya bisa dirancang dan
dikembangkan secara bersamaan.
3. Desain komponen, di mana Anda mengambil masing-masing
komponen sistem dan desain bagaimana itu akan beroperasi. Ini
mungkin pernyataan sederhana tentang fungsionalitas yang
diharapkan diimplementasikan, dengan desain khusus diserahkan
kepada programmer. Atau, mungkin saja menjadi daftar perubahan
yang harus dilakukan pada komponen yang dapat digunakan
kembali atau model desain terperinci. Model desain dapat
digunakan untuk secara otomatis menghasilkan implementasi.

Universitas Esa Unggul

http://esaunggul.ac.id
5 / 16
 4. Perancangan basis data, tempat Anda mendesain struktur data
sistem dan bagaimana semua ini untuk diwakili dalam database.
Sekali lagi, pekerjaan di sini tergantung pada apakah suatu
database yang ada akan digunakan kembali atau database baru akan
dibuat.
Kegiatan-kegiatan ini mengarah pada serangkaian output desain, yang
juga ditunjukkan pada Gambar 2.5. Detail dan representasi ini sangat
bervariasi. Untuk sistem kritis, detail dokumen desain yang menetapkan
deskripsi sistem yang tepat dan akurat diproduksi. Jika pendekatan berbasis
model digunakan, output ini sebagian besar mungkin berupa diagram. Di
mana metode pengembangan tangkas digunakan, output dari proses desain
mungkin tidak menjadi dokumen spesifikasi yang terpisah tetapi dapat
diwakili dalam kode program.
Metode terstruktur untuk desain dikembangkan pada 1970-an dan 1980-
an pendahulu untuk UML dan desain berorientasi objek (Budgen, 2003).
Mereka mengandalkan memproduksi model grafis sistem dan, dalam
banyak kasus, menghasilkan secara otomatiskode dari model ini. Model-
driven development (MDD) atau model-driven engineering (Schmidt, 2006),
di mana model perangkat lunak dibuat berbeda tingkat abstraksi, adalah
evolusi dari metode terstruktur. Di MDD, ada yang lebih besar penekanan
pada model arsitektur dengan pemisahan antara implementasi abstrak
independen model dan model implementasi spesifik. Model dikembangkan
dalam detail yang cukup sehingga sistem yang dapat dieksekusi dapat
dihasilkan dari mereka. Saya berdiskusi pendekatan pengembangan ini
dalam Bab 5.
Pengembangan program untuk mengimplementasikan sistem mengikuti
secara alami dari proses desain sistem. Meski beberapa kelas program,
seperti safety-critical sistem, biasanya dirancang secara rinci sebelum
implementasi dimulai, itu lebih umum untuk tahap selanjutnya dari desain
dan pengembangan program untuk disatukan. Alat pengembangan
perangkat lunak dapat digunakan untuk menghasilkan program kerangka
dari rancangan. Ini termasuk kode untuk mendefinisikan dan

Universitas Esa Unggul

http://esaunggul.ac.id
6 / 16
 mengimplementasikan antarmuka, dan, dalam banyak kasus,pengembang
hanya perlu menambahkan rincian pengoperasian setiap komponen program.
Pemrograman adalah kegiatan pribadi dan tidak ada proses umum yang
biasanya diikuti. Beberapa programmer mulai dengan komponen yang
mereka pahami, kembangkan ini, dan kemudian beralih ke komponen yang
kurang dipahami. Yang lain mengambil pendekatan yang berlawanan,
membiarkan komponen-komponen yang dikenal sampai akhir karena
mereka tahu bagaimana mengembangkannya mereka. Beberapa
pengembang suka mendefinisikan data di awal proses kemudian
menggunakannya untuk mengemudi pengembangan program; yang lain
meninggalkan data yang tidak ditentukan selama mungkin.
Biasanya, programmer melakukan beberapa pengujian terhadap kode
yang telah mereka kembangkan. Ini sering mengungkapkan cacat program
yang harus dihapus dari program. Ini disebut debugging. Pengujian dan
debugging yang cacat adalah proses yang berbeda. Pengujian menetapkan
adanya cacat. Debugging berkaitan dengan mencari dan memperbaiki cacat
ini.
Ketika Anda debugging, Anda harus membuat hipotesis tentang yang
dapat diamati perilaku program kemudian menguji hipotesis ini dengan
harapan menemukan kesalahan itu menyebabkan anomali output. Menguji
hipotesis mungkin melibatkan penelusuran program kode secara manual.
Mungkin memerlukan uji kasus baru untuk melokalisasi masalah. Interaktif
alat debugging, yang menunjukkan nilai menengah dari variabel program
dan jejak dari pernyataan yang dieksekusi, dapat digunakan untuk
mendukung proses debugging.

C. Latihan
1. Jelaskan apa itu perangkat lunak ?
2. Atribut penting apa yang harus dimiliki sebuah perangkat lunak ?

D. Kunci Jawaban

Universitas Esa Unggul

http://esaunggul.ac.id
7 / 16
 1. Perangkat lunak adalah sebuah kumpulan instruksi (program)
komputer yang dilengkapi oleh dokumentasi terkait program tersebut.

2. Atribut yang penting untuk dimiliki perangkat lunak adalah dapat

dipelihara, dapat diandalkan dan aman, efesien, dan diterima oleh
pengguna.

Universitas Esa Unggul

http://esaunggul.ac.id
8 / 16
 AKTIVITAS PROSES PEMBANGUNAN PERANGKAT LUNAK
TAHAP VALIDASI DAN EVOLUSI

A. Kemampuan Akhir Yang Diharapkan

Setelah mempelajari modul ini, diharapkan mahasiswa mampu :

1. Memahami aktivitas dasar proses perangkat lunak untuk tahap Validasi
dan Evolusi;
2. Memahami hasil dari setiap aktivitas dasar proses perangkat lunak untuk
tahap Validasi dan Evolusi;
3. Menyusun aktivitas dasar untuk membangun perangkat lunak untuk
tahap Validasi dan Evolusi;

B. Uraian dan Contoh

1. Validasi
Validasi perangkat lunak atau, lebih umum, verifikasi dan validasi
(V&V) adalah dimaksudkan untuk menunjukkan bahwa suatu sistem sesuai
dengan spesifikasinya dan memenuhi harapan pelanggan sistem. Pengujian
program, di mana sistem dijalankan menggunakan data uji simulasi, adalah
teknik validasi utama. Validasi mungkin juga melibatkan proses
pemeriksaan, seperti inspeksi dan ulasan, pada setiap tahap proses perangkat
lunak mulai dari definisi kebutuhan pengguna hingga pengembangan
program. Karena dominasi pengujian, sebagian besar biaya validasi
dikeluarkan selama dan setelah implementasi.

Kecuali untuk program kecil, sistem tidak boleh diuji sebagai

monolitik tunggal satuan. Gambar 2.6 menunjukkan proses pengujian tiga

Universitas Esa Unggul

http://esaunggul.ac.id
9 / 16
 tahap di mana komponen sistem berada diuji kemudian sistem terintegrasi
diuji dan, akhirnya, sistem diuji dengan data pelanggan. Idealnya, kerusakan
komponen ditemukan pada awal proses, dan masalah antarmuka ditemukan
ketika sistem terintegrasi. Namun, seperti halnya cacat ditemukan, program
harus di-debug dan ini mungkin memerlukan tahapan lain dalam proses
pengujian harus diulang. Kesalahan dalam komponen program, misalnya,
mungkin terungkap selama pengujian sistem. Karena itu proses ini
merupakan proses berulang dengan informasi diumpan balik dari tahap
selanjutnya ke bagian awal proses.
Tahapan dalam proses pengujian adalah:
1. Pengujian pengembangan Komponen yang membentuk sistem diuji
oleh orang mengembangkan sistem. Setiap komponen diuji secara
independen, tanpa komponen sistem lainnya. Komponen dapat berupa
entitas sederhana seperti fungsi kelas pengujian atau objek, atau mungkin
pengelompokan yang koheren dari entitas ini. Otomatisasi uji alat, seperti
JUnit (Massol dan Husted, 2003), yang dapat menjalankan kembali
komponen tes ketika versi baru dari komponen dibuat, biasanya digunakan.
2. Pengujian sistem Komponen sistem terintegrasi untuk membuat
sistem yang lengkap. Proses ini berkaitan dengan menemukan kesalahan
yang dihasilkan dari tidak terduga interaksi antara komponen dan masalah
antarmuka komponen. Itu juga berkaitan dengan menunjukkan bahwa sistem
memenuhi fungsional dan non-fungsional persyaratan, dan pengujian
properti sistem yang muncul. Untuk sistem besar, ini mungkin proses multi-
tahap di mana komponen terintegrasi untuk membentuk subsistem yang diuji
secara individual sebelum sub-sistem ini sendiri terintegrasi untuk
membentuk sistem akhir.
3. Pengujian penerimaan. Ini adalah tahap terakhir dalam proses
pengujian sebelum sistem diterima untuk penggunaan operasional. Sistem
diuji dengan data yang disediakan oleh pelanggan sistem daripada dengan
data uji simulasi. Pengujian penerimaan mungkin mengungkapkan
kesalahan dan kelalaian dalam definisi persyaratan sistem, karena data nyata
menjalankan sistem dengan cara yang berbeda dari data uji. Penerimaan

Universitas Esa Unggul

http://esaunggul.ac.id
10 / 16
 pengujian juga dapat mengungkapkan masalah persyaratan di mana fasilitas
sistem lakukan tidak benar-benar memenuhi kebutuhan pengguna atau
kinerja sistem tidak dapat diterima.
Biasanya, pengembangan komponen dan proses pengujian saling
terkait. Pemrogram membuat data pengujian mereka sendiri dan secara
bertahap menguji kodenya dikembangkan. Ini adalah pendekatan yang
masuk akal secara ekonomi, seperti yang diketahui oleh programmer
komponen dan karena itu merupakan orang terbaik untuk menghasilkan
kasus uji.
Jika pendekatan inkremental untuk pembangunan digunakan, setiap
kenaikan harus dilakukan diuji saat dikembangkan, dengan tes ini
berdasarkan pada persyaratan untuk kenaikan itu. Dalam pemrograman
ekstrim, tes dikembangkan bersama dengan persyaratan sebelum
pengembangan dimulai. Ini membantu penguji dan pengembang untuk
memahami persyaratan dan memastikan bahwa tidak ada penundaan karena
kasus uji dibuat.

Saat proses perangkat lunak yang digerakkan oleh rencana digunakan

(mis., Untuk pengembangan sistem kritis), pengujian didorong oleh
serangkaian rencana pengujian. Tim penguji independen bekerja dari
rencana uji pra-formulasi ini, yang telah dikembangkan dari sistem
spesifikasi dan desain. Gambar 2.7 mengilustrasikan bagaimana rencana
pengujian merupakan penghubung kegiatan pengujian dan pengembangan.
Ini kadang-kadang disebut V-model pembangunan (putar di sisinya untuk
melihat V).

Universitas Esa Unggul

http://esaunggul.ac.id
11 / 16
 Tes penerimaan kadang-kadang disebut 'pengujian alfa'. Sistem kustom
dikembangkan untuk satu klien. Proses pengujian alfa berlanjut hingga
sistem pengembang dan klien setuju bahwa sistem yang dikirimkan adalah
implementasi yang dapat diterima dari persyaratan.
Ketika suatu sistem akan dipasarkan sebagai produk perangkat lunak,
proses pengujian disebut 'Pengujian beta' sering digunakan. Pengujian beta
melibatkan pengiriman sistem ke sejumlah pelanggan potensial yang setuju
untuk menggunakan sistem itu. Mereka melaporkan masalah ke sistem
pengembang. Ini membuat produk benar-benar digunakan dan mendeteksi
kesalahan yang mungkin tidak telah diantisipasi oleh pembangun sistem.
Setelah umpan balik ini, sistem diubah dan dirilis baik untuk pengujian beta
lebih lanjut atau untuk penjualan umum.

2. Evolusi Perangkat Lunak

Fleksibilitas sistem perangkat lunak adalah salah satu alasan utama
mengapa semakin banyak perangkat lunak dimasukkan dalam sistem yang
besar dan kompleks. Setelah keputusan diambil dibuat untuk memproduksi
perangkat keras, sangat mahal untuk melakukan perubahan pada perangkat
keras rancangan. Namun, perubahan dapat dilakukan ke perangkat lunak
kapan saja selama atau setelah pengembangan sistem. Bahkan perubahan
ekstensif masih jauh lebih murah daripada yang sesuai perubahan pada
perangkat keras sistem.

Secara historis, selalu ada pemisahan antara proses pengembangan

perangkat lunak dan proses evolusi perangkat lunak (pemeliharaan
perangkat lunak). Orang-orang berpikir pengembangan perangkat lunak
sebagai aktivitas kreatif di mana sistem perangkat lunak dikembangkan dari

Universitas Esa Unggul

http://esaunggul.ac.id
12 / 16
 konsep awal hingga sistem kerja. Namun, mereka terkadang anggap
pemeliharaan perangkat lunak membosankan dan tidak menarik. Meski
biaya perawatannya sering beberapa kali lipat biaya pengembangan awal,
proses pemeliharaan kadang-kadang dianggap kurang menantang daripada
pengembangan perangkat lunak asli.
Perbedaan antara pengembangan dan pemeliharaan ini semakin tidak
relevan. Hampir tidak ada sistem perangkat lunak yang benar-benar sistem
baru dan itu menghasilkan lebih banyak akal untuk melihat pengembangan
dan pemeliharaan sebagai sebuah kontinum. Daripada dua terpisah proses,
lebih realistis untuk menganggap rekayasa perangkat lunak sebagai evolusi
proses (Gambar 2.8) di mana perangkat lunak terus berubah sepanjang
hidupnya di menanggapi perubahan kebutuhan dan kebutuhan pelanggan.

C. Latihan

1. Mengapa rekayasa perangkat lunak perlu untuk dipahami dan

dipelajari?
2. Jelaskan hal-hal yang perlu diperhatikan ketika mengembangkan
sebuah perangkat lunak?

D. Kunci Jawaban

1. Rekayasa perangkat lunak merupakan metode, teknik dan alat untuk

mengembangkan perangkat lunak yang berkualitas sesuai dengan
kebutuhan penggunanya serta dapat digunakan sesuai biaya dan waktu
yang telah direncanakan.
2. Hal yang perlu diperhatikan adalah:
i. Perangkat lunak harus dikembangkan menggunakan
pengembangan yang terkelola dan dipahami prosesnya.
ii. Keandalan dan kinerja sangat penting untuk semua jenis sistem.

Universitas Esa Unggul

http://esaunggul.ac.id
13 / 16
 iii. Memahami dan mengelola spesifikasi dan kebutuhan perangkat
lunak (apa perangkat lunak harus dilakukan) merupakan hal yang
penting.
iv. Anda harus menggunakan seefektif mungkin sumber daya yang
ada.

E. Daftar Pustaka

1. Arlow, J. and Neustadt, I. (2005). UML 2 and the Unified Process:

Practical Object-Oriented Analysis and Design (2nd Edition). Boston:
Addison-Wesley.
2. Boehm, B. and Turner, R. (2003). Balancing Agility and Discipline: A
Guide for the Perplexed. Boston: Addison-Wesley.
3. Boehm, B. W. (1988). ‘A Spiral Model of Software Development and
Enhancement’. IEEE Computer, 21 (5), 61–72.
4. Budgen, D. (2003). Software Design (2nd Edition). Harlow, UK.:
Addison-Wesley.
5. Krutchen, P. (2003). The Rational Unified Process—An Introduction
(3rd Edition). Reading, MA: Addison-Wesley.
6. Massol, V. and Husted, T. (2003). JUnit in Action. Greenwich, Conn.:
Manning Publications Co.
7. Rettig, M. (1994). ‘Practical Programmer: Prototyping for Tiny
Fingers’. Comm. ACM, 37 (4), 21–7.
8. Royce, W. W. (1970). ‘Managing the Development of Large Software
Systems: Concepts and Techniques’. IEEE WESTCON, Los Angeles
CA: 1–9.
9. Rumbaugh, J., Jacobson, I. and Booch, G. (1999). The Unified Software
Development Process. Reading, Mass.: Addison-Wesley.
10. Schmidt, D. C. (2006). ‘Model-Driven Engineering’. IEEE Computer,
39 (2), 25–31.
11. Schneider, S. (2001). The B Method. Houndmills, UK: Palgrave
Macmillan.

Universitas Esa Unggul

http://esaunggul.ac.id
14 / 16
 12. Wordsworth, J. (1996). Software Engineering with B. Wokingham:
Addison-Wesley.

Universitas Esa Unggul

http://esaunggul.ac.id
15 / 16