Skip to main content

System Design (Desain Sistem) Menurut Ian Sommerville

Gambar 1 

Proses desain sistem yang ditunjukkan dalam Gambar 1 berhubungan dengan cara komponen-komponen sistem memberikan fungsionalitas sistem. Langkah-langkah yang dilakukan dalam proses tersebut adalah sebagai berikut:

  1. Partition requirements, Pada tahap ini, Anda melakukan analisis terhadap persyaratan dan mengelompokkannya ke dalam kelompok yang relevan. Dalam kebanyakan kasus, ada beberapa opsi partisi yang dapat dipertimbangkan, dan pada tahap ini Anda dapat menyarankan beberapa alternatif.
  2. Identify sub-systems, Terdapat keharusan untuk mengidentifikasi sub-sistem yang dapat memenuhi persyaratan secara individual atau bersama-sama. Kelompok persyaratan cenderung terkait dengan sub-sistem, sehingga aktivitas partisi persyaratan dapat dikelompokkan. Meskipun demikian, faktor-faktor organisasi atau lingkungan lain juga dapat memengaruhi identifikasi sub-sistem.
  3. Assign requirements to sub-systems, Tahap selanjutnya adalah menetapkan persyaratan untuk sub-sistem. Dalam prinsipnya, hal ini seharusnya langsung dilakukan apabila persyaratan partisi digunakan untuk membantu mengidentifikasi sub-sistem. Namun, dalam kenyataannya, tidak selalu ada kesesuaian yang sempurna antara partisi persyaratan dan sub-sistem yang telah teridentifikasi. Terkadang keterbatasan dari sub-sistem yang dibeli dari luar dapat memaksa perubahan pada persyaratan untuk mengakomodasi kendala tersebut.
  4. Specify sub-system functionality, Langkah berikutnya adalah menentukan fungsi yang disediakan oleh masing-masing sub-sistem secara spesifik. Hal ini bisa dilakukan sebagai bagian dari tahap desain sistem atau, jika sub-sistem merupakan sistem perangkat lunak, dapat menjadi bagian dari aktivitas spesifikasi kebutuhan untuk sistem itu. Selain itu, pada tahap ini juga harus dilakukan upaya untuk mengidentifikasi hubungan antar sub-sistem.
  5. Define sub-system interfaces, Selanjutnya, perlu dilakukan penentuan antarmuka yang disediakan dan dibutuhkan oleh masing-masing sub-sistem. Setelah antarmuka tersebut disetujui, sub-sistem dapat dikembangkan secara paralel.

Gambar 1 menunjukkan bahwa dalam proses desain ini terdapat banyak umpan balik dan iterasi yang terjadi antara tahap-tahap. Ketika masalah dan pertanyaan muncul, seringkali diperlukan untuk mengulang pekerjaan yang dilakukan pada tahap awal. Hal ini tercermin pada panah berujung ganda yang menghubungkan tahap-tahap pada gambar tersebut.

Walaupun dalam pembahasan ini saya telah memisahkan antara proses rekayasa dan desain persyaratan, namun pada praktiknya keduanya saling berkaitan. Kendala yang timbul dari sistem yang sudah ada dapat membatasi pilihan desain, dan pilihan tersebut dapat ditentukan oleh persyaratan. Oleh karena itu, mungkin diperlukan beberapa desain awal untuk menyusun dan mengorganisir proses rekayasa persyaratan. Selama proses desain berlangsung, mungkin akan ditemukan masalah dengan persyaratan yang telah ada, dan persyaratan baru mungkin juga akan muncul. Oleh karena itu, salah satu cara untuk memandang hubungan proses-proses tersebut adalah dengan menggunakan pendekatan spiral, seperti yang ditunjukkan pada Gambar 2.

Gambar 2

Proses spiral memperlihatkan bahwa persyaratan dan desain saling memengaruhi satu sama lain, sehingga wajar jika proses ini diintegrasikan. Pada setiap putaran spiral, bisa jadi detail persyaratan atau desain ditambahkan. Terkadang, fokusnya hanya pada persyaratan atau hanya pada desain. Namun, terkadang pengetahuan baru yang didapat selama proses persyaratan dan desain menyebabkan perlu dilakukan perubahan pada pernyataan masalah itu sendiri.

Gambar 3

Anda dapat memilih dari berbagai kemungkinan desain yang dapat memenuhi persyaratan sistem. Solusi yang Anda pilih dapat menjadi yang paling tepat secara teknis untuk pengembangan sistem, tetapi pertimbangan organisasi dan politik yang lebih luas dapat mempengaruhi pilihan solusi. Sebagai contoh, klien pemerintah mungkin lebih memilih menggunakan pemasok dalam negeri daripada asing meskipun produk dalam negeri kurang unggul secara teknis. Faktor-faktor ini biasanya mempengaruhi fase peninjauan dan evaluasi dalam model spiral di mana desain dan persyaratan dapat diterima atau ditolak. Proses desain berakhir ketika tinjauan dan evaluasi menunjukkan bahwa persyaratan dan desain yang lebih rinci memungkinkan untuk memulai fase proses selanjutnya.



Source: Sommerville, Ian. 2007. Software Engineering Eight Edition. s.l. : Addison-. Wisley, 2007.

Labels:

Comments

Post a Comment

Popular posts from this blog

Proses Perangkat Lunak Menurut Roger S. Pressman

Suatu proses adalah gabungan dari beberapa kegiatan, aksi, dan pekerjaan yang dikerjakan saat akan membuat beberapa produk. Setiap kegiatan memiliki tujuan yang luas (seperti komunikasi dengan pemangku kepentingan) dan diterapkan secara universal, tidak peduli pada domain aplikasi, ukuran proyek, kompleksitas usaha, atau tingkat ketelitian rekayasa perangkat lunak yang digunakan. Aksi (contohnya, desain arsitektur) mencakup rangkaian tugas yang menghasilkan produk utama (sebagai contoh, model desain arsitektural). Sebuah tugas berfokus pada tujuan yang kecil namun terdefinisi dengan baik (seperti melakukan pengujian unit) yang menghasilkan hasil yang konkret. Dalam dunia rekayasa perangkat lunak, suatu proses tidaklah berarti resep yang kaku untuk membuat perangkat lunak. Sebaliknya, proses ini merupakan pendekatan yang dapat disesuaikan yang memungkinkan tim pengembang perangkat lunak untuk memilih dan mengeksekusi serangkaian tindakan dan tugas yang sesuai. Tujuannya adalah untuk sel...
Post a Comment
Read more

Extreme Programming (XP) Menurut Roger S. Pressman

 Untuk memberikan gambaran yang lebih rinci tentang proses agile, saya akan memaparkan Extreme Programming (XP), suatu pendekatan yang banyak digunakan dalam pengembangan perangkat lunak agile. Meskipun ide dan metode yang terkait dengan XP telah muncul pada akhir 1980-an, Kent Beck telah menulis secara ekstensif mengenai topik ini. Baru-baru ini, sebuah varian XP yang disebut Industrial XP (IXP) telah diajukan. IXP telah menyempurnakan XP dan dirancang untuk digunakan khusus dalam organisasi besar dengan proses yang lebih fleksibel. 1.1 XP Values Sebuah seperangkat lima nilai yang menjadi dasar bagi seluruh pekerjaan yang dilakukan dalam XP telah didefinisikan oleh Beck. Nilai-nilai ini mencakup communication, simplicity, feedback, courage, dan respect, dan masing-masing nilai ini digunakan sebagai motivasi dalam aktivitas, tindakan, dan tugas XP yang spesifik. XP menekankan pada kolaborasi yang erat namun tidak formal secara verbal untuk mencapai komunikasi yang efektif anta...
Post a Comment
Read more

Other Agile Process Models (Model Process Agile Lainnya) Menurut Roger S. Pressman

 Sejarah pengembangan perangkat lunak telah dicatat dengan banyak deskripsi dan metodologi proses yang telah usang, alat-alat, dan teknologi, serta notasi pemodelan. Semua hal tersebut telah mencapai popularitasnya masing-masing sebelum akhirnya digantikan oleh yang baru dan lebih baik. Dalam upaya mencapai penerimaan di komunitas pengembangan perangkat lunak, berbagai agile process model telah diperkenalkan dan bersaing satu sama lain, mengikuti pola yang sama dengan gerakan sebelumnya. Sudah saya sampaikan pada bagian terakhir bahwa Extreme Programming (XP) merupakan agile process models yang paling sering digunakan. Meskipun demikian, terdapat banyak agile process models lain yang telah diusulkan dan diterapkan dalam berbagai industri. Beberapa model yang paling umum meliputi: Adaptive Software Development (ASD) Scrum Dynamic Systems Development Method (DSDM) Crystal Feature Drive Development (FDD) Lean Software Development (LSD) Agile Modeling (AM) Agile Unified Process (AUP) P...
Post a Comment
Read more