Pertanyaan Hal 114

1. The Capability Maturity Model ( CMM ) was developed the Software

Engineering Institute at Cargenic Mellon, and it widely used both the private
and public sectors. What is the purpose of the CMM Framework and how does it
achieve this ?
Jawaban : Framework CMM untuk sistem dan perangkat lunak informasi bermaksud
untuk membantu organisasi meningkatkan kematangan dari proses pengembangan
sistem. CMM dibagi menjadi lima tingkatan kematangan yang mengukur kualitas
dari proses pengembangan sistem dan perangkat lunak organisasi (setiap level
menjadi pra-syarat bagi level sesudahnya).
Level 1 Initial
Hampir setiap organisasi memulai dari level yang seringkali disebut anarki atau
kekacauan (chaos) ini. Pengembangan system tidak menggunakan proses yang
terstruktur dan tiap developer menggunakan alat dan metodenya masing-masing. Pada
tahap ini umumnya proses tidak dapat diprediksi, tidak berulang, sering mengalami
krisis, over-budget, dan gagal mencapai target waktu. Ciri-ciri dari
fungsi initial adalah tidak ada manajemen proyek, tidak adanya quality assurance,
tidak adanya mekanisme manajemen perubahan (change management), tidak ada
dokumentasi, adanya seorang ahli yang tau segalanya tentang perangkat lunak yang
dikembangkan, dan sangat bergantung pada kemampuan individual.
Level 2 Repeatable
Proses dan praktek manajemen proyek pengembangan system telah dirancang untuk
melacak biaya proyek, jadwal, dan kegunaan dari sistem. Pada tahap ini, fokus
ditekankan pada manajemen proyeknya, bukan pada pengembangan sistem
(pengembangan sistem bervariasi untuk tiap proyek). Kesuksesan dan kegagalan
masih bergantung pada kemampuan dan pengalaman dari tim yang mengerjakan
proyek. Walaupun begitu, telah terdapat usaha untuk mengulang keberhasilan proyek
sebelumnya, dan manajemen proyek yang efektif pun akhirnya menjadi pondasi bagi
standardisasi proses level berikutnya.
Ciri-ciri dari fungsi repeatable adalah kualitas perangkat lunak mulai bergantung pada
proses bukan pada orang, ada manajemen proyek sederhana, ada quality
assurancesederhana, ada dokumen sederhana, ada software configuration management
sederhana, tidak adanya knowledge management, tidak adanya komitmen untuk selalu
mengikuti SDLC dalam kondisi apapun, tidak adanya stastikal control untuk estimasi
proyek dan rentan perubahan struktur organisasi.
 Level 3 Defined
Proses pengembangan sistem standar (umumnya disebut metodologi) telah dimiliki
atau dikembangkan dan telah digunakan secara terintegrasi melalui unit sistem atau
pelayanan informasi organisasi. Sebagai hasilnya, hasil dari setiap proyek menjadi
lebih konsisten, dokumentasi serta penyampaian yang berkualitas tinggi, dan proses
menjadi lebih stabil, mampu diprediksi (predictable), dan berulang (repeatable).
Ciri-ciri dari level Defined adalah SDLC sudah ditentukan, ada komitmen untuk
mengikuti SDLC dalam keadaan apapun, kualitas proses dan produk masih bersifat
kualitatif atau hanya perkiraan saja, tidak menerapkan Activity Based Costing, dan
tidak adanya mekanisme umpan balik yang baku.
Level 4 Managed
Telah memiliki tujuan yang terukur untuk kualitas dan produktivitas. Ukuran
mendetail mengenai proses pengembangan proses standar dan kualitas produk telah
dikumpulkan secara rutin dan disimpan dalam database. Pada tahap ini manajemen
lebih proaktif dalam melihat masalah pengembangan sistem. Jadi walaupun proyek
menemui masalah atau isu yang tidak diperkirakan, proses masih akan dapat
disesuaikan berdasarkan efek dari kondisi yang mampu diprediksi dan terukur.
Ciri-cirinya adalah sebagai berikut, sudah ada Activity Based Costing dan digunakan
untuk estimasi proyek berikutnya, proses penilaian kualitas perangkat lunak dan
proyek bersifat kuantitatif, terjadi pemborosan biaya untuk pengumpulan data karena
proses pengumpulan data masih dilakukan secara manual, cenderung belum jelas
disebabkan karena manusia ketika diperhatikan perilakuknya cenderung berubah,
tidak ada mekanisme pencegahan defect dan adanya mekanisme umpan balik.
Level 5 Optimized
Proses pengembangan sistem terstandarisasi secara kontinu dimonitor dan
ditingkatkan berdasarkan ukuran dan analisa data di level 4. Setiap pembelajaran yang
ada disebarluaskan pada seluruh bagian organisasi dengan penekanan pada penurunan
ketidakefisienandalam proses pengembangan sistem ketika menjaga kestabilan
kualitas. Sebagai kesimpulan, organisasi telah menjadikan peningkatan proses
pengembangan sistem yang kontinu bagian dari dirinya.
Cirri-cirinya adalah sebagai berikut, Pengumpulan data secara automatis, adanya
mekanisme pencegahan defect, adanya mekanisme umpan balik yang sangat baik, dan
adanya peningkatan kualitas dari SDM dan juga peningkatan kualitas proses.
2. List the five maturity levels, and briefly describe each of them ?
Jawaban :
Maturity level 1 : Initial
 Pada tingkat 1, proses biasanya ad hoc dan kacau. Organisasi biasanya tidak
menyediakan lingkungan yang stabil. Sukses dalam organisasi ini tergantung pada
kompetensi dan heroik dari orang-orang dalam organisasi dan bukan pada penggunaan
proses terbukti.
Maturity level 2 : Managed
Pada tingkat 2, sebuah organisasi telah mencapai semua tujuan spesifik dan generik
dari area proses tingkat kematangan 2. Dengan kata lain, proyek organisasi telah
memastikan bahwa persyaratan dikelola dan bahwa proses yang direncanakan,
dilakukan, diukur, dan dikendalikan.
Maturity level 3 : Defined
Pada tingkat kematangan 3, proses yang ditandai dengan baik dan dipahami, dan
dijelaskan dalam standar, prosedur, alat, dan metode.
Maturity level 4 : Quantitatively Managed
Pada tingkat kematangan 4 Subproses dipilih yang secara signifikan berkontribusi
terhadap kinerja proses secara keseluruhan. Ini subproses dipilih dikendalikan
menggunakan teknik kuantitatif statistik dan lainnya.
Maturity level 5 : Optimizing
Kematangan tingkat 5 berfokus pada kinerja proses terus-menerus meningkatkan baik
melalui perbaikan teknologi tambahan dan inovatif.
3. Between which two CMM levels does an organization gain the greatest benefit in
terms of percentages of improvement? what do you think is the reason for this ?
Jawaban :
Sangat penting untuk menyadari bahwa setiap tingkat merupakan prasyarat untuk
tingkat berikutnya. Saat ini, banyak organisasi yang bekerja keras untuk mencapai
setidaknya CMM level 3 (sehingga melitemes didorong oleh pemerintah atau organisi
Mandare). Sebuah tema sentral untuk mencapai tingkat 3 (ditentukan) adalah
penggunaan proses standart atau methology untuk membangun atau mengintegrasikan
sistem. Seperti terlihat pada tabel 3-1, sebuah organisi dapat mewujudkan peningkatan
tidak bisa signiti di jadwal dan biaya dengan melembagakan tingkat CMM 3 proses
perbaikan.

4. Metedologi pengembangan sistem dan siklus hidup sistem adalah dua istilah
yang sering digunakan dan sering disalahgunakan. Apa perbedaan dari dua
istilah tersebut ?
Jawab:

Siklus hidup sistem adalah sebuah pemfaktoran umur hidup sebuah sistem informasi
ke dalam dua tahap , yaitu pengembangan sistem dan operasi dan perawatan sistem . pertama
kita akan membangunnya kemudian akan menggunakan dan merawatnya. Pada akhirnya, kita
kembali ke pengembangan ulang sebuah sistem baru.

Metodologi pengembangan sistem adalah sebuah proses pengembangan

terstandarisasi yang mendefinidsikan satu set aktifitas, metode, praktik terbaik, barang siap
kirim, dan perangkat terotomasi yang akan digunakan oleh para pengembang sistem dan
secara berkesinambungan memperbaiki sistem informasi dan perangkat lunak.

Jadi metedologi pengembangan sistem mengeksekusi pengembangan sistem siklus

hidup sistem sesuai dengan tujuan CMM ( Capability Maturity Model ).
5. Describe how using a system development methodology is in line with CMM
goals and can help an organization increase its maturity level
Jawab:
CMM merupakan mekanisme kualifikasi sebuah Software Development House yang
dapat memberikan gambaran tentang kemampuan perusahaan tersebut dalam
melakukan development software. Capability Maturity Model adalah sebuah model
yang dikembangkan oleh Software Engineering Institute atas permintaan Departement
of Defense(DOD) Amerika Serikat dengan tujuan membuat ujian saringan masuk bagi
kontraktor yang mendaftarkan diri untuk menjadi konsultan

Pengertian secara harfiah:

- Capability, diartikan menjadi kapabilitas yang berarti kemampuan yang
bersifat laten. Capability lebih mengarah kepada integritas daripada
kapabilitas yang berarti itu sendiri.
- Maturity, berarti matang atau dewasa. Matang merupakan hasil proses.
Dewasa merupakan hasil pertumbuhan
- Model, didefinisikan sebagai suatu penyederhanaan yang representatif
terhadap keadaan di dunia nyata

Secara keseluruhan pengertian CMM, yaitu:

CMM dapat didefinisikan sebagai sebuah penyederhanaan yang representatif yang
digunakan untuk mengukur tingkat kematangan sebuah software development house
dalam menyajikan/membuat/mengembangkan perangkat lunak sebagaimana telah
dijanjikan secara tertulis dalam perjanjian kerjasama. Sehingga bisa dikatakan bahwa
CMM adalah mengukur.

Nilai-nilai yang dilihat dalam pengukuran tersebut:

1. Apa yang diukur (Parameter)
2. Bagaimana cara mengukurnya (Metode)
3. Bagaimana standar penilaiannya (Skala Penilaian)
 4. Bagaimana Interpretasinya (Bagi Manusia)

Capability Maturity Model terdapat 5 level/skala kematangan yaitu :

Initial

Ciri-ciri dari fungsi initial adalah tidak ada manajemen proyek, tidak adanya quality
assurance, tidak adanya mekanisme manajemen perubahan (change management), tidak ada
dokumentasi, adanya seorang ahli yang tau segalanya tentang perangkat lunak yang
dikembangkan, dan sangat bergantung pada kemampuan individual.

Repeatable

Ciri-ciri dari fungsi repeatable adalah kualitas perangkat lunak mulai bergantung pada proses
bukan pada oprang, ada manajemen proyek sederhana, ada quality assurance sederhana, ada
dokumen sederhana, ada software configuration management sederhana, tidak adanya
knowledge management, tidak adanya komitmen untuk selalu mengikuti SDLC dalam
kondisi apapun, tidak adanya stastikal control untuk estimasi proyek dan rentan perubahan
struktur organisasi.

Defined

Ciri-ciri dari level Defined adalah SDLC sudah ditentukan, ada komitmrn untuk mengikuti
SDLC dalam keadaan apapun, kualitas proses dan produk masih bersifat kualitatif atau hanya
perkiraan saja, idak menerapkan Activity Based Costing, dan tidak adanya mekanisme umpan
balik yang baku.

Managed

Ciri-cirinya adalah sebagai berikut, sudah ada Activity Based Costing dan digunakan untuk
estimasi proyek berikutnya, proses penilaian kualitas perangkat lunak dan proyek bersifat
kuantitatif, terjadi pemborosan biaya untuk pengumpulan data karena proses pengumpulan
data masih dilakukan secara manual, cenderung belum jelas disebabkan karena masnusia
ketika diperhatikan perilakuknya cenderung berubah, tidak ada mekanisme pencegahan
defect dan adanya mekanisme umpan balik

Optimized
Pengumpulan data secara automatis, adanya mekanisme pencegahan defect, adanya
mekanisme umpan balik yang sangat baik, dan adanya peningkatan kualitas dari SDM dan
juga peningkatan kualitas proses.

6. A number of underlying principles are the common to all systems development

methodologies. Identify principles and explain them
Jawab:
Get the system users involved.
Use a problem-solving approach.
Establish phase and activities.
Document throughout development.
Establish standards.
Manage the process and projects.
Justify information systems capital investments.
Dont be afraid to cancel and revise scope.
Divide and conquer.
Design systems for growth and change.

A. Sistem yang dikembangkan adalah untuk manajemen.

Setelah sistem selesai dikembangkan, maka yang akan menggunakan informasi dari
sistem ini adalah manajemen, sehingga sistem harus dapat mendukung, kebutuhan
yang diperlukan oleh manajemen. Pada waktu Anda mengembangkan sistem, maka
prinsip ini harus selalu diingat.

B. Sistem yang dikembangkan adalah investasi modal yang besar.

Sistem informasi yang akan Anda kembangkan membutuhkan dana modal yang tidak
sedikit, apalagi dengan digunakannya teknologi yang mutakhir.
Sistem yang dikembangkan ini merupakan investasi modal yang besar. Seperti halnya
dengan investasi modal lainnya yang dilakukan oleh perusahaan, maka setiap
investasi modal harus mempertimbangkan 2 hal berikut ini:
Semua alternatif yang ada harus diinvestigasi.
Investasi yang terbaik harus bernilai.

C. Sistem yang dikembangkan memerlukan orang-orang yang terdidik.

Manusia merupakan faktor utama yang menentukan berhasil tidaknya su atu sistem,
baik dalam proses pengembangannya, penerapannya, maupun dalam proses
operasinya. Oleh karena itu orang yang terlibat dalam pengembangan maupun
penggunaan sistem ini harus merupakan orang yang terdidik tentang permasalahan-
permasalahan yang ada dan terhadap solusi-solusi yang mungkin dilakukan.
D. Tahapan kerja dan tugas-tugas yang harus dilakukan dalam proses pengembangan
sistem.
Proses pengembangan sistem umumnya melibatkan beberapa tahapan kerja dan
melibatkan beberapa personil dalam bentuk suatu team untuk mengerjakannya.
Pengalaman menunjukan bahwa tanpa adanya perencanaan dan koordinasi yang baik,
maka proses pengembangan sistem tidak akan berhasil dengan memuaskan. Untuk
maksud ini sebelum proses pengembangan sistem dilakukan, maka harus dibuat
terlebih dahulu skedul kerja yang menunjukkan tahapan-tahapan kerja dan tugas-tugas
pekerjaan yang akan dilakukan, sehingga proses pengembangan sistem dapat
dilakukan dan selesai dengan berhasil sesuai dengan waktu dan anggaran yang
direncanakan.

E. Proses pengembangan sistem tidak harus urut.

Prinsip ini kelihatannya bertentangan dengan prinsip nomor 4, tetapi tidaklah
sedemikian. Tahapan kerja dari pengembangan sistem di prinsip nomor 4
menunjukkan langkah-langkah yang harus dilakukan secara bersama-sama. Ingatlah
waktu adalah uang. Misalnya di dalam pengembangan sistem, perancangan output
merupakan tahapan yang harus dilakukan sebelum melakukan perancangan file. Ini
tidak berarti bahwa semua output harus dirancang semuanya terlebih dahulu baru
dapat melakukan perancangan file, tetapi dapat dilakukan secara serentak, yaitu
sewaktu proses pengadaan hardware.

F. Jangan takut membatalkan proyek.

Umumnya hal ini merupakan pantangan untuk membatalkan suatu proyek yang
sedang berjalan. Keputusan untuk meneruskan suatu proyek atau membatalkannya
memang harus dievaluasi dengan cermat. Untuk kasus-kasus yang tertentu, dimana
suatu proyek terpaksa harus dihentikan atau dibatalkan karena sudah tidak layak lagi,
maka harus dilakukan dengan tegas. Keraguan untuk terus melanjutkan proyek yang
tidak layak lagi karena sudah terserapnya dana kedalam proyek ini hanya akan
memubang dana yang sia-sia.

7. PIECES Framework telah dikembangkan oleh James Watherbe, sebagai sarana

mengkelompokan masalah. Identifikasi kategori, lalu mengkategorikan masalah
dibawah ini dengan menggunakan PIECES Framework.
Duplikasi data disimpan di semua system.
kebutuhan untuk port sebuah aplikasi yang sudah ada ke perangkat PDA
laporan penjualan perkuartal dihasilkan secara otomatis.
Karyawan dapat mengakses kebagian rahasia dari system.
 Bagi saya, user interface untuk system inventory sangat susah dan
membingungkan. Sehingga menghasilkan tingkat kesalahan yang tinggi.
Jawaban :
1. Performance
Memiliki waktu respon yang baik karena telah di perhitungkan dan dilakukan secara
otomatis
2. Informasi dan data
- Outputs
Kurangnya informasi yang diperlukan, baik itu dalam hal petunjuk pada user interface
karena dapat membingungkan pengguna dan berdampak meningkatnya kesalahan
yang tinggi.
- Inputs
Data terlalu di expose jadi dapat mengambil data secara berlebih, sehingga karyawan
bisa mengakses kerahasiaan dari system. Akibat dari mengambil data berlebihan dari
system, akan mudah terkena hacking dari orang yang tidak bertanggung jawab.
- Penyimpanan Data
Data disimpan secara berlebihan dengan menyimpan di semua system, hal ini akan
merumitkan untuk mencari duplikasi data yang penting.
3. Economic
Biaya tidak diketahui seperti biaya yang dikeluarkan dll.
4. Control and security
Terlalu sedikit keamanan dan pengawasan pada sytem. Akan merugikan sebuah
perusahaan
5. Efficiency
Dengan menggunakan PDA efficiency lebih meningkat, karena kita bias memantau
apabila kita tidak di ruangan dan di kantor.
6. Service
System menghasilkan produk yang tidak akurat, membuat pengguna menjadi bingung
dan sangat susah. Dan system tidak mudah dipelajari mengakibatkan banyak
kesalahan.

8. Each phase of a project includes specific deliverables that must be produced and
delivered to the next phase. Using tile textbook's hypothetical FAST
methodology, what are the deliverables for the requirements analysis, logical
design, and physic design/Integration phases?
Jawaban : Logical Design adalah bagian dari fase desain dalam SDLC dimana semua
fitur-fitur fungsional dari sistem dipilih dari tahapan analisis dideskripsikan terpisah
dari platform komputer yang nanti digunakan. Hasil dari tahapan ini adalah : o
Deskripsi fungsional mengenai data dan proses yang ada dalam sistem baru o
 Deskripsi yang detail dari spesifikasi sistem meliputi:
Input (data apa saja yang menjadi input)
Output (informasi apa saja yang menjadi output)
Process (prosedur apa saja yang harus dieksekusi untuk mengubah input menjadi
output)
Tahapan disain logikal biasanya menghasilkan beberapa dokumen diantaranya :
dokumen model data, dokumen model proses, rancangan tabel, hirarki antar modul
sampai ke desain antar muka dari system yang akan dibuat. Physical design Pada
bagian ini spesifikasi logical diubah ke dalam detail teknologi dimana pemrograman
dan pengembangan sistem bisa diselesaikan.

9. Scope definition is the first phase of the FAST methodology and it is either the
first phase or pasrt of the first phase of most methodlogy?
Jawaban : Metodologi pengembangan sistem (system development
methodology) adalah proses pengembangan sistem yang sangat formal dan akurat
yang mendefinisikan sekumpulan aktivitas, metode, praktek-praktek terbaik,
penyampaian, dan alat terotomasi yang digunakan oleh pengembang sistem dan
manajer proyek untuk mengembangkan dan memelihara sistem
dan software informasi.
Salah satu metodologi pengembangan sistem yang umum dipakai adalah
metodologi FAST (Framework for the Application of Systems Technique).

Metodologi FAST terdiri dari fase-fase berikut:

1. Scope Definition (Definisi Lingkup)
2. Problem Analysis (Analisis Permasalahan)
3. Requirements Analysis (Analisis Kebutuhan)
4. Logical Design (Desain Logis)
5. Decision Analysis (Analisis Keputusan)
6. Physical Design (Desain Logis)
7. Construction and Testing
8. Installation and Delivery
Karena scope definition adalah definisi lingkupan atau dengan kata lain mencangkup
seluruh fase fase methodology FAST. Dan Pada tahap ini dilakukan pengumpulan
informasi yang akan diteliti tingkat feasibility dan ruang lingkup proyek yaitu dengan
menggunakan kerangka PIECES (Performance, Information, Economics, Control,
Efficiency, Service). Hal ini dilakukan untuk menemukan inti dari masalah-masalah
yang ada (problems), kesempatan untuk meningkatkan kinerja organisasi
(opportunity), dan kebutuhan-kebutuhan baru yang dibebankan oleh pihak manajemen
atau pemerintah (directives).
10. the requirements analysts phase is an essential part of a system development
methodology. According to the FAST methodology, which stakeholders typically
participate In thls phase? What Is the primary focus of requirements analysis'
What is not the focus? How should each proposed requirement be evaluated?
What Critical error must be avoided?
Jawaban : pemangku kepentingan yang berpartisipasi disebut Discovery prototyping,
Persyaratan adalah fokus utama dalam proses rekayasa sistem karena tujuan utama
proses ini adalah untuk mengubah persyaratan ke dalam desain. Proses
mengembangkan desain ini dalam batasan. Mereka akhirnya harus diverifikasi untuk
memenuhi kedua persyaratan dan kendala.
kesalahan kritis dan bagaimana untuk menghindarinya:
> Masalah 1: Pelanggan tidak (benar-benar) tahu apa yang mereka inginkan
Untuk mengatasi masalah ini, Anda harus:
Pastikan bahwa Anda menghabiskan waktu yang cukup pada awal proyek pada
pemahaman tujuan, kiriman dan ruang lingkup proyek.
Buat terlihat setiap asumsi bahwa pelanggan menggunakan, dan kritis mengevaluasi
baik manfaat end-user kemungkinan dan risiko proyek.
Mencoba untuk menulis sebuah pernyataan visi beton untuk proyek, yang meliputi
baik fungsi tertentu atau manfaat pengguna memberikan dan masalah bisnis secara
keseluruhan diharapkan untuk memecahkan.
Dapatkan pelanggan Anda untuk membaca, memikirkan dan menandatangani
persyaratan spesifikasi perangkat lunak selesai, untuk menyelaraskan harapan dan
memastikan bahwa kedua belah pihak memiliki pemahaman yang jelas tentang
penyampaian.
> masalah 2: Persyaratan mengubah selama proyek
Untuk mengatasi masalah ini, Anda harus:
Memiliki proses yang jelas untuk menerima, menganalisis dan menggabungkan
perubahan permintaan, dan membuat pelanggan Anda menyadari / nya entry point ke
dalam proses ini.
Set tonggak untuk setiap tahap pengembangan di luar yang perubahan tertentu tidak
diperbolehkan - misalnya, pelarangan perubahan besar sekali modul mencapai 75
persen selesai.
Pastikan bahwa permintaan perubahan (dan persetujuan) dikomunikasikan dengan
jelas kepada semua pemangku kepentingan, bersama dengan alasan mereka, dan
bahwa rencana proyek induk diperbarui sesuai.

> Masalah 3: Pelanggan memiliki jadwal yang tidak masuk akal

Untuk mengatasi masalah ini, Anda harus:
 Mengkonversi persyaratan spesifikasi perangkat lunak ke dalam rencana proyek,
merinci tugas dan sumber daya yang dibutuhkan pada setiap tahap dan pemodelan
kasus terbaik, menengah-kasus dan skenario terburuk.
Pastikan bahwa rencana proyek memperhitungkan keterbatasan sumber daya yang
tersedia dan membuat waktu yang cukup untuk pengujian dan pemeriksaan kualitas.
Masukkan ke dalam percakapan tentang tenggat waktu dengan pelanggan Anda,
menggunakan angka-angka dalam draft rencana Anda sebagai bukti pendukung untuk
laporan Anda. Dengan asumsi bahwa rencana Anda adalah wajar, itu sangat mungkin
bahwa negosiasi berikutnya akan baik produktif dan hasilnya dalam hasil yang
menguntungkan bagi kedua belah pihak.

11. In the FAST methodology, as well as most system methodologies, system owners
and system designers do not participate in the requirements analysis phase.
What do you think the reason is for this?
Jawaban : pada tahap ini analisis sistem yg harus kerja nyari kebutuhan para
pengguna apa yg diinginkan sama pengguna dari sistem baru tsb, tapi dia harus
menghindari diskusi teknologi sama implementasi teknis.
Kendala yg sering terjadi pada sistem dan aplikasi baru itu biasanya tidak benar-benar
memenuhi kebutuhan pengguna Ini terjadi karena para desainer dan pembangun
sistem terlalu asik sama solusi teknis sebelum benar2 memahami kebutuhan2
bisnisnya sendiri
12. Apa tujuan penting dari fase desain logis? Bagaimana cara mencapai hal ini?
Bagaimana solusi teknologi yang tergabung dalam fase ini? Apakah beberapa
sinonim umum untuk fase ini digunakan oleh metodologi lain? Siapa saja ciri
khas dalam fase ini? Apa pemodelan tangkas dan apa tujuannya? Apa kiriman
keluar dari fase ini? Dalam hal tim pengembangan, apa transisi kritis terjadi
pada akhir fase ini?
Jawaban : Tahap desain logis menerjemahkan kebutuhan bisnis ke model. Proses ini
adalah independen dari solusi teknologi, dan hanya memetakan proses bisnis dalam
persiapan menuju tahap selanjutnya, yaitu mulai untuk memenerjemahkannya ke
dalam solusi teknis. Istilah system pemodelan juga di gunakan untuk menggambarkan
fase ini. Analis sistem, pengguna, dan manajer proyek yang termasuk dalam fase ini
berguna untuk memastikan tinkat detail yang tepat yang sudah dicapai dan standar
yang harus ditaati. Pemodelan agile berguna untuk mengurangi jumlah waktu yang
dihabiskan di fase ini, dan metodologi seperti pemograman ekstrim menekankan fase
ini dengan asumsi bahwa, tidak peduli seberapa besar persyaratan proyek akan
 berubah. Data, Proses dan model interface harus di tarik keluar dari fase ini yang
berasal dari fase sebelumnya. Transfer proyek dari bagian sistem desain dari sistem
pengembangan.

13. Apa tujuan penting dari fase Physical Design? Yang harus terlibat dalam fase
ini, dan yang mungkin terlibat? Apakah dua filosofi desain fisik pada ujung yang
berbeda dari kontinum, dan bagaimana mereka berbeda? Apakah ini fase
kemungkinan di mana proyek mungkin dibatalkan? Dengan apa fase lain adalah
ada kemungkinan akan tumpang tindih, dan apa yang Anda pikir adalah alasan
untuk ini?
Jawaban :
untuk menerapkan database. pada tahap ini seseorang harus mengetahui sistem yang
manajemen database (dbms) yang digunakan.
administrator database harus terlibat dalam fase physical design. yang terlibat dalam
fase physical design adalah database analyst, database modeler, programmer analyst
dan system manager.
dua filosofi desain fisik adalah centralized design dan decentralized design. yang
berbeda dari keduanya adalah, centralized design adalah produktif ketika komponen
data terdiri dari jumlah yang relatif kecil obyek dan prosedur, disamping itu
decentralized design digunakan ketika komponen data sistem memiliki jumlah yang
cukup of entitas dan hubungan kompleks pada yang sangat kompleks operasi
dilakukan.
ya, itu bisa dibatalkan, jika di dalam fase logical design terdapat beberapa perubahan,
maka di dalam fase physical design juga harus mengikuti perubahan yang terjadi pada
fase logical design.
dengan fase logical design. karena fase logical design jika terjadi perubahan, maka di
fase physical design akan terjadi perubahan yang saling tumpang tindih

14. A customer has engaged your software development company to develop a new
order-processing system. However, the time frames are very tight and inflexible
for delivery of at least the basic part of the new system. Further, user
requirements are sketchy and unclear. What are two system development
strategies that might be advantageous to use in this engagement?
Jawaban : Iterative Development and Rapid Application Development Strategy.
15. Apa potensi downside untuk menggunakan strategi yang dijelaskan dalam
pertanyaan sebelumnya?
Jawaban : Menggunakan metodologi RAD dapat meningkatkan biaya sistem seumur
hidup melalui apa yang sering dianggap sebagai filosofi "kode, menerapkan dan
perbaikan" karena penekanannya pada kecepatan pelaksanaan. Sebuah solusi COTS
mungkin berakhir biaya jauh lebih daripada yang diantisipasi karena integrasi sistem
bisa sangat sulit dan memakan waktu. Selanjutnya, solusi COTS mungkin berakhir
mengemudi proses bisnis, bukan sebaliknya dengan proses bisnis mengemudi solusi
teknologi.