ICT Notes

Rabu, 01 Mei 2013

Bringing C code to the modern world

Setiap peneliti, apalagi praktisi dalam dunia software engineering, harus mengakui, bahwa riset Marco Trudel adalah sebuh TEROBOSAN ...

Bringing C code to the modern world

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:

https://www.dropbox.com/s/qciryf9inv0vvgh/INCEPTION%20tim%20pengembang%20Cloud%20Cycle%20Corporation.docx

2. Kelompok User Pentagon:

https://www.dropbox.com/s/42t1scv7aa0uh48/CARA%20KERJA%20PT.PENTAGON%20%28FIX%29.docx

3. Kelompok User PTN dapat dilihat disini:

https://www.dropbox.com/s/ulnkt27xs2fkbiu/INCEPTION%20Unversitas%20Sam%20Ratulangi.docx

(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.

Sabtu, 09 Februari 2013

Computing Now Archive | February 2013 | The Education Issue - IEEECS

Rabu, 30 Januari 2013

Rangkuman URL Praktikum Metode Numerik Bagian 1

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.