Support Manual Review,, alias SMR..

Support manual review merupakan salah satu jenis review yang masuk dalam tinjauan desain formal. Tujuan dari review ini adalah untuk meninjau support manual(manual bantuan) seperti user guide, user manual, installation manual, dan dokumen yang berkaitan dengan itu agar dihasilkan dokumen yang berkualitas dan bermutu, sesuai dengan rencana SQA yang telah ditetapkan sebelumnya.

Komponen – komponen dari support manual review ini antara lain:

1. Infrastuktur SMR
   1. Mengembangkan daftar periksa untuk setiap jenis dokumen, atau setidaknya untuk umum.
   2. Melatih profesional untuk melakukan suatu hal teknis yang utama sebaik isu proses review. Para profesional terlatih melayani sebagai reservoir untuk tim SMR.
   3. Secara periodik menganalisa efektifitas dari SMR tentang deteksi kerusakan untuk meningkatkan metodologi SMR.
   4. Jadwal SMR sebagai bagian dari rencana kegiatan proyek dan mengalokasikan sumber daya yang diperlukan sebagai bagian integral dari prosedur standar pengembangan perangkat lunak.
   5. Partisipan (Tim) SMR

Tim review harus dibatasi dengan jumlah anggota 3-5 orang agar menjadi optimal.

1. Sesi SMR

• Mendiskusikan isu-isu profesional dengan cara yang konstruktif. Disini dituntut untuk menjaga agar suasana diskusi bebas dari ketegangan yang tidak perlu.
• Mempertahankan agenda review. Terhanyut pada agenda yang direncanakan biasanya mengganggu efisiensi review.
• Fokus pada deteksi kesalahan dengan memverifikasi dan memvalidasi komentar peserta. Menahan diri dari mendiskusikan solusi untuk kesalahan yang terdeteksi sehingga dapat menghemat waktu dan menghindari kemunduran jadwal.
• Dalam kasus ketidaksepakatan tentang pentingnya kesalahan, itu diharapkan untuk mengakhiri perdebatan dengan mencatat masalah ini dan pergeseran diskusi ke forum lain.
• Dokumen diskusi, terutama rincian komentar peserta dari hasil verifikasi dan validasi. Langkah penting ini terutama jika dokumentasi untuk melayani sebagai masukan atau dasar untuk penyusunan laporan review.
• Durasi sesi SMR tidak boleh lebih dari 2 jam.
• Siapkan laporan review, yang merangkum masalah yang dibahas dan item tindakan.
• Menetapkan prosedurtindak lanjut untuk memastikan kinerja yang memuaskan dari semua koreksi termasuk dalam daftar item tindakan.

1. Kegiatan setelah Review

ü  Menyiapkan laporan review yang berisi tentang hal-hal yang dibahas dalam review dan hasil dari pembahasan tersebut

ü  Melakukan kegiatan sebagai tindak lanjut dari review untuk memastikan bahwa perbaikan yang dilakukan (hasil review) memuaskan sehingga dihasilkan support manual yang berkualitas.

 

TRR (Test Readiness Review)

TUJUAN

Review uji kesiapan (TRR) merupakan salah satu proses SQA. Tujuan dari review ini adalah menyediakan manajemen dengan menjamin bahwa perangkat lunak telah menjalani pengujian secara menyeluruh dan siap untuk memasuki tahap pengujian selanjutnya.

Ruang lingkup Review Uji Kesiapan adalah untuk memeriksa produk tes dan hasil tes dari tahap uji coba yang  telah diselesaikan sebagai kelengkapan dan keakuratan, dan untuk memverifikasi bahwa kasus tes, tes skenario, skrip uji, lingkungan, dan data uji telah dipersiapkan untuk uji fase berikutnya. Masing-masing tim uji berkontribusi terhadap sebuah rilis aplikasi, harus mengadakan Review Uji Kesiapan untuk aplikasi tersebut. Semua tim uji berkontribusi terhadap sebuah rilis aplikasi akan mengadakan TRR dengan Organisasi  Enterprise pada saat aplikasi siap untuk integrasi ke dalam DCII.

Ada dua jenis TRR menurut sifat pertemuannya:

• Review Informal

Tidak dilakukan pertemuan secara formal, namun hasil dari pertemuan ini sama seperti pertemuan formal, yakni dokumen yang dihasilkan oleh TRR ini

• Review Formal

TRR formal dilaksanakan setiap adanya release aplikasi baru setelah selesainya  Uji integrasi perangkat lunak dan Uji Validasi Fungsi. Review Kesiapan Implemenasi dilaksanakan oleh Organisasi pengujian enterprise setelah selesainya Pengujian Serahterima enterprice dan Penilaian Operasional.

TINGKATAN TRR

Ada 3 level TRR pada level aplikasi, yakni:

• Development Test Readiness Review

TRR informal yang membahas  keberhasilan dan penyelesaian pengujian unit/ modul dari aplikasi yang dikembangkan

• Project Test Readiness Review

TRR formal yang membahas keberhasilan dan penyelesaian dari SIT (Tes integrasi perangkat lunak) dari aplikasi yang dikembangkan

• Enterprise Test Readiness Review

TRR formal yang membahas keberhasilan dan penyelesain dari FVT (Functional validation test) dari aplikasi yang dikembangkan. Enterprise test readiness review dibagi menjadi 2, yaitu:

• Acceptance Test Readiness Review

TRR formal yang membahas masalah keberhasilan dan penyelesaian Enterprise Integration Test (Pengujian Integrasi Enterprose)  dan Performance test (Pengujian Performansi) dari setiap rilis DCII

• Implementation Readiness Review

TRR formal membahas masalah keberhasilan dan penyelesaian dari Enterprise Acceptance Test (Pengujian Serang terima enterprise) dan yang berkaitas dengannya, jika tidak semua penilaian Operasional pada level enterprise diberikan pada rilis DCII

PARTISIPAN TRR

Berikut adalah partisipan dari TRR:

1. Development Test Readiness Review
   1. DCII Test Director
   2. Technical Project Officer
   3. Application Test Manager
   4. Project SQA Representatives
   5. Project Test Readiness Review
      1. DCII Test Director
      2. Technical Project Officer
      3. Functional Project Officer
      4. Application Test Director
      5. Application Test Manager
      6. Enterprise Test Director
      7. Test Integrator
      8. Certifying Subject Matter Experts
      9. Project SQA Specialists
   6. Enterprise Test Readiness Review and Acceptance Test Readiness Review
      1. Program Manager
      2. DCII Test Director
      3. Technical Project Officer
      4. Functional Project Officer
      5. Application Test Director
      6. Enterprise Test Director
      7. Test Integrator
   7. Implementation Readiness Review
      1. Program Manager
      2. DCII Test Director
      3. Enterprise Test Director
      4. Test Integrator
      5. Certifying Subject Matter Experts
      6. Operational Assessment Test Manager
      7. Project SQA Specialists

1. PERAN DAN TANGGUNGJAWAB PARTISIPAN REVIEW
   1. Koordinator Review

Merupakan perasn kunci dalam keseluruhan proses TRR. Seorang koordinator review harus mempunyai pengetahuan dan pengalaman mengenai TRR ini. Peran dari koordinator review adalah

ü  Bertangungjawab rehadap seluruh persiapan review

ü  Memastikan bahwa semua pe-review telah siap dan familiar dengan produk  yang akan direview. Jika pe-review belum siap maka diadakan penjadwalan ulang.

ü  Mengingatkan semua partisipan TRR mengenai tanggal , tempat dan lokasi review.

ü  Memulai pertemuan tepat waktu

ü  Menjaga agar pe-review tetap fokus terhadap produk yang di review.

ü  Berperan sebagai pe-review dan berpartisipasi dalam proses review

ü  Memastikan bahwa semua checklist, catatan review dan kesimpulan dari review telah selesai dikerjakan. Kemudian koordinator review berama dengan grup SQA melakukan follow up/ tindak lanjut dari review.

1. Presenter

Tugas utama dari presenter antara lain:

ü  Memberikan gambaran umum dari priduk yang di review

ü  Menjadi presenter saat review ketika ada klarifikasi

ü  Melakukan koreksi terhadap hasil pengujian sesuai kebeutuhan setelah dilakukan review

1. Panitera (Meeting Recorder)

Panitera mencatat semua kegiatan yang terjadi selama review, termasuk mencatat semua checklist. Panitera juga memberikan kesimpulan terhadap hasil review serta membuat laporan review.

1. Spesialis SQA

Spesialis SQA akan mereview pengujian produk dan aktifitas review untuk memastikan kecocokan dengan rencana SQA yang telah ditetapkan dan mengindentifikasi standar produk.

1. Petugas Review (Reviewer)

Melakukan review, meliputi semua pengujian dan beberapa tahapan, sertifikasi, hasil pengujian, dan laporan pengujian. Semua peviewer harus telibat dalam diskusi kelompok. Tujuan dari review adalah untuk me review hasil pengujian dan menyakinkan bahwa perangkat lunak siap untuk digunakan.

1. KRITERIA TRR

Beberapa proses  berikut menjelaskan kriteria sebelum revieew dilaksanakan

1. Development TRR
   1. Pegawai teknis proyek akan menjadi korrdinator dari tahapan ini. Manager penguji Aplikasi diberi tugas sebagai presenter review. Pegawai teknis proyek yang lain akan menjadi panitera dan menyiapkan checklist review dan catatan kegiatan yang kemudian didistribusikan ke seluruh perserta review.
   2. Presenter review, memastikan bahwa hal berikut telah siap:

ü  Menyelesaikan checklit pengujian modul, kasus mengujian modul, dan data laporan pengujian modul harus ditempatkan pada kontrol managemen.

ü  Laporan pengujian modul harus sudah didistribusikan pada selueuh partisipan

ü  Kasus pengujian, skenerio pengujian dan skrip pengujian telah didokumentasikan untuk Pengujian Integrasi perangkat lunak aplikasi dan siap digunakan

ü  Data pengujian telah disiapkan untuk Pengujian integrasi perangkat lunak

ü  Menyiapkan lingkungan pengujian

1. Project TRR
   1. Pegawai teknis proyek akan menjadi korrdinator dari tahapan ini. Manager penguji Aplikasi diberi tugas sebagai presenter review. Pegawai teknis proyek yang lain akan menjadi panitera dan menyiapkan checklist review dan catatan kegiatan yang kemudian didistribusikan ke seluruh perserta review.
   2. Presenter review, memastikan bahwa hal berikut telah siap:

ü  Software Test Plan, Software Integration Test cases, test scenarios, test scripts, automated test scripts, dan data pengujian telah ditempatkan pada kontrol konfigurasi managemen.

ü  Laporan Software Integration Test telah disiapkan dan didistribusikan pada seluruh partisipan

ü  Sesi yang bersesuaian dengan spesifikasi DCII telah divalidasi dan di sertifikasi oleh Technical Project Officer.

ü  Test Discrepancy Reports (TDRs) dari Software Integration Test telah ditutup.

1. Application Test Director atau Functional Project Officer memastikan bahwa hal-hal berikut ini telah siap/ selesai:

ü  Aplikasi Functional Validation Test (FVT) telah siap digunakan

ü  Data pengujian telah disipakan untuk aplikasi Functional Validation Test (FVT).

ü  Lingkungan pengujian telah disiapkan

ü  Matrik kebutuhan telah disesuaikan dengan memasukkan identifikasi kebutuhan, deskripsi kebutuhan, kasus pengujian yang berhubungan, skrip pengujian, file data pengujian, dan di sinkronkan dengan identifikasi FFMR untuk FVT

ü  Technical Action Manager dan akun pengawai telah dibuat untuk level pengujian dan even pengujian untuk FVT tanpa CMIS

1. Enterprise TRR
   1. Functional Project Officer akan menjadi koordinator review untuk Project TRR. Application Test Director atau application Functional Project Office diberi tanggungjawab sebagai presenter review. Functional Project Officer menjadi panitera dan menyiapkan checklist review dan catatan kegiatan yang kemudian didistribusikan ke seluruh perserta review.
   2. Presenter review, memastikan bahwa hal berikut telah siap:

ü  Software Test Plan, Software Integration Test cases, test scenarios, test scripts, automated test scripts, dan data pengujian telah ditempatkan pada kontrol konfigurasi managemen.

ü  Laporan Software Integration Test telah disiapkan dan didistribusikan pada seluruh partisipan

ü  Sesi yang bersesuaian dengan spesifikasi DCII telah divalidasi dan di sertifikasi oleh Technical Project Officer.

ü  Test Discrepancy Reports (TDRs) dari Software Integration Test telah ditutup.

ü  Parstisipan pengujian/ subyek fungsional direkomendasikan menjadi manager program

ü  Data yang bersesuaian telah dikumpulkan dan disimpan dalam FFMR

ü  Sertifikasi tahun 2000 telah selesai dan diterima oleh  manager program

1. Enterprise Test Director memastikan bahwa beberapa hal berikut telah siap:

ü  Kasus pengujian, skenario pengujian, skrip pengujian telah didokumentasikan dan siap digunakan untuk pengujian intergrasi dan perfornansi enterprise

ü  Kasus pengujian, skenario pengujian, skrip pengujian telah didokumentasikan dan siap digunakan untuk penilaian operasional

ü  Test Integrator telah mereview hasil pengujian dan mensertifikasi kesesuainnya dengan kebutuhan dan standar

ü  Data pengujian telah disiapkan untuk pengujian enterprise.

ü  Lingkungan pengujian telah disiapkan

ü  Matrik kebutuhan telah disesuaikan dengan memasukkan identifikasi kebutuhan, deskripsi kebutuhan, kasus pengujian yang berhubungan, skrip pengujian, file data pengujian, dan di sinkronkan dengan identifikasi FFMR untuk FVT

ü  Technical Action Manager dan akun pengawai telah dibuat untuk level pengujian dan even pengujian untuk FVT tanpa CMIS

1. Acceptance TRR
   1. Enterprise Test Director akan menjadi koordinator review untuk Project TRR. Enterprise Test Director atau ketua penguji Enterprise Test Director diberi tanggungjawab sebagai presenter review. Functional Project Officer menjadi panitera dan menyiapkan checklist review dan catatan kegiatan yang kemudian didistribusikan ke seluruh perserta review.
   2. Presenter review, memastikan bahwa hal berikut telah siap:

ü  Sesi yang bersesuain dnegan spesifikasi DCII telah divalidasi dan disertifikasi oleh Direktur penguji Enterprise

ü  Test Discrepancy Reports (TDRs) dari Enterprise Integration Test dan Performance Test telah direview pegawai fungsional dan teknis proyek

ü  Data yang bersesuaian telah dikumpulkan dan disimpan pada FFMR

ü  Sertifikasi telah selesai dan diterima

ü  Kasus pengujian, skenario pengujian, skrip pengujian telah didokumentasikan dan siap digunakan untuk Enterprise Acceptance Test

ü  Kasus pengujian, skenario pengujian, skrip pengujian telah didokumentasikan dan siap digunakan untuk penilaian operasional dengan pengguna akhir.

1. Review Planning and Preparation

Koordinator review bertanggungjawab untuk menjadwalkan review, menyiapkan review pengujian produk, dan berperan sebagai moderator pada review. Koordinator review akan melakukan hal berikut:

1)      Mengkoordinasikan fasilitas review.

2)      Membuat agenda

3)      Mengingatkan semua partisipan:

ü  Menginformasikan kepada partisipan mengenai waktu, tempat dan lokasi review

ü  Mengingatkan presenter mengenai materi yang spesifik untuk di presentasikan dan waktunya

ü  Memberikan tugas kepada panitera atau partisipan review yang lain apabila ada tugas khusus

4)      Menyiapkan checklist

5)      Membuat paket review meliputi

ü  Agenda

ü  Checklist review

ü  Laporan pengujian

6)      Mendistribusikan paket review ke seluruh partisipan

Semua partisipan bertanggungjawab untuk melakukan penilaian/ koreksi terhadap paket review dan mendiskusikannya sesuai dengan bagian masing-masing.

1. Review Excecution

Koordinator review menverifikasi bahwa semua partisipan telah hadir dan siap untuk melakukan review.

1)      Koordinator review memperkenalkan tujuan dan ruang lingkup review

2)      Presenter review mencatat hal- hal yang berada di luar rencana kemudian menyiaplan rencana untuk menyelesaikannya

3)      Presenter review memperkenalkan hasil pengujian yang tertulis dalam laporan pengujian

4)      Presenter review menyediakan dokumen form sertifikasi dan mencatat hasil dari proses pengujian sertifikasi

5)      Presenter review menyediakan ekstraksi matrik kebutuhan

6)      Pe-review mencatat hal kebutuhan yang kurang

7)      Presenter review memberikan rekomendasi untuk pengembangan komponen perangkat pada tahapan berikutnya

8)      Presenter pengganti memberikan kesimpulan dari pengujian kesiapan pada tahap berikutnya

9)      Presenter pengganti memperkenalkan rencana pengujian perangkat lunak

10)   Koordinator review menyelesaikan ceklist review

11)   Panitera mencatat semua kegiatan yang dilakukan dalam catatan kegiatan

12)   Koordinator review menyimpulkan kegiatan review dan menutup review

13)   Koordinator review menyiapkan dan menyediakan catatan review dan mendistribusikan laporan kesimpulan review kepada semua partisipan

1. Exit Criteria

Berikut ini adalah hasil dari review

1. Completed Review Checklist
2. Review Summary Report
3. Review Action Item Notice
4. SQA Reports
5. Review Follow up

Selama tahap follow-up koordinator review dan spesialis SQA memastikan bahwa semua definisi telah diselesaikan dengan menggunakan catatan kegiatan untuk memastikannya

 

Vampire Academy:Blood Promise..

Blood Promise,,

Buku keempat dari serial vampire academy. sumber dari wikipedia. monggo dinikmati resensinya.. ^^

Dalam Blood Promise, Rose meninggalkan St Vladimir’s Academy untuk mencari Dimitri, yang telah menjadi Strigoi. Satu-satunya petunjuk yang dimilikinya adalah Dimitri ada di suatu tempat di Siberia. Setelah pertemuannya dengan seorang alkemis bernama Sydney, mereka melakukan perjalanan ke Siberia, sampai akhirnya ia menemukan keluarga Dimitri di kota kecil Baia. Sementara berada di Baia, ia juga bertemu dengan  pasangan terikat “Shadow-Kissed” yang lain yaitu Oksana dan Mark, dan seorang pria Moroi misterius bernama Abe, yang mencoba untuk memaksanya kembali ke St Vladimir’s. Dia terus memaksa Rose kembali, dan Rose setuju setelah ia pergi keluar dengan Viktoria, adik Dimitri. Dia kemudian pergi menuju Novosibirsk dengan pengawal lain yang  tidak diperjanjikan  untuk mengintai Strigoi dengan harapan menemukan Dimitri. Ketika Rose bertemu Dimitri, dia terlalu terpana oleh penampilan Strigoi Dimitri yang  mencoba untuk membunuhnya, dan berakhir dengan disandera olehnya. Dimitri menolak untuk membunuh Rose, dan sebaliknya, ia mengatakan akan terus menjaganya sampai Rose memutuskan untuk menjadi Strigoi untuk bisa bersamanya.

Sementara itu, Rose terus memeriksa keadaan Lissa di St Vladimir melalui ikatannya. Avery, pengguna Roh rahasia, telah menggunakan kompulsi untuk mengendalikan Lissa. Selama kunjungan ke kepala  Lissa, Rose seakan didorong oleh Avery. Sementara disandera oleh Dimitri, yang telah memberinya makanan dan akhirnya melemahkannya, Rose akhirnya berhasil melarikan diri dan sempat meraih pasak saat meloloskan diri. Dimitri menangkapnya kembali dan mereka akhirnya bertarung di jembatan. Rose berhasil menusukkan pasaknya ke dada Dimitri.

Kelelahan, Rose berakhir di tempat seorang teman Sydney si alkemis, di mana Oksana, Markus, dan Abe telah menunggunya. Ketika dia terbangun, dia menyadari Lissa dalam bahaya. Avery  ingin membunuh Lissa dan kemudian membangkitkannya kembali sehingga Lissa akan menjadi “shadow-kissed” dan terikat pada Avery. Dengan bantuan dari Oksana, Rose berhasil membimbing Lissa, dan Adrian melalui ikatannya bertarung  melawan Avery dan adiknya, Reed, dan pengawal Avery, Simon. Setelah menyelamatkan Lissa, Rose bertanya pada Oksana dan Mark apakah ada jalan agar Strigoi dapat kembali ke diri mereka sebelumnya. Dengan enggan, mereka bercerita tentang pengguna Roh yang mereka tahu bernama Robert Doru, yang mengklaim telah memulihkan Strigoi kembali ke dirinya semula. Namun, hanya Victor Dashkov, saudara-setengahnya, yang  tahu keberadaannya. Menyadari situasinya tidak ada harapan lagi dengan fakta bahwa dia sudah menusuk Dimitri, Rose kembali ke St Vladimir’s Academy.

Kembali ke St Vladimir’s Rose reuni dengan Lissa dan menceritakan apa yang terjadi padanya selama di Rusia. ibu Rose, Janine, yang juga di sana, mengungkapkan kepada Rose bahwa Abe sebenarnya adalah  ayahnya. Setelah setuju untuk kembali ke sekolah untuk kelulusan, Rose kembali ke kehidupan normalnya di St Vladmir’s. Namun, segera dia menerima paket dari Rusia yang melampirkan pasak yang digunakannya untuk menusuk Dimitri, dan sebuah catatan darinya yang mengatakan bahwa ia tidak benar-benar menusuk dengan benar, dan masih hidup, serta menunggu Rose menyelesaikan sekolahnya untuk menemukannya. Rose menyadari bahwa dengan Dimitri yang masih Strigoi, ia mempunyai kesempatan untuk memulihkannya ke kehidupan sebelumnya, tetapi hanya dengan menemukan Robert Doru.