Skip to main content

Specialized Process Models Menurut Roger S. Pressman

Proses model khusus menggunakan banyak fitur yang diperoleh dari satu atau beberapa model tradisional yang telah dijelaskan sebelumnya. Namun, model tersebut umumnya dipilih ketika pendekatan rekayasa perangkat lunak yang sangat spesifik atau terbatas telah dipilih. Dengan demikian, model proses khusus dirancang untuk memenuhi kebutuhan khusus yang tidak dapat dipenuhi oleh model tradisional.


1.1 Component-Based Development

Commercial off-the-shelf (COTS) software components dibangun oleh vendor sebagai produk yang dapat menghadirkan fungsionalitas tertentu, dan dilengkapi dengan antarmuka yang terdefinisi dengan baik sehingga komponen tersebut dapat diintegrasikan ke dalam perangkat lunak yang akan dibuat. Model pengembangan berbasis komponen menggabungkan beberapa fitur dari model spiral. Model tersebut merupakan pendekatan evolusioner yang membutuhkan proses pengulangan dalam pembuatan perangkat lunak. Namun, model pengembangan berbasis komponen memanfaatkan aplikasi dari komponen perangkat lunak yang sudah dikemas sebelumnya.

Proses pemodelan dan konstruksi dimulai dengan mengidentifikasi calon komponen. Komponen-komponen tersebut dapat dirancang sebagai modul perangkat lunak konvensional, kelas berorientasi objek, atau paket kelas. Meskipun teknologi pembuatan komponennya berbeda-beda, model pengembangan berbasis komponen memiliki tahapan yang sama (diterapkan dengan menggunakan pendekatan evolusi), yaitu:

  1. Produk berbasis komponen yang tersedia diteliti dan dievaluasi untuk domain aplikasi yang dimaksud.
  2. Pertimbangan dilakukan terhadap masalah integrasi komponen.
  3. Arsitektur perangkat lunak direncanakan agar dapat menampung komponen-komponen tersebut.
  4. Komponen-komponen tersebut diintegrasikan ke dalam arsitektur.
  5. Dilakukan pengujian menyeluruh untuk memastikan bahwa fungsionalitas yang tepat dapat tercapai.

Penerapan model pengembangan berbasis komponen akan memungkinkan penggunaan kembali perangkat lunak dan memberikan manfaat yang dapat diukur bagi insinyur perangkat lunak. Dalam hal ini, tim rekayasa perangkat lunak dapat memperoleh pengurangan waktu siklus pengembangan dan biaya proyek dengan mengadopsi budaya penggunaan kembali komponen.


1.2 The Formal Methods Model

Model metode formal terdiri dari serangkaian aktivitas yang bertujuan untuk membuat spesifikasi matematis formal perangkat lunak komputer. Dengan menggunakan notasi matematis yang ketat, metode formal memungkinkan pengguna untuk menentukan, mengembangkan, dan memverifikasi sistem berbasis komputer. Beberapa organisasi pengembangan perangkat lunak saat ini menerapkan variasi dari pendekatan ini yang dikenal sebagai rekayasa perangkat lunak ruang bersih.

Ketika digunakan dalam pengembangan perangkat lunak, metode formal dapat membantu mengatasi banyak masalah yang sulit diatasi oleh paradigma rekayasa perangkat lunak lainnya. Dalam hal ini, ambiguitas, ketidaklengkapan, dan ketidakkonsistenan dapat diidentifikasi dan diperbaiki lebih mudah melalui analisis matematis yang sistematis, daripada hanya dengan tinjauan ad hoc. Selain itu, ketika metode formal digunakan dalam desain, mereka dapat digunakan untuk memverifikasi program dan menemukan kesalahan yang mungkin tidak terdeteksi.

Walaupun tidak banyak digunakan, model metode formal memiliki potensi untuk menghasilkan perangkat lunak yang bebas dari kesalahan. Meski begitu, beberapa orang mengkhawatirkan penerapannya di lingkungan bisnis:

  • Saat ini, pengembangan model formal membutuhkan waktu dan biaya yang cukup besar.
  • Diperlukan pelatihan yang komprehensif karena tidak semua pengembang perangkat lunak memiliki latar belakang yang dibutuhkan untuk menerapkan metode formal.
  • Mengkomunikasikan model kepada pelanggan yang tidak memiliki latar belakang teknis yang memadai bisa menjadi suatu tantangan.

Meskipun ada kekhawatiran, metode formal telah dianut oleh sebagian pengembang perangkat lunak yang membangun aplikasi yang kritis terhadap keselamatan.


1.3 Aspect-Oriented Software Development

Kompleksitas pembuatan perangkat lunak selalu melibatkan fitur, fungsi, dan konten informasi yang di-localize. Fitur-fitur ini dimodelkan sebagai komponen seperti kelas-kelas berbasis objek dan kemudian dikembangkan dalam kerangka sistem. Dalam sistem komputer modern yang semakin kompleks, perhatian khusus diberikan pada properti tertentu seperti keamanan atau toleransi kesalahan yang mempengaruhi keseluruhan arsitektur. Kekhawatiran lain dapat mempengaruhi fungsi, seperti penerapan aturan bisnis, atau bersifat sistemik seperti sinkronisasi tugas atau manajemen memori.

Jika beberapa kekhawatiran melibatkan beberapa fitur, fungsi, dan informasi dari sebuah sistem, maka masalah tersebut disebut sebagai masalah lintas sektoral. Karakteristik aspek menentukan masalah lintas sektoral yang mempengaruhi arsitektur perangkat lunak. Pendekatan Aspect-oriented software development (AOSD) atau aspect-oriented programming (AOP), merupakan suatu paradigma rekayasa perangkat lunak baru yang memberikan proses dan pendekatan metodologis untuk mendefinisikan, menentukan, merancang, dan membangun aspek, yaitu "mekanisme di luar subrutin dan pewarisan untuk melokalkan ekspresi keprihatinan lintas sektoral".

Grundy membahas secara lebih lanjut tentang aspek dalam konteks aspect-oriented component engineering (AOCE):

Dalam rekayasa komponen berorientasi aspek (AOCE), konsep irisan horizontal digunakan untuk karakterisasi sifat lintas sektoral dari komponen perangkat lunak yang didekomposisi secara vertikal, disebut "aspek". Aspek sistemik meliputi antarmuka pengguna, kerja kolaboratif, distribusi, persistensi, manajemen memori, pemrosesan transaksi, keamanan, integritas, dan lain-lain. Komponen dapat memiliki satu atau lebih "detail aspek" yang berkaitan dengan aspek tertentu, seperti mekanisme tampilan dan keterjangkauan yang dapat diperluas untuk aspek antarmuka pengguna, atau pembangkitan peristiwa, pengangkutan, dan penerimaan untuk aspek distribusi. Detail aspek memiliki sejumlah properti yang berkaitan dengan karakteristik fungsional dan/atau non-fungsional dari detail tersebut.

Proses pengembangan perangkat lunak berorientasi aspek masih belum matang. Namun, kemungkinan besar proses tersebut akan mengadopsi karakteristik model evolusioner dan konkuren. Model evolusi cocok karena aspek diidentifikasi dan dibangun secara independen. Sifat paralel dari pengembangan bersamaan juga sangat penting karena aspek memengaruhi komponen perangkat lunak secara langsung, meskipun dibangun secara terpisah. Oleh karena itu, penting untuk memastikan komunikasi yang efektif antara aktivitas rekayasa dan konstruksi aspek dan komponen melalui komunikasi asinkron.

Untuk membahas pengembangan perangkat lunak berorientasi aspek secara terperinci, sebaiknya merujuk pada buku yang secara khusus mengulas topik tersebut.



Source: Pressman, Roger S. 2010. Software engineering : A Practitioner’s Approach (7th. Edition). New York: McGraw-Hill Higher Education. 

Comments

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...

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...

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...