REKAYASA SISTEM BERBASIS KOMPUTER

PENGERTIAN REKAYASA SISTEM

PROPERTI SISTEM BARU
SISTEM DAN LINGKUNGANNYA
PEMODELAN SISTEM
PROSES REKAYASA SISTEM
PENGADAAN SISTEM

1. PENGERTIAN REKAYASA SISTEM

Rekayasa sistem adalah kumpulan konsep, pendekatan dan metodologi, serta
alat-alat bantu (tools) untuk merancang dan menginstalasi sebuah kompleks
sistem.
Kompleksitas sistem bisa diakibatkan karena 2 hal yaitu kompleksitas dinamis dan
kompleksitas detail. Kompleksitas detail ketika komponen atau sub-sistem yang
dirancang tidak hanya banyak tetapi ditambah pula dengan multi-sourcing (multi
suplier), multi standard, multi criteria dan lainnya.
Rekayasa sistem dewasa ini, terutama di Amerika, lekat dengan dunia militer, karena
produk-produk militer memang memiliki kriteria akan kompleksitas detail seperti ini,
misalnya pesawat tempur, kapal induk, sistem pertahanan rudal patrior dsb, dimana
timbul kombinasi yang kompleks antara sub-sistem mekanis, sub-sistem elektronik dan
sub-sistem manusia.

Disiplin ilmu sistem engineering sendiri dewasa ini sedang berevolusi untuk mencari
jati diri. Sebagian besar masih bergabung dengan bidang ilmu lainnya seperti biologi,
teknik industri, teknik komputer, teknik kimia (instalasi sebuah processing plant
membutuhkan skill rekayasa sistem).
 Dalam lingkup pengembangan perangkat lunak, rekayasa Sistem adalah kegiatan
untuk menentukan spesifikasi, perancangan, pengimplementasian, penyebaran,
dan pemeliharaan sistem sebagai satu kesatuan. Sehingga, rekayasa sistem atau lebih
tepatnya, rekayasa sistem berbasis komputer berhubungan dengan semua aspek
pengembangan dan evolusi sistem kompleks dimana perangkat lunak memainkan peran
utama. Rekayasa sistem merupakan disiplin yang lebih tua dibandingkan dengan
rekayasa perangkat lunak. Orang telah melakukan spesifikasi dan perakitan sistem
industri secara kompleks seperti kereta api dan pabrik kimia selama lebih dari 100 tahun.
Akan tetapi, seiring dengan bertambahnya persentase perangkat lunak
pada sistem, maka teknik rekayasa perangkat lunak seperti pemodelan use – case,
manajemen konfigurasi, dan lain sebagainya sering dipergunakan dalam proses rekayasa
sistem.

Sommerville mendefinisikan sistem sebagai sekumpulan komponen yang saling

berhubungan dan bekerja sama untuk mencapai tujuan. Definisi umum ini mencakup
banyak jenis sistem. Sebagai contoh, sistem yang sederhana seperti sistem pencatatan
skor mungkin hanya terdiri dari 2 atau 3 modul perangkat lunak. Sebaliknya, sistem
kontrol lalu lintas dapat terdiri dari ratusan perangkat lunak dan keran, ditambah
manusia sebagai pemakainya, yang membuat keputusan berdasarkan informasi.
Sistem seringkali hierarkis, dimana bahwa mereka mencakup sistem – sistem lain.
Sebagai contoh, sistem perintah dan kendali polisi mungkin melibatkan sistem informasi
geografis untuk memberikan detail lokasi suatu peristiwa. Sistem – sistem lain inilah
yang disebut sebagai subsistem. Karakteristik subsistem adalah kemampuannya untuk
berinteraksi secara independen. Dengan demikian, beberapa sistem informasi geografis
dapat dipakai pada sistem lain. Namun demikian, perilakunya pada sistem tertentu
bergantung pada subsistem lain. Adanya hubungan yang kompleks dalam sistem inilah
yang membuat rekayasa perangkat lunak merupakan bagian dari rekayasa sistem
berbasis komputer mengingat pentingnya perangkat lunak pada sebuah sistem.

Pressman menyebut sistem yang didalamnya terdapat perangkat lunak sebagai sistem
berbasis komputer. Pada sistem berbasis komputer terdapat komponen – komponen
sebagai berikut :

 Perangkat Keras (Hardware)

 Orang (People)
 Perangkat Lunak (Software)
 Basis Data (Database)
 Prosedur (Procedure)
 Dokumentasi

2. PROPERTI SISTEM
 Rekayasa sistem adalah kegiatan penspesifikasian, perancangan dan
pengimplementasianpemvalidasian, penyebaran dan pemeliharaan sistem sebagai
satu kesatuan.
 Ada banyak definisi yang benar tentang sistem, mulai dari yang paling abstrak ke
ayangpaling konkret tetapi defnisi prktisnya yang berguna adalah sistem
merupakan sekeumpulan komponen yang saling berhubungan dan bekerja sama
untuk mencapai suatu tujuan.
 Adanya hubungan yang kompleks anta komponen pada sistem memiliki arti
bahwa sistem tersebut lebi h dari sekedar penjumlahan abagian-bagianna.
Komponen sistemmemiliki properti yang merupakan properti sistem secara
keseluruhan.

Beberapa contoh properti baru ini adalah :

1. Beban sistem secara keseluruhan. Ini merupakan contoh properti baru yang
dapat dihitung dan properti kompoenen ini individual.
2. Keandalan sistem. Hal ini bergantung pada keandlaan komponen sistem da
hubungan di antara komponen tersebut.
 3. Kemampuapakaian sistem. Ini merupakan propert yang sangat kompleks
yang tidak hanya bergantung pada perangkat keras dan lunak sistem tetapi
juga bergantung pada orperator sistem dan lingkungan di amna sistem
tersebut diguankan.

Ada dua jenis properti baru yaitu :

1. Properti fungsional. Properti ini muncul ketika semua bagian sistem
bekerja sama untuk mencapai tujuan tertentu.
2. Properti baru non fungsional seperti keandalan, kinerja, keselmatan dan
keamanan. Properti ini menggambarkan kinerja sistem pada lingkungan
operasionalnya.

Ada 3 pengaruh yang berhubungan erat pada keandalan menyeluruh suatu sistem :
1. Keandalan perangkat keras. Berapa besar probabilitas komponen perangkat
keras akan rusak dan berapa lama waktu yang diperlukan untuk memperbaikinya.
2. Keandalan perangkat lunak. Berapa besar komponen perangkat unak
menghasilkan output yang tidak benar? Kerusakan perangakt unak dapat
dibedakan dari kerusakan perangkat keras dalam artian bahwa perangakt lunak
tidak bertambah usang.
3. Keandalan operator.

3. SISTEM DAN LINGKUNGANNYA

Sistem bukan merupakan entitas yang berdiri sendiri, melainkan terdapat dalam suatu
lingkungan. Lingkungan ini memperngaruhi fungsi dan kinerja sistem.

Ada 2 alasan mengapa lingkungan sistem harus dipahami oleh perekayasa sistem.
1. Pada banyak kasus, sistem ditujukan untuk melakukan beberapa perubahan
dilingkungannya.
2. Fungsi sistem dapat dipengaruhi oleh perubahan pada oingkunganya dengan cara
yang mungkin sulit untuk diramalkan.

Faktor manusia dan organisasi yang diturunkan dari lingkungan sistem yang
mempengaruhi perancangan sistem mencakup :
1. Perubahan proses. Apkaha sistem membetulkan perubahan proses kerja pada
lingkungan? Jika perubahan tersebut signifikan, atau jika melibatkan pemecatan
beberapa orang maka ada bahaya bahwa sistem ini akan ditolak oleh usernya.
2. Perubahan kerja. Apakah sistem menyebabkan useri di lingkungan kehilangan
keahliannya atau menyebabkan mereka harus mengubah cara kerja.
3. Perubahan organisasi. Apakah sistem mengubah struktur kekuatan politik dalam
organisasi.

4. PEMODELAN SISTEM
Sebagai bagian dari persyaratan sistem dan kegiatan perancangan, sistem harus
doimodelkan sebagai suatu kumpulan komponen dan hubungan antara komponen-
komponen ini.
Arsitektur sistem biasanya digambarkan sebagai diagram blok yang menunjukkan
subsistem utama dan interkoneksi antara subsisteem-subsistem ini.
Setiap subsistem direpresentasikan sebagai segi empat pada diagram blok dan
dihubungkan antara mereka ditujukkan dengan tanda panah yang menghubungkan
persegi tersebut.

Komponen Sistem Fungsional

Komponen fungsional pada sistem bisa diklasifikasikan dengan berbagai nama :
1. Komponen sensor.
2. Komponen aktuator
3. Komponen koputasi
4. Komponen komunikasi
5. Komponen koordinasi
6. Komponen intrface.

5. PROSES REKAYASA SISTEM

Ada perbedaan penting antara proses rekayasa sistem dan proses pengembangan
perangkat lunak :
1. Keterlibatan interdisipliner. Banyak disiplin ilmu yang mungkn terlibat pada rekayasa
sistem.
2. Ruang yang lebih kecil untuk pengerjaan ulang selama pengembangan sistem.

Definisi Persyaratan Sistem

Fase definisi persyaratan ini biasanya dipusatkan pada penurunan tiga jenis
persyaratan :
1. Persyaratan fungsional abstrak. Fungsi dasar yang harus diberikan sistem
didefinisikan pada tingkat abstrak.
2. Properti sistem. Properti ini bisa mencakup keandalan, kinerja, keselamatan, dll.
3. Karakteristik yang tidak boleh ditunjukkan oleh sistem. Kadang kala penitng untuk
menspesifikasikan apa yang tidak boleh dikerjakan sistem, disamping menspesifikasikan
apa yang harus dikerjakan oleh sistem.

Suatu bagian penting dari fase pendefinisian persyraatan adalah menetapkan satu
set tujuan menyeluruh yang ahrus dipenuhi oleh sistem.
Tujuan ini tidak harus dinyatakan sebagai fungsionalitas sistem tetapi harus
mendefinisikan mengapa sistem dubuat untuk lingkungan tertentu.
Perancangan Sistem
Perancangan sistem berhubungan dengan bagaimana fungsionalitas sistem
disediakan oleh komponen sistem.
o Persyaratan pembagian : persyartan dianlisis dan dikumpulkan mnejadi
kelompok yang berhubungan.
 o Identifikasi sistem : subsistem yang berbeda yang secara individu atau kolektif
memenuhi persyartaan diidentifikasi.
o Terapkan persyaratan pada subsistem : persyartan ditetapkan pada subsistem
o Tentukan fungsionalitas subsistem : fungsi spesifik yang diberikan setiap
subsistem dispesifikasi.
o Didefinisikan interface subsistem : kegiatan ini melibatkan pendefinisian
interface yang disediakan dan dibutuhkan oleh setiap subsistem.

Pengembangan Subsistem
Pengembangan subsitem diidentifikasikan pada perancangan sistem
diimplementasikan. Kegiatan ini melibatkan proses rekayasa sistem lain untuk
subsistem individu.
Subsistem yang berbeda biasanya dikembangkan secara pararel. Jika ditemukan
masalah yang melewati batasan subsistem, harus dilakukan permohonan modifikasi
sistem.

Intergrasi Sistem
Integrasi sistem mencakup pengumpulan subsistem yang dikembangkan seecara
independen dan menggabungkannya untuk membentuk sistem yang lengkap.

Adapun dua alasan mengapa proses inkremental ini merupakan pendekatan yang
paling sesuai :
1. Biasanya tidak mungkin menjadwalkan semua pengembangan subsistem sehingga
seluruhnya selesai pada waktu yang sama.
2. Integrasi inkremental memperkecil biaya lokasi kesalahan.

Instalasi Sistem
 Pada saat instalasi sistem diletakkan di lingkungan dimana sistem akan beroperasi.
Walaupun proses ini tempak sederhana, banyak amsalah yang dapat timbul dan ini
berarti bahwa instalasi sistem yang kompleks bisa memakan waktu lama.
Contoh :
1. Lingkungan dimana sistem akan diintal tidak sama dengan lingkungan yang
diasumsikan oleh pengembang sistem.
2. User potensial sistem mungkin tidak suka dengan keberadaan sistem tersebut.
3. Sistem baru harus berdampingan dengan sistem yang sudah ada sampai organisasi
puas dengan sistem baru yang bekerja dengan benar.
4. Terdapat masalah pada instalasi fisik.

Operasi Sistem
Pengoperasian system bisa melibatkan pengaturan sesi pelatihan untuk operator
dan perubahan proses kerja normal untuk menggunakan system baru dengan efektif.
Masalah yang dapat timbul hanya setelah system dioperasikan adalah masalah
mengoperasikan system baru dengan system yang ada.

Evolusi Sistem
Sistem yang besar dan kompleks memiliki waktu hidup yang sangat lama. Selama
hidupnya sistem tersebut harus berubah untuk memperbaiki keslahan pada persyaratan
sistem yanga sli dan ememenuhi persyartan baru yang muncul.

Evolusi sistem termasuk mahal karena :

1. Perubahan yang diusulkan harus dinalisis dengan teliti dari sudut pandang bisnis
dan teknik.
2. Karena subsistem tidak pernah benar-benar independen, perubahan satu
subsistem bisa mempengaruhi kinerja atau perilaku subsistem lain.
3. Dasar keputusan rancangan awal seringkali tidak tercatat.
4. Sementara sistem bertambah tua, struktur biasanya akan berganti karena adanya
perubahan sehingga biaya perubahan berikutnya akan bertambah.
Menonaktifkan Sistem
Menonaktifkan sistem berarti tidak memakai lagi sistem terebut pada akhir waktu
hidup operasionalnya yang berguna.
Kegiatan rekayasa sistem harus mengantisipasi penonaktifan dan
memperhitungkan masalah pembuangan materi pada saat fase perancangan.

6. PENGADAAN SISTEM
Proses pengadaan sistem berhubungan dengan pembuatan keutusan mengenai cara
terbaik organisasi mendapatkan sistem dan memutuskan pemaso terbaik dari sistem
tersebut.
Proses pengadaan berhubungan erat dengan proses rekayasa sistem. Beberap
spesifikasi sistem dan perancangan arsitektural dilakukan sebelum keputudan pengadaan
ini dibuat. Ada dua alasan :
1. Untuk membei dan menyewa kontrak perancangan dan pengembangan sistem,
spesifikasi tingkat tinggi mengenai apa yang harus dilakukan siste etersebut harus
diselesaikan.
2. Hampir selalu lebih murah untuk membeli sistem ketimbang merancang, membuat
dan membangunnya sebagai proyek yang terpisah.

Pengertian Proses Perangkat Lunak

Rekayasa Perangkat Lunak atau Software Engineering adalah satu bidang
profesi yang mendalami cara-cara pengembangan perangkat lunak termasuk pembuatan,
pemeliharaan, manajemen organisasi pengembanganan perangkat lunak dan manajemen
kualitas.

Proses perangkat lunak adalah serangkaian kegiatan dan hasil-hasil relevannya yang
menghasilkan perangkat lunak (sebagian besar dilakukan oleh perekayasa perangkat
lunak).
Ada 4 macam kegiatan/aktivitas pada proses perangkat lunak :
1. Spesifikasi Perangkat Lunak : Fungsionalitas perangkat lunak dan batasan
kemampuan operasinya harus didefinisikan.
2. Pengembangan Perangkat Lunak : Perangkat lunak yang memenuhi spesifikasi
harus diproduksi.
3. Validasi Perangkat Lunak : Perangkat lunak harus divalidasi untuk menjamin
bahwa perangkat lunak melakukan apa yang diinginkan oleh pelanggan.
4. Evolusi Perangkat Lunak : Perangkat lunak harus berkembang untuk memenuhi
kebutuhan pelanggan.

B.Model Proses Perangkat Lunak

A. Model Waterfall

Model Waterfall ini awalnya ditemukan oleh Winston W. Royce pada tahun
1970 . Dia menulis sebuah artikel ilmiah yang berisi pandangan pribadinya pada
pengembangan perangkat lunak . Pada paruh pertama dari artikel, ia membahas sebuah
proses yang dia sebut ” megah ” . Dia bahkan menggambar sosok model , dan lain yang
menunjukkan mengapa hal itu tidak bekerja ( karena persyaratan selalu berubah ) .
Model ini adalah air terjun . Dia menggunakannya sebagai contoh dari proses yang sama
sekali tidak bekerja. Di paruh kedua artikel ia menggambarkan proses berulang-ulang
bahwa ia dianggap jauh lebih baik .

Pada model Waterfall atau disebut model air terjun, ada beberapa fase yang harus kita
terapkan, yaitu:

1. Analisis kebutuhan lalu pendefenisiannya

2. Perancangan Sistem dan Perangkat lunaknya
3. Implementasi dan unit testing
4. Integrasi dan pengujian sistem
5. Pengoprasian dan perawatan
 Dimana sebuah proses akan kembali ke state sebulumnya agar tidak ada
perubahan setelah proses menuju state di bawahnya sebab sangat sulit.
Setiap model pasti ada kekurangan dan kelebihan, dan berikut merupakan kekurangan
dan kelebihan dari model Waterfall :

Kelebihan Model Waterfall:

 Bisa digunakan jika suatu persyaratan untuk membuat suatu software sudah
dipahami dengan baik dan sudah lengkap semua persyaratan yang ada.

Kekurangan Model Waterfall:

 Terjadinya pembagian proyek menjadi tahap-tahap yang tidak fleksibel, karena

komitmen harus dilakukan pada tahap awal proses.
 Hal ini mengakibatkan sulitnya untuk merespon perubahan kebutuhan pengguna
(user).
 Model air terjun harus digunakan hanya ketika persyaratan dipahami dengan
baik.

B. Model RAD
 Rapid Aplication Model (RAD) adalah sebuah proses perkembangan perangkat
lunak sekuensial linier yang menekankan siklus perkembangan yang sangat pendek.
Model RAD ini merupakan sebuah adaptasi “kecepatan tinggi” dari model sekuensial
linier dimana perkembangan cepat dicapai dengan menggunakan pendekatan konstruksi
berbasis komponen.

Kelebihan Penggunaan Model RAD

 Dimungkinkan dalam proses pembuatan membutuhkan waktu yang sangat

singkat (60-90 hari).
 Menghemat biaya, karena penekannya adalah penggunaan komponen-komponen
yang sudah ada.
 RAD menggunakan kembali komponen-komponen yang sudah ada, maka
beberapa komponen program sudah diuji sehingga kita dapat melakukan
penghematan waktu dalam uji coba

Kekurangan Penggunaan Model RAD

Seperti semua proses model yang lain, pendekatan RAD memiliki kekurangan-
kekurangan sebagi berikut :

 Bagi proyek yang besar tetapi berskala, RAD memerlukan sumber daya manusia
yang memadai untuk menciptakan jumlah tim RAD yang baik.
 RAD menuntut pengembangan dan pelanggan yang memiliki komitmen di dalam
aktifitas rapid-fire yang diperlukan untuk melengkapi sebuah sistem, di dalam
kerangka waktu yang sangat diperpendek. Jika komitmen tersebut tidak ada,
proyek RAD akan gagal. RAD menekankan perkembangan komponen program
yang bisa dipakai kembali. Reusable menjadi batu pertama teknologi objek dan
ditemui di dalam proses rakitan komponen
  Tidak semua aplikasi sesuai untuk RAD. Bila sistem tidak dapat dimodulkan
dengan teratur, pembangunan komponen penting pada RAD akan menjadi sangat
problematis.
 RAD menjadi tidak sesuai jika risiko teknisnya tinggi. Hal ini terjadi bila sebuah
aplikasi baru memforsir teknologi baru atau bila perangkat lunak baru
membutuhkan tingkat interoperabilitas yang tinggi dengan program komputer
yang ada.

C. Model Prototyping

Metode prototyping adalah sistem informasi yang menggambarkan hal-hal

penting dari sistem informasi yang akan datang. Prototipe sistem informasi bukanlah
merupakan sesuatu yang lengkap, tetapi sesuatu yang harus dimodifikasi kembali,
dikembangkan, ditambahkan atau digabungkan dengan sistem informasi yang lain bila
perlu.
Keunggulan Prototyping:

1. user dapat berpartisipasi aktif

2. Penentuan kebutuhan lebih mudah diwujudkan
3. Mempersingkat waktu pengembangan SI

Kelemahan Prototyping :

1. Proses analisis dan perancangan terlalu singkat

2. Mengesampingkan alternatif pemecahan masalah
3. Bisanya kurang fleksible dalam mengahadapi perubahan
4. Prototype yang dihasilkan tidak selamanya mudah dirubah
5. Prototype terlalu cepat selesai

D. Model Spiral

Model ini cukup baru ditemukan,yaitu tahun 1988 oleh Barry Boehm. Spiral
adalah salah satu bentuk evolusi yang menggunakan metode iterasi natural yang dimiliki
oleh model prototyping dan digabungkan dengan aspek sistematis yang dikembangkan
model waterfall.
Kelebihan model Spiral :

1. Dapat disesuaikan agar perangkat lunak bisa dipakai selama hidup perangkat
lunak komputer.
2. Lebih cocok untuk pengembangan sistem dan perangkat lunak skala besar
3. Pengembang dan pemakai dapat lebih mudah memahami dan bereaksi terhadap
resiko setiap tingkat evolusi karena perangkat lunak terus bekerja selama proses
.

Kelemahan model Spiral:

 1. Sulit untuk menyakinkan pelanggan bahwa pendekatan evolusioner ini bisa
dikontrol.
2. Memerlukan penaksiran resiko yang masuk akal dan akan menjadi masalah yang
serius jika resiko mayor tidak ditemukan dan diatur.
3. Butuh waktu lama untuk menerapkan paradigma ini menuju kepastian yang
absolute

E. Model Incremental

Model Incremental dalam rekayasa perangkat lunak, menerapkan rekayasa

perangkat lunak perbagian, hingga menghasilkan perangkat lunak yang lengkap. Proses
membangun berhenti jika produk telah mencapai seluruh fungsi yang diharapkan.

Kelebihan Incremental :

 Kebutuhan pengguna / customer dipenuhi pada setiap bagian yang selesai

terlebih dahulu
 Bagian yang selesai terlebih dahulu menjadi prototipe
 Resiko rendah
 Bagian yang punya prioritas tertinggi dapat dites secara intensive

Kekurangan Incremental

 Permasalahan
 Batasan proses tidak jelas
 Sistem kurang terstruktur
 Kemampuan aplikasi
 Untuk sistem dengan interaksi skala kecil dan medium
 Untuk antarmuka user
 Untuk sistem dengan masa penggunaan pendek

F. Rational Unified Process

 Menggunakan konsep object oriented, dengan aktifitas yang berfokus pada
pengembangan model dengan menggunakan Unified Model Language (UML).

Ada beberapa keuntungan dengan mengunakan RUP di antaranya :

 Menyediakan akses yang mudah terhadap pengetahuan dasar bagi anggota tim.
 Menyediakan petunjuk bagaimana menggunakan UML secara efektif.
 Mendukung proses pengulangan dalam pengembangan software.
 Memungkinkan adanya penambahan-penambahan pada proses.
 Memungkinkan untuk secara sistematis mengontrol perubahan-perubahan yang
terjadi pada software selama proses pengembangannya.
 Memungkinkan untuk menjalankan test case dengan menggunakan Rational Test

Kekurangan Pengembangan Perangkat Lunak RUP :

 Metodologi ini hanya dapat digunakan pada pengembangan perangkat lunak

yang berorientasi objek dengan berfokus pada UML (Unified Modeling
Language)

G. Extreme Programming (XP) Model

Extreme Programming (XP) adalah metode :

 pengembangan perangkat lunak yang ringan dan termasuk salah satu agile
methods yang dipelopori oleh Kent Beck, Ron Jeffries, dan Ward Cunningham.
 XP merupakan agile methods yang paling banyak digunakan dan menjadi sebuah
pendekatan yang sangat terkenal.
 Sasaran XP adalah tim yang dibentuk berukuran antara kecil sampai medium
saja, tidak perlu menggunakan sebuah tim yang besar. Hal ini dimaksudkan
untuk menghadapirequirements yang tidak jelas maupun terjadinya perubahan-
perubahan requirements yang sangat

Keunggulan:
  Menjalin komunikasi yang baik dengan klien. (Planning Phase)
 Menurunkan biaya pengembangan (Implementation Phase)
 Meningkatkan komunikasi dan sifat saling menghargai antar developer.
(Implementation Phase)
 XP merupkan metodologi yang semi formal. (Planning Phase)
 Developer harus selalu siap dengan perubahan karena perubahan akan selalu
diterima, atau dengan kata lain fleksibel. (Maintenance Phase)

Kelemahan :

 Tidak bisa membuat kode yang detail di awal (prinsip simplicity dan juga
anjuran untuk melakukan apa yang diperlukan hari itu juga).XP juga memiliki
keunggulan yang sekaligus menjadi kelemahannya, yaitu XP tidak memiliki
dokumentasi formal yang dibuat selama pengembangan. Satu-satunya
dokumentasi adalah dokumentasi awal yang dilakukan oleh user.

H. Timeboxing Model

Dalam model timeboxing, unit dasar dari

pembangunan adalah kotak waktu, yang adalah jangka waktu yang tetap. Karena durasi
adalah tetap, faktor kunci dalam memilih persyaratan atau fitur yang akan dibangun di
kotak waktu yang bisa masuk ke dalam waktu box. Hal ini berbeda dengan pendekatan
berulang biasa di mana fungsi dipilih dan kemudian waktu untuk memberikan
ditentukan. Perubahan timeboxing perspektif pembangunan dan membuat jadwal non
dinegosiasikan dan Komitmen prioritas tinggi.

Persyaratan perangkat lunak

A. Defenisi

Persyaratan perangkat lunak adalah Proses menetapkan layanan yang dibutuhkan

konsumen terhadap sistem dengan batasan operasi dan pengembangan. Persyaratan itu sendiri
adalah diskripsi layanan sistem dan batasan yang dihasilkan selama proses rekayasa persyaratan.
Perangkat Lunak harus memberikan bantuan dalam mempresentasikan dan mengakses file-file
eksternal yang dibuat dengan alat bantu lain.

B. Spesifikasi Persyaratan
 1. User diberikan fasilitas untuk mendefinisikan tipe file eksternal
2. Setiap tipe file eksternal mempunyai alat untuk dihubungkan yang dapat diaplikasikan
ke file
3. Setiap tipe file eksternal direpresentasikan sebagai icon tertentu pada tampilan User
4. Fasilitas disediakan untuk icon yang merepresentasikan tipe file eksternal yang
didefinisikan oleh user
5. Jika user memilih icon untuk merepresentasikan file eksternal, efek
pemilihanmengaplikasikan alat yang menghubungkan antara tipe file eksternal ke file
yangdirepresentasikan oleh icon terpilih

C. Tujuan perangkat lunak

Yaitu untuk memahami kebutuhan user.

Untuk itu perlu adanya persyaratan-persyaratan antara lain:

1. Persyaratan Fungsional dan Non Fungsional.

a. Persyaratan Fungsional

Pernyataan layanan tentang bagaimana sistem harus bereaksi terhadap input, sistem
harus berlaku pada situasi-situasi tertentu. Secara khusus menyatakan apa yang tidak
boleh dilakukan sistem. Merupakan penjelasan tentang layanan yang perlu
disediakan oleh system,bagaimana system menerima dan mengolah masukkan,dan
bagaimana sistem mengatasi situasi-situasi tertentu. Selain itu kadang-kadang juga
secara jelas menentukan apa yang tidak dikerjakan oleh system. Fungsional
requirenment menggambarkan system requirenment secara detail seperti
input,output dan pengecualian yang berlaku.

Contoh Persyaratan fungsional:

 User dapat mencari semua atau satu set awal database atau memilih subset darinya.
 System akan menyediakan viewer yang sesuai bagi user untuk membaca dokumen pada
penyimpanan (store) dokumen.
 Semua pemesanan diberi identifier yang unik (ORDER_ID) yang dapat di copy user ke
area penyimpanan permanent untuk account tersebut.
 b. Persyaratan Non Fungsional
Pernyataan tentang batasan layanan dan fungsi yang diberikan sistem. Karena
berkaitan dengan kebutuhan system secara keseluruhan, maka kegagalan memenuhi
kebutuhan jenis ini berakibat pada system secara keseluruhan. Contoh kebutuhan
jenis ini adalah kecepatan akses, keamanan data, besarnya kapasitas penyimpanan
yang diperlukan, privasi masing - masing profil / account, bahasa pemrograman
yang digunakan, system operasi yang di gunakan. Persyaratan non-fungsional terdiri
dari :
1. Persyaratan Produk: persyaratan yang diambil dari spesifikasi produk yang berkaitan
dengan kehandalan, kecepatan, kemudahan digunakan, kapasitas memori yang
dibutuhkan dan efisiensi system seperti persyaratan hardware untuk mendukung kinerja.
2. Persyaratan Organisasi: persyaratan yang berasal dari kebijakan dan prosedur pada
organisasi yang berkaitan dengan standar, bahasa pemrograman dan metode rancangan
yang digunakan.
3. Persyaratan Eksternal: persyaratan yang berasal dari factor eksternal terhadap system
dan proses pengembangannya yang berkaitan dengan masalah etika penggunaan,
interoperabilitas dengan system lain, legalitas dan privasi.

Ukuran persyaratan non-fungsional :

 Kecepatan: transaksi yang diproses perdetik, waktu tanggal user per event atau waktu
refres layar.
 Ukuran: KB atau jumlah Chip RAM.
 Kemudahan Penggunaan: waktu pelatihan atau jumlah frame help.
 Kehandalan: waktu rata-rata kegagalan, probabilitas ketidaksediaan, kecepatan
terjadinya kegagalan atau ketersediaan.
 Ketahanan: waktu start ulang setelah kegagalan, prosentase event yang gagal atau
probabilitas korupsi data.
 Portabilitas: presentase pernyataan tergantung target atau jumlah system target.

2. Persyaratan Domain.
 Persyaratan yang datang dari domain aplikasi sistem dan merefleksikan karakteristik
domain tersebut. Persyaratan-Persyaratan ini bisa berupa persyaratan fungsional yang
baru,membatasi persyaratan fungsional yang ada atau menentukan bagaimana komputasi tertentu
harus dilakukan. Jika persyaratan ini tidak dipenuhi,tidak menutup kemungkinan membuat
sistem bekerja dengan tidak memuaskan.
3. Persyaratan User

Mendeskprisikan persyaratan fungsional dan non-fungsional sehingga dapat dipahami

oleh user yang tidak memiliki pengetahuan teknik yang rinci. Persyaratan user harus ditulis
memakai bahasa natural formal dan diagaram intuitif yang sederhana sehingga dapat dipahami
oleh semua user. Persyaratan user tidak boleh didefinisikan memakai model implementasi.

Masalah yang sering muncul dengan bahasa alami:

a. Ketidak jelasan.
Sulit untuk presesi tanpa membuat dokumen yang sulit dibaca.
b. Persyaratan yang membingungkan.
Persyaratan fungsional dan non fungsional cenderung dicampur aduk.
c. Penggabungan persyaratan.
Beberapa persyaratan yang berbeda dinyatakan bersama-sama.

Untuk meminimasi kesalahan pahaman ketika menulis persyaratan user, beberapa

panduan sederhana untuk menulis persyaratan:

1.Buat format standart dan pastikan bahwa semua defenisi persyaratan mengikuti format
tersebut.

2.Gunakan bahasa secara konsisten. Bedakan antara persyaratan yng diperintahkan dan
yang diinginkan.

3.Gunakan penonjolan text( tebal dan miring) untuk menentukan bagian kunci pada
persyaratan tersebut.

4.Hindari semaksimal mungkin penggunaan istilah komputer.

4. Persyaratan Sistem
 Persyaratan system ini lebih rinci dari persyaratan user, dan berfungsi sebagai dasar
kontrak untuk implementasi system. Persyaratan system ini digunakan sebagai titik awal
perancangan system. Bahasa natural banyak digunakan dalam mendefinisikan persyaratan
system.

Notasi Spesifikasi Persyaratan :

1. Bahasa Natural Terstruktur

Pendekatan ini tergantung pada pendefinisian format atau template standar
untuk menyatakan spesifikasi persyaratan.
2. Bahasa Deskripsi Desain
Pendekatan ini menggunakan bahasa pemrograman tetapi dengan lebih
banyak fitur abstrak.
3. Notasi Grafis
Bahasa grafis dilengkapi oleh notasi teks yang digunakan untuk
mendefinisikan persyaratan fungsional.
4. Spesifikasi Matematis
Notasi seperti himpunan atau finite-state machine, lebih dikenal dengan
bahasa formal.

5. Dokumen Persyaratan Perangkat Lunak

Dokumen persyaratan perangkat lunak (SRS/Software Requirements Specification)

merupakan persyaratan resmi mengenai apa yang dituntut dari pengembang sistem. Dokumen
berisi persyaratan user untuk sistem dan spesifikasi secara rinci dari persyaratan sistem. Berikut
ilustrasi contoh dokumen persyaratan perangkat lunak dan bagaimana pemanfaatannya.
- Pelanggan Sistem
Menspesifikasikan persyaratan dan membacanya untuk memeriksa apakah sudah
memenuhi kebutuhan. Mereka menspesifikasi perubahan atas persyaratan tersebut
- Manajer
Menggunakan dokumen persyaratan untuk merencanakan penawaran atas sistem
dan merencanakan proses pengembangan sistem
- Perekayasa sistem
Menggunakan persyaratan untuk memahami ssitem apa yang akan dikembangkan
- Perekayasa pengujian sistem
Menggunakan persyaratan untuk mengembangkan pengujian validasi bagi sistem.
- Perekayasa pemeliharaan sistem
Menggunakan persyaratan untuk membantu memahami sistem dan hubungan antara
bagian – bagiannya.

Struktur dokumen persyaratan berdasarkan standart IEEE:

1. Pendahuluan
1.1. Tujuan Dokumen Persyaratan
1.2. Cakupan Produk
1.3. Definisi, Akronim dan Singkatan
1.4. Referensi
1.5. Tinjauan Bagian Dokumen Berikutnya
2. Deskripsi Umum
2.1. Perspektif Umum
2.2. Fungsi Produk
2.3. Karakteristik User
2.4. Batasan-Batasan Umum
2.5. Asumsi dan Ketergantungan
3. Persyaratan Khusus: mencakup persyaratan fungsional, non-fungsional, dan
interface
4. Lampiran
5. Indeks
 MANAJEMEN PROYEK
1. Pengertian

“Manajemen proyek merupakan suatu usaha merencanakan, mengorganisasi,

mengarahkan, mengkoordinasi, dan mengawasi kegiatan dalam proyek sedemikian rupa
sehingga sesuai dengan jadwal waktu dan anggaran yang telah ditetapkan.”
Atau
“Manajemen proyek adalah suatu cara mengelola, mengarahkan, dan
mengkoordinasikan sumber daya ( manusia / material ) disaat mulainya sebuah proyek
hingga akhir untuk mencapai suatu tujuan, yang dibatasi oleh biaya, waktu, dan kualitas
untuk mencapai kepuasan.”
Suatu pekerjaan rutin biasanya berlangsung secara berulang-ulang dan
berorientasi ke proses. Sebagai suatu proses yang terus menerus, pekerjaan yang rutin
tidak dianggap suatu proyek.
Pengelola dalam sebuah proyek disebut sebagai Proyek Manager (PM), Proyek
Manager bertanggung jawab untuk mengatur dan mengawasi semua kegiatan
pelaksanaan proyek, agar sesuai dengan standart kualitas, biaya dan waktu. Dan
tentunya selalu bertanggung jawab untuk selalu berkomunikasi dengan tim, atasan
(owner), dan pelanggan (user). Maksudnya manajer harus mampu memberikan contoh
tehnik, mampu mengambil keputusan yang tepat, dan pemimpin yang dapat memberikan
informasi berupa laporan kepada atasan.

2. Sejarah Manajemen Proyek

Sebagai sebuah dispilin keilmuan, Manajemen Proyek dikembangkan dari

beberapa bidang aplikasi termasuk didalamnya konstruksi sipil, teknik rekayasa, dan
juga aktivitas di bidang HANKAM (pertahanan-keamanan). Manajemen Proyek telah
diterapkan dari awal perabadan manusia. Kemudian baru pada tahun 1900-an
Manajemen Proyek dengan proses sistematiknya diterapkan pada proyek rekayasa yang
kompleks.
Dua tokoh yang fenomenal dari manajemen proyek. Adalah Henry Gantt,
disebut ayah dari teknik perencanaan dan kontrol , yang terkenal dengan penggunaan
tentang Gantt chart sebagai alat manajemen proyek, dan kemudian Henri Fayol untuk
ciptaan-Nya dari 5 fungsi manajemen yang membentuk dasar dari tubuh pengetahuan
yang terkait dengan proyek dan manajemen program. Gantt dan Fayol, keduanya adalah
mahasiswa Frederick Winslow Taylor untuk memperdalam teori manajemen ilmiah.
Karyanya adalah pelopor alat manajemen proyek modern termasuk rincian struktur kerja
(WBS – Work Breakdown Structure) dan alokasi sumber daya.
Tahun 1950 menandai awal era Manajemen Proyek modern datang bersama-
sama dengan bidang Rekayasa Teknis ( Enjinering ) sebagai satu kesatuan. Manajemen
proyek menjadi dikenal sebagai suatu disiplin ilmu yang berbeda yang timbul dari
disiplin ilmu manajemen dengan model rekayasa Di Amerika Serikat. Sebelum tahun
1950-an secara garis besar, proyek dikelola dengan menggunakan Grafik Gantt, sebagai
suatu alat dan teknik informal. Pada saat itu, dua model penjadwalan proyek dengan
model matematis sedang dikembangkan.

Yang pertama adalah Metode Jalur Kritis ( CPM - Critical Path Method ) yang
dikembangkan pada suatu proyek sebagai usaha patungan antara DuPont Corporation
dan Remington Rand Corporation untuk mengelola proyek-proyek pemeliharaan
tanaman. Dan yang kedua adalah "Evaluasi Program dan Tinjauan Teknik" ( PERT -
Program Evaluation and Review Technique ), dikembangkan oleh Booz Allen Hamilton
sebagai bagian dari Angkatan Laut Amerika Serikat ( dalam hubungannya dengan
Lockheed Corporation ) dalam pengembangan Program rudal kapal selam Polaris;
Perhitungan teknik matematis ini kemudian cepat menyebar ke perusahaan-perusahaan
swasta untuk diterapkan.
Dalam waktu yang sama, model penjadwalan-proyek juga sedang
dikembangkan, teknik menghitung biaya proyek, manajemen biaya, dan ekonomi teknik
terus berkembang, dengan kepeloporannya oleh Hans Lang dan lainlain. Pada tahun
1956, American Association of Cost Engineers ( AACE ), yang sekarang disebut AACE
Internasional; Asosiasi Internasional untuk ahli Teknik Biaya yang pada awalnya
dibentuk oleh praktisi manajemen proyek dan spesialisasi terkait dengan perencanaan
dan penjadwalan, perkiraan biaya , dan pengenadalian jadwal proyek ( Pengendali
Proyek - Project Control ).
AACE terus bekerja sebagai perintis dan pada tahun 2006 pertama kali merilis
proses yang terintegrasi untuk manajemen portofolio, program dan proyek ( Total Cost
Management Framework ). AACE menawarkan beberapa sertifikasi seperti CCE, PSP
dan lain sebagainya. Pada tahun 1967, International Project Management Association (
IPMA ) didirikan di Eropa, sebagai sebuah federasi dari beberapa asosiasi manajemen
proyek nasional.
IPMA memelihara struktur federal hari ini dan sekarang termasuk asosiasi
anggota pada setiap benua kecuali Antartika. IPMA menawarkan Sertifikasi Tingkat
Empat program yang berdasarkan Baseline IPMA Kompetensi ( ICB ). ICB ini
mencakup kompetensi teknis, kompetensi kontekstual, dan kompetensi perilaku. Pada
tahun 1969, Project Management Institute ( PMI ) dibentuk di Amerika Serikat. PMI
menerbitkan buku Panduan yang sering disebut dengan PMBOK Guide ( Project
Management Body of Knowledge Guide ), yang menggambarkan praktek manajemen
proyek yang umum untuk "hampir semua proyek dan hampir semua waktu".
PMI juga menawarkan beberapa sertifikasi seperti PMP, CAMP dan lain
sebagainya. Di Indonesia sendiri Manajemen Proyek berkembang pada era tahun 1970 –
1990-an diawali dengan semakin banyaknya berkembang proyek-proyek infrastruktur
yang banyak memerlukan profesional di bidang Manajemen Proyek. Salah satunya yang
berdiri pertama kali adalah Project Management Institut Chapter Jakarta ( yan sekarang
disebut PMI – Indonesia ). PMI Indonesia didirikan pada tahun 1996 dan merupakan
organisasi yang didedikasikan untuk meningkatkan, konsolidasi dan penyaluran
manajemen proyek Indonesia dan bekerja untuk pengembangan pengetahuan dan
keahlian untuk kepentingan semua stakeholder.
Organisasi ini adalah salah satu cabang dari Project Management Institute ( PMI
), sebuah organisasi, nirlaba profesional di seluruh dunia terkemuka. Dan pada tanggal
16 Juli 1999 didirikanlah Ikatan Ahli Manajemen Proyek Indonesia ( IAMPI ) yang
merupakan asosiasi dari para Ahli Manajemen Proyek Indonesia dan didirikan di
Jakarta, sebagai salah satu asosiasi profesi anggota LPKJ. Lembaga IAMPI ini juga
menawarakan sertifikasi yang betaraf nasional di Indonesia. Dan terakhir adalah
lembaga ITAPPI ( Ikatan Tenaga Ahli Pengendali Proyek Indonesia ) yang didirikan
pada tahun 2008 dan merupakan organisasi profesional dengan bidang pengendali
proyek ( Project Control ).

3. Manfaat Manajemen Proyek

a) Mengidentifikasi fungsi tanggung jawab

b) Meminimalkan tuntutan pelaporan rutin
c) Mengidentifikasi batas waktu untuk penjadwalan
d) Mengidentifikasi metode analisa peramalan
e) Mengukur prestasi terhadap rencana
f) Mengidentifikasi masalah dini & tindakan perbaikan
g) Meningkatkan kemampuan estimasi untuk rencana
h) Mengetahui jika sasaran tidak dapat dicapai/terlampaui

4. Konsep Manajemen Proyek

Manajemen proyek sistem informasi ditekankan pada tiga faktor, yaitu :

manusia, masalah dan proses. Dalam pekerjaan sistem informasi faktor manusia sangat
berperan penting dalam suksesnya manajemen proyek. Pentingnya faktor manusia
dinyatakan dalam model kematangan kemampuan manajement manusia ( a people
management capability maturity model / PM-CMM ) yang berfungsi untuk
meningkatkan kesiapan organisasi
perangkat lunak ( sistem informasi ) dalam menyelesaikan masalah dengan melakukan
kegiatan menerima, memilih, kinerja manajemen, pelatihan, kompensasi, pengembangan
karier, organisasi dan rancangan kerja serta pengembangan tim.

5. Ruang Lingkup Proyek

 Menentukan waktu dimulai proyek .

 Perencanaan lingkup dari proyek yang akan dikerjakan.
 Pendefinisian dari ruang lingkup proyek.
  Verifikasi proyek dan kontrol atas perubahan yang mungkin saja terjadi ketika
proyek tersebut dimulai.

6. Contoh Manajemen Proyek

Contoh proyek yang ada dilingkungan sekitar kita, misalnya seperti di bawah ini:
 Proyek konstruksi yaitu hasilnya seperti pembangunan gedung, jembatan, jalan
raya, jalan tol dan lain sebagainya.
 Proyek penelitian dan pembangunan yaitu melakukan suatu penelitian dan
pengembangan, sampai terciptanya suatu produk tertentu dengan maksud dan
tujuan untuk memperbaiki ataupun meningkatkan kualitas suatu produk, layanan
dan lain sebagainya.
 Proyek industri manufaktur yaitu kegiatannya mulai dari merancang sampai
terciptanya suatu produk yang baru.
 Proyek padat modal yaitu suatu proyek yang membutuhkan modal yang besar.
Seperti misalnya pembebasan tanah yang luas, pembelian barang maupun
pengadaan suatu barang, pembangunan suatu

7. Proses

Secara umum, siklus hidup proyek merupakan suatu metode yang digunakan
untuk
menggambarkan bagaimana sebuah proyek direncanakan, dikontrol, dan diawasi sejak
proyek disepakati untuk dikerjakan hingga tujuan akhir proyek tercapai. Terdapat lima
tahap kegiatan utama yang dilakukan dalam siklus hidup proyek yaitu :
1. inisiasi
2. perencanaan dan desain
3. pelaksanaan dan konstruksi
4. pemantauan dan sistem pengendalian
5. penyelesaian.

1. Tahap Inisiasi
Tahap inisiasi proyek merupakan tahap awal kegiatan proyek sejak sebuah
proyek disepakati untuk dikerjakan. Pada tahap ini, permasalahan yang ingin
diselesaikan akan diidentifikasi. Beberapa pilihan solusi untuk menyelesaikan
permasalahan juga didefinisikan. Sebuah studi kelayakan dapat dilakukan untuk memilih
sebuah solusi yang memiliki kemungkinan terbesar untuk direkomendasikan sebagai
solusi terbaik dalam menyelesaikan permasalahan. Ketika sebuah solusi telah ditetapkan,
maka seorang manajer proyek akan ditunjuk sehingga tim proyek dapat dibentuk.

2. Tahap Perencanaan dan Desain

 Ketika ruang lingkup proyek telah ditetapkan dan tim proyek terbentuk, maka
aktivitas proyek mulai memasuki tahap perencanaan. Pada tahap ini, dokumen
perencanaan akan disusun secara terperinci sebagai panduan bagi tim proyek selama
kegiatan proyek berlangsung. Adapun aktivitas yang akan dilakukan pada tahap ini
adalah membuat dokumentasi project plan, resource plan, financial plan, risk plan,
acceptance plan, communication plan, procurement plan, contract supplier dan perform
phare review.

3. Tahap Eksekusi (Pelaksanaan proyek atau Konstruksi)

Dengan definisi proyek yang jelas dan terperinci, maka aktivitas proyek siap
untuk memasuki tahap eksekusi atau pelaksanaan proyek. Pada tahap ini, tujuan proyek
secara fisik akan dibangun. Seluruh aktivitas yang terdapat dalam dokumentasi project
plan akan dieksekusi.

4. Tahap Pemantaun dan sistem Pengendalian

Sementara kegiatan pengembangan berlangsung, beberapa proses manajemen
perlu dilakukan guna memantau dan mengontrol penyelesaian deliverables sebagai hasil
akhir proyek.

5. Tahap Penutupan
Tahap ini merupakan akhir dari aktivitas proyek. Pada tahap ini, hasil akhir
proyek (deliverables project) beserta dokumentasinya diserahkan kepada pelanggan,
kontak dengan supplier diakhiri, tim proyek dibubarkan dan memberikan laporan kepada
semua stakeholder yang menyatakan bahwa kegiatan proyek telah selesai dilaksanakan.
Langkah akhir yang perlu dilakukan pada tahap ini yaitu melakukan post
implementation review untuk mengetahui tingkat keberhasilan proyek dan mencatat
setiap pelajaran yang diperoleh selama kegiatan proyek berlangsung.

8. Organisasi Proyek

Tahapan ini merupakan tahapan sebuah proyek sebelum kemudian ditutup

(penyelesaian). Namun tidak semua proyek akan melalui setiap tahap, artinya proyek
dapat dihentikan sebelum mereka mencapai penyelesaian. Beberapa proyek tidak
mengikuti perencanaan terstruktur atau proses pemantauan. Beberapa proyek akan
melalui langkah 2, 3 dan 4 beberapa kali. Banyak industri menggunakan variasi pada
tahap-tahapan proyek ini. Sebagai contoh, ketika bekerja pada sebuah perencanaan
desain dan konstruksi, proyek biasanya akan melalui tahapan dengan nama yang
berbeda-beda seperti pada tahapan Perencanaan dengan nama: Pra- Perencanaan, Desain
Konseptual, Desain Skema, Pengembangan Desain, Gambar Konstruksi (atau Dokumen
Kontrak), atau Administrasi Konstruksi.

9. Manajemen Proyek Konstruksi

 Proyek konstruksi adalah suatu rangkaian kegiatan yang sifatnya hanya
dilakukan satu kali. Pada umumnya proyek konstruksi memiliki jangka waktu yang
pendek. Di dalam rangkaian kegiatan proyek kontstruksi tersebut, biasanya terdapat
suatu proses yang berfungsi untuk mengolah sumber daya proyek sehingga dapat
menjadi suatu hasil kegiatan yang menghasilkan sebuah bangunan. Adapun proses yang
terjadi dalam rangkaian kegiatan tersebut tentunya akan melibatkan pihak-pihak yang
terkait baik secara langsung maupun tidak langsung. Dengan terlibatnya banyak pihak
dalam sebuah proyek konstruksi maka hal ini dapat menyebabkan potensi terjadinya
konflik juga sangat besar sehingga dapat diambil sebuah kesimpulan bahwa proyek
konstruksi sebenarnya mengandung konflik yang cukup tinggi juga. Manajemen
Konstruksi pada umumnya akan meliputi mutu fisik konstruksi, biaya dan waktu.
Manajemen material serta manjemen tenaga kerja. Pada prinsipnya, dalam manajemen
konstruksi, manajemen tenaga kerja merupakan salah satu hal yang akan lebih
ditekankan.
Hal ini disebabkan manajemen perencanaan hanya berperan sekitar 20% dari
rencana kerja proyek.Sisanya manajemen pelaksanaan termasuk didalamnya
pengendalian biaya dan waktu proyek. Adapun fungsi dari manajemen konstruksi yaitu :
1. Sebagai Quality Control sehingga dapat menjaga kesesuaian antara perencanaan dan
pelaksanaan
2. Mengantisipasi terjadinya perubahan kondisi di lapangan yang tidak pasti serta
mengatasi
kendala terjadinya keterbatasan waktu pelaksanaan
3. Memantau prestasi dan kemajuan proyek yang telah dicapai. Hal itu dilakukan dengan
laporan harian, mingguan dan bulanan

10. Manajemen Waktu Proyek

Manajemen waktu proyek merupakan salah satu kompetensi yang harus dimiliki
oleh seorang manajer proyek. Manajemen waktu proyek dibutuhkan manajer proyek
untuk memantau dan mengendalikan waktu yang dihabiskan dalam menyelesaikan
sebuah proyek. Dengan menerapkan manajemen waktu proyek, seorang manajer proyek
dapat mengontrol jumlah waktu yang dibutuhkan oleh tim proyek untuk membangun
deliverables proyek sehingga memperbesar kemungkinan sebuah proyek dapat
diselesaikan sesuai dengan jadwal yang telah ditentukan.

Terdapat beberapa proses yang perlu dilakukankan seorang manajer proyek

dalam
mengendalikan waktu proyek yaitu :

1. Mendefinisikan aktivitas proyek

Merupakan sebuah proses untuk mendefinisikan setiap aktivitas yang
dibutuhkan untuk mencapai tujuan proyek.
2. Urutan aktivitas proyek
 Proses ini bertujuan untuk mengidentifikasi dan mendokumentasikan hubungan
antara tiap-tiap aktivitas proyek.
3. Estimasi aktivitas sumber daya proyek
Estimasi aktivitas sumber daya proyek bertujuan untuk melakukan estimasi
terhadap
penggunaan sumber daya proyek.
4. Estimasi durasi kegiatan proyek
Proses ini diperlukan untuk menentukan berapa lama waktu yang dibutuhkan
untuk mencapai tujuan proyek.
5. Membuat jadwal proyek
Setelah seluruh aktivitas, waktu dan sumber daya proyek terdefinisi dengan jelas,
maka seorang manager proyek akan membuat jadwal proyek. Jadwal proyek ini
nantinya dapat digunakan untuk menggambarkan secara rinci mengenai seluruh
aktivitas proyek dari awal pengerjaan proyek hingga proyek diselesaikan.
6. Mengontrol dan mengendalikan jadwal proyek
Saat kegiatan proyek mulai berjalan, maka pengendalian dan pengontrolan
jadwal proyek perlu dilakukan. Hal ini diperlukan untuk memastikan apakah kegiatan
proyek berjalan sesuai dengan yang telah direncanakan atau tidak.
Setiap proses di atas setidaknya terjadi sekali dalam setiap proyek dan dalam satu atau
lebih
tahapan proyek.

Terdapat beberapa proses yang perlu dilakukan seorang manajer proyek dalam
melakukan manajemen ruang lingkup proyek, yaitu :

1. Perencanaan ruang lingkup proyek

Pada tahap ini, manajer proyek akan mendokumentasikan bagaimana ruang
lingkup proyek akan didefinisikan, diverifikasi, dikontrol dan menentukan
bagaimana WBS akan dibuat serta merencanakan bagaimana mengendalikan
perubahan akan ruang lingkup proyek.
2. Mendefinisikan ruang lingkup proyek
Pada tahap ini, ruang lingkup proyek akan didefinisikan secara terperinci sebagai
landasan untuk pengambilan keputusan proyek dimasa depan.
3. Membuat Work Breakdown Structure
WBS merupakan pembagian deliverables proyek berdasarkan kelompok kerja.
WBS dibutuhkan karena pada umumnya dalam sebuah proyek biasanya melibatkan
banyak orang dan deliverables, sehingga sangat penting untuk
mengorganisasikan pekerjaan- pekerjaan tersebut menjadi bagian-bagian yang
lebih terperinci lagi.
4. Melakukan verifikasi ruang lingkup proyek
Tahap ini merupakan tahap dimana final project scope statement diserahkan
kepada
stakeholder untuk diverifikasi.
5. Melakukan kontrol terhadap ruang lingkup proyek
 Dalam pelaksanaan proyek, tidak jarang ruang lingkup proyek mengalami
perubahan. Untuk itu, perlu dilakukannya kontrol terhadap perubahan ruang lingkup
proyek.

Perubahan yang tidak terkendali, akan mengakibatkan meluasnya ruang lingkup

proyek. Seorang manager proyek merupakan seorang professional dalam bidang
manajemen proyek. Manajer proyek memiliki tanggung jawab untuk melakukan
perencanaan, pelaksanaan dan penutupan sebuah proyek yang biasanya berkaitan dengan
bidang industri kontruksi, arsitektur, telekomunikasi dan informasi teknologi. Untuk
menghasilkan kinerja yang baik, sebuah proyek harus dimanage dengan baik oleh
manajer proyek yang berkualitas baik serta memiliki kompetensi yang disyaratkan.
Seorang manajer proyek yang baik harus memiliki kompetensi yang mencakup unsur
ilmu pengetahuan (knowledge), kemampuan (skill) dan sikap (attitude).
Ketiga unsur ini merupakan salah satu faktor penting dalam menentukan
keberhasilan proyek. Sebuah proyek akan dinyatakan berhasil apabila proyek dapat
diselesaikan sesuai dengan waktu, ruang lingkup dan biaya yang telah direncanakan.
Manajer proyek merupakan individu yang paling menentukan keberhasilan / kegalan
proyek. Karena dalam hal ini manajer proyek adalah orang yang memegang peranan
penting dalam mengintegrasikan, mengkoordinasikan semua sumber daya yang dimiliki
dan bertanggung jawab sepenuhnya atas kenberhasilan dalam pencapaian sasaran
proyek. Untuk menjadi manajer proyek yang baik, terdapat 9 ilmu yang harus dikuasai.
Adapun ke sembilan ilmu yang dimaksud antara lain :
1. Manajemen Ruang Lingkup;
2. Manajemen Waktu;
3. Manajemen Biaya;
4. Manajemen Kualitas;
5. Manajemen Sumber Daya Manusia;
6. Manajemen Pengadaan;
7. Manajemen Komunikasi;
8. Manajemen Resiko;
9. Manajemen Integrasi.
Seorang manajer proyek yang baik juga harus mempersiapkan dan melengkapi
kemampuan diri sendiri yang bisa diperoleh melalui kursus manajemen proyek. Adapun
panduan referensi standart internasional yang kerap dipergunakan dalam bidang
manajemen proyek dalam PMBOK ( Project Management Body Of Knowledge ).
Setelah seorang manajer proyek dirasa cukup menguasai bidang pekerjaan yang sedang
dijalani, maka disarankan untuk dapat mengambil sertifikasi manajemen proyek. Mereka
yang berhasil mendapatkan sertifikasi ini akan memperoleh gelar PMP ( Project
Management Professional ) dibelakang namanya sebagai bukti dimilikinya kemampuan
terkait.
 MODEL SISTEM

A. Pengertian Rekayasa Perangkat Lunak

Istilah Rekayasa Perangkat Lunak (RPL) secara umum disepakati sebagai

terjemahan dari istilah Software Engineering. Istilah Software Engineering
dipopulerkan tahun 1968 pada Software Engineering Conference yang
diselenggarakan oleh NATO. Sebagian orang mengartikan RPL hanya sebatas
pada bagaimana membuat program komputer. Padahal ada perbedaan yang
mendasar antara perangkat lunak (software) dan program komputer.

Perangkat lunak adalah seluruh perintah yang digunakan untuk memproses

informasi. Perangkat lunak dapat berupa program atau prosedur. Program adalah
kumpulan perintah yang dimengerti oleh komputer sedangkan prosedur adalah
perintah yang dibutuhkan oleh pengguna dalam memproses informasi (O’Brien,
1999). Pengertian RPL sendiri adalah sebagai berikut:

Suatu di siplin Ilmu yang membahas semua aspek produksi perangkat lunak,
mulai dari tahap awal yaitu analisa kebutuhan pengguna, menentukan spesifikasi
dari kebutuhan pengguna, disain, pengkodean, pengujian sampai memelihara
system setelah di gunakan

Jelaslah bahwa RPL tidak hanya berhubungan dengan cara pembuatan

program komputer. Pernyataan “semua aspek produksi” pada pengertian di atas,
mempunyai arti semua hal yang berhubungan dengan proses produksi seperti
manajemen proyek, penentuan personil, anggaran biaya, metode, jadwal, kualitas
sampai dengan pelatihan pengguna merupakan bagian dari RPL.

B. Tujuan Rekayasa Perangkat Lunak

 Secara umum tujuan RPL tidak berbeda dengan bidang rekayasa yang
lain. Mari kita perhatikan Gambar 1. berikut ini.

Kinerja

Biaya Waktu

Gambar 1. Tujuan RPL

Dari Gambar 1 dapat diartikan bahwa bidang rekayasa akan selalu berusaha
menghasilkan output yang kinerjanya tinggi, biaya rendah dan waktu penyelesaian
yang tepat. Secara lebih khusus kita dapat menyatakan tujuan RPL adalah :

a. Memperoleh biaya produksi perangkat lunak yang rendah.

b. Menghasilkan perangkat lunak yang kinerjanya tinggi, andal dan tepat
waktu
c. Menghasilkan perangkat lunak yang dapat bekerja pada berbagai jenis
Platform.
d.Menghasilkan perangkat lunak yang biaya perawatannya rendah.

C. Ruang Lingkup Rekayasa Perangkat Lunak

 Sesuai definisi yang telah disampaikan sebelumnya, maka ruang lingkup
RPL dapat digambarkan sebagai berikut.

Requiremnnt Software Software

Software Design Construction

Proses Software

Testing
Software

Engineering Software
Software
Maintenance
Quality

Configuration
Tool dan Management
Management
Method

Gambar 2 Ruang Lingkup RPL

 Software requirements berhubungan dengan spesifikasi kebutuhan dan

persyaratan perangkat lunak.
 Software design mencakup proses penentuan arsitektur, komponen,
antarmuka, dan karakteristik lain dari perangkat lunak.
 Software construction berhubungan dengan detil pengembangan perangkat lunak,
termasuk algoritma, pengkodean, pengujian, dan pencarian kesalahan.
  Software testing meliputi pengujian pada keseluruhan perilaku perangkat lunak.
 Software maintenance mencakup upaya-upaya perawatan ketika perangkat lunak
telah dioperasikan.
 Software configuration management berhubungan dengan usaha perubahan
konfigurasi perangkat lunak untuk memenuhi kebutuhan tertentu.
 Software engineering management berkaitan dengan pengelolaan dan
pengukuran RPL, termasuk perencanaan proyek perangkat lunak.
 Software engineering tools and methods mencakup kajian teoritis tentang alat
bantu dan metode RPL.
 Software engineering process berhubungan dengan definisi, implementasi,
pengukuran, pengelolaan, perubahan dan perbaikan proses RPL.
 Software quality menitikberatkan pada kualitas dan daur hidup perangkat lunak.

D. Rekayasa Perangkat Lunak dan Disiplin Ilmu Komputer

Disiplin ilmu computer (Computer Science) lahir pada awal-awal tahun 1940-an
yang merupakan integrasi dari teori algoritma, logika matematika dan ditemukannya
cara penyimpanan program secara elektronik pada komputer.Sejak itu ilmu
komputer mengalami perkembangan yang terus menerus sehingga cakupannya
menjadi semakin meluas.Cakupan pengetahuan dalam ilmu komputer seringkali
didiskripsikan sebagai suatu studi sistematis pada proses-proses algoritma yang
menjelaskan dan mentransformasikan informasi (Denning, 2000). Termasuk di
sini adalah teori, analisis, disain, efisiensi penerapan dan aplikasinya. Ada beberapa
model pengelompokkan sub-bidang ilmu dalam disiplin ilmu komputer seperti
terlihat pada Gambar .
 Komputer

Scince

Section A Section B

Komputer Perangkat

Section C Section D
Orgasisasi Sistem
Perangkat
Komputer

Section E Section F

Data Teori

Section G Section H

Matematika Sistem

Section I
Section J
Metodologi
Komputer di

Section K

Aspek Lain

Gambar 4 Kalsifikasi ilmu Komputer menurut ACM

 Komputer

Scince

Algoritma dan Bahasa

Struktur Data
Pemrograman

Arsitektur Sistem
Operasi
Komputer
Dan

Rekayasa Basis Data dan

perangkat
Lunak Pencarian
Informasi

Intelegensi
Grafis
Buatan
Robotika

Interaksi Ilmu
Peengetahuan
Komputer
Manusia Komputasi

Pengorganisas Bio-
ian Informatics
Informatika

Gambar 4 Kalsifikasi ilmu Komputer menurut Danning

 Komputer

Scince

Dasar Teori
Matematika
Komputasi Komputasi

Algoritma dan Bahasa

Struktur Data Pemrograman
Dan Compiler

Concurrent, Rekayasa
Parallel dan
system
Perangkat
Pendistribusia
Lunak

Komunikasi
Basis Data

Intelegensia Komputer
Garfis dan
Buatan Visual

Berdasarkan pengelompokkan
Interaksi Denning (2000) dan Wikipedia (2007), RPL
Komputasi
merupakan sub-bidang ilmudan
Manusia komputer yang setara untuk dengan
ilmu sub-bidang lainnya
Sedangkan menurut Komputer
ACM (Association for Computing Pengetahuan Machinery), RPL
merupakan bagian dari Section D (Perangkat Lunak). Meskipun terlihat terpisah-
pisah, namun dalam penerapannya, sub-bidang RPL selalu membutuhkan
Gambar 5 Kalsifikasi ilmu Komputer menurut Wikipedia
dukungan dari sub-bidang lain, terutama sub-bidang Algoritma dan Struktur Data,
Bahasa Pemrograman, Basis Data, Sistem Operasi dan Jaringan, dan Sistem
Informasi.
E. Rekayasa Perangkat Lunak dan Disiplin Ilmu Lain

Cakupan ruang lingkup yang cukup luas, membuat RPL sangat terkait dengan
disiplin bidang ilmu lain. Tidak saja dengan sub-bidang dalam disiplin ilmu
komputer namun dengan beberapa disiplin ilmu lain di luar ilmu komputer.
Hubungan keterkaitan RPL dengan ilmu lain dapat dilihat pada Gambar 6.

Manajemen Matematika Orgonomika

Rekayasa
Perangkat Lunak

Manajemen Manajemen Manajemen

Sistem
Kualitas Proyek

Gambar 6 Keterkaitan RPL dengan Bidang Ilmu Lain

  Bidang ilmu manajemen meliputi akutansi, finansial, pemasaran,
manajemen operasi, ekonomi, analisis kuantitatif, manajemen sumber daya
manusia, kebijakan dan strategi bisnis.
 Bidang ilmu matematika meliputi aljabar linier, kalkulus, peluang, statistik,
analisis numerik dan matematika diskrit.
 Bidang ilmu manajemen proyek meliputi semua hal yang berkaitan dengan
proyek, seperti ruang lingkup proyek, anggaran, tenaga kerja, kualitas,
manajemen resiko, dan penjadwalan proyek.
 Bidang ilmu manajemen kualitas meliputi pengembangan sistem kualitas,
manajemen resiko dan keandalan, perbaikan kualitas, dan metode-metode
kuantitatif.
 Bidang ilmu ergonomika menyangkut hubungan (interaksi) antara manusia
dengan komponen-komponen lain dalam sistem komputer.
 Bidang ilmu rekayasa sistem meliputi teori sistem, analisis biaya-
keuntungan, pemodelan, simulasi, proses dan operasi bisnis.

F. Profesi dan Sertifikasi

Profesi sebagai seorang Software Engineering mungkin masih terasa asing

ditelinga orang

Indonesia. Sebagian besar orang Indonesia mungkin lebih familiar dengan sebutan
Ahli Teknologi Informasi, Analis Sistem Informasi, Programmer, Operator atau
sebutan profesi lainnya. Hal ini karena adanya kerancuan tentang istilah RPL seperti
telah disebutkan di awal bab.

Namun di negara-negara yang maju\ dalam bidang teknologi informasi, sebutan

Software Engineer telah mulai banyak digunakan. Sertifikasi kompetensi dalam
bidang RPL, saat ini masih menjadi perdebatan di kalangan ahli dan penyedia
perangkat lunak. Sebagian besar sertifikasi dalam industri perangkat lunak
biasanya sangat spesifik untuk perangkat lunak tertentu. Sebagai contoh,
perusahaan perangkat lunak seperti Redhat Linux Inc., Adobe Inc., Oracle, atau
Microsoft, memberikan sertifikasi. diproduksinya.

ACM (Association for Computing Machinery) pernah menyelenggarakan

sertifikasi untuk program Software Engineer pada tahun 1980an, namun
dihentikan karena kurangnya peminat. IEEE (Institute of Electrical and
Electronics Engineers) telah mengeluarkan lebih dari 500 sertifikat profesi
perangkat lunak. DiCanada, telah dikeluarkan sebuah sertifikat legal untuk RPL
yang disebut sebagai ISP (Information Systems Profesional). Saat ini, sertifikasi
 untuk RPL di Indonesia juga belum tersedia, namun telah disusun Standar
Kompetensi Kerja Nasional Indonesia untuk Bidang Programmer Komputer.
Meskipun belum memenuhi cakupan bidang RPL secara keseluruhan, namun
paling tidak dapat digunakan sebagai pendekatan sertifikasi bidang RPL.

G. Rekayasa Perangkat Lunak dan Pemmecahan Masalah

Secara konsep, rekayasa perangkat lunak memiliki kedekatan dengan prinsi

prinsip pemecahan masalah. Pemahaman tentang masalah, strategi dan proses
pemecahan masalah, serta pendekatan sistem pada pemecahan masalah akan sangat
membantu proses rekayasa perangkat lunak.

1. Masalah dan Gejala

Masalah (problem) adalah perbedaan antara kondisi yang terjadi dan kondisi
yang diharapkan atau boleh juga diartikan sebagai perbedaan antara kondisi
sekarang dengan tujuan yang diinginkan. Sebagai contoh seorang siswa berharap
memperoleh nilai di atas 80 untuk ujian mata pelajaran Pemrograman
C++, namun pada kenyataannya dia hanya memperoleh nilai 60. Adanya
perbedaan menunjukkan adanya masalah. antara gejala dan masalah. Gejala
adalah tanda/petunjuk terjadinya suatu masalah. Perhatikan seorang yang
berprofesi sebagai Seorang dokter dalam usaha mengobati penyakit pasien
selalu bertanya dulu tentang gejala-gejala yang dirasakan pasien
kemudian menyimpulkan bahwa pasien menderita penyakit tertentu dan
menentukan obat yang tepat. Pusing, demam, batuk, dan pilek merupakan
gejala atau tanda dari penyakit flu. Apabila dokter hanya memberi obat sakit
kepala, maka penyakit flu tidak

Gambar 7 Gejala dan Masalah

 Mungkin kita bertanya-tanya apa hubungan masalah dan gejala dengan RPL.
Seperti telah disampaikan di awal bab, perangkat lunak yang merupakan hasil dari
RPL merupakan alat bantu yang digunakan untuk menyelesaikan tugas / masalah
tertentu. Apabila kita tidak mengetahui dengan benar masalahnya mustahil kita
dapat menentukan bagaimana menyelesaikannya. Dan, untuk mengetahui dengan
baik masalah, maka pengetahuan tentang gejala dari masalah menjadi sangat
penting.

2. Tipe-Tipe Masalah

Gambar 8 Type-type masalah

 Masalah pemenuhan standar

Tipe masalah dalam kelompok ini adalah masalah-masalah yang berhubungan
dengan pencapaian standar yang telah ditentukan dalam sebuah organisasi.
Biasanya tujuan seperti ini berlaku dalam jangka yang relative panjang.

 Masalah pemilihan alternative

Masalah dalam kelompok ini berhubungan dengan bagaimana memilih solusi
terbaik dari berbagai alternative berdasarkan kriteria-kriteria tertentu.
Permasalahan ini seringkali kita jumpai dalam kehidupan sehari-hari, seperti
bagaimana memilih sekolah yang tepat, memilih lokasi tempat tinggal,
memilih bidang pekerjaan. Masing-masing alternatif dan kriteria memiliki
bobot yang telah disepakati.
 Masalah pemenuhan kepuasan konsumen
Pada organisasi-organisasi yang bersifat profit (mencari keuntungan), masalah-
masalah pada kelompok ini merupakan tipe yang seringkali muncul.
Konsumen memiliki berbagai macam keinginan yang satu sama lain berbeda.
Memenuhi seluruh keinginan konsumen sangat tidak mungkin dan sangat
memberatkan sebuah organisasi. Oleh karena itu perlu dicari pemecahan yang
sama-sama menguntungkan, baik bagi konsumen maupun organisasi tersebut.

 Masalah pencpaian tujuan

Tipe ini mirip dengan tipe pertama (masalah pemenuhan standar). Yang

berbeda adalah, pada tipe ini tujuan yang ingin dicapai dapat berubah- ubah dan

bersifat jangka pendek.

3. Pemecahan Masalah

Pemecahan masalah adalah sebuah proses dimana suatu situasi diamati kemudian
bila ditemukan ada masalah dibuat penyelesaiannya dengan cara menentukan
masalah, mengurangi atau menghilangkan masalah atau mencegah masalah
tersebut terjadi. Ada banyak urutan proses pemecahan masalah yang diajukan oleh
para ahli, salah satunya seperti terlihat pada Gambar 9.
 Gambar 9 Proses Pemecahan Masalah

Pada gambar 9 terlihat serangkaian tahapan proses yang berbeda yang dapat
digunakan dalam berbagai tingkatan, tergantung dari tipe dan sifat
masalahnya. Masalah yang berbeda membutuhkan penggunaan cara yang
berbeda, bahkan mungkin urutan yang berbeda. Tahapan kritis dari proses
pemecahan masalah adalah

Pendefinisian Masalah. Apabila masalah tidak cukup jelas didefinisikan maka

tahapan-tahapan berikut sulit untuk dijalankan. Bahkan apabila dipaksakan,
kemungkinan besar penyelesaian yang tepat tidak akan diperoleh.

Secara umum proses pemecahan masalah dapat dilakukan dengan empat

tahapan utama yaitu :

 Memahami dan mendefinisikan masalah

Bagian ini merupakan bagian yang sangat penting karena menjadi awal dari
seluruh proses pemecahan masalah. Tujuan pada bagian ini adalah
memahami masalah dengan baik dan menghilangkan bagian-bagian yang dirasa
kurang penting.

 Membuat rencana untuk pemecahan masalah

Pada bagian ini ada dua kegiatan penting yaitu :

a) mencari berbagai cara penyelesaian yang mungkin diterapkan b) membuat

rencana pemecahan masalah

Penyelesaian suatu masalah biasanya tidak hanya satu tapi mungkin bisa
beberapa macam. Sebagai ilustrasi, apabila kita berada di kota Surabaya dan
ingin pergi ke Jakarta, maka banyak cara yang mungkin bisa dilakukan,
 misalnya kita bisa menempuh dengan angkutan darat, laut atau udara. Dengan
angkutan darat kita bisa menggunakan kereta api, bus atau angkutan yang
lain. Jalurnya pun kita bisa lewat jalur utara, tengah atau selatan. Jadi banyak
sekali cara penyelesaian yang bisa kita kembangkan. Masing-masing
mempunyai karakteristik sendiri-sendiri. Dari sekian banyak penyelesaian ini
kita harus memilih satu yang berdasarkan persyaratan tertentu merupakan
cara yang paling baik untuk menyelesaikan permasalahan. Setelah
terpilih, maka kita dapat membuat rencana kasar

(outline) penyelesaian masalah dan membagi masalah dalam bagian-bagian

yang lebih kecil. Rencana kasar (outline) penyelesaian masalah hanya berisi
tahapan-tahapan utama penyelesaian masalah.

 Merancang dan menerapkan rencana untuk memperoleh cara penyelesaian

Pada bagian ini rencana kasar penyelesaian masalah diperbaiki dan

diperjelas dengan pembagian dan urutan rinci yang harus ditempuh dalam

penyelesaian masalah

 Memeriksa dan menyampaikan hasil dari pemecahan masalah

Bagian ini bertujuan untuk memeriksa apakah akurasi (ketepatan) hasil dari

cara yang dipilih telah memenuhi tujuan yang diinginkan. Selain itu juga

untuk melihat bagaimana daya guna dari cara yang dipilih yang dipilih.
 METODE REKAYASA PERANGKAT LUNAK

Ketika kita bekerja dengan komputer seperti pada kita

membutuhkan serangkaian tahapan dan cara-cara tertentu agar dapat menghasilkan
sesuatu yang menjadi harapan kita. Demikian juga dalam rekayasa
perangkat

lunak, diperlukan tahapan-tahapan kerja yang harus dilalui. Rekayasa perangkat

lunak yang sukses tidak hanya membutuhk kemampuan komputasi seperti algoritma,
pemrograman, dan basis data yang kuat, namun juga perlu penentuan tujuan
yang baik, identifikasi cara penyelesaian, metode pengembangan, urutan aktifitas,
identifikasi kebutuhan sumberdaya, dan faktor-faktor lain.

Hal-hal seperti ini terkait dengan apa yang disebut dengan metode rekayasa perangkat
lunak. Isi dari bab ini tidak termasuk dalam standar kompetensi bidang keahlian RPL.
Namun penulis memandang perlu disampaikan agar kalian dapat mengetahui
bagaimana sebenarnya rekayasa perangkat lunak dilakukan dan metode-metode apa saja
yang biasa digunakan. Beberapa bagian dari bab ini mungkin agak sulit dipahami,
sehingga peran guru dalam membantu menjelaskan akan sangat diperlukan.

Setelah mempelajari Rekayasa Perangkat Lunak ini diharapkan mampu :

1. Memahami karakteristik umum model proses dalam rekayasa perangkat Lunak

2. Menyebutkan beberapa model rekayasa perangkat lunak
3. Mengetahui Prinsip-prinsip dari metode waterfall, prototyping, dan univied process.
4. Memahami Tahapan-tahapan dalam rekayasa Perangkat Lunak.

A. Model Rekayasa Perangkat Lunak

Pada rekayasa perangkat lunak, banyak model yang telah dikembangkan untuk
membantu proses pengembangan perangkat lunak. Model-model ini pada umumnya

mengacu pada model proses pengembangan sistem yang disebut System Development
Life Cycle (SDLC) seperti terlihat pada Gambar 10.
 Gambar 10 Sistem Development Life Cycle

Setiap model yang dikembangkan mempunyai karakteristik sendiri- sendiri.

Namun secara umum ada persamaan dari model-model ini, yaitu:

 Kebutuhan terhadap definisi masalah yang jelas. Input utama dari setiap model
pengembangan perangkat lunak adalah pendefinisian masalah yang jelas. Semakin
jelas akan semakin baik karena akan memudahkan dalam penyelesaian masalah.
Oleh karena itu pemahaman masalah seperti dijelaskan pada Bab 1,
merupakan bagian penting dari model pengembangan perangkat lunak.
 Tahapan-tahapan pengembangan yang teratur. Meskipun model-model
pengembangan perangkat lunak memiliki pola yang berbeda-beda, biasanya model-
model tersebut mengikuti pola umum analysis – design – coding – testing -
maintenance.
 Stakeholder berperan sangat penting dalam keseluruhan tahapan
pengembangan. Stakeholder dalam rekayasa perangkat lunak dapat berupa
pengguna pemilik, pengembang, pemrogram dan orang-orang yang terlibat dalam
rekayasa perangkat lunak tersebut.

 Dokumentasi merupakan bagian penting dari pengembangan perangka lunak.

Masing-masing tahapan dalam model biasanya menghasilkan sejumlah tulisan,
diagram, gambar atau bentuk-bentuk lain yang harus didokumentasi dan merupakan
bagian tak terpisahkan dari perangkat lunak yang dihasilkan.

 Keluaran dari proses pengembangan perangkat lunak harus bernilah ekonomis.

Nilai dari sebuah perangkat lunak sebenarnya agak susah di- rupiah-kan Namun
efek dari penggunaan perangkat lunak yang telah dikembangkan haruslah memberi
nilai tambah bagi organisasi. Hal ini dapat berupa penurunan biaya operasi,
 efisiensi penggunaan sumberdaya, peningkatan keuntungan organisasi,
peningkatan “image” organisasi dan lain-lain

Ada banyak model pengembangan perangkat lunak, antara lain

The Waterfall Model, Joint Application Development (JAD), Information Engineering

(IE), Rapid Application Development (RAD), Prototyping, Unified Process (UP),
Structural Analysis and Design (SAD) d Framework for the Application of System
thinking (FAST) The Waterfall Model, Prototyping, Unified Process (UP).

1. The waterfall model

Model siklus hidup (life cycle model) adalah model utama dan dasar dari banyak

model. Salah satu model yang cukup dikenal dalam dunia rekayasa perangkat lunak
adalah The Waterfall Model. Ada 5 tahapan utama dalam The Waterfall Model
seperti terlihat pada Gambar 2.3. di sebut Waterfall ( berarti Air Terjun) memang
diagram tahapan prosesnya mirip dengan air terjun yang bertingkat. Tahapan-
tahapan dalam The Waterfall Model secara ringkas adalah sebagai berikut :

a) Tahap investigasi dilakukan untuk menentukan apakah terjadi suatu masalah

atau adakah peluang suatu sistem informasi dikembangkan. Pada tahapan ini
studi kelayakan perlu dilakukan untuk menentukan apakah sistem informasi
yang akan dikembangkan merupakan solusi yang layak
b) Tahap analisis bertujuan untuk mencari kebutuhan pengguna dan organisasi serta
menganalisa kondisi yang ada (sebelum diterapkan sistem informasi yang baru).

c) Tahap disain bertujuan menentukan spesifikasi detil dari komponen-

komponen sistem informasi (manusia, hardware, software, network dan data)
dan produk-produk informasi yang sesuai dengan hasil tahap analisis.
d) Tahap implementasi merupakan tahapan untuk mendapatkan atau
mengembangkan hardware dan software (pengkodean program),
melakukan pengujian, pelatihan dan perpindahan ke sistem baru.
e) Tahapan perawatan (maintenance) dilakukan ketika sistem informasi sudah
dioperasikan. Pada tahapan ini dilakukan monitoring proses, evaluasi dan
perubahan (perbaikan) bila diperlukan.
 Gambar 11 The Waterfall Model

2. Prototyping model

Prototyping adalah salah satu pendekatan dalam rekayasa perangkat lunak yang
secara langsung mendemonstrasikan bagaimana sebuah perangkat lunak atau
komponen-komponen perangkat lunak akan bekerja dalam lingkungannya
sebelum tahapan konstruksi aktual dilakukan (Howard, 1997). Prototyping model
dapat diklasifikasikan menjadi beberapa tipe seperti terlihat pada gambar 12
 Gambar 12. Klasifikasi prototyping model (Harris, 2003)

 Reusable prototype :
Prototype yang akan ditransformasikan menjadi produk final.

 Throwaway prototype :
Prototype yang akan dibuang begitu selesai menjalankan maksudnya.

 Input/output prototype :
Prototype yang terbatas pada antar muka pengguna (user interface).

 Processing prototype :
Prototype yang meliputi perawatan file dasar dan proses-proses transaksi.

 System prototype :
Prototype yang berupa model lengkap dari perangkat lunak.

Tahap-tahap dalam prototyping boleh dikata merupakan tahap-tahap yang dipercepat.

Strategi utama dalam prototyping adalah kerjakan yang mudah terlebih dahulu dan
sampaikan hasil kepada pengguna sesegera mungkin. Harris (2003) membagi
prototyping dalam enam tahapan seperti terlihat pada gambar 13.
Tahapan-tahapan secara ringkas dapat dijelaskan sebagai berikut:

 Identifikasi kandidat prototyping. Kandidat dalam kasus ini meliputi user

interface (menu, dialog, input dan output), file-file transaksi utama, dan fungsi-
fungsi pemrosesan sederhana.
 Rancang bangun prototype dengan bantuan software seperti word
processor, spreadsheet, database, pengolah grafik, dan software CASE
(Computer-Aided System Engineering).

 Uji prototype untuk memastikan prototype dapat dengan mudah dijalankan untuk
tujuan demonstrasi.
 Siapkan prototype USD (User’s System Diagram) untuk mengidentifikasi
bagian-bagian dari perangkat lunak yang di-prototype-kan.
 Evaluasi dengan pengguna untuk mengevaluasi prototype dan melakukan
perubahan jika diperlukan.
 Transformasikan prototype menjadi perangkat lunak yang beroperasi penuh
dengan melakukan penghilangan kode-kode yang tidak dibutuhkan,
penambahan program-program yang memang dibutuhkan dan perbaikan dan
pengujian perangkat lunak secara berulang.
 Gambar 13. Tahapan-tahapan prototyping model (Harris, 2003)

3. Unified Proces dan Unified Modeling Languange

Unified Process (UP) atau kadang disebut sebagai Unified Software Development
Process (USDP) adalah kerangka proses pengembangan yang bersifat use-case-
driven, berpusat pada arsitektur perangkat lunak, interatif dan tumbuh-kembang (Alhir,
2005).

Kerangka pengembangan ini termasuk baru dalam metodologi pengembangan

perangkat lunak. UP dapat diaplikasikan pada berbagai skala proyek, mulai dari skala
kecil sampai dengan skala besar.
Daur hidup UP secara umum akan tampak seperti pada bagan di Gambar

Bagan ini biasa disebut sebagai “hump chart”. Pada bagan ini terlihat ada empat
tahap peengembangan yaitu inception, elaboration, construction, dan transition Selain
itu tampak pula sejumlah aktifitas yang harus dilakukan sepanjang pengembangan
perangkat lunak, yaitu business, modeling, requirements, analisys and design.
Impelemntasi, test. Tahap dan aktifitas tersebut akan dilakukan secara iteratiff (
Ambler, 2005).

Gambar 14 RUP Life Cycle (Ambler, 2005)

Penjelasan singkat untuk empat tahapan dalam UP adalah sebagai berikut :

  Inception tahapan ini merupakan tahapan paling awal dimana aktivitas
penilaian terhadap sebuah proyek perangkat lunak dilakukan. Tujuannya
adalah untuk mendapatkan kesepakatan dari stakeholder sehubungan dengan
tujuan dan dana proyek..

 Elaboration. Tujuan dari tahap ini adalah untuk mendapatkan gambaran

umum kebutuhan, persyaratan dan fungsi-fungsi utama perangkat lunak. Hal ini
penting untuk mengetahui secara lebih baik resiko-resiko proyek, baik meliputi
resiko arsitektur perangkat lunak, perencanaan, maupun implementasi. Pada
tahap ini telah dimulai rancang bangun perangkat lunak secara iterative
melalui aktivitas-aktivitas seperti business modeling, requirements, analysis
dan design meskipun baru pada tahap awal.

 Construction. Tujuan dari tahapan ini adalah membangun perangkat lunak

sampai dengan saat perangkat lunak tersebut siap digunakan. Titik berat
tahapan ini adalah pada penentuan tingkat prioritas kebutuhan / persyaratan,
melengkapi spesifikasinya, analisis lebih dalam, disain solusi yang memenuhi
kebutuhan dan persyaratan, pengkodean dan pengujian perangkat lunak. Jika
dimungkinkan versi awal dari perangkat lunak diuji cobakan untuk
mendapatkan masukan dari pengguna.
 Transition. Tahap ini difokuskan pada bagaimana menyampaikan
perangkat lunak yang sudah jadi pada pengguna. Perangkat lunak akan secara
resmi diuji oleh baik oleh penguji (tester) yang kompeten maupun oleh
pengguna. Beberapa aktivitas seperti pemindahan pusat data dan pelatihan
pengguna dan staf pendukung harus dilakukan pada tahap ini.

Dalam pengembangan perangkat lunak dengan menggunakan UP, makatidak lepas

dari penggunaan notasi-notasi yang biasa disebut sebagai UML ( Unifie Modeling
Languange) Meskipun UP mensyaratkan penggunaan UML, namun UML sendiri
dapat digunakan pada berbagai metodologi yang lain bahkan dapat digunakan pada
bidang selain sistem informasi. UML adalah bahan pemodelan standar atau
kumpulan teknik-teknik pemodelan untuk men- spesifikasi, mem-visualisasi, meng-
konstruksi dan mendokumentasi hasil kerja dalam pengembangan perangkat lunak
(Fowler, 2004). UML lahir dari penggabungan banyak bahasa pemodelan grafis
berorientasi obyek yang berkembang pesat pada akhir tahun 1980an dan awal 1990an.

Secara sederhana UML digunakan untuk menggambar sketsa sistem. Pengembang

menggunakan UML untuk menyampaikan beberapa aspek dari sebuah perangkat
lunak melalui notasi grafis. UML mendefinisikan notasi dan semantik. Notasi
merupakan sekumpulan bentuk khusus yang memiliki makna tertentu untuk

menggambarkan berbagai diagram piranti lunak dan semantik mendefinisikan

bagaimana bentuk-bentuk tersebut dapat dikombinasikan. Ada beberapa jenis diagram
yang disediakan dalam UML, antara lain adalah:

 Use-case diagram. Diagram ini berguna untuk menggambarkan interaksi antara

pengguna dengan sebuah perangkat lunak
 Activity diagram. Diagram ini berguna untuk menggambarkan prosedur
prosedur perilaku perangkat lunak.
 Class diagram. Diagram ini berguna untuk menggambarkan class, fitur, dan
hubungan-hubungan yang terjadi. Pada diagram ini pendekatan berorientasi
obyek memegang peranan yang sangat penting.
 Sequence diagram. Diagram ini berguna untuk menggambarkan interaksi
antar obyek dengan penekanan pada urutan proses atau kejadian.
 State machine diagram. Diagram ini digunakan untuk menggambarkan
bagaimana suatu kejadian mengubah obyek selama masa hidup obyek tersebut.
 Component diagram. Diagram ini berguna untuk menggambarkan struktur
dan koneksi komponen.

B. Tahap-tahap Rekayasa Perangkat Lunak

Seperti telah disebutkan, meskipun dalam pendekatan berbeda-beda, namun

model-model di atas memiliki kesamaan, yaitu menggunakan pola tahapa analysis –
design – coding(construction) – testing – maintenance.

.1. Analisis

Analisis sistem adalah sebuah teknik pemecahan masalah yang menguraikan

sebuah sistem menjadi komponen-komponennya dengan tujuan mempelajari

seberapa bagus komponen-komponen tersebut bekerja dan berinteraksi untuk
meraih tujuan mereka.

Analisis mungkin adalah bagian terpenting dari proses rekayasa perangkat lunak.
Karena semua proses lanjutan akan sangat bergantung pada baik tidaknya hasil
analisis. Tahapan-tahapan dalam analisis rekayasa perangkat lunak secara ringkas
dapat dilihat pada Gambar 15.

Ada satu bagian penting yang biasanya dilakukan dalam tahapan analisis yaitu

Pemodelan proses bisnis. Model proses adalah model yang memfokuskan

pada seluruh proses di dalam sistem yang mentransformasikan data menjadi
informasi (Harris, 2003). Model proses juga menunjukkan aliran data yang masuk
dan keluaran pada suatu proses. Biasanya model ini digambarkan dalam bentu
Diagram Arus Data (Data Flow Diagram / DFD). DFD meyajikan gambaran apa
yang manusia, proses dan prosedur lakukan untuk mentransformasi data menjadi
informasi.
Gambar 15 Tahapan dan aktifitas dalam analisis.
Umumnya ada empat notasi yang sering digunakan dalam DFD seperti tampak Gambar

External Entity melambangkan sumber daya ( dari mana data

berasa) atau Penerima Informasi ( Tujuan ahir dari data) Contoh
external Entity antara lain konsumen yang memesan suatu
produk, manajer yang mengevaluasi laporan penjualan
External Entity
mingguan, dan lain-lain.

Proses adalah serangkaian langkah yang dilakukan untuk

memanipulasi data, misalnya pengumpulan, pengurutan,
pemilihan, pelaporan, peringkasan,analisis, dan lain-lain.

Process

Data Store adalah untuk menyimpan data untuk digunakan

kemudian. Nama yang ada pada data store iniMerupakan
Abstraksidari data yang di simpan. Namun detil etim data apa
Data Store saja yang ada, bagaimana cara akses, atau bagaimana
mengorganisasinya tidak dijelaskan dalam notasi ini

Data Flow menunjukkan aliran data dari suatu tempat ke tempat

lain. Perpindahan data ini dapat dari external entity ke proses ke
Data Flow data store. Dalam penggambaranya setiap data flow harus diberi
lebel yang menunjukkan data apa yang mengalir.

Gambar 16 Notasi pada DFD

Dalam pembuatan DFD ada beberapa tahapan yang dilakukan secara berurutan
Gambar 17 menunjukkan urutan tahapan tersebut

Gambar 17 tahapan pembuatan DFD

Context diagram adalah DFD ruang lingkup dari sistem yang menunjukkan batas-
batas sistem, external entitiy yang berinteraksi dengan sistem dan aliran data utama antara
external entity dengan sistem. Context diagram menggambarkan keseluruhan sistem dalam
suatu proses tunggal. Gambar 2.10 menunjukkansebuah contoh context diagram.

Gambar 18 Context diagram sistem pemesanan makanan (Hoffer et al.,2002).

Selanjutnya adalah merinci kontek diagram tersebut ke DFD level 0. DFD Level 0 adalah DFD
yang mempresentasikan proses-proses, data flow dan data storage utama dalam sistem. DFD
level 0 ini akan digunakan sebagai dasar untuk membangun DFD yang level bawahnya (level1,
2, 3, ....dst). Di bawah 19 ini gambar DFD level 0
Gambar 19 DFD level 0