Laman

Minggu, 06 Maret 2011

Fase Deployment

Tahap Penyebaran (Deployment) adalah tahap dimana sistem dibuat tersedia bagi komunitas pengguna. Tergantung pada komunitas pengguna, ini mungkin memerlukan tambahan sumber daya IT. Proses penyebaran harus direncanakan dengan baik sehingga meminimalkan downtime dan dampak untuk mengakhiri produktivitas pengguna.Hal ini tidak hanya mencakup perangkat keras dan perangkat lunak tetapi pengguna akhir.Tahap penyebaran meliputi tugas-tugas berikut:

System Build
Sistem proses build meliputi pembuatan perangkat lunak dan penyebaran otomatis
paket, dan meletakkan sistem ke dalam database manajemen konfigurasi
(CMDB).Itu CMDB akan dibahas lebih detail di banyak di kemudian hari, tetapi untuk
sekarang mari kita mendefinisikan CMDB sebagai tempat dimana sistem membangun citra disimpan untuk
deployments mendatang.Hal ini dapat sederhana atau sangat rumit, tergantung pada
sejumlah sistem dan lingkungan operasi yang mengelola organisasi TI.
The CMDB bisa menjadi membangun sistem atau bahkan sistem penyebaran atau manajemen, melainkan
tergantung pada bagaimana organisasi TI Anda memilih untuk mengelola sistem.

Hardening
Sistem pengerasan adalah proses meningkatkan keamanan sistem dengan menambahkan
tindakan keamanan dan mematikan atau menghapus yang tidak perlu, port perangkat lunak berputar, dan
layanan.Jumlah pengerasan dilakukan pada sebuah sistem harus didasarkan
pada penilaian risiko yang mencakup kekritisan dari sistem dan nilai
informasi proses sistem atau toko.Overhardening sistem dapat merender
sistem tidak dapat digunakan untuk tujuan yang telah.Underhardening sistem dapat menyebabkan
sistem kompromi, hilangnya data, dan biaya pemulihan yang luas.

Installation
Proses membangun meliputi penciptaan gambar sistem standar.instalasi
Proses menyebarkan gambar tersebut untuk sistem produksi.Instalasi termasuk membuat
dan mengkonfigurasi sistem baru, memperkenalkan software baru ke sistem yang sudah ada,
memperbarui konfigurasi sistem yang ada, dan membuat dan pelacakan
manajemen perubahan permintaan, persetujuan, dan penutup.Proses pemasangan dapat
menjadi sangat rumit bila cakupan TI organisasi yang lebih mencakup
dari sistem beberapa ribu, terutama jika sistem yang terpisah secara geografis.
Ketika mengelola basis instalasi yang besar, perusahaan harus menggunakan perangkat lunak produk manajemen untuk mengelola dan sistem konfigurasi penyebaran.
Sistem Perangkat Lunak Manajemen
Ada banyak sistem manajemen paket yang tersedia untuk menangani berbagai
kebutuhan organisasi.Pentingnya aspek sebagian besar perangkat lunak manajemen
produk adalah kemampuan organisasi untuk mengoperasikan dan memeliharanya.Harus ada
menjadi proses yang di tempat untuk mengatur bagaimana sistem digunakan, staf, dan dipelihara.
Banyak manajemen perusahaan membeli perangkat lunak tanpa mengatasi organisasi
overhead yang diperlukan.A-tim yang terlatih serta personil pendukung sistem
akan dibutuhkan untuk mendapatkan hasil maksimal dari perangkat lunak manajemen sistem.

Kompatibilitas Sistem Pengujian
Pengujian interoperabilitas dalam ujian dan menstabilkan tahap mencari kompatibel
antara komponen sistem saling terkait.pengujian Kompatibilitas mencari kompatibel
dengan komponen terkait.Ketika menginstal software baru atau sistem,
tim uji harus ditugaskan untuk memverifikasi kompatibilitas antara yang ada
paket perangkat lunak dan upgrade.Kompatibilitas pengujian sangat penting
dalam organisasi dengan sejumlah besar aplikasi dikerahkan.

Change Control
Semua organisasi TI harus memiliki kontrol program perubahan di tempat.Ubah kontrol
adalah cara untuk semua orang saling berhubungan dan proses untuk menyadari dan
menyetujui perubahan yang dibuat untuk sistem yang mempengaruhi organisasi.Selama penugasan,
tim implementasi sistem akan perlu untuk mengajukan, melacak, dan menutup satu atau lebih
permintaan perubahan (RFC).RFC disalurkan, review, dan disetujui oleh
organisasi manajemen perubahan program.Untuk proyek penyebaran utama, manajer proyek
biasanya merupakan peserta aktif pada papan kontrol perubahan dan dapat diberikan
persetujuan perubahan kewenangan untuk perubahan di bawah bidang nya.

Operasi Verifikasi
Setelah sistem ini dikerahkan harus ada cara untuk memverifikasi bahwa mereka melakukan
ke tingkat yang diharapkan.Hal ini dapat diukur dengan kombinasi kepatuhan dan
perangkat lunak manajemen alat.Sistem harus melakukan seperti yang diharapkan dan menemukan
masalah harus ditangani secepat mungkin.Sebuah sistem infrastruktur yang
terlalu usang untuk mengikuti perubahan kebutuhan organisasi harus
pensiun atau repurposed ke tugas yang lebih cocok.

Keamanan Verifikasi
Sistem kontrol keamanan perlu diverifikasi secara terpisah dari verifikasi operasional.
Ada beberapa cara bagi suatu organisasi untuk memverifikasi fungsi keamanan
mereka sistem, termasuk uji penetrasi, pengujian kepatuhan, penilaian risiko,
dan ancaman pemodelan.Setiap kombinasi dari tindakan di atas dapat digunakan
berdasarkan atau peraturan persyaratan operasional perusahaan.
Penetrasi Pengujian
pengujian Penetrasi adalah tempat atau eksternal tim internal terdiri dari profesional keamanan
upaya untuk menghindari keamanan sistem kontrol untuk mendapatkan akses tidak sah
untuk sumber daya sistem.Lebih besar konsultasi dan audit TI perusahaan-perusahaan memberikan "test pena"
layanan.Tim harus berusaha untuk meningkatkan kerentanan teknis dalam sistem
software, aplikasi, dan konfigurasi, serta kelemahan dalam keamanan fisik
pengawasan dan prosedur operasional.Sebuah organisasi harus berhati-hati ketika menyewa
uji penetrasi jasa; ada garis tipis antara hacker etis dan tidak begitu
etika hacker.Cara terbaik adalah praktek untuk melakukan pemeriksaan latar belakang pada orang atau
organisasi Anda berniat untuk digunakan untuk menguji penetrasi dalam organisasi Anda.A
definisi yang jelas tentang apa yang masuk dan keluar dari ruang lingkup untuk uji harus dibuat, dan semua
pihak manajemen harus menyadari pengujian dan ruang lingkup sehingga tidak ada
kejutan harus tes menaikkan alarm dengan IT atau pengguna akhir staf.
Pengujian Kepatuhan
pengujian kepatuhan rutin harus dilakukan oleh / keamanan organisasi TI
memastikan bahwa sistem patuh terhadap kebijakan keamanan organisasi, standar,
dan persyaratan.Sedangkan keseluruhan tingkat kepatuhan merupakan indikator seberapa baik
perusahaan melakukan secara keseluruhan, rincian kepatuhan dapat digunakan untuk memverifikasi
efektivitas operasional keamanan kontrol pada sistem individu.Ada
banyak alat komersial kepatuhan yang dapat digunakan untuk melakukan pengujian kepatuhan
Penilaian Resiko
Analisis resiko harus menjadi bagian dari program verifikasi keamanan secara keseluruhan.Eksternal
pihak harus melakukan penilaian untuk memastikan bahwa tidak ada bias dalam penilaian
temuan.Penilaian harus fokus pada identifikasi risiko yang dapat menyebabkan sistem
kompromi atau kegagalan.Risiko dapat teknologi, proses, atau orang-orang berbasis.Sebuah
penilaian juga harus mengidentifikasi cara untuk mengurangi risiko yang diidentifikasi.
Ancaman Modeling
Ancaman pemodelan merupakan bagian integral dari proses verifikasi keamanan.Ancaman pemodelan
adalah proses di mana tim profesional keamanan review aplikasi spesifik
dan mencoba untuk mengidentifikasi titik-titik kemungkinan serangan.Hasilnya adalah daftar serangan
poin yang keamanan TI harus melindungi terhadap.

Dukungan Sistem Dokumentasi
Setelah sistem ini dikerahkan dan operasional sistem dokumentasi harus
dikoreksi dan diperbarui dengan konfigurasi parameter operasional final serta
karena setiap "pelajaran" dari proses instalasi dan konfigurasi.Jenis
dokumentasi yang dihasilkan akan bervariasi berdasarkan pada penggunaan dan organisasi.Akhir
dokumentasi pengguna harus disediakan untuk semua pengguna sistem.End user
dokumentasi dapat menjadi dokumentasi vendor standar untuk konsumen standar
perangkat lunak.Lebih aplikasi disesuaikan mungkin membutuhkan dokumentasi yang dipersonalisasi
untuk konfigurasi digunakan dalam perusahaan.Sistem administrasi
dan pengembangan dokumentasi serta membantu prosedur meja harus disediakan
untuk personil IT yang mendukung dan mengelola perangkat lunak dikerahkan.Ini
dokumentasi harus ditinjau secara berkala, terutama untuk perangkat lunak kustom
(Misalnya, sistem sumber daya manusia, sistem penagihan, dll).Sering perubahan ini
aplikasi akan menjamin pembaruan kepada dokumentasi.Ini harus direncanakan
aktivitas saat upgrade sistem atau perubahan dikerahkan.


Untuk lebih lengkapnya, bisa diunduh di sini:
http://www.4shared.com/file/nxcpXTSu/AuerbachSoftwareDeploymentUpda.html

Kamis, 03 Maret 2011

Langkah Umum Software Deployment

1. Membuat media pengiriman.
    - Merakit dan menguji semua file yang dapat dieksekusi.
    - Merakit dan menguji semua file data.
    - Membuat dan menguji semua dokumentasi user.
    - Menyediakan versi elektronik (misalnya, pdf).
    - Menyediakan hypertext "help" file.
    - Menyediakan panduan mengatasi masalah.
    - Tes media pengiriman dengan sekelompok kecil user.

2. Membentuk dukungan masyarakat atau kelompok.
    - Membuat dokumentasi dan/atau peralatan pendukung komputer.
    - Menetapkan mekanisma komunikasi (misalnya, situs Web, telepon, e-mail).
    - Menetapkan mekanisme logging yang bermasalah.
    - Menetapkan mekanisme laporan yang bermasalah.
    - Menetapkan masalah/error laporan database.

3. Membuat mekanisme feedback user.
    - Mendefinisikan proses feedback.
    - Mendefinisikan form feedback (kertas dan elektronik).
    - Merancang database feedback.
    - Merancang bentuk penilaian feedback.

4. Mengirimkan dan menyebarkan media ke semua user.

5. Menyediakan fungsi pendukung disaat berjalannya deployment.
    - Menyediakan bantuan saat mulai instalasi.
    - Terus memberikan bantuan tips pemecahan masalah.

6. Kumpulkan feedback user.
    - Log feedback.
    - Mengakses feedback.
    - Komunikasi dengan user yang memberikan feedback.

Rabu, 02 Maret 2011

Penjelasan Software Deployment

Pada dasarnya, deployment mencakup tiga proses, yaitu: penyampaian (delivery), bantuan (support), dan timbal balik (feedback). Karena model proses perangkat lunak sekarang ini semakin berevolusi, maka proses deployment pun terjadi tidak hanya sekali, namun beberapa kali di setiap langkah dalam penyelesaian perangkat lunak tersebut. Pada tiap siklus penyampaian memfasilitasi customer dan user terakhir dengan peningkatan operasional perangkat lunak yang menyediakan fungsi dan fitur yang berguna. Tiap siklus yang membantu menyediakan dokumentasi dan bantuan sumber daya manusia untuk setiap fungsi dan fitur yang diperkenalkan selama siklus deployment yang berlaku. Tiap siklus timbal balik menyediakan tim perangkat lunak dengan bimbingan yang penting sehingga menghasilkan modifikasi pada fungsi, fitur dan pendekatan yang diambil untuk peningkatan selanjutnya.
Penyampaian dari peningkatan perangkat lunak menunjukkan momen yang penting untuk setiap proyek perangkat lunak. Berikut adalah beberapa prinsip utama yang harus diikuti sebagai persiapan tim dalam penyampaian sebuah peningkatan.

Prinsip #1 : Ekspektasi customer pada perangkat lunak harus teratur.
Biasanya, customer mengharapkan lebih dari apa yang telah dijanjikan oleh tim pada saat penyampaian, sehingga kekecewaan pun banyak terjadi. Ini menghasilkan timbal balik yang tidak produktif dan merusak semangat juang dari tim tersebut. Dalam buku Naomi Karten pada “managing expectations”, [KAR94] menyampaikan: “The starting point for manaaging expectations is to become more conscientious about what you communicate and how”. Dia menyarankan bahwa software engineer harus berhati-hati pada saat pengiriman pesan pertentangan customer.

Prinsip #2 : Package lengkap yang diberikan harus telah digabungkan dan dites.
CD-ROM atau media lain yan berisi executable software, file data pendukung, dokumen pendukung, dan informasi relevan lainnya harus digabungkan dan telah dilakukan beta-tested dengan user yang sebenarnya. Semua script instalasi dan fitur operasi lainnya harus dicoba di semua konfigurasi computing (seperti, hadware, operating system, peripheral device, networking arrangement).

Prinsip #3 : Sistem Bantuan harus ditetapkan sebelum software diberikan.
Pengguna terakhir mengharapkan tanggapan dan informasi akurat ketika pertanyaan atau masalah muncul. Jika sistem bantuannya ad hoc, atau buruk, tidak ada, maka customer akan tidak puas. Sistem pendukung harus direncanakan, materi pendukung harus dipersiapkan, mekanisme menyimpan catatan yang semestinya harus ditetapkan, sehingga tim software dapat menunjukkan kategori perkiraan dari jenis sistem pendukung yang diminta.

Prinsip #4 : Instruksi material yang tepat harus diberikan kepada user terakhir.
Tim pembuat software memberikan lebih dari software itu sendiri. Pelatihan bantuan yang tepat (jika diperlukan) harus dikembangkan, panduan pemecahan masalah harus diberikan , dan deskripsi “what’s-different-about-this-software-increment ” harus dipublikasikan.

Prinsip #5 : Software yang mempunyai bug harus diperbaiki dahulu,baru dikirimkan kemudian.
Dibawah tekanan waktu, beberapa organisasi software mengirimkan peningkatan berkualitas rendah dengan peringatan untuk customer bahwa bug"akan diperbaiki selanjutnya". Ini adalah sebuah kesalahan. Ada sebuah ungkapan dalam sebuah bisnis software: "Customer akan lupa bahwa anda mengirimkan produk berkualitas tinggi terlambat beberapa hari, tapi mereka tidak pernah lupa masalah-masalah yang disebabkan produk berkualitas rendah pada mereka. Software yang mengingatkan mereka tiap hari."

Software yang terkirim menyediakan beberapa keuntungan untuk user terakhir, tapi juga menyediakan feedback yang berguna untuk team software dengan diletakannya peningkatan diletakkan pada kegunaannya, user terakhir seharusnya terpacu untuk mengomentari fitur-fitur dan fungsi-fungsi, kemudahan penggunaan, kehandalan, dan karakteristik lain yang tidak sesuai. Timbal balik harus dikumpulkan dan direkam oleh team software yang digunakan untuk:

(1) membuat modifikasi sesegera mungkin pada peningkatan yang telah tersampaikan(jika dibutuhkan);
(2) menentukan perubahan yang selanjutnya akan dihubungkan pada peningkatan selanjutnya yang telah direncanakan;
(3) membuat modifikasi desain yang diperlukan untuk mengakomodasi dan mendukung perubahan; dan
(4) meralat rencana(termasuk jadwal pengiriman) untuk peningkatan selanjutnya agar merefleksikan perubahan.