Software Documentation

dokumen-dokumen yang mirip
Software Requirements

Software Project Management


PENGANTAR RUP & UML. Pertemuan 2

Chapter 2 What is Software Quality?

BAB I PENDAHULUAN. 1.1 Latar Belakang

SOFTWARE DEVELOPMENT PLAN. Program Studi S1 - Sistem Informasi

Pemodelan Berorientasi Objek

Project IT Organization

MANAJEMEN PROYEK FRAMEWORK

KONSEP & TEKNIK PEMELIHARAAN PERANGKAT LUNAK. Tugas ke 12 Rekayasa Perangkat Lunak

Analisis dan Perancangan Sistem Hanif Al Fatta M.kom

Manajemen Lingkup Proyek. Information Technology Project Management, Fourth Edition

Software Proses. Model Proses Perangkat Lunak. Pengembangan Perangkat Lunak. Framework activities 3/20/2018. System Development Life Cycle (SDLC)

System Development Life Cycle (SDLC)

PEMBUATAN APLIKASI MANAJEMEN PROYEK DALAM MENGELOLA PROYEK DI PT. X

PEMELIHARAAN PERANGKAT LUNAK (SOFTWARE MAINTENANCE)

Proses Dokumentasi. Area utama dokumentasi ada empat :

EDU SOFT. Statement Of Work

REQUIREMENT ENGINEERING

BAB 1 PENDAHULUAN 1.1 Latar Belakang

PERANCANGAN PERANGKAT LUNAK KARYAWAN TETAP UNTUK CV. TIGA PUTRA UTAMA DI UJUNG BERUNG BANDUNG.

MANAJEMEN RUANG LINGKUP PROYEK PERTEMUAN 3.2

METODE DAN TEKNIK PENGEMBANGAN SISTEM INFORMASI

SDLC Concepts. Muhammad Yusuf D3 Manajemen Informatika Universitas Trunojoyo

BAB 1 PENDAHULUAN. tersebut adalah metode pemodelan (notation), proses (process) dan tool yang

PENGENALAN. Perancangan Perangkat Lunak. (Software Engineering) Bertalya Program Pascasarjana Univesitas Gunadarma

Proyek Perangkat Lunak

Pengembangan Sistem Informasi

A. Model Desain Perangkat Lunak

Configuration Management

MODEL DESAIN & DOKUMENTASI DESAIN

MODUL 4 Unified Software Development Process (USDP)

BAB 1 PENDAHULUAN 1.1 Latar Belakang Masalah

PROSES DESAIN. 1. Metodologi Pengembangan Sistem

Teknik Informatika S1

Pertemuan 1 PENGENALAN REKAYASA PERANGKAT LUNAK

Rational Unified Process (RUP)

BAB 3 Analisa dan Perancangan Sistem

BAB 1 PENDAHULUAN 1.1 Latar Belakang

Rekayasa Perangkat Lunak (Software Engineering)

Bab 1 PENDAHULUAN UKDW

BAB 3 PERENCANAAN PROYEK

BAB 1 PENDAHULUAN. 1.1 Latar Belakang

Manajemen Proyek. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 1 Slide 1

PROJECT CHARTER. Project Number: 01. Project Name: Sistem Informasi Koperasi Karyawan Studi Kasus Stikom Surabaya

SIKLUS REKAYASA PERANGKAT LUNAK (SDLC)

BAB 3 PERENCANAAN PROYEK

SDLC Software Development Life Cycle Mukhlas Imam Muhajir Muhsin Nur Ali

TEKNIK DOKUMENTASI APLIKASI 12.1 STIKOM SURABAYA. PENGEMBANGAN DOKUMENTASI APLIKASI Pertemuan 2

BAB III METODOLOGI PENELITIAN. Metode pengumpulan data yang digunakan pada penelitian ini berupa studi

E-PLANNING SYSTEM PROJECT MANAGEMENT PLAN

Implementasi Sistem dan Maintenace Sistem. Sistem Informasi Universitas Gunadarma 2012/2013

Review & Summarize REKAYASA KEBUTUHAN PERANGKAT LUNAK ABOERYZAL AHMED KOESYAIRY / IMAM AFANDI AHMAD /

SDLC : Project Planning

Rekayasa Perangkat Lunak

Nama : Rendi Setiawan Nim :

BAB I PENDAHULUAN 1.1 Latar Belakang

FASE PERENCANAAN. MPSI sesi 4


Rekayasa Perangkat Lunak

Requirement? Teknik Informatika S1. Definisi. Rekayasa Perangkat Lunak. Pengertian Requirement. Pengertian Requirement Engineering

STMIK AMIKOM YOGYAKARTA

1. BAB 1 PENDAHULUAN. 1.1 Latar Belakang

SOFTWARE ENGINEERING (REKAYASA PERANGKAT LUNAK)

REKAYASA PERANGKAT LUNAK

Review Rekayasa Perangkat Lunak. Nisa ul Hafidhoh

BAB II LANDASAN TEORI

PENGEMBANGAN SISTEM INFORMASI MANAJEMEN PRAKTIK INDUSTRI DI JURUSAN PENDIDIKAN TEKNIK ELKTRONIKA UNY BERBASIS WEBSITE MENGGUNAKAN YII FRAMEWORK

Ringkasan Chapter 12 Developing Business/ IT Solution

BAB 3 PERENCANAAN PROYEK

Inisiasi, Perencanan dan Esekusi dalam Proyek

PERANAN TEAM SOFTWARE PROCESS PADA REKAYASA PERANGKAT LUNAK

BAB 1 PENDAHULUAN. 1.1 Latar Belakang

METODOLOGI PENGEMBANGAN SOFTWARE

BAB III LANDASAN TEORI

The Process. A Layered Technology. Software Engineering. By: U. Abd. Rohim, MT. U. Abd. Rohim Rekayasa Perangkat Lunak The Process RPL

REKAYASA PERANGKAT LUNAK I

Piranti Perencanaan dan Pengawasan Mutu dalam Manajemen Proyek Sistem Informasi

BAB III LANDASAN TEORI. mengumpulkan (input), memanipulasi (process), menyimpan, dan menghasilkan

BAB 1 PENDAHULUAN. 1.1 Latar Belakang

PROJECT MANAGEMENT PLAN RANCANG BANGUN SISTEM INFORMASI PENERIMAAN DAN SELEKSI PEGAWAI MENGGUNAKAN METODE MANAGEMENT BY OBJECTIVE

DAFTAR ISI. Abstraksi... Kata Pengantar... Daftar Isi... Daftar Tabel... Daftar Gambar... Daftar Lampiran... BAB I PENDAHULUAN...

REKAYASA PERANGKAT LUNAK. 3 sks Sri Rezeki Candra Nursari reezeki2011.wordpress.com

BAB 1 PENDAHULUAN. 1.1 Latar Belakang

BAB 1 PENDAHULUAN 1.1 Latar Belakang

DAFTAR ISI... HALAMAN JUDUL... HALAMAN PERNYATAAN PERSETUJUAN... HALAMAN PENGESAHAN... MOTTO DAN PERSEMBAHAN... RINGKASAN... KATA PENGANTAR...

Pertemuan 2 SOFTWARE DEVELOPMENT LIFE CYCLE (SDLC)

GARIS-GARIS BESAR PROGRAM PENGAJARAN (GBPP)

REKAYASA PERANGKAT LUNAK 1

BAB 1 PENDAHULUAN. 1.1 Latar Belakang

Tujuan Perkuliahan. PENGANTAR RPL (Pert. 2 chapter 1 Pressman) Agenda. Definisi Software (Perangkat Lunak) Lunak) 23/09/2010

BAB 1 PENDAHULUAN. 1.1 Latar Belakang

Bab 3 Metode Perancangan

FASE PENGEMBANGAN. MPSI sesi 7 & 8

BAB 1 PENDAHULUAN. 1.1 Latar Belakang

BAB 1 PENDAHULUAN. 1.1 Latar Belakang

BAB 1 ASUMSI PERANAN PENGANALISIS SISTEM

1 PENDAHULUAN. 1.1 Latar Belakang

A. Tujuan dan Ruang Lingkup Proyek Perancangan Rekayasa Perangkat Lunak

Transkripsi:

Software Documentation Dokumentasi Pengembangan Perangkat Lunak Husni husni@trunojoyo.ac.id

Dokumentasi Proyek

Kategori Dokumentasi Proyek Software Dokumentasi Proyek Dokumentasi Proses Rencana Proyek, Gant Chart Dokumen Rapat, Dokumentasi Kebutuhan & Rancangan, Email, Dokumen Test, Dokumen jenis lain Pekerjaan, dll. Dokumentasi Produk Dokumentasi Sistem Dokumentasi Teknis yang diperlukan dalam rangka memelihara software, dll. Panduan Instalasi Dokumentasi Pengguna Manual Pengguna, Wiki, Online Help, dll.

Dokumentasi Proses Proyek Software 1. Software Development Plan (SDP) 2. Software Requirements Specifications (SRS) 3. Software Design Documents (SDD) 4. Software Test Documents (STD)

Kebutuhan & Rancangan Software Requirements (WHAT): WHAT (Apa yang sistem akan lakukan) Mendeskripsikan apa yang sistem akan lakukan dengan Kata dan Gambar, dll. SRS Dokumen Software Requirements Specification Software Design (HOW): HOW (Bagaimana itu akan dilakukan) Contoh: Rancangan GUI, UML, diagram ER, CAD, dll. SDD Software Design Document Catat! Banyak praktisi tidak memisahkan dokumen SRS dan SDD, tetapi menggabungkan ke dalam Requirements & Design Document (SRD). Dalam praktek, requirements dan design tidak dapat dipisahkan.

Dokumen Persyaratan Software Software Requirements Specifications (SRS) Dokumen spesifikasi kebutuhan perangkat lunak (software requirements specifications, SRS) merupakan pernyataan resmi mengenai apa yang diperlukan oleh pengembang sistem. Harus memasukkan definisi dari kebutuhan pengguna dan spesifikasi dari kebutuhan sistem. BUKAN dokumen rancangan (desain). Sejauh mungkin, merupakan APA yang sistem akan kerjakan, bukan BAGAIMANA itu dilakukan.

Struktur Dokumen SRS Bab Kata Pengantar Pendahuluan Daftar Istilah Definisi Kebutuhan Pengguna Arsitektur Sistem Deskripsi Mendefinisikan para pembaca yang diharapkan dari dokumen dan menjelaskan sejarah versinya, termasuk alasan pembuatan versi baru dan suatu rangkuman perubahan yang dibuat pada setiap versi. Menjelaskan kebutuhan bagi sistem. Sebaiknya dengan ringkas mendeskripsikan fungsifungsi sistem dan menyebutkan bagaimana sistem akan bekerja sistem lain. Ini juga harus menjelaskan bagaimana sistem cocok dengan bisnis atau tujuan strategis organisasi secara menyeluruh dengan adanya perangkat lunak. Dengan jelas mendefinisikan istilah-istilah teknis yang digunakan dalam dokumen. Sebaiknya tidak membuat asumsi mengenai pengalaman atau kepakaran pembaca. Di sini, kita menjelaskan layanan-layanan yang tersedia bagi Pengguna. Kebutuhan sistem non-fungsional juga digambarkan dalam bagian ini. Deskripsi dapat menggunakan bahasa alami, diagram atau notasi lain yang dapat dipahami oleh Customer. Standar proses dan produk yang harus diikuti harus ditetatpkan. Bab ini menyajikan suatu tinjauan level tinggi dari arsitektur sistem yang diharapkan, memperlihatkan distribusi fungsi lintas modul-modul sistem. Komponen-komponen arsitektural yang digunakan-ulang perlu disoroti.

Struktur Dokumen SRS Bab Spesifikasi Kebutuhan Sistem Model-model Sistem Evolusi Sistem Lampiran Indeks Deskripsi Harus menjelaskan kebutuhan fungsional dan non-fungsional secara rinci. Jika diperlukan, rincian lebih lanjut dapat pula ditamnbahkan ke kebutuhan non-fungsional. Antarmuka ke sistem lain dapat didefinisikan. Ini dapat menyertakan model-model sistem grafis yang memperlihatkan hubungan antara komponen-komponen sistem dengan sistem dan sistem tersebut dengan lingkungannya. Contoh dari model yang mungkin adalah model Obyek, data-flow atau data semantik. Bab ini menjelaskan asumsi-asumsi fundamental yang dijadikan basis bagi sistem, dan perubahan yang diharapkan dikarenakan evolusi hardware, kebutuhan pengguna yang berubah, dsb. Bagian ini berguna bagi Perancang sistem karena akan membantu Perancang menghindari keputusan rancangan yang akan membatasi kemungkinan perubahan di masa depan terhadap sistem. Ini harus menyediakan informasi spesifik dan rinci yang terkait dengan aplikasi yang dikembangkan; misalnya deskripsi hardware dan database. Kebutuhan hardware mendefinisikan konfigurasi minimal dan optimal bagi sistem. Kebutuhan basis data mendefinisikan organisasi logis dari data yang digunakan oleh sistem dan relasi antar data. Beberapa indeks terhadap dokumen dapat disertakan. Selain indeka alfabet biasa, tambahan indeks diagram, fungsi, dll. tentu sangat menarik dan memudahkan pencarian informasi tertentu di dalam dokumen.

Persyaratan Dokumentasi Software Harus bertindak sebagai media komunikasiantara anggota Tim Pengembangan Repositori informasi yang digunakan oleh Insinyur Pemeliharaan Sistem Informasi bagi Manajemen untuk membantu mereka Merancang, Menganggarkan, dan Menjadwalkan Proses Pengembangan Software Beberapa dokumen harus memberitahukan pengguna bagaimana menggunakan dan mengelola sistem tersebut Dokumen untuk Kendali Kualitas, Sertifikasi Sistem, dll.. => Memenuhi persyaratan ini membutuhkan berbagai jenis dokumen mulai dari dokumen kerja informal s.d Manual Pengguna yang diproduksi secara profesional

Dokumentasi Software Jika dokumentasinya tidak berguna, jangan buatkan!!

Dokumentasi Software (Produk) Dokumentasi Sistem/Teknis Diagram Class Diagram State Diagra Sequence Komentar dalam Kode Dokumentasi Pengguna Manual Pengguna Panduan Instalasi Wiki Dokumentasi & Bantuan Online

Dokumentasi Software Untuk proyek besar, biasanya untuk memperoleh hasil yang baik, dokumentasi dimulai sebelum proses pembangunan dimulai Himpunan dokumen yang harus dihasilkan tergantung pada Kontrak dengan klien pengguna sistem (pelanggan) Jenis sistem yang dikembangkan Umur hidup yang diharapkan Budaya perusahaan Ukuran perusahaan yang mengembangkan sistem Jadwal pembangunan

Programmer Malas Membuat Dokumen ;-) Tetapi wajib!!!

Dokumentasi Proyek Software Dokumentasi yang dihasilkan selama proyek software dapat dibagi ke dalam 2 kategori: Dokumentasi Proses Dokumen ini merekam proses pengembangan dan perawatan, seperti Rencana (Software Development Plan, Software Test Plan,...), Jadwal (e.g., Gantt Charts), dll. Dokumentasi Produk Dokumen ini menjelaskan produk yang dikembangkan. Dapat dibagi ke dalam 2 kategori: Dokumentasi Sistem Digunakan oleh insinyur dalam pengembangkan dan memelihara sistem Dokumentasi Pengguna Digunakan oleh orang-orang yang menggunakan sistem.

Dokumentasi Proses Proyek

Dokumentasi Proses Tujuan: Dokumentasi proses dihasilkan sehingga pengembangan sistem dapat dikelola Merupakan suatu komponen penting dari pendekatan digerakkan rencana (plandriven, seperti Waterfall) Pendekatan cerdas (agile): Tujuannya adalah untuk meminimalkan jumlah Dokumentasi Proses.

Dokumentasi Proses Kategori: 1. Rencana, Estimasi & Jadwal. These are documents produced by managers which are used to predict and to control the software process. 2. Laporan-laporan. These are documents which report how resources were used during the process of development. 3. Standar-standar. These are documents which set out how the process is to be implemented. These may be developed from organizational, national or international standards. 4. Naskah Ilmiah. These are often the principal technical communication documents in a project. They record the ideas and thoughts of the engineers working on the project, are interim versions of product documentation, describe implementation strategies and set out problems which have been identified. They often, implicitly, record the rationale for design decisions. 5. Pesan E-mail, Wiki, dll. These record the details of everyday communications between managers and development engineers.

Software Development Plan (SDP) Suatu SDP normalnya memasukkan bagian-bagian berikut: 1. Pendahuluan: This briefly describes the objectives of the project and set out the constraints (e.g., budget, time, etc.) that affects the management of the project 2. Organisasi Proyek (Team Description) This section describes how the development team is organized, the peaople involved and their roles in the team. Software Process Model Description (Scrum, XP, Waterfall,...), etc. 3. Analisa Resiko 4. Kebutuhan Sumber Daya Hardware dan Software 5. Work Breakdown (WBS, Work Breakdown Structure): Memecah proyek ke dalam aktifitas-aktifits dan memahami milestone-nya. 6. Project Schedule: Shows dependencies between activities, the estimated time required to reach each milestone, allocation of people to activities. (5) and (6) is typically done in a Gantt Chart (created in e.g. Microsoft Project) 7. Monitoring and Reporting Mechanisms: Definition of the Management Report that should be produced, when thes should be produced, etc. 8. Perangkat yang Tools that you are using

Gantt Chart

Dokumentasi Pengujian Dokumen ini akan menjadi fondasi untuk semua Pengujian

Dokumentasi Produk

Dokumentasi Produk Tujuan: Describing the delivered software product Unlike most process documentation, it has a relatively long life. It must Evolve in step with the product that it describes. Product documentation includes User documentation, which tells users how to use the software product, System Documentation, which is principally intended for maintenance engineers.

Jenis & Pembaca Dokumentasi Produk Manajer & Evaluator Sistem Menyediakan suatu ikhtisar dari tujuan sistem dan mendeskripsikan layanan sistem yang paling penting Administrator Sistem Menjelaskan cara instalsi sistem pada platform yang diharapkan Pengguna Baru Pengguna Berpengalaman Ringkas, menjelaskan cara memulai program itu Sediakan deskripsi rinci setiap fasilitas Sistem Untuk memenuhi kelas-kelas berbeda dari pengguna dan berbagai tingkat keahlian pengguna, beberapa dokumen (atau mungkin bab dalam satu dokumen) harus diserahkan bersama dengan sistem softwarenya.

Dokumentasi Produk Dokumentasi Pengguna (User Documentation)

Dokumentasi Pengguna

Pembaca Dokumentasi Pengguna Pengguna dari suatu sistem tidak semuanya sama. Penghasil dokumen harus menstrukturkannya untuk memenuhi tugas-tugas pengguna berbeda dan level-level berbeda dari pengalaman dan kepakaran. Hal ini sangat penting untuk membedakan antara pengguna (end-user) dan administrator sistem : 1. Pengguna menggunakan software untuk membantu dengan beberapa tugas. Ini dapat menerbangkan pesawat, mengelola kebijakan asuransi, menulis buku, dll Mereka ingin tahu bagaimana software dapat membantu mereka. Mereka tidak tertarik pada komputer atau administrasi rinci. 2. Administrator Sistem bertanggungjawab mengelola software yang digunakan Pengguna. Ini dapat mencakup tindakan sebagai operator jika sistemnya merupakan sistem mainframe besar, sebagai network manager jika sistem mencakup jaringan workstations atau sebagai technical guru yang membetulkan masalah software pengguna dan yang bertindak sebagai penghubung antara pengguna dan pemasok software.

Manual Pengguna

Wiki

Dokumentasi Produk Dokumentasi Sistem

Dokumentasi Sistem

Dokumentasi Sistem Dokumentasi sistem termasuk semua dokumen yang menjelaskan sistem itu sendiri mulai dari spesifikasi persyaratan s.d rencana uji penerimaan akhir. Dokumen yang menggambarkan desain, implementasi dan pengujian sistem adalah penting jika program ini ingin dipahami dan dipelihara. Seperti dokumentasi pengguna, dokumentasi sistem terstruktur penting sekali, dengan ikhtisar mengarahkan pembaca menuju deskripsi yang lebih formal dan rinci dari setiap aspek dari sistem.

Dokumentasi Kode

Dokumentasi Sistem Untuk sistem yang besar yang dikembangkan dengan spesifikasi pelanggan, dokumentasi sistem harus mencakup : 1. Dokumen Kebutuhan. 2. Dokumen yang menjelaskan Arsitektur Sistem. 3. Untuk setiap program dalam sistem, deskripsikan arsitektural dari program tersebut. 4. Untuk setiap komponen dalam sistem, deskripsikan fungsionalitas dan antarmukanya. 5. Daftar source code dari program, sebaiknya dikomentari dimana komentar harus menjelaskan bagian kompleks dari kode dan menyediakan alasan penggunaan metode coding itu. Jika nama-nama bermakna digunakan dan gaya pemrograman terstruktur (yang bagus) digunakan, banyak dari kode sudah self documenting tanpa perlu komentar tambahan. Informasi ini dapat dipelihara secara elektoronik, bukan di kertas, informasi penting dicetak jika PERLU. 6. Dokumen Validasi menjelaskan bagaimana setiap program divalidasi dan bagaimana informasi validasi tersebut terkait dengan kebutuhan. Ini diperlukan untukproses penjaminan kualitas dalam organisasi. 7. Panduan Pemeliharaan Sistem, yang menjelaskan masalah-masalah yang diketahui pada sistem, menjelaskan bagian sistem yang bergantung pada hardware dan software dan bagaimana evolusi sistem ditentukan saat perancangan.

Sequence Diagrams UML Use Case Diagrams Class Diagrams

Diagram ER dari Database: Contoh

Rangkuman

Referensi I. Sommerville, Software Engineering: Pearson, 2015. Wikipedia. (2013). Scrum Development. Available: http://en.wikipedia.org/wiki/scrum_(development) Wikipedia. (2013). Agile Software Development. Available: http://en.wikipedia.org/wiki/agile_software_development CoreTrek. (2013). Scrum i et nøtteskall. Available: http://www.coretrek.no/scrum-i-et-noetteskall/category642.html

Pertanyaan?