Senin, 01 April 2013

Evaluasi Tugas Proyek ANSIS Unsrat Fase Planning

Melakukan evaluasi tugas proyek merupakan tugas rutin untuk mata kuliah Analisa dan Perancangan Sistem. Untuk Tahun Akademik 2012/2013 terasa sedikit berbeda, berhubung pendekatan yang dilakukan untuk mata kuliah ini, adalah real-case project base. Pendekatan real-case project base ini terbilang unik dan baru pertama kali dilakukan dalam konteks uji-coba Kurikulum Berbasis Kompetensi untuk Mata Kuliah Software Engineering.

Real-case project base, membagi setiap peserta mata kuliah dalam 4 kelompok utama; yakni 2 kelompok pengembang dan dua kelompok user. Dua kelompok user, dibedakan menjadi kelompok user dengan organisasi berorientasi profit, sedangkan yang lainnya adalah kelompok user berorientasi non profit. Untuk semester ini, kelompok berorientasi profit memilih studi kasus Perusahan Finance, sedangkan kelompok berorientasi non profit memilih studi kasus Perguruan Tinggi Negeri.

Laporan Fase Planning dari setiap kelompok tersebut, bisa dilihat disini:
1. Kelompok Pengembang Cloud Cycle: 
2. Kelompok User Pentagon:
3. Kelompok User PTN dapat dilihat disini:

(Untuk Laporan kelompok Pengembang Skyware, hingga tulisan ini dibuat untuk dievaluasi, belum memasukkan Laporannya)

Berikut adalah catatan evaluasi saya 

1. Semua Laporan yang dimasukkan masih mengandung salah-tulis dan belum dalam bentuk FINAL. Karena tidak memiliki Cover, Halaman Daftar Isi, Halaman Executive Summary serta Daftar Pustaka dan Lampiran, maka saya nilai Laporan ini belum dalam bentuk FINAL.

2. Laporan yang dibuat Kelompok Pengembang Cloud Cycle sudah mengikuti contoh template yang diberikan, dan cukup lengkap. Dibandingkan dengan Laporan yang dibuat oleh Kelompok user PTN dan Pentagon: yang tidak memiliki Laporan Financial Feasibility secara lengkap; yang mana menjadi salah satu tuntutan utama dalam Laporan fase Inception/Planning. Sayangnya, Financial Feasibility Kelompok Cloud Cycle, tidak mencantumkan besar ROI, NPV dan Grafik BEP.

3. Semua kelompok, TIDAK MEMASUKKAN dokumen hasil iterasi yang sesuai dengan metodologi Agile Unified Process; yakni dokumen RMP, dokumen STRQ dan dokumen VISION. Termasuk laporan iterasi proses inception yang dilakukan.

4. Untuk aktivitas estimasi software, maka setiap kelompok menggunakan tools Function Point Analysis yang tepat, namun sayangnya, setiap kelompk masih KELIRU besar ukuran software dan person-months (ukuran berapa lama software akan dikerjakan).

5. Rencana Kerja (atau Workplan) masing2 kelompk sudah tepat; namun TIDAK DILENGKAPI dengan WBS dan/atau Gantt Chart, sehingga tidak bisa memperkirakan dengan detail implementasi Rencana Kerja yang sesuai dengan metodologi. 

6. Proses Bisnis yang dilaporkan oleh Kelompok Pentagon sudah cukup memadai. Namun Gambar Proses Bisnis tersebut tidak sesuai dengan aturan penggambaran standar (misalnya dgn UML atau BPNM). Dibandingkan dengan proses bisnis yang dilaporkan kelompok PTN dan Cloud Cycle yang tidak bisa terbaca dan sepertinya tidak tepat.

7. Daftar RISK yang dilaporkan setiap kelompok juga masih KELIRU. Padahal apabila menggunakan metodologi AUP, maka Risks List haruslah tepat karena akan menjadi acuan dalam proses iterasi setiap fase selanjutnya.

Kesimpulan:
1. Memberikan point 400 untuk Kelompok Cloud Cycle dan Kelompok PTN. Point 400 berarti BELOW AVERAGE, dan disarankan untuk MEMBUAT KEMBALI Laporan ini.
2. Memberikan point 300 untuk Kelompok Pentagon. Point 300 berarti BELOW AVERAGE dan disarankan untuk MEMBUAT KEMBALI Laporan ini.
3. Memberikan point NULL untuk Kelompok Skyware yang tidak memasukkan Laporan tepat waktunya. Nilai akan diberikan setelah laporan dimasukkan. Disarankan untuk segera memasukkan Laporan, berhubung adanya pengurangan point 50 basis point setiap keterlambatan sehari.

Saran:
1. Setiap Pimpinan Kelompok dapat menghadap Dosen Pengampu As Soon As Possible.
2. Perbaikan Dokumentasi dapat dilakukan namun hanya berpengaruh pada Nilai Akhir, bukan pada Nilai Fase Inception sehingga dengan demikian setiap Kelompok dapat berkonsultasi dgn Dosen Pengampu.

Rabu, 07 November 2012

Architectural Design


Pertanyaan besar seorang software engineer saat hendak membangun perangkat lunak adalah apa yang dimaksud dengan arsitektur desain perangkat lunak.

Pressman summary menuliskan bahwa ...
Architectural design represents the structure of the data and program components required to build a computer-based system. A number of architectural "styles" exist. Architectural design begins with data design and proceeds to the derivation of one or more representations of the architectural structure of the system. The resulting architectural model encompasses both the data architecture and the program structure. Alternative architectural patterns are analyzed to determine the structure that is best suited to the customer’s requirements. The architectural model is subjected to software quality review like all other design work products.

Mari kita lihat pengertian yang dikemukan oleh Software Engineering Institute (SEI Carnegie  Mellon) yang saya kutip disini (http://blog.sei.cmu.edu/post.cfm/reflection-on-20-years-of-software-architecture-a-presentation-by-linda-northrop) ...
The software architecture of a program or computing system is the structure or structures of the system, which comprise software elements, the externally visible properties of those elements, and the relationships among them. Architecture is concerned with the public side of interfaces; private details of elements—details having to do solely with internal implementation—are not architectural. This work constituted the beginning of a cohesive body of SEI research and transition efforts focused on software architecture. 

Dari pengertian diatas, maka kita dapat menyimpulkan bahwa arsitektur sistem aplikasi itu adalah terkait dengan "struktur" (atau bagian dalam, bisa disebut sebagai unsur pembangun/pembentuk) dari sistem perangkat lunak yang akan dikembangkan. Pengertian yang lebih praktis dari arsitektur desain perangkat lunak dapat dipahami dengan menganalogikan perangkat lunak dengan bangunan rumah atau gedung bertingkat. Seperti biasanya seorang insinyur, sebelum membangun rumah atau gedung bertingkat, maka insinyur akan membangun rumah atau bangunan tersebut diatas kertas, lengkap dengan semua perhitungan yang terkait proses penyelesaian rumah atau bangunan tersebut. Inilah yang dimaksud dengan arsitektur desain perangkat lunak.

Dibawah ini, saya berikan sebuah gambar arsitektur SOA (service oriented architecture)


Melakukan architectural design bermanfaat dalam berkomunikasi dengan stakeholder terkait hal-hal teknis yang terkait aplikasi yang akan dikembangkan. Selain itu, architectural design akan memandu tim pengembang untuk mulai membangun aplikasi.

Dokumentasi kegiatan Architectural Design biasanya disebut SAD (atau Software Architecture Document). Template dokumen SAD biasanya mengikuti standar format dokumentasi yang dikeluarkan IEEE.

Selasa, 06 November 2012

Tutorial Rational Rose: Membuat Package


Package digunakan untuk membuat grup dari class-class yang memiliki beberapa kesamaan. Ada beberapa pendeketan berdasarkan kesamaan untuk membuat paket class. Salah satu pendekatan yang digunakan adalah berdasarkan stererotype. Dengan pendekatan ini, satu paket dapat berisi Entity Class, Boundary class, Control class, dan sebagainya. Pendekatan yang lain yaitu berdasarkan fungsi. Sebagai contoh sebuah paket bernama sekuriti, yang digrupkan dengan paket lain misal Employee Maintenance, Reporting, atau Error Handling. Keuntungan dengan pendekatan ini yakni dapat  digunakan secara berulang.

Menambah paket
Paket (package) dibuat dalam Logocal View dari browser. Untuk menambahkan sebuah paket yang sudah ada untuk Class diagram, pindahkan dengan men-drag  paket dari browser ke dalam Class Diagram.

Menambahkan paket yang baru  ke Class diagram:
  1. Pilih icon Package  dalam toolbar 
  2. Click dimana saja dalam  Class diagram untuk menempatkan paket.
  3. Ketik nama Paket (package).
Menambahkan Paket ke Browser:
  1. Click kanan Logical View dalam browser NewPackageketik nama paket

Gambar 1. Membuat Paket baru

Untuk menambahan paket dalam sebuah paket maka Click kanan pada paket yang sudah ada dan ikuti langkah seperti diatas.

Menghapus Paket
Menghapus paket dari Class diagram:
  1. Pilih paket pada Class diagram.
  2. Tekan tombol Delete
Catatan: 
Menghapus paket dari sebuah Class diagram, tidak otomatis menghapus paket pada browser dan dalam class diagram yang lain.

Menghapus paket dari model:
  1. Click kanan pada paket di browser Delete

Gambar 2. Menghapus Paket

Atau
  1. Pilih paket pada Class diagram.
  2. Pilih Edit Delete from Model, atau tekan Ctrl+D.


Gambar 3. Menghapus Paket dari Model


Membuat paket yang memiliki ketergantungan (Package Dependencies)

Sifat dependency merupakan tipe relasi yang hanya terjadi dalam menggambarkan antar paket. Sebuah package dependency, seperti sebuah class dependency yang digambarkan dengan panah bergari putus-putus. Sebuah package dependency dari paket A ke paket B memberikan gambaran bahwa beberapa class dalmapaket A memiliki unidirectional relationship ke beberapaclass dalam paket B.
Dengan kata lain, beberapa class dalam A ingin mengetahui beberapa class dalam B.
Membuat  package dependency pada Class diagram:
  1. Pilih icon  Dependency  dari toolbar.
  2. Drag garis dependency dari paket yang terikat (dependent package)  ke paket yang lain. 
Atau 
  1. Pilih Tools Create Dependency.
  2. Drag garis dependency line dari dependent package ke yang lain.

Gambar 4. Membuat garis dependency


Menghapus Package Dependencies
  1. Pilih package dependency yang ingin dihapus
  2. Tekan tombol Delete.
Atau
  1. Pilih package dependency yang ingin dihapus
  2. Pilih Edit Delete