Mau kemana ?
Hidup harus seimbang. Jadi, setelah seminggu belajar dan bekerja, manfaatkan waktu di akhir pekan untuk refreshing. Tidak perlu jauh-jauh. Di seputar Dago ini banyak tempak yang asyik. Misalnya jalan kaki dari Dago Pakar ke Maribaya. Udaranya masih segar, pemandangan juga indah. Jaraknya tidak terlalu jauh. Lihat foto di bawah, anak saya yang masih kecil juga kuat…
(foto diambil dari sini)
Sudah cukupkah ?
Sudah cukupkah design yang kita buat ? Sampai seberapa detil kita harus membuat model design untuk software yang akan kita bangun ?
Paling tidak, jawablah pertanyaan ini: siapkah programmer bekerja dengan model design yang sudah kita buat ? jangan sampai programmer masih harus memikirkan berbagai hal ini: framework apa yang sebaiknya digunakan, file apa saja yang harus dibuat, library apa saja yang bisa digunakan, bagaimana struktur menunya, bagaikan tampilan antarmukanya, dimana setiap komponen harus di-deploy, dan seterusnya…
Tugas programmer adalah menerjemahkan hasil design ke dalam lingkungan implementasi tertentu. Itu saja… Jadi, jangan bebani programmer dengan pekerjaan designer…
Teknologi Komponen: COM dan DCOM
COM (Component Object Model) adalah spesifikasi mencakup implementasi yang dikembangkan Microsoft Corporation, yang menyediakan framework untuk integrasi komponen. Framework ini mendukung interoperability dan reusability objek-objek terdistribusi yang memungkinkan developer membangun sistem dengan melakukan assembly berbagai komponen dari berbagai vendor. Komponen-komponen tersebut akan berkomunikasi melalui COM.
COM mendefinisikan API (application programming interface) untuk membuat komponen maupun untuk mendukung interaksi antar komponen. Untuk bisa berinteraksi, komponen harus punya struktur biner yang sesuai dengan spesisikasi Microsoft. Selama mempunyai struktur biner yang sesuai, maka komponen yang dibangun dengan bahasa pemrograman yang berbeda akan dapat berkomunikasi.
COM dikembangkan menjadi DCOM (Distrubuted COM) untuk mendukung interaksi antar komponen yang terdistribusi (berlokasi di mesin yang berbeda). Dengan DCOM, komponen yang beroperasi di berbagai platform yang berbeda akan dapat berinteraksi.
COM dan DCOM merepresentasikan teknologi low-level untuk interaksi komponen, sedangkan OLE, ActiveX, dan MTS merepresentasikan higher-level application services yang dibangun di atas COM dan DCOM.
Batasan antar berbagai teknologi Microsoft kadang-kadang kurang jelas. Orang seringkali menggunakan terminologi “OLE technologies” yang mencakup COM, atau “Active Platform” sebagai web solution yang lengkap.
W5HH
Berikut ini adalah prinsip W5HH yang sebaiknya diterapkan pada pembangunan perangkat lunak:
a. Why is the system being developed?
b. What will be done by When?
c. Who is responsible for a function?
d. Where are they organizationally located?
e. How will the job be done technically and managerially?
f. How much of each resource is needed?
Jadi, jangan melangkah lebih lanjut kalau pertanyaan di atas belum jelas…
Testing vs Debugging
Testing adalah salah satu aktivitas yang harus dilakukan sebagai bagian dari tahap pembangunan perangkat lunak. Tujuannya adalah untuk mencari sebanyak-banyaknya kesalahan, error maupun defect. Testing dilakukan dengan mengacu pada test plan dan test cases. Idealnya, testing dilakukan oleh tester, bukan oleh programmer, sehingga lebih obyektif.
Debugging adalah aktivitas yang dilakukan untuk mencari posisi kesalahan dan memperbaikinya apabila dari hasil testing diperoleh indikasi adanya error atau defect. Debugging biasanya dilakukan oleh programmer-nya. Debugging bisa sangat menghabiskan waktu. Untuk itu, perlu diterapkan cara dan strategi yang tepat. Kita bisa memilih satu dari tiga cara:
- Brute force – biasanya kita tambahkan print atau write dimana-mana untuk melacak kesalahan
- Backtracking – source code dianalisis untuk mencari kemungkinan penyebab kesalahan; bergerak dari suatu posisi hingga akhirnya ditemukan posisi kesalahannya
- Cause elimination - menggunakan partisi biner terhadap bagian program untuk memperkecil kemungkinan posisi kesalahan
Penting sekali agar tester maupun debugger dapat bekerja dengan seefektif mungkin…
Cara mana yang sering anda pilih ?
S/W Quality: Dependability
Salah satu faktor kualitas yang akan meningkatkan kepercayaan customer terhadap software yang digunakannya adalah dependability. Ya, agar customer dapat mengunakan software dengan ‘tenang’, perlu ada jaminan bahwa software yang digunakannya dapat diandalkan.
Dependability pada sistem komputer didefinisikan pada IFIP 10.4 Working Group on Dependable Computing and Fault Tolerance sebagai berikut:
“[..] the trustworthiness of a computing system which allows reliance to be justifiably placed on the service it delivers [..]”
Definisi alternatif lainnya adalah seperti yang dinyatakan pada IEC IEV 191-02-03 sebagai berikut:
“dependability (is) the collective term used to describe the availability performance and its influencing factors : reliability performance, maintainability performance and maintenance support performance”
Sebenarnya, definisi asli dependability muncul dari beberapa atribut kebutuhan non fungsional berikut: availability, reliability, dan maintainability, yang dikombinasikan dengan konsep threats dan failures. Definisi dependability ini kemudian diperluaskan sehingga mencakup safety dan security.
Dependability dapat dipandang sebagai komposisi dari tiga elemen berikut:
* Attributes - cara untuk mengukur/menilai (to assess) dependability dari sebuah sistem
* Threats – pemahaman tentang segala hal yang dapat mempengaruhi dependability sebuah sistem
* Means - cara untuk meningkatkan dependability sebuah sistem
Software (Architecture) Quality
Software quality adalah salah satu topik riset yang cukup populer, baik di bidang akademik maupun industri, sehubungan dengan masih belum adanya kesepakatan dan formalisasi definisi quality itu sendiri. Berkaitan dengan software quality ini, ada dua area yang bisa menjadi fokus, yaitu software product evaluation dan software process evaluation.
Software product evaluation mencakup aktivitas validasi dan verifikasi. Validasi bertujuan untuk memastikan bahwa kita membangun produk yang benar, sedangkan verifikasi untuk memastikan bahwa produk yang dibangun sudah sesuai dengan spesifikasinya.
Software architecture evaluation adalah salah satu bentuk verifikasi. Software architecture berperan saat kita ingin memprediksi kualitas software sebelum benar-benar membangunnya. Kita perlu melakukan evaluasi terhadap software architecture untuk memastikan bahwa sejumlah quality attributes yang diharapkan akan bisa dicapai. Selain untuk meningkatkan quality, dari software achitecture desciption (SAD) tersebut, kita bisa memprediksi beberapa resiko yang mungkin terjadi sejak awal. Kita mungkin tidak akan dapat memprediksi seluruh quality attributes termasuk validity, usability, dan beberapa performance qualities, tapi kita akan punya cukup jaminan untuk beberapa quality attributes, seperti beberapa aspek performance dan reliability.
-
Archives
- November 2009 (5)
- October 2009 (15)
- September 2009 (12)
- August 2009 (5)
- July 2009 (4)
- June 2009 (7)
- May 2009 (14)
- April 2009 (7)
- March 2009 (7)
- February 2009 (18)
- January 2009 (15)
- December 2008 (13)
-
Categories
- analysis
- aspect oriented
- CBSE
- critical system
- design
- digital learning
- e-business
- ecosystem
- final project
- fun
- health informatics
- introduction
- lecture
- maintenance
- method
- oop
- others
- programming
- project
- project management
- quality
- real time system
- requirement
- research
- service computing
- soa
- software architecture
- software metrics
- software process
- software product
- software quality
- software standard
- technology
- testing
- tools
- Uncategorized
- webE
-
RSS
Entries RSS
Comments RSS


