PERANAN TEAM SOFTWARE PROCESS PADA

REKAYASA PERANGKAT LUNAK

Oleh:
Suhatati Tjandra
tati@stts.edu
Dosen Teknik Informatika dan Komputer
Sekolah Tinggi Teknik Surabaya

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.

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

1
 2
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
 3
2. Metode/Proses

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

2.2 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

2.3 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
 4
2.4 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 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 hal-hal
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.

2.5 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 masing-
masing anggota tim mempunyai kesamaan dalam hal penamaan seperti nama
file, variable, parameter, dan lain sebagainya.
o Format interface
 5
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
Standar LOC dihitung sebelum desain dimulai apabila tim ingin menggunakan
penomeran yang berbeda, karena LOC ini biasanya 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.

2.6 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
 6
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.
 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.

2.7 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 masing-
masing 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
 7
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
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 alat 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

3. Kesimpulan
Untuk menjadi anggota tim, seorang individu harus membuat dirinya layak untuk
bekerja dalam tim. Sebelum menjadi bagian dari tim, setiap individu diharapkan memiliki:
 8
 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.

4. Daftar Pustaka
1. Fairley, Rchard E., 1997, Software Engineering Concepts, McGraw Hill Book Co,
singapore
2. Humphrey, Watts S., 1998, Introduction to The Team Software Process (TSP)SM,
Prentice Hall.
3. Pressman, Roger S., 1999, Software Engineering A Practitioner’s Approach,
McGraw Hill.
4. Pressman, Roger S., 1998, A Manager’s Guide to Software Engineering, McGraw
Hill.