PERANAN TEAM SOFTWARE PROCESS PADA REKAYASA PERANGKAT LUNAK Suhatati Tjandra Teknik Informatika dan Komputer Sekolah Tinggi Teknik Surabaya Email: tati@stts.edu ABSTRAK Semakin berkembangnya dunia industrialisasi semakin tinggi pula permintaan perangkat lunak yang digunakan untuk mendukung bidang industri tersebut. Ada kalanya seseorang mampu melakukan pengembangan perangkat lunak yang telah dibuatnya secara personal dengan membutuhkan waktu dan biaya yang tidak efisien jika dibanding dengan kemajuan industri yang sedang berlangsung. Untuk mengefektifkan biaya dan waktu serta meminimisasi kegagalan yang mungkin terjadi, sangat disarankan agar perangkat lunak yang digunakan oleh suatu industri besar, dikerjakan oleh suatu tim. Dengan adanya tim yang terdiri dari berbagai orang, diharapkan dapat saling melengkapi satu sama lain sehingga perangkat lunak yang dihasilkan benar-benar dapat diterapkan secara efektif dan ikut memberikan keuntungan pada bidang industri yang didukungnya. Kata kunci: Industrialisasi, Biaya dan waktu yang efektif, Rekayasa perangkat lunak PENDAHULUAN Team Software Process merupakan proses yang dilakukan oleh tim yang berskala besar dengan anggota minimal dua puluh orang, dimana tim tersebut terlibat dalam rekayasa perangkat lunak yang besar dan sangat kompleks serta membutuhkan waktu hingga dalam hitungan tahun. Karena tidak semua perangkat lunak berskala besar, maka digunakan istilah Team Software Process (TSPi). TSPi didefinisikan sebagai kerangka kerja yang harus dilakukan oleh tim rekayasa perangkat lunak. TSPi mempunyai tujuh prinsip untuk mengambil keputusan dalam suatu proses: 1. Menyediakan kerangka kerja sederhana yang berdasarkan personal software process. 2. Membagi produk menjadi beberapa rangkaian kejadian. 3. Menetapkan nilai standar untuk kualitas dan pembuatan produk. 4. Menyediakan langkah yang tepat untuk tim. 5. Menerapkan peranan masing-masing anggota dan menyediakan tim evaluasi. 6. Membutuhkan disiplin untuk melakukan suatu proses. 7. Menyediakan pedoman untuk membantu menyelesaikan suatu masalah yang dihadapi oleh tim. Dalam merekayasa perangkat lunak, disusun langkah-langkah yang terstruktur semaksimal mungkin, sehingga apa bila masih terjadi kegagalan maka penyebabnya bukan masalah teknis tetapi masalah tersebut berasal dari individunya. Masalah-masalah yang biasa dihadapi oleh suatu tim dalam merekayasa perangkat lunak, antara lain:
Kepemimpinan yang tidak efektif Tanpa kepemimpinan yang efektif, tim akan mengalami kesulitan mengatasi rencana dan disiplin dari masing-masing anggota tim. Kegagalan berkompromi atau berkooperasi Tidak semua anggota tim mampu bekerja sama dalam tim dengan baik. Kurangnya partisipasi Seberapa besar partisipasi seseorang terhadap tim tergantung pada besar kecilnya tim dimana individu tersebut menjadi anggotanya, semakin besar tim biasanya semakin besar pula partisipasi yang diberikan. Jika salah satu dari anggota tim kurang berusaha untuk mewujudkan tujuan yang hendak dicapai, maka akan mempengaruhi kerja tim. Kurang dan berkurangnya kepercayaan Tim yang tidak mempunyai tujuan membuat waktu untuk memulai mengerjakan proyek, akan menyebabkan proyek menjadi tertunda-tunda dan tidak cepat selesai. Masalah tersebut timbul karena tiga hal berikut ini: o Tidak adanya pengalaman dalam bidang kepemimpinan o Kurang jelasnya tujuan dari proyek yang akan dikerjakan o Kurang jelasnya proses dan rencana yang akan dilakukan Kualitas yang kurang Masalah kualitas berasal dari berbagai hal, misalnya requirements yang kurang jelas, dokumentasi desain yang kurang, implementasi yang tidak teliti. Berjalannya fungsi secara perlahan-lahan Selama desain dan implementasi produk, seseorang akan menemukan berbagai cara untuk mengembangkan produk tersebut. Modifikasi yang dilakukan dengan sungguh-sungguh ini sulit untuk diawasi karena para perekayasa tersebut melakukan modifikasi pada produk dengan berdasarkan rasa ingin memperoleh hasil akhir yang benar-benar bagus. Menjadi sulit diawasi, karena tidak ada perbedaan yang jelas antara fungsi yang diharapkan pada saat requirement dengan fungsi tambahan yang diberikan. Evaluasi pembanding yang tidak efektif Evaluasi pembanding kadang menimbulkan persaingan antara masing-masing anggota dan mengurangi rasa kerjasama yang ingin diciptakan, karena dalam evaluasi pembanding ini, masing-masing anggota saling memberikan penilaian, kemudian membandingkannya satu dengan yang lain Tim terdiri dari sedikitnya dua orang, yang bekerja berdasarkan tujuan bersama dimana masing-masing anggota tim mempunyai peranan atau fungsi yang harus dilaksanakan dan untuk menyelesaikan tugas tersebut dibutuhkan ketergantungan antar anggotanya. Untuk membentuk suatu tim, dibutuhkan waktu. Biasanya tim dimulai dari seorang yang mempunyai sebuah tujuan, kemudian membahasnya bersama dengan beberapa orang, lalu menjadikannya tujuan bersama. Dengan demikian terbentuklah tim. Tim yang efektif dihasilkan dari penggabungan tujuan semua anggotanya di mana masing-masing individu harus berpartisipasi dan memberikan kontribusi. Terdapat tiga elemen yang dapat menjadikan suatu tim efektif: 1. komunikasi 2. komitmen 3. partisipasi dalam kegiatan tim C-2-2
METODE/PROSES Menentukan Tim Untuk membuat sistem, tim harus dibentuk dulu, kemudian menentukan tujuan yang ingin dicapai. TSPi mempunyai tiga tujuan dasar: 1. Menghasilkan produk yang berkualitas 2. Mengerjakan proyek yang diatur dengan baik dan produktif 3. Menyelesaikan proyek tepat pada waktunya Selain tiga tujuan dasar tersebut, tujuan standar TSPi yang hendaknya dimiliki oleh anggota tim, adalah sebagai berikut: 1. Menjadi anggota tim yang kooperatif dan efektif 2. Melaksanakan disiplin kerja secara konsisten 3. Merencanakan dan melaksanakan tugas yang menjadi bagiannya 4. Menghasilkan produk yang berkualitas Dalam mengerjakan suatu proyek, tim mempunyai catatan proyek dan alat bantu TSPi. Catatan merupakan informasi utama dari suatu proyek. Apa yang harus dikerjakan, apa yang sudah dikerjakan, bagaimana kinerja yang telah dicapai, dan sebagainya. TSPi mempunyai alat bantu yang membantu tim dalam merencanakan suatu pekerjaan, mengolah data, dan menelusuri pekerjaan yang telah dilakukan. Menyusun Strategi Strategi adalah cara yang digunakan untuk menyelesaikan suatu masalah guna mencapai tujuan yang telah ditetapkan. Yang perlu dilakukan dalam menyusun strategi adalah: 1. Mendefinisikan kriteria strategi 2. Membuat strategi alternatif 3. Mengetahui keuntungan dan resiko strategi alternatif 4. Membuat perbandingan antar strategi alternatif satu dengan yang lainnya 5. Membuat keputusan yang strategis 6. Mendokumentasikan strategi yang digunakan Strategi disusun dengan maksud untuk mengurangi resiko timbulnya permasalahan dalam pengerjaan proyek. Resiko ini dapat berupa: Tidak dapat terdesainnya sebuah fungsi atau lebih Produk yang dihasilkan tidak sempurna sehingga waktu uji cobapun menjadi lama Produk beserta perubahannya tidak dapat lagi diawasi sehingga waktu yang digunakan untuk merekayasanya menjadi sia-sia Tim tidak dapat bekerja dengan efektif Menyusun Rencana Kompleksitas rencana tergantung dari kompleksitas proyek yang dikerjakan. Ada beberapa alasan yang menyebabkan suatu rencana perlu untuk dibuat, yaitu: Supaya masing-masing anggota dapat bekerja secara efektif Supaya setiap anggota mempunyai komitmen untuk mengerjakan tugasnya Supaya tercipta kualitas kerja yang baik Mendefinisikan Kebutuhan Pada fase ini, tim membuat atau mendefinisikan spesifikasi kebutuhan sistem (software requirement specification/srs). SRS harus mencakup deskripsi yang jelas dan tidak mempunyai arti ganda dari suatu produk yang akan dibuat, serta terdiri dari C-2-3
kriteria awal untuk mengevaluasi produk akhir sehingga tahu langkah apa yang harus ditempuh. SRS juga memberikan feedback pada customer. Adapun langkah-langkah dasar yang dilakukan untuk menentukan kebutuhan sistem adalah sebagai berikut: 1. memperkirakan kemungkinan sistem 2. memahami pokok permasalahan organisasi 3. mengidentifikasi sistem stakeholder 4. mencatat sumber kebutuhan 5. mendefinisikan bisnis apa yang dilakukan 6. mendefinisikan batas sistem 7. mencatat dasar pemikiran kebutuhan 8. mendefinisikan kebutuhan yang tidak dipahami 9. mendefinisikan proses operasional Prinsip dasar dalam membuat spesifikasi kebutuhan sistem adalah mencakup halhal sebagai berikut: 1. Functional Requirement: input, output, perhitungan dan keadaan yang bagaiman yang digunakan. 2. External Interface Requirement: user, hardware, software, dan komunikasi 3. Batas Design: format file, bahasa pemrograman yang digunakan, standar sistem, kompatibilitas. 4. Atribut: tersedianya produk yang diinginkan customer, keamanan sistem, perawatan sistem. 5. Requirement lain: database dan instalasi. Desain Pada Tim Tahap desain ini difokuskan pada struktur sistem secara keseluruhan. Hasil dari tahap ini disebut software design specification (SDS) yang meliputi: Prinsip-prinsip desain Desain adalah proses kreatif dalam memutuskan bagaimana cara produk dibuat. Desain pada tim Desain pada tim memerlukan waktu yang lebih banyak. Hal ini diakibatkan desain yang dibuat harus dimengerti oleh semua anggota tim, karena dengan desain inilah masing-masing anggota nantinya akan bekerja untuk mengerjakan bagian yang sudah menjadi tanggung jawabnya. Standar desain Ada beberapa macam tipe standar desain antara lain: o Persetujuan nama Menetapkan nama-nama yang digunakan dalam sistem sehingga masingmasing anggota tim mempunyai kesamaan dalam hal penamaan seperti nama file, variable, parameter, dan lain sebagainya. o Format interface Mendefinisikan isi dan format interface. Termasuk pendefinisian parameter yang digunakan untuk variable, kode error, maupun kondisi lainnya. o Sistem dan pesan kesalahan Menentukan format dan prosedur standar untuk sistem dan pesan kesalahan. Sistem yang baik mempunyai tampilan yang konsisten dan mudah dimengerti. o Perhitungan LOC C-2-4
Standar LOC dihitung sebelum desain dimulai apabila tim ingin menggunakan penomeran yang berbeda, karena LOC ini biasanay dihitung pada saat tahap implementasi. o Standar representasi desain Standar representasi desain ini mendefinisikan produk hasil tahap desain. Hal ini perlu untuk mencegah representasi desain yang mempunyai arti ganda sehingga mengganggu jalannya proses implementasi dan uji coba. Desain untuk reuse Reuse menggunakan sebagian desain tahap sebelumnya untuk menjadi pengerjaan tahap tertentu. Beberapa desain yang dapat direuse: o Interface o Dokumentasi o Kualitas o Aplikasi pendukung Desain untuk usability Usability adalah pokok bahasan yang luas mengenai suatu produk yang menjamin seluruh produk dan bagiannya. Pokok bahasan ini dibahas selama proses desain yaitu mengenai sistem yang akan dibuat terutama fungsi-fungsi yang terdapat di dalamnya. Desain untuk uji coba Uji coba bagian luar program maksudnya bagaimana program tersebut digunakan oleh customer dan pemenuhan kebutuhan sistem customer. Selain itu juga dilakukan uji coba untuk memeriksa bagian logika dan struktur program. Memeriksa dan mereview desain Untuk melakukan pemeriksaan yang efektif, desain harus didokumentasikan dengan baik. Setiap elemen desain diperiksa apakah sudah berjalan sebagaimana seharusnya. Implementasi Hal-hal yang perlu diperhatikan dalam menentukan standar implementasi menurut TSPi adalah: Standar hasil review Standar tidak perlu sempurna pada awalnya, cukup standar dasar yang dapat dikembangkan setelah digunakan untuk mengerjakan produk. Penamaan, interface dan standar pesan Penamaan perlu distandarkan untuk keseragaman hasil produk sistem. Nama harus konsisten untuk mempermudah kerja tim dan proses uji coba serta penelusuran bila terjadi masalah. Interface dan pesan juga perlu diberi standar supaya dapat digunakan bersama oleh anggota tim. Standar coding Coding sangat membutuhkan konsistensi dari tim sehingga perlu dibuatkan standarnya untuk mempermudah pemeriksaan jika didapati masalah atau tidak, mempercepat proses coding dan menjadikannya lebih efektif, hal ini disediakan oleh komentar-komentar yang dibuat pada saat pengkodean. Standar ukuran Ukuran ini ditentukan oleh angka LOC. Standar ukuran tidak wajib ditentukan. Standar ukuran biasanya ditentukan bila data-data yang dipunyai digunakan pada produk berikutnya. C-2-5
Standar kerusakan Standar tipe kerusakan dapat digunakan kemudian menambahkan uji coba terhadap material untuk mengetahui kerusakan yang terjadi pada produk. Pencegahan terhadap kerusakan Tindakan pencegahan terhadap kerusakan dapat diawali dengan mempelajari lagi bahasa pemrograman yang akan digunakan, mempelajari kebutuhan sistem, memastikan proses yang akan dikerjakan, menggunakan alat bantu yang lebih baik, melakukan koreksi dan menggunakan metode yang lebih baik. Uji Coba Tujuan melakukan proses uji coba adalah untuk memastikan bahwa semua bagian yang dibutuhkan sudah terwakili untuk membentuk sebuah sistem kerja, dan menyediakan sistem ini untuk diuji coba dan diintegrasi. Proses uji coba ini sangat penting untuk mengetahui terpenuhinya atau tidak requirement. Beberapa hal yang harus dilakukan pada proses uji coba: Mengidentifikasi modul atau komponen yang mempunyai kualitas rendah dan mengembalikannya kepada quality/proses manajer untuk dikoreksi. Mengidentifikasi modul atau komponen yang masing-masing mempunyai kualitas yang rendah setelah mengalami perbaikan kemudian mengembalikannya kepada quality/proses manager untuk dikerjakan kembali atau diganti dengan modul baru. Tabel 1 Peranan Individu dalam Tim Peranan Prinsip Kerja Team Leader 1. Memotivasi anggota tim untuk mengerjakan tugasnya 2. Melaksanakan pertemuan tim 3. Melaporkan perkembangan mingguan 4. Membantu tim menentukan hal yang harus dikerjakan 5. Bertindak sebagai fasilitator dan penjaga waktu pada rapat tim 6. Bertanggung jawab atas pencatatan proyek 7. Bersama anggota tim membuat laporan kegiatan masingmasing cycle 8. Bertindak sebagai anggota tim. Development Manager 1. Memimpin tim membuat strategi pengerjaan proyek 2. Memimpin tim membuat perkiraan awal tentang waktu dan ukuran produk 3. Memimpin pembuatan SRS 4. Memimpin tim membuat high level design 5. Memimpin tim membuat software design specification 6. Memimpin tim membuat implementasi produk 7. Memimpin tim membuat sistem, mengintegrasi, dan rencana uji coba sistem 8. Memimpin tim membuat materi uji coba dan melaksanakan uji coba 9. Memimpin tim membuat dokumentasi produk untuk user 10. Berpartisipasi dalam pembuatan laporan kerja 11. Bertindak sebagai anggota tim Planning Manager 1. Memimpin tim untuk menghasilkan rencana kerja untuk cycle berikutnya 2. Memimpin tim untuk menghasilkan jadwal untuk cycle berikutnya 3. Memimpin tim untuk membuat rencana yang seimbang C-2-6
4. Menelusuri perkembangan tim terhadap rencana yang telah dibuat 5. Berpartisipasi dalam pembuatan laporan kerja tiap cycle 6. Bertindak sebagai anggota tim Process Manager 1. Memimpin tim untuk membuat rencana kualitas 2. Memberitahu team leader dan instruktur jika terjadi maslah 3. Memimpin tim dalam mendefinisikan dan mendokumentasikan proses dan melaksanakan proses improvement 4. Menentukan dan melaksanakan standar pembuatan produk 5. Mereview dan menyetujui produk sebelum dimasukkan configuration control board (ccb) 6. Bertindak sebagai moderator inspeksi 7. Bertindak sebagai notulen dalam rapat tim 8. Berpartisipasi dalam pembuatan laporan kerja tiap cycle 9. Bertindak sebagai anggota tim Support Manager 1. Memimpin tim menentukan fasilitas dan alt bantu apa yang dibutuhkan 2. Mengepalai CCB dan mengatur kontrol perubahan sistem 3. Mengatur sistem konfigurasi manajemen 4. Mengatur daftar istilah sistem 5. Mengatur penelusuran resiko dan masalah sistem 6. Bertindak sebagai penasihat reuse tim 7. Berpartisipasi dalam pembuatan laporan kerja tiap cycle 8. Bertindak sebagai anggota tim KESIMPULAN Untuk menjadi anggota tim, seorang individu harus membuat dirinya layak untuk bekerja dalam tim. Sebelum menjadi bagian dari tim, setiap individu diharapkan memiliki: Tanggung jawab Mau bekerja keras untuk mencapai tujuan Mempunyai prinsip hidup Orang yang bekerja dalam tim tentunya mempunyai tugas dan peran yang berbeda. Hal ini bertujuan untuk mengatur tim sedemikian rupa sehingga tidak ada tugas yang saling tumpang tindih dan masing-masing anggota mempunyai tanggung jawab terhadap tugas yang dimilikinya. DAFTAR PUSTAKA Fairley, Rchard E., 1997, Software Engineering Concepts, McGraw Hill Book Co, singapore Humphrey, Watts S., 1998, Introduction to The Team Software Process (TSP) SM, Prentice Hall. Pressman, Roger S., 1999, Software Engineering A Practitioner s Approach, McGraw Hill. Pressman, Roger S., 1998, A Manager s Guide to Software Engineering, McGraw Hill. C-2-7