KONSEP MANAJEMEN PROYEK REKAYASA PERANGKAT LUNAK

KONSEP MANAJEMEN PROYEK REKAYASA PERANGKAT LUNAK

Spektrum Manajemen

Manajemen proyek perangkat lunak yang efektif berfokus pada tiga P: people (manusia), problem (masalah), process (proses). Urutannya tidak dapat berubah. Manajer yang lupa bahwa kerja rekayasa perangkat lunak merupakan usaha manusia yang intens, tidak akan pernah meraih sukses dalam manajemen proyek. Seorang manajer yang gagal melakukan komunikasi pelanggan yang komprehensif diawal evolusi sebuah proyek, beresiko membangun pemecahan yang elegan untuk masalah-masalah yang salah. Ahirnya manajemen yang tidak begitu memperhatikan proses, beresiko menyisipkan metode teknik yang cakap serta peranti ke dalam sebuah ruang hampa.

a.      Manusia

Factor manusia sangat penting sehingga Software Enginering Institute telah mengembangkan sebuah model kematangan kemampuan manjemen masusia (PM-CMM) untuk mempertinggi kesiapan organisasi perangkat lunak untuk mengerjakan aplikasi yang semakin kompleks dengan membantu menarik, menumbuhkan , memotivasi,menyebarkan, dan memelihara bakat yang dibutuhkan untuk mengembangkan kemampuan perkembangan perangkat lunak mereka . Model kematangan manajemen manusia membatasi area praktik berikut kunci bagi masyarakat perangkat lunak: rekruitmen, seleksi, manajemen untuk untuk kerja, pelatihan, kompensasi, perkembangan karir , desain kerja dan organisasi, dan perkemangan tim/kultur. Organisasi yang mencapai tingkat kematangan yang tinggi didalam area manajemen manusia memiliki kemiripan yang lebih tnggi dari implementasi praktik rekaysa perangkat lunak yang efektif.

b.      Masalah

Sebelum proyek direncanakan, obyektifitas dan ruang lingkupnya harus ditetapkan, pemecahan alternatifnya harus dipertimbangkan, teknik dan atas pun harus didefinisikan. Sekali tujuan dan ruang ligkup proyek di pahami, pemecahan alternatifnya dapat di pertimbangkan. Meskipunhanya sedikit saja yang didiskusikan,alternative tersebut memungkinkan manajer dan pelaksanaan memilih sebuah pendekatan ”terbaik” menentukan penghalang yang di sebabkan oleh batas waktu penyampaian, ketentuan anggaran, ketersediaan personil, interface teknis, dan banyak lagi factor yang lain.

c.       Proses

Proses perangkat lunak memberikan suatu kerangka kerja dimana rencana komprehensif bagi pengembangan perangkat lunak dapat di bangun. Sejumlah kecil aktifitas kerangka kerja dapat di aplikasikan pada semua proyek perangkat lunak, tanpa mempedulikan ukuran dan kompleksitasnya.

1.      Manusia

Manusia dalam proses rekayasa perangkat lunak. Yang karena itu kita semua, dari wakil presiden teknik senior sampai pelaksanaan yang paling rendah, dengan penuh kepastian mempertimbangkan factor manusia. Para manajer ber argument bahwa manusia merupakan hal yang utama. Namun demikian, tindakan mereka kadang-kadang tidak sesuai dengan perkataan mereka.

1.      Para Pemain

Proses perangkat lunak diisi oleh para pemain yang dapat dikategorikan ke dalam salah satu dalam lima konstituen berikut ini :

·         Manajer senior, yang menentukan isu-isu bisnis yang sering memiliki pengaruh penting didalam proyek.

·         Manajer proyek, yang harus merencanakan, memotivasi, mengorganisir dan mengontrol sebuah produk atau aplikasi.

·         Pelaksanaan , yang menyampaikan ketrampilan teknik yang di perlukan untuk merekayasa sebuah proyek atau aplikasi.

·         Pelanggan, yang menentukan jenis kebutuhan bagi perangkat lunak yang akan direkayasa.

·         Pemakai akhir, yang berinteraksi dengan perangkat lunak bila perangkat lunak telah dikeluarkan untuk digunakan.

Setiap proyek perangkat lunak dihuni oleh para pemain seperti yang ditulis.

2.      Pimpinan Tim

Manajemen proyek merupakan kegiatan manusia intensif, dan karena alasan itu para praktisi yang cakap sering melemahkan pemimpin tim. Dalam sebuah buku yang sangat menarik tentang kepemimpinan teknik, jerry Weinberg cenderung menjawab pertanyaan tersebut dengan mengusulkan model kepemimpinan MOI :

·         Motivasi

Kemampuan untuk member dorongan orang teknik untuk menghasilkan sesuatu dengan kemampuan terbaiknya.

·         Organisasi

Kemampuan untuk membentuk prosesyang sedang berlangsungyang memungkinkan konsep dasar diterjemahkan kedalam suatu hasil akhir.

·         Gagasan dan inovasi

Kemampuan untuk mendorong manusia untuk menciptakan dan bertindak kreatif meskipun mereka bekerja didalam suatu ikatan yang dibangun untuk suatu produk atau aplikasi perangkat lunak yang spesifik.

Pandangan lain menurut Edgemon tentang karakteristik yang menentukan seorang manajer proyek yang efektif memberikan tekan pada empat kata kunci:

Pemecahan masalah.

Seorang manajer proyek yang efektif dapat mendiagnosis isu-isu organisasi dan teknis yang paling relevan, yang secara sistematis membentuk sebuah pemecahan atau dengan tepat memotivasi para pelaksana yang lain untuk membuat pemecahan, menerapkan hasil pengalaman dari proyek sebelumnya ke situasi yang baru, dan tetap fleksibel untuk mengubah arah jika pendekatan pemecahan masalah semula tidak membuahkan hasil.

Identitas manajeral.

Seorang manajer proyek yang baik harus bersentuhan secara langsung dengan proyeknya.

Prestasi. Untuk mengoptimasi produktifitas sebuah tim proyek, seorang manajer harus memiliki inisiatif dan prestasi, serta dengan caranya sendiri memperlihatkan bahwa pengambilan resiko yang terkontrol tidak akan dikenai hukuman.

Pengaruh dan pembentukan tim. Seorang manajer proyek yang efektif harus mampu “membaca” manusia; dia harus mampu memahami sinyal verbal dan nonverbal serta bereaksi terhadap kebutuhan-kebutuhan orang-orang yang mengirim sinyal tersebut.

3.      Tim Perangkat Lunak

Struktur tim “terbaik” tergantung pada gaya manajemen sebuah organisasi, jumlah orang yang akan ada tim tersebut, dan tingkat keterampilannya, serta kesulitan masalah secara keseluruhan, Mantei [MAN81] mengusulkan tiga organisasi tim yang umum:

Demokrasi terdesentralisasi(DD). Tim rekayasa perangkat lunak ini tidak memiliki yang permanen . Tetapi “koordinator” dipilih untuk bertugas di dalam durasi waktu yang pendek, yang kemudian diganti oleh yang lain yang mungkin bertugas untuk mengkoordinasi tugas-tugas yang berbeda.

Terkentrol terdesenralisasi(CD). Tim rekeyasa perangkat lunak memiliki pemimpin tertentu yang mengkordinasi tugas-tugas khusus serta memiliki pemimpin-pemimpin sekunder yang bertanggung-jawab atas masalah sub-sub tugas. Pemecahan masalah merupakan aktivitas dari kelompok, tetapi implementasi dari pemecahan masalah di pecah di antara sub-sub kelompok oleh pimpinan tim.

Terkontrol tersentralisasi (CC). Koordinasi pemecahan masalah tingkat puncak dan internal tim diatur oleh pimpinan tim. Komonikasi antara pimpinan dan anggota tim bersifat vertical.

      Mantei juga menggambarkan tujuh faktor proyek yang harus dipertimbangkan pada saat merencanakan struktur tim rekayasa perangkat lunak:

·         Kesulitan masalah yang akan dipecahkan

·         Ukuran program-program resultan pada baris kode atau titik fungsi

·         Waktu tim akan tinggal bersama (umur tim)

·         Tingkat di mana masalah dapat dimodularisasi

·         Kualitas yang diperlukan serta keandalan sistem yang dibangun

·         Kepastian tanggal penyampaian

·         Tingkat sosiabilitas(komunikasi) yang dibutuhkan untuk proyek tersebut.

Tim yang tersentralisasi biasa membutuhkan lebih banyak waktu untuk menyelesaikan sebuah proyek daripada struktur yang tersentralisasi, dan pada saat yang sama merupakan pilihan yang terbaik bila sosiabilitas yang tinggi di perlukan .

      Constantine(CON93)mengusulkan empat “paradigma organisasi” bagi tim rekayasaperangkat lunak:

1.      Paradigm tertutup membebtuk sebuah tim di sepanjang hirarki otoris tradisional (sama dengan tim CC). Tim semacam itu dapat berkerja dengan baik pada saat memproduksi perangkat lunak yang sangat mirip dengan apa yang dilakukan sebelumnya; tetapi tim kurang inovatif ketika bekerja dalam paradigm tertutup

2.      Paradigma random membentuk sebuah tim secara longgar dan tergantung pada inisatif individual anggota tim. Pada saat terobosan inovasi atau teknologi dibutuhkan, tim yang mengikuti paradigma random akan unggul. Tetapi tim semacam ini dapat berjuang keras bila “unjuk kerja yang teratur” diperlukan.

3.      Paradigma terbuka cenderung membentuk tim dengan cara tertentu sehingga tercapai banyak control yang berhubungan dengan paradigm tertutup, tetapi sekaligus juga banyak inovasi pada saat menggunakan paradigm random.

4.      Paradigm sinkron bertumpu pada penggolongan alami dari suatu masalah serta mengorganisasi anggota tim untuk bekerja pada bagian-bagian kecil masalah dengan komunikasi aktif diantara mereka sendiri.

4.   Masalah koordinasi dan komunikasi

Ada banyak alasan mengapa proyek perangkat lunak menemui kesulitan. Skala usaha pengembangan yang besar, kompleksitas yang semakin besar, dan kesulitan dalam mengkoordinasi anggota tim. Ketidakpastian adalah umum, membuahkan sebuah aliran perubahan yang terus menerus yang menggelindingkan tim proyek. Interoperabilitas menjadi cirri-ciri kunci dari banyak sistem. Perangkat lunak yang baru harus berkomunikasi denagn perangkat lunak yang sudah ada dan menyesuiakan diri dengan batasan yang sudah ditentukan sebelumnya oleh sistem atau produk.

      Karakteristik modern perangkaqt lunak ini – skala, ketidakpastian, dan interoperabilitas – adalah kenyataan kehidupan. Kraul dan Streeter [KRA95] menguji kesimpulan teknik koordinasi proyek yang dikatagorikan dalam kelompok berikut:

Pendeketan impersonal, formal.  Mencakup penyampaian dan dokumen rekayasa perangkat lunak(seperti kode sumber), memo-memo teknis, kejadian penting pada proyek, jadwal dan peranti control proyek, kebutuhan akan perubahan dan dokumentasi yang berhubungan, laporan pelacakan kesalahan, dan data cadangan.

Prosedur interpersonal, formal. Berfokus pada aktivitas jaminan kualitas yang diterapkan pada produk kerja rekayasa perangkat lunak. Hal ini menyangkut pertemuan status pengajian serta perancangan  dan inspeksi kode.”

Prosedur interpersonal, informal. Menyangkut pertemuan kelompok untuk penyerbaran informasi dan pemecahan masalah serta “kolokasi” kebutuhan dan pengembangan staff.”

Komunikasi elektronik. Mencangkup surat elektronik, papan bulletin elektronik, Web stes, serta sistem konfersi berbasis video.

Jaringan interpersonal. Dikusi informal dengan orang-orang di luar proyek yang mungkin memiliki pengalaman atau pengetahuan yang dalam yang dapat mendukung anggota tim.

2.      Masalah

     Seorang manajer proyek perangkat lunak dihadapkan pada sebuah dilemma pada awal proyek rekayasa perangkat lunak. Diperlukan perkiraan kuantitatif dan rencana organisasi, tetapi informasi yang solid tidak dapar di peroleh. Analisa yang mendetail tetngan kebutuhan perangkatlunak akan memberikan informasi yang memadai untuk suatu perhitungan, tetapi analisis sering memerlukan waktu berminggu-minggu atau bahkan berbulan-bulan. Lebih buruk lagi, kebutuhan terkadang berubah-ubah, berubah secara regular pada saat proyek berjalan. Tetapi walaubagaimanapun diperlukan suatu rencana. Kita harusmengamati masalah pada awal dimulainya sebuah proyek.

a)      Ruang lingkup

Aktivitas  manajemen proyek perangkat lunak yang pertama adalah menentukan ruang lingkup perangkat lunak. Ruang lingkup dibatasi dengan menjawab pertanyaan-pertanyaan berikut :

Ø  Konteks

Bagaimana perangkat lunak yang akan dibangun dapat memenuhi sebuah sistem,produk atau kontek 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 dan objek data apa yang diperlukan sebagai input.

Ø  Fungsi dan unjuk kerja

Fungsi apa yang dilakukan oleh perangkat lunak untuk mentransformasi input data menjadi output. Adakah ciri kerja khusus yang akan ditekankan.

b)      Decomposisi Masalah

Dekomposisi masalah sering juga disebut partitioning (pembagian), merupakan sebuah aktivitas yang mendudukan inti dari analisis kebutuhan perangkat lunak. Dekomposisi diterapkan pada 2 area utama : 1. Fungsionalitasyang harus disampaikan dan 2. Proses yang akan dipakai untuk menyampaikannya.

Sementara ruang lingkup berkembang, pembagian tingkat pertama secara alami berlangsung. Tim proyek belajar bagaimana bagian pemasaran telah berbicara dengan pelanggan yang potensial dan mendapati bahwa fungsi-fungsi berikutini seharusnya menjadi bagian dari copy editing otomatis :

Ø  Pengecekan ejaan

Ø  Pengecekan tata bahasa kalimat

Ø  Pengecekan refrence untuk dokumen-dokumen yang besar.

Ø  Validasi refrence subbab dan bab untuk dokumen yang besar.

3.      Proses

            Fase – fase generic yang menandaiproses perangkat lunak-defiisi pengembangan dan pemeliharaan dapat diaplikasikan pada semua perangkat lunak. Masalah nya adalah bagaimana memilih model proses yang sesuai bagi perangkat lunakyang akan di rekayasa oleh sebuah tim proyek. Manaer proyek  harus memutuskan model proses mana yang paling sesuai untuk proyek tertentu, yang kemudian menentukan sebuah rencana utama yang didasarkan pada sejumlah aktifitas kerangka kerja proses yang umum. Sekali rencana pendahuluan di bangun,dekomposisi proses dimulai, yaitu rencana sepenuhnya meresfleksikan tugas kerja yang dibutuhkan utuk mengisi aktivitas kerangka kerja yang harus dibuat.

a)      Menggabungkan masalah dan proses

Perencanaan proyek dimulai dengan menggabungkan masalah dan proses. Setiap fungsi yang akan direkayasa oleh tim perangkat lunak harus melampui sejumlah aktivitas kerangka kerja yang sudah ditentukan bagi sebuah organisasi perangkat lunak. Misalnya organisasi sudah mengadopsi serangkaian aktivitas kerangka kerja sebagai berikut :

Ø  Komunikasi pelanggan

Tugas-tugas yang diperlukan untuk membangun komunikasi yang efektif diantara pengembang dan pelanggan.

Ø  Perencanaan

Tugas-tugas yang diperlukan untuk menentukan sumber-sumber daya,ketepatan waktu dan informasi proyek yang lain.

Ø  Analisis Resiko

Tugas-tugas yang diperlukan untuk memperkirakan resiko-resiko manajemen dan teknik

Ø  Rekayasa

Tugas-tugas yang diperlukan untuk membangun satu perwakilan aplikasi atau lebih

Ø  Kontruksi da rilis

Tugas-tugas yang diperlukan untuk membangun , menguji , memasang dan memberikan dukungan kepada pemakai.

Ø  Evaluasi pelanggan

Tugas-tugas yang diperlukan untuk memperoleh umpan balik dari pelanggan dengan didasarkan pada evaluasi representasi perangkat lunak yang diciptakan selama masa rekayasa serta diimplementasi selama masa instalasi.

b)      Dekomposisi proses

Tim perangkat lunak harus memiliki tingkat fleksibilitas yang signifikan dalam memilih paradigm rekayasa perangkat lunak yang paling baik bagi proyek dan tugas rekayasa perangkat lunak yang mendiami model proses sekali paradigma. CPF adalah invariant dan berfungsi sebagai dasar bagi semua kerja perangkat lunak yang dilakukan oleh organisasi perangkat lunak. Dekomposisi proses dimulai ketika manajer proyek bertanya : “bagaimana kita menyelesaikan aktifitas CPF ini ?” contohnya proyek yang relative sederhana dan kecil kemungkinan membutuhkan tugas kerja sebagai berikut bagi aktifitas komunikasi pelanggan :

Ø  Mengembangkan daftar isu klarifikasi

Ø  Bertemu dengan pelanggan untuk menekankan isu klarifikasi

Ø  Secara bersama mengembangkan pernyataan ruang lingkup.

Ø  Mengkaji keadaan lapangan dengan seluruh pendapat yang ada.

Ø  Memodifikasi pernyataan jangkauan sesuai keperluan.

Mengendalikan sebuah proyek yang lebih kompleks yang memiliki ruang lingkup yang lebihluas serta pegaruh bisnis yang signifikan. Proyek semacam itu memerlukan tugas-tugas – tugas kerja sebagai berikut untuk kegiatan komunikasi pelanggan :

Ø  Mengkaji kebutuhan pelanggan

Ø Merencanakan dan menjadwal sebuah pertemuan formal dengan pelangganan yang di  fasilitasi.

Ø Melakukan penelitian untuk menentukan pemecahan yang diusulkan dan pendekata yang ada.

Ø  Mempersiapkan “dokumen kerja” serta agenda untuk pertemuan formal.

Ø  Mengadakan pertemuan.

Ø  Mengkaji setiap perincian kecil tersebut untuk upaya perbaikan,konsistensi dan mengurangi abiguitas.

Ø  Memasang perincian kecil kedalam sebuah dokumen ruang lingkup

Ø  Mengkaji dokumen yang membatasi dengan semua pendapat yang ada.

Memodifikasi dokumen.