Design Terstruktur

FASE DISAIN

Aktivitas utama dalam Fase Disain adalah membuat top dan medium
level dari disain sistem dan mendokumentasikannya dalam
Spesifikasi Disain. Aktivitas kedua dimulai dengan melakukan
Rencana Test Penerimaan (Acceptance Test Plan / ATP).
ATP adalah sebuah dokumen tes yang akan digunakan untuk
mendemonstrasikan seluruh fungsi sistem kepada user pada fase
penerimaan.
Terdapat dua langkah dalam mendisain sistem software, yaitu :
• Pertama, bagilah sistem menjadi beberapa komponen secara
fungsional.
• Kedua, hubungkanlah komponen-komponen tersebut.

DISAIN YANG TERSTRUKTUR (STRUCTURED DESIGN)

Tujuan utama dari disain yang terstruktur adalah memecah sistem
menjadi bagian yang lebih kecil, teratur dan mudah untuk dibangun.
Disain Top Down (Top Down Design)
Disain Top Down dimulai dengan Top Level Design (TLD).
Lihat Gambar 7.1. Top Level Design
Masing-masing komponen utama atau kotak dalam TLD dipecah
menjadi sub-bagian dimulai dengan level teratas, kemudian turun ke
level berikutnya, dst.
Dalam kasus ini, dimulai dengan MENU dan mendisainnya sebelum
turun ke INQUIRY, UPDATE, dan REPORT GENERATION, yang
akan diikuti dengan tingkat selanjutnya, jika ada.
Disain Bottom Up (Bottom Up Design)
Pada kasus tertentu mungkin akan lebih mudah mendisain dengan
menggunakan pendekatan dari level bawah / rendah ke level atas.
Hal ini sering ditemui pada kasus sistem pengontrolan proses dimana
perlatan pengontrolan hardware pada level terbawah menentukan
bagaimana sistem tersebut disatukan (integrasi sistem).

COCOMO dan Sebutkan Jenis-Jenisnya

COCOMO merupakan singkatan dari Constructive Cost Model, yang berarti sebuah model parametris pengestimasian yang menghitung jumlah FP dalam perencanaan serta pengembangan perangkat lunak, COCOMO sendiri memiliki 3 jenis pengimplementasian dalam evolusinya sejak awal kejadiannya hingga kini, yaitu:


Basic (COCOMO I 1981)
Menghitung dari estimasi jumlah LOC (Lines of Code);
Pengenalan Cocomo ini diawali tahun 70-an akhir. Sang pelopor Boehm, melakukan riset dengan mengambil kasus dari 63 proyek perangkat lunak untuk membuat model matematisnya. Model dasar dari model ini adalah sebuah persamaan sebagai baerikut :
effort = C * size^M
ket :
effort
adalah usaha yang dibutuhkan selama proyek, diukur dalam person-months;

c dan M
adalah konstanta-konstanta yang dihasilkan dalam riset Boehm dan tergantung pada penggolongan besarnya proyek perangkat lunak;

size
adalah estimasi jumlah baris kode yang dibutuhkan untuk implementasi, dalam satuan KLOC (kilo lines of code)


Intermediate (COCOMO II 1999)
Menghitung dari besarnya program dan “cost drivers” (faktor-faktor yang berpengaruh langsung kepada proyek), seperti: perangkat keras, personal, dan atribut-atribut proyek lainnya. Selain itu pada jenis ini, COCOMO mempergunakan data-data historis dari proyek-proyek yang pernah menggunakan COCOMO I, dan terdaftar pengelolaan proyeknya dalam COCOMO database. yang dijabarkan dalam kategori dan subkatagori sebagai berikut
a. Atribut produk (product attributes)
1. Reliabilitas perangkat lunak yang diperlukan (RELY)
2. Ukuran basis data aplikasi (DATA)
3. Kompleksitas produk (CPLX)
b. Atribut perangkat keras (computer attributes)
1. Waktu eksekusi program ketika dijalankan (TIME)
2. Memori yang dipakai (STOR)
3. Kecepatan mesin virtual (VIRT)
4. Waktu yang diperlukan untuk mengeksekusi perintah (TURN)
c. Atribut sumber daya manusia (personnel attributes)
1. Kemampuan analisis (ACAP)
2. Kemampuan ahli perangkat lunak (PCAP)
3. Pengalaman membuat aplikasi (AEXP)
4. Pengalaman penggunaan mesin virtual (VEXP)
5. Pengalaman dalam menggunakan bahasa pemrograman (LEXP)
d. Atribut proyek (project attributes)
1. Penggunaan sistem pemrograman modern(MODP)
2. Penggunaan perangkat lunak (TOOL)
3. Jadwal pengembangan yang diperlukan (SCED)

Pada tahun 1981, Barry Boehm mendesain COCOMO untuk memberikan estimasi / perkiraan jumlah Person-Months untuk mengembangkan suatu produk software. Referensi pada model ini dikenal dengan nama COCOMO 81.
Pada tahun 1990, muncul suatu model estimasi baru yang disebut dengan COCOMO II. Secara umum referensi COCOMO sebelum 1995 merujuk pada original COCOMO model yaitu COCOMO 81, kemudian setelah itu merujuk pada COCOMO II.
Model estimasi COCOMO telah digunakan oleh ribuan project manager suatu proyek perangkat lunak, dan berdasar pada pengalaman dari ratusan proyek sebelumnya. Tidak seperti model estimasi biaya yang lain, COCOMO adalah model terbuka, sehingga semua detail dipublikasikan, termasuk :
· Dasar persamaan perkiraan biaya
· Setiap asumsi yang dibuat dalam model
· Setiap definisi
· Biaya yang disertakan dalam perkiraan dinyatakan secara eksplisit
Perhitungan paling fundamental dalam COCOMO model adalah penggunaan Effort Equation (Persamaan Usaha) untuk mengestimasi jumlah dari Person-Months yang dibutuhkan untuk pengembangan proyek. Sebagian besar dari hasil-hasil lain COCOMO, termasuk estimasi untuk Requirement dan Maintenance berasal dari persamaan tersebut.

SOURCE LINE OF CODE
Perhitungan COCOMO didasarkan pada estimasi anda pada ukuran proyek dalam Source Line Of Code (SLOC). Pendefinisian SLOC:
· Hanya jumlah baris kode yang dikirim sebagai bagian dari produk yang disertakan (test drivers dan software pendukung lainnya tidak dihitung).
· Baris kode dibuat oleh staf proyek (kode yang di-generate oleh aplikasi tidak dihitung).
· Satu SLOC adalah satu baris kode secara logis.
· Deklarasi dihitung sebagai SLOC.
· Komentar tidak dihitung sebagai SLOC.
Model COCOMO 81 didefinisikan dalam bentuk Delivered Source Instruction, yang mana sangat menyerupai SLOC. Perbedaan utama antara DSI dan SLOC adalah sebuah SLOC mungkin merupakan beberapa baris secara fisik. Sebagai contoh, sebuah statement “if-then-else” akan dihitung sebagai satu SLOC, tetapi mungkin dihitung sebagai beberapa DSI.
SCALE DRIVERS
Pada model COCOMO II, beberapa factor terpenting yang berkontribusi pada durasi proyek dan biaya yang dikeluarkan adalah Scale Drivers. Anda mengeset setiap Scale Driver untuk mendeskripsikan proyek anda. Scale Drivers tersebut menentukan eksponen yang digunakan dalam Effort Equation.
Ada 5 Scale Drivers :
· Precedentedness
· Development Flexibility
· Architecture / Risk Resolution
· Team Cohesion
· Process Maturity
Catat bahwa Scale Drivers telah menggantikan Development Mode dari COCOMO 81. Dua Scale Drivers yang pertama, Precedentedness dan Development Flexibility sebenamya mendeskripsikan pengaruh yang hampir sama dibanding Development Mode.
COST DRIVERS
COCOMO II memiliki 17 cost drivers. Cost driver tersebut adalah factor pengali yang menentukan usaha yang diperlukan untuk menyelesaikan proyek software anda. Sebagai contoh, jika proyek anda akan mengembangkan software yang mengatur penerbangan pesawat, anda akan mengeset Required Software Reliability (RELY) cost driver menjadi sangat tinggi. Rating tersebut berhubungan dengan effort multiplier 1,26 yang berarti bahwa proyek anda akan membutuhkan usaha lebih sebesar 26% dibanding proyek software pada umumnya. COCOMO II mendefinisikan setiap cost drivers dan effort multiplier yang terhubung dengan setiap rating.
COCOMO II EFFORT EQUATION
Model COCOMO II membuat estimasi dari usaha yang dibutuhkan (diukur dari Person-Month) berdasarkan keutamaan dalam estimasi anda akan ukuran proyek perangkat lunak (yang diukur dalam ribuan SLOC atau KSLOC) :
Effort = 2,94 * EAF * (KSLOC)E
Dimana :
EAF = Effort Adjustment Factor yang berasal dari Cost Drivers
E = Eksponen yang berasal dari Scale Drivers.
Sebagai contoh, suatu proyek dengan semua Nominal Cost Drivers dan Scale Drivers akan memiliki sebuah EAF 1,00 dan eksponen (E) 1,0997. Diasumsikan bahwa proyek diproyeksikan terdiri atas 8.000 baris kode, COCOMO II mengestimasi bahwa 28,9 Person-Months effort diperlukan untuk menyelesaikannya :
Effort = 2.94 * (1.0) * (8)1.0997 = 28.9 Person-Months
EFFORT ADJUSTMENT FACTOR
Effort Adjustment Factor dalam effort equation adalah produk dari effort multipliers yang terhubung pada masing-masing cost drivers untuk proyek anda.
Sebagai contoh, jika proyek anda berating sangat tinggi untuk kompleksitas (effort multipliers 1,34) dan rendah untuk pengalaman language & tools (effort multipliers 1,09) dan semua cost drivers yang lain berating nominal (effort multipliers 1,00), sehingga EAF adalah produk dari 1,34 dan 1,09.
EAF= 1,34 * 1,09 = 1,46
Effort = 2,94 * (1,46) * (8)1,0097 = 42,3 Person-Months
COCOMO II SCHEDULE EQUATION
COCOMO II Schedule Equation memprediksi jumlah bulan yang dibutuhkan untuk menyelesaikan proyek perangkat lunak anda. Durasi dari proyek berdasarkan pada usaha yang diprediksi oleh effort equation :
Duration = 3,67 * (Effort)SE
Dimana :
Effort = usaha dari COCOMO II effort equation.
SE = eksponen scheduled equation yang berasal dari Scale Dirvers.
Melanjutkan contoh, dansubtitusi eksponen dengan 0.3179 yang dihitung dari scale drivers, menghasilkan estimasi hanya dalam satu tahun dan rata-rata staf antara 3 sampai 4 orang.
Duration = 3.67 * (42.3)0.3179 = 12.1 months
Average staffing = (42.3 Person-Months) / (12.1 Months) = 3.5 people
SCED COST DRIVER
COCOMO cost driver untuk Required Development Schedule (SCED) adalah unik dan memerlukan penjelasan special.
SCED cost driver digunakan untuk menghitung observasi bahwa proyek yang dikembangkan dalam jadwal yang dipercepat akan membutuhkan usaha yang lebih banyak dari proyek yang dikembangkan dalam jadwal optimal. Sebuah rating SCED yang sangat rendah diwakili oleh sebuah effort multipliers sebesar 1,43 dan berarti bahwa anda berniat menyelesaikan proyek anda dalam 75% jadwal optimal (yang ditentukan oleh estimasi COCOMO sebelumnya). Melanjutkan contoh yang digunakan tadi, tetapi diasumsikan bahwa SCED memiliki rating sangat rendah, COCOMO menghasilkan estimasi :
Duration = 75% * 12.1 Months = 9.1 Months
Effort Adjustment Factor = EAF = 1.34 * 1.09 * 1.43 = 2.09
Effort = 2.94 * (2.09) * (8)1.0997 = 60.4 Person-Months
Average staffing = (60.4 Person-Months) / (9.1 Months) = 6.7 people
Catat bahwa perhitungan durasi tidak berdasar secara langsung pada effort (jumlah Person-Months), justru hal tersebut berdasar pada jadwal yang akan diperlukan untuk proyek diasumsikan proyek tersebut telah berjalan dalam jadwal nominal. Ingat bahwa SCED cost driver berarti “percepatan dari jadwal nominal”.
COCOMO II
COCOMO II diset sebagai siklus hidup software modern. Orgininal COCOMO model sudah sangat berhasil, tetapi tidak sesuai dengan praktek pengembangan software yang lebih baru sebagaimana dengan software tradisional. COCOMO II menargetkan proyek software pada tahun 1990an sampai 2000an dan akan terus berkembang dalam beberapa tahun ke depan.
COCOMO II memiliki 3 model berbeda :
· The Application Composition Model
Sesuai untuk pembangunan proyek dengan tools GUI-builder yang modern. Berdasar pada Object Points baru.
· The Early Design Model
Anda bisa menggunakan model ini untuk mendapat estimasi kasar biaya dan durasi dari suatu proyek sebelum anda menentukan arsitektur keseluruhan proyek tersebut. Model ini menggunakan sekumpulan kecil cost driver baru dan persamaan estimasi baru. Berdasar pada Unadjusted Function Points atau KSLOC.
· The Post-Architecture Model
Ini adalah model COCOMO II yang paling detail. Anda akan menggunakannya setelah anda membentuk arsitektur proyek anda secara menyeluruh. Model ini memiliki cost driver baru, aturan penghitungan baris yang baru, dan persamaan baru.

Kriteria Manager Proyek Yang Baik

Yang dimaksud dengan manager adalah orang atau seseorang yang harus mampu membuat orang-orang dalam organisasi yang berbagai karakteristik, latar belakang budaya, akan tetapi memiliki ciri yang sesuai dengan tujuan (goals) dan teknologi (technology).

Dan tugas seorang manager adalah bagaimana mengintegrasikan berbagai macam variabel (karakteristik, budaya, pendidikan dan lain sebagainya) kedalam suatu tujuan organisasi yang sama dengan cara melakukan mekanisme penyesuaian.
Adapun mekanisme yang diperlukan untuk menyatukan variabel diatas adalah sebagai berikut:

• Pengarahan (direction) yang mencakup pembuatan keputusan, kebijaksanaan, supervisi, dan lain-lain.
• Rancangan organisasi dan pekerjaan.
• Seleksi, pelatihan, penilaian, dan pengembangan.
• Sistem komunikasi dan pengendalian.
• Sistem reward.

Hal tersebut memang tidak mengherankan karena posisi Manajer Proyek memegang peranan kritis dalam keberhasilan sebuah proyek terutama di bidang teknologi informasi. Berikut ini kualifikasi teknis maupun nonteknis yang harus dipenuhi seorang Manajer Proyek yang saya sarikan dari IT Project Management Handbook.

Setidaknya ada 3 (tiga) karakteristik yang dapat digunakan untuk mengukur tingkat kualifikasi seseorang untuk menjadi Manajer Proyek yaitu:

• Karakter Pribadinya
• Karakteristik Kemampuan Terkait dengan Proyek yang Dikelola
• Karakteristik Kemampuan Terkait dengan Tim yang Dipimpin

Karakter Pribadinya

1. Memiliki pemahaman yang menyeluruh mengenai teknis pekerjaan dari proyek yang dikelola olehnya.
2. Mampu bertindak sebagai seorang pengambil keputusan yang handal dan bertanggung jawab.
3. Memiliki integritas diri yang baik namun tetap mampu menghadirkan suasana yang mendukung di lingkungan tempat dia bekerja.
4. Asertif
5. Memiliki pengalaman dan keahlian yang memadai dalam mengelola waktu dan manusia.

Karakteristik Kemampuan Terkait dengan Proyek yang Dikelola

1. Memiliki komitmen yang kuat dalam meraih tujuan dan keberhasilan proyek dalam jadwal, anggaran dan prosedur yang dibuat.
2. Pelaksanakan seluruh proses pengembangan proyek IT sesuai dengan anggaran dan waktu yang dapat memuaskan para pengguna/klien.
3. Pernah terlibat dalam proyek yang sejenis.
4. Mampu mengendalikan hasil-hasil proyek dengan melakukan pengukuran dan evaluasi kinerja yang disesuaikan dengan standar dan tujuan yang ingin dicapai dari proyek yang dilaksanakan.
5. Membuat dan melakukan rencana darurat untuk mengantisipasi hal-hal maupun masalah tak terduga.
6. Membuat dan menerapkan keputusan terkait dengan perencanaan.
7. Memiliki kemauan untuk mendefinisikan ulang tujuan, tanggung jawab dan jadwal selama hal tersebut ditujukan untuk mengembalikan arah tujuan dari pelaksanaan proyek jika terjadi jadwal maupun anggaran yang meleset.
8. Membangun dan menyesuaikan kegiatan dengan prioritas yang ada serta tenggat waktu yang ditentukan sebelumnya.
9. Memiliki kematangan yang tinggi dalam perencanaan yang baik dalam upaya mengurangi tekanan dan stres sehingga dapat meningkatkan produktifitas kerja tim.
10. Mampu membuat perencanaan dalam jangka panjang dan jangka pendek.

Karakteristik Kemampuan Terkait dengan Tim yang Dipimpin

1. Memiliki kemampuan dan keahlian berkomunikasi serta manajerial.
2. Mampu menyusun rencana, mengorganisasi, memimpin, memotivasi serta mendelegasikan tugas secara bertanggung jawab kepada setiap anggota tim.
3. Menghormati para anggota tim kerjanya serta mendapat kepercayaan dan penghormatan dari mereka.
4. Berbagi sukses dengan seluruh anggota tim.
5. Mampu menempatkan orang yang tepat di posisi yang sesuai.
6. Memberikan apresiasi yang baik kepada para anggota tim yang bekerja dengan baik.
7. Mampu mempengaruhi pihak-pihak lain yang terkait dengan proyek yang dipimpinnya untuk menerima pendapat-pendapatnya serta melaksanakan rencana-rencana yang disusunnya.
8. Mendelegasikan tugas-tugas namun tetap melakukan pengendalian melekat.
9. Memiliki kepercayaan yang tinggi kepada para profesional terlatih untuk menerima pekerjaan-pekerjaan yang didelegasikan darinya.
10. Menjadikan dirinya sebagai bagian yang terintegrasi dengan tim yang dipimpinnya.
11. Mampu membangun kedisiplinan secara struktural.
12. Mampu mengidentifikasi kelebihan-kelebihan dari masing-masing anggota tim serta memanfaatkannya sebagai kekuatan individual.
13. Mendayagunakan setiap elemen pekerjaan untuk menstimulasi rasa hormat dari para personil yang terlibat dan mengembangkan sisi profesionalisme mereka.
14. Menyediakan sedikit waktu untuk menerima setiap ide yang dapat meningkatkan kematangan serta pengembangan dirinya.
15. Selalu terbuka atas hal-hal yang mendorong kemajuan.
16. Memahami secara menyeluruh para anggota tim yang dipimpinnya dan mengembangkan komunikasi efektif di dalamnya.

Alasan Menggunakan Software Open Source

Open Source adalah sebuah sistem baru dalam mendistribusikan perangkat lunak kepada pengguna dengan memberikan program dan source code nya secara gratis. Bahkan pengguna dapat mempelajari dan melakukan modifikasi untuk membuat software tersebut sesuai dengan kebutuhan mereka.

Isu-isu keamanan yang dihadapi sistem open source, mencakup beberapa filosofi keamanan umum dan bagaimana membuat lebih aman sistem tersebut dari para penyusup. Beberapa pengguna komputer yang merupakan anggota dari komunitas pengguna Open Source Software (OSS) dan free software berpendapat bahwa kode program mereka lebih aman karena kelemahan kode program mereka lebih mudah ditemukan dan diperbaiki oleh pemakai program tersebut. Sementara itu, komunitas hak-hak kepemilikan berpendapat bahwa pembukaan akses ke kode program pada OSS akan memudahkan bagi beberapa kelompok tertentu untuk menyerang program tersebut.

Fitur-fitur utama dari karakteristik open source adalah kebebasan user untuk:

1. Menggunakan software sesuai keinginannya.
2. Memiliki software yang tersedia sesuai kebutuhan.
3. Mendistribusikan software kepada user lainnya.

Kebebasan yang tak terbatas bagi tiap orang untuk mengakses kode program merupakan pedang bermata dua bagi software itu sendiri. Hal ini disebabkan karena kebebasan ini memberikan informasi tentang kelemahan software. Kemudian, yang terjadi adalah eksploitasi kelemahannya. Para hacker akan menggunakan kelemahan ini untuk melakukan hal-hal yang dapat merugikan pengguna software tersebut. Akibatnya akan lebih buruk jika software tersebut merupakan software yang vital bagi pengguna karena akan memungkinkan terjadinya penipuan, pencurian identitas, pencurian informasi, dan sebagainya.

Beberapa keuntungan dari software open source, yaitu:

1. Adanya hak untuk mendistribusikan modifikasi dan perbaikan pada kode.
2. Ketersediaan source code dan hak untuk memodifikasi.
3. Tidak disandera vendor, open source menggunakan format data terbuka, sehingga data menjadi transparan dan bisa dengan bebas diproses di sistem komputer yang berbeda-beda, sambil tetap menjaga keamananya. Dengan demikian, konsumen tidak lagi terikat pada kemauan vendor untuk dapat menggunakan data-datanya.
4. Banyaknya tenaga (SDM) untuk mengerjakan proyek, proyek open source biasanya menarik banyak developer, misalnya pengembangan web server Apache menarik ribuan orang untuk ikut mengembangkan dan memantau.
5. Kesalahan (bugs, error) lebih cepat ditemukan dan diperbaiki, hal ini dikarenakan jumlah developer-nya sangat banyak dan tidak dibatasi. Visual inspection (eye-balling) merupakan salah satu metodologi pencarian bugs yang paling efektif. Selain itu, source code yang tersedia membuat setiap orang dapat mengusulkan perbaikan tanpa harus menunggu dari vendor.
6. Kualitas produk lebih terjamin, hal ini dikarenakan evaluasi dapat dilakukan oleh banyak orang sehingga kualitas produk dapat lebih baik. Namun, hal ini hanya berlaku untuk produk open source yang ramai dikembangkan orang. Tidak selamanya open source dikembangkan oleh banyak orang, karena bisa juga dilakukan oleh individual.
7. Hemat biaya, sebagian besar developer ini tidak dibayar. Dengan demikian, biaya dapat dihemat dan digunakan untuk pengeluaran yang tidak dapat ditunda, misal membeli server untuk hosting web.
8. Tidak mengulangi development, pengulangan (re-inventing the wheel) merupakan pemborosan. Adanya source code yang terbuka membuka jalan bagi seorang programmer untuk melihat solusi-solusi yang pernah dikerjakan oleh orang lain. Namun, pada kenyataannya tetap banyak pengulangan.
9. User dapat memodifikasi dan mengunci agar hanya kalangan terbatas yang dapat membaca kode dan memodifikasinya.
10. Mencegah software privacy yang melanggar hukum.

Beberapa kerugiannya adalah :

1. Kurangnya SDM yang dapat memanfaatkan open source, ketersediaan source code yang diberikan dapat menjadi sia-sia, jika SDM yang ada tidak dapat menggunakannya. SDM yang ada ternyata hanya mampu menggunakan produk saja, Jika demikian, maka tidak ada bedanya produk open source dan yang propriertary dan tertutup.
2. Tidak adanya proteksi terhadap HaKI, kebanyakan orang masih menganggap bahwa open source merupakan aset yang harus dijaga kerahasiannya. Hal ini dikaitkan dengan besarnya usaha yang sudah dikeluarkan untuk membuat produk tersebut. Karena sifatnya dapat di-abuse oleh orang-orang untuk mencuri ide dan karya orang lain.
3. Kesulitan dalam mengetahui status project.
4. Tidak ada garansi dari pengembangan.
5. Limitasi modifikasi oleh orang – orang tertentu yang membuat atau memodifikasi sebelumnya.
6. Untuk beberapa platform, contohnya JAVA yang memiliki prinsip satu tulis dan bisa dijalankan dimana saja, akan tetapi ada beberapa hal dari JAVA yang tidak competible dengan platform lainnya. Contohnya J2SE yang SWT – AWT bridge-nya belum bisa dijalankan di platform Mac OS.
7. Open Source digunakan secara sharing, dapat menimbulkan resiko kurangnya diferensiasi antara satu software dengan yang lain, apabila kebetulan menggunakan beberapa open Source yang sama.