IEEE Panduan Teknologi Sistem Informasi

Definisi-Konsep Operasi (ConOps) Dokumen

Sponsor Software Engineering

Komite Standar dari IEEE Computer Society 19 Maret 1998

Disetujui IEEE-SA Standards Board

Abstract: Format dan isi konsep operasi (ConOps) dokumen ini menjelaskan sebuah ConOps yang berorientasi pengguna dokumen yang menggambarkan karakteristik sistem untuk sistem yang diusulkan dari 'sudut pandang para pengguna. ConOps dokumen yang digunakan untuk berkomunikasi secara kuantitatif dan kualitatif karakteristik sistem kepada pengguna, pembeli, pengembang, dan unsur organisasi lainnya (misalnya, pelatihan, fasilitas, staf, dan pemeliharaan). Hal ini digunakan untuk menggambarkan organisasi user (s), misi (s), dan • tujuan-tujuan organisasi dari sistem terpadu sudut pandang.

Kata kunci: pembeli, karakteristik, konsep operasi, konsep dokumen operasi, ConOps, pengembang, persyaratan operasional, skenario, perangkat lunak sistem intensif, sistem software, sistem, pengguna, kebutuhan pengguna, sudut pandang.

Dokumen Standar IEEE dikembangkan dalam IEEE Masyarakat dan Komite Koordinasi Standar IEEE Standards Board. Anggota komite melayani secara sukarela dan tanpa kompensasi. Mereka tidak perlu anggota Institut. Standar IEEE mewakili dikembangkan dalam konsensus keahlian yang luas pada subjek dalam Institut serta kegiatan-kegiatan di luar IEEE yang telah menyatakan minat untuk berpartisipasi dalam pengembangan standar.

Penggunaan IEEE Standard adalah sepenuhnya sukarela. Keberadaan sebuah Standar IEEE tidak berarti bahwa tidak ada cara lain untuk menghasilkan, menguji, mengukur, pembelian, pasar, atau menyediakan barang dan jasa lain yang berkaitan dengan lingkup Standar IEEE.

Selanjutnya, sudut pandang yang diungkapkan pada saat standar disetujui dan dikeluarkan dapat berubah ditimbulkan melalui perkembangan di negara bagian seni dan komentar yang diterima dari pengguna standar.

Setiap IEEE Standar mereview sekurang-kurangnya setiap lima tahun untuk revisi atau penegasan kembali. Bila dokumen adalah lebih dari lima tahun dan belum ditegaskan kembali, masuk akal untuk menyimpulkan bahwa isinya, walaupun masih dari beberapa nilai, tidak sepenuhnya mencerminkan keadaan seni. Pengguna memperingatkan untuk memeriksa untuk menentukan bahwa mereka memiliki edisi terbaru dari setiap IEEE Standar.

Komentar untuk revisi Standar IEEE dipersilahkan dari pihak yang berkepentingan, tanpa afiliasi dengan keanggotaan IEEE. Saran untuk perubahan dokumen harus dalam bentuk perubahan yang diusulkan teks, bersama dengan pendukung yang sesuai komentar. Interpretasi: Kadang-kadang pertanyaan-pertanyaan yang mungkin timbul mengenai arti dari bagian-bagian standar karena terkait dengan aplikasi tertentu. Ketika kebutuhan untuk interpretasi dibawa ke perhatian IEEE, Institute akan melakukan tindakan untuk menyiapkan respons yang sesuai.

Karena konsensus Standar IEEE mewakili kepentingan semua pihak, adalah penting untuk memastikan bahwa setiap penafsiran juga telah mendapat persetujuan dari keseimbangan kepentingan. Untuk alasan ini, IEEE dan anggota dari masyarakat dan Standar Komite Koordinasi tidak dapat memberikan respon terhadap penafsiran instan permintaan kecuali dalam kasus-kasus di mana matte / sebelumnya menerima consideration.Comments resmi mengenai standar dan permintaan untuk penafsiran harus ditujukan untuk: Sekretaris, IEEE 445 Hoes Strndards Dewan LaneP.O. Box 1331 Piscataway, NJ 08855-1331 USA Catatan: Perhatian dipanggil untuk kemungkinan bahwa pelaksanaan standar ini mungkin memerlukan penggunaan subjek yang dicakup oleh hak paten.

Dengan penerbitan standar ini, tidak ada posisi yang diambil sehubungan dengan adanya atau keabsahan dari setiap hak paten yang berhubungan dengannya. IEEE tidak bertanggung jawab untuk mengidentifikasi hak paten yang lisensi mungkin diperlukan oleh standar IEEE atau untuk melakukan penyelidikan keabsahan hukum atau cakupan yang paten yang akan dibawa ke perhatian.

Tujuan ini menyajikan format dan isi konsep operasi (ConOps) dokumen yang akan digunakan ketika mengembangkan atau memodifikasi perangkat lunak sistem intensif. Software-sistem intensif adalah sistem perangkat lunak yang merupakan tantangan teknis utama dan mungkin merupakan faktor utama yang mempengaruhi jadwal sistem, biaya, dan risiko.

Dalam kasus yang paling umum, sebuah perangkat lunak sistem intensif terdiri dari perangkat keras, perangkat lunak, orang, dan manua. " prosedur. Untuk membuat panduan ini lebih mudah dibaca, istilah "sistem" akan digunakan untuk asoftware-intensif berarti sistem yang mencakup unsur-unsur untuk dikembangkan atau diubah, di samping perangkat lunak. Istilah.

"Sistem perangkat lunak" akan digunakan untuk maksud-software sistem intensif di mana perangkat lunak merupakan satu-satunya komponen untuk dikembangkan atau dimodifikasi. Panduan ini tidak menjelaskan teknik-teknik yang tepat untuk digunakan dalam mengembangkan dokumen ConOps, tetapi tidak memberikan pendekatan yang dapat digunakan.

Setiap organisasi yang menggunakan panduan ini harus mengembangkan seperangkat praktek dan prosedur untuk memberikan panduan rinci untuk mempersiapkan dan memperbarui dokumen ConOps. Ini praktek-praktek dan prosedur rinci harus into'account lingkungan, organisasi, dan faktor-faktor politik yang mempengaruhi penerapan panduan.

Jantung ConOps dijelaskan dalam buku petunjuk ini terdapat dalam Klausul 3 sampai 5.

Pasal 3 menjelaskan sistem yang ada (manual atau otomatis) bahwa pengguna ingin mengganti.

Ayat 4 memberikan pembenaran untuk yang baru atau diubah sistem dan semua larangan pada sistem tersebut.

Ayat 5 menjelaskan sistem yang diusulkan.

Garis untuk Klausul 3 dan pasal 5 adalah hampir identik. Ini bukan untuk mengatakan bahwa isi dokumen yang telah selesai ConOps akan sama. Sebaliknya, isi harus sangat berbeda .. Garis yang sama untuk mengingatkan pengembang item yang harus dimasukkan dan tindakan yang akan diambil.

Tidak semua proyek perangkat lunak yang bersangkutan dengan pengembangan kode sumber untuk produk software baru. Beberapa proyek perangkat lunak terdiri dari kelayakan s ^ udy dan definisi persyaratan produk. Tenninate proyek-proyek lain setelah menyelesaikan desain produk atau hanya berkaitan dengan modifikasi produk perangkat lunak yang ada. Penerapan panduan ini tidak terbatas pada operasional proyek yang mengembangkan versi produk baru, juga tidak dibatasi oleh ukuran atau cakupan proyek.

Proyek-proyek kecil mungkin membutuhkan lebih sedikit formalitas dari proyek-proyek besar, tetapi semua komponen dari panduan ini harus ditangani oleh setiap proyek software. Pendekatan yang ConOps menyediakan kegiatan analisis dan dokumen that'bridges kesenjangan antara kebutuhan pengguna dan penglihatan dan pengembang spesifikasi teknis.

Selain itu, dokumen menyediakan ConOps berikut:

- Sebuah cara untuk menggambarkan pengguna kebutuhan operasional tanpa menjadi macet dalam masalah teknis rinci yang ditujukan pada kegiatan analisis sistem.

- Sebuah mekanisme untuk mendokumentasikan karakteristik sistem dan kebutuhan operasional pengguna dengan cara yang dapat diverifikasi oleh pengguna tanpa memerlukan pengetahuan teknis apapun di luar apa yang dibutuhkan untuk melakukan normal fungsi pekerjaanku.

- Sebuah tempat bagi pengguna untuk menyatakan keinginan mereka, visi, dan harapan tanpa memerlukan penyediaan dihitung, diuji spesifikasi. Sebagai contoh, pengguna dapat mengungkapkan kebutuhan mereka untuk "handal" sistem, dan alasan-alasan yang mereka butuhkan, tanpa harus menghasilkan kehandalan yang dapat diuji persyaratan.

Dalam hal ini, pengguna perlu untuk "keandalan tinggi" mungkin dinyatakan dalam istilah kuantitatif oleh pembeli sebelum mengeluarkan permintaan pembuatan proposal (RFP), atau mungkin dapat dihitung oleh pengembang selama analisis persyaratan. Dalam kasus apapun, itu adalah tugas dari uyerand pengembang untuk mengukur kebutuhan pengguna

- Sebuah mekanisme untuk pengguna dan pembeli (s) untuk mengekspresikan thougnts dan kekhawatiran tentang kemungkinan strategi solusi. Dalam beberapa kasus, kendala desain mendikte pendekatan tertentu. Dalam kasus lain, mungkin ada berbagai diterima strategi solusi.

Dokumen ConOps memungkinkan para pengguna dan pembeli (s) untuk merekam kendala desain, yang alasan bagi mereka kendala, dan untuk menunjukkan berbagai strategi solusi yang dapat diterima. Bermaksud menggunakan .Panduan ini dimaksudkan untuk digunakan dalam berbagai situasi oleh berbagai pengguna termasuk yang berikut ini:

- Acquirers menggunakan ISO / IEC 12207:1995, teknologi informasi-Software proses siklus hidup, akan menemukan Panduan saat ini cocok untuk memuaskan persyaratan 5.1.1.1: "The pengakuisisi memulai proses akuisisi dengan menjelaskan sebuah konsep atau kebutuhan untuk memperoleh, mengembangkan, atau meningkatkan sistem, perangkat lunak atau perangkat lunak procuct layanan."

- Pengguna yang sebelumnya diterapkan MIL-STD-498, Software Development dan Dokumentasi, dan standar yang terkait akan menemukan bahwa dokumen ConOps dijelaskan dalam buku petunjuk ini sangat mirip dengan konsep operasional deskripsi (OCD) termasuk dalam MIL-STD-498.

- Pengguna EIA / IEEE J-STD-016-1995, EIA / IEEE Interim Trial-Gunakan Standar untuk Teknologi Informasi Proses Software Life Cycle Software Development Acquirer-Supplier Perjanjian akan menemukan bahwa dokumen ConOps dijelaskan dalam buku petunjuk ini secara substantif identik dengan OCD termasuk dalam EIA / IEEE J-STD-016-1995.

- Lain pengguna akan menemukan panduan ini berguna dalam memfasilitasi komunikasi di antara berbagai pemangku kepentingan dalam suatu proyek.

Tinjauan Panduan ini berisi empat klausa. Ayat 1 mendefinisikan cakupan panduan ini. Ayat 2 memberikan referensi standar IEEE lain yang harus diikuti ketika menerapkan panduan ini. Ayat 3 memberikan definisi dari istilah yang digunakan di seluruh panduan.

Ayat 4 berisi ikhtisar dan spesifikasi rinci dari ConOps dokumen, termasuk komponen yang diperlukan yang harus disertakan, dan komponen opsional yang mungkin termasuk dalam rencana proyek berdasarkan panduan ini.

Organisasi yang bertanggung jawab

Idealnya, ConOps dokumen harus ditulis oleh wakil-wakil komunitas pengguna. Dalam prakteknya, individu atau organisasi lain dapat menulis ConOps (misalnya, pembeli, konsultan pihak ketiga, dan / atau pengembang perangkat lunak).

Dalam kasus ini, penting bila user terlibat dalam meninjau, merevisi, dan menyetujui dokumen ConOps.

Tujuan utama untuk dokumen ConOps adalah untuk menangkap kebutuhan pengguna, dan untuk mengungkapkan kebutuhan-kebutuhan tersebut dalam terminology pengguna.

Audience Panduan ini ditujukan untuk pengguna dan pembeli sistem perangkat lunak, pengembang perangkat lunak, dan personel lain yang menyiapkan dan memperbarui perangkat lunak persyaratan operasional untuk sistem intensif dan memonitor kepatuhan terhadap persyaratan tersebut.

Evolusi rencana

Mengembangkan versi awal dari dokumen ConOps harus menjadi salah satu kegiatan pertama selesai pada proyek perangkat lunak. Sebagai proyek berkembang, sifat pekerjaan yang harus dilakukan dan rincian pekerjaan akan lebih baik dipahami. ConOps dokumen yang harus diupdate secara berkala untuk mencerminkan situasi yang berkembang. Jadi, setiap versi dokumen harus ditempatkan di bawah kontrol konfigurasi.

Terminologi

Panduan ini mengikuti edisi tahun 1996 Standar IEEE Style Manual. Istilah harus, mungkin, mungkin, dan menyarankan digunakan untuk menunjukkan tindakan yang harus digunakan untuk mengembangkan dokumen ConOps yang baik tetapi yang tidak wajib. Namun, para penulis dari sebuah dokumen ConOps harus mempertimbangkan untuk menggunakan semua aspek dari panduan ini untuk memastikan lengkap dan efektif dokumen. Dokumen yang ConOps kadang-kadang disebut konsep operasional dokumen (OCD).

Sejarah

Penggunaan dokumen ConOps pertama kali didokumentasikan di Lano, RJ, "A Structured Pendekatan untuk Perumusan Konsep Operasional," TRW SS-80-02, TRW Pertahanan dan Space Systems Group, Redondo Beach, CA, 1980. Pada tahun 1992 Sistem Perangkat Lunak Panitia Teknis American Institute of Aeronautics and Astronautics (alaa), mengembangkan sebuah standar untuk OCD.

Panduan ConOps ini berasal pada Oktober 1993, sebagai Master of Science tesis di California State University, Sacramento, dan didukung oleh Kantor US Penelitian dan Pengembangan. Itu diterima sebagai MIL-STD-498, Data Item Description (DID), oleh theDoD-Std-2167A Harmonisasi Working Group dengan sedikit cnanges. M1L-STD-498-1995 menjadi IEEE Std 1498-1995, yang redesignated J-STD-016-1995. Dewan Standar IEEE menyetujui permintaan otorisasi proyek (PAR) untuk pengembangan panduan ini pada bulan Juni 1993. Draft pertama telah disampaikan kepada Komite Standar Software Engineering (SESC) pada tanggal 8 Agustus 1995; itu adalah kembali pada tanggal 1 November 1995 dengan permintaan bahwa panduan diselaraskan dengan tertentu lainnya standar rekayasa perangkat lunak tertentu. Kedua rancangan telah disampaikan kepada SESC pada tanggal 28 Februari 1996. Draft ini balloted pada tanggal 21 Agustus 1996.

Peserta

Panduan ini ditulis oleh IEEE Panduan untuk Operasi Dokumen Konsep Working Group, yang merupakan bagian dari IEEE Computer Society. Berikut adalah tiga orang penulis dari panduan ini: Richard H. Thayer

Richard E. Fairley

Per Bjorke

Other individuals who supported the development of this guide are:

Jed Bartlett Merlin Dorfman

Boris I. Cogan Rajko Milovanovic

The following persons were on the balloting committee:

Randy Paul jane Radatz

Mikhail Auguston Peter A. Berggren

Robert E. Barry H. Ronald Berlack

Mordechai Ben-Menachem Audrey C. Brewer

Alan L. Bridges Kathleen L. Briggs Thomas G. Callaghan

Contents

1. Scope (tya).................................................................................................................................. l

2. References (tya)........................................................................................]................................1

3. Definitions (tya)...,................................................................................„;...................................2

4. Elements of a ConOps document.................................................................................................4

4.1 Scope (Clause 1 of the ConOps document) (tya)....................................................................54.2 Referenced documents (Clause 2 of the ConOps document) (rida)........................................64.3 Current system or situation (Clause 3 of the ConOps document) (rida)......-............................74.4 Justification for and nature of changes (Clause 4 of the ConOps document) (qorry)................94.5 Concepts for the proposed system (Clause 5 of the ConOps document) (qorry)....................114.6 Operational scenarios (Clause 6 of the ConOps document) (onny).......................................144.7 Summary of impacts (Clause 7 of the ConOps document) (onny)..........................................154.8 Analysis of the proposed system (Clause 8 of the ConOps document)(tya)............................164.9 Notes (Clause 9 on the ConOps document) (rida)................................................................164.10Appendices (Appendices of die ConOps document) (qorry).................................................164.11Glossary (Glossary of the ConOps document) (onny)...........................................................16

Annex A (Informative) IEEE/EIA 12207.1-1997 Compliance Statement...................................................17

IEEE Panduan untuk Teknologi Informasi

Definisi-Konsep Sistem Operasi (ConOps) Dokumen

1. Lingkup

Panduan ini menentukan format dan isi konsep operasi (ConOps) dokumen. Sebuah ConOps adalah berorientasi pengguna dokumen yang menggambarkan karakteristik sistem to-be-sistem disampaikan dari sudut pandang pengguna. ConOps dokumen yang digunakan untuk berkomunikasi secara kuantitatif dan kualitatif karakteristik sistem kepada pengguna, pembeli, pengembang, dan unsur organisasi lainnya (misalnya, pelatihan, fasilitas, staf, dan pemeliharaan). Ini menggambarkan organisasi user (s), misi (s), dan tujuan organisasi dari systeiis terpadu sudut pandang.

Panduan ini dapat diterapkan pada semua jenis perangkat lunak sistem intensif: hanya perangkat lunak atau perangkat lunak / perangkat keras / orang sistem. Konsep-konsep yang terkandung dalam buku petunjuk ini juga bisa digunakan untuk hardware-hanya sistem, tetapi cara ini digunakan tidak ditujukan di sini. Ukuran, ruang lingkup, kompleksitas, atau kritis dari produk perangkat lunak tidak membatasi penggunaan panduan ini. Panduan ini berlaku untuk sistem yang akan diterapkan di segala bentuk produk media, termasuk firmware, embedded system code, programmable logic array, dan software-di-silikon. Panduan ini dapat diterapkan untuk setiap dan semua segmen dari siklus hidup sistem. Minimal ret mengidentifikasi unsur-unsur yang harus muncul dalam semua dokumen ConOps. Namun, pengguna buku petunjuk ini mungkin memasukkan unsur-unsur lain dengan menambahkan klausul tambahan atau ConOps mereka subclauses dokumen. Dalam setiap kasus, skema penomoran klausa yang diperlukan dan harus mematuhi subclauses format yang ditetapkan dalam buku petunjuk ini. Berbagai klausa dan subclauses dari dokumen ConOps dapat dimasukkan oleh penggabungan langsung atau dengan mengacu pada dokumen-dokumen pendukung lainnya.

2. Referensi

Panduan ini akan digunakan dalam hubungannya dengan publikasi berikut. Secara khusus, pada persyaratan standar dan rencana harus berkonsultasi dalam menyiapkan ConOps Ketika standar-standar berikut ini digantikan oleh revisi yang telah disetujui, revisi akan berlaku. IEEE Std 610.12-1990, IEEE Standard Glossary of Software Engineering Terminology.1

3. Definisi

Definisi yang tercantum di sini menetapkan makna dalam konteks panduan ini. Definisi istilah-istilah lain yang mungkin sesuai dalam konteks panduan ini dapat ditemukan dalam IEEE Std 610,12-1.990.

3.1 Analisis : Proses mempelajari sistem partisi sistem ke dalam bagian (fungsi, komponen, atau objek) dan menentukan bagaimana bagian-bagian berhubungan satu sama lain.

3.2 pembeli: (A) Sebuah individuaj atau organisasi yang bertanggung jawab untuk memperoleh suatu produk atau jasa (misalnya, sistem perangkat lunak) untuk digunakan oleh mereka sendiri atau pengguna lain. Lihat juga: pelanggan. (B) Orang atau organisasi yang menerima sistem dan membayar untuk proyek.

Konsep

3.3 Analisis konsep: The derivasi dari konsep sistem melalui penerapan analisis. 3.4 Konsep operasi (ConOps) dokumen: Seorang pengguna yang berorientasi dokumen yang menggambarkan karakteristik operasional sistem dari sudut pandang pengguna akhir. Sinonim: deskripsi konsep operasional (OCD).

3.5 kendala: Sebuah eksternal pada sistem pembatasan dikenakan persyaratan, desain, atau pelaksanaan atau pada proses yang digunakan untuk mengembangkan atau memodifikasi sebuah sistem. 3.6 kontrak: Dalam manajemen proyek, dokumen yang mengikat secara hukum disepakati oleh nasabah dan pengembang perangkat keras atau perangkat lunak atau pemasok; mencakup teknis, organisasi, biaya, dan / atau persyaratan penjadwalan proyek.

3.7 pelanggan: (A) Orang pribadi atau organisasi yang menetapkan persyaratan dan menerima penyerahan secara resmi baru atau diubah produk perangkat keras atau perangkat lunak dan dokumentasi; pelanggan mungkin atau tidak menjadi pengguna utama dari sistem.

Ada potensial, banyak tingkat pelanggan, masing-masing dengan tingkat yang berbeda untuk memuaskan kebutuhan. Pelanggan mungkin internal atau eksternal bagi organisasi pembangunan untuk proyek. Lihat juga: user.

(B) Seorang individu atau organisasi yang bertindak bagi pengguna akhir yang baru atau diubah produk perangkat keras atau perangkat lunak untuk mendapatkan produk dan dokumentasinya. Lihat juga: pembeli. 3.8 pengembang: Suatu organisasi yang mengembangkan produk-produk perangkat lunak; "mengembangkan" dapat mencakup perkembangan baru, modifikasi, menggunakan kembali, rekayasa ulang, pemeliharaan, atau kegiatan lain yang menghasilkan produk-produk perangkat lunak, dan termasuk pengujian, jaminan mutu, manajemen konfigurasi, dan kegiatan lainnya diterapkan untuk produk ini. Sinonim: pemasok.

3.9 lingkungan: Keadaan, benda, dan kondisi yang mengelilingi sebuah sistem yang akan dibangun; mencakup teknis, politik, komersial, budaya, organisasi, dan pengaruh fisik serta standar dan kebijakan yang mengatur sistem apa yang harus dilakukan atau bagaimana, akan melakukannya.

3.10 fungsi: Kemampuan dari berbagai komputasi, user interface, input, output, manajemen data, dan fitur lain yang diberikan oleh produk.

3.11 mode: Satu set fitur terkait atau kemampuan fungsional dari suatu produk, (misalnya, on-line, off-line, dan pemeliharaan mode).

3.12 N diagram: Sebuah sistem rekayasa perangkat lunak teknik atau alat untuk tabulasi, mendefinisikan, menganalisis, dan menggambarkan antarmuka fungsional dan interaksi di antara komponen sistem. The N2 diagram struktur matriks yang menampilkan grafis bidirectional fungsi dan keterkaitan antara komponen dalam suatu sistem atau struktur. 3.13 konsep operasional deskripsi (OCD): Lihat: konsep operasi (ConOps) dokumen. 3,14 prioritas: Sebuah urutan peringkat status, kegiatan, atau tugas-tugas. Prioritas sangat penting ketika sumber daya terbatas.,

3.15 masalah domain: Satu set masalah yang sama yang terjadi dalam suatu lingkungan dan meminjamkan diri ke solusi umum.

3.16 permintaan proposal (RFP): Sebuah permintaan layanan, penelitian, atau produk yang disiapkan oleh pelanggan dan dikirimkan kepada calon pengembang dengan harapan bahwa calon pengembang akan merespons dengan biaya yang diusulkan, jadwal, dan pendekatan pembangunan.

3.7 skenario: (A) Sebuah langkah-demi-langkah deskripsi dari rangkaian peristiwa yang mungkin terjadi secara bersamaan atau secara berurutan. (B) Sebuah rekening atau sinopsis dari suatu kursus diproyeksikan peristiwa atau tindakan.

3.18 software-sistem intensif: Sebuah sistem untuk perangkat lunak mana yang merupakan tantangan teknis utama dan mungkin merupakan faktor utama yang mempengaruhi jadwal sistem, biaya, dan risiko. Dalam kasus yang paling umum, sebuah perangkat lunak sistem intensif terdiri dari perangkat keras, perangkat lunak, orang, dan manual prosedur.

3.19 siklus hidup perangkat lunak: Sistem atau siklus produk yang diprakarsai oleh pengguna kebutuhan atau dirasakan kebutuhan pelanggan dan diberhentikan oleh menghentikan penggunaan produk. Siklus hidup perangkat lunak biasanya menyertakan sebuah konsep fase, persyaratan tahap, tahap desain, tahap pelaksanaan, tahap pengujian, instalasi dan checkout fase, fase operasi dan pemeliharaan, dan, kadang-kadang, fase pensiun. Fase-fase ini mungkin tumpang tindih dalam waktu atau mungkin terjadi iteratively. 3.20 sistem perangkat lunak: software-sistem intensif yang lunak, adalah satu-satunya komponen untuk dikembangkan atau dimodifikasi. Lihat juga: perangkat lunak sistem intensif. 3.21 solusi domain: The lingkungan di mana solusi atau serangkaian solusi berada. Lihat juga: masalah domain. 3.22 pemasok: Lihat: pengembang.

3.23 Sistem (A) Asekumpulan komponen yang berinteraksi terorganisir untuk mencapai fungsi tertentu atau sekumpulan fungsi dalam lingkungan tertentu. (B) Sekelompok orang, benda, dan merupakan prosedur untuk mencapai tujuan yang telah ditetapkan beberapa peran operasional dengan melakukan fungsi-fungsi tertentu. Sebuah sistem lengkap yang mencakup semua peralatan yang terkait, fasilitas, bahan, program komputer, firmware, dokumentasi teknis, layanan, dan personel yang diperlukan untuk Operas dan dukungan ke tingkat yang diperlukan untuk mandiri dimaksudkan digunakan dalam lingkungan. ( 3.24 Penelusuran: Identifikasi dan dokumentasi derivasi jalan (ke atas) dan alokasi atau flowdown jalan (ke bawah) dari produk kerja dalam hirarki produk kerja. Penting jenis pelacakan meliputi: ke atau dari sumber eksternal atau dari persyaratan sistem; ke atau dari sistem persyaratan ke atau dari tingkat terendah persyaratan; ke atau dari persyaratan ke atau dari desain atau dari desain ke atau dari pelaksanaan; ke atau dari pelaksanaan untuk menguji dan ke atau dari persyaratan untuk menguji. 3.25 pengguna: (A) Orang pribadi atau organisasi yang menggunakan perangkat lunak sistem intensif dalam aktivitas kerja sehari-hari atau recreatiorjaj pursuits. (B) seseorang (atau orang) yang mengoperasikan atau berinteraksi secara langsung dengan perangkat lunak sistem intensif. 3.26 kebutuhan user: Seorang pengguna persyaratan untuk sistem user percaya akan menyelesaikan masalah yang dialami oleh pengguna

4. Unsur dokumen ConOps

Klausul ini menggambarkan masing-masing dari unsur-unsur penting dari sebuah dokumen ConOps. Elemen-elemen ini harus dipesan dalam urutan klausa dan subclauses ditunjukkan pada Tabel 1. Setiap versi dokumen ConOps didasarkan pada panduan ini harus berisi judul dan revisi perhatikan bahwa pengenal yang unik pada dokumen.

Informasi revisi proyek dapat mencakup nama, nomor versi dokumen, tanggal rilis, tanda tangan persetujuan, daftar suhclauses yang telah diubah dalam versi dokumen, dan daftar nomor versi dan tanggal pembebasan semua sebelumnya versi dokumen.

ConOps yang disetujui dokumen harus ditempatkan di bawah kontrol konfigurasi.

Sebagaimana ditunjukkan pada Tabel 1, pengantar dari dokumen ConOps memberikan informasi bahwa penulis ingin pembaca tahu sebelum membaca dokumen. Kata pengantar harus mencakup tujuan dokumen, ruang lingkup kegiatan yang mengakibatkan perkembangannya, yang menulis dokumen dan mengapa, yang dimaksudkan penonton untuk dokumen, dan evolusi yang diharapkan dokumen.Daftar isi, daftar angka, dan daftar tabel harus dimasukkan dalam setiap ConOps dokumen, seperti ditunjukkan dalam Gambar 1

Persyaratan untuk dokumen kepatuhan dibahas dalam subclauses berikut: A.3.1 membahas informasi sesuai dengan persyaratan yang tercantum dalam kolom 2 Tabel A.2 seperti yang ditentukan oleh Pasal 5.1.1.1 dari IEEE / EIA 12.207,0-1.996.

A.3.2 membahas sesuai dengan pedoman konten generik (the "jenis" dokumen) dicatat dalam kolom 3 dari Tabel A.2 sebagai "deskripsi." Panduan konten generik untuk "deskripsi" muncul di 5,1 dari IEEE / EIA 12.207,1-1.997.

A.3.3 membahas sesuai dengan persyaratan tertentu untuk dokumen ConOps dicatat dalam kolom 4 dari Tabel A.2 seperti yang ditentukan oleh 6,3 dari IEEE / EIA 12.207,1-1.997.

A.3.4 membahas sesuai dengan data siklus hidup tujuan dari Lampiran H dari IEEE / EIA 12.207,0-1.996 seperti yang dijelaskan dalam 4,2 dari IEEE / EIA 12.207,1-1.997.

A.3.1 Kepatuhan dengan informasi persyaratan lEEE / EIA 12.207,0-1.996 Informasi persyaratan untuk dokumen ConOps adalah yang ditentukan oleh 5.1.1.1 dari IEEE / EIA 12.207,0-1.996. Dalam kasus ini, persyaratan tersebut secara substansial identik seperti A.3.3 mereka yang dianggap dalam standar ini.

A.3.2 Kepatuhan dengan panduan konten generik dari lEEE / EIA 12.207,1-1.997 Panduan konten generik untuk "deskripsi" di IEEE / EIA 12.207,1-1.997 diresepkan oleh 5,1 dari IEEE / EIA 12.207,1-1.997.

Sebuah deskripsi memenuhi akan mencapai tujuan yang tercantum dalam 5.1.1 dan termasuk informasi yang tercantum dalam 5.1.2 dari IEEE / EIA 12.207,1-1.997.

Tujuan dari deskripsi adalah:

IEEE / EIA 12.207,1-1.997, subclause 5.1.1: Tujuan: Jelaskan yang direncanakan atau fungsi yang sebenarnya, desain, kinerja, atau proses.

4.1.1 Indentiflcation (1.1 dari dokumen ConOps)

Subclause ini berisi nomor identifikasi, judul, dan singkatan (jika berlaku) dari sistem atau subsistem yang ConOps ini berlaku. Jika dokumen-dokumen yang terkait ConOps untuk sistem secara keseluruhan telah dikembangkan secara hirarki atau jaringan dengan cara, posisi dokumen ini relatif terhadap dokumen-dokumen ConOps lain harus dijelaskan.

4.1.2 Dokumen ikhtisar (1.2 dari dokumen ConOps)

Subclause ini meringkas dan memperluas tujuan motivasi untuk ConOps dokumen. Tujuan khalayak untuk dokumen juga harus disebutkan. Selain itu, subclause ini menjelaskan apapun pertimbangan keamanan atau privasi yang terkait dengan penggunaan ConOps. Subclause ini juga menguraikan sisa bagian panduan ini.

Tujuan dari dokumen ConOps akan, dalam banyak kasus, menjadi; - Untuk berkomunikasi pengguna kebutuhan dan harapan dari sistem yang diusulkan kepada pembeli dan / atau pengembang;

- Untuk berkomunikasi pembeli atau pengembang pemahaman pengguna 'kebutuhan dan bagaimana sistem akan beroperasi untuk memenuhi kebutuhan tersebut. Namun, sebuah dokumen ConOps mungkin juga melayani tujuan lain, seperti membangun konsensus di antara beberapa kelompok pengguna, di antara beberapa organisasi pembeli, dan / atau di antara beberapa pengembang. Para penonton dari: ConOps dokumen ini dapat beragam orang.

- User dapat membacanya untuk menentukan apakah kebutuhan dan keinginan mereka telah benar ditentukan oleh perwakilan mereka atau untuk memverifikasi pengembang under: anding dari kebutuhan mereka.

- Pembeli dapat membacanya untuk mendapatkan pengetahuan tentang kebutuhan pengguna dan / atau pengembang pemahaman kebutuhan tersebut.

- Pengembang akan biasanya menggunakan ConOps dokumen sebagai dasar untuk kegiatan pengembangan sistem, dan membiasakan anggota tim baru dengan masalah domain dan sistem yang berlaku ConOps.

4.1.3 ikhtisar Sistem (1.3 dari dokumen ConOps)

Subclause ini menyatakan secara singkat tujuan dari sistem yang diusulkan atau subsistem mana ConOps berlaku. Ini menggambarkan sifat umum dari sistem, dan mengidentifikasi proyek sponsor, lembaga pengguna, organisasi pembangunan, dukungan lembaga, badan-badan sertifikasi atau sertifikasi, dan pusat-pusat operasi atau situs yang akan menjalankan sistem. Hal ini juga menunjukkan dokumen-dokumen lain yang relevan hingga saat ini atau sistem yang diusulkan.

Sebuah gambaran grafis dari sistem sangat dianjurkan. Hal ini bisa dalam bentuk diagram konteks, tingkat atas objek diagram, atau beberapa jenis diagram yang menggambarkan sistem dan lingkungannya.

Dokumen yang mungkin dikutip termasuk, tetapi tidak terbatas pada: otorisasi proyek, dokumentasi teknis yang relevan, signifikan korespondensi, dokumen tentang proyek terkait, laporan analisis risiko, dan studi kelayakan.

4.2 Referenced dokumen (Pasal 2 dari dokumen ConOps)

Klausul ini daftar nomor dokumen, judul, revisi, dan tanggal dari semua dokumen yang direferensikan di dalam dokumen ConOps. Klausul ini juga harus mengidentifikasi soi rce untuk semua dokumen yang tidak tersedia melalui saluran normal.

4.3 Sistem atau situasi (Pasal 3 dari dokumen ConOps)

Ayat 3 menjelaskan sistem atau situasi (baik otomatis atau manual) seperti saat ini. Jika tidak ada sistem yang sekarang yang akan menjadi dasar perubahan, subclause ini menggambarkan situasi yang memotivasi pengembangan sistem yang diusulkan. Dalam kasus ini, berikut akan subclauses disesuaikan sesuai untuk menggambarkan situasi yang memotivasi.

Klausul ini juga menyediakan pembaca dengan pengenalan masalah domain. Hal ini memungkinkan pembaca untuk lebih memahami alasan-alasan untuk perubahan dan perbaikan yang diinginkan.

4.3.1 Latar Belakang, tujuan, dan ruang lingkup (3,1 dari dokumen ConOps)

Subclause ini memberikan ikhtisar tentang sistem atau situasi saat ini, termasuk sebagai berlaku, latar belakang, misi, tujuan, dan ruang lingkup. Selain menyediakan latar belakang untuk sistem yang sekarang, subclause ini harus memberikan ringkasan singkat dari motivasi untuk sistem yang sekarang.

Contoh motivasi untuk sistem otomatisasi dapat mencakup tugas-tugas tertentu atau melawan ancaman situasi tertentu. Para goafs untuk sistem yang sekarang juga harus ditetapkan, bersama-sama dengan strategi, solusi, taktik, metode, dan teknik yang digunakan untuk mencapai mereka.

Modus operasi, kelas pengguna, dan interface kelingkungan operasional menetapkan cakupan sistem yang diusulkan, yang dirangkum dalamklausul ini dan didefinisikan secara lebih rinci dalam pasal-pasal berikutnya.

4.3.2 kebijakan operasional dan kendala (3.2 dari dokumen ConOps) Subclause ini menggambarkan kebijakan operasional dan kendala yang berlaku untuk sistem yang sekarang atau situasi.

Kebijakan operasional yang telah ditetapkan keputusan manajemen operasi mengenai sistem saat ini, biasanya dalam bentuk pernyataan atau pemahaman umum yang membimbing kegiatan pengambilan keputusan.

Kebijakan pengambilan keputusan membatasi kebebasan tapi apakah memungkinkan untuk beberapa kebijaksanaan. Operasional kendala keterbatasan ditempatkan pada operasi sistem yang sekarang.

Contoh kendala operasional meliputi:

- Sebuah kendala pada jam operasi dari sistem, mungkin dibatasi oleh akses ke terminal aman - Sebuah kendala pada jumlah personil yang tersedia untuk mengoperasikan sistem - Sebuah kendala pada perangkat keras komputer (misalnya, harus beroperasi di komputer X) - Sebuah kendala operasional pada fasilitas, seperti ruang kantor 4.3.3 Deskripsi sistem yang sekarang atau situasi (3,3 dari dokumen ConOps) Subclause ini akan berisi bagian utama dari deskripsi sistem yang sekarang. Ini memberikan gambaran mengenai sistem yang sekarang atau situasi, termasuk yang berikut, yang sesuai: a) lingkungan operasional dan karakteristiknya

b) komponen sistem Mayor dan keterkaitan antara komponen-komponen;

c) Penghubung ke sistem eksternal atau prosedur

d) Kemampuan, fungsi, dan fitur dari sistem yang sekarang

e) Grafik dan deskripsi yang menyertainya yang menggambarkan input, output, aliran data, aliran kontrol, dan proses manual dan otomatis cukup untuk memahami sistem yang sekarang atau situasi dari pengguna sudut pandang;

f) Biaya sistem operasi;

g) faktor-faktor risiko operasional;

h) Kinerja karakteristik, seperti kecepatan, throughput, volume, frekuensi;

i) Kualitas atribut, seperti: ketersediaan, ketepatan, efisiensi, upgrade, fleksibilitas, interoperabilitas, menjaga-kemampuan, portabilitas, reliabilitas, usabilitas, supportability, survivability, dan kegunaan, dan

j) Ketentuan untuk keselamatan, keamanan, privasi, integritas, dan kesinambungan operasi dalam keadaan darurat. Ayat ini bertujuan untuk menggambarkan sistem yang digunakan saat ini dan cara system beroperasi, yang tepat untuk menggunakan alat atau teknik yang melayani tujuan ini.

Perlu diketahui bahwa deskripsi dari sistem cukup sederhana dan cukup jelas sehingga semua pembaca dokumen yang dimaksud dapat memahami sepenuhnya. Perlu diingat juga bahwa dokumen ConOps akan ditulis menggunakan user 'terminologi. Dalam kebanyakan kasus, hal ini berarti menghindari terminologi yang spesifik untuk komputer (misalnya, "jargon komputer").

Alat grafis harus sedapat mungkin digunakan, disebabkan karena ConOps dokumen harus dimengerti oleh beberapa jenis pembaca. Perangkat grafis yang berguna termasuk, namun tidak terbatas pada, pekerjaan struktur breakdown (WBS), N2 grafik, atau kegiatan urutan bagan, diagram blok aliran fungsional, struktur bagan, alokasi bagan, data flow diagram (DFD), diagram objek, diagram konteks, storyboard, dan entitas-hubungan diagram.

Deskripsi lingkungan operasional harus mengidentifikasi, sebagaimana berlakunya fasilitas peralatan computer (hardware, software) personalia, dan prosedur operasional yang digunakan untuk mengoperasikan sistem yang ada. Deskripsi ini harus sedetail yang diperlukan sehingga memberikan pembaca pemahaman kepada pembaca : angka mentega, versi, kapasitas, dll, dari peralatan operasional yang digunakan. Sebagai contoh, jika sistem yang sekarang berisi sebuah database, kapasitas unit penyimpanan (s) harus ditentukan, informasi yang diberikan memberikan pengaruh pada pengguna 'kemampuan operasional. Demikian juga, jika sistem komunikasi menggunakan link, kapasitas link tersebut harus dilengkapi jika mereka mempengaruhi faktor-faktor seperti kemampuan pengguna, waktu tanggap, atau throughput.

Aspek-aspek keselamatan, keamanan, dan privasi yang memberikan pengaruh pada pengoperasian atau lingkungan operasional sistem yang sekarang harus dijelaskan. Penulis (s) dari sebuah dokumen ConOps harus mengatur informasi dalam subclause ini yang sesuai dengan sistem atau situasi, selama uraian yang jelas tentang sistem yang ada akan tercapai. Jika

bagian dari deskripsi produktif, mereka dapat dimasukkan dalam lampiran atau didirikan oleh referensi. Contoh bahan yang mungkin akan dimasukkan dalam lampiran akan menjadi kamus data.

Contoh bahan yang akan dimasukkan oleh mungkin referensi manual rinci kebijakan operasional dan prosedur untuk sistem yang sekarang.

4.3.4. Model operasi untuk sistem yang sekarang atau situasi (3,4 dalam dokumen ConOps) Subclause ini menggambarkan berbagai modus operasi untuk sistem atau situasi saat ini (misalnya : operasional, rusak, pemeliharaan, pelatihan, darurat, alternatif-situs, masa damai, masa perang, tanah-based, penerbangan, aktif, dan idle mode)

Semua cara-cara yang berlaku untuk semua kelas pengguna harus dimasukkan. Penting menyertakan mode untuk yang mengalami degradasi, cadangan dan mode darurat, jika ada seperti itu. Hal ini terutama benar jika modus ini melibatkan situs geografis yang berbeda dan peralatan yang memiliki dampak signifikan pada aspek-aspek operasional dari sistem.

Subclause ini dapat dibagi lagi menjadi subclauses tingkat bawah, satu untuk setiap mode dijelaskan. Proses sistem, prosedur, dan kemampuan atau fungsi harus berkaitan dengan setiap mode, sebagaimana mestinya, mungkin menggunakan matriks referensi silang.

4.3.5. Pengguna kelas dan Terlibat lain personel (3,5 dari dokumen ConOps) Seorang pengguna kelas dibedakan oleh cara-cara di mana pengguna berinteraksi dengan sistem.

Faktor-faktor yang membedakan kelas pengguna termasuk tanggung jawab umum, tingkat keterampilan, aktivitas kerja, dan cara interaksi dengan sistem. Kelas-kelas pengguna yang berbeda mungkin telah berbeda skenario operasional untuk interaksi mereka dengan sistem.

Dalam konteks ini, pengguna adalah orang yang berinteraksi dengan sistem yang ada, termasuk operasional pengguna, entri data personalia, operator sistem, dukungan operasional personel, perangkat lunak pengelola, dan pelatih.

Subclause ini dapat diatur lebih lanjut, sebagai berikut, jika membantu dalam mengkomunikasikan konten.

4.3.5.1. Struktur Organisasi (3.5.1 dari dokumen ConOps)

Subclause ini menggambarkan struktur organisasi yang ada dari berbagai kelompok pengguna dan kelas pengguna yang terlibat dengan sistem yang sekarang. Bagan organisasi adalah alat grafis berguna untuk tujuan ini.

Subclause ini memberikan profil pengguna masing-masing kelas untuk sistem yang sekarang. Jika beberapa pengguna memainkan beberapa peran, peran masing-masing harus diidentifikasi sebagai pengguna terpisah kelas. Setiap user kelas untuk sistem saat ini, termasuk operator dan pengelola, harus dijelaskan dalam subclause terpisah. Masing-masing harus memberikan penjelasan mengenai kelas pengguna, termasuk tanggung jawab, pendidikan, latar belakang, tingkat keterampilan, kegiatan, dan cara interaksi dengan sistem yang sekarang.

4.3.5.2. Interaksi antara pengguna kelas (3.5.3 dari dokumen ConOps)

Subclause ini menjelaskan interaksi di antara berbagai kelas pengguna yang terlibat dengan sistem yang sekarang. Secara khusus, interaksi di antara kelompok pengguna, operator, dan pengelola harus dijelaskan. Interaksi yang terjadi di antara para pengguna sistem, dan antara pengguna dan non-pengguna, baik dalam organisasi dan melintasi batas-batas organisasi, jika memang relevan pengoperasian sistem yang ada, harus dijelaskan. Informal serta interaksi formal harus dimasukkan.

4.3.5.3. Terlibat Lainnya personel (3.5.4 dari dokumen ConOps)

Ini menggambarkan subclause personil yang lain tidak akan secara langsung berinteraksi dengan sistem, tetapi yang mempunyai pengaruh terhadap, dan busur dipengaruhi oleh, sistem sekarang. Contohnya termasuk eksekutif manajer, pembuat kebijakan, dan pengguna klien. Walaupun orang-orang ini tidak memiliki tangan-on interaksi dengan sistem, mereka dapat secara signifikan mempengaruhi, dan dipengaruhi oleh, yang baru atau diubah sistem.

4.3.6. Dukungan lingkungan (3,6 dari dokumen ConOps)

Subclause ini menggambarkan dukungan environmeni konsep dan dukungan untuk sistem saat ini, termasuk dukungan badan atau lembaga; fasilitas peralatan perangkat lunak pendukung; perbaikan atau penggantian kriteria tingkat dan siklus pemeliharaan dan penyimpanan, distribusi, dan metode pasokan.

4.4. Pembenaran untuk perubahan sifat (Pasal 4 dari dokumen ConOps)

Klausul 4 dari dokumen ConOps menggambarkan kelemahan dari sistem yang sekarang atau situasi yang memotivasi pengembangan sistem baru atau modifikasi sistem yang ada. Klausul ini memberikan sebuah transisi dari pasal 3 dari ConOps, yang menggambarkan sistem yang sekarang atau situasi, untuk Clause.5 dari ConOps, yang menggambarkan sistem yang diusulkan. Jika tidak ada sistem yang sekarang yang akan menjadi dasar perubahan, ini harus jadi subclause menunjukkan dan memberikan pembenaran untuk fitur dari sistem baru.

4.4.1. Pembenaran untuk perubahan (4.1 dari dokumen ConOps) Subclause ini harus:

a. Secara ringkas meringkas baru atau diubah aspek kebutuhan pengguna, misi, tujuan, lingkungan, interface, personalia,, atau faktor lain yang memerlukan sistem baru atau yang diubah;

b. Ringkaskan UV kekurangan atau keterbatasan dari sistem yang sekarang atau situasi yang membuatnya tidak mampu untuk merespon faktor-faktor baru atau yang diubah dan

c. Menyediakan pembenaran untuk sebuah sistem yang baru atau dimodifikasi. Jika sistem yang diusulkan untuk memenuhi peluang baru, menjelaskan

alasan mengapa sebuah sistem baru harus dikembangkan untuk memenuhi kesempatan ini.

Jika sistem yang diusulkan meningkatkan operasi arus, menjelaskan alasan di balik keputusan untuk mengubah sistem yang ada (misalnya, untuk mengurangi biaya-biaya siklus hidup atau meningkatkan efisiensi personil).

Jika sistem yang diusulkan menerapkan kemampuan fungsional baru, menjelaskan mengapa fungsi ini diperlukan.

4.4.2. Deskripsi perubahan yang diinginkan (4,2 dari dokumen ConOps)

Subclause ini merangkum baru atau diubah kemampuan, fungsi, proses, antarmuka, dan perubahan lain yang diperlukan untuk merespon faktor-faktor yang diidentifikasi dalam 4.1. Perubahan harus didasarkan pada sistem yang sekarang yang dijelaskan dalam Klausul 3 dari dokumen ConOps Jika tidak ada sistem yang ada sebagai dasar perubahan, ini harus meringkas subclause kemampuan untuk menjadi yang disediakan oleh sistem baru. Deskripsi ini harus mencakup berikut ini, yang sesuai: a. Kemampuan perubahan. Penjelasan tentang fungsi dan fitur yang akan

ditambahkan, dihapus, dan dimodifikasi agar yang baru atau diubah sistem untuk memenuhi tujuan dan persyaratan.

b. Sistem pengolahan perubahan. Deskripsi perubahan dalam proses Drocess atau mengubah data yang akan menghasilkan output yang baru dengan data yang sama, output yang sama dengan data baru, atau keduanya.

c. Interface perubahan. Deskripsi perubahan dalam sistem yang akan menyebabkan perubahan dalam antarmuka dan perubahan dalam antarmuka yang akan menyebabkan perubahan dalam sistem.

d. Personil perubahan. Deskripsi perubahan dalam personil yang disebabkan oleh persyaratan baru, perubahan dalam kelas pengguna, atau keduanya.

e. Lingkungan perubahan. Deskripsi perubahan dalam lingkungan operasional yang akan menyebabkan perubahan? dalam fungsi sistem, proses, interface, atau personil dan / atau perubahan yang harus dilakukan dalam lingkungan karena perubahan dalam fungsi sistem, proses, interface, atau personil.

f. Operasional perubahan. Deskripsi perubahan pada operasional pengguna kebijakan, prosedur, metode, atau rutinitas kerja sehari-hari disebabkan oleh perubahan di atas.

g. Membantu perubahan. Deskripsi perubahan dalam persyaratan dukungan yang disebabkan oleh perubahan dalam fungsi sistem, proses, interface, atau personil dan / atau perubahan fungsi sistem, proses, interface, atau personil yang disebabkan oleh perubahan dalam lingkungan dukungan.

h. Perubahan-perubahan lain. Deskripsi perubahan lain yang akan berdampak pada pengguna, tetapi yang tidak sesuai dalam salah satu kategori di atas.

4.4.3. Prioritas di antara perubahan (4.3 dari dokumen ConOps) Subclause ini mengidentifikasi prioritas di antara perubahan yang diinginkan dan fitur baru. Setiap perubahan harus diklasifikasikan sebagai penting, diinginkan, atau opsional. Diinginkan dan biaya opsional harus diprioritaskan dalam kelas mereka. Jika tidak ada sistem yang ada sebagai dasar perubahan, subclause ini harus mengelompokkan dan memprioritaskan fitur dari sistem yang diusulkan. A. Fitur penting. Fitur yang harus disediakan oleh sistem yang baru atau

diubah. Dampak yang akan dihasilkan jika fitur yang tidak dilaksanakan harus dijelaskan untuk setiap fitur penting.

B. Desirable fitur. Fitur yang harus disediakan oleh sistem yang baru atau dimodifikasi. Fitur diinginkan harus diprioritaskan. Alasan mengapa fitur deshable harus dijelaskan untuk setiap fitur yang diinginkan.

C. Opsional fitur. Fitur yang mungkin disediakan oleh sistem yang baru atau dimodifikasi. Fitur opsional harus diprioritaskan. Alasan mengapa fitur opsional harus dijelaskan untuk setiap fitur opsional. Mengklasifikasikan perubahan yang diinginkan dan fitur-fitur baru menjadi penting, diinginkan, dan opsional kategori adalah penting untuk membimbing proses

pengambilan keputusan selama pengembangan sistem yang diusulkan. Informasi ini juga membantu dalam kasus anggaran atau jadwal luka atau overruns, karena memungkinkan penentuan fitur yang harus diselesaikan, dan mana yang dapat ditunda atau dihilangkan.

4.4.4. Termasuk Perubahan tetapi tidak dianggap (4,4 dari dokumen ConOps) Subclause ini mengidentifikasi perubahan dan fitur-fitur baru dianggap tetapi tidak termasuk dalam 4,2 dari ConOps dokumen, dan alasan karena tidak termasuk mereka. Dengan menggambarkan perubahan dan fitur dianggap tetapi tidak termasuk dalam usulan sistem, penulis dokumen hasil kegiatan analisis mereka. Informasi ini dapat berguna untuk personil lain yang terlibat dengan pengembangan sistem, apakah itu pengguna, pembeli, atau pengembang harus mereka ingin tahu apakah tertentu.

KONSEP OPERASI (CONOPS) DOKUMEN IEEE Std 1362-1998 mengubah atau fitur dianggap, dan jika demikian, mengapa hal itu tidak termasuk. Dalam software khususnya, ada beberapa, jika ada, tanda-tanda luar dari apa yang telah diubah, diperbaiki atau masih tidak aman atau tidak aman (misalnya, dalam skenario tertentu atau workarounds).

4.4.5. Asumsi dan kendala (4,5 dari dokumen ConOps) Subclause ini menggambarkan asumsi atau batasan yang berlaku untuk perubahan dan fitur baru yang diidentifikasi dalam ketentuan ini. Ini harus mencakup semua asumsi dan kendala yang akan mempengaruhi pengguna selama pembangunan dan pengoperasian sistem baru atau diubah. Sebuah asumsi adalah suatu kondisi yang dianggap benar. Contoh dari asumsi adalah bahwa sistem akan melipatgandakan beban kerja selama dua tahun, sehingga sistem baru dengan kinerja yang lebih tinggi diperlukan. Sebuah kendala adalah pembatasan dikenakan eksternal ditempatkan di baru atau diubah sistem atau proses yang digunakan untuk mengembangkan atau memodifikasi sistem. Contoh kendala antarmuka eksternal meliputi persyaratan, dan batas-batas sesuai jadwal dan anggaran.

4.5. Konsep yang diusulkan untuk sistem (Pasal 5 dari dokumen ConOps) Klausul ini menggambarkan sistem yang diusulkan hasil dari perubahan yang diinginkan yang dijelaskan dalam Klausul 4 dari dokumen ConOps. Klausul ini menggambarkan sistem yang diusulkan pada cara tingkat tinggi, menunjukkan fitur operasional yang akan diberikan tanpa menentukan detil desain. Metode deskripsi yang akan digunakan dan tingkat detail dalam deskripsi akan tergantung pada situasi. Tingkat detail harus cukup

untuk sepenuhnya menjelaskan bagaimana sistem yang diusulkan dibayangkan untuk beroperasi dalam memenuhi kebutuhan pengguna dan kebutuhan pembeli. Dalam beberapa kasus, mungkin perlu untuk memberikan beberapa detail desain tingkat di ConOps. Yang tidak boleh mengandung ConOps spesifikasi desain, tetapi mungkin mengandung beberapa contoh strategi desain khas, untuk tujuan klarifikasi rincian operasional sistem yang diusulkan. Dalam hal desain sebenarnya kendala perlu dimasukkan dalam 'deskripsi sistem yang diusulkan, mereka harus secara eksplisit diidentifikasi sebagai diperlukan untuk menghindari kemungkinan kesalahpahaman. CATATAN - Jika beberapa fitur sistem yang diusulkan busur sama dengan ciri-ciri sistem yang asli, maka komentar "tidak berubah" akan muncul setelah nomor dan nama subclause. 4.5.1. Latar Belakang, tujuan, dan ruang lingkup (5.1 dari dokumen ConOps)

Subclause ini memberikan ikhtisar yang baru atau diubah sistem, termasuk, seperti yang berlaku, latar belakang, misi, tujuan, dan ruang lingkup. Selain menyediakan latar belakang untuk sistem yang diusulkan, subclause ini harus memberikan ringkasan singkat dari motivasi untuk sistem. Contoh motivasi untuk sistem otomatisasi dapat mencakup tugas-tugas tertentu atau pajak keuntungan dari peluang baru. Tujuan untuk sistem yang baru atau diubah juga harus didefinisikan, bersama-sama dengan strategi, solusi, taktik, metode, dan teknik yang diusulkan untuk mencapai tujuan tersebut. Modus operasi, kelas pengguna, dan interface ke lingkungan operasional menetapkan cakupan sistem yang diusulkan, yang dirangkum dalam subclause ini dan didefinisikan secara lebih rinci dalam subclauses berikutnya.

4.5.2. kebijakan dan kendala Operasional (5,2 dari dokumen ConOps) Subclause ini menggambarkan kebijakan operasional dan kendala yang berlaku untuk sistem yang diusulkan. Kebijakan operasional yang telah ditetapkan keputusan manajemen tentang pengoperasian sistem baru atau diubah, biasanya dalam bentuk pernyataan umum atau pemahaman yang membimbing kegiatan pengambilan keputusan. Kebijakan pengambilan keputusan membatasi kebebasan, tapi jangan biarkan untuk beberapa kebijaksanaan. Operasional kendala keterbatasan ditempatkan pada operasi sistem yang diusulkan. Contoh kendala operasional meliputi:

Sebuah kendala pada jam operasi dari sistem, mungkin dibatasi oleh akses untuk mengamankan terminal;

Sebuah kendala membatasi jumlah personil yang tersedia untuk mengoperasikan sistem;

Sebuah membatasi kendala pada perangkat keras komputer (misalnya, harus beroperasi di komputer X); dan

Sebuah membatasi kendala operasional pada fasilitas, seperti ruang kantor.Deskripsi sistem yang diusulkan (5,3 dari dokumen ConOps) Subclause ini akan berisi bagian utama dari deskripsi sistem yang diusulkan. Ini memberikan gambaran mengenai sistem yang diusulkan, termasuk yang berikut, yang sesuai: a. lingkungan operasional dan karakteristiknya; b. komponen sistem utama dan saling keterkaitan antara komponen-

komponen ini; c. Penghubung ke sistem eksternal atau prosedur; d. Kemampuan atau fungsi-fungsi dari sistem yang diusulkan; e. Grafik dan deskripsi yang menyertainya menggambarkan input, output,

data flow, dan proses manual dan otomatis cukup untuk memahami sistem yang diusulkan atau situasi dari pengguna sudut pandang;

f. Biaya operasi syste.ns; g. faktor-faktor risiko operasional; h. Kinerja karakteristik, seperti kecepatan, throughput, volume, frekuensi;i. Kualitas atribut, seperti: keandalan, ketersediaan, ketepatan, efisiensi,

upgrade, fleksibilitas, interoperabilitas, Kemampu-rawatan, portabilitas, usabilitas, supportability, survivability, dan kegunaan, dan

j. Ketentuan selama keselamatan, keamanan, privasi, integritas, dan kesinambungan operasi dalam keadaan darurat.

Karena tujuan subclause ini adalah untuk menggambarkan sistem yang diusulkan dan bagaimana harus beroperasi, itu yang tepat untuk menggunakan alat dan / atau teknik yang melayani tujuan itu. Adalah penting bahwa deskripsi dari sistem cukup sederhana dan cukup jelas bahwa semua pembaca dimaksud dokumen dapat sepenuhnya memahaminya. Penting untuk diingat bahwa akan ConOps ditulis dalam bahasa pengguna. Dalam kebanyakan kasus, hal ini berarti menghindari terminologi yang spesifik untuk komputer-dengan kata lain, "jargon komputer." Grafik dan gambar-gambar alat-alat harus digunakan sedapat mungkin, terutama karena ConOps dokumen harus dimengerti menjadi beberapa jenis pembaca.

Perangkat grafis yang berguna termasuk, namun tidak terbatas pada, WBS, diagram N2, urutan atau kegiatan bagan, diagram blok aliran fungsional, struktur bagan, alokasi bagan, DFDs, objek diagram, storyboard, dan diagram hubungan entitas.

Deskripsi lingkungan operasional harus mengidentifikasi, sebagaimana berlaku, fasilitas, peralatan, komputer hardware, software, personalia, dan

prosedur operasional yang dibutuhkan untuk mengoperasikan sistem yang diusulkan. Deskripsi ini harus sedetail yang diperlukan untuk memberikan pembaca pemahaman mengenai angka, versi, kapasitas, dll, dari peralatan operasional yang akan digunakan. Sebagai contoh, jika sistem yang diusulkan berisi database, kapasitas unit penyimpanan harus dilengkapi, asalkan informasi mempengaruhi pengguna kemampuan operasional. Demikian juga, jika sistem komunikasi menggunakan link, maka kapasitas link tersebut harus dilengkapi jika mereka menggunakan pengaruh pada kemampuan pengguna atau waktu respon. Aspek-aspek keselamatan, keamanan, dan privasi yang memberikan pengaruh pada lingkungan operasi atau operasional dari sistem yang diusulkan harus dijelaskan. Penulis (s) dari sebuah dokumen ConOps harus mengatur informasi dalam subclause ini yang sesuai dengan sistem atau situasi, selama uraian yang jelas tentang sistem yang diusulkan akan tercapai. Jika bagian dari deskripsi yang produktif, mereka dapat dimasukkan dalam lampiran atau didirikan oleh referensi. Contoh bahan yang mungkin akan dimasukkan ke dalam appendi .. akan menjadi kamus data. Contoh bahan yang akan dimasukkan oleh mungkin referensi rinci operasi manual kebijakan dan prosedur untuk sistem yang diusulkan.

4.5.3. Model operasi (5,4 dari dokumen ConOps) Subclause ini menggambarkan berbagai modus operasi untuk mengusulkan sistem (misalnya, biasa, rusak, pemeliharaan, pelatihan, darurat, alternatif-situs, masa damai, masa perang, tanah-based, (cahaya, aktif, dan idle mode). Sertakan semua mode yang berlaku untuk semua kelas pengguna. Penting mode untuk memasukkan yang mengalami degradasi, cadangan, dan mode darurat, jika ada seperti Ini terutama berlaku jika modus ini melibatkan situs-situs geografis yang berbeda dan peralatan yang memiliki dampak signifikan pada sistem. Subclause ini dapat dibagi lagi menjadi subclauses tingkat bawah, satu untuk setiap mode dijelaskan. Proses sistem, prosedur, dan kemampuan atau fungsi harus berkaitan dengan setiap mode.

4.5.4. Pengguna kelas dan personel lain yang Terlibat (5.5 dari dokumen ConOps) Seorang pengguna kelas dibedakan oleh cara-cara di mana pengguna berinteraksi dengan sistem. Faktor-faktor yang membedakan kelas pengguna termasuk tanggung jawab, tingkat keterampilan, aktivitas kerja, dan cara interaksi dengan sistem. Kelas-kelas pengguna yang berbeda mungkin telah berbeda skenario operasional untuk interaksi mereka dengan sistem. Dalam konteks ini, pengguna adalah siapa pun, yang akan berinteraksi dengan sistem yang diusulkan, termasuk operasional pengguna, entri data personalia, operator sistem, dukungan operasional personel, perangkat lunak pengelola, dan pelatih.

Subclause ini dapat dibagi lagi menjadi tingkat rendah subclauses jika membantu dalam berkomunikasi konten.

4.5.5.1 Struktur Organisasi (5.5.1 dari dokumen ConOps) subclause ini menggambarkan struktur organisasi dari berbagai kelompok pengguna dan pengguna kelas yang akan terlibat dengan sistem yang diusulkan. Bagan organisasi adalah alat grafis berguna untuk tujuan ini.

4.5.5.2 Profil pengguna kelas (5.5.2 dari dokumen ConOps) Subclause ini menyediakan profil pengguna masing-masing kelas untuk sistem yang diusulkan. Jika beberapa pengguna memainkan beberapa peran, peran masing-masing harus diidentifikasi sebagai pengguna terpisah kelas. Setiap user kelas untuk sistem yang diusulkan, termasuk operator dan pengelola, harus dijelaskan dalam subclause terpisah. Setiap subclause harus memberikan penjelasan mengenai kelas pengguna, termasuk responsibi'ities, pendidikan, latar belakang, tingkat keterampilan, kegiatan, dan membayangkan cara-cara interaksi dengan sistem yang diusulkan.

4.5.5.3. Interaksi antara pengguna 4.5.5.3 kelas (5.5.3 dari dokumen ConOps) Subclause ini menjelaskan interaksi di antara berbagai kelas pengguna yang mungkin terlibat dengan sistem yang diusulkan. Secara khusus, interaksi di antara kelompok pengguna, operator, dan pengelola harus dijelaskan. Interaksi yang akan terjadi di antara para pengguna sistem yang diusulkan, dan antara pengguna dan non-pengguna, baik dalam organisasi dan seluruh organisasi interfacing, jika memang relevan pengoperasian sistem yang diusulkan, harus dijelaskan. Informal serta interaksi formal harus dimasukkan.

4.5.5.4 Terlibat Lainnya personel (5.5.4 dari dokumen ConOps) Ini menggambarkan subclause personil yang lain tidak akan secara langsung berinteraksi dengan sistem, tetapi yang mempunyai pengaruh terhadap, dan dipengaruhi oleh sistem yang ada sekarang. Contohnya termasuk eksekutif manajer, pembuat kebijakan, dan pengguna klien. Walaupun orang-orang ini tidak memiliki tangan-on interaksi dengan sistem, mereka dapat secara signifikan mempengaruhi dan dipengaruhi oleh, yang baru atau diubah sistem.

4.5.6 Dukungan lingkungan (5,6 dari dokumen ConOps)

Subclause ini menjelaskan konsep-konsep dukungan dan dukungan lingkungan untuk sistem yang diusulkan, termasuk dukungan badan atau lembaga; fasilitas peralatan perangkat lunak pendukung; perbaikan atau penggantian kriteria tingkat dan siklus pemeliharaan dan penyimpanan, distribusi, dan metode pasokan.

4.6. Scenario Operasional (Pasal 6 dari dokumen ConOps)

Sebuah skenario adalah langkah-demi-langkah deskripsi bagaimana sistem yang diusulkan harus beroperasi dan berinteraksi dengan para pengguna dan antarmuka eksternal di bawah keadaan himpunan. Skenario harus dijelaskan dengan cara yang akan memungkinkan para pembaca untuk berjalan melalui mereka dan mendapatkan di. pemahaman tentang bagaimana semua berbagai bagian dari sistem yang diusulkan fungsi dan berinteraksi.

Skenario mengikat bersama semua bagian dari sistem, pengguna, dan entitas lain dengan menjelaskan bagaimana mereka berinteraksi. Skenario juga dapat digunakan untuk menggambarkan sistem apa yang tidak boleh dilakukan.

Skenario harus diatur dalam pasal dan subclauses, masing-masing menggambarkan urutan operasional yang menggambarkan peranan dari sistem, maka interaksi dengan pengguna, dan interaksi dengan sistem lain.

Skenario operasional harus dijelaskan untuk semua mode operasional dan semua kelas pengguna diidentifikasi untuk sistem yang diusulkan. Setiap skenario harus mencakup peristiwa, tindakan, rangsangan, informasi, dan interaksi yang sesuai untuk memberikan pemahaman yang komprehensif tentang aspek-aspek operasional dari sistem yang diusulkan. Prototipe, storyboard, dan media lainnya, seperti video atau hypermedia presentasi, dapat digunakan untuk menyediakan sebagian informasi ini. Dalam kebanyakan kasus, akan diperlukan untuk mengembangkan beberapa variasi dari setiap skenario, termasuk satu untuk operasi normal, satu untuk menangani beban stres, satu untuk penanganan pengecualian, satu untuk operasi mode degradasi, dll Skenario memainkan beberapa peran penting. Yang pertama adalah untuk mengikat bersama semua panci individua1 suatu sistem menjadi dipahami secara keseluruhan. Skenario juga dapat membantu para pembaca sebuah dokumen ConOps memahami bagaimana semua bagian berinteraksi untuk menyediakan kemampuan operasional. Cf peran kedua skenario adalah untuk menyediakan pembaca dengan rincian untuk operasional sistem yang diusulkan; ini memungkinkan mereka untuk memahami pengguna peran, bagaimana sistem harus beroperasi, dan berbagai fitur operasional harus disediakan. Skenario juga dapat mendukung pengembangan model simulasi yang membantu dalam definisi dan alokasi yang diperoleh persyaratan, identifikasi, dan persiapan prototipe untuk mengatasi isu-isu kunci. Selain itu, skenario dapat digunakan sebagai dasar untuk mati rancangan pertama pengguna manual, dan sebagai dasar untuk pengembangan rencana uji penerimaan. Skenario yang juga berguna bagi pembeli dan pengembang untuk memverifikasi bahwa sistem desain akan memenuhi kebutuhan pengguna dan harapan. Skenario dapat disajikan dalam beberapa cara berbeda. Satu pendekatan adalah untuk menentukan skenario untuk masing-masing fungsi pemrosesan utama dari sistem yang diusulkan. Dengan menggunakan pendekatan ini, klausul ini akan

berisi satu subclause untuk setiap proses. Setiap subclause kemudian akan berisi beberapa tingkat lebih rendah subclauses, satu untuk setiap skenario yang didukung oleh proses itu. Pendekatan alternatif adalah untuk mengembangkan skenario berbasis thread, dimana setiap skenario berikut satu jenis tipe transaksi melalui sistem yang diusulkan. Dalam kasus ini, masing-masing subclause akan berisi satu skenario untuk tiap jenis interaksi, ditambah skenario untuk mengalami degradasi, stres dimuat, dan back-up modus operasi. Alternatif lain termasuk mengikuti arus informasi melalui sistem untuk setiap pengguna kemampuan, mengikuti aliran kontrol, atau berfokus pada objek-objek dan peristiwa-peristiwa dalam sistem.

Skenario adalah komponen penting dari suatu ConOps, dan karenanya harus menerima penekanan substansial. Jumlah skenario dan level detail yang ditentukan akan sebanding dengan risiko yang dirasakan dan kritis proyek.

4.7. Dampak Ringkasan (Pasal 7 dari dokumen ConOps) Klausul ini menjelaskan tentang dampak operasional sistem yang diusulkan pada pengguna, para pengembang, dan dukungan pemeliharaan organisasi. Ini juga menggambarkan dampak sementara pengguna, pembeli, pengembang, dan dukungan dan pemeliharaan organisasi selama periode waktu ketika sistem baru sedang dikembangkan, diinstal, atau dilatih. Informasi ini disediakan untuk membolehkan semua organisasi terpengaruh untuk mempersiapkan perubahan-perubahan yang akan ditimbulkan oleh sistem baru dan untuk memungkinkan perencanaan pembeli dampak pada badan atau lembaga, kelompok pengguna, dan dukungan organisasi pemeliharaan selama pengembangan, dan transisi ke sistem baru.

4.7.1 Dampak Operasional (7.1 ConOps dokumen)

Subclause ini harus dibagi lagi menjadi tingkat rendah untuk menggambarkan subclauses mengantisipasi dampak operasional di USI r, pengembangan, dan dukungan atau badan atau lembaga pemeliharaan selama pengoperasian sistem yang diusulkan.

Dampak tersebut dapat mencakup sebagai berikut:

Interface dengan alternatif primer atau pusat operasi komputer; Perubahan dalam prosedur; Penggunaan sumber-sumber data baru; Perubahan dalam jumlah, jenis, dan waktu data yang akan masukan ke

dalam sistem; Perubahan dalam persyaratan penyimpanan data; New modus operasi berdasarkan keadaan darurat, bencana, atau kondisi

kecelakaan;

New metode untuk memberikan masukan data jika data yang dibutuhkan tidak tersedia;

Perubahan dalam anggaran operasional dan Perubahan dalam risiko operasional.

4.7.2. Dampak Organisasi (7,2 dari dokumen ConOps) Subclause ini harus dibagi lagi menjadi tingkat rendah untuk menggambarkan subclauses mengantisipasi dampak operasional pada pengguna, pengembangan, dan dukungan atau badan atau lembaga pemeliharaan selama pengoperasian sistem yang diusulkan. Dampak tersebut dapat mencakup sebagai berikut:

Modifikasi tanggung jawab; tanggung jawab; Penambahan atau penghapusan posisi pekerjaan; posisi; Training atau pelatihan ulang pengguna; pengguna; Perubahan dalam angka, tingkat keterampilan, posisi pengidentifikasi,

atau lokasi personil; personil dan Bilangan dan tingkat kemampuan personil yang diperlukan untuk operasi

kontingensi pada satu atau lebih alternatif situs berikut keadaan darurat, bencana, atau kecelakaan.

4.7.3. Dampak selama perkembangan (7.3 dari dokumen ConOps) Subclause ini harus dibagi lagi menjadi subclauses tingkat rendah yang menggambarkan mengantisipasi dampak pada pengguna, pengembangan, dan dukungan atau badan atau lembaga pemeliharaan selama proyek pengembangan sistem yang diusulkan. Dampak tersebut dapat mencakup sebagai berikut:

Keterlibatan dalam studi, rapat, dan diskusi sebelum penghargaan dari kontrak;

User dan dukungan keterlibatan dalam tinjauan dan demonstrasi, evaluasi kemampuan operasional awal dan berkembang versi sistem, pengembangan atau modifikasi dari database, dan pelatihan yang dibutuhkan;

Paralel pengoperasian sistem baru dan yang sudah ada dan Dampak operasional sistem selama pengujian sistem yang diusulkan.

4.8. Analisis sistem yang diusulkan (Klausul 8 atau dokumen yang ConOps) Klausul ini memberikan analisis manfaat, keterbatasan, keuntungan, kerugian, dan alternatif dan perdagangan-offs dipertimbangkan untuk sistem yang diusulkan.4.8.1. Ringkasan perbaikan (8,1 dari dokumen ConOps)

Subclause ini menyediakan kualitatif (dan sejauh mungkin, kuantitatif) ringkasan manfaat yang dapat diberikan oleh sistem yang diusulkan. Ringkasan ini harus mencakup barang-barang di bawah ini, sebagaimana berlaku. Dalam setiap kasus,

manfaat harus berkaitan dengan kekurangan-kekurangan yang diidentifikasi dalam.

New kemampuan. Tambahan fitur atau fungsi baru. Peningkatan kemampuan. Upgrade ke kemampuan yang ada. Dihapus kemampuan. Tidak terpakai, usang, membingungkan, atau

kemampuan berbahaya dihapus. Peningkatan kinerja. Waktu respons yang lebih baik, mengurangi

persyaratan penyimpanan, peningkatan mutu, dll 4.8.2. Kekurangan dan keterbatasan (8,2 dari dokumen ConOps)

Subclause ini menyediakan kualitatif (dan sejauh mungkin, kuantitatif) ringkasan dari kerugian dan / atau keterbatasan dari sistem yang diusulkan. Kekurangan mungkin termasuk kebutuhan untuk melatih personel, mengatur ulang ruang kerja, atau perubahan ke gaya baru antarmuka pengguna; keterbatasan mungkin mencakup fitur yang diinginkan oleh pengguna tetapi tidak termasuk, degradasi kemampuan yang ada untuk mendapatkan kemampuan baru, atau lebih besar-daripada-respon yang diinginkan waktu untuk operasi kompleks tertentu.

4.8.3. Alternatif dan trade-off dianggap (8,3 dari dokumen ConOps) Subclause ini harus menjelaskan alternatif utama dipertimbangkan, trade-off di antara mereka, dan alasan bagi keputusan tercapai. Dalam konteks dokumen ConOps, alternatif yang operasional alternatif dan bukan desain alternatif, kecuali sejauh bahwa alternatif desain mungkin dibatasi oleh kemampuan operasional yang diinginkan dalam sistem baru. Infonnation ini dapat bermanfaat untuk menentukan, sekarang dan di kemudian hari, apakah pendekatan tertentu dianalisis dan dievaluasi, atau mengapa suatu solusi pendekatan atau ditolak. Informasi ini mungkin akan hilang jika tidak tercatat.

4.9. Catatan (Pasal 9 di dokumen ConOps) Klausul ini harus berisi informasi tambahan yang akan membantu pemahaman tentang dokumen ConOps tertentu. Klausul ini harus mencakup suatu urutan sesuai abjad dari semua akronim dan singkatan, bersama dengan maknanya sebagaimana digunakan dalam dokumen ini, dan daftar istilah dan definisi apapun yang diperlukan untuk memahami dokumen.

4.10. Lampiran (Lampiran dari dokumen ConOps) Untuk memfasilitasi kemudahan penggunaan dan pemeliharaan dokumen ConOps, beberapa informasi mungkin ditempatkan dalam lampiran dokumen. Grafik dan data diklasifikasikan contoh khas. Setiap lampiran harus dirujuk dalam tubuh utama dari dokumen di mana informasi yang biasanya telah disediakan. Lampiran dapat terikat sebagai dokumen terpisah untuk penanganan lebih mudah.

4.11. Kamus (Istilah dari dokumen ConOps)

Penyertaan yang jelas dan ringkas tentang definisi istilah yang digunakan dalam dokumen ConOps (terutama untuk pembaca dokumen ConOps yang mungkin belum terbiasa) sangat penting. Seorang glossary harus dipelihara dan diperbarui selama proses analisis dan konsep pengembangan dokumen ConOps. Untuk menghindari pekerjaan yang tidak perlu akibat salah tafsir, semua definisi harus ditinjau ulang dan disepakati oleh semua pihak yang terlibat.

Lampiran A

IEEE / EIA 12.207,1-1.997 Compliance Statement (Informatif) A.1 Overview

Rekayasa Perangkat Lunak Standards Committee (SESC) dari IEEE Computer Society telah mendukung kebijakan mengadopsi standar internasional. Pada tahun 1995, standar internasional, 1SO/IEC 12.207, teknologi informasi-Software siklus hidup proses, selesai. Menetapkan standar kerangka umum untuk proses siklus hidup perangkat lunak, dengan terminologi yang terdefinisi dengan baik, yang dapat direferensikan oleh industri perangkat lunak. Pada tahun 1995 dievaluasi SESC ISO / IEC 12207 dan memutuskan bahwa standar harus diadopsi dan digunakan sebagai dasar untuk proses siklus kehidupan dalam IEEE Software Engineering Collection. IEEE adaptasi dari ISO / IEC 12207 adalah IEEE / EIA 12.207,0-1.996. Berisi ISO / IEC 12.207 dan tambahan berikut: meningkatkan pendekatan kepatuhan, proses siklus hidup tujuan, tujuan data siklus hidup, dan errata. Implementasi ISO / IEC 12.207 dalam IEEE juga mencakup sebagai berikut:

IEEE / EIA 12.207,1-1.997, IEEE / EIA Panduan untuk Teknologi Informasi-Software siklus hidup Siklus hidup proses-data;

IEEE / EIA 12.207,2-1.997, IEEE / EIA Panduan untuk Teknologi Informasi-Software siklus hidup-Pelaksanaan proses pertimbangan dan

Penambahan sampai 11 SESC standar yang ada (yakni, Stds IEEE 730, 828, 829, 830, 1012, 1016, 1058, 1062,1219, 1233, dan 1362) untuk menentukan korelasi antara data yang dihasilkan oleh SESC ada standar dan data dihasilkan oleh penerapan IEEE / EIA 12.207,1-1.997.

CATATAN

Meskipun IEEE / EIA 12.207,1-1.997 adalah panduan, juga mengandung ketentuan untuk aplikasi sebagai standar sesuai dengan persyaratan tertentu. Lampiran ini memperlakukan IEEE / EIA 12.207,1-1.997 sebagai standar. Untuk mencapai sesuai dengan kedua standar ini dan IEEE / EIA 12207,1 -1997, adalah penting bahwa pengguna meninjau dan memenuhi persyaratan data untuk kedua standar. Ketika standar ini secara langsung direferensikan, yang Urutan untuk kesesuaian didasarkan pada standar ini sendirian. Ketika standar ini adalah direferensikan dengan IEEE / EIA standar 12207.x seri, yang Urutan untuk kesesuaian didasarkan atas direferensikan langsung IEEE / EIA standar 12207.x, kecuali ada pernyataan bahwa standar ini telah diutamakan.

A.1.1 Ruang Lingkup dan tujuan

Kedua standar ini dan IEEE / EIA tempat 12207,1 -1997 persyaratan pada dokumen ConOps. Tujuan dari lampiran ini adalah untuk menjelaskan hubungan antara dua set persyaratan, sehingga pengguna akan menghasilkan dokumen yang dimaksudkan untuk memenuhi kedua standar dapat melakukannya.

A.2 Korelasi

Klausul ini menjelaskan hubungan antara standar ini dan IEEE/E1A 12.207,0-1.996 di bidang-bidang berikut: terminologi, proses, dan siklus hidup data.

A.2.1 Terminologi korelasi

Kedua standar ini dan lEEE / EIA 12.207,0-1.996 memiliki semantik yang sama untuk tenns kunci perubahan, kendala, lingkungan, modus operasi, kebijakan, dan sistem.

A.2.2 Proses korelasi

Standar ini tidak ada persyaratan pada tempat-tempat proses.

A.2.3 Hidup data siklus konsep korelasi dan operasi dokumen Informasi yang diperlukan dalam sebuah dokumen ConOps standar ini dan informasi yang diperlukan dalam sebuah dokumen ConOps oleh IEEE / EIA 12.207,1-1.997 serupa. Masuk akal untuk mengharapkan bahwa dokumen tunggal dapat memenuhi kedua standar. Kedua dokumen menggunakan konteks yang berorientasi proses untuk menggambarkan isi dari dokumen ConOps.

A.2.4 Siklus hidup korelasi antara lain data data Pada IEEE / EIA 12.207,1-1.997 dan standar ini Ini berkorelasi sublause data siklus kehidupan selain dokumen antara ConOps IEEE / EIA 12.207,1-1.997 dan standar ini. Memberikan informasi kepada pengguna dari kedua standar. Tabel A-1-Llfe data siklus korelasi antara lain data Pada lEEE / EIA 12.207,1-1.997 dan IEEE Std 1362-1998 Informasi item IEEE / EIA 12.207,0-1.996 Jenis subclause IEEE / EIA 12.207,1-1.997 subclause lEEEStd 1362-1998 subclause Arsitektur sistem alokasi dan persyaratan deskripsi 5.3.3.1.5.3.3.2 Keterangan 6,25 4.5.3 Dokumen kepatuhan Klausul ini memberikan rincian berpengaruh pada klaim bahwa dokumen ConOps sesuai dengan standar ini juga akan mencapai "dokumen kepatuhan" dengan "dokumen ConOps dijelaskan dalam IEEE / EIA 12207,1 -1997. Persyaratan untuk dokumen kepatuhan dirangkum dalam satu baris dari Tabel 1 dari IEEE / EIA 12.207,1-1.997. Baris yang direproduksi dalam Tabel A.2.

Tujuan dari deskripsi adalah: IEEE / EIA 12.207,1-1.997, subclause 5.1.1: Tujuan: Jelaskan yang direncanakan atau fungsi yang sebenarnya, desain, kinerja, atau proses. Sebuah dokumen ConOps sesuai dengan standar ini akan mencapai tujuan yang disebutkan. Deskripsi apapun sesuai dengan IEEE / EIA 12.207,1-1.997 harus memenuhi persyaratan konten generik 5.1.2 diberikan dalam standar itu. Tabel A.3 standar ini daftar konten generik item dan, dimana tepat, referensi yang subclause standar ini yang memerlukan informasi yang sama. Kolom ketiga berisi informasi yang akan ditambahkan dalam rangka untuk memenuhi persyaratan konten generik.