Migrasi Data: Some issues…

Menyambung tulisan sebelumnya tentang migrasi data, berikut adalah beberapa issues yang perlu diperhatikan saat melakukan pekerjaan tersebut:

• perbedaan DBMS yang digunakan; perlu diperhatikan apakah fitur DBMS asal dan DBMS tujuan relatif sama; jika tidak, teknik apa yang akan kita gunakan untuk migrasi data…
• perbedaan skema basisdata; seberapa jauh bedanya… bagaimana pemetaannya…
• perbedaan tipe data dan character set; bagaimana konversinya…
• data yang redundant; bagaimana memastikan integritasnya…
• data yang tidak konsisten; mana yang paling benar…
• data awal yang tidak ‘bersih’, banyak mengandung ’sampah’; bagaimana memilah-milahnya…

Apa lagi ya ??

Business Process Reengineering

Bisnis tanpa didukung IT (Information Technology) sudah bukan jamannya lagi. Ya, IT sudah banyak dimanfaatkan di berbagai lini untuk mendukung keberhasilkan bisnis perusahaan. Akan tetapi, seberapa besar IT ini sudah berhasil mendukung pelaksanaan bisnis, juga merupakan pertanyaan yang harus dijawab. Business Process Reengineering (BPR) adalah salah satu hal yang bisa dilakukan.

BPR memberikan tantangan untuk meninjau kembali apakah aktivitas bisnis sudah dijalankan dengan cara yang paling produktif. Produktivitas ini, salah satunya, dapat dicapai dengan menerapkan pemanfaatan IT yang pas. Ya, tentu saja harus pas, tidak kurang tidak lebih, sesuai dengan kebutuhan dan prioritas rencana strategis perusahaan. Aktivitas BPR akan berfokus pada tiga arsitektur utama, yaitu arsitektur data, arsitektur aplikasi (software), dan arsitektur teknologi (infrastruktur). Nah, agar IT bisa memberikan nilai tambah, maka tiga arsitektur ini perlu dirancang dengan baik…

Migrasi Data

Migrasi data biasanya menjadi bagian dari suatu proyek lain yang lebih besar, yaitu upgrade atau migrasi perangkat lunak. Dan, karena hanya berupa sub-proyek, perhatian terhadap hal tersebut biasanya relatif kurang. Padahal, migrasi data adalah bagian yang cukup kritis. Tanpa migrasi data, perangkat lunak yang sudah berhasil dibangun atau di-upgrade tidak dapat digunakan dengan maksimal, karena data histori tidak bisa diabaikan begitu saja.

Migrasi data juga relatif jarang dilakukan sehingga tidak banyak pengalaman yang bisa dipelajari. Padahal, begitu kita harus melaksanakannya, cukup banyak situasi dan kondisi yang bisa menjadi kendala sehingga akhirnya membuat delay terhadap proyek secara keseluruhan. Perlu best practices juga untuk melaksanakannya. Dan cukup banyak issues yang perlu diperhatikan pada proses migrasi data ini…

Saya sedang menghadapi pekerjaan jenis ini juga. Mudah-mudahan nanti bisa sharing di blog ini ya…

How freak are you ?

(diambil dari http://blogs.sun.com/kazem/)

Resume: Kuliah RPLL

Kuliah baru di kurikulum baru ini juga berakhir minggu lalu. Kuliah pilihan untuk jalur RPL ini cukup banyak peminatnya sehingga dibagi dalam dua kelas paralel. Peserta di kelas saya sendiri mencapai 91 orang. Cukup banyak materi dan tugas yang diberikan di kuliah ini.

Kuliah dimulai dengan review metode terstruktur dan review metode berorientasi objek. Tujuannya tentu saja untuk mempertinggi jam terbang…

Kemudian dilanjutkan dengan materi baru yaitu Web Engineering. Ya, WebApp punya karakteristik khusus sehingga kita perlu memodelkan hasil analisis dan design-nya dengan cara yang berbeda, cara yang lebih lengkap. Yang baru di sini adalah pembuatan User Experience Model (UX-Model) dan penggunaan notasi WAE to UML (WebApp Extension to UML) di tahap design.

Materi terakhir adalah Real Time System (RTS). Dimulai dengan membahas berbagai contoh dan karakteristik RTS, kemudian dibahas SART (Structured Analysis for Real Time) dan RT-UML (Real Time UML). Di SART dibahas tentang Control Flow Diagram yang dapat kita gunakan untuk memodelkan kontrol pada RT software. Sedangkan pada RT-UML, dibahas berbagai tambahan pada UML 2.0 yang dapat digunakan untuk memodelkan RTS. Beberapa diantaranya adalah tambahan constraint pada Use Case Diagram yang menggambarkan QoS (quality of service), structured class yang menggambarkan komposisi kelas dengan cara yang lebih jelas (structured class terdiri dari berbagai part yang saling berhubungan melalui port-nya). Sequence diagram yang digunakan juga bisa menggambarkan proses paralel dan berbagai constraint yang terkait dengan pewaktuan. Sequence diagram pada UML 2.0 juga bisa di-zoom vertikal dan horisontal. Ada lagi timing diagram yang dapat digunakan untuk memperlihatkan bagaiman state sistem berubah terhadap sumbu waktu. State diagram juga dapat digunakan untuk menggambarkan use case secara lebih detil. Jadi, pada RT-UML ini, realisasi use case dapat digambarkan dengan berbagai diagram (sequence diagram, state diagram, timing diagram, dan activity diagram) untuk memberikan gambaran yang lebih lengkap…

Materi yang cukup padat ini, semoga bisa digunakan sebagai tambahan wawasan, yang selanjutnya dapat dipelajari sendiri detilnya…

OK students, prepare yourself for the final exam…

Resume: Kuliah RPL

Kuliah RPL untuk kelas Prodi Teknik Elektro/Telekomunikasi berakhir minggu lalu, ditutup dengan presentasi tugas analisis dan merancang software dengan metode berorientasi objek… (sayangnya, saya tidak bisa hadir di kelas di minggu terakhir ini)

Dengan berakhirnya kuliah ini, saya harap para pesertanya:

• tahu apa itu software, apa bedanya dengan program, dan mengapa software engineering berkembang
• tahu berbagai model proses pembangunan software termasuk yang terbaru: agile process model dan unified process, serta bisa memilih model proses yang tepat sesuai kebutuhan
• bisa merancang software skala kecil/menengah dengan metode terstruktur, yang mencakup analisis terstruktur (dengan memodelkannya dalam bentuk DFD, ERD, dan STD) dan perancangan terstruktur (dengan merancang arsitekturnya, antarmukanya, datanya, dan algoritmanya)
• bisa merancang software skala kecil/menengah dengan dan metode berorientasi objek (Unified Process), mulai dari memodelkan kebutuhan dalam bentuk use case diagram, merealisasikan setiap use case (dengan meng-identifikasi kelas-kelas, membuat diagram interaksi antar objek -sequence diagram atau collaboration diagram-, dan membuat diagram kelasnya) sehingga akhirnya siap diimplementasikan dalam suatu bahasa pemrograman tertentu

Selain itu, saya juga berharap agar para peserta juga bisa memahami apa bedanya software engineer dengan programmer, apa bedanya membuat software dengan memrogram…

Jum’at (19 Desember) ini adalah waktunya ujian akhir. Sukses ya…

Senyum lagi…

Setelah beberapa hari panas, Didit akhirnya dirawat di rumah sakit. Semalam dirawat, senyumnya sudah mulai muncul lagi…

Dear pembaca, mohon doanya agar segera sehat dan pulang ke rumah ya…

Resume: Kuliah APBO

Ditutup dengan sebuah quis tentang design pattern, Kuliah APBO (Analisis dan Perancangan Berorientasi Objek) sudah berakhir minggu lalu. Ini adalah kuliah pilihan. Biasanya pesertanya hampir mencapai 100 orang. Tapi, karena ada pergantian kurikulum yang mempengaruhi prioritas pengambilan matakuliah pilihan, peserta kuliah ini turun drastis hingga hanya 16 orang. Ternyata enak juga mengajar kelas kecil. Untuk tiga tugas yang diberikan, tiap kelompok (ada 4 kelompok) punya waktu untuk sharing dan mempresentasikan hasil kerjanya. Bahkan ada yang presentasi dengan gaya sinetron…

Dengan berakhirnya kuliah ini, saya harap para pesertanya:

• punya gambaran tentang berbagai metode OOAD yang ada, pendekatannya, serta kekuatan masing-masing metode
• tambah mahir menerapkan Unified Process untuk pembangunan software skala menengah
• mengenal The Gang of Four dan Design Pattern Catalog-nya
• mulai refleks mencari-cari design pattern yang sesuai jika berhadapan dengan problem tertentu
• mampu memetakan hasil design menjadi kode program dalam bahasa pemorgraman tertentu
• mengenal refactoring untuk meningkatkan kualitas kode program
• mengenal alat bantu untuk melakukan pengujian secara otomatis

That’s all students, see you at the final exam…

Jadi, buat apa dong ?

Ada kesimpulan menarik yang muncul dari hasil pelaksanaan tugas analisis dan design WebApp. Kesimpulan tersebut adalah: “Dokumentasinya tambah buanyak… Kayaknya lebih cepat langsung buat programnya…”

Jadi, buat apa dong setumpuk dokumen (yang berisi berbagai model) tersebut ?

Selain sebagai dasar atau pedoman pembangunan software untuk tahap berikutnya (model requirement sebagai dasar untuk analisis; model analisis sebagai dasar untuk perancangan; model perancangan sebagai dasar implementasi dalam bentuk kode program; dst), dokumen tersebut akan sangat membantu proses perawatan (maintenance) software tersebut di masa yang akan datang. Jadi, kalau software-nya tidak operasional dan tidak perlu dirawat, manfaat dokumentasi yang lengkap memang tidak terasa.

Lebih cepat kalau langsung buat program ?

Ya, akan lebih cepat langsung membuat programnya jika software yang dibangun adalah software skala kecil. Itupun, programmer-nya harus merangkap sebagai analis dan designer.

Kompromi coba dibuat pada Agile Process Model. Dokumentasi yang lengkap tidak lagi menjadi prioritas (lihat Manifesto for Agile Software Development). Tapi itupun tidak cocok untuk setiap jenis software. Dan hanya developer yang sudah berpengalaman yang akan sukses menerapkan Agile Process Model…

Bumper Stickers: Error

* Error: erroneous error; nothing wrong.

* Error: illegal brain function. Process terminated.

* Error: no keyboard – press F1 to continue.

* Error: reserved for future mistakes.

* Error: the operation was completed succesfully. (MS Exchange)

* Error: Windows not found. (C)heer (P)arty (D)ance?

(dari http://www.c2i.ntu.edu.sg/AI+CI/Humor/index.html)