Menurut penulis, sebuah proses perangkat lunak yang optimal adalah yang dapat disesuaikan dengan kebutuhan tim yang akan melaksanakan pekerjaan tersebut. Meskipun model proses perangkat lunak telah dibuat di tingkat perusahaan atau organisasi, namun untuk efektifitasnya hanya akan tercapai apabila dapat diadaptasi dengan signifikan untuk memenuhi kebutuhan tim proyek yang sebenarnya melaksanakan rekayasa perangkat lunak. Sebaiknya, proses yang dibuat haruslah yang paling cocok dengan kebutuhan tim dan organisasi secara menyeluruh. Atau, tim itu sendiri dapat membuat proses sesuai dengan kebutuhan individu mereka, namun tetap memenuhi kebutuhan organisasi secara keseluruhan. Watts Humphrey berpendapat bahwa membangun "personal software process" maupun "team software process" dapat dilakukan, meskipun memerlukan usaha, pelatihan, dan koordinasi yang sungguh-sungguh.
1.1 Personal Software Process (PSP)
Semua pengembang perangkat lunak menggunakan suatu proses, meskipun mungkin tidak terstruktur atau tidak efektif. Watts Humphrey mengemukakan bahwa untuk mengubah proses pribadi yang tidak efektif, diperlukan empat tahap yang melibatkan pelatihan dan penggunaan alat yang tepat. Salah satu contoh proses yang diperkenalkan adalah Personal Software Process (PSP) yang menekankan pada pengukuran kualitas produk dan hasil kerja, serta memberdayakan praktisi untuk mengendalikan kualitas seluruh produk perangkat lunak yang dihasilkan. PSP juga menetapkan tanggung jawab praktisi dalam perencanaan proyek, termasuk memperkirakan dan menjadwalkan waktu yang dibutuhkan. Model PSP mencakup lima kegiatan kerangka kerja yang didefinisikan secara jelas:
Planning. Kegiatan ini terdiri dari dua tahap utama yaitu memisahkan persyaratan dan menentukan ukuran dan sumber daya yang dibutuhkan. Selain itu, juga dibuat perkiraan jumlah cacat yang mungkin terjadi pada pekerjaan tersebut. Semua informasi metrik dicatat pada lembar kerja atau template yang telah disiapkan. Setelah itu, tugas-tugas pengembangan yang perlu dilakukan diidentifikasi dan jadwal proyek disusun.
High-level design. Proses pengembangan dimulai dengan membuat spesifikasi eksternal untuk setiap komponen yang akan dibangun dan merancang desain komponennya. Apabila terdapat ketidakpastian, dibuatlah prototipe untuk menguji dan memperbaiki desain tersebut. Seluruh masalah yang muncul dicatat dan dipantau untuk dicari solusinya.
High-level design review. Untuk mendeteksi kesalahan dalam desain, Formal verification methods digunakan. Selain itu, seluruh tugas penting dan hasil kerja dipantau dengan menggunakan metrik untuk memastikan kualitasnya tetap terjaga.
Development. Desain komponen dievaluasi dan diperbaiki, serta ditinjau ulang. Setelah itu, dilakukan pembuatan kode, review kode, proses kompilasi, dan pengujian. Metrik dipertahankan pada semua tugas penting dan hasil kerja untuk memastikan kualitasnya terjaga.
Postmortem. Dengan menggunakan ukuran dan metrik yang telah dikumpulkan (yang memerlukan analisis statistik yang cermat), dilakukan penilaian terhadap efektivitas dari proses yang telah dilakukan. Ukuran dan metrik tersebut diharapkan dapat memberikan petunjuk untuk melakukan modifikasi pada proses agar dapat meningkatkan efektivitasnya.
PSP menitikberatkan pentingnya mengidentifikasi kesalahan secara dini dan memahami jenis kesalahan yang mungkin terjadi. Hal ini dapat dicapai melalui penilaian yang ketat terhadap seluruh produk kerja yang dihasilkan oleh individu.
PSP menerapkan pendekatan yang didasarkan pada metrik dan disiplin dalam rekayasa perangkat lunak, yang dapat menyebabkan perubahan budaya bagi para praktisi. Namun, ketika diterapkan dengan benar pada insinyur perangkat lunak, PSP telah terbukti meningkatkan produktivitas dan kualitas perangkat lunak secara signifikan. Meskipun begitu, PSP belum sepenuhnya diadopsi di seluruh industri, terutama karena kendala manusia dan kelemahan organisasi. Pendekatan PSP menuntut tingkat komitmen yang tinggi dari praktisi dan manajemen, serta memerlukan pelatihan yang relatif lama dan mahal. Selain itu, pengukuran yang dibutuhkan untuk PSP sulit diakomodasi oleh beberapa praktisi perangkat lunak karena perbedaan budaya dan sikap.
Apakah PSP bisa menjadi proses pengembangan perangkat lunak yang efektif untuk individu? Jawabannya adalah "ya" tanpa ragu. Meskipun PSP mungkin tidak sepenuhnya diadopsi oleh semua praktisi, banyak konsep peningkatan proses pribadi yang diperkenalkannya dapat sangat berharga dan dapat dipelajari.
1.2 Team Software Process (TSP)
Watts Humphrey menyarankan untuk mengembangkan pelajaran dari pengenalan PSP untuk digunakan dalam proyek perangkat lunak tingkat industri yang biasanya ditangani oleh tim praktisi. Oleh karena itu, ia mengusulkan penggunaan Team Software Process (TSP) dengan tujuan membangun tim proyek yang dapat mengatur dirinya sendiri dalam menghasilkan perangkat lunak berkualitas tinggi. Menurut Humphrey, tujuan TSP adalah sebagai berikut:
- Membangun tim yang dapat bekerja secara mandiri dan bertanggung jawab untuk merencanakan dan memantau pekerjaan mereka, menetapkan tujuan, serta memiliki proses dan rencana mereka sendiri. Tim ini dapat terdiri dari tim khusus pengembangan perangkat lunak atau integrated product teams (IPT) yang terdiri dari 3 hingga 20 orang insinyur.
- Berikan pelatihan kepada manajer untuk mengembangkan keterampilan dalam melatih dan memotivasi tim mereka, serta membantu mereka menjaga kinerja terbaik.
- Berupayalah untuk meningkatkan proses perangkat lunak dengan membuat perilaku yang selevel dengan CMM Level 5 menjadi biasa dan diharapkan.
- Disediakan arahan perbaikan bagi organisasi yang memiliki tingkat kematangan yang tinggi.
- Dapat membantu memfasilitasi pengajaran di perguruan tinggi tentang keterampilan tim yang relevan dengan industri.
Tim mandiri memiliki kesepahaman yang seragam mengenai tujuan dan target keseluruhan; memetakan peran dan tanggung jawab masing-masing anggota tim; memonitor data kuantitatif proyek (seperti produktivitas dan kualitas); mengidentifikasi proses tim yang cocok untuk proyek dan strategi untuk mengimplementasikan proses tersebut; menetapkan standar lokal yang relevan untuk pekerjaan rekayasa perangkat lunak tim; secara terus-menerus mengevaluasi risiko dan menanggapinya; dan memantau, mengelola, dan melaporkan status proyek.
TSP memiliki kerangka kegiatan yang terdiri dari peluncuran proyek, desain tingkat tinggi, implementasi, integrasi dan pengujian, dan postmortem. Kegiatan-kegiatan ini memungkinkan tim untuk melakukan perencanaan, perancangan, dan pembangunan perangkat lunak secara teratur sambil mengukur proses dan produk secara kuantitatif, seperti yang dilakukan rekan-rekan mereka di PSP (meskipun dengan terminologi yang sedikit berbeda). Postmortem digunakan untuk mengevaluasi dan meningkatkan proses ke depannya.
TSP menggunakan berbagai macam skrip, formulir, dan standar untuk membimbing anggota tim dalam pekerjaan mereka. "Skrip" ini menetapkan aktivitas proses tertentu seperti peluncuran proyek, desain, implementasi, integrasi dan pengujian sistem, serta postmortem. Selain itu, skrip juga mencakup fungsi kerja yang lebih terperinci seperti perencanaan pengembangan, pengembangan persyaratan, manajemen konfigurasi perangkat lunak, dan pengujian unit yang merupakan bagian integral dari proses tim.
TSP mengakui bahwa tim perangkat lunak yang terbaik harus memiliki pengaturan sendiri. Anggota tim harus menetapkan tujuan proyek, menyesuaikan proses untuk memenuhi kebutuhan mereka, mengawasi jadwal proyek, dan dengan menggunakan pengukuran dan analisis metrik yang dikumpulkan, terus berusaha meningkatkan pendekatan tim mereka terhadap rekayasa perangkat lunak.
Sama seperti PSP, TSP juga merupakan pendekatan yang ketat dalam rekayasa perangkat lunak dan memberikan manfaat terukur dalam hal produktivitas dan kualitas. Untuk menerapkan pendekatan tersebut dengan benar, anggota tim harus membuat komitmen penuh terhadap proses dan menjalani pelatihan yang komprehensif.
Source: Pressman, Roger S. 2010. Software engineering : A Practitioner’s Approach (7th. Edition). New York: McGraw-Hill Higher Education.
Comments
Post a Comment