Team Type DD CD CC

Table of Contents

Team Type DD CD CC

Team Type

Difficulty tinggi rendah rendah
Size kecil besar besar
Team Life Time panjang singkat singkat
Modularity rendah tinggi tinggi
Reliability tinggi tinggi rendah
Delivery date longgar longgar ketat/pasti
Sociability tinggi rendah rendah

Constantine [CON93] mengusulkan empat “paradigma organisasional” untuk rekayasa perangkat lunak :
§ Paradigma tertutup sama dengan tim CC karena membentuk tim di sepanjang hirarki otoritas tradisional. Tim jenis ini akan efektif dalam memproduksi perangkat lunak yang mirip dengan apa yang dilakukan sebelumnya. Kelemahannya tim kurang inovatif.
§ Paradigma random sebuah tim yang tergantung inisiatif individual anggota tim sehingga terobosan inovasi atau teknologi akan unggul. Kelemahannya akan berjuang keras bila “unjuk kerja yang teratur” diperlukan.
§ Paradigma terbuka membentuk tim dengan cara tertentu dan memerlukan banyak kontrol tetapi banyak inovasi. Kerja dilakukan secara kolaboratif dengan komunikasi sarat konsensus pada pengambilan keputusan. Cocok untuk pemecahan masalah-masalah yang kompleks tetapi tidak bekerja seefisien tim yang lain.
§ Paradigma sinkron bergantung pada penggolongan alami dari suatu masalah serta mengorganisasi anggota tim untuk bekerja pada bagian-bagian kecil masalah dengan komunikasi aktif diantara mereka sendiri.
Chief pemrogram tim merupakan organisasai tim perangkat lunak yang paling awal dan merupakan sebuah struktur sentralisasi terkontrol. Inti dari tim ini terdiri dari seorang senior engineer yang merencanakan, mengkoordinasi, dan mengkaji semua aktivitas teknik tim; technical staff (terdiri dari dua samapi lima orang) yang melakukan analisa serta mengembangkan aktivitas, dan backup engineer yang mendukung senior engineer dalam aktivitasnya atau juga menggantikan senior engineer untuk masalah-masalah tertentu yang berhubungan dengan kelangsungan proyek. Senior engineer dapat dibantu oleh seorang spesialis, staf pembantu, dan seorang ahli pustaka perangkat lunak. Ahli pustaka ini bertindak sebagai pengontrol, koordinator, dan evaluator yang potensial dari konfigurasi perangkat lunak.

– Masalah Koordinasi dan Komunikasi
Ada beberapa masalah yang ditemui pada proyek perangkat lunak. Hal ini dikarenakan :
§ Skala usaha pengembangan yang besar, kompleksitas yang besar, dan kesultian dalam mengkoordinasi anggota tim.
§ Ketidakpastian, menghasilkan sebuah aliran perubahan yang terus-menerus.
§ Interoperabilitas, perangkat lunak baru harus berkomunikasi dengan perangkat lunak yang sudah ada dan menyesuaikan diri dengan batasan yang sudah ditentukan sebelumnya oleh sistem.
Untuk mengatasi hal itu tim rekayasa perangkat lunak harus membangun metode yang efektif untuk mengkoordinasi orang-orang yang mengerjakan pekerjaan tersebut.
Kraul dan Streeter [KRA95] menguji sekumpulan teknik koordinasi proyek yang dikategorikan dalam kelompok berikut :
§ Pendekatan impersonal, formal : penyampaian dan dokumen rekayasa perangkat lunak (kode sumber), memo-memo teknik, kejadian penting pada proyek dan sebagainya.
§ Prosedur interpersonal, formal : menyangkut pertemuan status pengkajian serta perancangan dan inspeksi kode.
§ Prosedur interpersonal, informal : pertemuan kelompok untuk penyebaran informasi dan pemecahan masalah serta “kolokasi kebutuhan dan pengembangan staf”.
§ Komunikasi elektronik : surat elektronik, papan buletin elektronik, website dan sebagainya.
§ Jaringan interpersonal : diskusi informal dengan orang-orang diluar proyek yang telah memiliki pengalaman atau pengetahuan yang dapat mendukung anggota tim.

Ø Masalah
Pada awal proyek perangkat lunak diperlukan perkiraan kuantitatif dan rencana organisasi tetapi informasi yang solid tidak dapat diperoleh. Analisis yang mendetail tentang kebutuhan perangkat lunak akan memberikan informasi yang memadai untuk suatu perhitungan yang mungkin dapat memakan waktu berminggu-minggu atau bahkan berbulan-bulan.
Beberapa aspek penting antara lain ruang lingkup dan dekomposisi masalah.

– Ruang Lingkup
Ruang lingkup proyek perangkat lunak harus tidak ambigu dan dapat dipahami pada tingkat teknik maupun menajemen. Batasan-batasan dari ruang lingkup :
§ Konteks. Bagaimana perangkat lunak yang akan dibangun dapat memenuhi sebuah sistem, produk, atau konteks bisnis yang lebih besar, serta batasan apa yang ditentukan sebagai hasil dari konteks tersebut?
§ Tujuan Informasi. Objek data pelanggan apa yang dihasilkan sebagai output dari perangkat lunak? Objek data apa yang diperlukan sebagai input?
§ Fungsi dan Unjuk Kerja. Fungsi apa yang dilakukan oleh perangkat lunak untuk mentranformasikan input data menjadi output? Adakah ciri kerja khusus yang akan ditekankan?

– Dekomposisi Masalah
Dekomposisi masalah (partitioning) merupakan sebuah aktivitas yang berkedudukan inti dari analisis kebutuhan perangkat lunak. Dekomposisi diterapkan pada dua area utama yaitu fungsionalitas yang harus disampaikan dan proses yang akan dipakai untuk menyampaikannya.
Dekomposisi Fungsional adalah identifikasi fungsional dari software, kemampuan yang diinginkan oleh pelanggan dan menentukan method/ feature untuk memenuhi fungsional

Sumber : https://forbeslux.co.id/