Metode Dokumentasi Divisi Pengembangan Aplikasi Di PT Daya Adira MUstika
27
ABSTRAKSI
Kerja Praktek dilaksanakan di PT Daya Adira Mustika, perusahaan yang bergerak di bidang otomotif, mulai tanggal 19 Juli 2010 sampai dengan tanggal 18 Agustus 2010.
Kerja praktek yang dilakukan adalah mendokumentasikan perangkat lunak yang telah dikembangkan dan mencari serta mendokumentasikan standarisasi kode yang akan digunakan selama proses pengembangan berlangsung.
Selama proses pendokumentasian pada perangkat lunak, penulis hanya membuat dokumen berupa Deskripsi Perancangan dan Spesifikasi Program, Tahap pertama yang dilakukan adalah menganalisa perangkat lunak yang akan didokumentasikan. Tahap kedua mempelajari dan proses eksplorasi seluruh komponen baik dari tool-tool yang digunakan pada saat proses pengembangan perangkat lunak tersebut maupun pada perangkat lunak itu sendiri. Tahap terakhir adalah proses dokumentasi dengan membuat Deskripsi dan Spesifikasi perangkat lunak yang didokumentasikan.
Pada akhir kerja praktek telah berhasil mendokumentasikan beberapa perangkat lunak dan Standard koding yang akan diterapkan selama proses pengembangan selanjutnya.
(2)
RIWAYAT HIDUP
NIM : 10107773
Kelas : IF-15
Nama Lengkap : Mubassirin
Tempat / Tanggal Lahir : Sidoarjo, 10 Juli 1988
Agama : Islam
Jenis Kelamin : Laki - laki
Alamat : Jl. Siliwangi dalam no
No. Telp : 081910029157
PENDIDIKAN
1993 - 1999 : SD Muhammadiyah
1999 - 2002 : SLTP Negeri 1 Taman
2002 - 2005 : SMK Perkapalan Sidoarjo
2005 - 2009 : Program S1, J Teknik Informatika, Universitas Komputer Indonesia
Bandung, 2010
Mubassirin NIM : 10107773
(3)
27
BAB I
PENDAHULUAN
1.1Latar belakang
Kadang perusahaan ingin melakukan modifikasi kecil dari software yang sudah dibuat dan sudah diluar masa garansi. Tapi sulit dilakukan karena hambatan dokumentasi. Dokumentasi yang buruk, yang hanya dimengerti oleh pembuatnya saja, menyulitkan dipahami oleh pihak lain yang akan meneruskan pekerjaan tersebut. Ketika sistem berkembang lalu ada tuntutan integrasi, dokumentasi yang buruk mungkin akan menyulitkan untuk memahami struktur data, cara berkomunikasi data, apalagi kalau ada keperluan modifikasi algoritma untuk mencapai tujuan integrasi. Dokumentasi juga berguna untuk menginformasikan tentang proses yang ada dalam program, sehingga jika ada pertanyaan tentang program yang dibuat memiliki kemampuan apa saja, kita dapat mengetahui atau menjelaskan berdasarkan dokumentasi. Karena program yang telah selesai dibuat belum tentu dapat langsung sempurna, sesuai dengan yang diperlukan oleh penggunanya. Perlu ada pengembangan untuk dapat memenuhi keperluan penggunanya dan perbaikan jika ternyata pada saat digunakan ditemukan kesalahan.Suatu dokumentasi program sangat diperlukan oleh pemilik aplikasi, jika ingin mengembangkan aplikasinya bukan oleh pengembang yang sama. Pengembang lain yang diserahi tugas untuk mengembangkan aplikasi dapat dengan cepat mempelajari dari dokumentasi tersebut.
Berdasarkan pertimbangan di atas, PT. Daya Adira Mustika (PT. DAM), sebagai perusahaan yang bergerak dalam bidang otomotif dan bertindak sebagai distributor utama (Main Dealer) Sepeda Motor Honda (SMH) untuk wilayah Jawa Barat yang sangat membutuhkan penerapan teknologi informasi dan komunikasi membuat semakin padatnya kegiatan bisnis pada departemen Information Technology (IT) seperti permintaan user di sub departemen system analys yang makin meningkat sehingga departemen IT khususnya bagian development selaku
(4)
bagian yang bertanggung jawab dalam kebutuhan teknologi informasi memerlukan sebuah dokumentasi, guna menunjang kegiatan bisnis tersebut.
1.2Rumusan masalah
Berdasarkan latar belakang yang telah diuraikan di atas, maka penulis merumuskan beberapa masalah yang akan dibahas sebagai berikut :
1. Bagaimana merancang sebuah dokumentasi guna mendukung proses pengembangan pada divisi development aplication.
2. Penggunaan metode yang digunakan pada proses pembangunan. 3. Aturan ( Pedoman ) yang diterapkan pada saat proses pembangunan. 4. Proses yang terjadi pada saat proses pembangunan.
5. Pengimplementasian dokumen yang telah dibangun.
1.3Maksud dan Tujuan
Maksud dari kerja praktek yang dilakukan di PT. Daya Adira Mustika dari tanggal 19 Juli 2010 sampai dengan 18 Agustus 2010 ini membuat sebuah dokumentasi pada perangkat lunak yang telah dikembangkan dan membuat standar koding yang akan diterapkan pada proses pengembangan selanjutnya di PT Daya Adira Mustika guna mempermudah proses kerja yang terjadi di bagian development.
Sedangkan tujuan yang akan dicapai adalah untuk mengetahui dan mempelajari proses yang terjadi pada divisi pengembangan aplikasi di PT Daya Adira Mustika.
1.4Batasan masalah
Selama kerja praktek dilaksanakan penulis hanya dilibatkan dalam pembuatan standar koding pengembangan pada bahasa pemrograman Visual Basic.Net dan Pembuatan dokumentasi perangkat lunak yang telah dikembangkan. Materi pendokumentasian yang di lakukan selama melaksanakan kerja praktik
(5)
menyangkut hal tentang materi mengenai Deskripsi Perancangan dan Spesifikasi
Aplikasi sesuai dengan penerapan IEEE Std 1016-1987.
1.5 Sistematika Penulisan
Penyusunan Laporan Praktek Kerja Lapangan ini, Penulis bagi dalam beberapa bab yang secara singkat dapat dijelaskan sebagai berikut:
BAB I PENDAHULUAN
Pada bab ini memuat latar belakang penulisan, perumusan masalah, tujuan dan manfaat penulisan, dan sistematika penulisan.
BAB II PROFIL PT. DAYA ADIRA MUSTIKA
Dalam bab ini akan membahas profil singkat awal mula berdirinya perusahaan Daya Adira Mustika dan struktur organisasi pada PT Daya Adira Mustika.
BAB III LANDASAN TEORI
Pada bab ini merupakan pembahasan mengenai materi tentang teori pengembangan aplikasi, berbagai jenis metodologi dan aturan (pedoman) yang harus diterapkan pada saat proses pembangunan. BAB IV PEMBAHASAN
Pada bab ini akan membahas proses pembangunan sebuah dokumen yang telah di lakukan selama pelaksanaan kerja praktek.
BAB V PENUTUP
Berisi kesimpulan dari apa yang telah dibahas sebelumnya, dan juga saran dari masalah yang terkait.
(6)
27
BAB II
TINJAUAN PUSTAKA
2.1Profil Perusahaan
PT. Daya Adira Mustika (PT. DAM) adalah sebuah perusahaan swasta yang bergerak di bidang otomotif. PT. DAM bertindak sebagai distributor utama (Main Dealer) sepeda motor Honda (SMH) untuk wilayah Jawa Barat. PT. DAM berkantor pusat di Bandung dan memiliki dua kantor cabang yang berfungsi sebagai gudang, yaitu di Kota Cirebon dan Karawang.
2.1.1 Sejarah Instansi
Sejarah berdirinya PT. DAM tidak dapat dipisahkan dari tokoh pendiri dan pemimpin perusahaan, yaitu Raphael Adi Rachmat. Setelah menamatkan sekolah dasar HCZS di Kadipaten, Raphael melanjutkan ke sekolah dagang M.H.S - Kesatrian Institue Douwes Dekker di Bandung.
Sejalan dengan perkembangan zaman, Raphael pindah ke Bandung pada tahun 1948. Kemudian bersama dengan beberapa teman membuka usaha angkutan "PEKALIPAN" dan hasil bumi. Dengan kejeliannya, mulailah Raphael membuka usaha baru sebagai Leveransir Badan Usaha Milik Negara dengan nama PD. Matras yang berkedudukan di JI. Gatot Subroto No. 6 Bandung. Selain sebagai Leveransir alat - alat listrik, besi dan alat-alat telekomunikasi, PD. Matras juga menjual hasil bumi, yaitu menjadi grosir gula.
Menjelang tahun 1970, adik ipar Raphael, Tjia Kian Tie, meminta pendapat Raphael mengenai tawaran untuk memasarkan SMH di Indonesia. Raphael menyarankan adiknya untuk menerima tawaran tersebut karena SMH menurut pandangan Raphael banyak dibutuhkan oleh masyarakat, sehingga memiliki peluang pasar yang baik.
Tahun 1970, PD. Matras mulai memasarkan SMH di Propinsi Jawa Barat. Pada tahun 1972, PD. Matras hanya menangani barang - barang seperti : oli CALTEX, accu GS, ND busi, ND parts dan beberapa produk lainnya. Sedangkan,
(7)
pemasaran SMH dilakukan oleh PD. Daya yang berkedudukan di Jl. Jendral Sudirman Bandung. Prediksi Raphael mengenai SMH ternyata sangat tepat dan penjualannya pun terus meningkat. Dalam rangka menunjang purna jualnya, maka pada tahun 1974 didirikan Honda Service Center yang berlokasi di Jl. Gardujati No. 56 Bandung. Honda Service Center bergerak dalam bidang pelayanan jasa service dan penjualan suku cadang SMH. Pada tahun 1977, kantor PD. Daya dan PD. Matras pindah ke Jl. Asia Afrika No. 13 B Bandung.
Pada tahun 1984, PD. Daya melakukan perubahan secara yuridis menjadi perseroan terbatas dengan nama PT. DAM berdasarkan Akta Notaris No. 1 tanggal 2 April 1984, yang kemudian dibagi menjadi dua divisi, yaitu Honda Divison sebagai dealer SMH dan sepeda Federal di Jawa Barat dan Parts and Service Division sebagai dealer suku cadang Honda Genuine Parts di Jawa Barat yang menangani service dan penjualan suku cadang.
Sejalan dengan perkembangan kebutuhan masyarakat, PT. DAM tidak lagi menjual sepeda federal dan memfokuskan diri sebagai dealer utama SMH, baik unit maupun spare part di Jawa Barat.
Pada tahun 1994, kantor PT. DAM pindah ke Jl. Raya Cibeureum No.26 Bandung dengan pertimbangan bisnis, yaitu karena lokasi tersebut merupakan jalur Jakarta - Bandung, sehingga akan memudahkan di dalam pendistribusian SMH. Hal ini pula yang menjadi dasar pertimbangan perusahaan membuka kantor cabang di Karawang dan Cirebon pada tahun 2002. Kantor cabang di Karawang didirikan dengan tujuan untuk mewakili distribusi SMH di Jawa Barat bagian Barat. Lokasi di Karawang berdekatan dengan pabrik PT. AHM. Sedangkan kantor cabang di Cirebon didirikan dengan tujuan untuk mewakili distribusi SMH di Jawa Barat bagian Timur. Lokasi kantor tersebut merupakan jalur PANTURA, sehingga mudah dijangkau dan memiliki pangsa pasar yang lebih baik dibandingkan kota lain.
2.1.2 Struktur Organisasi
PT. Daya Adira Mustika yang beralamat di Jalan Raya Cibereum No.26 Bandung adalah sebuah perusahaan yang bergerak dalam bidang otomotif dan
(8)
bertindak sebagai distributor utama (Main Dealer) Sepeda Motor Honda (SMH) untuk wilayah Jawa Barat.
Struktur organisasi PT. Daya Adira Mustika dapat dilihat pada Lampiran X. Dalam melaksanakan kerja praktek, didapatkan bimbingan secara langsung dari Bapak Risnandi Abadi selaku Kepala Product Development. Dengan demikian, pendokumentasian perangkat lunak yang dikembangkan ini berada di bawah lingkup tim Product Development.
2.1.3 Lingkup Pekerjaan
Divisi Product Development PT. Daya Adira Mustika memiliki lingkup pekerjaan mengembangkan aplikasi yang di gunakan untuk mendukung proses bisnis yang terjadi di PT. Daya Adira Mustika dan di dealer-dealer yang lainnya yang merupakan mitra dari PT. Daya Adira Mustika. Pengembangan aplikasi dapat didasarkan pada aplikasi yang telah dibuat sebelumnya ataupun berupa aplikasi baru. Lingkup pekerjaan yang terjadi di Divisi Development dapat dilihat pada Lampiran XI.
Ketika proses kerja praktek ini berlangsung, divisi Product Development PT. Daya Adira Mustika sedang membangun system pendokumentasian seluruh proses pengembangan perangkat lunak yang telah dilakukan guna mendukung proses pengembangan perangkat lunak selanjutnya. Pada pelaksaaan kerja praktek, peserta kerja praktek membantu mendokumentasikan perangkat lunak yang telah dikembangkan dan juga mendokumentasikan standard koding yang akan digunakan.
2.1.4 Jadwal Kerja
Kerja praktek yang dilakukan di PT. Daya Adira Mustika dilaksanakan selama satu bulan, dimulai sejak tanggal 19 Juli 2010 hingga 18 Agustus 2010. Jam kerja peserta kerja praktek mengikuti aturan jam kerja karyawan tetap di PT. Daya Adira Mustika, yaitu dimulai pukul 08.00 hingga 17.00 selama hari Senin hingga Jumat. Waktu istirahat adalah pukul 12.00 – 13.00 untuk hari Senin – Kamis dan pukul 11.30 – 13.30 untuk hari Jumat.
(9)
Adapun detail kegiatan kerja praktek dalam skala harian dapat dilihat pada lampiran E. Secara keseluruhan, realisasi jadwal kerja sesuai dengan rencana yang telah disusun.
2.2Landasan Teori
Selama pelaksanaan kerja praktek di PT. Daya Adira Mustika peserta kerja praktek menggunakan pengetahuan yang diperoleh selama masa perkuliahan sebagai landasan teori. Pengetahuan dan teori yang digunakan antara lain:
1. Deskripsi Perancangan dan Spesifikasi Program
Adalah representasi sistem perangkat lunak yang dibuat untuk membantu tahapan analisis, perencanaan, implementasi, dan pengambilan keputusan. Deskripsi ini merupakan model atau ‘blueprint’ dari sistem perangkat lunak dan digunakan sebagai media utama dalam komunikasi informasi perancangan perangkat lunak.
Dokumen perancangan sangat penting dalam merepresentasikan informasi perancangan. Setiap bagian dari dokumen perancangan menggambarkan sebagian informasi mengenai perancangan perangkat lunak. Umumnya, dokumen perancangan menentukan daftar isi untuk dokumen dan memberikan deskripsi singkat dari setiap bagian. Secara teori, informasi dibagi menjadi bagian-bagian dokumen yang sesuai dengan kebutuhan pengguna tertentu. Pertimbangan yang digunakan dalam memilah-milah informasi dalam dokumen perancangan adalah: Deskripsi perancangan dapat dibagi menjadi dua atau lebih dokumen agar berkorespondensi dengan proses pengembangan perancangan, contohnya perancangan dokumen arsitektur dan dokumen perancangan rinci. Setiap bagian dokumen perancangan dapat berkorespondensi dengan model yang diidentifikasikan pada metode perancangan.m Setiap bagian dokumen perancangan dapat berkorespondensi dengan struktur perangkat lunak, contohnya bagian untuk setiap komponen penting peranglat lunak. Setiap bagian dokumen perancangan dapat berkorespondensi dengan pengguna yang berbeda,
(10)
IEEE Std 1016-1987 mendefinisikan informasi minimal yang harus ada dalam deskripsi perancangan perangkat lunak. Bagian ini akan memberikan contoh untuk setiap metode perancangan dan menggambarkan perlunya mengembangkan metode ke metodologi yang komprehensif.
1. Metode Perancangan Berorientasi Fungsi
Metode perancangan berorientasi fungsi memodelkan sistem perangkat lunak dengan memecahnya menjadi komponen, menentukan input yang diperlukan bagian tersebut dan output yang dihasilkan setiap bagian.Metode perancangan berorientasi fungsi mencakup analisi struktur dan perancangan struktur.
Berikut ini adalah empat model utama, atau representatif perancangan, yang dihasilkan metode ini:
a) Data flow diagram – Dapat didekomposisi menjadi context diagram, proses, data store, source, control flow.
b) Data dictionary – Dapat didekomposisi menjadi data flow definition, file definition, dan definisi dari data store yang digunakan dalam proses
c) Structure chart – Dapat didekomposisi menjadi afferent, efferent, transform, coordinate module, dan predefined module.
d) Process specification – Modul ini memberikan data yang selanjutnya didefinisikan dalam data dictionary.
2. Metode Perancangan Berorientasi Data
Metode berorientasi data adalah metode perancangan dimana struktur program diturunkan dari struktur data. Diagram pohon umumnya digunakan untuk merepresentasikan data dan struktur program.
Contoh
Contoh yang digunakan adalah Jackson Structured Programming (JSP). Langkah pertama dalam metode ini adalah mendefinisikan struktur data. Setelah kaitan data telah ditetapkan maka data masukan
(11)
dipetakan ke data keluaran. Struktur program pada level atas umumnya digambarkan dengan grafik. Grafik ini berupa pohon fungsi, terdiri dari fungsi atau operasi yang dapat memproses data. Setiap fungsi biasanya dipecah menjadi subfungsi masukan, proses, dam keluaran. 3. Metode Perancangan Berorientasi Kontrol Real-Time
Hal utama pada metode perancangan berorientasi kontrol real-time adalah variasi pada pendekatan perancangan struktur dan memiliki notasi data flow yang lebih banyak untuk menangani kompleksitas sistem berorientasi kontrol real-time. Elemen penting dalam metode perancangan berorientasi kontrol real-time adalah ketentuan dalam merepresentasikan konkurensi dan heuristik dalam membangun cara pandang. Atribut utama yang berasosiasi dengan cara pandang ini adalah proses atau task. Elemen lain yang dapat ditemukan dalam metode perancangan berorientasi kontrol real-time adalah ketentuan dalam pemodelan komunikasi antar proses atau task. Contoh Pendekatan Ward&Mellor akan digunakan sebagai contoh untuk perancangan berorientasi kontrol real-time.
4. Metode Perancangan Berorientasi Objek
Metode perancangan berorientasi objek menghasilkan arsitektur perangkat lunak yang berdasar pada manipulasi objek oleh sistem dan bukan berdasarkan fungsi. Objek, seperti yang didefinisikan oleh Booch, adalah entitas yang memiliki:
a) Status yang menunjukkan nilai sekarang b) Deskripsi aksi yang diperlukan objek
c) Instance dari sejumlah kelas yang unik dimana kelas dicirikan oleh sejumlah nilai dan operasi yang valid untuk instance kelas tersebut d) Nama yang dapat diacu
e) Pengontrolan dapat dilakukan dari/ke objek lain
Layer virtual machine/object-oriented method (LVM/OOD) akan digunakan sebagai contoh untuk menggambarkan metode berorientasi objek, seperti yang dipaparkan oleh Wasserman. LVM/OOD
(12)
menggambarkan konsep dekomposisi paralel dari sistem ke mesin virtual dan objek. Setiap mesin virtual menyediakan instruksi yang digunakan untuk menyelesaikan persoalan.
5. Metode Perancangan Berorientasi Bahasa Formal Contoh dari metode berorientasi bahasa formal adalah: a) Z
b) Paisley
c) Vienna Design Method
Agar dapat diklasifikasikan sebagai metode berorientasi bahasa formal, proses pengembangan perangkat lunak harus mencakup sekumpulan keluaran yang terdefinisi dengan baik dan bahasa formal yang digunakan.
Contoh yang digunakan adalah Vienna Design Method (VDM). VDM adalah perancangan yang dibangun di lingkungan bahasa formal META IV. VDM menggambarkan sistem sebagai sederetan model dalam layer top down.
b. Bagian-bagian Deskripsi Perancangan 1. Pendahuluan
2. Deskripsi Dekomposisi
Deskripsi dekomposisi mencatat pembagian dari sistem perangkat lunak ke dalam entitas perancangan. Ini menggambarkan cara penstrukturan sistem, tujuan, dan fungsi setiap entitas. Untuk setiap entitas, deskripsi ini menyediakan referensi ke deskripsi detail melalui atribut identifikasi.
Deskripsi dekomposisi dapat digunakan designer dan maintainer untuk mengidentifikasikan entitas perancangan utama dari sistem , yang bertujuan seperti misalnya menentukan entitas mana yang bertanggung jawab dalam melakukan fungsi tertentu. Entitas perancangan dapat dikelompokkan ke dalam kelas utama untuk membantu pengalokasian informasi tertentu dan membantu dalam
(13)
pemeriksaan dekomposisi (kelengkapan). Sebagai contoh misalnya pemisahan antara dekomposisi modul dan data.
Sejumlah metode dapat digunakan untuk menggambarkan dekomposisi entitas seperti misalnya diagram dekomposisi hirarki atau bahasa alami.
3. Deskripsi Ketergantungan
Deskripsi ketergantungan menggambarkan keterkaitan antar entitas. Ini mengidentifikasikan entitas yang bergantung pada entitas lain, coupling, dan mengidentifikasikan keperluan sumber daya lain.
Deskripsi ketergantungan menyediakan gambaran tentang bagaimana sistem bekerja, dalam hal pengaruh keperluan dan perubahan perancangan. Ini dapat membantu maintainer untuk mengisolasi entitas yang dapat menyebabkan kegagalan sistem.
Metode yang dapat digunakan untuk merepresentasikan kebergantungan ini yaitu structure chart, data flow diagram, dan transaction diagram.
4. Deskripsi Antarmuka
Deskripsi antarmuka digunakan oleh designer, programmer, dan tester untuk mengetahui penggunaan fungsi yang disediakan oleh entitas dengan benar. Deskripsi ini mencakup antarmuka internal dan eksternal secara rinci yang tidak dicantumkan dalam SKPL.
Deskripsi antarmuka memberikan gambaran pada designer, programmer, tester, dan customer sebelum melangkah ke perancangan rinci atas entitas. Sebagai tambahan, deskripsi ini dapat digunakan untuk membuat dokumentasi bagi pengguna.
Deskripsi antarmuka harus menyediakan bahasa untuk berkomunikasi dengan setiap entitas termasuk format layar, masukan yang valid, dan keluaran. Untuk entitas yang sifatnya data driven, harus menggunakan data dictionary untuk menggambarkan karakteristik data. Untuk entitas yang sifatnya dekat kaitannya dengan pengguna, harus mencakup functional model, skenario penggunaan,
(14)
fasilitas secara rinci, dan interaction language. Representasi yang dapat digunakan adalah interface file dan parameter table.
5. Perancangan Rinci
Deskripsi perancangan rinci berisi rincian internal dari setiap entitas perancangan. Rincian ini mencakup deskripsi atribut untuk identifikasi, pemrosesan, dan data. Informasi atribut ini harus disediakan untuk setiap entitas perancangan.
Deskripsi ini berguna bagi programmer dalam tahap implementasi dan juga dapat digunakan untuk membantu perencanaan pembuatan unit tes.
Terdapat sejumlah alat bantu untuk menggambarkan entitas perancangan. Misalnya Program Design Language (PDL) dapat digunakan untuk menggambarkan masukan, keluaran, data lokal, dan algoritma untuk suatu entitas. Alat representasi lainnya yaitu Nassi-Schneidermann chart (N-S chart), dan flowchart.
2. Konsep Relasional Database dan RDBMS
Relational Database sebenarnya adalah salah satu konsep penyimpanan data, sebelum konsep database relasional muncul sebenarnya sudah ada dua model database yaitu Network Database dan Hierarchie Database. Dalam database relasional, data disimpan dalam bentuk relasi atau tabel dua dimensi, dan antar tabel satu dengan tabel lainnya terdapat hubungan atau relationship, sehingga sering kita baca diberbagai literatur, database didefinisikan sebagai “kumpulan dari sejumlah tabel yang saling hubungan atau keterkaitan”. Nah, kumpulan dari data yang diorganisasikan sebagai tabel tadi disimpan dalam bentuk data elektronik di dalam hardisk komputer. Untuk membuat struktur tabel, mengisi data ke tabel, mengubah data jika diperlukan dan menghapus data dari tabel diperlukan software. Software yang digunakan membuat tabel, isi data, ubah data dan hapus data disebut Relational Database Management System atau dikenal dengan singkatan RDBMS sedangkan perintah yang digunakan untuk membuat tabel, isi, ubah dan hapus data disebut perintah SQL yang merupakan singkatan
(15)
dari Structure Query Language. Jadi, setiap software RDBMS pasti bisa digunakan untuk menjalankan perintah SQL.
Sebenarnya fungsi RDBMS bukan cuma buat tabel, isi data, ubah dan hapus data, untuk manajemen data dalam skala besar dan agar bisa mendukung proses bisnis yang kontinyu dan real time suatu RDBMS dituntut untuk mempunyai kemampuan manajemen user dan keamanan data, backup dan recovery data serta kemampuan lainnya yang berkaitan dengan kecepatan pemrosesan data (performance). Salah satu software RDBMS yang ada dipasaran saat ini dan cukup banyak digunakan adalah Oracle Database.
3. PL / SQL
PL/SQL MySQL adalah bahasa prosedural yang digunakan untuk mengoptimalkan pembuatan aplikasi database yang menggunakan database MySQL. Kata PL pada PL/SQL merupakan singkatan dari Procedural Language. Dalam PL/SQL dapat digunakan perintah untuk memanipulasi data yang ada dalam database MySQL. PL/SQL MySQL membentuk pemrograman terstruktur dalam memproses data. Pada PL/SQL ditambahkan beberapa hal yang dikenal pada dunia pemrograman, seperti variabel, loop, pemrosesan kondisi, operasi cursor, modularisasai, dan hal-hal lainnya. Semua tambahan itu bertujuan untuk meningkatkan kinerja operasi-operasi SQL pada database MySQL sehingga manfaat dari kehandalannya menjadi maksimal.
PL/SQL dapat dibagi menjadi tiga, yaitu: prosedur, fungsi, dan trigger. Prosedur dan fungsi bekerja berdasarkan eksekusi langsung dari user/program, sedangkan trigger akan bekerja secara otomatis apabila terjadi aktivitas insert, update atau delete data.
2.3Kakas Penunjang
Kakas atau tools yang digunakan dalam pendokumentasian antara lain: 1. Oracle Database 10g Express Edition
Oracle Database Express Edition adalah sebuah database relational yang diberikan secara gratis oleh Oracle Corporation. Oracle Database Express Edition
(16)
adalah cetakan yang lebih kecil dari Oracle Database. Oracle Database XE mudah untuk diinstall dan mudah dalam pengaturannya. Dengan Oracle Database XE, Anda dapat menggunakan interface berbasis web browser untuk:
a. Mengatur Database
b. Membuat tabel, view, dan objek database lainnya c. Import, export, dan view data table
d. Menjalankan query, dan script SQL e. Membuat report
Aplikasi Oracle Database 10g Express Edition menawarkan pengembangan yang terpadu, antara lain semua objek aplikasi tersimpan dalam database beserta dengan table dan prosedur atau fungsi yang ditulis dengan bahasa PL/SQL.
Ketika Pemakai melalui web browser mengirimkan suatu URL, alamat URL akan dipetakan ke pemanggilan PL/SQL yang sesuai, Di mana dari
2. Browser Mozilla Firefox
Mozilla Firefox (aslinya bernama Phoenix dan kemudian untuk sesaat dikenal sebagai Mozilla Firebird) adalah penjelajah web antar-platform gratis yang dikembangkan oleh Yayasan Mozilla dan ratusan sukarelawan. Versi 3.0 dirilis pada 17 Juni 2008.
Sebelum rilis versi 1.0-nya pada 9 November 2004, Firefox telah mendapatkan sambutan yang sangat bagus dari pihak media, termasuk dari Forbes dan Wall Street Journal. [6][7] Dengan lebih dari 5 juta download dalam 12 hari pertama rilisnya dan 6 juta hingga 24 November 2004, Firefox 1.0 adalah salah satu perangkat lunak gratis, sumber-terbuka (open-source) yang paling banyak digunakan di antara pengguna rumahan.
Melalui Firefox, Yayasan Mozilla betujuan untuk mengembangkan sebuah browser web yang kecil, cepat, simpel, dan sangat bisa dikembangkan (terpisah dari Mozilla Suite yang lebih besar). Firefox telah menjadi fokus utama perkembangan Mozilla bersama dengan client e-mail Mozilla Thunderbird, dan telah menggantikan Mozilla Suite sebagai rilis browser resmi Yayasan Mozilla.
(17)
Di antara fitur populer Firefox adalah pemblokir pop-up yang sudah terpasang di dalamnya, dan sebuah mekanisme pengembangan (extension) untuk menambah fungsionalitas tambahan. Meskipun fitur-fitur ini sudah tersedia untuk beberapa lamanya di browser-browser lainnya seperti Mozilla Suite dan Opera, Firefox merupakan browser pertama yang mendapatkan penerimaan dalam skala sebesar ini. Firefox ditargetkan untuk mendapat sekitar 10% pangsa pasar Internet Explorer keluaran Microsoft (browser paling populer dengan margin yang besar (per 2004) hingga tahun 2005, yang telah disebut oleh banyak orang sebagai tahun kembalinya perang browser. [9]
Firefox telah mendapatkan perhatian sebagai alternatif kepada Internet Explorer sejak Explorer dikecam karena tuduhan ketidakamanannya—pihak yang setuju terhadap anggapan ini mengatakan Explorer tidak mengikuti standar Web, menggunakan komponen ActiveX yang sering membahayakan, dan kelemahannya terhadap pemasangan spyware dan malware—dan kurangnya fitur-fitur yang dianggap pemakai Firefox penting. [10] Microsoft sendiri telah merespons bahwa mereka tidak menganggap jika isu-isu mengenai keamanan dan fitur Explorer perlu dikhawatirkan. [11]
Versi 2.0 diluncurkan pada 24 Oktober 2006. Pada versi 2.0 ini, Mozilla mempunyai bug (kelemahan) yaitu akan "crash" jika membuka web page (halaman Web) yang sangat besar dan memiliki JavaScript, namun hal ini telah diperbaiki
3. Microsoft Word
Microsoft Word merupakan program aplikasi pengolah kata (word processor) yang yang biasa digunakan untuk membuat laporan, membuat dokumen berbentuk surat kabar, membuat label surat, membuat table pada dokumen, dan masih banyak lagi dukumen-dokumen lain yang biasa dibuat dengan menggunakan Microsoft Word.
Sebelum memulai mengoperasikan Microsoft Word, ada baiknya jika kita mengenal beberapa istilah yang akan dipakai dalam paket latihan ini. Di antaranya adalah istilah Screen Layout (tampilan layar), Menu, dan Toolbar.
(18)
Screen Layout atau tampilan layar, sesuai dengan arti kata-kata penyusunnya, merupakan sebuah tampilan yang ditunjukkan komputer anda saat mengoperasikan program ini. Untuk tampilan dalam Microsoft Word, dapat dilihatpadagambardi bawah ini.
(19)
27
BAB III
PEMBAHASAN
1.1Input
Tugas pendokumentasian diberikan oleh Bapak Risnandi Abadi, secara lisan. Salah satu kebutuhan yang paling mendasar dalam pendokumentasian adalah informasi mengenai tool yang akan digunakan dalam proses pendokumentasian.
Dalam mempelajari metodologi pendokumentasian, diberikan beberapa contoh dokumentasi sebelumnya yang pernah dibuat. Secara keseluruhan, dasar teori yang dipelajari selama perkuliahan menjadi input yang berharga dalam proses pelaksanaan kerja praktek. Dasar teori ini menjadi hal yang sangat penting untuk mempelajari aplikasi yang dibutuhkan untuk proses dokumentasi.
Sebagai penunjang seluruh kegiatan kerja praktek, disediakan pula fasilitas perangkat keras berupa satu set komputer, internet dan satu meja kerja. Untuk keperluan pembangunan dokumentasi disediakan pula sebuah perangkat lunak yang dibutuhkan untuk proses pendokumentasian.
1.2Proses
Setelah melakukan pengenalan lingkungan kerja pada awal pelaksanaan kerja praktek, selanjutnya proses kerja praktek dapat dibagi menjadi beberapa tahap. Secara garis besar, pekerjaan yang telah dilakukan dapat dibagi dalam 3 tahap :
1. Pembangunan dokumentasi mengenai standar coding.
2. Pembangunan dokumentasi pada perangkat lunak yang telah dikembangkan. Proses Pembangunan dokumentasi ini dapat dibagi menjadi beberapa tahap :
a. Proses Eksplorasi seluruh komponen pada perangkat lunak yang akan didokumentasikan.
b. Pembangunan dokumentasi perangkat lunak sesuai dengan standard yang telah ditetapkan.
(20)
c. Pengujian dokumentasi yang telah dibuat sebelum proses penyimpanan.
3. Pelaporan kegiatan dan hasil kerja praktek, baik kepada PT. Daya Adira Mustika maupun kepada Departemen Teknik Informatika Universitas Komputer Indonesia. Pelaporan ini dilakukan melalui pembuatan laporan kerja praktek.
Deskripsi pekerjaan yang dilakukan sesuai dengan kesepakatan antara peserta kerja praktek dengan pihak PT. Daya Adira Mustika yang dicantumkan di dalam Log Activity yang dapat dilihat pada Lampiran E.
1.2.1 Proses Pembangunan Coding Standard
Tujuan dari pembangunan dokumen ini adalah menyediakan coding standar untuk pengembangan source code yang dibuat dalam bahasa VB.net. Dengan mengikuti aturan standar coding membuat team development menjadi lebih efisien dalam proses pengembangan dgn biaya yang effective pada saat perawatan suatu aplikasi.
Berikut adalah beberapa informasi tentang aturan standar koding untuk pengembangan source code yang telah di buat, seperti :
a. Formatting
b. Pedoman dalam pembuatan Class layout,Indicating Scope/Ruang, Indentation & Braces, White space, Long lines pada kode.
c. Dalam pemberian komentar
Pedoman Penggunaan Single Line Comments, End-Of-Line Comments, ‘ TODO: Comments.
d. Pedoman Penggunaan Single Line Comments, End-Of-Line Comments, ‘ TODO: Comments.
e. Pedoman Pengkapitalan dan Penamaan yang harus diperhatikan pada saat proses coding.
f. Style pemrograman pada source code.
Pedoman dalam pembuatan namespaces, class dan structures, interface, konstanta, enumerasi, variable , fields, parameter, properties,
(21)
metode yang digunakan, event handlers dan pembuatan penanganan error.
1.2.2 Proses Pendokumentasian Pada Perangkat Lunak
Pada tahapan ini dimulai dengan membuat deskripsi perancangan mengenai perangkat lunak yang akan didokumentasikan sesuai dengan IEEE Std 1016-1987 mengenai informasi minimal yang harus ada dalam deskripsi perancangan perangkat lunak. Dokumen ini dibuat untuk membantu membuat pengembangan perancangan perangkat lunak yang akan dikembangkan dengan ancangan berorientasi proses. Pada prinsipnya, hasil analisis sistem perangkat lunak dengan ancangan ini diuraikan sebagai sekumpulan proses yang terorganisasi secara hirarkis. Proses-proses tersebut saling berkomunikasi melalui suatu jalur aliran data. Berikut adalah tahapan-tahapan yang harus dibuat penulis dalam pembangunan dokumentasi pada perangkat lunak
1. Bagian pendahuluan
Pada bagian Pendahuluan ini penulis di haruskan memberikan gambaran umum dari seluruh isi dokumen. Pendahuluan harus berisi bagian-bagian berikut:
a. Tujuan
Bagian yang menunjukkan tujuan dari pembuatan dokumen secara umum.
b. Lingkup Masalah
Bagian ini mengidentifikasi lingkup produk perangkat lunak yang diracncang
c. Definisi, Akronim dan Singkatan
Harus memberikan penjelasan terhadap semua definisi, akronim dan singkat yang digunakan agar dapat menginterpretasikan dokumen dengan benar dan satu arti. Informasi ini dapat dibuat pada lampiran atau dokumen terpisah. Pada kasus ini, bagian ini diisi dengan rujukan ke lampiran atau dokumen yang dimaksud. d. Referensi
(22)
Bagian ini harus memberikan:
i. Daftar lengkap dari dokumen (baik itu berupa buku, panduan, atau spesifikasi/deskripsi lain) yang dirujuk pada dokumen ini.
ii. Identifikasi dari setiap dokumen berdasarkan judul, nomor dokumen (bila ada), tanggal dan organisasi penerbit.
iii. Bila perlu, sebutkan sumber-sumber atau organisasi yang dapat memberikan referensi yang dituliskan tersebut.
e. Deskripsi Umum Dokumen
Bagian ini adalah ikhtisar dari dokumen DPPL. Tuliskan sistematika pembahasan dokumen DPPL ini. Pada bagian ini, dijelaskan pula tentang proses transformasi dari DFD ke dalam bentuk rancangan.
2. Deskripsi Umum Dokumen
Bagian ini adalah ikhtisar dari dokumen. Penulis harus menuliskan sistematika pembahasan dokumen ini. Dan menjelaskan pula tentang proses transformasi dari DFD ke dalam bentuk rancangan.
3. Rancangan Lingkungan Implementasi
Menuliskan lingkungan implementasi pengembangan perangkat lunak. Pada bagian ini diharuskan menuliskan Sistem Operasi, DBMS, Development Tools, Filling System, Bahasa Pemrograman yang dipakai. 4. Dekomposisi Fungsional Modul
Menjelaskan dekomposisi logik dari modul. Pada bagian ini berisi tabel dengan kolom Modul, Proses, Keterangan. Kolom keterangan hanya diisi jika proses tidak tergambarkan dalam DFD. Misalnya untuk proses-proses yang mewakili suatu library umum
5. Deskripsi Data
Berisi mengenai deskripsi tabel-tabel.. Diamana Untuk setiap tabel mengandung Nama tabel, jenisnya, Volume, laju, primary key, constraint integrity dengan tabel lain..
(23)
6. Dekomposisi Fisik Modul
Berisi dekomposisi “fisik” dari modul. Minimal berisi tabel dengan kolom: Sub Aplikasi, Modul, Nama File, Input, Output. Sub Aplikasi biasanya dibuat per pengguna. dibuat per modul
7. Deskripsi Rinci Modul
Deskripsi supaya modul dapat diprogram. Dibuat sesuai dengan jenis proses. Jika perlu, dilengkapi dengan algoritma atau pernyataan SQL-like (untuk aplikasi berbasis data)..Algoritma yang ditulis harus cukup jelas untuk dapat diprogram, tetapi bukan merupakan kode program. Yang penting, dengan rancangan ini, kode program dapat dibuat.
8. Deskripsi Layar
Sketsa layar dilengkapi dengan objek-objek yang didalamnya. Awali dengan Daftar layar yang akan dibuat subbab detilnya. Satu subbab untuk setiap layar.
9. Nama Layar
Dibuat satu sub bab untuk setiap layar Sebutkan identitas layar dan deskripsinya.. Lay Out Layar Gambarkan rancangan layar
a. Deskripsi Objek
Minimal berisi sebuah tabel dengan kolom : objek, jenisnya (button, link, ..) dan keterangan.
b. Algoritma
Jika ada lagoritma/program yang harus dibuat, tuliskan. Pada umumnya, untuk program berbasis GUI, penanganan layar dilakukan tools sehingga bagian ini tidak perlu diisi
10.Deskripsi Proses a. Nama Proses
Menyebutkan identitas dan deskripsi proses. i. Deskripsi Masukan
Nama data atau table yang menjadi masukan ii. Deskripsi Keluaran
(24)
iii. Algoritma
Algoritma proses b. Deskripsi Laporan
Untuk modul yang menghasilkan laporan, berisi lay out laporan. Satu subbab untuk setiap laporan Awali dengan Daftar Laporan yang akan dibuat detilnya
i. Nama Laporan
Sebutkan identitas dan deskripsi Laporan ii. Tata Letak Laporan
Deskripsikan lay out dari laporan iii. Deskripsi Masukan
Sebutkan tabel atau input parameter yang dipakai sebagai masukan laporan.
iv. Algoritma
Algoritma untuk menghasilkan report tersebut. menggunakan wizard (seperti dalam MS mAccess) maka tuliskan nama wizard yang akan dipakai.
11.Matriks Keterurutan
Bagian ini menunjukkan hubungan dari kebutuhan perangkat lunak dan deskripsi perancangan. Matriks ini digambarkan dalam bentuk tabel dengan kolom-kolom Nomor SKPL, Nama Layar, Nama Proses, dan Nama Laporan.
12.Memberikan Informasi Tambahan a. Daftar isi dan Index
Daftar isi dan index sesuai dengan standard yang ada. b. Memberikan Lampiran
Lampiran dapat berisi:
i. Contoh tampilan layar atau contoh laporan ii. Dukungan informasi yang membantu.
iii. Instruksi khusus, dan media yang perlu disiapkan untuk implementasi, dan kebutuhan lain.
(25)
1.2.3 Pelaporan Hasil Kerja
Proses pelaporan hasil kerja praktek dilakukan pada tahap akhir kerja praktek di PT. Daya Adira Mustika. Pelaporan hasil kerja praktek ini dilakukan melalui pembuatan laporan kerja praktek.
1.3Pencapaian Hasil
Adapun hasil yang dicapai selama kerja praktek di PT. Daya Adira Mustika ini berupa Dokumentasi Standard coding yang akan diterapkan pada proses pengembangan perangkat lunak selanjutnya dan beberapa dokumentasi perangkat lunak. Dokumentasi ini terdiri dari beberapa dokumen sebagai berikut:
1. Deskripsi pada Aplikasi manajemen asset 2. Spesifikasi pada Aplikasi Manajemen asset 3. Spesifikasi Modul Laporan Titipan Gantung 4. Spesifikasi Modul Laporan AP AGING 5. Spesifikasi Modul Laporan mutasi hutang 6. Spesifikasi Modul Laporan PDC Bayar JTO
7. Spesifikasi Modul Laporan Cetak Rencana Bayar AP 8. Spesifikasi Modul Laporan Penerimaan Kasir
9. Spesifikasi Modul Laporan AR Aging 10.Spesifikasi Modul Laporan Kartu AR 11.Spesifikasi Modul Laporan Titipan Gantung 12.Spesifikasi Modul Laporan PDC Gantung 13.Spesifikasi Modul Laporan PDC Tolak
14.Spesifikasi Modul Laporan Cetak Tagihan AR
Beberapa tampilan hasil akhir dari dokumen mengenai Spesifikasi Program dan Coding Standard yang telah dibuat dan didokumentasikan dapat dilihat pada Lampiran A. Secara garis besar, informasi yang tersedia dalam dokumen yang dibuat adalah sebagai berikut:
(26)
Berisi tentang keterangan penjelasan (narrative description) yang berisi keterangan-keterangan tulisan mengenai program. meliputi tujuan program, struktur program, daya yang dibutuhkan, prosedur-prosedur, bentuk-bentuk input / output atau informasi-informasi yang berguna bagi mereka yang berhubungan dengan program.
2. Standarisasi Koding
Berisi informasi tentang aturan standar koding untuk pengembangan source code yang di buat, seperti :
g. Formatting
h. Pedoman dalam pembuatan Class layout,Indicating Scope/Ruang, Indentation & Braces, White space, Long lines pada kode.
i. Dalam pemberian komentar
Pedoman Penggunaan Single Line Comments, End-Of-Line Comments, ‘ TODO: Comments.
j. Pedoman Penggunaan Single Line Comments, End-Of-Line Comments, ‘ TODO: Comments.
k. Pedoman Pengkapitalan dan Penamaan yang harus diperhatikan pada saat proses coding.
l. Style pemrograman pada source code.
Pedoman dalam pembuatan namespaces, class dan structures, interface, konstanta, enumerasi, variable , fields, parameter, properties, metode yang digunakan, event handlers dan pembuatan penanganan error.
Dokumen-dokumen teknis tersebut ada sebagian tidak disertakan dalam laporan kerja praktek ini karena kebijakan PT. Daya Adira Mustika tidak memperbolehkan publikasi dokumen tersebut. Dengan keberhasilan pembuatan dokumentasi ini, terbuka kemungkinan yang cukup besar untuk memudahkan bagi pemakai maupun pengembangan yang akan mengembangkan aplikasi.
(27)
27 BAB IV
KESIMPULAN DAN SARAN
1.1Kesimpulan Pelaksanaan Kerja Praktek
1. Mahasiswa dapat mengaplikasikan ilmu yang diperoleh selama perkuliahan untuk menyelesaikan permasalahan di dunia nyata.
2. Mahasiswa dapat mengetahui ilmu dan keterampilan yang dibutuhkan untuk memasuki dunia kerja di era globalisasi, seperti:
a) Keterampilan berkomunikasi dan bekerja sama dengan orang lain. b) Ilmu dasar mengenai bidang spesifik yang diperoleh selama
perkuliahan. Misalnya ilmu dasar di bidang informatika, ilmu dasar di bidang ekonomi, dan sebagainya.
c) Keterampilan menganalisis permasalahan untuk dicari solusinya. d) Ilmu pengetahuan umum.
e) Keterampilan mempelajari hal yang baru dalam waktu relative singkat.
3. Mahasiswa menyadari pentingnya etos kerja yang baik, disiplin, dan tanggung jawab dalam menyelesaikan suatu pekerjaan.
4. Kerja praktek dapat melatih mahasiswa untuk bekerja sama dalam suatu tim, baik antar peserta kerja praktek maupun dengan karyawan lain di PT. Daya Adira Mustika.
5. Mahasiswa memperoleh tambahan ilmu yang tidak diperoleh di proses perkuliahan. Pada kerja praktek yang dilakukan di PT. Daya Adira Mustika, mahasiswa mendapatkan pengetahuan tambahan mengenai cakupan pekerjaan divisi pengembangan perangkat lunak secara mendetail, seperti pembuatan proses bisnis, pengetesan perangkat lunak (QA), programing perangkat lunak, mekanisme pelaksanaan pengembangan perangkat lunak.
(28)
1.2Saran Pelaksanaan KP
Adapun saran mengenai pelaksanaan kerja praktek antara lain:
1. Perlu ditumbuhkan kebiasaan belajar secara mandiri (self-learning) di kalangan mahasiswa, khususnya dalam mempelajari teknologi secara aplikatif. Salah satu fasilitas yang tersedia yang mendukung proses pembelajaran secara mandiri ini adalah koneksi internet yang cukup cepat. 2. Perlu adanya kemampuan mahasiswa untuk menggabungkan seluruh ilmu
yang pernah didapat di perkuliahan dalam proses pembangunan perangkat lunak.
3. Perlu adanya bimbingan secara lebih intensif bagi mahasiswa kerja praktek.
4. Jika memungkinkan, dalam pelaksanaan kerja praktek mahasiswa dapat dilibatkan dalam suatu proyek di mana mahasiswa dapat bekerja sama dengan pegawai lain.
(29)
27
METODE DOKUMENTASI
DIVISI PENGEMBANGAN APLIKASI
DI PT DAYA ADIRA MUSTIKA
KERJA PRAKTEK
Diajukan untuk Memenuhi Tugas Mata Kuliah Kerja Praktek
Program Strata Satu Jurusan Teknik Informatika Fakultas Teknik dan Ilmu Komputer
Universitas Komputer Indonesia
MUBASSIRIN
10107773
PROGRAM STUDI TEKNIK INFORMATIKA
FAKULTAS ILMU TEKNOLOGI DAN KOMPUTER
UNIVERSITAS KOMPUTER INDONESIA
2011
(30)
27
DAFTAR ISI
LEMBAR JUDULLEMBAR PENGESAHAN
ABSTRAKSI ... iii
KATA PENGANTAR ... iv
DAFTAR ISI ... vi
DAFTAR LAMPIRAN ... viii
Bab I PENDAHULUAN ...2
1.1 Latar Belakang Masalah ... Error! Bookmark not defined. 1.2 Rumusan Masalah ...2
1.3 Maksud dan Tujuan ...2
1.4 Batasan Masalah ...2
1.5 Sistematika Penulisan ...3
Bab II TINJAUAN PUSTAKA ...4
2.1 Profil Perusahaan ...4
2.1.1 Sejarah Perusahaan ...4
2.1.2 Struktur Organisasi ...5
2.1.3 Ruang Lingkup Pekerjaan ...6
2.1.4 Jadwal Kerja ...6
2.2 Landasan Teori ...7
2.3 Kakas Penunjang ...13
Bab III PEMBAHASAN ...17
3.1 Input ...17
3.2 Proses Kerja ...17
3.2.1 Proses Pembangunan Coding Standard ...18
3.2.2 Pembangunan Dokumentasi Perangkat Lunak ...19
3.2.3 Pelaporan Hasil Kerja ...23
3.3 Pencapaian Hasil ...23
Bab VI KESIMPULAN DAN SARAN ...25
(31)
4.2 Saran Pelaksanaan ...26 Bab V Daftar Pustaka ...27
(32)
27
DAFTAR PUSTAKA
[1] Desenta, S., Santoso, A., Laporan Kerja Praktek: Pembangunan Perangkat Lunak Ksatria Medical System Extension Prototype di PT. Mitrais, Departemen Teknik Informatika, 2005
[2] Nareswari, A., Puspitasari, I., Mandasari, T., Laporan Kerja Praktek: Pembangunan Sistem Informasi Karyawan (SIMKA) di PT. Berdikari (Persero) Jakarta, Departemen Teknik Informatika, 2005 [3] Russell, Stuart J., Artificial Intelligence, A Modern Approach, Prentice-Hall [4] Panduan Pengisian Deskripsi Perancangan Perangkat Lunak Berorientasi
Proses
[5] IEEE Std 1016-1987, IEEE Recommended Practice for Software Requirement Specifications.
[6] IEEE Std 610.12-1990 IEEE Standard Glossary of Software Engineering Terminology (ANSI).
(33)
27
KATA PENGANTAR
Segala puji dan syukur penulis panjatkan kepada Allah SWT yang telah memberikan taufik serta hidayah-Nya, sehingga penulis dapat menyelesaikan penulisan laporan praktik kerja ini. Dalam penyusunan laporan praktik kerja ini penulis telah berusaha semampu mungkin menuangkan kemampuan yang ada, namun karena adanya keterbatasan waktu dan pengetahuan penulis sehingga kiranya masih terdapat kekurangan. Oleh karena itu, penulis harapkan adanya saran dan kritikan yang membangun dari berbagai pihak demi penyempurnaan laporan praktik kerja ini.
Pada kesempatan ini dengan penuh rendah hati, penulis ingin menyampaikan rasa terima kasih kepada semua pihak, terutama:
1. Bapak Iskandar Ikbal,ST. selaku dosen pembimbing praktik kerja juga sebagai koordinator praktik kerja yang telah membantu mengorganisir jalannya praktik kerja kami.
2. Bapak Risnandi Abadi, selaku pembimbing lapangan praktik kerja di PT Daya Adira Mustika.
3. Bapak Hasdi, selaku manajer IT yang telah memberi izin untuk melaksanakan praktik kerja di PT Daya Adira Mustika.
4. Seluruh karyawan PT Daya Adira Mustika, khususnya bagian Pengembangan Aplikasi, atas semua bantuan yang diberikan selama berlangsungnya kegiatan praktik kerja.
5. Kedua orang tuaku, serta seluruh keluarga penulis yang telah membantu dalam menyelesaikan kegiatan praktik kerja.
6. Teman - teman yang telah membantu selama proses pembuatan laporan praktek kerja ini.
7. Semua pihak yang tidak bisa penulis sebutkan satu per satu dalam membantu dalam penulisan laporan praktik kerja ini.
Walaupun masih jauh dari kesempurnaan, namun penulis berharap semoga apa yang terkandung di dalamnya dapat berguna dan bermanfaat bagi orang
(34)
banyak. Akhir kata penulis berharap semoga Allah SWT memberikan rahmat dan hidayah-Nya kepada kita semua atas amal baik yang telah kita lakukan.
Bandung, Februari 2010 Penulis
(35)
27
(1)
27
DAFTAR ISI
LEMBAR JUDULLEMBAR PENGESAHAN
ABSTRAKSI ... iii
KATA PENGANTAR ... iv
DAFTAR ISI ... vi
DAFTAR LAMPIRAN ... viii
Bab I PENDAHULUAN ...2
1.1 Latar Belakang Masalah ... Error! Bookmark not defined. 1.2 Rumusan Masalah ...2
1.3 Maksud dan Tujuan ...2
1.4 Batasan Masalah ...2
1.5 Sistematika Penulisan ...3
Bab II TINJAUAN PUSTAKA ...4
2.1 Profil Perusahaan ...4
2.1.1 Sejarah Perusahaan ...4
2.1.2 Struktur Organisasi ...5
2.1.3 Ruang Lingkup Pekerjaan ...6
2.1.4 Jadwal Kerja ...6
2.2 Landasan Teori ...7
2.3 Kakas Penunjang ...13
Bab III PEMBAHASAN ...17
3.1 Input ...17
3.2 Proses Kerja ...17
3.2.1 Proses Pembangunan Coding Standard ...18
3.2.2 Pembangunan Dokumentasi Perangkat Lunak ...19
3.2.3 Pelaporan Hasil Kerja ...23
3.3 Pencapaian Hasil ...23
Bab VI KESIMPULAN DAN SARAN ...25
(2)
4.2 Saran Pelaksanaan ...26 Bab V Daftar Pustaka ...27
(3)
27
DAFTAR PUSTAKA
[1] Desenta, S., Santoso, A., Laporan Kerja Praktek: Pembangunan Perangkat Lunak Ksatria Medical System Extension Prototype di PT. Mitrais, Departemen Teknik Informatika, 2005
[2] Nareswari, A., Puspitasari, I., Mandasari, T., Laporan Kerja Praktek: Pembangunan Sistem Informasi Karyawan (SIMKA) di PT. Berdikari (Persero) Jakarta, Departemen Teknik Informatika, 2005 [3] Russell, Stuart J., Artificial Intelligence, A Modern Approach, Prentice-Hall [4] Panduan Pengisian Deskripsi Perancangan Perangkat Lunak Berorientasi
Proses
[5] IEEE Std 1016-1987, IEEE Recommended Practice for Software Requirement Specifications.
[6] IEEE Std 610.12-1990 IEEE Standard Glossary of Software Engineering Terminology (ANSI).
(4)
27
KATA PENGANTAR
Segala puji dan syukur penulis panjatkan kepada Allah SWT yang telah memberikan taufik serta hidayah-Nya, sehingga penulis dapat menyelesaikan penulisan laporan praktik kerja ini. Dalam penyusunan laporan praktik kerja ini penulis telah berusaha semampu mungkin menuangkan kemampuan yang ada, namun karena adanya keterbatasan waktu dan pengetahuan penulis sehingga kiranya masih terdapat kekurangan. Oleh karena itu, penulis harapkan adanya saran dan kritikan yang membangun dari berbagai pihak demi penyempurnaan laporan praktik kerja ini.
Pada kesempatan ini dengan penuh rendah hati, penulis ingin menyampaikan rasa terima kasih kepada semua pihak, terutama:
1. Bapak Iskandar Ikbal,ST. selaku dosen pembimbing praktik kerja juga sebagai koordinator praktik kerja yang telah membantu mengorganisir jalannya praktik kerja kami.
2. Bapak Risnandi Abadi, selaku pembimbing lapangan praktik kerja di PT Daya Adira Mustika.
3. Bapak Hasdi, selaku manajer IT yang telah memberi izin untuk melaksanakan praktik kerja di PT Daya Adira Mustika.
4. Seluruh karyawan PT Daya Adira Mustika, khususnya bagian Pengembangan Aplikasi, atas semua bantuan yang diberikan selama berlangsungnya kegiatan praktik kerja.
5. Kedua orang tuaku, serta seluruh keluarga penulis yang telah membantu dalam menyelesaikan kegiatan praktik kerja.
6. Teman - teman yang telah membantu selama proses pembuatan laporan praktek kerja ini.
7. Semua pihak yang tidak bisa penulis sebutkan satu per satu dalam membantu dalam penulisan laporan praktik kerja ini.
Walaupun masih jauh dari kesempurnaan, namun penulis berharap semoga apa yang terkandung di dalamnya dapat berguna dan bermanfaat bagi orang
(5)
banyak. Akhir kata penulis berharap semoga Allah SWT memberikan rahmat dan hidayah-Nya kepada kita semua atas amal baik yang telah kita lakukan.
Bandung, Februari 2010 Penulis
(6)
27