GAMBARAN UMUM PROSES PENGEMBANGAN SISTEM INFORMASI DAN PIRANTI LUNAK

GAMBARAN UMUM PROSES PENGEMBANGAN SISTEM INFORMASI DAN PIRANTI LUNAK

oleh: Tumar


Maksud dari bab ini adalah untuk meletakan dasar yang efektif pada manajemen proyek pengembangan sistem informasi daan piranti lunak asal saja prosesnya ditinjau. Suatu proses dimulai dengan persyaratan sistem analis yang mana selama persyaratan sistem dialokasikan untuk piranti keras, karya yang kokoh, dan sub system piranti lunak. Proses pengembangan diakhiri bilamana sub systemnya diuji coba, didemontrasikan yang sesuai dengan persyaratan sistem, dan siap diinstal-kan untuk dioperasikan. Instalasi dan aktivitas pengoperasiannya mengikuti uji coba piranti keras, dan piranti lunak serta sub rangkaian terintegrasi untuk format subsegmen, segmen, dan akhirnya sistem komplit. Rapi, tertib dan pendekatan pengembangan sistem informasi dan piranti lunaknya yang terstruktur berikutnya tercapai.


Kegunaannya adalah untuk meletakan dasar pengelolaan Proyek Pengembangan Sistem Informasi dan Piranti Lunak (PL).

• Proses pengembangan berasal dari kegiatan analisa apa yang diperlukan suatu sistem, agar sistem bisa berjalan dan menghasilkan sesuatu yang memang diharapkan manfaatnya bagi pemakai. (disebut : Analisa Kebutuhan Sistem ).
• Selama dalam analisa ini perlu dialokasikan hardware, firmware dan sub sistem software (yang harus diwujudkan / dikembangkan / dimutakhirkan).
• Proses pengembangan ini diakhiri bilamana subsistem telah diuji, disajikan sesuai dengan kebutuhan sistem dan dipasang / dipakai untuk dijalankan. Kegiatan pemakaian dan pengoperasian dilakukan sesudah pengujian hardware dan software dan berikut pemaduan untuk membentuk suatu sub segmen, segmen dan akhirnya pengujian sistem secara lengkap.
• Pendekatan Pengembangan Software yang teratur dan tersusun baik akan diperoleh hal-hal seperti tersebut di bawah ini antara lain :

1. Meningkatkan kemungkinan keberhasilan.
2. Membutuhkan keyakinan bagi pemakai bila diberi suatu pendekatan terencana untuk mengelola software.
3. Memberi wawasan yang lebih mendalam bagi pemakai / user dan pimpinan bila diberikan dokumentasi pengembangan yang baku beserta tahap-tahapannya.
4. Mampu menetapkan tanggung jawab jawab organisasi.
5. Meningkatkan ketepatan rancangan software dan perkiraan biaya pengembangan
6. Mengurangi biaya pengembangan software.
7. Meningkatkan kualitas proyek.
8. Memberikan pengetahuan bagi personil pendukung yang bukan perekayasa software tentang proses pengembangan software.

Menyediakan sumber data untuk penyiapan usulan yang akan datang dan sumber data untuk perencanaan proyek.

2.1. Apa itu Subsistem Piranti Lunak (Software) ?
Software adalah bagian suatu sistem. Software itu bisa terdiri dari satu atau lebih subsistem software. Posisi atau tingkat sub sistem software dalam suatu hirarkhi sistem dapat dilihat pada gambar 2.1.

Gambar 2.1, Jenjang Sistem

Pengertian Sub Sistem
Suatu sub sistem adalah berupa kumpulan-kumpulan program-program komputer dirancang untuk menyelesaikan tugas pengelolaan utama. Suatu sub sistem software berupa suatu organisasi elemen-elemen tingkat rendah (program komputer).Program komputer adalah elemen akhir dari kontrak dan sering disebut elemen tatanan program komputer (CPCI), ini diperlihatkan dalam gambar 2.2





Dalam suatu program komputer yang rumit, modul yang merupakan kelompok fungsi dalam program komputer, yakni routine atau subroutine.

2.2 Konsep Pengembangan
Pengembangan software berlangsung meluli tiga tahap :
1. Rancangan Pendahuluan,
2. Rancangan Rinci,
3. Implementasi (mencoba memakai) dan pengoperasian.

Masing-masing tahap terdiri dari serangkaian langkah-langkah yang berbeda-beda seperti diperlihatkan dalam gambar 2.3. Pengalaman menunjukan bahwa sangat sulit bagi pengelolaan proyek untuk menentukan status kegiatan-kegiatan pengembangan. Sering juga terjadi lima atau enam langkah-langkah pengembangan selesai 75% waktu serta anggaran telah dipakai, namun pembuktian kualiatas belum bisa diperlihatkan.
Untuk memberikan gambaran kepada pengelola proyek secara dini tentang pengembangan software, maka cara pengembangan software pada gambar 2.3 menggunakan konsep pengendalian dasar.
Pertama-tama, selama dalam tahap rancangan pendahuluan tugas-tugas analisa persyaratan dilakukan untuk menetapkan apa itu persyaratan dasarnya. Ini dilakukan, mengingat dasar tersebut dipakai untuk menilai dan mengesahkan produk-produk rancangan. Persyaratan-persyaratan sistem tersebut kemudian dianalisa dan diwujudkan kedalam fungsi software seperti misalnya modul-modul dan program komputer. Persyaratan dasar yang dimaksud disini adalah kemampuan software (sistem) atau fungsi software yang akan dibuat. Persyaratan dasar ini dihasilkan pada rancangan pendahuluan yang berarti juga dihasilkan dalam tahap pertama, yang mencerminkan semua persyaratan dan memberikan dasar untuk tahap Rancangan Rinci.
Lebih lanjut kerja analisa dan rancangan pada dasar rancangan pendahuluan yang disetujui, menghasilkan rancangan rinci, yang menjadi dasar tahap implementasi dan operasi. Selama tahap akhir ini kegiatan peng-kode-an (penerjemaahan kedalam bahasa pemrograman) dan pengujian akan terjadi. Kegiatan-kegiatan ini akan dikendalikan melalui dasar pengembangan dan dasar pengujian terhadap peng-kode-an phisik, dokumentasi programer, data uji dan prosedur uji.
Setelah software dipakai dalam lingkungan operasional (lapangan) maka kegiatan kegiatan operasional dan pemeliharaan dikendalikan melalui dasar/versi, yang terdiri dari release (pelemparan ke pemakaian) khusus, dokumen resmi, dan prosedur uji dan hasil-hasil uji.
Masing-masing dasar didokumentasikan dan secara resmi diperiksa ulang oleh personil pengembang, personil proyek lainnya, pakar perusahaan dan pada umumnya oleh pelanggan dan personil calon pemakai. Dolumen-dokumen ini dan pemeriksaan kembali tersebut bisa menghasilkan skala waktu kegiatan yang bisa diukur dan skala waktu kegiatan yang didasarkan pada penilaian yang saksama. Selama dalam keseluruhan proses pengembangan software.
Konsep pengembangan software menggabungkan unsur pengelolaan tatanan termasuk mengenali tatanan pengendalian perubahan tatanan, laporan status tatanan. Konsep pengembangan software juga memerlukan standar dan kecepatan proyek pembuatan program khusus serta pertimbangan pemakaian alat pengembangan yang di auotomatisasikan, pengujian serta pengelolaan tatanan.
Masing-masing proyek memerlukan pengembangan program komputer untuk dilempar ke pasaran sebaiknya mengetahui Rencana Proyek Pengembangan Software untuk dipakai dalam organisasi sendiri maupun untuk keperluan pemeriksaan dan persetujuan pelanggan. Rencana ini setidaknya harus menetapkan antara lain:
1. Ikhtisar proyek yang ringkas,
2. Daftar skala waktu (milestone) kegiatan, yang satu sama lain terpisah.
3. Susunan Rincian Pekerjaan
4. Jaringan kegiatan
5. Jadual dan anggaran rinci
6. Difinisi interface dan rencana pengembangan
7. Rencana dokumentasi
8. Rencana pengelolaan jadual dan baiaya
9. Rencana pengelolaan tatanan
10. Rencana audit dan pemeriksaan ulangMengidentifikasi personl kunci dan tanggung jawabnya.

Butir-butir tersebut di atas memasukan juga ikhtisar-ikhtisar singkat dan pedoman-pedoman ke arah bagian suatu standard piranti lunak / software perusahaan untuk materi tambahan. Informasi khusus yang berkaitan dengan organisasi proyek, pengertian sistem dan juga pelanggan-pelanggan yang unik atau kebutuhan sistem sebaiknya secara tegas dimasukan kedalam rencana proyek pengembangan piranti lunak/software. Selain itu hal-hal yang merupakan perkecualian dari standar sebaiknya diperhatikan dan terimalah semua butir-butir yang pendekatannya lain dari standar perusahaan yang ditetapkan.

2.3 Konsep Implementasi

Konsep pengembangan software yang dicontohkan dalam gambar 2.3 membagi-bagi proses pengembangan menjadi tiga tahap. Implementasi konsep ini melibatkan suatu review lebih lanjut kedalam tugas-tugas dengan produk-produk yang dirumuskan dengan baik serta pemeriksaan ulang yang lebih baik. Gambar 2.4 menghubungkan produk-produk (dokumen-dokumen) dan pemeriksaan ulang pada tugas yang sama sesuai dengan gambar 2.3.

2.3.1 Dokumentasi

Proyek pengembangan software harus menghasilkan dan memeliharan sedikitnya paling tidak seperangkat dokumen software agar dapat memenuhi persyaratan-persyaratan kontrak serta langkah-langkah pengembangan software. Dokumen-dokumen ini merupakan rancangan dan alat perencanaan perlu untuk pengembangan software yang berhasil dan disiplin. Maksud berikut harus ditekankan dalam dokumentasi piranti lunak/software yang resmi:

Dokumentasi software:
1. Persyaratan-persyaratan piranti lunak/software
2. Rancangan Software
3. Rencana-rencana untuk Pengujian & Penerimaan Piranti lunak/Software
4. Rencana-rencana untuk meyakinkan kualitas & Pengelolaan tatanan Piranti lunak Software
5. Penjelasan pemakaian software untuk mengoperasikan.

Dokumen dan format dokumen harus memenuhi kontrak atau/dan memenuhi kebijaksanaan pengembangan software perusahaan yang bisa dipakai, tentunya isi dokumen tersebut sebaiknya cocok dengan pelanggan, pemakai, dan kebutuhan proyek (misal : mungkin saja memorandum dua halaman antar kantor bisa memenuhi persyaratan dokumen-dokumen tertentu). Dokumen-dokumen sebaiknya ditata dan dibundel kedalam volume yang sesuai dengan persyaratan kontrak dan pelanggan, serta kebutuhan proyek. Dokumentasi software yang resmi menjadikan pimpinan proyek, pucuk pimpinan dan pelanggan mendapat pengertian/wawasan status pengembangan tersebut.Jadi penting sekali menyiapkan dokumen-dokumen tersebut tepat pada waktunya. Dokumentasi dengan pemeriksaan ulang yang hati-hati dapat menghemat waktu, upaya dan biaya selama dalam pengujian dan pengabsahan dengan menemu kenali persyaratan dan masalah-masalah rancangan sebelum dilakukan coding.

1. Spesifikasi (Rincian) Persyaratan Piranti lunak/Software

• Memberikan definisi (pengertian) jelas tentang Kerja Piranti lunak/ Software yang harus dilakukan.
• Menjadikan pimpinan proyek dan pelanggan untuk mengerti apa yang dikerjakan piranti lunak/software dan menyetujui atas cara-cara untuk mengerjakan itu.
• Memberikan pilihan kepada pelanggan untuk menerima atau tidak menerima atau tidak menerima produk akhir dengan cara melaksanakan program uji penerimaan.
• Memberikan kepada tim penguji dengan persyaratan-persyaratan yang harus diperlukan.
• Harus disetujui secara tertulis oleh calon pemakai. Idealnya sekali setuju, persyaratan tersebut tidak boleh berubah. Apabila perubahan persyaratan dipandang perlu, dampaknya harus dievaluasi dan tentunya kontrak berubah.

2. Dokumen-dokumen Rancangan fungsi Software dan dokumen-dokumen Rancangan Rinci

• Memberikan keyakinan pimpinan proyek dan pelanggan bahwa produk akhir piranti lunak/software telah dirancang secara sistematik sesuai ketentuan.
• Pimpinan bisa mampu membandingkan kode yang dituliskan dengan rancangan dan bisa mengikuti kemajuan proyek.
• Apakah disetujui oleh pimpinan proyek dan disetujui atas dasar pemeriksaan ulang.
• Apakah dimutakhirkan setelah pengujian untuk mencerminkan tatanan produk piranti lunak/software yang dibentuk. Dokumen yang dimutakhirkan memberikan dasar penyerahan kepada pemesan / pelemparan ke pasaran dan sebagai akibat perlu ada pemeliharaan piranti lunak/software.

3. Dokumen Pengendalian Antarmuka (Interface)

• Memberikan alat untuk membentuk dan mengendalikan persyaratan interface serta mengendalikan Rancangan bagi pimpinan proyek, pelanggan serta organisasi pengembang lain.
• Membentuk pertanggungan jawab antar organisasi (kontraktor/ konsultan) atas persyaratan-persyaratan dan rancangan-rancangan antarmuka (interface) khusus.

4. Rencana-rencana pengujian Software Piranti Lunak/Software, Prosedur dan Laporan

• Meyakinkan kepada pimpinan proyek dan pelanggan bahwa piranti lunak /software yang sedang diuji meliputi semua tingkat (level).
• Menjadikan pimpinan-pimpinan perancang bisa memastikan bahwa perancang tersebut mengerti persyaratan-persyaratan pengujian.
• Memberikan dasar perancangan unsur piranti lunak/software tingkat paling rendah dan pemeriksaan ulang pengujian. Prosedur dan Rencana Pengujian Piranti lunak/Software tingkat rendah biasanya tidak diserahkan pada calon pengguna piranti lunak/software, prosedur dan rencana tersebut memerlukan persetujuan pimpinan paket kerja dan dimutakhirkan sesuai kebutuhan.
• Memungkinkan memberikan suatu definisi untuk pemaduan module, verifikasi dan pengujian-pengujian yang bisa diterima.

5. Panduan Operasi

• Meyakinkan pada pimpinan proyek dan pelanggan bahwa pemakai piranti lunak/software akan memiliki panduan, panduan-panduan peng-operasian sistem piranti lunak/software yang akan diserahkan kepada pemesan.
• Memenuhi janji pada pelanggan untuk merancang antarmuka (interface) manusia/mesin dengan cara menyerahkan versi yang paling baru untuk diperiksa ulang terhadap rancangan rinci piranti lunak/software.

6. Dokumen Penjelasan Versi

• Memberikan keterangan pengantar untuk masing-masing versi piranti lunak/software yang diserahkan.
• Memberikan data-data yang berhubungan dengan status dan pemakaian piranti lunak/software yang diserahkan.

2.3.1 Tinjauan Ulang (Review)
Pemeriksaan ulang berbagai kejadian dan langkah-langkah dalam tahap-tahap pembangunan piranti lunak/software penting sekali bagi pandangan manajemen dan keberhasilan pengembangan produk. Disini diperlukan pemeriksaan ulang secara resmi maupun tidak resmi. Masing-masing pemeriksaan ulang tersebut memiliki kegunaan sendiri-sendiri.
Ada pemeriksaan ulang dilakukan untuk memperoleh persetujuan tertulis dari pelanggan, lainnya menyediakan antamuka (interface) bagi upaya-upaya pengembangan dan rancangan yang lainnya lagi, dan masih lainnya lagi melengkapi perancang dengan pengalaman pengawasan atau mereka menjadi mampu memeriksa ulang rancangan bersama dengan personil piranti lunak/software lain.
Pemeriksaan-pemeriksaan ulang meliputi produk pengembangan piranti lunak/ software utama yang harus direncanakan dan dilaksanakan yakni :

1. Persyaratan yang harus dipenuhi piranti lunak/software Pemeriksaan ulang persyaratan piranti lunak/software kegiatan ini dilakukan setelah pemeriksaan ulang persyaratan level sistem untuk sistem-sistem dimana piranti lunak/software merupakan sistem yang besar.
2. Pendekatan Desain Software dan Antarmuka (Software Design Aproach and Interfase). Pemeriksaan ulang konsep desain piranti lunak/software dan rancangan pendahuluan paling banyak untuk keperluan pemerintahan atau militer yang mensponsori pengembangannya pada pertemuan rancangan pendahuluan datang dengan beberapa pelanggan mengunjungi pemeriksaan ulang rancangan awal.
3. Rancangan Rinci Piranti Lunak (Software Detail Design). Persyaratan yang harus dipenuhi pada rancangan rinci piranti lunak pada kegiatan ini dilakukan setelah persyaratan pemeriksaan ulang rancangan yang kritis atau beberapa beberapa pelanggan yang akan menggunakan hasil pemeriksaan ulang rancangan rinci pada tingkat unit program boleh dilakukan pada pemeriksaan internal rancangan rinci. Pemeriksaan ulang sebagaian besar dilaksanakan untuk proyek yang besar bilamana pada tingkatan rinci tidak dapat diperiksa ulang pada pemeriksaan ulang rancangan yang kritis.
4. Rencana dan prosedur uji piranti lunak, rencana uji yang harus dipenuhi pada pemeriksaan rancangan awal dan pemeriksaan ulang rancangan yang kritis, sebagai gambaran dalam deskripsinya di bawah pemeriksaan ulang. Prosedur uji adalah pemeriksaan ulang prosedur uji.
5. Produk akhir piranti lunak, pemeriksaan ulang produk piranti lunak adalah cara mengidentifikasi sebagai Penerimaan Tinjauan Ulang Piranti Lunak (the Software Acceptance Review (SAR)
   Gambar 2.5 dan 2.6 ini adalah ringkasan dokumen pemeriksaan ulang. Pemeriksaan ulang adalah formal yang utama pada kejadian penting itu telah diberikan oleh managemen perusahaan dan personil pelanggan fleksibel termasuk didalamnya teknisi dan status administrasi proyek. Mereka memberikan pemeriksaan ulang dalam laporan pada pengembangan produk piranti lunak utama. Pada ringkasan paragrap berikutnya persyaratan untuk setiap pemeriksaan ulang dari sudut pandang manajer proyek. Perincian dekripsi untuk setiap pemeriksaan ulang dan kumpulan dokumen adalah diberikan dalam bab 5-8.

Persyaratan Tinjauan Ulang Piranti Lunak.
Setelah persiapan spesifik persyaratan piranti lunak dan tinjauan ulang rancangan awal lebih dulu, persyaratan pemeriksaan ulang piranti lunak adalah adalah kelakuan untuk maksud formal tercapai yang bersamaan dengan pelanggan dalam ketentuan persyaratan piranti lunak spesifik. Persyaratan spesifik dalam dokumen ini adalah sebagai dasar penerimaan produk akhir piranti lunak. Dalam persiapan untuk pemeriksaan ulang personil proyek harus :

1. menganalisis dan mengevaluasi persyaratan piranti lunak,
2. produk piranti lunak spesifikasinya konsisten dengan teknik berdasarkan perjanjian terbatas pada proyek.

Pengembangan suatu respon untuk setiap problem yang teridentifikasi pada pelanggan spesifik, berkomentar pada pemeriksaan ulang yang mana persyaratan sebelumnya untuk persyaratan pemeriksaan ulang piranti lunak. Persyaratan pemeriksaan ulang piranti lunak kedua-duanya harus termasuk didalamnya persyaratan proyek berhasil dan pelanggan berhasil serta respon untuk seluruh spesifikasi pemeriksaan ulang yang dikomentari.

Tinjauan Ulang Rancangan Pendahuluan (Software Requirement Review/ SRR)
Setelah persyaratan spesifikasi piranti lunak disetujui, personil proyek harus melakukan rancangan dan rencana aktivitas untuk menentukan suatu dasar rancangan awal piranti lunak dan dokumen dasar itu dalam fungsi (atau awal) rancangan spesifikasi. Implementasi dan kebutuhan rencana uji untuk proses dengan rancangan rinci dan pengembangannya juga disediakan/disiapkan. Rancangan awal, kelompok perencanaan dan sedikit teknisi dan atau keterbatasan pemeriksaan ulang sebagai isu pada pemeriksaan ulang rancangan awal. Maksud ini adalah untuk menaksir kecukupan identifikasi isu perubahan rancangan dan rencana-rencana dan memperoleh komitmen bersama untuk proses selanjutnya tahap rancangan rinci. Pemeriksaan ulang rancangan awal memungkinkan pelanggan untuk membuktikan seluruh persyaratan itu adalah alamat dan pengesahan proyek untuk diproses dengan rancangan rinci.
Pada pemeriksaan ulang rancangan awal rencana peng-ujian piranti lunak adalah pemeriksaan ulang untuk tercapainya maksud yang tertulis dalam perjanjian dengan pelanggan. Penyelesaian uji program, suatu ketegasan dalam rencana uji, yang hasilnya pelanggan menerima produk piranti lunak. Seringkali subset secara resmi ke pengujian akan teridentifikasi seperti yang diperlihatkan atau penerimaan pengujian dalam gaya /caranya membuat yang hasil perencanaan piranti lunak akan diterima pelanggan. Waktu disetujui subset ini pada kasus uji, penerimaan mengunjungi rencana uji, akan memodifikasi perubahan dalam perusahaannya untuk disetujui secara tertulis oleh kedua belah pihak antara manajer proyek dan pelanggan.
Jika seperangkat pengujian adalah identifikasi untuk penerima, pemeriksaan ulang itu akan dijamin oleh rencana uji.

1. Bagaimana membuat uji coba diterima berkenaan untuk satu lagi uji coba proyek.
2. Kriteria yang diduga dibatasi oleh kesiapan sistem piranti lunak akan siap untuk menerima uji coba.
3. Identifikasi penerimaan persyaratan uji coba untuk piranti lunak dan tingkat atas yang menerima kriteria.
4. Berkenaan basis data untuk diterima pengujiannya dan rencana mendapatkan nilai data, validasi dan mendapatkan persetujuan pelanggan sebelumnya pada penerimaan pengujian awal.
5. Identifikasi dukungan pemakai piranti lunak dalam penerimaan uji dan rencana proyek-proyek sebelumnya untuk mendapatkan validasi pada awal penerimaan pengujian.

Karena piranti lunak yang beroperasi di bawah pengembangan piranti lunak standar pemerintah, seperti standar Militer 483, fungsi SRR dan PDR adalah sering dikombinasikan. Ini adalah yang umum untuk merancang di mana usaha pengembangan piranti lunak /software bukanlah bagian dari suatu sistem lebih besar. Dalam yang kasus sedemikian kebutuhan spesifikasi mungkin adalah suatu pelanggan yang memproduksi dokumen atau produk dari suatu studi lebih awal dan dokumen dibanding dengan kontrak piranti lunak tertulis.

Tinjauan produk pada PDR yang kemudian adalah suatu statemen kebutuhan yang terperinci dan fungsional definisi piranti lunak yang serupa telah itu digambarkan dalam buku ini untuk Dokumen Disain Fungsional. Kebutuhan ditinjau sepanjang yang pertama bagian dari PDR, dan desain pendahuluan diperkenalkan sepanjang bagian yang terakhir dari tinjauan ulang. Hubungan antara dokumentasi diperlukan untuk menemukan standar militer / standard pemerintah dan dokumen diuraikan dalam buku ini diperkenalkan Catatan tambahan A.

Tinjauan Ulang Disain Kritis
Setelah persiapan Spesifikasi Rinci, suatu Tinjauan ulang Disain Kritis (Citical Design Review ( CDR)) tentang disain, dan test rencana harus diselenggarakan meneruskan tahap coding. Disain Rinci, spesifikasinya, sebagai rencana sociated, dan apapun isu kritis adalah tinjauan ulang pada CDR untuk :

1. bermufakat ketercukupan tentang desain rinci dan merencanakan,
2. isu tekad,
3. manajemen memperoleh persetujuan pelanggan dan untuk mulai tahap coding, dan
4. memperoleh persetujuan test program yang mendukung pengakuan produk. Perbedaan yang utama antara PDR dan CDR adalah tingkatan desain dan informasi test memperkenalkan dan meninjau.

Tinjauan ulang Internal Disain Piranti lunak
Sebelum CDR proyek boleh pada waktu tertentu melakukan tinjauan ulang desain piranti lunak informal di unit atau subroutine mengukur untuk memudahkan itu awal pendeteksian kesalahan desain. Beberapa petunjuk untuk tinjauan ulang disain ini adalah:

1. Disain Tinjauan ulang harus diselenggarakan di tingkatan unit sebagai perancangan unit masing-masing diselesaikan.
2. Tim Tinjauan ulang terdiri dari satu sampai empat orang, yang terutama pada perancang/programmer/ tingkat pengujian. Itu adalah yang diinginkan, tetapi tidak wajib, bahwa yang akhirnya programmer-programmer dan yang teruji tentang unit program jadilah anggota tim tinjauan ulang.
3. lingkup tinjauan ulang perlu meliputi, sebagai minimum, cek untuk kemampuan reaksi mendisain ke kebutuhan, kelengkapan dan konsistensi desain, arus data sampai masukan/keluaran antarmuka, test kemampuan, dan ukuran-ukuran lain yang sesuai seperti prosedur recovery kesalahan, modularas, dan kesederhanaan.
4. Permasalahan mendeteksi sepanjang tinjauan ulang desain suatu unit yang harus dikenali adalah suatu ringkasan tertulis dan tersedia untuk unit pengembang.

Tinjau ulang Test Prosedur
Personil Proyek yang perlu melakukan Prosedur Test verifikasi dan pengembangan terperinci Tinjauan ulang untuk meyakinkan melalui uji coba produk piranti lunak. Tujuan tinjauan ulang ini adalah untuk menyediakan prosedur persetujuan formal untuk digunakan di dalam piranti lunak menguji program dan untuk meyakinkan bahwa mereka memenuhi tujuan Test yang direncanakan. Rencana Test ditinjau pada CDR untuk meyakinkan bahwa semua corak desain penting diuji dan bahwa semua kebutuhan spesifikasi adalah terbukti.
Dua rangkaian Prosedur Test Tinjauan ulang harus diselenggarakan: Tinjauan ulang Prosedur Test Pengembangan Dan Prosedur Test Pengesahan Tinjauan ulang. Ini harus diselenggarakan secara terpisah. Prosedur Test Pengembangan Tinjauan ulang harus diselenggarakan sebelum pengintegrasian modul yang teruji. Prosedur Test Pengesahan Tinjauan ulang harus diselenggarakan sebelum verifikasi dan penerimaan diuji.
Verifikasi test diselenggarakan untuk memastikan bahwa unsur-unsur piranti lunak yang dilaksanakan individu ketika dirancang, dan kesalahan antarmuka itu antara mereka telah dihapuskan. Test Penerimaan diselenggarakan untuk memastikan bahwa subsistem pirangkat lunak atau program komputer yang diselesaikan membuat puas tercapainya kebutuhan yang dinyatakannya. Seperti itu, test verifikasi mengevaluasi piranti lunak itu melawan terhadap dokumentasi desain nya (Fungsional Desain dan Dokumen Disain Rinci), Sedangkan penerimaan menguji mengevaluasi pirangkat lunak itu melawan terhadap kebutuhan di dalam Spesifikasi Kebutuhan Piranti lunak.

Penerimaan Piranti lunak Tinjuan Ulang.
Penerimaan Piranti lunak Tinjauan ulang adalah suatu pelanggan / pemborong yang secara formal bertemu yang kemudian diadakan untuk audit produk piranti lunak sebelum pelanggan diterima. Penyelesaian tentang audit ini menandakan bahwa piranti lunak tersebut adalah siap untuk beroperasi dan bahwa tahap pengembangan telah diselesaikan. Tinjauan ulang yang secara normal terdiri dari dua macam audit, suatu Audit Konfigurasi Fungsional (Functional configuration audit (FCA)) dan suatu Audit Konfigurasi Phisik (Physical configuration audit ( PCA)).
Dua macam audit ini mungkin adalah diselenggarakan yang makin bertambah sebagai informasi yang diperlukan menjadi tersedia. Jika mereka penyelenggaraannya bertambah, kebanyakan materi tinjauan ulang akan merupakan suatu perihal merekam ketika pertemuan-pertemuan yang formal itu. SAR akan kemudian sebagian besar berisi pengujian arsip untuk memastikan bahwa semua audit materi telah diselesaikan.
Sasaran FCA adalah kebenaran bahwa capaian piranti lunak mematuhi kebutuhan capaian spesifikasi piranti lunak itu. Ini adalah terpenuhi dengan tinnjau ulang test data test mengumpulkan piranti lunak yang diuji. PCA diselenggarakan sebelum penyerahan piranti lunak. Itu terdiri dari dari suatu pengujian dokumentasi desain rinci melawan terhadap "as-built" konfigurasi piranti lunak. Itu diselenggarakan untuk memastikan ketercukupan itu, kelengkapan, dan ketelitian dokumentasi desain teknis. Tinjauan ulang juga meliputi suatu audit status perubahan sekarang, perubahan arsip, dan arsip uraian versi untuk memastikan bahwa "as-built" itu konfigurasi yang kompatibel dengan dokumen yang disampaikan itu.

2.3.2 Pengendalian Konfigurasi.
Manager proyek pengembangan piranti lunak/software harus menyediakan pengendalian konfigurasi sesuai dengan usaha pengembangan. Standard Pengendalian konfigurasi diuraikan pada bab 9. sesuai standars yang harus diadopsi oleh manager proyek dan menghasilkan dokumen rencana implementasi konfigurasi manajemen harus dan meringkas sebagai bagian dari proyek yang direncanakan. Masing-masing proyek akan mempunyai beberapa kebutuhan pengendalian konfigurasi yang unik. Bagaimanapun, semua projek yang diperlukan harus untuk menemukan standard pengendalian konfigurasi minimum.
Tanggung-Jawab Manajemen Konfigurasi organisatoris dibahas pada Bagian 4.2. Beberapa fungsi konfigurasi pengendalian dilakukan secara praktis pada tiap-tiap tingkatan perancangan pengembangan. Manajer proyek harus memastikan bahwa fungsi ini dengan baik dilakukan. Tugas manajemen ini adalah suatu kunci membantu pemahaman status perancangan pengembangan. Dalam banyak kasus manager proyek akan mempunyai konfugurasi akhir mengendalikan wewenang persetujuan.

2.3.3 Standard Dan Konvensi
Di mulai dengan manager proyek harus menggambarkan standars dan konvensi untuk digunakan. Implementasi Dan Adopsi sejumlah yang telah diambil standard dan konvensi harus didokumentasikan proyek yang direncanakan. Standard harus dipertahankan ketidak hadiran berlawanan kebutuhan pelanggan. Manapun penyimpangan dari perusahaan atau kostumisasi standard harus didokumentasikan Rencana Proyek, bersama-sama dengan suatu pertimbangan yang layak. Pertanggungan jawab manager proyek adalah untuk memastikan bahwa konvensi dan standard itu diikuti. Tinjauan ulang yang perlu memerlukan untuk melaksanakan tugas manajemen ini membantu manager proyek itu untuk memahami status dari pengembangan proyek.

Referensi
Philip Bruce, Sam M. Pederson, 1982 The Software Development Project, John Wiley and Sons, New York.
Steve McConnell, 1996, Rapid Development Taming Wild Software Schedule, Microsoft Press, Washington.
Tumar, 2002, Information System Strategic, Universitas Bina Nusantara, Jakarta.
Bob Hughes and Mike Cotterell, 2002, Software Project Management, McGraw Hill, London.