The Cathedral vs The Bazaar

The Cathedral dan the Bazaar (disingkat CatB) adalah dua software development model untuk free software project. Model ini dikenalkan oleh Eric S. Raymond berdasarkan hasil observasinya terhadap proses pembangunan kernel Linux serta pengalamannya mengelola open source project. Beda kedua model tersebut adalah sbb:

1. The Cathedral model; source code tersedia/dapat diakses untuk setiap software release, tetapi kode-kode di antara dua release hanya bisa diakses oleh sekelompok software developer tertentu. Contohnya adalah pada proyek pembangunan GNU Emacs dan GCC.
2. The Bazaar model; model ini lebih terbuka; publik dapat melihat setiap kode yang sedang dikembangkan via internet. Menurut Raymond, Linus Torvalds adalah pelopor model proses ini dengan filosofinya (Linus’s Law): the more widely available the source code is for public testing, scrutiny, and experimentation, the more rapidly all forms of bugs will be discovered.

Raymond menambahkan: dibutuhkan waktu dan energi yang lebih banyak untuk mencari bugs pada Cathedral model, karena working version of the code hanya bisa dilihat oleh developer yang terbatas.

Jadi, akhirnya, Bazaar-style open development model lebih banyak diadopsi pada open source and free software projects, baik seluruhnya maupun sebagian, termasuk pada proyek pembangunan GNU Emacs dan GCC yang awalnya menerapkan Cathedral Model .

Half Full or Half Empty?

To the optimist, the glass is half full.
To the pessimist, the glass is half empty.
To the engineer, the glass is twice as big as it needs to be.

(Dari Jokes for Engineers)

Mengenal SEI

SEI (Software Engineering Institute) adalah sebuah pusat riset di bidang software engineering, terutama yang berkaitan dengan: acquisition, architecture and product lines, process improvement and performance measurement, security, and system interoperability and dependability. Pusat riset ini berada di Carnegie Mellon University, sejak tahun 1984. Pusat riset ini menjadi ujung tombak berbagai inovasi teknis di bidang software engineering.

Ada 5 program teknis SEI, yaitu sbb:

1. Through the Dynamic Systems Program, the SEI establishes and demonstrates methods for designing, integrating, evolving and sustaining systems using preexisting components. The Dynamic Systems Program also teaches software engineers how to specify and predict the performance, dependability, and interoperability of software-intensive systems while systems are being designed.
2. The goal of the Product Line Systems Program is to enable widespread product line practice through architecture-based development. Product line practice involves engineering a set of software-intensive systems that share a common, managed set of features that satisfy the specific needs of a particular market segment or mission from a common set of core assets in a prescribed way.
3. The Software Engineering Process Management Program at the SEI provides leadership to software-dependent organizations through proven, process-focused methods for improving product costs, schedule and quality. This program also manages the SEI’s work on the internationally recognized Capability Maturity Model Integration, a framework that helps organizations improve their processes enterprisewide.
4. Building on the experience of the nationally recognized CERT Coordination Center, the Networked Systems Survivability Program develops and widely distributes information security practices and evaluation methods that enable organizations to protect their systems against security threats such as viruses and worms. The CERT/CC has recently formed a partnership with the Department of Homeland Security to create US-CERT, a coordination point for prevention, protection, and response to cyber attacks across the Internet.
5. The Acquisition Support Program helps government agencies improve the way they acquire software-intensive systems, and provides opportunities for SEI programs to create and disseminate new technologies.

Kalau ingin berkenalan lebih lanjut dengan SEI, silahkan klik http://www.sei.cmu.edu

Perancangan Terstruktur

Perancangan terstruktur bertujuan untuk membuat model SOLUSI terhadap PROBLEM yang sudah dimodelkan secara lengkap pada tahap analisis terstruktur. Ada empat kegiatan perancangan yang harus dilakukan, yaitu:

1. Perancangan arsitektural; kita merancang struktur modul P/L dengam mengacu pada model analisis yang sesuai (DFD). Langkahnya adalah: mengidentifikasi jenis aliran (transform flow atau transaction flow), menemukan batas-batas aliran (incoming flow dan outgoing flow), kemudian memetakannya menjadi striktur hirarki modul. Selanjutnya, kita alokasikan fungsi-fungsi yang harus ada pada modul-modul yang tepat.
2. Perancangan data; kita merancang struktur data yang dibutuhkan, serta merancang skema basisdata dengan mengacu pada model analisis yang sesuai (ERD).
3. Perancangan antarmuka; kita merancang antarmuka P/L dengan pengguna, antarmuka dengan sistem lain, dan antarmuka antar-modul.
4. Perancangan prosedural; kita merancang detil dari setiap fungsi pada modul. Notasi yang digunakan bisa berupa flow chart, algoritma, dan lain-lain

Pastikan bahwa model perancangan yang kita buat sudah mengakomodasi kebutuhan non fungsional…

Requirement Gathering

Requirement gathering harus kita lakukan di awal pembangunan perangkat lunak. Kita perlu mengetahui dengan jelas, apa sebenarnya yang dibutuhkan client. Keterampilan dan strategi khusus perlu dipersiapkan untuk menghadapi berbagai karakter client. Quote di bawah menggambarkan problem yang bisa terjadi pada tahap ini:

“I know you believe you understood what you think I said, but I am not sure you realize that what you heard is not what I meant!”

Reporting Tool untuk SCM

SCM (Software Configuration Management) akan lebih mudah dilaksanakan apabila dibantu dengan tools yang sesuai. Pengelolaan versi (versioning system) dari CSCI (computer software configuration Item) adalah salah satu kegiatan yang harus dilakukan pada SCM.

Ratna (2002) mengkaji beberapa versioning system yang sudah ada seperti SpectrumSCM, +1CM, CVS, SVN, dan FishEye. Dari salah satu versioning system ini, ingin dibuat aplikasi untuk membangkitkan berbagai report sehingga memudahkan penggunanya untuk memperoleh informasi. CVS dipilih sebagai aplikasi yang akan dikelola datanya. Perangkat lunak yang dibuat Ratna diberi nama IT Change. IT Change berhasil menampilkan berbagai report yang merupakan hasil olahan data perubahan pada CVS.

TA yang menarik

Software Architecture

Shaw dan Garlan mendefinisikan software architecture secara abstrak sebagai “the description of the elements that compose the system, their interactions, the patterns and principles that guide their composition and design, and the constraints on those patterns” (Shaw, M.,Garlan, D. 1996. Software Architecture: Perspectives on an Emerging Discipline. Upper Saddle River, NJ: Prentice-Hall).

IEEE (Recommended Practice for Architecture Description of Software-Intensive Systems – IEEE standard 1471–2000) mendefinisikan arsitektur sebagai “the fundamental organization of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution.“

Untuk memahami definisi di atas, kita bisa menganalogikannya dengan arsitektur bangunan. Arsitek membuat gambar arsitektur bangunan yang menggambarkan bagian-bagian bangunan dan keterhubungan antar-bagiannya. Misalnya, pada bangunan tersebut ada kamar, ruang tamu, dapur, dsb. Selanjutnya, ada pintu yang menghubungkan satu ruang dengan ruang lainnya, ada sistem listrik yang terhubung di setiap ruangan, dst. Akan tetapi, akan lebih tepat menganalogikan software system saat ini dengan sebuah perumahan. Sebuah software yang berevolusi dapat kita bayangkan seperti sebuah perumahan yang berkembang. Ada tambahan rumah, ada pelebaran jalan untuk mengatasi kemacetan, ada bangunan kumuh yang dihancurkan untuk diganti dengan sebuah mall, dst…

Jadi sederhananya, software architecture menggambarkan elemen/komponen software dan keterkaitan antar-elemen/komponennya.

Lalu, kenapa kita perlu merancang software architecture ? Agar mudah menjawabnya, kembali kita bayangkan analoginya. Kenapa gambar arsitektur bangunan atau perumahan perlu dibuat ? Dengan merancang gambar arsitekturnya, kita bisa membayangkan seperti apa bangunan/perumahan tersebut nantinya. Kita bisa mengelola kompleksitas bangunan/perumahan tersebut, kita bisa mengubah/memodifikasi tata letak, interaksi, dll dengan mudah karena masih bekerja dengan ‘gambar’. Bayangkan kalau kita harus langsung memodifikasi bangunan/perumahannya. Tiba-tiba kita perlu memindahkan letak dapur karena terlalu jauh dari ruang makan, dst…

Jadi, software architecture sebenarnya membantu kita untuk mengelola kompleksitas dan memastikan bahwa kualitas software tersebut nantinya akan optimal…

Analisis Terstruktur

Dengan metode terstruktur (di buku Pressman disebut metode konvensional) pada tahap analisis kita memodelkan PROBLEM dari tiga sudut pandang:

1. pemodelan fungsional; kita memodelkan fungsional P/L dalam terminologi proses dan aliran data antar proses; kita membuat DFD (data flow diagram)
2. pemodelan data; kita memodelkan kebutuhan data yang yang harus dikelola P/L dalam terminologi entitas data dan relasi antar-entitas; kita membuat ERD (entity-relationship diagram)
3. pemodelan kelakuan (behaviour); kita memodelkan aspek dinamis P/L dalam terminologi state, event, dan action; kita amembuat STD (state transition diagram)

Kenapa harus dari tiga sudut pandang ?

Ya, untuk mendapatkan gambaran yang lengkap tentang suatu hal, akan lebih baik kalau kita memotretnya dari berbagai sudut pandang. Tapi jangan lupa, kita harus memastikan bahwa model yang kita buat dari berbagai sudut pandang tersebut harus dikelola dengan baik sehingga konsisten.

Ingat cerita tentang tiga orang buta yang ingin memahami gajah ? Satu orang meraba belalai gajah sehingga dia mendapat gambaran bahwa gajah itu panjang. Satu orang lagi meraba kupingnya, sehingga dia mendapat gambaran bahwa gajah itu lebar dan pipih. Satu orang lagi meraba badannya, sehingga dia memperolah gambaran bahwa gajah itu besar dan berkulit kasar. Jika informasi-informasi tersebut tidak dikelola dan dikoordinasikan, gambaran akhir tentang gajah akan jadi salah kan ??

Jadi, pastikan ketiga model di atas juga saling melengkapi dan konsisten. Misalnya, proses pada DFD harus didukung dengan adanya action di STD. Data store di DFD harus didukung dengan adanya entitas/relasi di ERD. Dst…

What next ?

Tahukah kamu ? (14)

Staffing untuk sebuah project perlu dilakukan secara bertahap. Di awal project, di saat kita masih brainstorming, bisa saja kita sudah melibatkan banyak orang. Tetapi, pada saat kita ingin mengkristalkannya menjadi project dengan lingkup yang jelas, sebaiknya tidak melibatkan terlalu banyak orang. Beranjak ke tahap berikutnya, analisis dan design, kita bisa mulai menambah orang. Dan penambahan terbanyak baru kita lakukan di tahap implementasi.

Kenapa begitu ? Makin banyak orang yang terlibat, maka effort untuk koordinasi akan membesar. Banyak orang bisa dilibatkan dengan optimal jika pekerjaan dan pembagiannya sudah jelas…

Kasus ini juga bisa diterapkan dalam kerja kelompok untuk tugas matakuliah. Jika anggota kelompok terlalu banyak, ada beberapa orang yang cenderung hanya jadi ‘penggembira’ saja ya…

Berapa sebenarnya ukuran optimal untuk kerja kelompok ya ??