Team software process
Team Software Process (TSP) adalah kerangka kerja proses pengembangan perangkat lunak yang berkombinasi dengan Personal Software Process (PSP) untuk membantu tim manajer dan praktisi mengatur proyek dan menghasilkan perangkat lunak yang berkisar dalam ukuran dari proyek kecil dari several thousand lines of code (KLOC) sampai proyek yang sangat besar lebih dari setengah juta baris kode. TSP dimaksudkan untuk meningkatkan tingkat kualitas dan produktivitas proyek pengembangan perangkat lunak tim, untuk membantu mereka memenuhi biaya dan menjadwalkan komitmen untuk mengembangkan sistem perangkat lunak dengan lebih baik.[1][2][3]
Tujuan TSP adalah untuk membangun tim proyek "mandiri" yang mengatur sendiri untuk menghasilkan perangkat lunak berkualitas tinggi. Humphrey [4]mendefinisikan tujuan TSP berikut:[5]
- 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.[5]
- Menunjukkan kepada manajer bagaimana melatih dan memotivasi tim mereka dan bagaimana membantu mereka mempertahankan kinerja puncak.[5]
- Mempercepat peningkatan proses perangkat lunak dengan membuat perilaku Level 5 CMM menjadi normal dan diharapkan.[5]
- Memberikan panduan peningkatan untuk organisasi dengan kematangan tinggi.[5]
- Memfasilitasi pengajaran universitas tentang keterampilan tim kelas industri.[5]
Tim yang diarahkan sendiri memiliki pemahaman yang konsisten tentang tujuan dan sasaran keseluruhannya; mendefinisikan peran dan tanggung jawab untuk setiap anggota tim; melacak data proyek kuantitatif (tentang produktivitas dan kualitas); mengidentifikasi proses tim yang sesuai untuk proyek dan strategi untuk mengimplementasikan proses; mendefinisikan standar lokal yang berlaku untuk pekerjaan rekayasa perangkat lunak tim; terus-menerus menilai risiko dan bereaksi terhadapnya; dan melacak, mengelola, dan melaporkan status proyek.[5]
Sejarah TSP[sunting | sunting sumber]
Pada tahun 1996, Watts Humphrey mengembangkan versi awal proses TSP. Tujuannya adalah untuk menyediakan proses operasional untuk membantu praktisi secara konsisten melakukan pekerjaan yang berkualitas. Humphrey merancang proses TSP0 awal sesederhana mungkin, mencobanya dengan dua tim, dan kemudian meninjau hasilnya untuk melihat bagaimana cara kerjanya. Humphrey kemudian mengidentifikasi di mana tim membutuhkan bimbingan lebih lanjut dan meningkatkan proses untuk memberikan bimbingan itu. Proses TSP0 pertama dirancang untuk tim terlatih PSP yang tidak menerima pelatihan atau bimbingan selain yang disediakan oleh proses TSP dan manajemen langsung dari tim.[6]
Berdasarkan hasil dari dua tim TSP awal, jelas bahwa TSP membantu para praktisi untuk melakukan pekerjaan disiplin tetapi diperlukan lebih banyak panduan dan dukungan. Jelas juga bahwa manajemen harus secara luas mendukung Proses TSP. Proses TSP0.1 yang disempurnakan kemudian digunakan oleh tim tambahan, memberikan lebih banyak informasi tentang penyempurnaan proses yang dibutuhkan.[6]
Selama tiga tahun berikutnya, Humphrey mengembangkan sembilan versi TSP lainnya. Pada awalnya, tujuannya adalah untuk melihat apakah tujuan umum team process dapat membantu tim teknik untuk melakukan pekerjaan mereka. Setelah jelas bahwa TSP memenuhi tujuan dasar ini, upaya pengembangan proses TSPnya diarahkan untuk menyederhanakan proses, mengurangi ukurannya, dan memberikan dukungan dan bimbingan yang diperlukan untuk menjadikan proses tersebut paling efisien dan berguna. Akibatnya, versi TSP terbaru jauh lebih kecil daripada versi TSP0.1 dan TSP0.2 yang dikembangkan pada akhir 1996 dan awal 1997.[6]
Karena semakin banyak kelompok yang menggunakan Proses TSP, beberapa metode pengenalan telah dikembangkan untuk membantu praktisi dan manajer dalam membangun tim, mengikuti proses dengan lebih baik, dan secara berkala melakukan penilaian ulang dan perencanaan ulang proyek. Berbagai alat pendukung prototipe juga telah dikembangkan untuk menyederhanakan perencanaan praktisi, perekaman data, analisis data, dan kegiatan pelaporan proyek.[6]
Proses TSP[sunting | sunting sumber]
TSP mendefinisikan kegiatan-kegiatan berikut dalam kerangka kerja TSP, antara lain peluncuran proyek (project launch), desain tingkat tinggi (high-level design), implementasi (implementation), integrasi dan pengujian (integration and test), dan postmortem. Seperti pada PSP (perhatikan bahwa istilahnya agak berbeda), kegiatan ini memungkinkan tim untuk merencanakan, merancang, dan membuat perangkat lunak secara disiplin sementara pada saat yang sama secara kuantitatif mengukur proses dan produk. Tahap postmortem menetapkan tahapan untuk perbaikan proses.[5]
Sebelum praktisi dapat berpartisipasi dalam TSP, mereka diharuskan sudah mempelajari PSP, sehingga TSP dapat bekerja secara efektif. Pelatihan juga diperlukan untuk anggota tim lainnya, pemimpin tim dan manajemen. Siklus pengembangan perangkat lunak TSP dimulai dengan proses perencanaan yang disebut peluncuran, dipimpin oleh seorang pelatih yang telah dilatih secara khusus, dan bersertifikat atau provisional[7][8]. Peluncuran ini dirancang untuk memulai proses pembangunan tim, dan selama waktu ini tim dan manajer menetapkan tujuan, menentukan peran tim, menilai risiko, memperkirakan upaya, mengalokasikan tugas, dan menghasilkan rencana tim. Selama fase eksekusi, pengembang melacak rencana dan realita dari upaya , jadwal, dan cacat dengan melakukan pertemuan secara teratur (biasanya setiap minggu) untuk melaporkan status dan merevisi rencana. Siklus pengembangan berakhir dengan posmortem untuk menilai kinerja, merevisi parameter perencanaan, dan menangkap pelajaran yang dipetik untuk perbaikan proses.[6]
Peran pelatih (coach) berfokus pada mendukung tim dan individu-individu dalam tim sebagai ahli proses sambil independen terhadap tanggung jawab manajemen proyek langsung. Peran pemimpin tim berbeda dari peran pelatih dalam hal itu, pemimpin tim bertanggung jawab kepada manajemen untuk produk dan hasil proyek sedangkan pelatih bertanggung jawab untuk mengembangkan kinerja individu dan tim. TSP memanfaatkan beragam skrip, formulir, dan standar yang berfungsi untuk memandu anggota tim dalam pekerjaan mereka. "Script" mendefinisikan kegiatan proses spesifik (yaitu, peluncuran proyek, desain, implementasi, integrasi dan pengujian sistem, postmortem) dan fungsi kerja lainnya yang lebih rinci (misalnya, perencanaan pengembangan, pengembangan persyaratan, manajemen konfigurasi perangkat lunak, pengujian unit) yang merupakan bagian dari proses tim.[7][9]
TSP mengakui bahwa tim perangkat lunak terbaik adalah tim yang diarahkan secara mandiri. Anggota tim menetapkan tujuan proyek, menyesuaikan proses untuk memenuhi kebutuhan mereka, mengontrol jadwal proyek, dan melalui pengukuran dan analisis metrik yang dikumpulkan, bekerja secara kontinu untuk meningkatkan kualitas tim pendekatan rekayasa perangkat lunak. Seperti PSP, TSP adalah pendekatan yang ketat untuk rekayasa perangkat lunak yang memberikan manfaat yang jelas dan terukur dalam produktivitas dan kualitas. Tim harus membuat komitmen penuh untuk proses dan harus menjalani pelatihan menyeluruh untuk memastikan bahwa pendekatan tersebut diterapkan dengan benar.[5]
- ^ Jones, Capers. (2010). Software engineering best practices : lessons from successful projects in the top companies. New York: McGraw-Hill. ISBN 9780071621625. OCLC 471500462.
- ^ Kindler, Nosh B; Krishnakanthan, Vasantha; Tinaikar, Ranjit. Applying Lean to Application Development. McKinsey Quarterly, May 2007
- ^ Ker, J. I., Wang, Y., Hajli, M. N., Song, J., & Ker, C. W. (2014). "Deploying lean in healthcare: Evaluating information technology effectiveness in US hospital pharmacies". International Journal of Information Management, 34(4), 556–560.
- ^ Humphrey, W., “The Three Dimensions of Process Improvement, Part III: The Team Process,” CrossTalk, April 1998, available at www.stsc.hill.af.mil/crosstalk/1998/apr/dimensions.asp.
- ^ a b c d e f g h i Pressman, Roger S. (2015). Software engineering : a practitioner's approach. McGraw-Hill Education. ISBN 9781259253157. OCLC 949696534.
- ^ a b c d e Humphrey, Watts S. (2002-01-15). "Team Software Process (TSP)". Encyclopedia of Software Engineering. Hoboken, NJ, USA: John Wiley & Sons, Inc. ISBN 0471028959.
- ^ a b Humphrey, Watts S.; Chick, Timothy A.; Nichols, William; Pomeroy-Huff, Marsha (2010-07-01). "Team Software Process (TSP) Body of Knowledge (BOK)". Fort Belvoir, VA.
- ^ Chick, Timothy A.; Cannon, Robert; McHale, James; Nichols, William; Pomeroy-Huff, Marsha; Welch, Jefferson; Willett, Alan (2010-06-01). "Team Software Process (TSP) Coach Mentoring Program Guidebook Version 1.1". Fort Belvoir, VA.
- ^ Humphrey, Watts (2005). TSP: Coaching Development Teams. Addison Wesley.