Personal software process

Personal Software Process (PSP) adalah kerangka kerja proses pengembangan perangkat lunak yang dirancang untuk membantu pengembang perangkat lunak untuk lebih memahami dan meningkatkan kinerja mereka dengan membawa disiplin cara mereka mengembangkan perangkat lunak dan melacak prediksi dan pengembangan aktual dari kode mereka. Setiap pengembang menggunakan beberapa proses untuk membangun perangkat lunak komputer. Prosesnya mungkin sembarangan atau ad hoc; dapat berubah setiap hari; mungkin tidak efisien, tidak efektif, atau bahkan tidak sukses; tetapi prosesnya memang ada. Watts Humphrey ^[1] mengemukakan bahwa untuk mengubah personal process yang tidak efektif, seorang individu harus bergerak melalui empat fase, masing-masing membutuhkan pelatihan dan instrumentasi yang cermat. Personal Software Process (PSP) menekankan pengukuran pribadi dari work product yang dihasilkan dan kualitas hasil dari work product tersebut. Selain itu, PSP membuat praktisi bertanggung jawab atas perencanaan proyek (mis. memperkirakan dan menjadwalkan) dan memberdayakan praktisi untuk mengontrol kualitas semua work product perangkat lunak yang dikembangkan.^[2]

PSP menekankan perlunya mengidentifikasi kesalahan sejak dini dan memahami jenis kesalahan yang mungkin dilakukan. Hal ini dicapai melalui aktivitas penilaian ketat yang dilakukan pada semua work product yang dihasilkan. PSP mewakili pendekatan disiplin dan berbasis metrik untuk rekayasa perangkat lunak yang dapat menyebabkan guncangan budaya bagi banyak praktisi. Namun, ketika PSP benar-benar diperkenalkan kepada praktisi perangkat lunak^[3], peningkatan yang dihasilkan dalam produktivitas rekayasa perangkat lunak dan kualitas perangkat lunak adalah signifikan^[4]. Namun, PSP belum banyak diadopsi di seluruh industri. Alasannya, lebih berkaitan dengan sifat manusia dan kelemahan organisasiona daripada dengan hal yang berkaitan dengan kekuatan dan kelemahan pendekatan PSP. PSP adalah tantangan intelektual dan menuntut tingkat komitmen (oleh para praktisi dan manajer mereka) yang tidak selalu mungkin diperoleh. Pelatihan relatif panjang, dan biaya pelatihan tinggi. Tingkat pengukuran yang diperlukan secara budaya sulit bagi banyak praktisi perangkat lunak.^[2]

Evolusi Proses PSP

PSP memperkenalkan konsep proses dalam serangkaian langkah. Setiap langkah PSP, termasuk semua elemen dari langkah sebelumnya bersama dengan satu atau dua tambahan elemen. Memperkenalkan konsep-konsep ini satu per satu akan membantu para praktisi mempelajarai metode personal yang disiplin.^[3]

Personal Measurement (PSP0) adalah tempat dimulainya PSP. Pada langkah pertama ini, para praktisi mempelajari cara menerapkan formulir dan skrip PSP ke dalam pekerjaan pribadi mereka. Mereka melakukan ini dengan mengukur waktu pengembangan dan cacat. Ini memungkinkan para praktisi mengumpulkan data yang nyata dan praktis dan memberikan tolok ukur untuk mengukur kemajuan saat mempelajari dan mempraktikkan PSP. PSP0 memiliki tiga fase: planning, development (yang meliputi design, code, compile, dan test), dan postmortem. PSP0.1 menambahkan standar pengkodean, pengukuran ukuran, dan formulir Process Improvement Proposal (PIP). Formulir PIP memungkinkan para praktisi merekam masalah, isu, dan gagasan untuk digunakan nanti dalam meningkatkan prosesnya. Mereka juga melihat bagaimana formulir membantu mereka mengumpulkan dan menggunakan data proses.^[3]

Personal Planning (PSP1) memperkenalkan metode PROBE. praktisi menggunakan PROBE untuk memperkirakan ukuran dan waktu pengembangan untuk program baru berdasarkan data pribadi mereka [2]. PROBE menggunakan regresi linier untuk menghitung parameter estimasi, dan menghasilkan interval prediksi untuk menunjukkan ukuran dan kualitas estimasi waktu. Jadwal dan perencanaan tugas ditambahkan dalam PSP1.1. Dengan memperkenalkan perencanaan lebih awal, para praktisi mengumpulkan cukup data dari 10 PSP exercise untuk mendapatkan manfaat dari estimasi statistik PSP dan metode perencanaan.^[3]

Personal Quality (PSP2) memperkenalkan manajemen cacat (defect management). Dengan data cacat dari PSP exercise, praktisi membuat dan menggunakan checklist untuk desain dan meninjau kode (code review). Mereka belajar mengapa penting untuk fokus pada kualitas sejak awal dan cara meninjau program mereka secara efisien. Dari data mereka sendiri, mereka melihat bagaimana checklist dapat membantu mereka meninjau desain dan kode secara efektif serta bagaimana mengembangkan dan memodifikasi checklist ini ketika keterampilan dan praktik pribadi mereka berkembang. PSP2.1 memperkenalkan spesifikasi desain dan teknik analisis bersama dengan pencegahan cacat, analisis proses, dan tolok ukur proses. Dengan mengukur waktu tugas yang diambil dan jumlah cacat yang mereka injeksikan dan lepaskan dalam setiap fase proses, para praktisi belajar untuk mengevaluasi dan meningkatkan kinerja pribadi mereka.^[3]

Scalling Up (PSP3) adalah langkah PSP terakhir. Pada tingkat PSP ini, para praktisi juga mengeksplorasi metode verifikasi desain serta prinsip dan metode definisi proses.^[3]

Proses PSP0

PSP0 mendefinisikan lima kegiatan dalam kerangka kerja PSP ini:^[2]

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.^[2]

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.^[2]

High-level design review: Metode verifikasi formal diterapkan untuk mengungkap kesalahan dalam desain. Metrik dipertahankan untuk semua tugas penting dan hasil kerja.^[2]

Development: Desain tingkat komponen disempurnakan dan ditinjau. Kode dihasilkan, ditinjau, disusun, dan diuji. Metrik dipertahankan untuk semua tugas penting dan hasil kerja.^[2]

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.^[2]

Referensi

^ Humphrey, Watts S., 1927- (2000). Introduction to the team software process(sm). Addison-Wesley. ISBN 020147719X. OCLC 41315572.
^ ^a ^b ^c ^d ^e ^f ^g ^h Pressman, Roger S. (2015). Software engineering : a practitioner's approach. McGraw-Hill Education. ISBN 9781259253157. OCLC 949696534.
^ ^a ^b ^c ^d ^e ^f Humphrey, W.S. (1996-05). "Using a defined and measured Personal Software Process". IEEE Software. 13 (3): 77–88. doi:10.1109/52.493023. ISSN 0740-7459.
^ Ferguson, P., et al., “Results of Applying the Personal Software Process,” IEEE Computer,vol. 30, no. 5, May 1997, pp. 24–31

[1] Humphrey, Watts S., 1927- (2000). Introduction to the team software process(sm). Addison-Wesley. ISBN 020147719X. OCLC 41315572.

[:0-2] ^ ^a ^b ^c ^d ^e ^f ^g ^h Pressman, Roger S. (2015). Software engineering : a practitioner's approach. McGraw-Hill Education. ISBN 9781259253157. OCLC 949696534.

[:1-3] ^ ^a ^b ^c ^d ^e ^f Humphrey, W.S. (1996-05). "Using a defined and measured Personal Software Process". IEEE Software. 13 (3): 77–88. doi:10.1109/52.493023. ISSN 0740-7459.

[4] Ferguson, P., et al., “Results of Applying the Personal Software Process,” IEEE Computer,vol. 30, no. 5, May 1997, pp. 24–31

[1]

[2]

[3]

[4]