Personal Software Process

Alur Personal Software process

Struktur proses PSP konseptual ditunjukkan dalam gambar 1. Dimulai dengan
persyaratan
-langkah pertama dalam proses PSP adalah perencanaan. Ada perencanaan script
yang memandu pekerjaan ini dan ringkasan rencana untuk merekam data
perencanaan.
-Sementara para engineer mengikuti script untuk yang dilkerjakan, mereka
merekam data waktu dan cacat mereka pada waktu dan log Cacat.
-Pada akhir pekerjaan, selama fase postmortem (PM), mereka meringkas
waktu dan Cacat data dari log, mengukur ukuran program, dan memasukkan
data ini dalam rencana bentuk ringkasan.
-Ketika selesai, mereka memberikan produk jadi bersama dengan rencana selesai
bentuk ringkasan. Salinan rencana PSP1 ringkasan ditunjukkan dalam tabel 1.

PSP struktur
Pelatihan PSP berikut pendekatan perbaikan evolusi: seorang engineer belajar untuk
mengintegrasikan PSP ke dalam proses nya dimulai di tingkat pertama - PSP0 - dan berlangsung

dalam proses kedewasaan untuk tingkat akhir - PSP2.1. Setiap Tingkat telah rinci skrip, daftar
periksa dan template untuk memandu engineer melalui langkah-langkah yang diperlukan dan
membantu engineer meningkatkan proses perangkat lunak pribadinya sendiri. Humphrey
mendorong engineer mahir untuk menyesuaikan script ini dan template karena mereka memperoleh
pemahaman tentang kekuatan dan kelemahan mereka sendiri.
Proses
Input ke PSP adalah persyaratan; dokumen persyaratan selesai dan dikirim ke engineer.
PSP0, PSP0.1 (Memperkenalkan disiplin proses dan pengukuran)
PSP0 memiliki 3 fase: perencanaan, pengembangan (desain, coding, test) dan post
mortem. Sebuah dasar didirikan dari proses pengukuran saat ini: waktu yang dihabiskan untuk
pemrograman, kesalahan disuntikkan / dihapus, ukuran dari sebuah program. Dalam post mortem,
engineer memastikan semua data untuk proyek telah dicatat dengan benar dan dianalisis. PSP0.1
kemajuan proses dengan menambahkan standar coding, pengukuran ukuran dan pengembangan
rencana perbaikan proses pribadi (PIP). Dalam PIP, ide-ide catatan engineer untuk meningkatkan
proses sendiri.
PSP1, PSP1.1 (Memperkenalkan memperkirakan dan perencanaan)
Berdasarkan data dasar dikumpulkan dalam PSP0 dan PSP0.1, perkiraan engineer seberapa besar
program baru akan dan menyiapkan laporan uji (PSP1). Akumulasi data dari proyek-proyek
sebelumnya digunakan untuk memperkirakan total waktu. Setiap proyek baru akan mencatat waktu
aktual yang dihabiskan. Informasi ini digunakan untuk tugas dan jadwal perencanaan dan estimasi
(PSP1.1).
PSP2, PSP2.1 (manajemen mutu Memperkenalkan dan desain)
PSP2 menambahkan dua fase baru: Ulasan desain dan kode ulasan. Pencegahan cacat dan
penghapusan dari mereka adalah fokus pada PSP2 ini. Engineer belajar untuk mengevaluasi dan
meningkatkan proses mereka dengan mengukur berapa lama tugas mengambil dan jumlah cacat
mereka menyuntikkan dan menghapus dalam setiap tahapan pembangunan. Engineer membangun
dan menggunakan daftar periksa untuk desain dan kode ulasan. PSP2.1 memperkenalkan
spesifikasi desain dan analisis teknik
(PSP3 adalah tingkat warisan yang telah digantikan oleh TSP.)

Tujuan [sunting]

PSP bertujuan untuk memberikan engineer perangkat lunak dengan metode disiplin untuk
meningkatkan proses pengembangan perangkat lunak pribadi. PSP membantu engineer perangkat
lunak untuk:

Meningkatkan estimasi dan perencanaan keterampilan mereka.

Membuat komitmen mereka dapat menjaga.

Mengelola kualitas proyek-proyek mereka.

Mengurangi jumlah cacat dalam pekerjaan mereka.

Pentingnya data [sunting]

Salah satu aspek inti dari PSP menggunakan data historis untuk menganalisis dan meningkatkan
kinerja proses. Pengumpulan data PSP didukung oleh empat unsur utama:

Script

Tindakan

Standar

Bentuk

PSP script menyediakan bimbingan ahli-tingkat untuk mengikuti langkah-langkah proses dan
mereka menyediakan kerangka kerja untuk menerapkan langkah-langkah PSP. PSP memiliki empat
langkah utama:

Ukuran - ukuran ukuran untuk bagian produk, seperti baris kode (LOC).

Upaya - waktu yang dibutuhkan untuk menyelesaikan tugas, biasanya disimpan di menit.

Kualitas - jumlah cacat pada produk.

Jadwal - ukuran kemajuan proyek, dilacak terhadap tanggal penyelesaian yang direncanakan
dan aktual.

Menerapkan standar untuk proses dapat memastikan data yang tepat dan konsisten. Data dicatat
dalam bentuk, biasanya menggunakan perangkat lunak PSP. SEI telah mengembangkan alat PSP
dan ada juga pilihan open source yang tersedia, seperti Dashboard Proses.
Data kunci dikumpulkan dalam alat PSP adalah waktu, cacat, dan ukuran data - waktu yang
dihabiskan di setiap fase; kapan dan di mana cacat disuntik, ditemukan, dan tetap; dan ukuran
bagian-bagian produk. Pengembang perangkat lunak menggunakan banyak langkah-langkah lain
yang berasal dari tiga langkah dasar ini untuk memahami dan meningkatkan kinerja
mereka. Tindakan berasal meliputi:

akurasi estimasi (ukuran / waktu)

interval prediksi (ukuran / waktu)

waktu dalam distribusi fase

distribusi injeksi cacat

distribusi penghapusan cacat

produktivitas

Persentase penggunaan kembali

Indeks kinerja biaya

Nilai direncanakan

nilai yang diterima

diprediksi nilai yang diterima

kerapatan cacat

kerapatan cacat oleh fase

tingkat penghapusan cacat oleh fase

Leverage penghapusan cacat

tarif ulasan

proses hasil

fase hasil

biaya kegagalan kualitas (COQ)

appraisal COQ

appraisal / kegagalan rasio COQ

Perencanaan dan pelacakan [sunting]

Logging waktu, cacat, dan ukuran data merupakan bagian penting dari perencanaan dan pelacakan
proyek PSP, sebagai data historis digunakan untuk meningkatkan memperkirakan akurasi.
PSP menggunakan Proxy Berbasis Estimasi metode (PROBE) untuk meningkatkan keterampilan
memperkirakan pengembang untuk perencanaan proyek yang lebih akurat. Untuk pelacakan
proyek, PSP menggunakan nilai yang diperoleh metode.
PSP juga menggunakan teknik statistik, seperti korelasi, regresi linier, dan standar deviasi, untuk
menerjemahkan data menjadi informasi yang berguna untuk meningkatkan memperkirakan,
perencanaan dan kualitas. Ini rumus statistik yang dihitung dengan alat PSP.

Menggunakan PSP [sunting]

PSP ini dimaksudkan untuk membantu pengembang meningkatkan proses pribadi mereka; Oleh
karena itu pengembang PSP diharapkan untuk terus beradaptasi proses untuk memastikan
memenuhi kebutuhan pribadi mereka.

PSP dan TSP [sunting]

Dalam prakteknya, keterampilan PSP digunakan dalam lingkungan tim TSP. Tim TSP terdiri dari
PSP terlatih pengembang yang relawan untuk bidang tanggung jawab proyek, sehingga proyek ini
dikelola oleh tim itu sendiri. Menggunakan data pribadi yang dikumpulkan menggunakan
keterampilan PSP mereka; tim membuat rencana, perkiraan, dan kontrol kualitas.
Menggunakan metode proses PSP dapat membantu tim TSP untuk memenuhi komitmen jadwal
mereka dan menghasilkan perangkat lunak berkualitas tinggi.Misalnya, menurut penelitian oleh
Watts Humphrey, sepertiga dari semua perangkat lunak proyek gagal, [2] tetapi studi SEI pada 20
TSP proyek di 13 organisasi yang berbeda menemukan bahwa tim TSP terjawab jadwal target
mereka rata-rata hanya enam persen. [ 3]
Berhasil memenuhi komitmen jadwal dapat dikaitkan dengan menggunakan data historis untuk
membuat perkiraan yang lebih akurat, sehingga proyek didasarkan pada rencana yang realistis dan dengan menggunakan metode kualitas PSP, mereka menghasilkan software rendah cacat,
yang mengurangi waktu yang dihabiskan untuk menghapus cacat pada tahap selanjutnya, seperti
integrasi dan pengujian penerimaan.

PSP dan metodologi lain [sunting]

PSP adalah proses pribadi yang dapat disesuaikan dengan kebutuhan pengembang individu. Hal ini
tidak spesifik untuk setiap pemrograman atau metodologi desain;oleh karena itu dapat digunakan
dengan metodologi yang berbeda, termasuk pengembangan perangkat lunak Agile.
Metode rekayasa perangkat lunak dapat dianggap bervariasi dari prediksi melalui adaptif. PSP
adalah metodologi prediksi, dan Agile dianggap adaptif, tetapi meskipun perbedaan mereka, TSP /
PSP dan Agile berbagi beberapa konsep dan pendekatan - khususnya dalam hal organisasi
tim. Mereka berdua memungkinkan tim untuk:

Tentukan tujuan dan standar mereka.

Memperkirakan dan jadwal pekerjaan.

Tentukan jadwal realistis dan dapat dicapai.

Membuat rencana dan perbaikan proses.

Kedua Agile dan TSP / PSP berbagi ide anggota tim bertanggung jawab untuk pekerjaan mereka
sendiri dan bekerja sama untuk menyetujui rencana yang realistis, menciptakan lingkungan
kepercayaan dan akuntabilitas. Namun, TSP / PSP berbeda dari Agile dalam penekanan pada
mendokumentasikan proses dan penggunaannya data untuk memprediksi dan menentukan jadwal
proyek.

Kualitas [sunting]
Software berkualitas tinggi adalah tujuan dari PSP, dan kualitas diukur dalam hal cacat. Untuk PSP,
proses mutu harus menghasilkan software rendah cacat yang memenuhi kebutuhan pengguna.
PSP struktur fase memungkinkan pengembang PSP untuk menangkap cacat awal. Dengan
penangkapan cacat awal, PSP dapat mengurangi jumlah waktu yang dihabiskan di tahap
selanjutnya, seperti Test.
PSP teori adalah bahwa hal itu lebih ekonomis dan efektif untuk menghilangkan cacat sedekat
mungkin ke mana dan kapan mereka disuntik, sehingga engineer perangkat lunak didorong untuk
melakukan ulasan pribadi untuk setiap tahap pembangunan. Oleh karena itu struktur fase PSP
mencakup dua fase ulasan:

Desain Ulasan

Kode Ulasan

Untuk melakukan kajian yang efektif, Anda perlu mengikuti proses review terstruktur. PSP
merekomendasikan menggunakan daftar periksa untuk membantu pengembang untuk konsisten
mengikuti prosedur yang teratur.
PSP mengikuti premis bahwa ketika orang membuat kesalahan, kesalahan mereka biasanya
diprediksi, sehingga para pengembang PSP dapat mempersonalisasikan daftar periksa mereka
untuk menargetkan kesalahan umum mereka sendiri. Engineer perangkat lunak juga diharapkan
untuk menyelesaikan proposal perbaikan proses, untuk mengidentifikasi bidang kelemahan dalam
kinerja mereka saat ini bahwa mereka harus menargetkan untuk perbaikan. Data proyek historis,
yang mengekspos mana waktu yang dihabiskan dan cacat diperkenalkan, bantuan pengembang
untuk mengidentifikasi daerah-daerah untuk meningkatkan.
Pengembang PSP juga diharapkan untuk melakukan ulasan pribadi sebelum pekerjaan mereka
mengalami rekan atau tim ulasan.

Sertifikasi [sunting]
Sebuah sertifikasi meliputi PSP ditawarkan oleh SEI di Carnegie Mellon University. Langkahlangkah untuk menjadi PSP Developer SEI Bersertifikat adalah: mempelajari PSP; mengambil ujian
sertifikasi; mempertahankan identitasnya. PSP Pemeriksaan Developer berdasarkan konsep yang
ditemukan dalam tubuh PSP Pengetahuan. [4] The SEI mempertahankan FAQ [5] pada sertifikasi.

https://en.wikipedia.org/wiki/Personal_software_process

Manfaat/keuntungan PSP.
Kerja keras untuk menstabilkan personal sofware
process, tetapikerja keras ini akan menanggung banyak manfaat untuk programmer.
Data dan analisis akan menawarkan apresiasi terhadap kekuatan dan kelemahan Anda.
Data dan analisis berikutnya akan mengarah ke ide-ide yang tak terhitung untuk
perbaikan proses.
Anda memiliki kontrol menyeluruh jadwal Anda, menerima hanya komitmen yang
Anda dapat membuat. Jika Anda dihadapkan dengan tekanan yang tidak masuk
akal, Anda dapat membuka database kinerja historis Anda dan membuktikan hal
ini tidak mungkin bagi Anda untuk membuat komitmen.
Anda mendapatkan rasa prestasi pribadi.
Bagian kualitas PSP akan membantu Anda dalam memproduksi produk kerja yang lebih baik.
Anggota tim akan memiliki keyakinan Anda karena Anda disiplin dalam
mengembangkan produk.

Kerugian dari PSP.

Meskipun PSP mengikuti aturan ketat dan memaksa para programmer untuk menjadi eksplisitpada d
ata kinerja nya, PSP masih memiliki kekurangan.
Proxy pengukuran baris kode yang digunakan dalam PSP memiliki kekurangan (Damian, 199
6):
o LOC tergantung bahasa.
o Tidak setiap engineer setuju pada apa yang merupakan satu Logis baris kode.
o LOC sulit untuk memvisualisasikan dalam fase rencana dan desain.
PSP hanya membutuhkan perkiraan waktu gangguan, ketimbang memaksa pengguna untuk
capwaktu sebuah gangguan. Hal ini membuat estimasi waktu gangguan yang dapat bias.
Metode PROBE akan efektif jika ada tidak ada korelasi antara titik data historis.
Desain template untuk PSP 2.1 dapat berlebihan untuk programmer yang sudah memiliki aks
es kealat desain perangkat lunak eksternal.
Menentukan potongan baru kode sebagai reusable subyektif.
Tidak setiap engineer dilihat definisi produktivitas dengan cara yang sama.
PSP secara khusus ditujukan pada pengembangan perangkat
lunak dan tidak memperhitungkanwaktu yang dihabiskan negosiasi persyaratan dengan pela
nggan. Fasa persyaratan adalahkomponen kunci dari setiap proyek.
Mengikuti PSP ke huruf ini tidak layak untuk kebanyakan engineer. Engineer harus didorong untukm
emperlakukan PSP sebagai kerangka kerja untuk pengembangan kualitas perangkat
lunakpengembangan praktek. Setiap metode yang harus disesuaikan untuk engineer sendiri teknolo
gi,praktek, kekuatan, dan kelemahan. Hal ini juga penting untuk dicatat bahwa metrik yang adauntuk
mengevaluasi proses, tidak engineer sebagai orang.
http://www.issi.uned.es/AGDS/documentos/otros/resumen_PS.htm

Karakteristik
Setiap engineer berbeda; untuk menjadi paling efektif, engineer harus merencanakan pekerjaanmer
eka dan mereka
harus mendasarkan rencana mereka pada data pribadi mereka sendiri.
Untuk secara konsisten meningkatkan kinerja mereka, engineer harus secara
pribadimenggunakan didefinisikan dengan baik
dan diukur proses.
Untuk menghasilkan produk berkualitas, engineer harus merasa secara pribadi bertanggung
jawab untuk kualitas
produkproduk mereka. Produk unggulan yang tidak diproduksi oleh kesalahan; engineer harusberusaha
keras untuk
kualitas kerja.
Biaya kurang untuk menemukan dan memperbaiki cacat sebelumnya dalam proses daripadananti.
Ini lebih efisien untuk mencegah cacat dari untuk menemukan dan memperbaiki mereka.
Cara yang tepat adalah selalu cara tercepat dan termurah untuk melakukan pekerjaan.

www.sei.cmu.edu/reports/00tr022.pdf

Team Software Process

Alur Team Software Process
Tim TSP yang diluncurkan kembali secara berkala. Karena proses TSP mengikuti
berulang-ulang dan berkembang strategi pembangunan relaunches periodik diperlukan sehingga
bahwa setiap fase atau siklus dapat direncanakan berdasarkan pengetahuan yang diperoleh
alam siklus sebelumnya.
Peluncuran ini juga diperlukan untuk memperbarui rencana rinci para engineer, yang biasanya akurat
hanya beberapa bulan. Alasan untuk memiliki peluncuran adalah bahwa rencana rinci hanya dapat
akurat selama beberapa bulan. Dalam peluncuran TSP, tim membuat keseluruhan rencana dan
rencana rinci
untuk tentang tiga sampai empat bulan ke depan. Setelah tim anggota telah menyelesaikan
semua atau sebagian
Proyek fase berikutnya atau siklus, mereka merevisi keseluruhan rencana jika diperlukan dan
membuat baru rinci
rencana untuk menutupi tiga sampai empat bulan ke depan. Mereka akan dipandu dalam melakukan
hal ini dengan TSP
peluncuran proses.

www.sei.cmu.edu/reports/10tr020.pdf

Keuntungan

Proyek-proyek yang berhasil menggunakan TSP memiliki resiko rendah kegagalan.

Proyekproyek TSP telah terbukti berhasil dalam membangun tim termotivasi yang sangat efektif.Buil
tin proses peningkatan aspek TSP memastikan bahwa data dikumpulkan feed kembali kekegia
tan tim, membantu untuk menyoroti isu-isu dan mengarah ke resolusi.
TSP dapat digunakan sebagai kendaraan untuk proses perbaikan dalam sebuah organisasi. Ti
mdapat mengadopsi TSP dan menggunakannya untuk mengidentifikasi dan menerapkan per
baikanproses.
TSP scalable dari satu tim antara dua dan dua puluh orang beberapa tim benarbenar 100 hingga150 orang.

https://en.wikiversity.org/wiki/Plan-driven_software_development#Benefits

Kekurangan
Untuk mengelola kualitas, tim harus mendirikan kualitas tindakan, menetapkan Tujuan
berkualitas,membangun rencana untuk

memenuhi tujuan tersebut, mengukur kemajuan terhadap rencana dan mengambil tindakan
perbaikan ketika tujuan tidak terpenuhi. TSP tim menunjukkan bagaimana untuk melakukan hal
ini. Unsur-unsur TSP manajemen mutu
membuat rencana kualitas, mengidentifikasi masalah kualitas, dan menemukan dan mencegah
kualitas masalah.

Karakteristik :
Untuk menjadi efektif, tim harus benar terampil dan dapat bekerja sebagai unit yang kohesif.Efektif
tim memiliki karakteristik umum tertentu:
Anggota terampil.
Tujuan tim penting, didefinisikan, terlihat, dan realistis.
Tim sumber daya memadai untuk pekerjaan.
Anggota termotivasi dan bertekad untuk memenuhi tujuan tim.
Anggota bekerja sama dan saling mendukung.
Anggota disiplin dalam pekerjaan mereka.
Ciri lain dari tim yang efektif adalah kemampuan mereka untuk berinovasi. Inovasi adalah lebihdari
hanya memikirkan ide-ide cemerlang; Hal
ini membutuhkan kreativitas dan banyak kerja keras.Hampir setiap
teknik tugas adalah bagian dari upaya yang inovatif. Inovatif tim harus terampil dan
mampu orang-orang yang memiliki motivasi tinggi. Mereka harus kreatif, fleksibel, dan disiplin.
Mereka harus berusaha untuk memenuhi jadwal menuntut sementara menyesuaikan
diri denganperubahan kebutuhan. Mereka harus
juga mengontrol biaya dan jadwal sambil manajemen informasi tentang kemajuan mereka.