Bab 3

Software Process
2.2.1 Kerangka Proses (Process Framework)
Kerangka proses (process framework) membuat pondasi untuk proses rekayasa perangkat
lunak yang lengkap dengan mengidentifikasi sebagian kecil kegiatan kerangka kerja
(framework activities) yang berlaku untuk semua proyek perangkat lunak, tanpa
menghiraukan ukuran atau kompleksitasnya. Sebagai tambahan, kerangka proses meliputi
sekumpulan dari kegiatan umbrella (umbrella activities) yang berlaku bagi keseluruhan
proses perangkat lunak. Kerangka proses secara umum untuk rekayasa perangkat lunak
meliputi lima kegiatan :
Komunikasi (Communication) – sebelum banyak pekerja teknis dapat memulai, ini
merupakan sangat penting untuk mengkomunikasi dan kolaborasi dengan pelanggan (dan
pemangku kepentingan lainnya). Ini dimaksudkan untuk memahami sasaran hasil pemangku
kepentingan dan mengumpulkan keperluan yang membantu mendefinisikan fitur dan fungsi
dari perangkat lunak.
Perencanaan (Planning) – merencanakan kegiatan yang akan dilakukan dalam pembuatan
perangkat lunak dalam bentuk “map”. Hal ini ditujukan untuk membantu sebagai petunjuk
(guide) ketika pembuatan perangkat lunak. Map – biasa disebut rencana proyek perangkat
lunak – didefinisikan rekayasa perangkat lunak bekerja dengan menggambarkan tugas teknis
untuk dilaksanakan, masalah yang mungkin terjadi, resource yang diperlukan, hasil kerja
yang diproduksi dan jadwal pekerjaan.
Pemodelan (Modeling) – sepertihalnya arsitektur, perancang perangkat lunak perlu membuat
“sketsa” atau desain terhadap perangkat lunak yang akan dibuat, dengan menambahkan
beberapa detail pada desain menjadikan lebih mudah dipahami bagi programmer dalam
membuat perangkat lunak.
Konstruksi (Construction) – Apapun yang didesain perlu dibangun. Kegiatan ini
dikombinasikan dengan penulisan kode dan testing diperlukan untuk mengungkap error dari
kode yang ditulis.
Penyebaran (Deployment) – perangkat lunak yang sudah selesai diberikan ke pelanggan dan
mereka mengevaluasi produk yang diberikan dan memberikan timbal balik.
3. Sruktur Proses Perangkat Lunak (Software Process Structure)
Proses perangkat lunak didefinisikan sebagai kumpulan dari aktifitas-aktifitas, tindakan-
tindakan dan tugas-tugas yang mana dijalankan ketika bebrapa hasil pekerjaan terbentuk
(Pressman, 2010). Proses perangkat lunak dapat direpresentasikan seperti gambar berikut.

Gambar 1. Struktur proses perangkat lunak

3.1 Model Proses Umum (Generic Process Model)
Merujuk dari gambar di atas, setiap aktifitas kerangka kerja (Framework) terdiri dari
kumpulan tidakan rekayasa perangkat lunak (Software Engineering). Setiap tindakan rekayasa
perangkat lunak didefinisikan oleh kumpulan tugas yang mana tugas tersebut
mengindikasikan tugas pekerjaan yang harus diselesaikan, hasil pekerjaan yang akan dibuat,
titik kepastian kualitas (quality assurance points) yang akan diperlukan, dan kejadian-
kejadian penting (milestones) yang akan digunakan untuk indikasi kemajuan (progress).
Sebuah kerangka kerja proses umum untuk rekayasa perangkat lunak didefinisikan lima
kegiatan kerangka kerja – komunikasi (communication), perencanaan (planning), pemodelan
(modeling), konstruksi (construction), dan pelepasan (deployment). Sebagai tambahan,
kumpulan kegiatan umbrella (umbrella activities) – pengendalian dan pelacakan proyek
(project tracking and control), manjemen resiko (risk management), kepastian kualitas
(quality assurance), manajemen konfigurasi (configuration management), tinjauan teknik
(technical reviews), dll – yang diterapkan pada keseluruhan proses.
3.2 Mendefinisikan Kegiatan Kerangka Kerja
Terdapat salah satu aspek penting dalam proses perangkat lunak yang disebut alur proses
(process flow). Aspek tersebut menggambarkan bagaimana kegiatan kerangka kerja dan
tindakan dan tugas yang muncul di setiap kegiatan kerangka kerja terorganisir secara baik
dalam urutan dan waktu pelaksanaan.
Alur proses linier (linear process flow) mengeksekusi 5 kegiatan kerangka kerja dari
komunikasi berurutan hingga deployment seperti gambar berikut.

Gambar 2. Alur proses linier

Alur proses iteratif (iterative prosess flow) mengulang satu atau banyak kegiatan sebelum
melanjutkan kegiatan selanjutnya seperti ditujukan gambar berikut.

Gambar 3. Alur proses iteratif

Alur proses evolusioner (evolutionary prosess flow) mengeksekusi kegiatan secara sirkular,
setiap sirkular melakukan kegiatan mulai dari awal lagi sehingga membentuk versi terbaru
dari perangkat lunak seperti ditujukan gambar berikut.

Gambar 4. Alur proses evolusioner

Alur proses paralel (parallel process flow) mengeksekusi satu atau banyak kegiatan secara
paralel dengan kegiatan lainnya seperti gambar berikut.
Gambar 5. Alur proses paralel
 BAB 4
MODEL PROSES
4.1 MODEL PROSES PRESKRIPTIF
4.1.1 The Waterfall Model

Model Waterfall merupakan salah satu model untuk perencanaan dari

sebuah Perangkat Lunak. Model Waterfall adalah salah satu model klasik
yang bersifat sistematis. Mengapa disebut sistematis ? Karena model ini
dikerjakan secara berurutan. Penggunaan model ini dalam penerapan di
kehidupan sehari-hari sangatlah memakan waktu dan sangat sedikit dipakai
membuat software. Namun model ini cocok untuk bisnis kecil.
Kelebihan Model Waterfall :
1. Merupakan model pengembangan paling handal dan paling lama
digunakan.
2. Cocok untuk sistem software yang bersifat generik.
3. Pengerjaan projek sistem akan terjadwal dengan baik dan mudah
dikontrol.
Kekurangan Model Waterfall :
1. Persyaratan sistem harus digambarkan dengan jelas.
2. Rincian proses harus benar-benar jelas dan tidak boleh berubah
ubah
3. Sulit untuk mengadaptasi jika terjadi perubahan spesifikasi pada
suatu tahapan pengembangan

4.1.2 Model Proses Incremental

Dalam model Incremental ini proses pengerjaan perangkat lunak akan
dilakukan perbagian sehingga bagian selanjutnya akan dikerjakan setelah
bagian awal telah selesai dan selanjutnya sampai menghasilkan perangkat
lunak yang lengkap dengan semua fungsi yang diperlukan dan pengerjaan
perangkat lunak berakhir. Sebelum pengerjaan perangkat lunak akan
dilakukan perancangan arsitektur software sebagai kerangka dalam
pengerjaan perbagian.
Kelebihan Model Incremental :
1. Resiko yang rendah pada pengembangan sistem.
2. Mengutamakan fungsi-fungsi pada sistem perangkat lunak
sehingga kemudahan pemakaian sistem yang paling di utamakan.
3. Tahap awal adalan dasar dari pembuatan tahap berikutnya
(dikerjakan secara terurut).
4. Cocok digunakan bila pembuat software tidak banyak/kekurangan
pembuat
5. Mampu mengakomodasi perubahan kebutuhan customer.
 6. Mengurangi trauma karena perubahan sistem. Klien dibiasakan
perlahan-lahan menggunakan produknya bagian per bagian.
7. Memaksimalkan pengembalian modal investasi konsumen.
Kekurangan Model Incremental :
1. Hanya akan berhasil jika tidak ada staffing untuk penerapan secara
menyeluruh.
2. Penambahan staf dilakukan jika hasil incremental akan
dikembangkan lebih lanjut.
3. Hanya cocok untuk proyek dengan skala kecil.
4. kemungkinan tiap bagian tidak dapat diintegrasikan.

4.1.3 Model Proses Evolusi

Model evolusi adalah sebuah model yang berulang-ulang. Model ini
memiliki karakteristik yang memungkinkan para programmer
mengembangkan perangkat lunaknya menjadi semakin lengkap di tiap
versinya. Model ini diterapkan karena persyaratan (requierement) sering
berubah sehingga hasil akhir dari sebuah produk tidak akan realistis,
dimana edisi komplit dari produk tersebut mustahil dikeluarkan
dikarenakan deadline market yang begitu ketat. Oleh karena itu lebih baik
mengeluarkan versi limited untuk memperkenalkannya terlebih dahulu
dan programmer dapat membuat model dari sebuah design untuk
mengakomodasikan produk, yang secara bertahap akan diselesaikan dari
waktu ke waktu.
Kelebihan Model Evolusi :
1. Meningkatkan kemampuan memimpin dan mengatur sesuatu
dengan pengembangan diri.
2. Menciptakan suasana yang sadar akan kualitas suatu produk.
3. Fungsi inti dari quality control dalam perusahaan besar pada
tingkat lokakarya.
4. Meningkatkan kebersamaan untuk mencapai suatu hasil dan
semangat kerja karyawan.
5. Meningkatkan kualitas dengan biaya efektif.
6. Membebaskan manajemen.
7. pekerja Shop Floor adalah lokasi terbaik untuk mengidentifikasi
masalah.
Kekurangan Model Evolusi :
1. Intensitas pekerjaan meningkat karena masalah akan lebih banyak
dari pada yang diperkirakan.
2. Manajemen perlu berkomitmen untuk sistem yang berkualitas, jika
sebuah solusi dari sebuah masalah tidak dapat diterapkan maka itu
bisa membuat frustasi para pekerja.
3. Dapat memiliki efek negatif pada hubungan industrial.
4. Dapat fokus pada masalah duniawi.
Terdapat 2 model proses Evolusi, yaitu :
a. Prototype

Prototype merupakan salah satu metode pengembangan perangat lunak

yang banyak digunakan. Dengan metode prototyping ini pengembang
dan pelanggan dapat saling berinteraksi selama proses pembuatan
sistem. Prototyping, dimulai dengan pengumpulan kebutuhan,
mendefinisikan objektif keseluruhan dari software,
mengidentifikasikan segala kebutuhan, kemudian dilakukan
“perangcangan kilat” yang difokuskan pada penyajian aspek yang
diperlukan.
Kelebihan :
1. Prototype melibatkan user dalam analisa dan desain.
2. Punya kemampuan menangkap requirement secara konkret
daripada secara abstrak.
3. Untuk digunakan secara standalone.
4. Digunakan untuk memperluas SDLC.
5. Mempersingkat waktu pengembangan Sistem Informasi
Kekurangan :
1. Proses analisis dan perancangan terlalu singkat.
2. Mengesampingkan alternatif pemecahan masalah.
3. Bisanya kurang fleksible dalam mengahdapi perubahan.
4. Prototype yang dihasilkan tidak selamanya mudah dirubah
b. Model Spiral
Model spiral (spiral model) adalah model pengembangan software
dimana proses digambarkan sebagai spiral. Setiap loop akan mewakili
satu fase dari proses pembuatan/perancangan software. Loop paling
dalam berfokus pada kelayakan dari sistem, loop selanjutnya tentang
definisi dari kebutuhan, loop berikutnya berkaitan dengan desain
sistem dan seterusnya, seperti gambar berikut:

Kelebihan Model Spiral :

1. Setiap tahap pengerjaan dibuat prototyping sehingga
kekurangan dan apa yang diharapkan oleh client dapat
diperjelas dan juga dapat menjadi acuan untuk client dalam
mencari kekurangan kebutuhan.
2. Lebih cocok untuk pengembangan sistem dan perangkat lunak
skala besar.
3. Dapat disesuaikan agar perangkat lunak bisa dipakai selama
hidup perangkat lunak komputer.
4. Pengembang dan pemakai dapat lebih mudah memahami dan
bereaksi terhadap resiko setiap tingkat evolusi karena
perangkat lunak terus bekerja selama proses.
5. Menggunakan prototipe sebagai mekanisme pengurangan
resiko dan pada setiap keadaan di dalam evolusi produk.
6. Tetap mengikuti langkah-langkah dalam siklus kehidupan
klasik dan memasukkannya ke dalam kerangka kerja iteratif.
7. Membutuhkan pertimbangan langsung terhadap resiko teknis
sehingga mengurangi resiko sebelum menjadi permaslahan
yang serius.
Kekurangan Model Spiral :
1. Banyak konsumen (client) tidak percaya bahwa pendekatan
secara evolusioner dapat dikontrol oleh kedua pihak.
2. Model spiral mempunyai risiko yang harus dipertimbangkan
ulang oleh konsumen dan developer.
3. Memerlukan tenaga ahli untuk memperkirakan risiko, dan
harus mengandalkannya supaya sukses.
4. Belum terbukti apakah metode ini cukup efisien karena
usianya yang relatif baru.
5. Memerlukan penaksiran risiko yang masuk akal dan akan
menjadi masalah yang serius jika risiko mayor tidak ditemukan
dan diatur.
 6. Butuh waktu lama untuk menerapkan paradigma ini menuju
kepastian yang absolut.

4.1.4 Model Proses Konkuren

Concurrent development model adalah cara/proses pengembangan yang
pada dasarnya adalah rangkaian dari kegiatan teknis, tugas, dan hubungan
saling terkait dengan kegiatan seperti analisis desain atau komunikasi.
Aktifitas dalam model ini dilakukan secara simultan, setiap aktifitas kerja
saling terkait dengan aktifitas kerja lain. Concurrent Development Model
yang biasa disebut dengan Concurrent Engineering adalah pengembangan
berdasarkan parelisasi (yaitu melakukan tugas secara bersamaan).
Pengembangan Concurrent development model terjadi seiring dengan
analisis yang dilakukan terhadap pengembangan model lainnya seperti
model Inkremental, waterfall, dll. Di mana pada model Concurrent
Development Model ini waktu yang diperlukan untuk membawa produk
ke pasar relatif lebih singkat. Concurrent Development Model Mirip
model spiral, biasa digunakan dalam pengembangan aplikasi client /
server.

Gambar Berikut Memberikan representasi skematis dari satu kegiatan

dengan model proses bersamaan. Aktivitas-Analisis-mungkin dalam salah
satu dari state yang tercatat pada waktu tertentu. State adalah beberapa
cara eksternal yang dapat diamati perilakunya. Masing-masing kegiatan
pada jaringan ada persamaan dengan kegiatan lain dan bisa dimulai/
Diperbarui dari semua step. Sebagian besar model Proses pengembangan
perangkat lunak didorong oleh waktu, kemauan yang kemudian itu, dalam
proses pengembangan Perangkat Lunak.
.
4.2 Proses Model Khusus
4.2.1 Component-Based Development
Komponen perangkat lunak komersial off-the-shelf (COTS), yang
dikembangkan oleh vendor yang menawarkannya sebagai produk,
menyediakan fungsionalitas yang ditargetkan dengan antarmuka yang
terdefinisi dengan baik yang memungkinkan komponen diintegrasikan ke
dalam perangkat lunak yang akan dibangun. Model pengembangan
berbasis komponen menggabungkan banyak karakteristik dari model
spiral. Ini bersifat evolusioner, menuntut pendekatan berulang untuk
pembuatan perangkat lunak. Namun, model pengembangan berbasis
komponen terdiri dari aplikasi dari komponen perangkat lunak yang
dikemas sebelumnya.
Kegiatan pemodelan dan konstruksi dimulai dengan identifikasi
komponen kandidat. Komponen-komponen ini dapat dirancang sebagai
modul perangkat lunak konvensional atau kelas atau paket berorientasi
objek kelas. Terlepas dari teknologi yang digunakan untuk membuat
komponen, model pengembangan berbasis komponen menggabungkan
langkah-langkah berikut (diimplementasikan menggunakan pendekatan
evolusi):
1. Produk berbasis komponen yang tersedia diteliti dan dievaluasi
untuk domain aplikasi yang dimaksud.
2. Masalah integrasi komponen dipertimbangkan.
3. Arsitektur perangkat lunak dirancang untuk mengakomodasi
komponen.
4. Komponen diintegrasikan ke dalam arsitektur.
5. Pengujian komprehensif dilakukan untuk memastikan
fungsionalitas yang tepat.
4.2.2 Model Metode Formal
Model metode formal mencakup serangkaian kegiatan yang mengarah
pada spesifikasi matematika formal perangkat lunak komputer. Metode
formal memungkinkan Anda menentukan, mengembangkan, dan
memverifikasi sistem berbasis komputer dengan menerapkan notasi
matematika yang ketat. Variasi pada pendekatan ini, yang disebut
rekayasa perangkat lunak cleanroom, saat ini diterapkan oleh beberapa
organisasi pengembangan perangkat lunak.
Meskipun bukan pendekatan utama, model metode formal menawarkan
janji perangkat lunak bebas cacat. Namun, kekhawatiran tentang
penerapannya dalam lingkungan bisnis telah disuarakan:
1. Pengembangan model formal saat ini cukup memakan waktu dan
mahal.
2. Karena beberapa pengembang perangkat lunak memiliki latar
belakang yang diperlukan untuk menerapkan metode formal,
pelatihan ekstensif diperlukan.
3. Sulit untuk menggunakan model sebagai mekanisme komunikasi
untuk pelanggan yang secara teknis tidak canggih.
4.2.3 Aspect-Oriented Software Development
Terlepas dari proses perangkat lunak yang dipilih, pembangun perangkat
lunak yang kompleks selalu menerapkan serangkaian fitur, fungsi, dan
 konten informasi yang dilokalkan. Karakteristik perangkat lunak yang
dilokalkan ini dimodelkan sebagai komponen (mis., Kelas berorientasi
objek) dan kemudian dibangun dalam konteks arsitektur sistem. Ketika
sistem berbasis komputer modern menjadi lebih canggih (dan kompleks),
kekhawatiran tertentu — properti yang dibutuhkan pelanggan atau bidang
minat teknis — menjangkau seluruh arsitektur. Beberapa masalah adalah
sifat tingkat tinggi dari suatu sistem (mis., Keamanan, toleransi
kesalahan). Masalah lain memengaruhi fungsi (mis., Penerapan aturan
bisnis), sementara yang lain bersifat sistemik (mis., Sinkronisasi tugas
atau manajemen memori).
4.3 Unified Process
Unified Process (UP) adalah kerangka kerja proses pengembangan perangkat lunak
yang iterative dan incremental. Penyempurnaan Unified Process yang paling terkenal
dan banyak didokumentasikan adalah Rational Unified Process (RUP). Contoh lain
adalah OpenUP dan Agile Unified Process. Dalam buku seminal tentang Unified
Process, Ivar Jacobson, Grady Booch, dan James Rumbaugh membahas perlunya
proses perangkat lunak yang "use case driven, arsitechture-centric, iterative, dan
incremental". Dalam beberapa hal, unified process adalah upaya untuk memanfaatkan
fitur dan karakteristik terbaik dari model proses perangkat lunak tradisional, namun
mengkategorikannya dengan cara mengimplementasikan banyak prinsip terbaik dari
agile software development. Unified process mengakui pentingnya komunikasi kepada
pelanggan dan metode yang sederhana untuk menggambarkan pandangan pelanggan
tentang suatu sistem (use case). Ini menekankan peran penting arsitektur perangkat
lunak dan membantu arsitek fokus pada tujuan yang tepat, seperti understandability,
bergantung pada perubahan di masa depan, dan penggunaan kembali [Jac99]. Model
ini menganjurkan aliran proses yang iterative dan incremental, memberikan nuansa
evolusi yang penting dalam pengembangan perangkat lunak modern
4.3.1 Sejarah
Selama awal 1990-an James Rumbaugh, Grady Booch[4], dan Ivar
Jacobson mulai bekerja pada "unified method" yang akan menggabungkan
fitur terbaik dari analisis berorientasi objek dan metode desain setiap
model dan mengadopsi fitur tambahan yang diusulkan oleh para ahli lain
dalam pemodelan berorientasi objek. Hasilnya adalah UML — unified
modelling language yang berisi notasi yang kuat untuk pemodelan dan
pengembangan sistem berorientasi objek. Pada 1997, UML menjadi
standar industri de facto untuk pengembangan perangkat lunak
berorientasi objek. UML menyediakan teknologi yang diperlukan untuk
mendukung praktik rekayasa perangkat lunak berorientasi objek, tetapi
tidak memberikan kerangka kerja proses untuk memandu tim proyek
dalam penerapan teknologi mereka. Selama beberapa tahun ke depan,
Jacobson, Rumbaugh, dan Booch mengembangkan unified process,
kerangka kerja untuk rekayasa perangkat lunak berorientasi objek
menggunakan UML. Saat ini, Unified Process (UP) dan UML banyak
digunakan pada proyek berorientasi objek dari semua jenis. Model iteratif,
tambahan yang diusulkan oleh UP dapat dan harus disesuaikan untuk
memenuhi kebutuhan proyek tertentu
4.3.2 Fase dalam Unified Process
Terdapat lima kegiatan dalam kerangka kerja umum dan dapat digunakan
untuk menggambarkan model proses perangkat lunak apapun. Unified
process tidak terkecuali.
Fase awal (inception) UP mencakup komunikasi (comminication)
pelanggan dan aktivitas perencanaan (planning). Dengan berkolaborasi
dengan pemangku kepentingan, kebutuhan bisnis untuk perangkat lunak
diidentifikasi; arsitektur kasar untuk sistem diusulkan; dan sebuah rencana
untuk sifat iterative, sifat incremental dari proyek berikutnya
dikembangkan. Kebutuhan bisnis mendasar dijelaskan melalui
serangkaian use case awal yang menggambarkan fitur dan fungsi mana
yang diinginkan oleh setiap kelas utama pengguna. Arsitektur pada titik
ini tidak lebih dari garis besar tentatif dari subsistem utama dan fungsi dan
fitur yang mengisi mereka. Nantinya, arsitektur akan disempurnakan dan
diperluas menjadi seperangkat model yang akan mewakili pandangan
berbeda dari sistem. Proses perencanaan mengidentifikasi sumber daya,
menilai risiko utama, menentukan jadwal, dan menetapkan dasar untuk
fase-fase yang akan diterapkan ketika peningkatan (increment) perangkat
lunak dikembangkan.
Tahap elaborasi (elaboration) meliputi kegiatan komunikasi dan
pemodelan model proses generik. Pada tahap elaborasi, use case awal
yang dikembangkan sebagai bagian dari fase awal (inception) dan
memperluas representasi arsitektur untuk memasukkan lima pandangan
yang berbeda dari perangkat lunak - use case model, model kebutuhan
(requirement), model desain (design), model implementasi
(implementation), dan model penyebaran (deployment) akan diperbaiki
dan diperluas. Dalam beberapa kasus, elaborasi menciptakan "garis dasar
arsitektur yang dapat dieksekusi" yang mewakili "first cut" sistem yang
dapat dieksekusi. Garis dasar arsitektur menunjukkan kelayakan arsitektur
tetapi tidak menyediakan semua fitur dan fungsi yang diperlukan untuk
menggunakan sistem. Selain itu, rencana tersebut ditinjau dengan saksama
pada puncak fase elaborasi untuk memastikan bahwa ruang lingkup,
risiko, dan tanggal pengiriman tetap masuk akal. Modifikasi rencana
sering dilakukan pada saat ini.
Fase konstruksi (construction) UP identik dengan aktivitas konstruksi
yang ditentukan untuk proses perangkat lunak generik. Menggunakan
model arsitektur sebagai input, fase konstruksi mengembangkan atau
memperoleh komponen perangkat lunak yang akan membuat setiap use
case operasional untuk pengguna akhir. Untuk mencapai hal ini,
kebutuhan dan model desain yang dimulai selama fase elaborasi
diselesaikan untuk mencerminkan versi akhir dari software increment.
Semua fitur dan fungsi yang diperlukan untuk software increment (mis.
Rilis) kemudian diimplementasikan dalam kode (source code). Ketika
komponen sedang diimplementasi, unit test dirancang dan dieksekusi
untuk masing-masing komponen. Selain itu, kegiatan integrasi (perakitan
komponen dan pengujian integrasi) dilakukan. Use case digunakan untuk
memperoleh serangkaian acceptance test yang dieksekusi sebelum
dimulainya fase UP berikutnya.
 Fase transisi (transition) UP mencakup tahap selanjutnya dari aktivitas
konstruksi generik (construction) dan bagian pertama dari aktivitas
penyebaran (deployment) generik. Perangkat lunak diberikan kepada
pengguna akhir untuk pengujian beta dan laporan umpan balik pengguna
baik cacat maupun perubahan yang diperlukan. Selain itu, tim perangkat
lunak membuat informasi dukungan yang diperlukan (mis., Buku
petunjuk, panduan pemecahan masalah, prosedur pemasangan) yang
diperlukan untuk rilis. Pada akhir fase transisi, software increment
menjadi xperangkat lunak yang dapat digunakan.
Fase produksi (production) UP bertepatan dengan aktivitas penyebaran
(deployment) proses generik. Selama fase ini, penggunaan perangkat
lunak yang sedang berlangsung dimonitor, dukungan untuk lingkungan
operasi (infrastruktur) disediakan, dan laporan cacat serta permintaan
untuk perubahan diajukan dan dievaluasi.
Sangat mungkin bahwa pada saat yang tahap konstruksi, transisi, dan
produksi sedang dilakukan, pekerjaan mungkin sudah dimulai pada
software increment berikutnya. Ini berarti bahwa lima fase UP tidak
terjadi secara berurutan, melainkan lebih cenderung bersamaan. Alur kerja
rekayasa perangkat lunak didistribusikan di semua fase UP. Dalam
konteks UP, alur kerja analog dengan set tugas Artinya, alur kerja
mengidentifikasi tugas yang diperlukan untuk menyelesaikan tindakan
rekayasa perangkat lunak yang penting dan produk kerja yang dihasilkan
sebagai konsekuensi dari berhasil menyelesaikan tugas. Perlu dicatat
bahwa tidak setiap tugas yang diidentifikasi untuk alur kerja UP dilakukan
untuk setiap proyek perangkat lunak. Tim mengadaptasi proses (tindakan,
tugas, subtugas, dan produk kerja) untuk memenuhi kebutuhannya.
4.4 Proses Personal dan Tim
4.4.1 Proses Personal
Model PSP mendefinisikan lima kegiatan kerangka kerja:
Planning: Kegiatan ini mengisolasi kebutuhan dan mengembangkan
estimasi ukuran dan sumber daya. Selain itu, perkiraan cacat (jumlah cacat
yang diproyeksikan untuk pekerjaan) dibuat. Semua metrik dicatat di
lembar kerja atau templat. Akhirnya, tugas pengembangan diidentifikasi
dan jadwal proyek dibuat.
High-level design: Spesifikasi eksternal untuk setiap komponen yang akan
dibangun dikembangkan dan desain komponen dibuat. Prototipe dibangun
ketika ada ketidakpastian. Semua masalah dicatat dan dilacak.
High-level design review: Metode verifikasi formal diterapkan untuk
mengungkap kesalahan dalam desain. Metrik dipertahankan untuk semua
tugas penting dan hasil kerja.
Development: Desain tingkat komponen disempurnakan dan ditinjau.
Kode dihasilkan, ditinjau, disusun, dan diuji. Metrik dipertahankan untuk
semua tugas penting dan hasil kerja.
Postmortem: Dengan menggunakan ukuran dan metrik yang dikumpulkan
(ini adalah jumlah substansial data yang harus dianalisis secara statistik),
efektivitas proses ditentukan. Ukuran dan metrik harus memberikan
panduan untuk memodifikasi proses untuk meningkatkan efektivitasnya.
4.4.2 Proses Tim
 Tujuan TSP adalah untuk membangun tim proyek "mandiri" yang
mengatur sendiri untuk menghasilkan perangkat lunak berkualitas tinggi.
Humphrey mendefinisikan tujuan TSP berikut:
Membangun tim mandiri yang merencanakan dan melacak pekerjaan
mereka, menetapkan tujuan, dan memiliki proses dan rencana mereka
sendiri. Ini bisa berupa tim perangkat lunak murni atau tim produk
terintegrasi (Integrated Product Teams) dari 3 hingga sekitar 20 praktisi.
Menunjukkan kepada manajer bagaimana melatih dan memotivasi tim
mereka dan bagaimana membantu mereka mempertahankan kinerja
puncak.
Mempercepat peningkatan proses perangkat lunak dengan membuat
perilaku Level 5 CMM menjadi normal dan diharapkan.
Memberikan panduan peningkatan untuk organisasi dengan kematangan
tinggi.
Memfasilitasi pengajaran universitas tentang keterampilan tim kelas
industri.
4.5 Teknologi Proses
Satu atau lebih model proses yang dibahas pada bagian sebelumnya harus disesuaikan
untuk digunakan oleh tim perangkat lunak. Untuk mencapai ini, proses alat teknologi
telah dikembangkan untuk membantu organisasi perangkat lunak menganalisis proses
mereka saat ini, mengatur tugas kerja, mengontrol dan memantau kemajuan, dan
mengelola kualitas teknis.
Alat teknologi proses memungkinkan organisasi perangkat lunak untuk membangun
model otomatis dari kerangka kerja proses, set tugas, dan kegiatan payung yang
dibahas dalam Bab 3. Model, yang biasanya direpresentasikan sebagai jaringan,
kemudian dapat dianalisis untuk menentukan aliran kerja khas dan memeriksa proses
alternatif. struktur yang mungkin menyebabkan berkurangnya waktu pengembangan
atau biaya.
Setelah proses yang dapat diterima telah dibuat, alat teknologi proses lainnya dapat
digunakan untuk mengalokasikan, memantau, dan bahkan mengendalikan semua
kegiatan, tindakan, dan tugas rekayasa perangkat lunak yang ditetapkan sebagai
bagian dari model proses. Setiap anggota tim perangkat lunak dapat menggunakan alat
tersebut untuk mengembangkan daftar tugas pekerjaan yang akan dilakukan, produk
kerja yang akan diproduksi, dan kegiatan jaminan kualitas yang akan dilakukan. Alat
teknologi proses juga dapat digunakan untuk mengoordinasikan penggunaan alat
rekayasa perangkat lunak lain yang sesuai untuk tugas kerja tertentu.
4.6 Produk dan Proses
Jika prosesnya lemah, produk akhirnya pasti akan menderita. Tetapi ketergantungan
yang berlebihan pada proses juga berbahaya. Orang-orang memperoleh sebanyak (atau
lebih) kepuasan dari proses kreatif seperti yang mereka lakukan dari produk akhir.
Seorang seniman menikmati sapuan kuas sebanyak hasil yang dibingkai. Seorang
penulis menikmati pencarian metafora yang tepat seperti halnya buku yang telah
selesai. Sebagai profesional perangkat lunak kreatif, Anda juga harus mendapatkan
kepuasan sebanyak dari proses sebagai produk akhir. Dualitas produk dan proses
adalah salah satu elemen penting dalam menjaga orang-orang kreatif terlibat ketika
rekayasa perangkat lunak terus berkembang.