Archive for Januari 2015
HERMES
HERMES
KATA
PENGANTAR
Assalamu’alaikum warahmatullahi wabarakatuh.
Alhamdulillahirabbilalamin, banyak nikmat yang Allah berikan, tetapi sedikit
sekali yang kita ingat. Segala puji hanya layak untuk Allah Tuhan seru sekalian
alam atas segala berkat, rahmat, taufik, serta hidayah-Nya yang tiada terkira
besarnya, sehingga penulis dapat menyelesaikan makalah dengan judul ”HERMES”.
Dalam penyusunannya, penulis memperoleh banyak bantuan dari berbagai pihak,
karena itu penulis mengucapkan terima kasih yang sebesar-besarnya kepada: Kedua
orang tua dan segenap keluarga besar penulis yang telah memberikan dukungan,
kasih, dan kepercayaan yang begitu besar. Dari sanalah semua kesuksesan ini
berawal, semoga semua ini bisa memberikan sedikit kebahagiaan dan menuntun pada
langkah yang lebih baik lagi. Meskipun penulis berharap isi dari makalah ini
bebas dari kekurangan dan kesalahan, namun selalu ada yang kurang. Oleh karena
itu, penulis mengharapkan kritik dan saran yang membangun agar skripsi ini
dapat lebih baik lagi. Akhir kata penulis berharap agar makalah ini bermanfaat
bagi semua pembaca. Penulis.
Chapter 1
PENDAHULUAN
1.1 PENJELASAN
AWAL
Manajemen adalah suatu kegiatan perencanaan,
pengorganisasian, penem- patan orang, pengendalian dan pengarahan. Proyek
adalah usaha sementara yang dilakukan untuk menciptakan produk atau jasa. Ini
menjadi usaha yang kontras dengan proses atau operasi yang permanen atau semi
permanen kerja fungsional yang sedang berlangsung untuk menciptakan produk yang
sama. Jadi Manajemen Proyek adalah suatu kegiatan yang merencanakan, men-
gorganisasikan, mengarahkan dan mengendalikan sumber daya organisasi untuk
mencapai tujuan tertentu dalam waktu tertentu dengan sumber daya tertentu pula.
Salah satu dari contoh dari manajemen proyek yang akan penuilis bahas yaitu
Hermes. Mengikuti contoh pemerintah Inggris dan Jerman, Pemerintah Swiss telah
mengembangkan Project Metode Manajemen sendiri yang dikenal dengan Her- mes.
Dan juga Hermes telah digunakan selama lebih dari 30 tahun. Domain pertama
aplikasi ini adalah proyek perangkat lunak. Hermes digunakan untuk mengelola
dan melaksanakan proyek-proyek dalam domain dari ICT dan juga merupakan standar
terbuka Pemerintahan Federal Swiss yang mendukung persyaratan yang paling
aktual. Ini adalah solusi lengkap, yang memenuhi kebutuhan sebagian besar jenis
proyek dan manajer proyek. Pekerjaan sedang berlangsung untuk mengintegrasikan
ke Hermes. Dokumen- tasi lengkap juga tersedia secara online. Konfederasi Swiss
adalah pemilik hak cipta dari metode Hermes. Dengan standardisasi prosedur dan
deskripsi spesi k hasil, tahapan, kegiatan dan peran yang bertanggung jawab
dalam perjalanan dari Hermes proyek bertujuan un- tuk meningkatkan transparansi
proyek, memfasilitasi perencanaan dan untuk meningkatkan kinerja.
1.2 METODE
HERMES
Hermes adalah pengembangan perangkat lunak yang
awalnya dikembangkan oleh Pemerintah Swiss, berdasarkan Jerman V-Modell. Hermes
merupakan metode yang berbasis fase, di mana beberapa tahap dapat diulang.
Hermes juga dapat disesuaikan dengan menggunakan alat PowerUser. Sub-modelnya
menggambarkan kegiatan yang tumpang tindih serta memberikan pandangan tambahan
tentang Peran dan Prosedur. Hermes merupakan proyek manajemen Swiss yang
mempunyai metode tebuka yang digunakan untuk mengelola, mengembangkan dan
melaksanakan proyek- proyek dalam Teknologi Informasi dan Komunikasi (TIK).
Metode ini wajib dalam Administrasi federal untuk semua proyek TIK. Metode
Hermes membantu pelaksanaan dan pengoperasian proyek-proyek di bidang teknologi
informasi dan komunikasi (TIK), baik di publik (Konfederasi, kanton, kotamadya)
ataupun di perusahaan-perusahaan. Ini merupakan standar terbuka yang
dikembangkan oleh Administrasi Federal Swiss. Hermes juga digunakan oleh
administrasi publik lainnya, perguruan tinggi serta bisnis dan telah menerapkan
metode ini untuk development proyek mereka. Untuk menegakkan sebuah proyek
terstruktur dengan baik, Hermes mem-bagi seluruh proses menjadi 6 fase yaitu :
• Inisialisasi • Pre-analisis • Konsep • Realisasi • Deployment • Finalisasi.
Dua jenis proyek Hermes yaitu: 1. Pengembangan sistem untuk implementasi solusi
dari awal 2. Sistem adaptasi untuk solusi pembelian. Metode manajemen proyek
Hermes ditujukan khususnya untuk semua manajer proyek dan juga Hermes
memfasilitasi banyak pekerjaan kolaborator proyek.
1.2.1 V-MODEL
V-Model adalah istilah yang digunakan untuk berbagai
model, dari model konseptual yang dirancang untuk menghasilkan pemahaman yang
sederhana dari kompleksitas yang berkaitan dengan pengembangan sistem untuk
rinci, model siklus pengembangan yang ketat dan model manajemen proyek. Ada
bentuk radikal berbeda dari V-model, hal ini menciptakan kebingungan yang cukup
besar. V-Model jatuh ke dalam tiga kategori besar. Kategori per- tama yaitu
V-Model Jerman "Das V-Modell", manajemen metodologi proyek resmi
pemerintah Jerman. metode ini kira-kira setara dengan PRINCE2 , tetapi lebih langsung
relevan dengan pengembangan perangkat lunak. AS juga memiliki standar
pemerintah V-Model, seperti rekan Jerman-nya. Jangkauannya agak sempit, menjadi
pengembangan sistem siklus hidup model, tetapi masih lebih jauh lebih rinci dan
lebih ketat daripada praktisi Inggris kebanyakan dan penguji akan mengerti
dengan V-Model. Di Inggris dan seluruh pengujian masyarakat di seluruh dunia,
V-Model se- cara luas dilihat sebagai samar, penggambaran ilustrasi dari proses
pengemban- gan perangkat lunak, seperti yang dijelaskan dalam Silabus Yayasan
ISTQB un- tuk penguji perangkat lunak. Tidak ada satu, diterima de nisi model
ini, yang lebih langsung dibahas dalam artikel alternatif pada V-Model
(pengembangan perangkat lunak) . Karena itu ada beberapa variasi dari versi
ini. Masalah ini harus diingat ketika membahas V-Model.
1.2.1.1 IKHTISAR
V-Model adalah representasi gra s dari siklus hidup
pengembangan sistem . Ini merangkum langkah-langkah utama yang harus diambil
dalam hubungannya dengan kiriman yang sesuai dalam validasi sistem
komputerisasi kerangka. V model merupakan urutan langkah-langkah dalam
pengembangan kehidu- pan siklus proyek. Ini menggambarkan kegiatan yang akan
dilakukan dan hasil yang harus dihasilkan selama pengembangan produk. Sisi kiri
dari "V" meru- pakan dekomposisi dari persyaratan, dan penciptaan
spesi kasi sistem. Sisi kanan V merupakan bagian integrasi dan validasi mereka.
Kadang-kadang dikatakan validasi yang dapat dinyatakan dengan query
"Apakah Anda membangun hal yang benar?" dan veri kasi oleh
"Apakah Anda mem- bangun dengan benar?" Dalam prakteknya, penggunaan
istilah-istilah ini bervariasi. Kadang-kadang mereka bahkan digunakan secara
bergantian. Panduan PMBOK , sebuah IEEE standar, mende nisikan mereka sebagai
berikut dalam edisi ke-4 .
1.2.1.2 TUJUAN
V-Model memberikan panduan untuk perencanaan dan
realisasi proyek. Tu- juan berikut ini dimaksudkan untuk dicapai oleh
pelaksanaan proyek: • Meminimalkan Resiko Proyek V-Model meningkatkan
transparansi proyek dan pengendalian proyek den- gan menentukan pendekatan
standar dan menggambarkan hasil yang sesuai dan peran yang bertanggung jawab.
Ini memungkinkan pengakuan awal perencanaan penyimpangan dan risiko dan
manajemen proses membaik, sehingga mengurangi resiko proyek.
• Peningkatan dan Jaminan Mutu Sebagai model proses
standar, V-Model memastikan bahwa hasil yang akan diberikan adalah lengkap dan
memiliki kualitas yang diinginkan. Hasil sementara Ditetapkan dapat diperiksa
pada tahap awal. Isi pro- duk yang seragam akan lebih mudah dibaca, dimengerti
dan pemastian. • Pengurangan Biaya Total lebih dari Proyek Seluruh dan Siklus
Hidup Sistem Upaya untuk produksi operasi pembangunan, dan pemeliharaan sistem
dapat dihitung, diperkirakan dan dikendalikan secara transparan dengan
menerapkan model proses standar. Hasil yang diperoleh adalah seragam dan mudah
menelusuri kembali. Ini mengurangi ketergantungan pada pemasok acquirers dan
upaya untuk kegiatan selanjutnya dan proyek. • Peningkatan Komunikasi antara
semua Stakeholder Deskripsi standar dan seragam dari semua elemen yang relevan
dan per- syaratan merupakan dasar untuk saling pengertian antara semua stake-
holder. Dengan demikian, kerugian gesekan antara pengguna, pemasok acquirer,
dan pengembang berkurang.
1.2.2 SISTEM
TEKNIK DAN VERIFIKASI
Rekayasa Sistem Proses (SEP) menyediakan jalur untuk
meningkatkan efek- tivitas biaya sistem yang kompleks seperti yang dialami oleh
pemilik sistem selama masa seluruh sistem, dari konsepsi sampai pensiun. Ini
melibatkan identi kasi awal dan komprehensif tujuan, konsep operasi yang
menggambarkan kebutuhan pengguna dan lingkungan operasi, persyaratan sistem
menyeluruh dan dapat diuji, desain rinci, implementasi, pengujian pener- imaan
yang ketat dari sistem yang diterapkan untuk memastikan memenuhi persyaratan
yang dinyatakan (sistem veri kasi ), mengukur efektivitas dalam menangani
tujuan (validasi sistem), yang sedang berlangsung operasi dan pemeli- haraan,
upgrade sistem dari waktu ke waktu, dan akhirnya pensiun. Proses ini menekankan
persyaratan-driven desain dan pengujian. Semua elemen desain dan tes penerimaan
harus dapat dilacak dari satu atau lebih persyaratan sistem dan setiap
kebutuhan harus ditangani oleh setidaknya satu elemen desain dan uji
penerimaan. Kekakuan tersebut memastikan tidak ada yang dilakukan tidak perlu
dan segala sesuatu yang diperlukan tercapai .
1.2.3 ALIRAN
SPESIFIKASI
Aliran Spesi kasi terutama terdiri dari: • Pengguna
Persyaratan Spesi kasi • Fungsional Kebutuhan Spesi kasi • Desain Spesi kasi
Aliran pengujian umumnya terdiri dari: • Instalasi Kuali kasi (IQ) •
Operasional Kuali kasi (OQ) • Kinerja Kuali kasi (PQ) Aliran pembangunan dapat
terdiri (tergantung pada jenis sistem dan ruang lingkup pengembangan)
kustomisasi, kon gurasi atau coding.
1.2.4 APLIKASI
V-model ini digunakan untuk mengatur proses
pengembangan perangkat lu- nak dalam pemerintahan federal Jerman. Saat ini
masih standar untuk Jerman proyek pemerintah federal dan pertahanan, serta
pengembang perangkat lunak di kawasan ini. Konsep Model V-dikembangkan secara
bersamaan, namun secara indepen- den, di Jerman dan di Amerika Serikat pada
akhir 1980-an: • Jerman V-Model awalnya dikembangkan oleh IABG di Ottobrunn,
dekat Munich, bekerjasama dengan Kantor Federal untuk Teknologi Pertahanan dan
Pengadaan di Koblenz, untuk Kementerian Federal Pertahanan. Itu diambil alih
oleh Kementerian Federal Dalam Negeri untuk domain otori- tas sipil umum di
musim panas 1992. • AS V-Model, yang didokumentasikan dalam 1991 proses untuk
Dewan Na- sional Sistem dan Teknik (NCOSE, sekarang INCOSE pada 1995), dikem-
bangkan untuk sistem satelit yang melibatkan hardware, software, dan interaksi
manusia. • V-Model pertama kali muncul di Hughes Aircraft sekitar tahun 1982
se- bagai bagian dari upaya pra-proposal untuk Sistem Otomasi Lanjutan FAA
(AAS) program. Ini akhirnya membentuk strategi uji untuk Tahap Desain AAS
Hughes Competition (DCP) proposal. Ini diciptakan untuk menunjukkan tes dan
pendekatan integrasi yang didorong oleh tantangan baru ke permukaan cacat laten
dalam perangkat lunak. Kebutuhan un- tuk tingkat baru deteksi cacat laten
didorong oleh tujuan untuk memulai mengotomatisasi pemikiran dan perencanaan
proses pengendali lalu lintas udara yang diusulkan oleh Kontrol Udara Enroute
Lalu Lintas Otomatis (Aera) program. Alasan V begitu kuat berasal dari budaya
Hughes ko- pling semua teks dan analisis gambar multi dimensi. Ini adalah dasar
dari Organisasi Tematik Sequential Publikasi (TITIK) diciptakan oleh Hughes
pada tahun 1963 dan digunakan sampai Hughes divestasi oleh Howard Hughes
Medical Institute pada tahun 1985. • Ia telah menemukan aplikasi luas dalam
program pertahanan komersial serta. Penggunaan utamanya adalah dalam Manajemen
Proyek dan di seluruh siklus hidup proyek. • Salah satu ciri mendasar dari AS
V-Model adalah bahwa langkah waktu dan jatuh tempo dari kiri ke kanan dan satu
tidak bisa bergerak kembali dalam waktu. Iterasi semua adalah sepanjang garis
vertikal ke tingkat yang lebih tinggi atau lebih rendah dalam hirarki sistem,
seperti yang ditunjukkan pada gambar. Hal ini telah terbukti menjadi aspek
penting dari model. Perluasan model untuk konsep dual-Vee diperlakukan dalam
referensi. • Sebagai V-model tersedia untuk umum banyak perusahaan juga menggu-
nakannya. Dalam manajemen proyek itu adalah metode sebanding den- gan PRINCE2
dan menjelaskan metode untuk manajemen proyek serta metode untuk pengembangan
sistem . V-Model sementara kaku dalam proses, bisa sangat eksibel dalam
aplikasi, khususnya yang berkaitan den- gan ruang lingkup di luar bidang Sistem
Pembangunan parameter Lifecy- cle normal.
1.2.5 KEUNTUNGAN
Ini adalah keuntungan V-Model menawarkan di depan
model pengembangan sistem lainnya: • Para pengguna Model V-berpartisipasi dalam
pembangunan dan pemeli- haraan Model V-. Sebuah panel kontrol perubahan publik
memperta- hankan V-Model. Panel kontrol perubahan bertemu di mana saja dari
setiap hari untuk memproses permintaan mingguan dan semua peruba- han yang
diterima selama pengembangan sistem dan pengujian. • V-Model memberikan bantuan
kongkrit tentang bagaimana menerapkan kegiatan dan langkah-langkah kerjanya,
mende nisikan secara eksplisit peristiwa yang dibutuhkan untuk menyelesaikan
langkah kerja: setiap skema kegiatan berisi petunjuk, rekomendasi, dan
penjelasan rinci dari kegiatan tersebut.
1.2.6 BATAS
Aspek-aspek berikut tidak tercakup oleh V-Model ,
mereka harus diatur di samping atau V-Model harus disesuaikan sesuai: •
Penempatan kontrak untuk layanan tidak diatur • Organisasi dan pelaksanaan
operasi, pemeliharaan perbaikan, dan pem- buangan dari sistem yang tidak
tercakup oleh V-Model. Namun, peren- canaan dan penyusunan konsep untuk
tugas-tugas yang diatur dalam V- Model . • V-Model mengembangkan perangkat
lunak dalam proyek daripada seluruh organisasi.
1.3 VERIFIKASI
FASE DARI V-MODEL
1.3.1 PERSYARATAN
ANALIS
Dalam analisis Persyaratan fase, langkah pertama dalam
proses veri kasi, persyaratan dari sistem yang diusulkan dikumpulkan dengan
menganalisis ke- butuhan pengguna. Fase ini berkaitan dengan membangun sistem
apa yang ideal harus dilakukan. Namun itu tidak menentukan bagaimana perangkat
lu- nak ini akan didesain atau dibangun. Biasanya, pengguna yang diwawancarai
dan dokumen yang disebut pengguna persyaratan dokumen yang dihasilkan. Pengguna
persyaratan dokumen biasanya akan menjelaskan fungsi sistem, antarmuka,
kinerja, data, keamanan,serta persyaratan seperti yang diharapkan oleh
pengguna. Hal ini digunakan oleh analis bisnis untuk mengkomunikasikan
pemahaman mereka tentang sistem untuk pengguna. Para pengguna hati-hati
meninjau dokumen ini sebagai dokumen ini akan berfungsi sebagai pedoman bagi
perancang sistem dalam tahap desain sistem. Tes penerimaan pengguna yang
dirancang dalam fase ini. Lihat juga persyaratan Fungsional . Ada berbagai
metode untuk mengumpulkan persyaratan metodologi baik lunak dan keras termasuk,
wawancara, kuesioner, analisis dokumen, observasi, membuang-jauhnya prototipe,
kasus penggunaan dan pandangan statis dan di- namis dengan pengguna.
1.3.2 SISTEM
DESAIN
Desain sistem adalah fase di mana insinyur sistem
menganalisis dan mema- hami bisnis dari sistem yang diusulkan dengan
mempelajari dokumen persyaratan pengguna. Mereka mengetahui kemungkinan dan
teknik dimana kebutuhan pengguna dapat diimplementasikan. Jika salah satu
persyaratan yang tidak layak, pengguna informasi dari masalah. Sebuah resolusi
ditemukan dan doku- men persyaratan pengguna diedit sesuai. Spesi kasi
perangkat lunak dokumen yang berfungsi sebagai cetak biru un- tuk tahap
pengembangan yang dihasilkan. Dokumen ini berisi organisasi sis- tem umum,
struktur menu, struktur data dll Hal ini juga dapat memegang skenario bisnis
contoh, jendela sampel, laporan untuk pemahaman yang lebih baik. Dokumentasi
teknis lainnya seperti diagram entitas, kamus data juga akan diproduksi di fase
ini. Dokumen-dokumen untuk pengujian sistem yang disiapkan dalam fase ini.
1.3.3 ARSITEKTUR
DESAIN
Fase desain arsitektur komputer dan arsitektur
perangkat lunak juga da- pat disebut sebagai desain tingkat tinggi. The dasar
dalam memilih arsitektur adalah bahwa ia harus menyadari semua yang biasanya
terdiri dari daftar modul, fungsi singkat setiap modul, mereka antarmuka
hubungan, dependensi , basis data tabel , diagram arsitektur, rincian teknologi
dll desain pengujian integrasi dilakukan dalam fase tertentu.
1.3.4 MODUL
DESAIN
Desain modul fase juga dapat disebut sebagai tingkat
rendah desain. Sistem yang dirancang dipecah menjadi unit yang lebih kecil atau
modul dan masing- masing dijelaskan sehingga pemrogram dapat mulai coding
secara langsung. Desain dokumen tingkat rendah atau spesi kasi program berisi :
• tabel database, dengan semua elemen, termasuk jenis dan ukuran • semua
rincian antarmuka dengan lengkap API referensi • semua masalah ketergantungan •
error message listing • menyelesaikan input dan output untuk modul.
1.3.5 VALIDASE
FASE
1. Unit Pengujian Dalam pemrograman komputer, unit
testing adalah metode dimana unit individu dari kode sumber yang diuji untuk
menentukan apakah mereka cocok untuk digunakan. Unit adalah bagian terkecil
dari diuji aplikasi. Dalam pemrograman prosedural unit mungkin merupakan fungsi
individ- ual atau prosedur. Unit test yang dibuat oleh programmer atau kadang-
kadang oleh penguji kotak putih. Tujuannya adalah untuk memveri kasi kode
logika internal dengan menguji setiap cabang mungkin dalam fungsi, juga dikenal
sebagai cakupan tes. Alat analisis statis digunakan untuk memudahkan dalam
proses ini, di mana variasi data masukan yang dile- watkan ke fungsi untuk
menguji setiap kemungkinan kasus eksekusi. 2. Integrasi Pengujian Dalam
pengujian integrasi modul terpisah akan diuji bersama-sama un- tuk mengekspos
kesalahan dalam antarmuka dan dalam interaksi antara komponen terintegrasi.
Pengujian biasanya kotak hitam sebagai kode ini tidak langsung diperiksa untuk
kesalahan. 3. Pengujian Sistem Pengujian sistem akan membandingkan spesi kasi
sistem terhadap sis- tem yang sebenarnya. Setelah tes integrasi selesai,
tingkat tes berikutnya adalah tes sistem. Pengujian sistem memeriksa apakah
produk terintegrasi memenuhi persyaratan yang ditentukan.
1.3.6 PENGGUNAAN
PENGUJIAN PENERIMAAN
Pengujian penerimaan adalah tahap pengujian digunakan
untuk menentukan apakah sistem memenuhi persyaratan yang ditentukan dalam tahap
analisis persyaratan. Desain tes penerimaan berasal dari dokumen persyaratan.
Tahap uji penerimaan adalah fase yang digunakan oleh pelanggan untuk menentukan
apakah akan menerima sistem atau tidak. Pengujian penerimaan membantu : • untuk
menentukan apakah sistem memenuhi kriteria penerimaan atau tidak. • untuk
memungkinkan pelanggan untuk menentukan apakah akan mener- ima sistem atau
tidak. • untuk menguji perangkat lunak di dunia nyata oleh audiens. Tujuan
pengujian penerimaan: untuk memveri kasi sistem atau perubahan sesuai dengan
kebutuhan aslinya
1.3.7 RILIS
PENGUJIAN
Pengujian rilis adalah fase yang menentukan apakah
software ini cocok untuk organisasi pengguna akhir.
1.3.8 KRITIK
V-Model telah dikritik oleh pendukung Agile dan
lain-lain sebagai model yang tidak memadai dari pengembangan perangkat lunak
untuk berbagai alasan, Kritiknya meliputi: • Hal ini terlalu sederhana untuk
secara akurat mencerminkan proses pengem- bangan perangkat lunak, dan dapat
menyebabkan manajer menjadi rasa aman yang palsu. V-Model mencerminkan
pandangan manajemen proyek pengembangan perangkat lunak dan sesuai dengan
kebutuhan manajer proyek, akuntan dan pengacara ketimbang pengembang perangkat
lunak atau pengguna. • Meskipun Hal ini mudah dipahami oleh pemula, bahwa
pemahaman awal hanya berguna jika pemula melanjutkan untuk memperoleh pemahaman
yang lebih dalam proses pembangunan dan bagaimana V-Model harus disesuaikan dan
diperluas dalam praktek. Jika praktisi bertahan dengan pandangan naif mereka,
V-Model akan mengalami kesulitan besar untuk berhasil. • Ini adalah eksibel dan
mendorong pandangan kaku dan linear dari pengem- bangan perangkat lunak dan
tidak memiliki kemampuan inheren untuk menanggapi perubahan. • Ini hanya
menyediakan varian sedikit pada model air terjun dan karena itu tunduk pada
kritik yang sama sebagai model itu. Ini memberikan penekanan lebih besar pada
pengujian, dan khususnya pentingnya peren- canaan tes awal. Namun, kritik
praktis umum dari V-model adalah bahwa hal itu mengarah ke pengujian yang
diperas ke jendela ketat di akhir pem- bangunan saat tahap sebelumnya telah
dikuasai namun tanggal pelak- sanaan masih tetap. • Hal ini konsisten dengan,
dan karena itu secara implisit mendorong, metodologi pengujian tidak e sien dan
tidak efektif. Ini implisit mempromosikan menulis skrip uji terlebih dahulu
daripada pengujian eksplorasi, melainkan mendorong penguji untuk mencari apa
yang mereka harapkan untuk men- emukan, daripada menemukan apa yang benar-benar
ada. Hal ini juga mendorong hubungan yang kaku antara tingkat setara leg kedua
(misalnya pengguna tes penerimaan rencana yang berasal dari dokumen kebutuhan
pengguna), daripada mendorong penguji untuk memilih cara yang paling efektif
dan e sien untuk merencanakan dan melaksanakan pengujian. • Itu tidak memiliki
koherensi dan presisi. Ada kebingungan yang meluas tentang apa sebenarnya
V-Model. Jika salah satu dari elemen-elemen yang kebanyakan orang akan setuju
atas menjadi representasi hambar dan tidak membantu pengembangan perangkat
lunak. Ketidaksepakatan ten- tang manfaat dari V-model sering mencerminkan
kurangnya pemahaman bersama tentang de nisi.
1.3.9 KEADAAN
V-MODEL SAAT INI
Pendukung V-Model berpendapat bahwa hal itu telah
berkembang dari waktu ke waktu dan mendukung eksibilitas dan kelincahan seluruh
proses pembangunan. Mereka berpendapat bahwa selain menjadi pendekatan yang
sangat disiplin, itu mempromosikan desain teliti, pengembanV-Model memiliki
beberapa kelebihan. Kelebihan-kelebihan tersebut secara garis besar dapat
dijelaskan seperti berikut: • V-Model sangat eksibel. V-Model mendukung project
tailoring dan pe- nambahan dan pengurangan method dan tool secara dinamik.
Akibatnya sangat mudah untuk melakukan tailoring pada V-Model agar sesuai den-
gan suatu proyek tertentu dan sangat mudah untuk menambahkan method dan tool
baru atau menghilangkan method dan tool yang dianggap sudah obsolete. • Model
dikembangkan dan di-maintain oleh publik. User dari V-Model berpartisipasi
dalam change control board yang memproses semua change request terhadap
V-Model. gan, dan doku- mentasi yang diperlukan untuk membangun stabil produk
perangkat lunak.
1.4 KELEBIHAN
V-MODEL
V-Model memiliki beberapa kelebihan.
Kelebihan-kelebihan tersebut secara garis besar dapat dijelaskan seperti
berikut: • V-Model sangat eksibel. V-Model mendukung project tailoring dan pe-
nambahan dan pengurangan method dan tool secara dinamik. Akibatnya sangat mudah
untuk melakukan tailoring pada V-Model agar sesuai den- gan suatu proyek
tertentu dan sangat mudah untuk menambahkan method dan tool baru atau
menghilangkan method dan tool yang dianggap sudah obsolete. • Model
dikembangkan dan di-maintain oleh publik. User dari V-Model berpartisipasi
dalam change control board yang memproses semua change request terhadap
V-Model.
1.5 KEKURANGAN
V-MODEL
V-Model juga memiliki beberapa kekurangan.
Kekurangan-kekurangan terse- but yaitu: • V-Model adalah model yang project
oriented sehingga hanya bisa digu- nakan sekali dalam suatu proyek. • V-Model
terlalu eksibel dalam arti, ada beberapa activitas dalam V- Model yang
digambarkan terlalu abstrak sehingga tidak bisa diketahui dengan jelas apa yang
termasuk dalam activity tersebut dan apa yang tidak
1.6 PENGGUNAAN
V-MODEL
V-Model digunakan dalam proyek teknologi informasi di
negara Jerman. Hal ini berlaku terutama untuk proyek teknologi informasi pada
pada sektor pertahanan negara Jerman. Selain itu, V-Model juga digunakan oleh
software developer negara Jerman untuk proyek teknologi informasi lain.
1.7
PERKEMBANGAN HERMES DARI TAHUN KE TAHUN
Perkembangan Hermes dari tahun ke tahun bisa kita
lihat dibagian bawah 1. Versi terbaru dari Hermes adalah Hermes 5, dimana proyek
manajement ini baru akan tersedia pada pertengahan tahun 2013 ini. Perubahan
Hermes 5 dari yang sebelumnya diperkirakan ada pada bidang berikut ini: •
Penyederhanaan metode (misalnya pengurangan lingkup dokumen- tasi, penekanan
lebih besar pada titik pandang klien) • Kejelasan dalam aplikasi (misalnya
tangkas aplikasi, model fase yang konsisten, pengurangan / ringkasan hasil) •
IT governance dalam proyek (hasil minimal misalnya sesuai COBIT) • Aktualitas
metode (misalnya integrasi portofolio proyek, penggabun- gan IT dan arsitektur
layanan ) • Alat pendukung. 2. Tahun 2011 FSUIT akan menentukan perkembangan
lebih lanjut dari Her- mes atas dasar evaluasi oleh Komite Ahli. 3. Tahun 2010
Komite Ahli tentang metode manajemen proyek akan diben- tuk. Tujuannya adalah
untuk mengevaluasi tren saat ini dan persyaratan untuk metode manajemen proyek.
Evaluasi harus mendorong pengem- bangan dari versi berikutnya dari Hermes. 4.
Pada tahun 2008-2010 mengoptimalisasikan alat pendukung penerapan Hermes. Yang
menarik pada tahun ini yaitu: • Adanya dukungan elektronik dari manajer proyek
dengan Hermes PowerUser 2.0 • Integrasi metode dalam perusahaan • Analisis mata
pelajaran yang berbeda bekerja sama dengan kelompok- kelompok Hermes khusus ech
• Manajemen elektronik dari isi pengguna Hermes 5. Pada tahun 2008 Hermes
PowerUser Rilis 2.0 tersedia dalam bahasa Jer- man dan Perancis. 6. Pada tahun
2007 Serti kasi untuk kolaborasi proyek Hermes dan manajer proyek tersedia. SAQ
diberi mandat untuk melakukan serti kasi dan Hermes PowerUser (Release 1.0)
juga telah tersedia. 7. Pada tahun 2006 Hermes adalah standar Ech. 13 8. Pada
tahun 2005 Hermes-Systemadadaption (SA) diterbitkan. Ini terutama berkaitan
dengan bagian dari pengembangan sistem. Sisanya dari manual pada dasarnya identik
dengan pengguna SE. 9. Pada tahun 2003 terjadi Revisi Hermes. Ini telah
didokumentasikan secara metodologis, sebuah manual pertama mencakup Hermes
Systementwick- lung (SE) (yang pada dasarnya bagian dari pengembangan sistem
dalam bahasa Jerman dan Perancis dengan semua aspek dari manajemen proyek yang
tertutup). Publikasi Hermes Manajer dalam 4 bahasa. Ini memberikan panduan yang
berguna bagi manajer (manajer ini bertanggung jawab atas manajer proyek) secara
keseluruhan bertanggung jawab untuk keseluruhan proyek. Hermes juga diakui
sebagai standar terbuka. Hermes lebih banyak diter- apkan dalam pemerintahan
Swiss dan di industri. 10. Pada tahun 1995, Hermes diterbitkan dalam bahasa
Jerman. Hal ini di- dasarkan pada model V Jerman. 11. Pada tahun 1986 Hermes
diterbitkan dalam bahasa Jerman. 12. Tahun 1975 Hermes versi pertama muncul.
Hal ini diakui serta standar luar pemerintahan Swiss. 13. Tahun 1970 Pemerintah
Swiss mulai pembangunannya sendiri dari metode manajemen proyek untuk
proyek-proyek TIK. Proyek ini diberi nama Her- mes. 2.7 Tujuan dan Konsep
Hermes Proyek Hermes berorientasikan target manajemen, pelaksanaan dan pengen-
dalian. Tujuan Hermes adalah untuk menawarkan dukungan kepada semua pihak yang
terlibat dalam tantangan yang kompleks dalam pengelolaan tugas khusus mereka.
Hermes mengusulkan prosedur tujuan dan hasil proyek berorientasi. Dengan
demikian, mempertimbangkan kepentingan-kepentingan dan tugas dari pembeli dan
manajer proyek, serta orang-orang dari kolaborator proyek serta menciptakan
kondisi yang tepat untuk koordinasi sukses antara semua peserta, dengan
menyediakan bahasa yang umum. Struktur Hermes berupa pengembangan dan
pelaksanaan proyek dengan hasil dan kegiatan proyek diperlukan dan serta
tanggung jawab yang kuat. Nama metode dan menggambarkan fase kegiatan spesi k
dan sifat mereka, serta tumpang tindih dan tugas seiring diperlukan untuk
penjaminan keberhasilan proyek, sebagaimana terangkum dalam sub-model (seperti
manajemen proyek, jaminan kualitas dan manajemen risiko). Penerapan Hermes
meningkatkan transparansi proyek. Ini memudahkan pe- mantauan kemajuan proyek
dan memungkinkan koreksi lebih cepat dan ditar- getkan akan dilakukan selama
berlangsungnya proyek, jika perlu harus muncul. Kami menghubungkan teknologi
inovatif kami dengan bertahun-tahun pen- galaman kami dalam rangka untuk
mengintegrasikan tren aktual dalam pe- nawaran kami. Kami mengembangkan produk
dengan kebanggaan dan gairah dan dalam melakukannya, kami menempatkan pelanggan
dalam fokus mutlak, selalu dan di mana-mana. 1. Target kami adalah untuk
menyediakan pelanggan kami dengan user- friendly dan up to date dan produk jasa
yang menawarkan kualitas tert- inggi dan fungsionalitas pada waktu yang sama.
Penerapan teknologi kami dan kolaborasi dengan mitra terbaik di seluruh dunia
akan diprioritaskan dalam kepentingan pelanggan kami. 2. Kami menumbuhkan
budaya bisnis yang terbuka di mana sebuah tim, kuat profesional unremittingly
menangani tantangan baru. Di atas semua kami menghargai individualitas setiap
rekan kerja tunggal dan berusaha untuk memajukan nya / kemampuan individu. 3.
Dengan asumsi responsibilites untuk negara kita diwakili dalam dan menghor-
mati budaya masing-masing dan sejarah, kami ingin berkontribusi secara positif
bagi perkembangan masyarakat global. 4. Pada semua kegiatan bisnis kami
perlindungan alam, keselamatan serta kesejahteraan masyarakat dan konservasi
sumber daya alam peringkat per- tama - dengan kami transfer data dilakukan
dengan cara menghemat sum- ber daya. 5. Kami selalu bertujuan untuk
memaksimalkan nilai perusahaan kami, se- cara konsisten meningkatkan manajemen
perusahaan kami dan sesuai berin- vestasi dalam penelitian dan pengembangan
dalam rangka untuk men- gatasi dan melampaui harapan pelanggan kami dan mitra.
2.7.1 Tujuan Browsing Menggunakan JMS Hermes WebLogic Server Konsol
Administrasi dilengkapi dengan tur untuk me- mantau dan melihat pesan JMS dari
WebLogic 9.x dan seterusnya. Namun itu adalah berbasis web (konsol) alat yang
dioptimalkan untuk pemantauan kon- gurasi, dan pengujian tidak pembangunan. Hal
ini tidak dapat melakukan beberapa kegiatan JMS canggih seperti menyalin pesan
dari satu antrian yang lain sangat mudah. Hermes JMS adalah konsol extensible
yang membantu Anda berinteraksi dengan penyedia JMS sehingga mudah untuk
menelusuri atau men- cari antrian dan topik, pesan copy sekitar dan
menghapusnya. Sepenuhnya terintegrasi dengan JNDI membiarkan Anda menemukan
benda diberikan dis- impan, membuat sesi JMS dari pabrik koneksi dan
menggunakan tujuan dite- mukan. Banyak penyedia termasuk plug-in yang
menggunakan API asli un- tuk melakukan non-JMS hal-hal seperti mendapatkan
kedalaman antrian (dan statistik lainnya) atau menemukan nama antrian dan
topic. Ini alat kecil namun kuat bekerja dengan banyak penyedia JMS populer
seperti WebLogic JMS, Tibco EMS, JBoss MQ, Sonic MQ, WebSphere MQ, OpenJMS, SAP
dll, Dalam buku ini kita akan melihat bagaimana mendapatkan Hermes diinstal dan
dikon gurasi untuk digunakan dengan WebLogic JMS. • Unduh installer • Run
"java-jar hermes-installer-1.13.jar" • Edit / Bin / hermes.bat atau
hermes.sh dan set JAVA_HOME • Buat JMS module> Connection Pabrik> Tujuan
• Launch Hermes dengan memanggil para hermes.bat • Klik kanan pada
"sesi" dan pilih "baru -> sesi New" • Buka tab
"penyedia" di bagian bawah dan menambahkan "kelompok" yang
disebut "weblogic10" dan "perpustakaan" menentukan jalan
menuju weblogic.jar. Pilih "Jangan Pindai" saat diminta. (Saya
menggunakan WLS 10,0 GA untuk posting ini) • Simpan kon gurasi. • Klik pada tab
"Sesi". Masukkan nama untuk sesi (dalam hal ini "examp-
lesQCF"). Pilih "BEA WebLogic" untuk "Plug In" bagian
dari dropdown. Dalam "Pabrik Connection", pilih
"weblogic10" untuk loader. Untuk sifat nilai merujuk pada gambar di
bawah (yang mengikat, URL dan keper- cayaan akan khusus untuk pengaturan Anda
WLS). • Sekarang klik kanan pada sesi baru dibuat "examplesQCF" dan
pilih Temukan. Ini akan daftar semua tujuan yang tersedia di bawah sesi ex-
amplesQCF. • Sekarang klik kanan pada satu entri di bawah Sesi dan pilih
"Browse", Anda harus dapat melihat isi dari antrian.
1.8
KOMPONEN-KOMPONEN HERMES
Hermes sebagai solusi Global untuk standarisasi dalam
melaksanakan proyek- proyek mempunyai komponen-komponen sebagai berikut: 1.
Penerapan sub-model untuk kombinasi yang lebih baik dari tugas yang tumpang
tindih dalam melakukan sebuah proyek. Lima dasar sub-model Hermes yaitu: •
Proyek Manajemen • Jaminan Mutu • Manajemen kon gurasi • Manajemen risiko •
Proyek pemasaran 2. Peningkatan integrasi perlindungan keamanan informasi dan
data dalam prosedur proyek 3. Meningkatkan de nisi dan deliniasi tugas,
tanggung jawab dan peran dari semua peserta proyek 4. Penggabungan pengalaman
yang luas dari proyek-proyek sebelumnya.
1.9 KEUNTUNGAN
HERMES
Hermes menggambarkan proses nyata menggunakan model
berbasis fase, menentukan untuk setiap fase hasil yang diperlukan dan peran
yang spesi- k. Hermes meningkatkan transparansi, memudahkan perencanaan dan
pelak- sanaan proyek. Tentu saja, salah satu cara untuk melakukan akurat dan
transparan adalah penting untuk menyederhanakan kolaborasi dalam proyek, dan
ini terlepas dari apakah Anda menggunakan Hermes atau metode lain. Keberadaan
bahasa umum akan tetap menjadi kebutuhan dasar bagi keberhasilan proyek. Kunci
kesuksesan juga denda campuran akal sehat, pengalaman, aturan, hubungan dan
pengetahuan profesional. Manajer proyek dapat dibandingkan dengan konduktor
yang diinstruksikan untuk menggunakan bakat dan sumber daya yang tersedia dan
membawa mereka ke dalam kebersamaan. Dalam penggunaan Hermes memiliki banyak
keuntungan seperti: • Informasi yang berkualitas sistem yang baik • Menurunkan
resiko proyek • Mengurangi biaya pengembangan dan tepat waktu • Keterbukaan
dalam penawaran.
Chapter 2
DAFTAR
PUSTAKA
WWW.GOOGLE.COM
