Team software process - Riwayat revisi

Maintenance script: Presentation V4: sitasi, referensi, Math, Wikimedia Commons, dan atribusi

2026-08-23T18:09:39Z

Presentation V4: sitasi, referensi, Math, Wikimedia Commons, dan atribusi

Maintenance script: Impor teks terkontrol dari Wikipedia bahasa Indonesia; revisi 27851884; atribusi sumber disertakan.

2026-08-23T17:50:09Z

Impor teks terkontrol dari Wikipedia bahasa Indonesia; revisi 27851884; atribusi sumber disertakan.

Halaman baru

'''''Team Software Process'' (TSP)''' adalah kerangka kerja [[proses pengembangan perangkat lunak]] yang berkombinasi dengan [[Personal Software Process (PSP)|''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.

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 terintegras''i (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.

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.

== Sejarah TSP ==
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.

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.

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

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 [[Purwarupa|prototipe]] juga telah dikembangkan untuk menyederhanakan perencanaan praktisi, perekaman data, analisis data, dan kegiatan pelaporan proyek.

== Proses TSP ==
TSP mendefinisikan kegiatan-kegiatan berikut dalam kerangka kerja TSP, antara lain '''peluncuran proyek ''(project launch)'''''<nowiki/>'','' '''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.

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''''.'' 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 realitas 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.

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.

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.

== Referensi ==

== Sumber dan atribusi ==

Konten artikel ini diadaptasi dari [https://id.wikipedia.org/w/index.php?title=Team+software+process&oldid=27851884 Wikipedia bahasa Indonesia], revisi 27851884 (2025-09-18T11:55:04Z), yang tersedia berdasarkan lisensi Creative Commons Atribusi-BerbagiSerupa (CC BY-SA). Mohon gunakan konten ini secara bijak serta sesuai dengan ketentuan lisensi yang berlaku.

← Revisi sebelumnya		Revisi per 23 Agustus 2026 18.09
Baris 1:		Baris 1:
	'''''Team Software Process'' (TSP)''' adalah kerangka kerja [[proses pengembangan perangkat lunak]] yang berkombinasi dengan [[Personal Software Process (PSP)\|''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.		'''''Team Software Process'' (TSP)''' adalah kerangka kerja [[proses pengembangan perangkat lunak]] yang berkombinasi dengan [[Personal Software Process (PSP)\|''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.<ref>Jones, Capers. [https://www.worldcat.org/oclc/471500462 Software engineering best practices : lessons from successful projects in the top companies]. McGraw-Hill. 2010. ISBN 9780071621625.</ref><ref>Kindler, Nosh B; Krishnakanthan, Vasantha; Tinaikar, Ranjit. Applying Lean to Application Development. McKinsey Quarterly, May 2007</ref><ref>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.</ref>

	Tujuan TSP adalah untuk membangun tim proyek "mandiri" yang mengatur sendiri untuk menghasilkan perangkat lunak berkualitas tinggi. Humphrey mendefinisikan tujuan TSP berikut:		Tujuan TSP adalah untuk membangun tim proyek "mandiri" yang mengatur sendiri untuk menghasilkan perangkat lunak berkualitas tinggi. Humphrey <ref>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.</ref>mendefinisikan tujuan TSP berikut:<ref>Pressman, Roger S. [http://worldcat.org/oclc/949696534 Software engineering : a practitioner's approach]. McGraw-Hill Education. 2015. ISBN 9781259253157.</ref>

	* 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 terintegras''i (Integrated Product Teams)'' dari 3 hingga sekitar 20 praktisi.		* 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 terintegras''i (Integrated Product Teams)'' dari 3 hingga sekitar 20 praktisi.<ref>Pressman, Roger S. [http://worldcat.org/oclc/949696534 Software engineering : a practitioner's approach]. McGraw-Hill Education. 2015. ISBN 9781259253157.</ref>
	* Menunjukkan kepada manajer bagaimana melatih dan memotivasi tim mereka dan bagaimana membantu mereka mempertahankan kinerja puncak.		* Menunjukkan kepada manajer bagaimana melatih dan memotivasi tim mereka dan bagaimana membantu mereka mempertahankan kinerja puncak.<ref>Pressman, Roger S. [http://worldcat.org/oclc/949696534 Software engineering : a practitioner's approach]. McGraw-Hill Education. 2015. ISBN 9781259253157.</ref>
	* Mempercepat peningkatan proses perangkat lunak dengan membuat perilaku Level 5 CMM menjadi normal dan diharapkan.		* Mempercepat peningkatan proses perangkat lunak dengan membuat perilaku Level 5 CMM menjadi normal dan diharapkan.<ref>Pressman, Roger S. [http://worldcat.org/oclc/949696534 Software engineering : a practitioner's approach]. McGraw-Hill Education. 2015. ISBN 9781259253157.</ref>
	* Memberikan panduan peningkatan untuk organisasi dengan kematangan tinggi.		* Memberikan panduan peningkatan untuk organisasi dengan kematangan tinggi.<ref>Pressman, Roger S. [http://worldcat.org/oclc/949696534 Software engineering : a practitioner's approach]. McGraw-Hill Education. 2015. ISBN 9781259253157.</ref>
	* Memfasilitasi pengajaran universitas tentang keterampilan tim kelas industri.		* Memfasilitasi pengajaran universitas tentang keterampilan tim kelas industri.<ref>Pressman, Roger S. [http://worldcat.org/oclc/949696534 Software engineering : a practitioner's approach]. McGraw-Hill Education. 2015. ISBN 9781259253157.</ref>

	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.		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.<ref>Pressman, Roger S. [http://worldcat.org/oclc/949696534 Software engineering : a practitioner's approach]. McGraw-Hill Education. 2015. ISBN 9781259253157.</ref>

	== Sejarah TSP ==		== Sejarah TSP ==
	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.		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.<ref>Watts S. Humphrey. [http://dx.doi.org/10.1002/0471028959.sof352 Team Software Process (TSP)]. ''Encyclopedia of Software Engineering''. John Wiley & Sons, Inc. 2002-01-15. ISBN 0471028959.</ref>

	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.		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.<ref>Watts S. Humphrey. [http://dx.doi.org/10.1002/0471028959.sof352 Team Software Process (TSP)]. ''Encyclopedia of Software Engineering''. John Wiley & Sons, Inc. 2002-01-15. ISBN 0471028959.</ref>

	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]].		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]].<ref>Watts S. Humphrey. [http://dx.doi.org/10.1002/0471028959.sof352 Team Software Process (TSP)]. ''Encyclopedia of Software Engineering''. John Wiley & Sons, Inc. 2002-01-15. ISBN 0471028959.</ref>

	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 [[Purwarupa\|prototipe]] juga telah dikembangkan untuk menyederhanakan perencanaan praktisi, perekaman data, analisis data, dan kegiatan pelaporan proyek.		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 [[Purwarupa\|prototipe]] juga telah dikembangkan untuk menyederhanakan perencanaan praktisi, perekaman data, analisis data, dan kegiatan pelaporan proyek.<ref>Watts S. Humphrey. [http://dx.doi.org/10.1002/0471028959.sof352 Team Software Process (TSP)]. ''Encyclopedia of Software Engineering''. John Wiley & Sons, Inc. 2002-01-15. ISBN 0471028959.</ref>

	== Proses TSP ==		== Proses TSP ==
	TSP mendefinisikan kegiatan-kegiatan berikut dalam kerangka kerja TSP, antara lain '''peluncuran proyek ''(project launch)'''''<nowiki/>'','' '''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.		TSP mendefinisikan kegiatan-kegiatan berikut dalam kerangka kerja TSP, antara lain '''peluncuran proyek ''(project launch)'''''<nowiki/>'','' '''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.<ref>Pressman, Roger S. [http://worldcat.org/oclc/949696534 Software engineering : a practitioner's approach]. McGraw-Hill Education. 2015. ISBN 9781259253157.</ref>

	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''''.'' 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 realitas 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.		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''<ref>Watts S. Humphrey. [http://dx.doi.org/10.21236/ada634307 Team Software Process (TSP) Body of Knowledge (BOK)]. 2010-07-01.</ref><ref>Timothy A. Chick. [http://dx.doi.org/10.21236/ada528656 Team Software Process (TSP) Coach Mentoring Program Guidebook Version 1.1]. 2010-06-01.</ref>''.'' 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 realitas 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.<ref>Watts S. Humphrey. [http://dx.doi.org/10.1002/0471028959.sof352 Team Software Process (TSP)]. ''Encyclopedia of Software Engineering''. John Wiley & Sons, Inc. 2002-01-15. ISBN 0471028959.</ref>

	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.		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.<ref>Watts S. Humphrey. [http://dx.doi.org/10.21236/ada634307 Team Software Process (TSP) Body of Knowledge (BOK)]. 2010-07-01.</ref><ref>Humphrey, Watts (2005). ''TSP: Coaching Development Teams''. Addison Wesley.</ref>

	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.		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.<ref>Pressman, Roger S. [http://worldcat.org/oclc/949696534 Software engineering : a practitioner's approach]. McGraw-Hill Education. 2015. ISBN 9781259253157.</ref>

	== Referensi ==		== Referensi ==
			<references />


	== Sumber dan atribusi ==		== Sumber dan atribusi ==

	Konten artikel ini diadaptasi dari [https://id.wikipedia.org/w/index.php?title=Team+software+process&oldid=27851884 Wikipedia bahasa Indonesia], revisi 27851884 (2025-09-18T11:55:04Z), yang tersedia berdasarkan lisensi Creative Commons Atribusi-BerbagiSerupa (CC BY-SA). Mohon gunakan konten ini secara bijak serta sesuai dengan ketentuan lisensi yang berlaku.		Konten artikel ini diadaptasi dari [https://id.wikipedia.org/w/index.php?title=Team+software+process&oldid=27851884 Wikipedia bahasa Indonesia], revisi 27851884 (2025-09-18T11:55:04Z), yang tersedia berdasarkan lisensi Creative Commons Atribusi-BerbagiSerupa (CC BY-SA). Mohon gunakan konten ini secara bijak serta sesuai dengan ketentuan lisensi yang berlaku.

			<!-- WIKI_UNISSULA_PRESENTATION_V4 -->