REKAYASA PERANGKAT LUNAK

( RPL )

NAMA : STEFANUS FREDTON MOLLE

NPM : 12155201210101

PRODI : INFORMATIKA

UNIVERSITAS KRISTEN INDONESIA MALUKU

2022
A. Pengenalan Rekayasa Perangkat Lunak
Rekayasa Perangkat Lunak atau biasa disingkat dengan RPL adalah salah satu bidang profesi dan juga
mata pelajaran yang mempelajari tentang pengembangan perangkat-perangkat lunak termasuk dalam hal
pembuatannya, pemeliharaan hingga manajemen organisasi dan manajemen kualitasnya. Bisa dikatakan
RPL ini merupakan sebuah perubahan yang terjadi pada perangkat lunak guna melakukan pengembangan,
pemeliharaan, dan pembangunan kembali dengan menerapkan prinsip rekayasa sehingga memperoleh
perangkat lunak yang bisa bekerja secara lebih efisien dan efektif pada user nantinya.
Perangkat lunak sendiri merupakan sekumpulan data yang tersimpan dan terprogram oleh sistem
komputer, istilah ini cukup umum dengan sebutan software. Merupakan elemen dari komputer, software
menjadi elemen yang tidak tampak secara fisik. Ia berisi instruksi-instruksi yang diprogram dan bisa
berada di perangkat keras manapun, software pada mulanya adalah sebuah kode mesin atau machine code
yang dibuat oleh seorang ilmuwan. Berisi angka-angka biner yang dapat dikenali oleh komputer,
terkhusus prosesor. Software bekerja dengan membuat instruksi tertentu dalam melakukan perhitungan,
logika, input-output, dan aritmatika pada prosesor.
Di Indonesia RPL sudah dipelajari sejak tingkat Sekolah Menengah Kejuruan hingga ke perguruan tinggi,
di tingkat SMK terdapat jurusan tersendiri untuk mempelajari dan menerapkan rekayasa perangkat lunak.
Sedangkan pada perguruan tinggi biasanya terdapat pada jurusan yang terkait dan perl untuk memahami
RPL seperti pada jurusan komputer. Materi-materi yang dipelajari biasanya seperti bahasa pemrograman,
desain web, pengetahuan terkait Undang-Undang ITE dan HAKI, namun tergantung kepada sekolah dan
kurikulum pada tiap tahunnya.

Pengertian Rekayasa Perangkat Lunak menurut Parah ahli

Beberapa ahli memberikan penjelasan yang sedikit berbeda satu dengan lainnya, teori ini jugalah yang
digunakan oleh dunia pendidikan untuk diberikan sebagai pemahaman kepada pelajarnya.
Stephen R.Schach
RPL adalah sebuah disiplin ilmu yang mana dibuat untuk kepentingan menghasilkan perangkat lunak
yang bebas dari kesalahan, pengiriman yang tepat waktu, dan memuaskan keinginan pemakainya.
Fritz Bauer
Ia mengartikan RPL sebagai pengembangan dan penggunaan prinsip rekayasa dalam rangka memperoleh
perangkat lunak yang bisa dipercaya dan bekerja secara efisien dan dilakukan pada mesin nyata.
Institute of Electrical and Electronics Engineers 610.12
Sedangkan menurut IEEE, adalah sebuah studi dan aplikasi dengan menggunakan pendekatan yang
bersifat kuantifiabel, disiplin, dan sistematis kepada pengembangnya, memiliki operasi dan pemeliharaan
perangkat lunak yang merupakan aplikasi.
Tujuan dan Penerapan Rekayasa Perangkat Lunak
Mempelajari ilmu RPL ini dianggap perlu karena pada dasarnya memungkinkan Anda untuk membangun
sistem yang lebih kompleks, efektif serta efisien dalam jangka waktu yang panjang dan tentu saja harus
memiliki kualitas yang tinggi. Sehingga tujuan dari rekayasa perangkat lunak ini adalah berikut.

Mengembangkan Perangkat Lunak

Mengembangkan perangkat lunak yang bisa berfungsi dan berguna bagi penggunanya menjadi tujuan
utama dari seseorang mempelajari RPL, tentunya perangkat lunak harus memiliki fungsi dan kegunaan
yang spesifik agar bisa digunakan oleh penggunanya.

Menciptakan User Friendly

Perangkat lunak yang user friendly setidaknya memiliki tampilan yang menarik, fungsional serta mudah
untuk digunakan, pemahaman lebih tentu dimiliki oleh orang yang mempelajari rekayasa perangkat
lunak. Sehingga ia bisa menggunakan ilmunya untuk memperbaiki, mengembang, dan menciptakan
perangkat lunak yang user friendly tersebut.

Meng-integrasi Peralatan Mekanikal

Beberapa peralatan mekanikal yang ada biasanya memerlukan integrasi dengan perangkat lunak, agar
sistemnya dapat bekerja dengan lebih optimal. Sebuah peralatan yang membutuhkan integrasi dengan
perangkat lunak bisa menjadi sebuah masalah, namun mereka yang mempelajarinya tentu bisa
menyelesaikan masalah tersebut. Dengan begitu, kegiatan operasionalnya mendukung untuk penggunaan
alat tersebut.

Melakukan Perawatan
Mempelajari RPL tidak membuat Anda terpaku dengan pembuatan dan pengembangan sistem perangkat
lunak yang ada, tetapi juga pada perawatan atau maintenance perangkat lunak yang ada. Perawatan
dibutuhkan jika perangkat lunak tersebut mengalami kendala atau gangguan, agar sistem tetap bagus
maka diperlukannya perawatan berkala.

Secara khusus, tujuan mempelajari rekayasa perangkat lunak adalah biaya produksi dan perawatan
perangkat lunak yang lebih rendah, menghasilkan perangkat lunak yang yang mampu bekerja pada semua
jenis platform dengan baik, serta mampu menghasilkan perangkat lunak yang kinerjanya handal dan tepat
waktu. Rekayasa Perangkat Lunak atau RPL ini bisa diterapkan dalam kehidupan sehari-hari maupun
dalam sebuah perusahaan, seperti pembuatan aplikasi yang mampu mencatat data kecelakaan, aplikasi
pembuatan kamera untuk driver dan lain sebagainya.
B. Konsep Pemodelan Rekayasa Perangkat Lunak

Konsep pemodelan perangkat lunak adalah suatu konsep dari berbagai proses atau metodologi yang
dipilih untuk pengembangan objek tergantung pada maksud dan tujuan objek.

Ada banyak model siklus pengembangan yang telah dikembangkan untuk mencapai berbagai tujuan yang
diperlukan.

Konsep pemodelan menentukan berbagai tahapan proses dan urutan pelaksanaannya.

Pemodelan memiliki dampak yang sangat tinggi pada pengujian yang dilakukan. Ini akan menentukan
apa, di mana dan kapan pengujian kami yang direncanakan, mempengaruhi pengujian regresi dan
sebagian besar menentukan teknik pengujian mana yang akan digunakan.

Ada beberapa konsep pemodelan perangkat lunak yang biasa digunakan para developer, berikut
ulasannya:

 Waterfall model
 V model
 Incremental model
 RAD model
 Agile model
 Iterative model
 Spiral model
 Prototype model

Memilih konsep pemodelan perangkat lunak yang tepat untuk pengembangan produk atau aplikasi
perangkat lunak sangat penting.

Berdasarkan model proses pengembangan dan pengujian dilakukan.

Mereka memilih jenis konsep pemodelan perangkat lunak yang sesuai dengan aplikasi mereka.

Tapi akhir-akhir ini di pasar Agile model adalah model yang paling banyak digunakan.

Waterfall model merupakan model yang sudah lama ada. Dalam pengujian Waterfall model dimulai
hanya setelah pengembangan selesai. Karena itu ada banyak cacat dan kegagalan yang dilaporkan pada
akhirnya.

Jadi, biaya untuk memperbaiki masalah ini sangat tinggi. Oleh karena itu, sekarang ini orang lebih
memilih Agile Model.

Pada Agile Model, setelah setiap sprint ada fitur yang dapat didemonstrasikan kepada pelanggan.

Karenanya pelanggan dapat melihat fitur-fiturnya apakah mereka memuaskan kebutuhan mereka atau
tidak. Sedangkan V model juga digunakan oleh banyak perusahaan dalam produk mereka.

V model tidak lain adalah model ‘Verifikasi’ dan ‘Validasi’. Dalam V model siklus hidup pengembang
dan siklus hidup tester dipetakan satu sama lain.
Dalam pengujian model ini dilakukan berdampingan pengembangan.

Konsep Pemodelan Perangkat Lunak

1. Waterfall Model

Waterfall Model adalah konsep pemodelan perangkat lunak pertama yang diperkenalkan. Ini juga disebut
sebagai model siklus hidup sekuensial linier.Model ini mudah dipahami dan digunakan.

Dalam waterfall model, setiap fase harus diselesaikan sepenuhnya sebelum fase berikutnya dapat dimulai.
Model pengembangan perangkat lunak jenis ini pada dasarnya digunakan untuk projek kecil.

Pada akhir setiap fase, tinjauan dilakukan untuk menentukan apakah projek berada di jalur yang benar
dan apakah akan melanjutkan atau tidak.

2. Incremental Model

Selanjutnya adalah incremental model yang merupakan konsep model pengembangan sistem pada
perangkat lunak sesuai requirement software yang dibagi menjadi beberapa bagian, sehingga
pengembangannya dilakukan secara bertahap.

Model ini bisa dikatakan sebagai perbaikan waterfall model dan mempunyai tahapan-tahapan dalam
perancangan perangkat lunak atau software. Inilah tahapan-tahapannya:

 Requirement, proses tahap awal dari incremental model yang merupakan analisis atau penentuan
kebutuhan. 
 Spesification, proses spesifikasi yang mengacu pada analisis kebutuhan. 
 Architecture design, tahap ini adalah perancangan software yang terbuka sehingga dapat
digunakan pada sistem pembangunan per bagian di tahap berikutnya.
 Code, merupakan proses pengkodean. 
  Tes adalah tahap uji coba model ini.

3. V Model

V model berarti model Verifikasi dan Validasi. Sama seperti waterfall model, siklus V model adalah jalur
berurutan dari eksekusi proses.

Setiap fase harus diselesaikan dulu sebelum fase berikutnya dimulai. VModel adalah salah satu dari
banyak konsep pemodelan perangkat lunak.Pengujian produk direncanakan secara paralel dengan fase
pengembangan yang sesuai dalam v model.

4. Agile Model

Konsep pemodelan perangkat lunak Agile juga merupakan jenis model Incremental. Perangkat lunak
dikembangkan dengan siklus cepat dan bertahap. Sehingga, menghasilkan rilis tambahan kecil dengan
setiap rilis rilis pada fungsionalitas sebelumnya.

Setiap rilis diuji secara menyeluruh untuk memastikan kualitas perangkat lunak tetap terjaga. Ini
digunakan untuk aplikasi waktu kritis. Extreme Programming (XP) saat ini adalah salah satu model siklus
hidup pengembangan tangkas yang paling terkenal.

5. Spiral Model

Model spiral mirip dengan model incremental, dengan lebih banyak penekanan pada analisis risiko.
Model spiral memiliki empat fase: Perencanaan, Analisis Risiko, Teknik dan Evaluasi.
Suatu proyek perangkat lunak berulang kali melewati fase-fase ini dalam iterasi (disebut Spiral dalam
model ini).

Spiral baseline, dimulai pada tahap perencanaan, persyaratan dikumpulkan dan risiko dinilai. Setiap spiral
berikutnya dibangun di atas spiral dasar. Ini salah satu model pengembangan perangkat lunak seperti
Waterfall, Agile, V-Model.

6. Prototype Model

Ide dasar dalam model Prototype dikembangkan berdasarkan persyaratan yang diketahui saat ini.

Model prototipe adalah model pengembangan perangkat lunak yang membuat klien mendapatkan “rasa
yang sebenarnya” dari sistem, karena interaksi dengan prototipe dapat memungkinkan klien untuk lebih
memahami persyaratan sistem yang diinginkan.

Prototyping adalah ide yang menarik untuk sistem yang rumit dan besar yang tidak ada proses manual
atau sistem yang ada untuk membantu menentukan persyaratan.

7. Iterative Model

Iterative model merupakan konsep pemodelan perangkat lunak yang dimulai dengan menentukan dan
mengimplementasikan hanya sebagian dari perangkat lunak, yang kemudian dapat ditinjau untuk
mengidentifikasi persyaratan lebih lanjut.

Proses ini kemudian diulangi, menghasilkan versi baru dari perangkat lunak untuk setiap siklus model.
C. Prinsip Praktik
Menjadi insinyur perangkat lunak yang baik bukan hanya tentang pengkodean, ini tentang memecahkan
masalah dengan cara yang paling efektif dan efisien. Ini dapat dicapai melalui algoritma, pengujian unit,
dan analisis kompleksitas ruang-waktu. Ada juga serangkaian prinsip yang telah dicoba dan benar yang
telah dikembangkan selama bertahun-tahun untuk menyempurnakan seni dan sains dalam
mengembangkan aplikasi perangkat lunak. Prinsip-prinsip tersebut berfungsi sebagai panduan menuju
kode yang lebih baik dan lebih bersih yang lebih mudah untuk di-debug dan dipahami.
Berikut daftar prinsip terpenting rekayasa perangkat lunak kami.
KERING (Jangan Ulangi Diri Anda)
Prinsip ini berasal dari buku “The Pragmatic Programmer” oleh Andy Hunt dan Dave Thomas, yang
mendefinisikannya sebagai:
Setiap bagian dari pengetahuan harus memiliki representasi tunggal yang tidak ambigu dan otoritatif
dalam suatu sistem.
Ini berarti bahwa setiap bagian data harus memiliki satu titik referensi atau satu sumber kebenaran
(SSOT), sehingga mengubah satu bagian data tersebut tidak memerlukan perubahan elemen yang tidak
terkait secara logis. Itu karena semua kemunculan data tersebut merujuk kembali ke satu lokasi. Ini
berbeda dengan kode yang mengharuskan perubahan setiap contoh katakanlah variabel setiap kali Anda
mengubah satu contoh dalam kode sumber Anda. Kode yang tidak mematuhi prinsip KERING dikatakan
WET, yang merupakan singkatan dari “tulis semuanya dua kali”, “kami senang mengetik”, “menulis
setiap saat”, atau “membuang waktu semua orang”! Menerapkan DRY ke kode mengurangi redundansi
dan membuatnya lebih mudah untuk dikelola nanti.
KISS (Keep It Simple Stupid)
Menurut The Routledge Dictionary of Modern American Slang and Unconventional English , prinsip ini
dirancang oleh US NAVY pada tahun 1960. Mereka mengamati bahwa sebagian besar sistem bekerja
paling baik bila dibuat sederhana dan sederhana, bukan rumit dan rumit. Pengalaman menunjukkan
bahwa kompleksitas menyebabkan bug karena ada lebih banyak bagian (tidak perlu) untuk dilacak dan
lebih sedikit teknisi yang dapat memahami bagaimana mereka terhubung. KISS membuat kode Anda
lebih bersih dan kecil kemungkinannya ada bug. Kode seperti itu juga lebih mudah untuk di-debug dan
dipelihara.
YAGNI (Anda Tidak Akan Membutuhkannya)
YAGNI berasal dari metodologi pengembangan perangkat lunak yang disebut Extreme
Programming (XP). Siapa yang lebih baik untuk mendefinisikannya selain co-founder XP, Ron Jeffries,
yang berkata:
Selalu terapkan hal-hal saat Anda benar-benar membutuhkannya, jangan pernah saat Anda meramalkan
bahwa Anda membutuhkannya.
Tidak jarang pengembang menambahkan fitur ke aplikasi mereka untuk mengantisipasi potensi
kebutuhan. Kemampuan untuk menghapus komentar mungkin menggoda bagi sebagian orang, tetapi
sekarang menjadi cukup standar untuk mengabaikan kemampuan untuk menghapusnya sama sekali.
Platform seperti Youtube dan LinkedIn, misalnya, tidak mengizinkan Anda untuk menghapus komentar
Anda. Menghindari fitur yang tidak diperlukan merupakan praktik yang baik dalam rekayasa perangkat
lunak. Namun, ada kasus di mana mengantisipasi penggunaan atau kebutuhan di masa mendatang akan
suatu fitur mungkin berguna.
PADAT
Ini terdiri dari prinsip-prinsip desain yang pertama kali muncul dalam makalah Robert C. Martin tahun
2000 yang berjudul Prinsip Desain dan Pola Desain. Mereka:

 Prinsip Tanggung Jawab Tunggal: Setiap kelas, metode, atau modul harus memiliki tanggung
jawab tunggal, sehingga hanya satu bagian dari aplikasi yang dapat memengaruhi kelas jika
bagian itu diubah. Itu masuk akal dalam kehidupan nyata. Kamar tidur Anda tidak dimaksudkan
untuk mandi, dan pancuran Anda juga tidak dimaksudkan untuk tidur. Kelas dan metode dapat
dianggap sebagai ruangan dengan tujuan dan tanggung jawab terpisah. Ini membuat kode Anda
lebih teratur dan lebih mudah diikuti.
 Prinsip Tertutup Terbuka: Ini berarti terbuka untuk perpanjangan dan ditutup untuk
modifikasi .

Tertutup untuk modifikasi berarti bahwa setelah kode yang ada berfungsi, kita harus mencoba untuk
tidak membuat perubahan yang tidak diperlukan. Alasannya adalah karena ia dapat membuka sekaleng
worm dengan memaksa kita untuk juga mengubah semua kode yang terkait dengannya, tanpa kita
ketahui. Untuk menghindari memberi diri kita lebih banyak pekerjaan daripada yang dibutuhkan, kode
yang ada harus dibiarkan sendiri, idealnya.
Harap diingat bahwa sering kali ada alasan yang sangat valid untuk memfaktorkan ulang kode yang
mungkin kaku atau sulit diikuti. Ketika refactoring dapat memberikan kejelasan atau meningkatkan
kinerja, pengecualian untuk prinsip ini harus dibuat.

 Prinsip Substitusi Liskov: Ini berarti bahwa subclass Anda harus berperilaku sama dengan kelas
yang mereka warisi. Dengan kata lain, Anda harus bisa mengganti anak dengan kelas induk dan
mengharapkan perilaku dasar yang sama . Misalnya, Anda memiliki kelas kendaraan dengan
properti roda dan metode penggerak ().

class Vehicle {
wheels: 4;
drive(){
System.out.println("Vroom!!!");
}
}
class Sedan extends Vehicle {
occupants: 4;
}
class Bicycle extends Vehicle {
occupants: 1;
}
 class Vehicle {
Vehicle (chosenBrand, chosenModel, numSeats){
brand: chosenBrand;
model: chosenModel
occupants: numSeats;
}
}
class Sedan extends Vehicle {
drive(){
console.log("Vroom");
}
class Bicycle extends Vehicle {
const numWheels = 2;
....
}

Lebih praktis memiliki antarmuka terpisah yang menangani tugas terpisah daripada yang menangani
banyak tugas. Misalnya, dalam suatu aplikasi, lebih baik memiliki tab terpisah yang menangani masalah
terpisah, seperti 'Pengaturan', daripada memiliki tab yang menangani masalah yang tidak terkait.

 Prinsip Pembalikan Ketergantungan : Modul tingkat tinggi tidak boleh bergantung pada modul
tingkat rendah. Interaksi antara kedua modul harus dianggap sebagai interaksi abstrak di antara
keduanya, bukan yang konkret.

Ini merujuk pada fakta penugasan tanggung jawab terpisah untuk setiap fungsi, kelas, atau komponen.
Seringkali sangat menggoda untuk memiliki satu fungsi yang menangani lebih dari satu tugas, namun
yang terbaik adalah membagi kerja di antara fungsi atau komponen khusus. Katakanlah Anda sedang
mengembangkan aplikasi cuaca, alih-alih memiliki satu fungsi yang menghasilkan ramalan cuaca untuk
hari tertentu, akan lebih bijaksana jika memiliki fungsi yang menghitung suhu, yang mengembalikan
kelembapan, dan satu lagi yang menentukan tanggal. Ini membuat kode lebih bersih yang lebih mudah
dibaca dan dipecahkan masalah.
Saya ingin mencatat bahwa meskipun ini tampak identik dengan 'prinsip tanggung jawab tunggal',
sebenarnya tidak. Tanggung jawab tunggal mengatakan bahwa setiap kelas atau fungsi harus memiliki
tanggung jawabnya sendiri. Pemisahan masalah mengatakan bahwa Anda harus memecah tanggung
jawab tunggal itu menjadi bagian-bagian kecil yang memiliki tanggung jawab masing-masing. Dalam
contoh aplikasi cuaca kami, Anda dapat memiliki satu fungsi yang mengambil satu tanggung jawab untuk
menghasilkan cuaca. Idealnya, Anda ingin memiliki fungsi terpisah untuk tanggal / waktu, satu untuk
kelembapan, dll. Itulah pemisahan perhatian. Oleh karena itu, ini dapat dianggap sebagai bagian dari
prinsip tanggung jawab tunggal.
Kode Dapat Digunakan Kembali
Salah satu manfaat dari pemisahan perhatian adalah memungkinkan penggunaan kembali kode. Karena
setiap metode ditulis untuk menangani tugas terpisah, sekarang metode tersebut dapat digunakan kembali
di masa mendatang untuk tujuan yang sama. Jadi, di aplikasi cuaca kami, fungsi penghitung tanggal kami
dapat digunakan kembali di bagian lain dari kode kami yang mungkin juga memerlukan tanggal.
Itu hanya beberapa prinsip rekayasa perangkat lunak yang sangat disarankan bagi pengembang untuk
diingat saat mengembangkan aplikasi. Mereka memungkinkan kode yang lebih mudah dibaca, di-debug,
dan dipelihara dalam jangka waktu yang lama. Silakan lihat tautan di bawah untuk sumber daya tambahan
tentang topik tersebut.
D. Feasibility Studies (Studi Kelayakan)

Tahap Planning

1. Identifikasi Business Value (System Request)

- Lower Costs

- Increase Productivity

- Increase Profits

2. Analisis Kelayakan

- Technical Feasibility

- Economic Feasibility

- Organizational Feasibility

studi kelayakan 

adalah kegiatan untuk menguji atau mengukur tingkat kelayakan pada suatu proyek dengan
mengidentifikasi masalah, peluang, tujuan, dan lain-lain. 

Feasibility sangatlah penting bagi perusahaan karena dapat membantu memberitahu persepsi tentang apa
saja manfaat yang diterima dari proyek tersebut.

Waktu tepat untuk perusahaan melakukan feasibility study adalah pada masa awal proyek dimulai
terutama saat tahap desain perencanaan.

Bagi perusahaan ternama, feasibility study dibuat untuk mengevaluasi dan menguji kelemahan dan
kekuatan dari sebuah rencana proyek secara faktual.

Hasil dari feasibility study juga dapat membantu perusahaan dalam mengetahui serta menilai ancaman
dan peluang yang ada di lingkungan sekitar, kebutuhan sumber daya, dan keberhasilan.

Tujuan Feasibility Studies

1. Memahami proses bisnis pada sistem yang lama. contoh: Flowchart dari sistem, Struktur Organisasi

2. Menentukan kebutuhan pemakai sistem secara garis besar untukdapat mencapai sasaran sistem. contoh:
Wawancara ke pemakai sistem, Observasi data

3. menentukan masalah sebelumnya pda sistem yang menyebabkan belum dapat mencapai sasarannya

4. dapat mempertimbangkan apakah suatu proyek layak untuk dijalankan

Tahapan Feasibility Studies:

1. Pengumpulan data dan informasi

2. Pemrosesan data

3. ananlisis data

4. pengambilan keputusan

5. memberikan rekomendasi

Jenis Studi Kelayakan:

1) Tecnical Feasibility Studies (kelayakan teknikal) adalah penilaian didasarkanatas outline rancangan
sistem kebutuhan proyek (design of systemrequirements), untuk menentukan apakah perusahaan
mempunyai kemampuan dan keahlian untuk menangani penyelesaian proyek.

- Familiarity with application: Pengguna familier terhadap pengoperasian software sejenis ini

- Familiarity with technology: Pengguna familier dengan teknologi pendukung aplikasi

- Project size: Jumlah dan waktu pengembang yang dibutuhkan

- Compatibility: Kompatibilitas dengan sistem yang ada di organisasi

2) Economic feasibility. Tujuan penilaian (assesment) kelayakanekonomi adalah untuk menentukan

keuntungan ekonomi yang posif bagiorganisasi yang diusulkan oleh proyek. Kelayakan ekonomi
secarakuantitatif mengidentifikasikan keuntungan yang diharapkan. Penilaian inisecara khusus
menyangkut cost/benefits analysis.

- Break-even Point (BEP): Waktu balik modal

- Return on Investment (ROI): Persentase pengembalian investasi

3) Organizational Feasibility. Aspek manajemen dan organisasi menggambarkan mengenai

pengorganisasian pihak-pihak yang terlibat dalam usaha, job desc, tanggung jawab serta kontribusi
masing-masing pihak dalam mencapai tujuan.

- is the project strategically aligned with the business?

- project champions

- senior management

- user

- other stakeholders
1. present value

Present Value (PV) adalah perhitungan nilai uang hari ini dari arus kas (cash flow) yang akan diterima di
masa depan dengan pertimbangan tingkat suku bunga (invest rate) dan inflasi.

Present Value (PV) dapat juga disebut dengan nilai diskon (discounted value)

PV menyatakan bahwa uang hari ini akan bernilai lebih besar di masa depan, karena adanya penerimaan
tingkat bunga dan pengembalian tertentu

2. Net Present Value

Net Present Value (NPV) adalah selisih antara nilaisaat ini dari arus kas masuk dengan nilai saat ini dari
arus kas keluar pada masa waktu tertentu NPV juga bisa dijadikan pertimbangan dalam menentukan
investasi mana yang lebih besar dalam menghasilkan keuntungan, sehingga dapat dijadikan dasar
pengambilan keputusan

NPV juga bisa dijadikan pertimbangan dalam menentukan investasi mana yang lebih besar dalam
menghasilkan keuntungan, sehingga dapat dijadikan dasar pengambilan keputusan

Jika hasil NVP nol atau positif, berarti proyek untung, harus diterima. Jika hasil NVP negative, berarti
proyek tidak untung, harus ditolak

3. Metode Return On Investment

Return on Investment atau ROI adalah besar persen profit yang bisa didapat dari total jumlah aset
investasi. Dari definisinya, bisa dikatakan juga bahwa ROI adalah perhitungan yang bisa menunjukkan
tingkat seberapa efektif seseorang atau perusahaan mempertaruhkan dana dalam tanam modal berupa
investasi

Return On Investment (ROI) adalah rasio yang menunjukkan hasil dari jumlah aktiva yang digunakan
dalam perusahaan atau suatu ukuran tentang efisiensi manajemen
4. Metode Break Even Point

Pengertian BEP (Break even point) adalah total pendapatan yang didapatkan sama dengan biaya yang
dikeluarkan. Total keuntungan dan kerugian pada titik BEP adalah 0, artinya di titik ini adalah titik impas,
dimana perusahaan dalam posisi netral. Perusahaan ini tidak mengalami kerugian maupun keuntungan.

BEP sangat penting bagi sebuah perusahaan karena dapat membantu dalam membuat keputusan, seperti
contoh apakah perlu menaikkan harga produk atau mengurangi biaya operasional.
E. Memahami Masalah

Secara konsep, rekayasa perangkat lunak memiliki kedekatan dengan prinsip-prinsip pemecahan masalah.
Pemecahan 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 dan gejala adalah sesuatu yang berbeda. Masalah adalah perbedaan kondisi yang terjadi dan
yang diharapkan. Sedangkan Gejala adalah tanda/petunjuk terjadinya suatu masalah.

     Hubungan RPL dengan masalah dan gejala adalah perangkat lunak  hasil dari RPL merupakan alat
bantu yang digunakan untuk menyelesaikan tugas/masalah itu.

2. Tipe-tipe masalah

Masalah Pemenuhan Standar

Yaitu masalah yang berhubungan dengan pencapaian standar yang telah ditentukan dalam suatu
organisasi. Biasanya berjangka waktu panjang.

Masalah Pemilihan Alternatif

Yaitu bagaimana memilih solusi alternatif dari kriteria-kriteria tertentu. Contohnya memilih sekolah yang
tepat, lokasi tempat tinggal dan tempat kerja yang dipilih secara alternatif.

Masalah Pemenuhan Kepuasan Konsumen

Yaitu misalnya pada organisasi/perusahaan yang ingin untung dengan keinginan konsumen yang berbeda-
beda, maka perlu dicari solusi masalah yang akan menguntungkan kedua belah pihak baik konsumen
maupun perusahaan itu sendiri.

Masalah Pencapaian Tujuan

Mirip dengan Masalah Pemenuhan Standar, hanya berjangka waktu pendek.
 
3. Pemecahan Masalah
    Proses mengamati situasi, ditemukan masalah dan dibuat penyelesaian dengan tentukan masalah,
mengurangi atau menghilangkan masalah atau mencegah masalah tersebut terjadi.

Proses pemecahan masalah :

Pendefinisian masalah, Analisis situasi, Pengembangan ide-ide solusi, Analisis ide-ide solusi,
Pengambilan keputusan, dan Penerapan solusi.

Tahapan-tahapan utama dalam pemecahan masalah :

Memahami dan mendefinisikan masalah

Bagian ini merupakan bagian yang sangat penting karena menjadi awal dari seluruh proses pemecahan
masalah. Tujuan 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 bisa menggunakan kereta api, bus atau lainnya. Jalurnya pun bisa lewat jalur utara, tengah
atau selatan. Jadi banyak sekali penyelesaian dan masing-masing punya karakteristik sendiri-sendiri. Dari
sekian banyak penyelesaian ini kita harus pilih satu yang berdasarkan persyaratan tertentu yang
merupakan cara yang paling baik untuk menyelesaikan 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.
 F. Persyaratan Software

Perangkat Lunak harus memberikan bantuan dalam mempresentasikan dan mengakses file-file eksternal
yang dibuat dengan alat bantu lain.

Tujuan Requirements
Yaitu memahami kebutuhan user. Untuk itu perlu adanya persyaratan-persyaratan antara lain:

1.Persyaratan Fungsional dan Non Fungsional.

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
.
Persyaratan non-fungsional terdiri dari:
a.Persyaratan Produk: persyaratan yang diambil dari spesifikasi produk, seperti persyaratan hardware
untuk mendukung kinerja.
b.Persyaratan Organisasi: persyaratan yang berasal dari kebijakan dan prosedur pada organisasi.
c.Persyaratan Eksternal: persyaratan yang berasal dari factor eksteral terhadap system dan proses
pengembangannya.

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: prosentase peryataan tergantung target atau jumlah system target.

2.Persyaratan User.
Mendeskprisikan persyaratan fungsional dan non-fungsional sehingga dapat dipahami oleh user yang
tidak memiliki pengetahuan teknik. Persyaratan user harus ditulis memakai bahasa natural formal dan
diagaram intuitif yang sederhana. Persyaratan user tidak boleh didefinisikan memakai model
implementasi.
Masalah yang sering muncul:

 Tidak ada kejelasan

 Kesimpang-siuran persyaratan
 Penggabungan persyaratan

3.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.

4.Dokumentasi Persyaratan Perangkat Lunak.

Spesifikasi Persyaratan Sistem

User harus diberi fasilitas untuk mendefinisikan jenis file eksternal. Setiap file eksternal bisa
memiliki alat bantu relevan yang bisa diterapkan pada file tersebut. Setiap file eksternal bisa
direpresentasikan sebagai ikon yang spesifik pada display user. Fasilitas harus disediakan untuk ikon
yang merepresentasikan suatu jenis file eksternal yang akan didefinisikan oleh user. Ketika user memilih
suatu ikon yang merepresentasikan file eksternal, efek pemilihan adalah penerapan alat bantu yang
berhubungan dengan jenis file eksternal ke file yang direpresentasikan oleh ikon yang dipilih.

Klasifikasi Requirements

1.Requirements Fungsional
Yaitu pernyataan layanan tentang bagaimana system harus bereaksi terhadap input. System harus berlaku
pada situasi-situasi tertentu. Secara khusus menyatakan apa yang tidak boleh dilakukan system.

 Merupakan Fungsi teknis dari perangkat lunak yang akan dikembangkan.

2.Requirements Non-fungsional
Yaitu pernyataan tentang batasan layanan dan fungsi yang diberikan system.

 Merupakan Persyaratan yang bersifat kualitatif terhadap sistem atau perangkat lunak yang akan
dikembangkan.
 Biasanya mencakup batasan waktu, batasan proses pengembangan, penggunaan standar, dsb.

3,Requirements Domain
Yaitu persyaratan yang datang dari domain aplikasi system dan merefleksikan karakteristik domain
tersebut.

 Mencakup domain sistem beserta karakteristiknya.

 Persyaratan ini bisa berupa persyaratan fungsional maupun non-fungsional.

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.
Contoh bahasa grafis adalah SADT (Ross 1977), Use-Case (Jacobson et al. 1993).
4,Spesifikasi Matematis
Notasi seperti himpunan atau finite-state machine, lebih dikenal dengan bahasa formal.

Metode Requirements
 Metode -> Bagaimana menjembatani antara user dengan pengembang perangkat lunak atau
developer.
 Tujuan lebih lanjut adalah agar tidak terjadi kesalahan persepsi baik dari sisi user maupun
developer.
 Metode : SRS Document.

SRS Document
 SRS: Software Requirements Specification
 Tujuan:
a.Aspek legalitas antara user dengan developer
b.Dengan adanya SRS, diharapkan kebutuhan user akan dapat terpenuhi dengan baik
 Syarat SRS Document:
a.Harus dapat menspesifikasi perilaku eksternal
b.Harus dapat menspesifikasi batasan-batasan implementasi
c.Harus mudah diubah
d.Sebagai alat bantu referensi untuk maintenance
e.Harus ada perkiraan mengenai siklus hidup sistem
f.Harus dapat mencirikan tanggapan yang dapat diterima terhadap kejadian yang tidak diinginkan
 Ada standar tertentu untuk pembuatan SRS Document yaitu Standar IEEE
G. Software Architecture

Selain makna gedung, istilah ‘arsitektur’ juga ada dalam Software Engineering dan Development.

Istilah software architecture berperan sebagai sebuah struktur dalam sebuah software atau aplikasi. Jadi
secara tidak langsung, software architecture juga menjadi solusi untuk requirements yang ada, lalu juga
meningkatkan performance dan security secara bersamaan.

Beberapa Jenis Software Architecture Pattern

1. Layered Pattern

2. Pattern ini digunakan untuk menstruktur program yang dapat didekompos menjadi beberapa subtask.
Setiap layer memberikan service kepada layer diatasnya. 4 layer yang umumnya ditemukan ada
sebagai berikut :

 Presentation layer (UI layer)

 Application layer (Service layer)

 Business logic layer (Domain layer)

 Data access layer (Persistence layer)

2. Client-Server Pattern

Pattern ini terdiri dari 2 komponen, yaitu satu Server dan Client yang lebih dari 1. Komponen server akan
menyediakan berbagai macam service kepada komponen klien, dan komponen klien akan me-request
service yang disediakan oleh komponen server, dan komponen server akan memberikan service yang
relevan kepada komponen klien tersebut.

3. Microservices

Pada microservices, pendekatannya berdasarkan service-service yang mempunyai fitur tertentu, lalu
terkumpul membangun suatu sistem. Sistem yang terbangun dari kumpulan service-service ini dapat
memanggil service yang menjalankan fitur tersendiri.
Penerapan dalam PPL TemanBisnis

Aplikasi kami bisa dikatakan menerapkan container-based architecture. Kami menggunakan docker untuk
menjalankan container dengan image yang sesuai. Setiap komponen pada aplikasi merupakan sebuah
container (pada diagram digambarkan dengan kotak). Setiap container memiliki image yang akan
digunakan.

Arsitektur ini dibuat berdasarkan kebutuhan teknologi dari klien kami. Pertama, TemanBisnis
membutuhkan dashboard untuk melihat data hasil tracking user activity. Di sisi lain, TemanBisnis juga
membutuhkan sebuah API yang dapat mengakomodasi kebutuhan tracking dari aplikasi mereka. Atas
dasar kebutuhan tersebut, kami memutuskan untuk memisahkan komponen API tersebut menjadi sebuah
container yang berdiri sendiri. Selanjutnya, masing-masing komponen, baik itu frontend dan android,
dapat melakukan komunikasi dengan backend dengan metode yang biasa dilakukan pada arsitektur REST.

Komponen Aplikasi

Container ppla1-frontend adalah aplikasi web kami yang akan digunakan oleh TemanBisnis.

Aplikasi frontend kami menggunakan framework Django. Komponen ini akan berinteraksi
dengan backend untuk meminta data hasil tracking activity untuk ditampilkan pada dashboard.

Container ppla1-backend adalah aplikasi berupa REST API. Kami menggunakan framework Django

REST dan sama seperti frontend. Komponen ini yang berperan penting untuk mengintegrasi
antara database, frontend dan aplikasi android.

Komponen lain yang tidak kalah penting adalah container untuk database. Aplikasi kami

menggunakan image postgresql. Container tersebut diakses oleh backend saja.

Demikian dari pengalaman yang saya dapat bagikan mengenai Software Architecture serta penerapannya.
Sekian dari saya, jika ada kesalahan pada penulisan, mohon diingatkan dan dikoreksi, karena disini saya
juga masih masih belajar :D. Terimakasih telah membaca artikel ini, dan sampai jumpa!
H. Testing

1. User Acceptance Test (UAT)

User Acceptance Test atau Tes Penerimaan Pengguna adalah sebuah tahapan final yang dilakukan dalam
semua jenis Model Pengembangan Perangkat Lunak, testing ini bertujuan untuk menentukan apakah
produk yang dikembangkan telah memenuhi kebutuhan pengguna, kebutuhan tersebut befokus kepada
pengguna, produk itu sendiri harus telah memenuhi fungsionalitas dan detail produk yang dapat diterima
oleh pengguna.

2.  Usability Testing

Usability Testing atau pengujian kegunaan adalah evaluasi yang dilakukan pada produk yang
memfokuskan pada mengidentifikasi masalah kegunaan, mengumpulkan data kualitatif dan kuantitatif,
dan menentukan kepuasan pengguna produk, dalam tahap ini, testing dilakukan oleh perwakilan
pengguna, mereka akan menggunakan produk kita untuk menentukan apakah mereka puas dengan
fungsionalitas, interface dan detail lainnya pada produk tersebut.

4.  Performance testing

Performance testing atau Pengujian kinerja adalah suatu evaluasi terhadap produk untuk menentukan
apakah sebuah produk tersebut memenuhi harapan dalam kecepatan waktu, skalabilitas, dan stabilitas
dibawah beban kerja yang diharapkan. Biasanya, produk harus memenuhi kriteria seperti Response
Time dan Throughput.

 Response time, menentukan waktu maksimum yang diijinkan dari respon suatu produk.
 Throughput, menentukan jumlah minimum query dan transaksi yang harus diproses dalam suatu
durasi waktu.
5.  Stress Testing
Stress Testing atau biasa disebut sebagai Torture Testing, adalah evaluasi produk dengan metode
pengujian dengan memberi tekanan kepada produk secara intensif, hal ini untuk menentukan stabilitas
produk atau sistem terlebih lagi saat menerima tekanan besar.

6.  Smoke testing

Smoke Testing juga biasa disebut sebagai Build Verification Testing atau Confidence Testing, adalah salah
satu tahap pengujian untuk mengungkapkan kegagalan sederhana tapi yang cukup parah untuk
ketidakberhasilan suatu fungsi atau fitur pada produk. Pengujian ini akan menentukan kelayakan rilis
pada suatu build di produk. Smoke testing terdiri dari sebuah kumpulan dari test dasar (seperti: apakah
program ini berjalan? apakah tombol ini berjalan?) yang akan dijalankan pada setiap build dari produk
untuk menguji fungsionalitas dari produk, informasi tersebut akan digunakan untuk sebuah konfirmasi
kepada Team QA apakah dibutuhkan Software Testing lebih khusus ke bagian yang bermasalah.
7.  Sanity Testing
Sanity Testing, sedikit mirip seperti Smoke Testing dimana dilakukan setiap tedapat build baru pada
produk, tapi testing ini adalah kumpulan dari Regression Testing, Testing yang berfokus kepada
perubahan seperti fitur baru dan perbaikan bug.

8.  Regression Testing

Regression Testing adalah tahap pengujian untuk menkonfirmasi apakah perubahan code tidak
mempengaruhi atau merusak fitur-fitur yang sudah ada, yang akan memastikan bahwa kode lama atau
fitur yang lama masih bekerja dengan baik dan tidak mendapatkan efek setelah ada penambahan atau
perubahan kode.

9.  System Testing

System Testing adalah tahap pengujian yang dilakukan setelah Integration Testing untuk menguji sistem
secara keseluruhan, semua modul/komponen yang telah terintegrasi, yang menentukan apakah kesuluhan
komponen yang telah terintegrasi pada sistem telah memenuhi harapan.

10.  Integration Testing

Integration Testing (biasanya juga disebut sebagai Integration and Testing/I & T, String Testing,
dan Thread Testing) adalah tahap testing yang dilakukan setelah Unit testing, yang melakukan pengujian
terhadap suatu module yang secara logika telah terintegrasi. Tujuan dari pengujian ini adalah untuk
menemukan kecacatan dalam interaksi antara modul perangkat lunak ketika mereka terintegrasi.

11.  Unit testing

Unit testing adalah pengujian yang befokus pada pungujian unit yang terkecil pada desain
produk. Unit kecil di sini dapat berupa sebuah Class atau Function pada suatu program.
I. Project Management

Sama halnya dengan hal-hal manajerial lainnya, proses manajemen yang satu ini juga dilakukan untuk
mengelola atau mengatur sesuatu. Sesuai namanya, hal yang dikelola oleh manajemen proyek perangkat
lunak adalah proses pengembangan perangkat lunak alias software. Secara manajerial, manajemen proyek
ini sama aja dengan manajemen lainnya. Hal yang membedakan hanyalah bidang dan bahasan di dalam
manajemennya. Namanya juga proyek perangkat lunak, sudah jelas kalau manajemen ini merupakan
manajerial di bidang teknologi.

Tujuan

Apa sih tujuan dari manajemen proyek ini? Secara umum, proses manajemen dilakukan untuk mengelola
atau mengatur sesuatu. Begitu juga dengan tujuan manajemen proyek perangkat lunak. Dari proses 
manajemen ini, kita bisa mengelola hal-hal dasar hingga teknis dari proyek yang dilakukan.

Mulai dari menetapkan dasar, tujuan, proses, hingga rencana hasil akhir proyek. Manajemen ini
digunakan untuk mengelola semua hal itu, Sob. Proses manajerial yang dilakukan mencakup penentuan
alur proyek bahkan mengatur pihak-pihak yang terlibat di dalamnya.

3 Fokus utama manajemen proyek perangkat lunak

Ada tiga hal yang jadi fokus utama dalam manajemen proyek perangkat lunak. Apa saja?

1. People

Persis dengan proses manajemen di mana pun, manajemen proyek di bidang teknologi juga berfokus pada
sumber daya manusia di dalamnya. Semua pihak yang terlibat menjadi fokus utama dari proses manajerial
ini.

Kenapa people menjadi salah satu fokus utamanya? Jawabannya sederhana, manusia menjadi fokus
utama karena manusialah yang menjadi perencana, pelaksana, dan pengguna dari proyek ini. Manusia
akan menjadi pihak yang menjalankan proses yang sudah ditentukan.

2. Problem

Dalam manajemen proyek ini, kita perlu tau masalah yang ada di dalamnya. Bukan hanya masalah yang
sudah tampak, tapi juga kemungkinan masalah yang mungkin muncul dan kompleksitasnya. Dari
masalah-masalah inilah akan disusun solusi serta strategi yang akan digunakan. Tentu saja semuanya
dihasilkan dari dasar keilmuan yang jelas.
Problem yang dimaksud juga mencakup masalah pemilihan sumber daya dan pengelolaannya. Eits, bukan
cuma sumber daya manusia tapi juga teknologi yang akan digunakan. Misalkan dalam pengembangan
aplikasi, memilih rekomendasi VPS Terbaik untuk menghasilkan aplikasi yang terbaik pula juga menjadi
salah satu contoh masalahnya.

3. Process 

Fokus utama berikutnya adalah proses. Proses ini menjadi salah satu hal yang diperhatikan dalam
manajemen. Mulai dari penyusunan kerangka kerja, memastikan semuanya berjalan sesuai alur kerangka
kerja tersebut, dan memaksimalkan hasil dari proses yang telah dilakukan.

Stakeholder dan pihak yang terlibat

Seperti yang sudah dijelaskan sebelumnya, salah satu fokus utama dari manajemen proyek
adalah people. Nah, sekarang kita bahas siapa aja sih people dalam manajemen proyek ini?

Sama seperti prinsip agile atau scrum, manajemen ini melibatkan user, project

manager, dan development team. Timnya terdiri dari developer sampai pihak-pihak lain yang akan
menjalankan proses pengembangan perangkat lunaknya,

Model manajemen

Dalam pengembangan perangkat lunak, ada beberapa model yang biasa digunakan. Model ini sama
dengan model agile development methods. Mulai dari metode waterfall sampai Rapid Application
Development. Penerapan model manajemen biasanya disesuaikan dengan jenis proyek atau perangkat
lunak yang dikembangkan.

Fungsi Manajemen Proyek

Berikut ini terdapat beberapa fungsi dari manajemen proyek, yakni sebagai berikut:
Planning (Perencanaan)

Planning merupakan proses yang secara sistematis mempersiapkan kegiatan guna mencapai tujuan dan
sasaran tertentu. Kegiatan diartikan sebagai kegiatan yang dilakukan dalam rangka pekerjaan konstruksi,
baik yang menjadi tanggung jawab pelaksana (kontraktor) maupun pengawas (konsultan). Kontraktor
maupun konsultan, harus mempunyai konsep planning” yang tepat untuk mencapai tujuan sesuai dengan
tugas dan tanggung jawab masing-masing.

Pada proses planning perlu diketahui kondisi-kondisi sebagai berikut:

1. Permasalahan yang terkait dengan tujuan dan sumber daya yang tersedia.
2. Cara mencapai tujuan dan sasaran dengan memperhatikan sumber daya yang tersedia.
3. Penerjemahan rencana kedalam program-program kegiatan yang  kongkrit.
4. Penetapan jangka waktu yang dapat disediakan guna mencapai tujuan dan sasaran.

Organizing (Pengorganisasian)

Organizing (pengorganisasian kerja) dimaksudkan sebagai pengaturan atas suatu kegiatan yang dilakukan
oleh sekelompok orang, dipimpin oleh pimpinan kelompok dalam suatu wadah organisasi. Wadah
organisasi ini menggambarkan hubungan-hubungan struktural dan fungsional yang diperlukan untuk
menyalurkan tanggung jawab, sumber daya maupun data.

Dalam proses manajemen, organisasi berfungsi untuk :

 Menjamin terpeliharanya koordinasi dengan baik.

 Mmembantu pimpinannya dalam menggerakkan fungsi-fungsi manajemen.
 Mempersatukan pemikiran dari satuan organisasi yang lebih kecil yang berada di dalam
kordinasinya.

Actuating (Penggerakan)

Actuating diartikan sebagai fungsi manajemen untuk menggerakkan orang yang tergabung dalam
organisasi agar melakukan kegiatan yang telah ditetapkan di dalam planning. Pada tahap ini diperlukan
kemampuan pimpinan kelompok untuk menggerakkan, mengarahkan dan memberikan motivasi kepada
anggota

kelompoknya untuk secara bersama-sama memberikan kontribusi dalam menyukseskan manajemen

proyek mencapai tujuan dan sasaran yang telah ditetapkan.
Controlling (Pengendalian)

Controlling diartikan sebagai kegiatan guna menjamin pekerjaan yang telah dilaksanakan sesuai dengan
rencana. Didalam manajemen proyek jalan atau jembatan, controlling terhadap pekerjaan kontraktor
dilakukan oleh konsultan melalui kontrak supervisi, dimana pelaksanaan pekerjaan konstruksinya
dilakukan oleh kontraktor. Pengawas Umum (General Superintendat) berkewajiban melakukan
Pengendalian (secara berjenjang) terhadap pekerjaan yang dilakukan oleh staf di bawah kendalinya yaitu
Site Administration, Quantity Surveyor, Materials Superintendant, Construction Engineer, dan Equipment
Engineer untuk memastikan masing-masing staf sudah melakukan tugasnya dalam koridor “jaminan
kualitas (quality assurance)”. Sehingga, tahap-tahap pencapaian sasaran sebagaimana direncanakan dapat
dipenuhi.