## JURNAL TEKNIK INFORMATIKA
Halaman Jurnal: http://jurnal.stmik-dci.ac.id/index.php/jutekin/ Halaman LPPM STMIK DCI : http://lppm.stmik-dci.ac.id/
62

## ANALISIS DAN PERANCANGAN PROTOTIPE PENGELOLAAN DOKUMEN UNTUK MENDUKUNG MANAJEMEN KONFIGURASI PERANGKAT LUNAK

## Sanyata Purwidayanta
Jurusan Teknik Informatika, STMIK DCI Email : purwidayanta@gmail.com

## ABSTRAK
Pada  penelitian  ini  dikembangkan  analisis  kebutuhan  dan  perancangan prototipe  perangkat  lunak  bantu  pengelolaan  dokumen  untuk  mendukung manajemen  konfigurasi  perangkat  lunak  (MKPL)  yang  dinamakan  DocCon (Document  Control).  Sudut  pandang  pengelolaan  dokumen  oleh  DocCon  adalah dokumen perangkat lunak dipandang sebagai individu dan/atau sebagai kumpulan dokumen,  relatif  terhadap  pekerjaan  tim  pengembang  (development)  perangkat lunak  dalam  suatu  proyek.  Konsep  kumpulan  dokumen  disebut  baseline. Perubahan  baseline  dilindungi  oleh  otoritas  akses  yang  disebut  pimpinan konfigurasi perangkat lunak.
Prinsip  dasar  mekanisme  pengelolaan  dengan  DocCon  ada  dua  macam. Pertama, DocCon akan membuat hubungan representasi fisik dengan tabel informasi yang  mendeskripsikan  tentang  dokumen  dan  baseline.    Kedua,  DocCon  mengelola kejadian (event) terhadap dokumen dan/atau baseline dengan memanfaatkan tabel informasi tersebut. Dalam penelitian ini, kejadian yang dapat diidentifikasi sebanyak sebelas  macam,  yaitu  inisialisasi  proyek  baru,  check-in,  check-out,  penyetoran dokumen,  peningkatan  versi  dokumen,  peningkatan  versi  baseline,  penghapusan dokumen,  penghapusan  baseline,  penambahan  item  konfigurasi,  penjagaan integritas tabel informasi, dan penutupan proyek. DocCon akan mengelola kejadian- kejadian  tersebut  dalam  suatu  mekanisme  yang  memungkinkan  pengoperasian secara otomatis. Dengan demikian, aktivitas manajemen konfigurasi dapat didukung dengan baik.
DocCon  diimplementasikan  dengan  platform  sistem  operasi  berbasis windows.  Dokumen  individu  direpresentasikan  sebagai  sebuah  file,  dan  dokumen baseline direpresentasikan sebagai sebuah subdirektori.
Kata  kunci  :  Manajemen  konfigurasi  perangkat  lunak  (MKPL),  proyek,  dokumen, baseline, versi, sebelas kejadian terhadap  dokumen.

## I. PENDAHULUAN
Hakekat  utama  hasil  produk
pengembangan perangkat lunak
adalah  sekumpulan  dokumen  yang mendefinisikan  perangkat    lunak
tersebut. Kompleksitas dokumen yang timbul berkaitan siklus hidup pengembangan perangkat lunak adalah  integritas  dokumen  harus tetap  terjamin  meskipun  diakses  oleh banyak  pengguna  (tim  pengembang). Di  sisi  lain,  perangkat  lunak  dituntut harus dapat memberi jaminan kualitas terhadap  integritas  produknya.  Salah satu  tuntutan  kualitasnya  adalah kelengkapan
dokumen
dan kesempurnaan  prosesnya,  sehingga perubahan dari waktu ke waktu harus dikelola dengan baik.
Oskarson  Ostein  dan  Robert  L Glass  [Osten  96]  memberikan  contoh masalah  yang  sering  muncul  akibat dokumen tidak terkontrol yaitu :
(1) Seseorang  memakai  dokumen  yang seharusnya  sesuai  tetapi  tidak  tepat atau keliru;
(2) Seseorang  menggunakan  dokumen spesifiaksi  atau  perencanaan  dengan versi yang salah;
(3) Ditemukan dua buah dokumen dengan identitas  dan  versi  yang  sama  tetapi isinya berbeda;
(4) Seseorang  memakai  dokumen  tidak dapat  menjelaskan  bagaimana  ia  tahu dokumen  tersebut  adalah  versi  yang benar;
(5) Seseorang  membutuhkan  dokumen untuk  keperluan  pekerjaannya,  tetapi tidak  memiliki  kemudahan  akses terhadap dokumen tersebut. Humphery {Humphrey 89]
memberikan  contoh  masalah  tentan konflik  yang  terjadi  apabila  dokumen tidak terkontrol, yaitu :
(1) Pengubahan bersama, ketika dua atau lebih  pemrogram  yang  bekerja  secara terpisah  pada  dokumen  yang  sama maka  apabila  seorang  membuat perubahan  akan  menganggu  atau merusak pekerjaan pemrogram lain;
(2) Kode  yang  terbagi,  ketika  kesalahan diperbaiki  oleh  beberapa  pemrogram,
sebagian tidak mencatatkan perbaikan-nya  sehingga  pemrogram lain  bingung  dan  frustrasi  pada kesalahan yang muncul pada pekerjaannya  dan  membuat  lama waktu pengembangan;
(3) Kode umum, dalam sistem yang besar ketika fungsi kode umum diubah maka seluruh  pemakai  kode  tersebut  harus mengetahuinya.  Tanpa  manajemen maka pengontrolan distribusi terhadap perubahan tesebut adalah sulit;
(4) Versi, banyak program besar
dikembangkan  dengan  evolusi  versi yang  berlainan.  Evolusi  versi  dapat terjadi  kesalahan  (kebutuhan  baru) yang  ditemukan  oleh  pemakai  atau oleh  pengembang  sendiri.  Tanpa manajemen  versi  maka  kesalahan- kesalahan sering muncul tidak terkendali.
Tujuan  penelitian  ini  adalah melakukan  analisis  kebutuhan  dan perancangan  prototipe  pengelolaan dokumen  untuk  mendukung  MKPL dalam aktivitas proyek.

## II. LANDASAN TEORI
2.1

## Pengantar
Selama  siklus  hidup  proyek, dokumen-dokumen mengalami
evolusi  atau  perubahan  baik  secara individu (file) maupun secara bersama (baseline).    Proses  evolusi  terus berlangsung  dan  berenti  sampai proyek berkahir (closing project).
Sebuah  dokumen  secara  individu dikenali  denan  identitas  nama  dan versi.
Evolusi pada dokumen ditunjukkan oleh perubahan isi
maupun perubahan versi. Penggunaan dokumen  secara  umum  adalah  untuk dibaca,  diperiksa,  diubah,  diuji,  atau dikonsultasikan. Hal ini bisa menyebabkan  isi  dokumen  berubah atau tidak berubah. Baseline adalah konsep
mendefiniskan  sekumpulan  dokumen resmi  yang  digunakan  sebagai  acuan dasar  (dokumen  referensi)  terhadap proses perubahan atau evolusi sekumpulan dokumen
tersebut.
Pengertian  dokumen  resmi  adalah sekumpulan  dokumen  yan  terlindungi oleh otoritas akses tertentu, dalam hal ini  dilakukan  oleh  pimpinan  atau  tim MKPL.  Sebuah  dokumen  didalam baseline  merepresentasikan  satu  item konfigurasi
perangkat lunak [Humphrey 89]. 2.2 Jenis Dokumen Dalam Baseline
Paradigma pengembangan
perangkat  lunak  mengenal  jenis dokumen  dalam  baseline,  namum belum  memiliki  penamaan  standar yang berlaku
umum. Untuk memberikan  gambaran  yang  lebih representatif tentang penamaan
dokumen tersebut, maka akan diberikan  tiga  contoh  jenis  dokumen dan sumbernya.
(1) Orkason  Osten  [Osten  96]  bahwa jenis-jenis dokumen menurut ISO 9000 meliputi:  a)  Spe-sifikasi  kebutuhan;  b) Desain;  c)  Perencanaan;  d)  File  source code;  e)  Prosedur  kerja;  f)  Standar internal dan eksternal.
(2) Pressman  [Pressman  92]  menetapkan jenis dokumen sebagai item
konfigurasi  dalam  baseline  meliputi  :
a)  System  Requirement;  b)  Software
Project  Plan;  c)  Software  Requirement
Specification;  d)  Preliminary  User
Manual;  e)  Design  Specification;  f)
Source Code Listing; g)  Test  Plan  and  Procedure;  h)  Test Case  and  Records  Result;  i)  Katalog Program;  j)  Deskripsi  Basis  Data;  k) Manual pema-kai yang siap diterbitkan;  l)  Dokumen  Perawatan;
m) Prosedur standar reka-yasa perangkat lunak yang diikuti. IEEE  dalam  standar  CSES-SDP- 0024-1.2.1 [IEEE 94] menetapkan
dokumen  dalam  baseline  meliputi  :  a) Software  Confiuration  Management  Plan; b)  Soft-ware  Detailed  Desin  Document;  c) Soft-ware  Development  Plan;  d)  Software Test  Procedure;  e)  Software  Product Specification;  f)  Software  Quality  Assu- rance;  g)  Software  Requirement  Speci- fication;  h)  Software  System  Speci- fication;  i)  Software  Top-Level  Design Docement;  j)  Software  Test  Plan;  k) Software Test Report.
2.3 Evolusi Dokumen Pressman [Pressman 92] menyatakan bahwa sebelum dokumen ditetapkan sebagai baseline, mungkin dokumen
mengalami perubahan  beberapa  kali.  Setelah baseline  ditetapkan  maka  evolusinya mengikuti pola graf (graph) penamaan versi seperti gambar 2.1.
Identifikasi  dokumen/baseline dapat  dilakukan  dengan  pendekatan berorientasi  objek.  Sebuah  objek dapat  mewakili  dokumen  maupun baseline. Objek 1.0 merupakan konfigurasi  awal  (baseline  awal) dengan  versi  1.0  (mungkin  sekaligus berisi  kumpulan  dokumen  yang masing-masing  juga  memiliki  versi 1.0).
Objek  1.0  selanjutnya  mengalami revisi  evolusi  menjadi  objek  1.1  dan objek  1.1  mengalami  perubahan- perubahan  “kecil”  menjadi  versi  1.1.1 dan  1.1.2,  kemudian  mengalami perubahan  “besar”  menjadi  versi objek  1.2.  Evolusi  objek  1.0  terus berlangsung  sampai dengan  objek  1.3 dan  objek  1.4.  Pada  saat  yang  sama modifikasi
“besar” objek
menyebabkan kebutuhan jalur evolusi baru  yaitu  versi  objek  2.0  yan kemudian  berevolusi  menajdi  versi objek  2.1.  Dengan  mekanisme  yang sama,  penamaan  versi  akan  terus berlanjut  sampai  dengan  proyek berakhir (closing project).
Objek  sebagai  baseline  terdiri  dari beberapa dokumen yan secara individu berevolusi
mengikuti baseline-nya.  Dengan kata lain, setiap dokumen  dalam  baseline  mungkin juga  mengalami  evolusi  versinya sendiri.  Misalkan  dalam  baseline  versi 1.0, mula-mula berisi dokumen-1 versi 1.0  dan  dokumen-2  versi  1.0. Kemudian,  setelah  mengalami  evolusi dokumen,  baseline-nya  masih  tetap versi  1.0  namun  dokumen  sudah berkembang menjadi dokumen-1 versi 1.0  dan  dokumen-1  versi  1.1.  serta dokumen-2  versi  1.0  (jadi  ada penambahan dokumen-1 versi 1.1).
2.4 Kontrol Akses Dokumen
Kontrol  akses  dan  sinkronisasi oleh Pressman [Pressman 92] digambarkan dengan skematik seperti gambar 2.2. Prinsip  kontrol akses dan sinkronisasi adalah pada saat pengguna melakukan check-out terhadap  objek  konfigurasi  (dokumen versi  tertentu  dari  baseline),  maka kontrol  sinkronisasi  akan  mengunci (lock)  sehingga  menjamin  tidak  ada perubahan (update) dokumen tersebut  dalam  “basis  data  proyek”.
Dengan  catatan,  bahwa  proses  copy dokumen  masih  diperbolehkan  tetapi perubahan dokumen dilarang. Dokumen akibat check-out ini dinamakan  dokumen  versi  ekstraksi yang
dimodifikasi oleh
tim pengembang.
Check-out  merupakan  kejadian seorang  pengguna  meng-copy  sebuah dokumen  dari  baseline  ke  lingkungan (direktori) masing-masing. Prinsip check-out tidak perlu dibatasi kejadiannya,  namun  untuk  menjaga efisiensi  dan  produktivitas  check-out harus dilakukan pada dokumen dengan  versi  yang  benar  dan  relatif tidak  dalam  kondisi  diubah  oleh pengguna  lain.  Untuk  itu,  informasi versi  dan  pengguna  dalam  bekerja menjadi  motivasi  penting  sebelum kejadian check-out berlangsung.
Setelah dokumen menjalani pengujian  dan  jaminan  kualitas, dokumen  tersebut  menjadi  dokumen versi modifikasi yang akan mengalami check-in.  Pada  saat  check-in  selesai dilakukan maka akes kontrol terhadap dokumen  dalam  “basis  data  proyek” dibuka (unlock).
Check-in merupakan kejadian memin-dahkan (move) sebuah
dokumen modifikasi (yang disetorkan) ke  dalam  baseline  yang  benar  oleh otoritas  MKPL.  Dengan  kata  lain, check-in  merupakan  kontrol  akses perubahan  dokumen  dan  mengatur sinkronisasi  kejadian  check-out  yang paralel  sehingga  tidak  terjadi  saling menimpa  (overwrite)  satu  dengan yang lainnya.
2.5 Evolusi Baseline
IEEE  [IEEE  94]  memberikan contoh  model  manajemen  perubahan baseline secara umum dengan ilustrasi yang diperlihatkan pada gambar 2.3.
Pada  gambar  tersebut,  diawali dengan    aktivitas  pembentukan baseline  (baseline  A)  yaitu  melakukan identifikasi  struktur  yang  mencakup idntifikasi emtitas/produk dan penamaannya.  Perubahan-perubahn dan  status  selanjutnya  terhadap baseline A dicatat dan dilaporkan. Jika dirasa  perlu  kebutuhan  baru  maka ditetapkan  baseline  baru  (baseline  B). Baseline  B  ditetapkan  menjadi  dasar perubahan berikutnya hingga diteapkan  baselie  C.  Proses  tersebut berulang sampai dengan baseline yang siap  diterbitkan  (release).  Bergantung pada  kebutuhan,  perubahan  baseline dilakukan  dengan  cara  penimpaan (overwrite)  atau  dengan  mekanisme penyimpanan histori.
2.6.  Aktivitas MKPL
Pengelolaan  terhadap  dokumen/ baseline dilakukan oleh disiplin MKPL. Humphery
[Humphery 89] menjelaskan  secara  umum  tentang mekanisme pengelolaan baseline yang ada  pada  MKPL  diperlihatkan  pada gambar 2.4. Gambar tersebut menjelaskan bahwa begitu produk
awal  ditentukan  maka  baseline  awal ditetapkan  dan  terlindungi  oleh otoritas  akses  terhadap  perubahan. Selanjutnya perubahan-perubahan yang  terjadi  selama  evolusi  dalam siklus hidup proyek, dilakukan memalui prosedur formal pengontrolan  perubahan  mengikuti arah aliran panah.
Prinsip pengelolaan dokumen terdiri  atas  dua  mekanisme.  Pertama, mekanisme  pengontrolan  perubahan melalui prosedur formal dan menetapkan  otoritas  akses.  Kedua, mekanisme  pengontrolan  baseline dalam  media  penyimpanan.  Di  dalam media penyimpanan ini, baseline akan membentuk  graf  evolusi  seperti  yang telah dibahas sebelumnya.

## 2.7.  Tipologi Organisasi Proyek
Struktur  organisasi    proyek  pengem- bangan perangkat lunak belum standar, namun memiliki elemen yang spesifik.  Humphery  [Humphrey  89] menyebutkan tipologi organisasi
proyek pengembangan perangkat lunak secara spesifik memiliki elemen- elemen  seperti  gambar  2.5.  Berkaitan dengan  penggunaan  dokumen  proyek perangkat lunak, fungsi-fungsi elemen organisasi yaitu :
(1) Kelompok  pimpinan,  adalah  pimpinan proyek  yang  bertugas  menyusun  tim proyek,  menginialisasi  proyek,  dan memonitor  perkembangan  proyek melalui  perkembangan  versi  baseline/ dokumen.
(2) SEPG  (Software  Engineering  Process Group),  seringkali  juga  disebut  tim pengembang,  merupakan  kelompok (agent) pembuat perubahan dokumen
dari  sebuah  proyek  pengembangan perangkat  lunak.  Kelompok  ini  akan menggunakan dokumen sesuai dengan keperluan spesialisasinya.
(3) SQA  (software  Quality  Assurance), merupakan tim atau kelompok penjamin  kualias  perangkat  lunak. Kelompok  ini  menggunakan  dokumen untuk  keperluan  pemeriksaan  kualitas yang mencakup kelengkapan dokumen dan proses.
(4) SCM (Software Configuration Manage- ment), adalah kelompok yang berfungsi sebagai MPKL, yaitu melakukan administrasi dan pengaturan  agar  integritas  perangkat lunak  (dokumen)  terhadap  perubahan tetap  terjaga  dan  dapat  ditelusuri kejadiannya.
Bagian  Administrasi,  keuangan, dan  servis  komputasi  merupakan bagian  yang  dapat  dikatakan  tidak terkait  dengan  penggunaan  dokumen peragkat  lunak.  Bagian-bagian  ini merupakan penunjang non-teknis. III. ANALISIS SISTEM
3.1.    Deskripsi Umum DocCon DocCon  (Document  Control) adalah perangkat lunak bantu pengelolaan dokumen untuk mendukung  MKPL.    Definisi  yang diperlukan mendeskripsikan
kebutuhan DocCon meliputi :
(1) Dokumen  adalah  dokumen  perangkat lunak,  yaitu  sebuah  file  dalam  sistem operasi windows.
(2) Baseline adalah sekumpulan dokumen resmi,  yaitu  sebuah  direktori  yang dilindungi otoritas akses tim MKPL.
(3) Proyek adalah deskripsi sebuah proyek pengembangan  perangkat  lunak  yang memiliki batasan waktu tertentu, yaitu dimulai  saat  tertentu  ditandai  dengan kejadian  ‘inisisalisasi  proyek’,  dan berakhir  ditandai  dengan  kejadian ‘mengakhiri proyek’ (closing project).
(4) Kejadian (event) adalah suatu peristiwa  yang  terjadi  berkaitan
dengan  dokumen,  baseline,  atau proyek yang senantiasa dicatat kejadiannya;
(5) Proses otomatis adalah proses akuisisi (move  atau  copy)  file  dokumen dengan  cara  membangkitkan  secara langsung  representasi  fisik  (direktori/ file)  tanpa  aktivitas  entri  ke  dalam tabel informasi;
(6) Baseline  acuan  adalah  baseline  yang berisi template dokumen dari standar, seperti IEEE, Thomson, atau lainnya;
(7) Representasi  fisik  adalah  perwujudan bentuk  dari  pengertian  atau  konsep nyata  ke  dalam  bentuk  yang  dapat dikenal  (baca-tulis)  dalam  media penyimpan oleh sistem komputer.
Pengelolaan  dokumen  yang  akan dikembangkan dalam DocCon mencakup  tiga  aspek  fungsional, yaitu:
1.  Sumber daya, meliputi : a) pegawai; b) jabatan;  c)  kejadian;  d)  anggota  tim proyek.
2.  Pengelolaan kejadian, meliputi: a) me- nginisialisasi  proyek  baru;  b)  check-in;
c) check-out; d) setor dokumen; e) me- naikkan versi dokumen;  f)  menaikkan versi baseline; g) menghapus dokumen;  h)  menghapus  baseline;  i) menambah item konfigurasi; j)
menjaga  integritas  tabel  informasi;  k) menutup proyek (closing project).
3.  Dukungan informasi, meliputi: a) Infor- masi proyek; b) Informasi anggota tim proyek;  c)  Informasi    progres  proyek;
d) Informasi kejadian.
Secara skematik, pengelolaan dokumen  DocCon  diperlihatkan  pada gambar  3.1.  Pengelolaan  dokumen yang dilakukan oleh DocCon mencakup dua hal pokok seperti yang tertulis di bawah ini.
1.  membuat  hubungan  (link)  antara representasi  fisik  dokumen  dengan tabel  informasi  yang  mendeskripsikan tentang dokumen;
2.  mengelola  sebelas  kejadian  terhadap dokumen atau baseline dengan memanfaatkan  tabel  informasi,  dan menjaga  integritas  keberadaan  repre- sentasi fisik dengan isi tabel informasi. 3.2.  Mekanisme Pengelolaan DocCon 3.2.1.  Identifikasi Fisik
Pengelolaan DocCon butuh identifikasi fisik untuk merepresentasikan nama dan struktur konsep dokumen/baseline relatif terhadap proyek, terlihat pada gambar 3.2.
1. Proyek,  diidentifikasi  dengan  dua nama  direktori,  yaitu  direktori  utama proyek yang digunakan untuk menyimpan  seluruh  baseline  proyek, dan direktori sementara yang
digunakan untuk
menyimpan dokumen akibat kejadian setor dokumen.  Kedua  direktori  tersebut merupakan subdirektori relatif terhadap direktori utama (root directory). Format penamaan direktori proyek  adalah  ‘XXXX’  dan  direktori sementara  diberi  tambahan  ‘-TMP’ menjadi  ‘XXXX-TMP’.  Panjang  nama direktori ‘XXXX’ dibatasi maksimum 20 karakter.  Contoh  nama  proyek  pada gambar 3.2 adalah Proyek_001. 2.  Baseline, diidentifikasi sebagai subdirektori  dari  direktori  utama proyek  yang  memiliki  nama  dan  versi dengan  format  ‘Baseline-V’.  ‘Baseline’ adalah  nama  baseline  dan  ‘V’  nomor versi  dari  0  (nol)  sampai  dengan  9 (sembilan).
3.  Dokumen,  diidentifikasi  sebagai  file  di dalam baseline. Nama sebuah dokumen mengikuti aturan file dengan format  nama  ‘XXXX-VN.YYY’.  ‘XXXX’ adalah  nama  dokumen  maksimum  20 karakter,  ‘VN’  kode  versi  dokumen (secara  implisit  ’V’  versi  baseline,  ‘N’ versi  dokumen),  sehingga  berisi  kode
dari  00  sampai  dengan  99  (00,  01, …,10, …, 91, ..., 99). ‘YYY’ tiga karakter ekstensi  file.  Contoh  dokumen  pada gambar  3.2  adalah  SRS-00.doc,  SDD- 00.txt  untuk  baseline-0  dan  SRS- 95.doc, SDD-99.txt. untuk baseline-9.
3.2.2.  Identifikasi Pemakai
Identifikasi pemakai DocCon dibedakan  dalam  tiga  kelompok  yang dideskripsikan sebagai berikut : 1.  Pimpinan Proyek, merupakan pemakai  yang  melakukan  aktivitas dengan kejadian inisialisasi proyek, memonitor proyek, dan mengakhiri proyek; 2.  Pimpinan MKPL, merupakan pemakai  yang  memiliki  otoritas terhadap kejadian check-in dokumen, melakukan aktivitas kejadian menaikkan versi dokumen/baseline, menghapus dokumen/baseline, dan
pengelolaan lainnya;
3.  Pengguna  Dokumen,  merupakan pema-kai  yang  intensif  terlibat penggunaan  dokumen.  Kejadian yang  terkait  meliputi    check-out dan  setor  dokumen.  Pengguna dokumen  ini  terdiri  dari  beberapa spesialisasi  tim  pengembang  dan tim kontrol kualitas.

## 3.2.3.  Pengelolaan Inisialisasi Proyek
Pelaku   : Pimpinan Proyek Masukan :
1. Data  proyek  (nama,  deskripsi,  tanggal mulai, tanggal selesai)
2. Acuan baseline, pemicu “inisialisasi”
Hasil :
1. Direktori utama dan sementara proyek
2. Direktori baseline dan  file dokumen.
3. Tabel proyek bertambah satu
DOI : 10.51530/jutekin.v11i1.719
4. Tabel baseline bertambah satu
5. Tabel dokumen bertambah beberapa;
6. Tabel kejadian bertambah satu

## Proses:
1. Pimpinan  proyek  mendeskripsikan proyek  dengan  cara  memasukkan (entry)  data  proyek,  misalkan  nama proyek PROYEK_001.
2. Pimpinan  proyek  memilih  acuan baseline  untuk  keperluan  inisialisasi proyek.  Pemilihan  baseline  acuan dapat dilakukan dengan dua cara :
a) memilih  template  acuan  (misal IEEE atau Pressman),
b) memilih  baseline  dari  proyek  lain (misal  base  line-2  berisi  file-X.doc, file-Y.txt, file-Z.doc ).
3. Pimpinan proyek aktifkan “Inisialisasi”.
4. DocCon  memproses  secara  otomatis semua  hasil  (  no.  1,  2,  3,  4,  5,  dan  6). Selanjutnya  DocCon  “mengaktifkan” evolusi dari proyek tersebut (keaktifan proyek dijadikan true).

## 3.2.4.  Pengelolaan Check-out
Pelaku    : Pengguna dokumen Masukan :
1. File baseline, direktori pengguna;
2. Pemicu “check-out”;
3. Deskripsi keperluan penggunaan.
Hasil :
1. File ter-copy ke direktori pengguna;
2. Tabel kejadian bertambah satu
Proses:
1. Pengguna menyeleksi satu dokumen di baseline, dan direktori kerjanya;
2. Pengguna aktifkan  “check-out”;
3. Pengguna meng-entry keperluan;
4. DocCon  meng-copy  otomatis  satu  file dari  baseline  ke  direktori  pengguna dan menambah kejadian check-out ke tabel informasi.

## 3.2.5.  Pengelolaan Setor Dokumen
Pelaku    : Pengguna dokumen Masukan : 1. File dokumen dari direktori pengguna
2. Pemicu “setor”
Hasil :
1. File pindah dari  direktori pengguna ke direktori sementara proyek;
2. Tabel kejadian bertambah satu
Proses:
1.  Pengguna seleksi file dari direktorinya;
2.  Pengguna dokumen aktifkan  “setor” ;
3.  DocCon  memindahkan  otomatis  file dari  direktori  pengguna  ke  direktori sementara  proyek,  dan  menambah identitas  unik  pada  file  tersebut,  agar tidak  terjadi  penimpaan  terhadap  file yang  sama.  Misal  file  SRS-00.doc menjadi  SRS-00-Sanyata.Doc.  Kemudi- an  menambah  data  kejadian  setor dokumen ke tabel informasi.
3.2.6.  Pengelolaan Check-in Pelaku    : Pimpinan MKPL Masukan :
1. File dari direktori sementara
2. Pemicu “check-in”
Hasil :
1. Satu  file  pindah  (move)  dari  direktori sementara ke direktori baseline proyek yang sesuai.
2. Tabel kejadian bertambah satu
Proses:
1. MKPL seleksi file (direktori sementara)
2. MKPL aktifkan “Check-in”
3. DocCon  otomatis  memindahkan  file dari  direktori  sementara  ke  direktori baseline  proyek  yang  sesuai,  sekaligus menghilangkan  identitas  tambahan dari  file  (misal  SRS-00-Sanyata.doc menjadi SRS-00.Doc). Tenik
pemindahan  ini  menimpa  (overwrite) file  yang  telah  ada.  Selanjutnya
DocCon  menambah  data  kejadian check-in ke dalam tabel informasi.

## 3.2.7. Menaikkan Versi Dokumen
Pelaku    : Pimpinan MKPL Masukan :
1. File dalam baseline
2. Pemicu “naik versi dokumen”
Hasil :
1. Satu file terduplikasi, versi meningkat;
2. Tabel kejadian bertambah satu
Proses   :
1. MKPL menyeleksi satu file baseline;
2. MKPL aktifkan “naik versi dokumen”;
3. DocCon  secara  otomatis  meng-copy file tersebut sekaligus menaikkan satu tingkat  versi  dokumen.  (misal  SRS- 00.doc  menjadi  SRS-01.Doc,  atau  SRS- 30.Doc menjadi SRS-31.Doc). Kemudian menambah data kejadian ke tabel informasi.
3.2.8. Menaikkan Versi Baseline Pelaku    : Pimpinan MKPL Masukan :
1. Direktori dalam baseline 2. Pemicu “naik versi baseline” Hasil :
1. Baseline terduplikasi, versi meningkat;
2. Tabel kejadian bertambah satu.
Proses:
1. MKPL aktifkan “naik versi baseline”;
2. DocCon  otomatis  meng-copy  sebuah direktori baseline versi terakhir beserta  seluruh  dokumen,  sekaligus menaikkan  satu  tingkat  versi  baseline serta  mengubah  versi  “baseline” dokumen sesuai dengan versi baseline-nya.  Kemudian  menambah data kejadian menaikkan versi baseline  ke  tabel  informasi  kejadian.
Contoh :
Baseline terakhir ---> Menaikkan versi
Baseline-5:                 Baseline-6 : -SRS-5.0.doc -SRS-6.0.doc -SRS-5.1.doc -SRS-6.1.doc 3.2.9.  Menghapus Dokumen Pelaku    : Pimpinan MKPL
Masukan :
1. File dokumen dalam suatu baseline
2. Pemicu “hapus dokumen”
Hasil :
1. Sebuah dokumen terhapus;
2. Tabel dokumen berkurang satu;
3. Tabel kejadian bertambah satu.
Proses:
1. MKPL menyeleksi sebuah dokumen;
2. MKPL aktifkan “hapus dokumen”;
3. DocCon otomatis menghapus representasi fisik file dokumen tersebut,  menghapus  data  dokumen dari  tabel  dokumen.  DocCon  lalu menambah kejadian menghapus dokumen ke dalam tabel.

## 3.2.10.  Menghapus Baseline
Pelaku    : Pimpinan MKPL Masukan :
1. Direktori suatu baseline
2. Pemicu “hapus baseline”
Hasil :
1. Sebuah baseline terhapus;
2. Tabel baseline berkurang satu data.
1. Tabel  dokumen  berkurang  beberapa, sesuai jumlah dokumen baseline;
3. Tabel kejadian bertambah satu.
Proses:
1. MKPL menyeleksi sebuah baseline;
2. MKPL aktifkan “hapus baseline”;
3. DocCon otomatis menghapus
representasi fisik baseline beserta file- file  dokumennya,  menghapus  data baseline  dari  tabel  informasi  baseline, menghapus  data  dokumen  dari  tabel informasi  dokumen,  dan  menambah data  kejadian  menghapus  baseline  ke tabel informasi.

## 3.2.11. Menambah Item Konfigurasi
Pelaku    : Pimpinan MKPL Masukan :
1. File item konfigurasi (sebuah file)
2. Direktori baseline
3. Pemicu “tambah item”
Hasil :
1. Isi baseline bertambah satu file;
2. Tabel dokumen bertambah satu;
3. Tabel kejadian bertambah satu.
Proses:
1. MKPL menyeleksi sebuah baseline;
2. MKPL menyeleksi file item konfigurasi;
3. MKPL aktifkan “tambah item”;
4. DocCon  meng-copy  satu  file  item konfigurasi  ke  baseline  yang  dipilih, sekaligus  menambah  identitas  versi  ‘- V0’,  dimana  ‘V’  adalah  versi  baseline. Selanjutnya  menambah  data  ke  tabel dokumen,  menambah  satu  kejadian menghapus baseline ke tabel kejadian. Contoh,  item  konfigurasi  ZZZ.doc, maka  setelah  kejadian  penambahan baseline-8, file menjadi ZZZ-80.Doc.
3.2.12.  Mengakhiri Proyek Pelaku    : Pimpinan Proyek
DOI : 10.51530/jutekin.v11i1.719
Masukan : Pemicu “Akhir proyek” Hasil : 1. Aktivasi proyek diakhiri (closing)
2. Tabel kejadian bertambah satu data
3. Catatan status histori proyek baseline
Proses  : 1. Pimpinan aktifkan “Akhir proyek”
2. DocCon  secara  otomatis  mengubah keaktifan proyek menjadi false, sekaligus membangkitkan catatan histori proyek relatif terhadap baseline beserta segenap dokumennya. Catatan histori  proyek  tersebut  dibangkitkan dengan struktur penyajian berikut : Nama Proyek   : xxx Tanggal Mulai  : xxx  Berakhir: xxx Status proyek: \Baseline-1 Nama Dokumen    Tanggal file   Ukuran Xxxxxxxxxxxxx      xxxxxxxxxx    xxxxx \Baseline-N Xxxxxxxxxxxxx      xxxxxxxxxx   xxxxx 3.2.13.  Pengelolaan Integritas Tabel Pelaku    : Pimpinan MKPL Masukan : Pemicu “Integritas” Hasil : 1. Tabel info sesuai representasi fisik;
2. Tabel kejadian bertambah satu.
Proses  :
1. Pimpinan Proyek aktifkan “Integritas”
2. DocCon  otomatis  melakukan  verifikasi dengan  mencocokan  kesesuaian  tabel informasi  dengan  data  representasi fisik.  Jika  data  tabel  masih  ada sedangkan representasi fisik tidak ada, maka  data  tabel  dihapus  dan  tabel ditambah satu data kejadian.

## IV. PERANCANGAN SISTEM
4.1 Model Fungsional DFD DocCon
Model fungsional DocCon
digambarkan  data  flow  diagram (DFD).  Penyajian  DFD  dimulai  dengan diagram  konteks,  diikuti  DFD  level-1 dan level turunannya. Tanda “*“ pada proses  berarti  memiliki  turunan. Resume DFD terlihat pada tabel.
DOI : 10.51530/jutekin.v11i1.719

## 4.2 Basis Data DocCon
Basis  data  kebutuhan  DocCon disajikan dalam model diagram Entity- Relationship, terlihat gambar 4.10.

## V. KESIMPULAN DAN SARAN
Kesimpulan  kajian  pengembangan prototipe  perangkat  lunak  bantu DocCon diurakan sebagai berikut:
1. Prototipe  perangkat  lunak  bantu DocCon  telah  memberikan  gambran simulasi yang memadai tentang MPKL.
2. Sudut  pandang  pengelolaan  dokumen dengan  DocCon  adalah  memandang dokumen  sebagai  objek  individu  dan dokumen sebagai kumpulan objek.
3. Proses  otomatis  DocCon  dilakukan dengan  membangkitkan  data  ke  tabel informasi,  mengambil  data  deskripsi file dari sistem file sistem operasi.
4. Perangkat lunak bantu DocCon mendukung  aktivitas  MKPL  dengan mengelola  sebelas  macam  kejadian, meliputi  inisialisasi  proyek,  check-out, setor  dokumen,  check-in,  menaikkan versi  dokumen,  menaikkan  versi
baseline, menghapus dokumen, menghapus  baseline,  menambah  item konfigurasi,  mengakhiri  proyek,  dan menjaga integritas informasi tabel. 5. Persoalan  penting  pada  mekanisme pe-ngelolaan dokumen adalah mendes-kripsikan  kejadian  dengan tepat, sehingga otomatisasi tercapai. 6. Pengelolaan  dokumen  memerlukan memori  yang  cukup  besar  apabila dokumen  memiliki  banyak  evolusi terutama  evolusi  baseline.  DocCon mengatasi masalah penyimpanan dengan  melakukan  kejadian  hapus dokumen/baseline,  dengan  konse-
kuensi kehilangan histori.
7. DocCon tidak sepenuhnya mendukung seluruh  aktivitas  MKPL,  tetapi  DocCon telah mengidentifikasi aktivitas penting  dari  manajemen  konfigurasi dalam  rangka  membangkitkan  proses otomatis pengelolaan dokumen. 8. DocCon belum melakukan sinkronisasi terhadap  perubahan  dokumen  yang diakibatkan  oleh  kejadian  check-out dan check-in.

## DAFTAR PUSTAKA
[Humphrey 89] Humphrey, Watts S. 1989. Managing  the  Software  Process. Addison-Wesley.
[IEEE  94]  IEEE.  1984.  IEEE  Standards  Co- llection Software Engineering. IEEE Inc.
[Osten 96] Osen, Orkarson, and Robert L. Glass.  1996.  An  Iso  9000  Approach  to Building Quality Software.
[Perry  95]  Perry,  William.  1995.  Effective Methods  for  Software  Testing.  John Wiley & Son Inc., Canada.
[Pressman  92]  Pressman,  Roger.  1992.
Software  Engineering  A  Practitioner’s Approach. 4 th edition, McGraw-Hill.
[Wallmuller 94] Wallmuller, Ernest. 1994.
Software Quality Assurance A’practical Approach. Prentice Hall.
[Wozniewicz  95]  Wozniewicz,  Andrew  J, and Shammas. 1995. Teach Yours Selft Delphi in 21 Days.Sams Publishing.