Universitas Gunadarma

Universitas Gunadarma

Minggu, 25 Januari 2015

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