Pendahuluan

Manajemen proyek perangkat lunak (Henry, 2003) telah terbukti

salah satu tugas tersulit dalam bisnis pengembangan perangkat lunak.
Literatur perangkat lunak menyediakan banyak makalah dan survei yang diterbitkan (misalnya
Standish, 1994; ElEmam & Koru, 2008) yang melaporkan angka kegagalan proyek perangkat
lunak di berbagai tingkat atau mendiskusikan
situasi proyek yang tidak nyaman (Boehm, 2000). Kegagalan seperti itu membutuhkan
bentuk keruntuhan proyek secara penuh (misalnya pembatalan proyek)
atau ketidakmampuan untuk memenuhi sebagian tetapi tujuan proyek kritis, seperti kepuasan
anggaran atau kendala waktu. Selain itu, sangat menjengkelkan bahwa tujuan proyek perangkat
lunak yang penting dan tidak nyata lainnya
dan tim pengembangan, seperti generasi pengetahuan perangkat lunak
atau citra publik dari industri perangkat lunak, juga terancam ketika
gagal mengembangkan produk perangkat lunak. Baru-baru ini, telah diklaim
bahwa ada klaim yang tidak dapat dibenarkan dalam laporan kegagalan proyek perangkat lunak
(Jorgensen dan Molokken, 2006; Glass, 2006) dan istilah tersebut
'krisis perangkat lunak' tidak sesuai atau sepenuhnya dibenarkan. Namun demikian,
dapat dikatakan bahwa tingkat kegagalan proyek perangkat lunak cukup tinggi (ElEmam &
Koru, 2008) dan bahwa SPM memang menjadi isu kritis bagi
masa depan industri perangkat lunak.
Ada banyak alasan di balik kegagalan total atau sebagian dari proyek perangkat lunak. Pasti ada
kendala eksternal (lingkungan) yang dikenakan pada sebuah proyek (harapan klien, ketat .)
jadwal, dll) yang dapat menyebabkan situasi yang tidak diinginkan. Dan disana
adalah alasan proyek internal yang mengarah pada penerapan yang salah dari:
fungsi manajemen dasar, yaitu perencanaan, pembangunan tim, pemantauan, pengambilan
keputusan. Dalam makalah ini, kami akan fokus pada cara-cara yang
proyek gagal karena kekurangan internal. Kami juga akan fokus pada
pengetahuan SPM; Pengetahuan adalah pendorong utama untuk mengatasi situasi yang kompleks
dan menghindari keputusan yang buruk dan konsekuensinya.
Pengetahuan tentang domain tertentu perlu disajikan dalam
bentuk yang memfasilitasi penangkapan dan penyimpanan pengetahuan, pengetahuan
pencarian, pengambilan dan akhirnya penggunaan kembali pengetahuan. Khas,
Pengetahuan ''positif'' atau ''bagaimana melakukan sesuatu'' dikumpulkan di seluruh
domain dan diletakkan di tangan para ilmuwan dan praktisi. Terkini
penelitian telah menghasilkan pola pengetahuan, yaitu terdokumentasi dengan baik
struktur atau seperangkat aturan yang membantu dalam menyelesaikan masalah yang sering
terjadi. Mungkin resep yang paling terkenal dalam pengembangan perangkat lunak adalah pola
desain (Gamma et al., 1994)
yang telah menjadi alat utama dalam mendesain berorientasi objek yang berkualitas
artefak perangkat lunak. Penerapan pola desain telah
ditingkatkan selama bertahun-tahun dengan kontribusi lebih lanjut seperti itu
ditemukan di (Larman, 2002). Selain itu, pola desain terintegrasi
dalam kurikulum rekayasa perangkat lunak modern1
, baik sebagai bagian dari yang lebih luas
kursus berorientasi objek atau sebagai kursus independen, dengan fokus pada
desain-demi-pola.
Pola memang sudah ada dalam manajemen perangkat lunak. Sangat mudah untuk
temukan dalam dokumentasi literatur yang tersedia tentang praktik terbaik
yang baik generik atau khusus untuk manajemen perangkat lunak. Kita
mungkin menganggap praktik ini sebagai ''pola desain'' SPM, bahkan
jika mereka tidak diberikan secara eksplisit istilah ''pola" atau disajikan dalam a
bentuk pola. Namun, perhatian yang diberikan jauh lebih sedikit pada
gagasan ''anti-pola", yaitu sering terjadi malpraktik
dan konsekuensinya. Mengingat keadaan genting dari begitu banyak proyek perangkat lunak,
masuk akal untuk menganggap bahwa mereka gagal karena
mekanisme proyek deja-vu yang rawan kesalahan. Dengan kata lain, alasan masalah proyek
terletak pada munculnya satu atau lebih
anti-pola SPM. Dan itu adalah solusi untuk anti-pola yang
membuat jenis pengetahuan SPM ini sangat menarik untuk industri perangkat lunak modern.
Di sisi lain, hingga saat ini anti-pola telah didokumentasikan dengan cara informal, sebagian
besar melalui bentuk yang telah ditentukan dan teks terstruktur. Meskipun deskripsi seperti itu
sudah cukup
untuk memberikan garis besar malpraktik yang diwakili oleh satu antipola, mereka tidak cocok
menentukan dinamika, kausalitas dan ambiguitas yang mendasari anti-pola atau
hubungan antara anti-pola yang berbeda. Spesifikasi yang lebih formal tampaknya diperlukan
untuk memajukan pemahaman kita tentang
anti-pola dan memungkinkan pemrosesan lebih lanjut. Anti-pola adalah
item pengetahuan proyek penting dan mereka memerlukan alat untuk
manajemen pengetahuan yang efisien. Formalisasi anti-pola
perawatan akan memberi kita kesempatan untuk membangun seperti itu
alat cerdas.
Pernyataan terakhir harus dibuat untuk implikasi anti-pola
w.r.t pendidikan manajer perangkat lunak pemula dan pembelajaran seumur hidup bagi para
profesional di bidang ini. SPM adalah topik SE yang lembut, oleh karena itu
pembelajaran SPM harus berbasis kasus. Namun, mengajar praktis
Aspek SPM dianggap bermasalah (Kitchenham et al, 2005).
Salah satu alasan untuk fallback ini dengan bidang rekayasa perangkat lunak lainnya
mungkin kurangnya formalisasi yang disebutkan di atas dan
kurangnya basis pengetahuan SPM yang terorganisir secara sistematis. Masuk akal untuk
mengharapkan bahwa alat anti-pola akan sangat meningkatkan SPM kami
kapasitas mengajar yang memberikan pembelajar SPM secara sistematis
contoh kontra SPM yang dikemas, bersama dengan fungsi pembelajaran yang berguna seperti
pencarian, pengambilan, perbandingan, pertanyaan, dll.
Secara keseluruhan, tampaknya peran anti-pola belum sepenuhnya
dihargai dan lebih banyak perhatian harus diberikan pada anti-pola SPM. Tujuan dari makalah
ini adalah untuk mengadvokasi penggunaan anti-pola sebagai mekanisme SPM yang efektif dan
menjelaskan teknologi yang
dapat memajukan seni anti-pola.2 Sisa makalah ini adalah
terstruktur sebagai berikut. Pertama, contoh representatif dari anti-pola
dan survei singkat tentang sumber anti-pola yang diterbitkan diberikan.
Berikut ini adalah diskusi tentang formalisme yang masuk akal untuk anti-pola
spesifikasi. Selanjutnya, alat untuk mengelola anti-pola dijelaskan,
berdasarkan formalisme yang disajikan. Akhirnya, kesempatan untuk
pendidikan rekayasa perangkat lunak yang lebih baik ditinjau, dan kesimpulan
dan tren penelitian masa depan ditarik.
2. Anti-pola manajemen perangkat lunak dan sumber dayanya
Pola adalah solusi untuk masalah yang umum terjadi. Di dalam
rekayasa perangkat lunak, pola telah mendapatkan reputasi dalam desain
sejauh ada berbagai acara (konferensi, lokakarya, dll) berurusan secara eksklusif dengan pola
desain yang ada dan baru dan penggunaannya dalam pengembangan perangkat lunak sehari-hari.
Di dalam
Selain itu, ada banyak sumber daya (makalah jurnal, buku,
halaman web, dll.) mendukung praktisi pola desain dan
peneliti dalam menerapkan dan memajukan pengetahuan pola desain.
Keberhasilan pola desain adalah karena fakta bahwa mereka menyediakan
pengguna mereka dengan resep siap pakai dengan cara yang sangat tidak terstruktur
domain pengetahuan, yaitu desain perangkat lunak, mewujudkan pengetahuan yang telah
terakumulasi dalam beberapa dekade terakhir oleh desainer
perangkat lunak berorientasi objek
Mirip dengan desain perangkat lunak, SPM tampaknya tidak terstruktur
bidang ilmu juga. Fungsi khas SPM adalah perencanaan, tim
pembangunan, pemantauan, pengambilan keputusan dan pelaporan. Meskipun
alat manajemen untuk perencanaan, seperti PERT . yang dikenal luas
diagram, algoritme jalur kritis, dan teknik estimasi biaya perangkat lunak, telah digunakan secara
ekstensif sejak lama, sifat fungsi SPM yang tidak tepat dan tidak jelas membuat SPM sebagian
besar merupakan masalah ahli
pertimbangan. Secara khusus, penalaran berbasis kasus tampaknya
pendekatan yang masuk akal bagi para manajer, berdasarkan apa yang terjadi di
proyek masa lalu yang sukses. Pola SPM, yaitu ''diakui secara umum''
praktik yang baik”, telah didokumentasikan secara luas melalui berbagai cara (sumber
PMBOK3, buku, kertas putih, dll). Namun,
pola SPM yang didefinisikan secara formal jauh lebih jarang daripada perangkat lunak
pola desain dan akan sangat berguna, membantu dalam menyediakan
struktur yang lebih untuk pengetahuan SPM.
Anti-pola adalah semacam proyek perangkat lunak yang bermasalah
situasi. Ini pada dasarnya adalah hasil dari kesalahan manusia (manajemen
anti-pola) dan/atau perangkap sosial/budaya (anti-pola lingkungan) (Laplante dan Neil, 2006).
Dalam makalah ini kita akan fokus pada manajemen anti-pola. Contoh anti-pola bisa menjadi
buruk
latihan, reaksi yang salah terhadap kombinasi peristiwa, kegagalan untuk
memprediksi, memahami atau mengontrol faktor proyek, dll. Gagasan tentang
anti-pola terkait erat dengan risiko proyek, dalam arti
bahwa anti-pola adalah risiko potensial untuk suatu proyek jika penyebabnya terjadi saat
menjalankan proyek itu. Solusi untuk anti-pola dapat
dianggap sebagai mekanisme penghindaran risiko
Atribut anti-pola kritis adalah penyebab, gejala dan konsekuensi. Namun, anti-pola bukanlah
deskripsi sederhana dari masalah proyek; mereka juga dimaksudkan untuk menyampaikan
kesuksesan dan
solusi berulang untuk masalah yang mereka rujuk (Brown et al.,
1998).
Sumber daya khas untuk anti-pola adalah buku (Brown et al.,
1998; Brown dkk., 2000; Laplante dan Neil, 2006). Namun, set
anti-pola juga diumumkan di konferensi (misalnya Kuranuki
& Hirabane, 2004), sedangkan halaman Web didedikasikan untuk anti-pola
telah diposting dalam beberapa tahun terakhir4,5,6
. Secara tradisional, anti-pola
dijelaskan dalam kerangka informal. Tabel 1 memberikan
daftar indikatif item yang dapat ditemukan dalam anti-pola informal
template, berdasarkan item yang diusulkan dalam literatur. Item opsional mungkin
ditambahkan ke templat ini (mis. Bukti atau Pengamatan Anekdot).
Oleh karena itu, templat yang diusulkan dalam literatur mungkin lebih banyak (Brown
et al., 1998) atau kurang rinci (Laplante dan Neil, 2006) dibandingkan Tabel 1. Tabel 2
memberikan deskripsi anti-pola yang terkenal
berdasarkan templat ini. Lampiran A menyediakan daftar (tidak lengkap)
anti-pola yang ditemukan dalam literatur dan di Web pada saat itu
makalah ini ditulis.
Tidak sulit untuk menghasilkan anti-pola berdasarkan miliknya sendiri
pengalaman. Anti-pola dapat dengan mudah diturunkan dengan menggeneralisasi
kasus proyek di mana keputusan buruk telah dibuat. Penulis
baru-baru ini terlibat dalam proyek pengembangan perangkat lunak,
di mana situasi bermasalah terjadi karena manajemen 'terlalu banyak', fragmentasi tim yang
berlebihan, berkurangnya partisipasi dalam
pertemuan tatap muka, tingkat churn tim yang tinggi, terlalu banyak paruh waktu
pekerjaan, terlalu fokus pada kualitas internal (kualitas eksternal diabaikan), kurangnya
pengalaman, kinerja personel kunci yang kurang baik
tugas-tugas tertentu, masalah komunikasi, keterbukaan yang berlebihan terhadap
kontribusi (sulit untuk menentukan kepemilikan hasil dan menetapkan
tanggung jawab), menjadi terlalu optimis meskipun proyek mengalami penundaan, dll. Meskipun
tidak semua situasi ini baru di konteks ini dan beberapa di antaranya sudah termasuk dalam
existing
anti-pola, anti-pola baru atau versi anti-pola dapat
mudah diekstraksi dari manajemen yang jelas-jelas salah
pertunjukan.
Anti-pola sebagian besar telah dilaporkan di lingkungan perangkat lunak sumber tertutup.
Dengan munculnya Free/Libre/Open Source
Software (FLOSS), peneliti telah mulai menganalisis populer
Proyek FLOSS, mencari indikator vitalitas dan pola sukses.
Namun, persentase proyek FLOSS yang sangat tinggi adalah
gagal atau ditinggalkan. Selain itu, bahkan dalam kasus yang berhasil
dari FLOSS, dapat ditemukan jejak upaya yang gagal, jalan buntu,
garpu, pengabaian, dll. Koordinasi/manajemen FLOSS antipola belum dieksplorasi pada tingkat
yang sama seperti di tertutup
sumber. Selain itu, karena FLOSS dan perangkat lunak sumber tertutup menghasilkan kode
melalui proses pengembangan yang sangat berbeda, FLOSS
anti-pola sangat berbeda sifatnya dari sumber tertutupnya
rekanan dan mereka berada di luar cakupan makalah ini (lihat Bagian 5).
3. Formalisme anti-pola
Survei singkat dari bagian sebelumnya telah mengungkapkan bahwa
banyak anti-pola telah dilaporkan hingga sekarang. Meskipun
banyak dari mereka didokumentasikan melalui beberapa jenis template informal, yang lain
dijelaskan dalam teks biasa. Di sisi lain lebih
anti-pola diharapkan untuk diterbitkan atau diposting di Web
dalam waktu dekat. Sejumlah pengamatan dapat dilakukan w.r.t.
dengan seni anti-pola saat ini:
– Template sangat berguna untuk mengingat anti-pola
detail, tetapi kurang bersemangat dan tidak memberikan informasi kuantitatif yang dapat
digunakan oleh manajer untuk meningkatkan indikator proyek yang nyata.
– Kausalitas adalah komponen kuat dari setiap deskripsi anti-pola.
Agar anti-pola meyakinkan, sangat penting untuk menghasilkan
sebab dan akibat, dengan ikatan yang dibenarkan antara pasangan
sebab-akibat.
– Anti-pola tidak sepenuhnya deterministik. Ambiguitas muncul
bermain ketika suatu sebab terkait dengan suatu akibat; penyebab dapat menghasilkan
efek dengan beberapa probabilitas dan sampai batas tertentu. Pengecualian untuk
anti-pola juga dimungkinkan (penyebabnya muncul selama
proyek, tetapi mereka tidak menghasilkan konsekuensi negatif untuk
beberapa alasan).
– Anti-pola saling terkait. Mereka mungkin berbagi penyebab dan/atau
gejala dan mereka mungkin menjadi penyebab atau konsekuensinya sendiri
anti-pola lainnya.
– Anti-pola adalah item pengetahuan, dan karena itu mereka harus
dikomunikasikan kepada komunitas manajemen proyek dan dibagikan
dengan cara yang efektif.
Deskripsi teks biasa tidak dapat dengan mudah menangkap karakteristik anti-pola di atas dan
deskripsi template tidak membantu
banyak untuk tujuan manajemen pengetahuan. Lebih ringkas artinya
diperlukan, yang mengarah pada kebutuhan akan spesifikasi anti-pola
dengan cara-cara formal.
Karya penelitian terbaru (Settas et al., 2006, 2008; Settas and
Stamelos, 2007a,b, 2008) telah mengusulkan sejumlah alat formal
untuk spesifikasi anti-pola yaitu Bayesian Belief Networks,
Ontologi, Desain Struktur Matriks dan Jaringan Sosial. Dalam
berikut ini kami membahas bagaimana formalisme semacam itu membantu dalam mendukung
penggunaan anti-pola.
3.1. Jaringan kepercayaan Bayesian
Bayesian Belief Networks (BBNs) adalah grafik asiklik yang menggambarkan hubungan kausal
probabilistik antara peristiwa (Jensen,
2001). Mereka cocok untuk menangkap sebab dan akibat, dan hubungan antar logis di antara
mereka. Selain itu mereka cocok
untuk mengekspresikan ambiguitas yang melekat dalam hubungan sebab-akibat,
karena mereka melampirkan probabilitas untuk setiap pasangan nilai sebab-akibat.
Contoh BBN yang menentukan ikatan sebab-akibat dalam
anti-pola ditunjukkan pada Gambar. 1. Anti-pola ini berhubungan dengan
efek negatif yang mungkin dimiliki oleh kepribadian pengembang yang serupa
pada efektivitas pasangan, dan BBN memodelkan bagian dari sebab-akibat ini
hubungan.
Nilai dan probabilitas untuk pasangan nilai yang mencirikan penyebab dan
efek anti-pola dapat dihasilkan oleh manajer yang
telah mengalami anti-pola atau dihitung dengan observasional
studi kasus, atau bahkan eksperimen terkontrol. Representasi BBN pada Gambar 1 adalah hasil
dari satu eksperimen terkontrol tersebut
(Settas et al., 2006). Berbagai alat Perangkat Lunak dapat digunakan untuk pembuatan model
anti-pola BBN. Menggunakan alat tersebut, proyek perangkat lunak
manajer dapat mengatur bukti ke node BBN untuk menggambarkan efek ketidakpastian pada
variabel anti-pola yang menarik. Sebuah contoh
pengaturan bukti ke node BBN ditunjukkan pada Gambar. 2.
Model BBN awal (Gbr. 1) mengilustrasikan variabel dari antipattern tanpa harus menetapkan
bukti apapun ke node BBN manapun.
Solusi refactored dari anti-pola di atas mengusulkan bahwa
memiliki pasangan pengembang dengan kepribadian dan temperamen campuran
meningkatkan komunikasi, kolaborasi, ketepatan desain dan
kualitas perangkat lunak. Hal ini diilustrasikan pada Gambar. 2 dengan menetapkan bukti
ke node '' Kepribadian Campuran '' dan '' Temperamen Campuran ''.
Menggunakan propagasi Bayesian, probabilitas variabel BBN
diperbarui. Oleh karena itu, dengan membandingkan model BBN awal (Gbr. 1)
dengan model BBN dari solusi refactored (Gbr. 2), perangkat lunak
manajer proyek dapat mengamati efek dari solusi yang diusulkan
pada konsekuensi anti-pola.
Sebelum menggunakan perangkat lunak untuk mengeksplorasi efek dari
solusi refactored dari anti-pola dalam menyelesaikan ketidakpastian,
Data BBN perlu diproses terlebih dahulu. Ini melibatkan diskritisasi
bidang kontinu menjadi sejumlah interval yang terbatas. Misalnya, variabel waktu
pengembangan (Gbr. 1) memiliki tiga interval:
X_75 menunjukkan rendah, X_75_105 menunjukkan rata-rata dan X_105 menunjukkan
peningkatan waktu pengembangan. Demikian pula, variabel Kualitas Perangkat Lunak memiliki
tiga interval: X_83.33 menunjukkan rendah, X_83.33_136.66
menunjukkan rata-rata, dan X_136, menunjukkan kode berkualitas tinggi. Angka dalam nama
variabel telah dibuat secara otomatis sesuai dengan nilai yang diamati selama percobaan
Dengan membandingkan nilai-nilai variabel BBN sebelumnya (Gbr. 1) dan
setelah (Gbr. 2) penerapan solusi refactored, perangkat lunak
manajer dapat membuat pengamatan mengenai efek dari
anti-pola pada waktu pengembangan, kualitas kode keseluruhan, dll. Dengan mengontrol tingkat
kepribadian campuran hingga 100%, BBN pada Gambar. 2
menyarankan peningkatan kinerja pasangan, mis. ada kemungkinan 17%
kualitas rendah, bukan 22% (Gambar 1). Dengan cara yang sama, dengan menurunkan
persentase pasangan campuran, manajer dapat memperoleh perkiraan
kemunduran proses mereka, menilai pentingnya
anti-pola dan pengaruhnya pada proyek mereka. Akhirnya, yang menarik
Fitur BBN adalah bahwa mereka dapat digunakan oleh manajer proyek perangkat lunak dalam
kasus data statistik langka dari proyek sekarang atau masa lalu. Di dalam
kasus seperti itu, manajer dapat melengkapi model menggunakan ahli mereka
pertimbangan.
3.2. Ontologi
Ontologi dapat digunakan untuk memberikan representasi formal dari
seperangkat konsep dalam domain anti-pola dan hubungan antara konsep-konsep itu. Mereka
dapat digunakan untuk menyediakan
orang atau perangkat lunak dengan pemahaman yang sama tentang
struktur anti-pola. Peneliti rekayasa perangkat lunak dan
pembuat alat sudah menggunakan ontologi untuk memodelkan berbagai lainnya
entitas rekayasa perangkat lunak (misalnya Kitchenham et al., 1999; Calero
dkk., 2006).
Setiap template anti-pola yang diusulkan dapat diwakili dengan a
ontologi yang berbeda. Namun, berbeda template yang telah
diusulkan untuk dokumentasi anti-pola dapat menyebabkan kebingungan untuk manajer proyek
perangkat lunak. Representasi UML dari satu
ontologi anti-pola generik yang diusulkan ditunjukkan pada Gambar. 3 (Settas
dan Stamelos, 2007a). Ontologi juga mempertimbangkan arsitektur perangkat lunak dan anti-
pola pengembangan perangkat lunak, yang bertujuan untuk
audiens yang lebih luas dan cakupan aplikasi anti-pola. Ontologi
memodelkan hubungan masuk akal tertentu antara anti-pola: dan
anti-pola dapat menggantikan, menggunakan, memperbaiki atau memerlukan antipola lain.
Ontologi Gambar 3 memungkinkan interoperabilitas perangkat lunak karena ontologi
memungkinkan berbagai alat SPM untuk dengan mudah menggunakan perangkat lunak tertentu
anti-pola. Selanjutnya, spesifikasi anti-pola
ontologi adalah langkah pertama menuju arsitektur sistem cerdas yang bertujuan untuk
membantu manajer proyek dalam mendeteksi
dan menyelesaikan anti-pola yang sesuai selama eksekusi a
proyek perangkat lunak (Settas dan Stamelos, 2007b).
3.3. Desain struktur matriks
Anti-pola SPM biasanya terkait dengan anti-pola lain dan
jarang muncul dalam isolasi (Brown et al., 1998). Anti-pola mungkin
muncul dalam fase proyek yang berbeda dan mempengaruhi satu sama lain dalam urutan yang
telah ditentukan, karena keterkaitan penyebab yang melekat
dan gejala dalam proyek perangkat lunak.
Matriks Struktur Desain atau Matriks Struktur Ketergantungan
(DSM) dapat digunakan sebagai metodologi yang memvisualisasikan, menganalisis
dan menyelesaikan kompleksitas dan saling ketergantungan antara yang terkait
anti-pola (Settas dan Stamelos, 2008). Pembaca yang tertarik itu
tidak akrab dengan DSM dapat menggunakan (Browning, 2001) sebagai pengantar metodologi.
Metodologi DSM dapat memvisualisasikan tiga
konfigurasi berbeda yang menjadi ciri anti-pola dan penyelesaian
sirkuit yang terbentuk antara anti-pola yang saling bergantung
atribut. Seperti yang telah disebutkan, anti-pola yang paling penting
atribut adalah penyebab, gejala dan akibat dari suatu antipattern. Oleh karena itu, menggunakan
DSM ketergantungan antara yang terkait
penyebab, gejala dan akibat dari anti-pola SPM adalah
dimodelkan dan dapat dianalisis. Gambar 4 mengilustrasikan contoh a
DSM dari serangkaian anti-pola SPM yang saling terkait.
Tanda diagonal nol menunjukkan ketergantungan antara dua elemen. Dalam contoh DSM (Gbr.
4), tanda ini menunjukkan ketergantungan antara dua anti-pola. Ketergantungan ini mungkin ada
karena dua atau lebih anti-pola terkait melalui
penyebab, gejala dan akibat. Membaca berturut-turut mengungkapkan
atribut anti-pola lain yang menjadi sandaran suatu atribut. Membaca
kolom, mengungkapkan atribut lain apa yang disediakan oleh anti-pola
informasi melalui atributnya. Misalnya, pada Gambar. 4, dengan
membaca di baris 4, anti-pola ''Kematian karena Perencanaan" (Brown
et al., 2000) tergantung pada '' Perencanaan 911 "(Brown et al., 2000)
anti-pola. Membaca di kolom 2 menunjukkan bahwa anti-pola
''Death by Planning" memberikan informasi ke ''Merencanakan 911'
anti-pola. Menggunakan DSM, manajer perangkat lunak dapat memeriksa potensi
efek domino dari anti-pola yang baru saja dia deteksi di dalam dirinya
proyek dan menghindari implikasi yang tidak diinginkan lebih lanjut. Dia juga bisa
memperoleh lebih banyak wawasan tentang mekanisme yang telah menghasilkan situasi yang
tidak diinginkan dalam proyek yang ada.
3.4. Jaringan sosial
Seperti yang telah disebutkan, ontologi anti-pola, dapat mengkodekan
pengetahuan manajemen proyek perangkat lunak ke dalam bentuk yang dapat dimengerti
komputer. Hal ini dapat mengatasi masalah heterogen
data anti-pola yang tersedia di Web. Namun, ontologi
dapat menjadi sumber heterogenitas itu sendiri. Dengan menggunakan ontologi,
entitas yang sama dapat dideskripsikan dengan nama atau cara yang berbeda. Oleh karena itu,
agar anti-pola menjadi praktik yang meluas, penting untuk mengatasi masalah mengidentifikasi
anti-pola yang serupa.
ontologi.
Teknik Analisis Jaringan Sosial (SNA) dapat membantu perangkat lunak
manajer proyek dalam menemukan ontologi anti-pola serupa (Settas
dkk., 2009). Jaringan sosial semantik anti-pola tiga lapis
melibatkan jaringan sosial, jaringan ontologi anti-pola dan
jaringan konsep. SNA dapat memodelkan jaringan komunitas manajemen masa depan berbasis
anti-pola, tetapi juga dapat digunakan
untuk mengekstrak tindakan dari satu lapisan jaringan sosial semantik
kepada yang lain. Pengetahuan ini kemudian dapat digunakan untuk menyimpulkan hubungan
baru antara ontologi anti-pola. BBN dapat digunakan lagi untuk mewakili Gambar. 3.
Representasi UML dari ontologi anti-pola generik. mengirimkan tingkat ketidakpastian yang
terkait dengan setiap tautan baru tersebut.
Selanjutnya, BBN juga membahas masalah kuantifikasi ketidakpastian data yang dikumpulkan
mengenai ontologi anti-pola.
4. Alat anti-pola
Seperti yang telah disebutkan, alat untuk manajemen pengetahuan anti-pola diperlukan untuk
mendorong penyebaran dan penggunaan anti-pola
dalam praktek. Salah satu sistem cerdas tersebut sedang diimplementasikan di
Universitas Aristoteles di Thessaloniki, bertujuan untuk membantu perangkat lunak
manajer proyek dalam proses identifikasi dan eksploitasi anti-pola. Sistem harus dapat
menampilkan daftar kemungkinan
gejala anti-pola kepada pengguna dan akan mengambil tidak hanya anti-pola yang terkait secara
langsung tetapi juga antipola yang diambil secara semantik. Anti-pola yang diambil secara
semantik akan diproses menggunakan informasi yang disertakan dalam anti-pola
ontologi pada Gambar. 3. Menggunakan properti OWL, ontologi akan berisi:
informasi mengenai hubungan anti-pola melalui
penyebab, gejala, dan konsekuensinya. Manajer proyek perangkat lunak akan dapat mengisi
basis pengetahuan sistem
dengan anti-pola baru dengan membuat instance baru dari ontologi.
Dengan satu sistem seperti itu, fungsi manajemen pengetahuan dasar
akan didukung: pengetahuan anti-pola akan ditangkap, disimpan
dan diambil, sementara pengetahuan yang relevan juga akan secara otomatis
tersedia. Melalui antarmuka Web-nya, sistem akan dapat menjawab pertanyaan seperti '' Apa
yang harus saya harapkan jika personel proyek?
merasa tidak nyaman dengan proyek saya?”, ‘’Saya mengalami hal negatif ini
akibatnya, apa yang bisa menjadi penyebabnya dan mengapa hal itu terjadi?”, dan
''Apa yang bisa terjadi sekarang, mengingat status proyek saya?"
Alat manajemen anti-pola memberikan peluang menarik untuk pendidikan manajer juga.
Menguasai SPM artinya
memiliki keterampilan yang sulit diperoleh; mengidentifikasi masalah yang tidak mudah
untuk menemukan, membuat keputusan yang tepat, mengelola sumber daya dan risiko
(Henry, 2003). Berurusan dengan kompleksitas manajemen menuntut perolehan pengetahuan
dari situasi dunia nyata. Menariknya, para peneliti telah mengidentifikasi kesenjangan yang lebar
antara apa yang
diajarkan di akademi dan apa yang sebenarnya dibutuhkan saat berolahraga
profesi manajer proyek perangkat lunak. Di (Dapur
et al., 2005), ditemukan bahwa SPM mungkin yang paling menuntut dari sudut pandang ini di
antara 40 topik rekayasa perangkat lunak.
Itu juga telah diamati (Jonassen dan Hernandez-Serrano, 2002)
bahwa domain “tidak terstruktur”, seperti SPM, cocok untuk pembelajaran berbasis kasus
(Demetriadis et al., 2007). Oleh karena itu, manajemen
pola sukses dan gagal, anti-pola dan cerita (kasus) adalah
sangat berharga tidak hanya untuk menginformasikan dan menginstruksikan manajer perangkat
lunak di lapangan (pembelajaran seumur hidup), tetapi untuk mengajar siswa manajemen
perangkat lunak juga dalam konteks akademis.
siswa gement juga dalam konteks akademik.
Instruksi manajemen perangkat lunak dapat mengambil manfaat dari serangkaian:
banyak, didefinisikan secara ringkas, contoh anti-pola dan anti-pola, yaitu kasus yang
didokumentasikan dari penampilan anti-pola tertentu.
Lingkungan berbasis web, mendukung instruksi berbasis kasus, dapat
menghasilkan dampak pembelajaran yang tinggi, memungkinkan siswa untuk mempelajari
contoh antipola dan antipola secara online. Anti-pola yang saling terkait memungkinkan
''persilangan tematik", mis. dengan mengizinkan pelajar manajemen untuk melihat bagaimana
manajemen orang yang tidak efektif,
bercampur dengan perangkap teknologi seperti penerapan alat atau proses yang tidak tepat, dapat
menyebabkan anti-pola yang berbeda.
Alat pengetahuan anti-pola dapat diinstrumentasi lebih lanjut untuk meningkatkan dan
merangsang (scaffold) aktivitas kognitif peserta didik, mis.
melalui penggunaan strategi bertanya, memberi kami sistem manajemen pembelajaran SPM
yang efektif.
5. Kesimpulan dan tren masa depan
Dalam makalah ini kami telah meninjau kembali konsep proyek perangkat lunak
manajemen anti-pola dan mendiskusikan kegunaan dari
menggambarkan situasi bermasalah ketika mengelola pengembangan perangkat lunak. Kami
telah meninjau sumber daya anti-pola, diterbitkan pada
kertas atau diposting di Web, mengamati bahwa anti-pola mampu
untuk menyampaikan kebijaksanaan manajemen perangkat lunak yang dikemas. Kita punya
memperkenalkan sarana formal untuk menentukannya secara lebih jelas dan lebih
cara kuantitatif. Kami telah melihat bagaimana alat dapat dibangun berdasarkan
spesifikasi anti-pola yang lebih mudah, bagaimana komunitas pengelola
dapat mengambil manfaat dari alat tersebut dan bagaimana pelajar formal dan informal
dapat menambah pengetahuan manajemen perangkat lunak mereka dan menjadi
lebih mahir dengan mempelajari situasi anti-pola.
Menurut pendapat penulis, ada lebih banyak peluang untuk meneliti dan mengeksploitasi anti-
pola, yang bertujuan untuk menambahkan lebih banyak
struktur ke domain pengetahuan manajemen perangkat lunak. Dalam
berikut kami berspekulasi tentang beberapa kemungkinan perkembangan di masa depan dan
arah penelitian di SPM berdasarkan konsep anti-pola
Anti-pola yang ada harus ditinjau kembali dan dipertahankan. Atribut anti-pola tertentu dapat
berubah sesuai dengan pengalaman
laporan, solusi baru dapat dirancang dan keyakinan tentang penyebab dan
hubungan efek dapat diubah. Investigasi empiris yang buruk
praktik manajemen diperlukan untuk meningkatkan pemahaman kita
penyebab kegagalan proyek dan alat kami untuk memeranginya, oleh karena itu eksperimen
terkontrol (bila memungkinkan) dan sebaliknya
studi kasus empiris yang akan memperkaya anti-pola yang ada dengan
informasi terukur harus diterima. Seperti yang telah disebutkan, pemeliharaan anti-pola akan
sangat difasilitasi dari
penggunaan alat manajemen pengetahuan anti-pola. Akibatnya, lebih banyak penelitian tentang
spesifikasi formal anti-pola dan
pengembangan lebih lanjut dari alat untuk manajemen pengetahuan mereka
harus diharapkan.
Masuk akal untuk mengharapkan lebih banyak anti-pola, yang mencakup semua bidang
manajemen perangkat lunak, akan muncul dalam waktu dekat. Ini sebagian karena fakta bahwa
banyak aspek perangkat lunak
manajemen belum sepenuhnya dipahami atau dieksplorasi (misalnya masalah kepribadian). Di
sisi lain, situasi yang lebih bermasalah akan
terjadi dalam praktik karena anti-pola yang terkait dengan cara-cara baru
untuk mengembangkan perangkat lunak (misalnya pengembangan sepanjang waktu, hybrid
proyek open source) yang belum cukup didokumentasikan. Penerapan teknologi dan proses
perangkat lunak baru juga tidak diragukan lagi akan menghasilkan masalah baru.
Sebagai contoh pertimbangkan forking di FLOSS. Forking dalam proyek FLOSS terjadi ketika
dua kelompok pengembang yang berasal dari itu
proyek mulai mengembangkan lebih lanjut basis kode secara independen dari
satu sama lain. Forking adalah hasil dari tujuan yang berbeda, tetapi juga dari sudut pandang
pribadi atau komunitas yang berbeda. Meskipun bercabang
mungkin memiliki aspek positif dan merupakan manifestasi dari kebebasan, itu adalah
dianggap memiliki efek negatif pada keseluruhan proyek, karena
komunitas pengembang yang mendukung proyek FLOSS sering
terbelah menjadi dua, menghasilkan usaha yang sia-sia untuk menghasilkan hasil yang serupa.
Selain itu, pengguna dapat bingung di depan dua versi yang sangat mirip dari sistem yang sama.
Anti-pola FLOSS lainnya
mungkin menyangkut peluncuran proyek pada waktu yang salah, ketidakmampuan
dari proyek FLOSS untuk menjangkau sejumlah besar pengguna/pengembang,
kematian proyek FLOSS karena persaingan dari FLOSS lainnya
proyek, dll. Proyek Hybrid FLOSS, yaitu proyek sumber terbuka yang
dimulai dan/atau dikendalikan oleh perusahaan perangkat lunak, berpotensi
melibatkan programmer berbayar, mungkin juga menjadi sumber anti-pola
situasi karena sifatnya yang campur aduk dan rumit. Misalnya, sebuah perusahaan
telekomunikasi besar melaporkan bahwa di salah satu
proyek hibrida mereka, partisipasi eksternal, programmer sukarelawan adalah nol, dan ada bukti
anekdot bahwa proyek hibrida
lebih produktif tetapi kurang berkualitas w.r.t. proyek FLOSS murni.
Kemajuan dalam teknologi anti-pola pada akhirnya akan memfasilitasi
pengembangan manajemen yang lebih terbuka dan lebih partisipatif
komunitas pengetahuan. Meskipun anti-pola bukan satu-satunya
cara untuk menguasai pengetahuan manajemen, mereka dapat membuktikan menjadi
alat untuk membentuk komunitas belajar manajemen yang efektif,
fakta yang sudah kami alami di FLOSS. Pada akhirnya, satu
akan mengharapkan penggunaan anti-pola yang lebih intensif dalam pendidikan manajemen
perangkat lunak formal.