Use Case Diagram: Sistem Aplikasi Pendaftaran Layanan PPDB Online Tahun 2015

Pertemuan 1, 10 September 2014 : Pengenalan .NET Framework

Dot NET Framework adalah platform komputasi baru yang menyederhanakan proses pembuatan aplikasi pada lingkungan terdistribusi di Internet. Framework ini didesain untuk memenuhi tujuan-tujuan berikut:

• Untuk menyedakan Iingkungan pemrograman berorientasi objek yang konsisten meskipun kode obyek disimpan dan dijalankan secara lokal, dijalankan secara lokal tetapi terdistribusi lewat Internet, atau dijalankan secara remote.
• Untuk menyediakan Iingkungan yang menjalankan kode dengan meminimalkan konflik saat deployment dan versioning.
• Untuk menyediakan Iingkungan yang menjalankan kode yang
  memberikan jaminan keamanan saat menjalankan kode, termasuk kode yang dijalankan oleh pihak ketiga yang tidak diketahui atau kurang dipercaya.
• Untuk menyediakan lingkungan yang menjalankan kode yang menghilangkan problem performance/kecepatan dari lingkungan skripting atau interpreted.
• Untuk membuat developer mengalami pengalaman yang konsisten di berbagai tipe aplikasi, seperti aplikasi Windows aplikasi berbasis web.
• Untuk membangun komunitas standart industri yang memastikan kode berbasis Framework .NET dapat diintegrasikan dengan kode lain.

Framework .NET memiliki dua komponen utama:

• common language runtime (CLR)
• .NET Framework class librarry

Software Requirements Specification

Software Requirement Specification (SRS) adalah dokumen yang menjelaskan tentang berbagai kebutuhan yang harus dipenuhi oleh suatu software. Dokumen ini dibuat oleh developer (pembuat software) setelah menggali informasi dari calon pemakai software. Pembuatannya pun seharusnya mengikuti standar yang ada dan paling diakui oleh para praktisi rekayasa software di dunia. Oleh karena itu, standar yang akan dibahas di sini adalah standar dari IEEE.

IEEE membuat standar SRS agar dokumen penting itu tidak ambigu dan tentu saja komplit. Lengkap. Dengan standar itu, si penggguna dapat mencurahkan semua keinginannya terkait software tersebut dengan jelas dan akurat sehingga sang developer pun dapat memahami apa yang diinginkan pengguna dengan tepat. Bahkan, bagi perorangan, standar ini dapat membantunya dalam mengembangkan outline SRS yang baku khusus untuk perusahaannya, membantunya membuat dokumen SRS dengan format dan isi yang standar (minimal), serta membantunya mengembangkan rincian-rincian pendukung lainnya.

SRS yang baik akan bermanfaat bagi customer, supplier, ataupun perorangan. Manfaat-manfaat tersebut antara lain:

Sebagai bentuk perjanjian antara customer dan supplier tentang software apa yang akan dibuat
Mengurangi beban dalam proses pengembangan software
Sebagai bahan perkiraan biaya dan rencana penjadwalan
Sebagai dasar validasi dan verifikasi software di ujung penyelesaian proyek nantinya
Memfasilitasi transfer, semisal software tersebut ingin ditransfer ke pengguna atau mesin-mesin yang lain. Customer pun merasa mudah jika ingin mentransfer software ke bagian-bagian lain dalam organisasinya. Bahkan, jika terjadi pergantian personil developer, proyek dapat mudah ditransfer ke personil baru dengan memahami SRS ini.
Mendasari perbaikan produk software di kemudian hari. Jadi, kadang SRS boleh diperbaiki dengan alasan dan mekanisme tertentu serta atas kesepakatan antara customer dan developer.
Ada beberapa istilah yang digunakan dan harus diketahui untuk memahami standar SRS yang dibuat IEEE ini. Istilah-istilah tersebut adalah:

- Kontrak: dokumen yang mengikat secara hukum dan disepakati oleh customer dan supplier, termasuk syarat-syarat teknologi dan organisasi, biaya, serta jadwal pengerjaan. Kontrak bisa mengandung sesuatu yang kurang formal tetapi bermanfaat, seperti komitmen atau harapan dari pihak yang terlibat.

- Customer (pelanggan) : Pihak yang membayar untuk produk dan biasanya yang menentukan persyaratan (requirements).

- Supplier (pemasok): Pihak yang membuat produk software untuk customer.

- Pengguna: Pihak yang mengoperasikan atau berinteraksi langsung dengan software. Pengguna dan customer biasanya bukan orang yang sama.

Untuk menyusun SRS, beberapa hal perlu dipertimbangkan, yaitu:

-Sifat SRS;

-Lingkungan SRS;

- Karakteristik dari SRS yang baik, yaitu:

Correct (benar)
Unambiguous (tidak ambigu, tapi jelas)
Complete (lengkap)
Consistent (konsisten)
Ranked for importance and/or stability (prioritas penting dan atau stabilitas)
Verifiable (dapat diverifikasi)
Modifiable (bisa dimodifikasi)
Traceable (bisa dilacak)
- Penyusunan SRS secara bersama-sama;

- Evolusi SRS ;

- Membuat prototipe, seperti model atau contoh;

- Mencantumkan desain sistem di SRS;

- Pencantuman persyaratan proyek di SRS. Untuk persyaratan proyek ada dokumen tersendiri

Pada akhirnya IEEE membuat template sebuah SRS, yang isinya antara lain:

1. Introduction
1.1 Purpose
1.2 Scope
1.3 Definitions, acronyms, and abbreviations
1.4 References
1.5 Overview
2. Overall description
2.1 Product perspective
2.2 Product functions
2.3 User characteristics
2.4 Constraints
2.5 Assumptions and dependencies
3. Specific requirements
4. Appendixes
5. Index

Untuk specific requirements sendiri ada beberapa template yang dibuat oleh IEEE, salah satunya adalah:

3.1 External interface requirements
3.1.1 User interfaces
3.1.2 Hardware interfaces
3.1.3 Software interfaces
3.1.4 Communications interfaces
3.2 Functional requirements
3.2.1 Mode 1
3.2.1.1 Functional requirement 1.1
.
.
.
3.2.1.n Functional requirement 1.n
3.2.2 Mode 2
.
.
.
3.2.m Mode m
3.2.m.1 Functional requirement m.1
.
.
.
3.2.m.nFunctional requirement m.n
3.3 Performance requirements
3.4 Design constraints
3.5 Software system attributes
3.6 Other requirements

System Development Life Cycle (SDLC)

System Development Life Cycle (SDLC)

SDLC adalah tahapan-tahapan pekerjaan yang dilakukan oleh analis sistem dan programmer dalam membangun sistem informasi. Langkah yang digunakan meliputi :
1. Melakukan survei dan menilai kelayakan proyek pengembangan sistem informasi
2. Mempelajari dan menganalisis sistem informasi yang sedang berjalan
3. Menentukan permintaan pemakai sistem informasi
4. Memilih solusi atau pemecahan masalah yang paling baik
5. Menentukan perangkat keras (hardware) dan perangkat lunak (software)
6. Merancang sistem informasi baru
7. Membangun sistem informasi baru
8. Mengkomunikasikan dan mengimplementasikan sistem informasi baru
9. Memelihara dan melakukan perbaikan/peningkatan sistem informasi baru bila diperlukan

System Development Lyfe Cycle (SDLC) adalah keseluruhan proses dalam membangun sistem melalui beberapa langkah. Ada beberapa model SDLC. Model yang cukup populer dan banyak digunakan adalah waterfall. Beberapa model lain SDLC misalnya fountain, spiral, rapid, prototyping, incremental, build & fix, dan synchronize & stabilize.

Dengan siklus SDLC, proses membangun sistem dibagi menjadi beberapa langkah dan pada sistem yang besar, masing-masing langkah dikerjakan oleh tim yang berbeda.

Dalam sebuah siklus SDLC, terdapat enam langkah. Jumlah langkah SDLC pada referensi lain mungkin berbeda, namun secara umum adalah sama. Langkah tersebut adalah

1. Analisis sistem, yaitu membuat analisis aliran kerja manajemen yang sedang berjalan

2. Spesifikasi kebutuhan sistem, yaitu melakukan perincian mengenai apa saja yang dibutuhkan dalam pengembangan sistem dan membuat perencanaan yang berkaitan dengan proyek sistem

3. Perancangan sistem, yaitu membuat desain aliran kerja manajemen dan desain pemrograman yang diperlukan untuk pengembangan sistem informasi

4. Pengembangan sistem, yaitu tahap pengembangan sistem informasi dengan menulis program yang diperlukan

5. Pengujian sistem, yaitu melakukan pengujian terhadap sistem yang telah dibuat

6. Implementasi dan pemeliharaan sistem, yaitu menerapkan dan memelihara sistem yang telah dibuat

Siklus SDLC dijalankan secara berurutan, mulai dari langkah pertama hingga langkah keenam. Setiap langkah yang telah selesai harus dikaji ulang, kadang-kadang bersama expert user, terutama dalam langkah spesifikasi kebutuhan dan perancangan sistem untuk memastikan bahwa langkah telah dikerjakan dengan benar dan sesuai harapan. Jika tidak maka langkah tersebut perlu diulangi lagi atau kembali ke langkah sebelumnya.

Kaji ulang yang dimaksud adalah pengujian yang sifatnya quality control, sedangkan pengujian di langkah kelima bersifat quality assurance. Quality control dilakukan oleh personal internal tim untuk membangun kualitas, sedangkan quality assurance dilakukan oleh orang di luar tim untuk menguji kualitas sistem. Semua langkah dalam siklus harus terdokumentasi. Dokumentasi yang baik akan mempermudah pemeliharaan dan peningkatan fungsi sistem

UML (Unified Modeling Languange)

Pengertian UML

Unified Modeling Language merupakan salah satu alat bantu yang dapat digunakan dalam bahasa pemograman yang berorientasi objek, saat ini UML akan mulai menjadi standar masa depan bagi industri pengembangan sistem/perangkat lunak yang berorientasi objek sebab pada dasarnya UML digunakan oleh banyak perusahaan raksasa seperti IBM, Microsoft, dan sebagainya [Adin05].

Definisi UML

Unified Modeling Language merupakan metode pengembangan perangkat lunak (sistem informasi) dengan menggunakan metode grafis serta merupakan bahasa untuk visualisasi, spesifikasi, konstruksi serta dokumentasi [Adin05].
Unified Modeling Language (UML) adalah bahasa yang telah menjadi standard untuk visualisasi, menetapkan, membangun dan mendokumentasikan arti suatu sistem perangkat lunak [Hend07].
Unified Modeling Language (UML) dapat didefinisikan sebagai sebuah bahasa yang telah menjadi standar dalam industri untuk visualisasi, merancang dan mendokumentasikan sistem perangkat lunak [Afif02].
Unified Modeling Language (UML) merupakan standard modeling language yang terdiri dari kumpulan-kumpulan diagram, dikembangkan untuk membantu para pengembang sistem dan software agar bisa menyelesaikan tugas-tugas seperti [Joml07] :
Spesifikasi
Visualisasi
Desain arsitektur
Konstruksi
Simulasi dan testing
Dokumentasi
Berdasarkan beberapa pendapat yang dikemukakan diatas dapat ditarik kesimpulan bahwa “Unified Modeling Language (UML) adalah sebuah bahasa yang berdasarkan grafik atau gambar untuk menvisualisasikan, menspesifikasikan, membangun dan pendokumentasian dari sebuah sistem pengembangan perangkat lunak berbasis Objek (OOP)  (Object Oriented programming)”.

Langkah-langkah penggunaan Unified Modeling Language (UML)

Adapun langkah-langkah penggunaan Unified Modeling Language (UML) [Afif02] diantaranya sebagai berikut :

Buatlah daftar business process dari level tertinggi untuk mendefinisikan aktivitas dan proses yang mungkin muncul.
Petakan use case untuk setiap business process untuk mendefinisikan dengan tepat fungsional yang harus disediakan oleh sistem, kemudian perhalus use case diagram dan lengkapi dengan requirement, constraints dan catatan-catatan lain.
Buatlah deployment diagram secara kasar untuk mendefinisikan arsitektur fisik sistem.
Definisikan requirement lain non fungsional, security dan sebagainya yang juga harus disediakan oleh sistem.
Berdasarkan use case diagram, mulailah membuat activity diagram.
Definisikan obyek-obyek level atas package atau domain dan buatlah sequence dan/atau collaboration utuk tiap alir pekerjaan, jika sebuah use case memiliki kemungkinan alir normal dan error, buat lagi satu diagram untuk masing-masing alir.
Buatlah rancangan user interface model yang menyediakan antarmuka bagi pengguna untuk menjalankan skenario use case.
Berdasarkan model-model yang sudah ada, buatlah class diagram. Setiap package atau domain dipecah menjadi hirarki class lengkap dengan atribut dan metodenya. Akan lebih baik jika untuk setiap class dibuat unit test untuk menguji fungsionalitas class dan interaksi dengan class lain.
Setelah class diagram dibuat, kita dapat melihat kemungkinan pengelompokkan class menjadi komponen-komponen karena itu buatlah component diagram pada tahap ini. Selain itu, definisikan test integrasi setiap komponen untuk meyakinkan ia dapat bereaksi dengan baik.
Perhalus deployment diagram yang sudah dibuat. Detailkan kemampuan dan requirement piranti lunak, sistem operasi, jaringan dan sebagainya. Petakan komponen ke dalam node.
Mulailah membangun sistem. Ada dua pendekatan yang tepat digunakan:
Pendekatan use case dengan mengassign setiap use case kepada tim pengembang tertentu untuk mengembangkan unit kode yang lengkap dengan test.
Pendekatan komponen yaitu mengassign setiap komponen kepada tim pengembang tertentu.
Lakukan uji modul dan uji integrasi serta perbaiki model beserta codenya. Model harus selalu sesuai dengan code yang aktual.
Perangkat lunak siap dirilis
Ruang Lingkup UML

Dalam kerangka spesifikasi, Unified Modeling Language (UML) menyediakan model-model yang tepat [Adin05], tidak mendua arti (ambigu) serta lengkap.

Secara khusus, Unified Modeling Language (UML) menspesifikasikan langkah-langkah penting dalam pengambilan keputusan analisis, perancangan serta implementasi dalam sistem yang sangat bernuansa perangkat lunak (software intensive  system).

Dalam hal ini, Unified Modeling Language (UML) bukanlah merupakan bahasa pemprograman tetapi model-model yang tercipta berhubungan langsung dengan berbagai macam bahasa pemprograman, sehingga adalah mungkin melakukan pemetaan (mapping) langsung dari model-model yang dibuat dengan Unified Modeling Language (UML) dengan bahasa-bahasa pemprograman berorientasi obyek, seperti Java, Borland Delphi, Visual Basic, C++, dan lain-lain.

Pemetaan (mapping) Unified Modeling Language (UML) bersifat dua arah yaitu :

Generasi  kode bahasa pemprograman tertentu dari Unified Modeling Language (UML) forward engineering.
Generasi kode belum sesuai dengan kebutuhan dan harapan pengguna, pengembang dapat melakukan langkah balik bersifat iterative dari implementasi ke Unified Modeling Language (UML) hingga didapat sistem/peranti lunak yang sesuai dengan harapan pengguna dan pengembang.