Kalo kita perhatikan perkembangan Business Process Modeling terakhir, maka walaupun belum 100% sempurna. Kita akan melihat pendekatan yang sama dengan Model Driven Engineering. Pendekatan yang sama ini kurang lebih adalah kemampuan untuk melakukan code generator.
Model Driven engineering memungkinkan kode dihasilkan hanya dengan menggambar suatu model. Dengan pendekatan ini kemudian akan di-generate kode. Artinya, untuk menghasilkan kode tidak perlu menulis baris kode tapi cukup menggambar model.
Dengan perkembangan Business Process Modeling terakhir ada suatu peranan yang diambil alih, yakni peranan orang software. Karena untuk menghasilkan kode, cukuplah dilakukan oleh business analis alias orang yang mengerti domain masalah dalam hal ini adalah proses bisnis. And then, 'sim sa labim' ...... dihasilkan kode.
end of this introduction
Tuesday, July 22, 2008
Tuesday, June 10, 2008
Integrasi Aspek Keamanan dalam RPL
Berikut adalah beberapa usulan untuk mengintegrasikan kebutuhan keamanan dengan proses pengembangan perangkat lunak.
1. Menyatukan aspek keamanan dengan rekayasa sistem
Pada saat sistem analis menganalisis dan mendesain sistem, analis keamanan harus mengembangkan desain keamanan. Untuk selanjutnya sumber daya yang ada dibangun dengan kombinasi desain sistem dengan desain keamanan.
2. Menyatukan aspek keamanan dengan system requirement
Ketika kebutuhan keamanan dipertimbangkan selama daur hidup pengembangan sistem, maka hal menjadi cenderung pada penentuan daftar keamanan sistem seperti manajemen password, firewall, pendeteksian virus dsb. Padahal hal ini bukan merupakan kebutuhan keamanan tapi merupakan mekanisme implementasi yang digunakan untuk memenuhi kebutuhan keamanan secara implisit, misalnya untuk pembatasan akses. Hasilnya adalah, kebutuhan keamanan yang khusus untuk sistem dan perlindungan terhadap suatu layanan dan sumber daya seringkali dilupakan. Sebagai tambahan, perspektif penyerang tidak dipertimbangkan. Untuk itu diperlukan pendekatan sistematik dalam manajemen kebutuhan keamanan akan mencegah permasalahan daftar keamanan sistem dan mengubahnya pada perspektif penyerang.
Program CERT pada Software Engineering Institute's telah mengembangkan sebuah metodologi untuk membangun keamanan sejak awal pada daur hidup pengembangan sistem yang disebut Security Quality Requirements Engineering (SQUARE).
Hasil analisis kebutuhan melalui metodologi SQUARE dengan menganalisis komponen fungsionalitas keamanan yang dideskripsikan pada CC part 2 digunakan sebagai dasar untuk membuat SFR ( Security Functional Requirement ) sebagai pelengkap SRS( Software Requirement Specification ). SFR yang merupakan bagian dari Protection Profile merupakan Security target yang menggambarkan kebutuhan pengguna dalam aspek keamanan.
3. Menyatukan aspek keamanan dengan model sistem
Pengembang perangkat lunak menggunakan model sejak proses awal siklus pengembangan software untuk meningkatkan kualitas artifact dokumen requirement. Kecenderungan yang ada adalah menggunakan model berorientasi obyek ( UML ). Salah satu riset yang dilakukan oleh komunitas software dan keamanan adalah mengadopsi dan mengembangkan standar, misalnya : UML untuk memodelkan fitur keamanan seperti privacy, integrity, access control dsb. Keuntungan yang bisa didapatkan adalah : 1 ) Menyatukan desain sistem dan kebijakan keamanan, 2) Modularitas ( melalui encapsulation) dan reuse ( melalui pewarisan ) dalam representasi kebijakan, 3) Mengembangkan tool standar saat ini untuk aktivits analisis dan desain( forward engineering ) sebagaimana analisis legacy systems( reverse engineering ).
Tantangan utama adalah mengembangkan sintaks dan semantik standar seperti UML untuk menangani permasalah keamanan. Riset untuk mengembangkan tools dan proses untuk menyatukan desain sistem dan kebijakan keamanan dipercayai mampu menghasilkan sistem yang lebih efektif memenuhi kebutuhan pengguna dan aman.
4. Menyatukan aspek keamanan dengan desain sistem
Desain system dilakukan dengan dua pendekatan, yakni : 1) Penggunaan Security Design Pattern, 2) Penggunaan Aspect Oriented Programming( AOP ).
• Penggunaan Security Design Pattern
Design pattern merupakan suatu cara untuk mengidentifikasi dan memberikan solusi terhadap permasalahan desain yang berulang-ulang terjadi pada pemrograman berorientasi obyek. Joseph Yoder and Jeffrey Barcalow adalah yang pertama kali mengadaptasi pendekatan design pattern pada pemgembangan perangkat lunak. Format yang digunakan adalah template design pattern yang dibuat oleh Gang of Four. Berikut adalah security design pattern : 1) Single Access Point : menyediakan sebuah modul keamanan dan satu cara untuk log in ke dalam sistem, 2) Check Point : manajemen pemeriksaan keamanan, 3) Roles : manajemen penggunan dengan security privileges, 4) Session : lokalisasi informasi global pada lingkungan banyak pengguna, 5) Full View with Errors: penyediaan sebuah view penuh kepada pengguna dan menampilkan exceptions ketika diperlukan, 6) Limited View : hanya memperbolehkan pengguna untuk melihat apa yang diperbolehkan untuk mereka, 7) Secure Access Layer: mengintegrasikan keamanan aplikasi dengan keamanan level yang lebih rendah( missal : jaringan ).
Sangat dimungkinkan di kemudian hari untuk menambah katalog security design pattern seiring dengan berkembangnya kesadaran akan integrasi aspek keamanan pada desain perangkat lunak.
• Penggunaan Aspect Oriented Programming( AOP )
Penggunaan aspect-oriented programming dapat digunakan untuk memisahkan permasalahan keamanan dalam sistem yang kompleks. Ide aspect-oriented programming adalah beberapa aspek dari kode secara alami adalah modular, seperti penyimpanan data yang dapat ditempatkan dalam basis data.
Sementara yang lain( biasanya non fungsionalitas ) seperti performansi tersebar( scattered ) pada kode. Dengan memisahkan kode yang tersebar dengan cara mengkodingkan dan mengisolasi terpusat dalam aspect-aspect maka memudahkan dalam manajemen kode ( aspect ) dan pengembangan sistem.
5. Menyatukan aspek keamanan dengan pengujian sistem
Pengujian aspek keamanan menggunakan EAL sesuai dengan tingkat EAL yang diterapkan dalam pembangunan perangkat lunak. Secara teknis, dapat digunakan pendekatan pengujian unit secara otomatis dengan menggunakan framework N-unit testing.
Catatan :
CC : Common Criteria, merupakan salah satu standar aspek keamanan dalam produk TI
1. Menyatukan aspek keamanan dengan rekayasa sistem
Pada saat sistem analis menganalisis dan mendesain sistem, analis keamanan harus mengembangkan desain keamanan. Untuk selanjutnya sumber daya yang ada dibangun dengan kombinasi desain sistem dengan desain keamanan.
2. Menyatukan aspek keamanan dengan system requirement
Ketika kebutuhan keamanan dipertimbangkan selama daur hidup pengembangan sistem, maka hal menjadi cenderung pada penentuan daftar keamanan sistem seperti manajemen password, firewall, pendeteksian virus dsb. Padahal hal ini bukan merupakan kebutuhan keamanan tapi merupakan mekanisme implementasi yang digunakan untuk memenuhi kebutuhan keamanan secara implisit, misalnya untuk pembatasan akses. Hasilnya adalah, kebutuhan keamanan yang khusus untuk sistem dan perlindungan terhadap suatu layanan dan sumber daya seringkali dilupakan. Sebagai tambahan, perspektif penyerang tidak dipertimbangkan. Untuk itu diperlukan pendekatan sistematik dalam manajemen kebutuhan keamanan akan mencegah permasalahan daftar keamanan sistem dan mengubahnya pada perspektif penyerang.
Program CERT pada Software Engineering Institute's telah mengembangkan sebuah metodologi untuk membangun keamanan sejak awal pada daur hidup pengembangan sistem yang disebut Security Quality Requirements Engineering (SQUARE).
Hasil analisis kebutuhan melalui metodologi SQUARE dengan menganalisis komponen fungsionalitas keamanan yang dideskripsikan pada CC part 2 digunakan sebagai dasar untuk membuat SFR ( Security Functional Requirement ) sebagai pelengkap SRS( Software Requirement Specification ). SFR yang merupakan bagian dari Protection Profile merupakan Security target yang menggambarkan kebutuhan pengguna dalam aspek keamanan.
3. Menyatukan aspek keamanan dengan model sistem
Pengembang perangkat lunak menggunakan model sejak proses awal siklus pengembangan software untuk meningkatkan kualitas artifact dokumen requirement. Kecenderungan yang ada adalah menggunakan model berorientasi obyek ( UML ). Salah satu riset yang dilakukan oleh komunitas software dan keamanan adalah mengadopsi dan mengembangkan standar, misalnya : UML untuk memodelkan fitur keamanan seperti privacy, integrity, access control dsb. Keuntungan yang bisa didapatkan adalah : 1 ) Menyatukan desain sistem dan kebijakan keamanan, 2) Modularitas ( melalui encapsulation) dan reuse ( melalui pewarisan ) dalam representasi kebijakan, 3) Mengembangkan tool standar saat ini untuk aktivits analisis dan desain( forward engineering ) sebagaimana analisis legacy systems( reverse engineering ).
Tantangan utama adalah mengembangkan sintaks dan semantik standar seperti UML untuk menangani permasalah keamanan. Riset untuk mengembangkan tools dan proses untuk menyatukan desain sistem dan kebijakan keamanan dipercayai mampu menghasilkan sistem yang lebih efektif memenuhi kebutuhan pengguna dan aman.
4. Menyatukan aspek keamanan dengan desain sistem
Desain system dilakukan dengan dua pendekatan, yakni : 1) Penggunaan Security Design Pattern, 2) Penggunaan Aspect Oriented Programming( AOP ).
• Penggunaan Security Design Pattern
Design pattern merupakan suatu cara untuk mengidentifikasi dan memberikan solusi terhadap permasalahan desain yang berulang-ulang terjadi pada pemrograman berorientasi obyek. Joseph Yoder and Jeffrey Barcalow adalah yang pertama kali mengadaptasi pendekatan design pattern pada pemgembangan perangkat lunak. Format yang digunakan adalah template design pattern yang dibuat oleh Gang of Four. Berikut adalah security design pattern : 1) Single Access Point : menyediakan sebuah modul keamanan dan satu cara untuk log in ke dalam sistem, 2) Check Point : manajemen pemeriksaan keamanan, 3) Roles : manajemen penggunan dengan security privileges, 4) Session : lokalisasi informasi global pada lingkungan banyak pengguna, 5) Full View with Errors: penyediaan sebuah view penuh kepada pengguna dan menampilkan exceptions ketika diperlukan, 6) Limited View : hanya memperbolehkan pengguna untuk melihat apa yang diperbolehkan untuk mereka, 7) Secure Access Layer: mengintegrasikan keamanan aplikasi dengan keamanan level yang lebih rendah( missal : jaringan ).
Sangat dimungkinkan di kemudian hari untuk menambah katalog security design pattern seiring dengan berkembangnya kesadaran akan integrasi aspek keamanan pada desain perangkat lunak.
• Penggunaan Aspect Oriented Programming( AOP )
Penggunaan aspect-oriented programming dapat digunakan untuk memisahkan permasalahan keamanan dalam sistem yang kompleks. Ide aspect-oriented programming adalah beberapa aspek dari kode secara alami adalah modular, seperti penyimpanan data yang dapat ditempatkan dalam basis data.
Sementara yang lain( biasanya non fungsionalitas ) seperti performansi tersebar( scattered ) pada kode. Dengan memisahkan kode yang tersebar dengan cara mengkodingkan dan mengisolasi terpusat dalam aspect-aspect maka memudahkan dalam manajemen kode ( aspect ) dan pengembangan sistem.
5. Menyatukan aspek keamanan dengan pengujian sistem
Pengujian aspek keamanan menggunakan EAL sesuai dengan tingkat EAL yang diterapkan dalam pembangunan perangkat lunak. Secara teknis, dapat digunakan pendekatan pengujian unit secara otomatis dengan menggunakan framework N-unit testing.
Catatan :
CC : Common Criteria, merupakan salah satu standar aspek keamanan dalam produk TI
Sunday, May 04, 2008
Framework Design Guidelines
Sumber : diskusi milist RPL-IF IT Telkom oleh Yudi Maryanto :
Ada beberapa panduan bagus dalam medesain framework di buku Framework Design Guidelines:
1.Gunakan Aggregate Component untuk menyederhanakan public interface pada skenario yang paling sering digunakan.
2. Pegang teguh prinsip "Make the top scenarios easy and the rest is possible". Jadi meskipun public interface kita sederhana untuk skenario yang paling umum, developer yang butuh skenario yang lebih rumit bisa mengeksplore lebih jauh framework kita.
3. Usahakan framework yang kita buat bersifat "Self Documenting". Pada skenario yang paling umum, usahakan developer tidak perlu melihat dokumentasi untuk melakukannya. Hal ini bisa dicapai dengan penamaan kelas dan method yang intuitif.
4. Buat framework kita konsisten sehingga jika developer telah menguasai sebagian framework kita, pengetahuan tersebut tetap bisa dipakai dalam mempelajari bagian lain dari framework kita.
5. Usahakan jangan mengekspose design pattern untuk public interface pada skenario yang paling umum. Konsep-konsep OOAD, design pattern, dll cocok diterapkan untuk detail implementasi framework kita tapi kurang cocok untuk public interface karena cenderun akan memperumit interface yang pada akhirnya akan membuat frustasi developer.
Ada beberapa panduan bagus dalam medesain framework di buku Framework Design Guidelines:
1.Gunakan Aggregate Component untuk menyederhanakan public interface pada skenario yang paling sering digunakan.
2. Pegang teguh prinsip "Make the top scenarios easy and the rest is possible". Jadi meskipun public interface kita sederhana untuk skenario yang paling umum, developer yang butuh skenario yang lebih rumit bisa mengeksplore lebih jauh framework kita.
3. Usahakan framework yang kita buat bersifat "Self Documenting". Pada skenario yang paling umum, usahakan developer tidak perlu melihat dokumentasi untuk melakukannya. Hal ini bisa dicapai dengan penamaan kelas dan method yang intuitif.
4. Buat framework kita konsisten sehingga jika developer telah menguasai sebagian framework kita, pengetahuan tersebut tetap bisa dipakai dalam mempelajari bagian lain dari framework kita.
5. Usahakan jangan mengekspose design pattern untuk public interface pada skenario yang paling umum. Konsep-konsep OOAD, design pattern, dll cocok diterapkan untuk detail implementasi framework kita tapi kurang cocok untuk public interface karena cenderun akan memperumit interface yang pada akhirnya akan membuat frustasi developer.
Saturday, May 03, 2008
UML : state of the art
Dalam pengembangan perangkat lunak digunakan pemodelan perangkat lunak sejak requirement sampai testing. Saat ini standar pemodelan yang banyak digunakan adalah UML seiring dengan banyak digunakan pendekatan berorientasi obyek dalam pambuatan perangkat lunak.
Namun UML dipandang masih mempunyai kekurangan karena masih terdapatnya kekurangan dalam meng-generate kode program secara komplit. Kenapa hal ini terjadi? Dalam analisis yang saya coba lakukan, hal ini karena kurangnya cara memodelkan aspek kelakuan internal perangkat lunak untuk dipetakan ke dalam kode program. Seperti yang kita ketahui, diagram UML yang dapat menghasilkan kode hanyalah diagram class, namun itupun hanya baru sebatas kerangka kodennya saja dan tidak bisa meng-generate badan program-nya.
Untuk itu diperlukan cara dalam memodelkan pengembangan perangkat lunak yang memungkinkan dihasilkannya kode program secara komplit.
Bersambung......
Namun UML dipandang masih mempunyai kekurangan karena masih terdapatnya kekurangan dalam meng-generate kode program secara komplit. Kenapa hal ini terjadi? Dalam analisis yang saya coba lakukan, hal ini karena kurangnya cara memodelkan aspek kelakuan internal perangkat lunak untuk dipetakan ke dalam kode program. Seperti yang kita ketahui, diagram UML yang dapat menghasilkan kode hanyalah diagram class, namun itupun hanya baru sebatas kerangka kodennya saja dan tidak bisa meng-generate badan program-nya.
Untuk itu diperlukan cara dalam memodelkan pengembangan perangkat lunak yang memungkinkan dihasilkannya kode program secara komplit.
Bersambung......
UML : state of the art
Dalam pengembangan perangkat lunak digunakan pemodelan perangkat lunak sejak requirement sampai testing. Saat ini standar pemodelan yang banyak digunakan adalah UML seiring dengan banyak digunakan pendekatan berorientasi obyek dalam pambuatan perangkat lunak.
Namun UML dipandang masih mempunyai kekurangan karena masih terdapatnya kekurangan dalam meng-generate kode program secara komplit. Kenapa hal ini terjadi? Dalam analisis yang saya coba lakukan, hal ini karena kurangnya cara memodelkan aspek kelakuan internal perangkat lunak untuk dipetakan ke dalam kode program. Seperti yang kita ketahui, diagram UML yang dapat menghasilkan kode hanyalah diagram class, namun itupun hanya baru sebatas kerangka kodennya saja dan tidak bisa meng-generate badan program-nya.
Untuk itu diperlukan cara dalam memodelkan pengembangan perangkat lunak yang memungkinkan dihasilkannya kode program secara komplit.
Bersambung......
Namun UML dipandang masih mempunyai kekurangan karena masih terdapatnya kekurangan dalam meng-generate kode program secara komplit. Kenapa hal ini terjadi? Dalam analisis yang saya coba lakukan, hal ini karena kurangnya cara memodelkan aspek kelakuan internal perangkat lunak untuk dipetakan ke dalam kode program. Seperti yang kita ketahui, diagram UML yang dapat menghasilkan kode hanyalah diagram class, namun itupun hanya baru sebatas kerangka kodennya saja dan tidak bisa meng-generate badan program-nya.
Untuk itu diperlukan cara dalam memodelkan pengembangan perangkat lunak yang memungkinkan dihasilkannya kode program secara komplit.
Bersambung......
Tuesday, March 11, 2008
Pabrik Software
Istilah ini tidak lazim. Namun bukan berarti tidak ada. Istilah di dunia software-nya adalah : Software Product Line atau Software Factory.
Kenapa istilah ini tidak lazim? Karena sampai saat ini pembuatan software secara luas bukanlah suatu hasil proses pabrikasi. Apa maksudnya? Bagaimana dgn 'product' suatu software house, misalnya?
Satu jawaban singkat, karakteristik dan prosesnyalah yg mrpkan pembedanya.
More, but to be continued
Kenapa istilah ini tidak lazim? Karena sampai saat ini pembuatan software secara luas bukanlah suatu hasil proses pabrikasi. Apa maksudnya? Bagaimana dgn 'product' suatu software house, misalnya?
Satu jawaban singkat, karakteristik dan prosesnyalah yg mrpkan pembedanya.
More, but to be continued
Berbedalah
Bismillah,
Aktivitas dlm kehidupan yg lalu, sekarang dan yang datang.
Dari yg gitu-gitu, selalu saja. Sampai dengan luar biasa dan sepanjang masa.
Terus apa bedanya? Padahal khan, ama Allah sudah dikasih kesempatan yang sama. Mesti ada sesuatu yang membikin beda. Apa ya?
Mimpi = visi & misi
Strategi & Taktik
Kebiasaan
Yuk, mulailah dengan membedakan!
Jangan sampai merugi.
Aktivitas dlm kehidupan yg lalu, sekarang dan yang datang.
Dari yg gitu-gitu, selalu saja. Sampai dengan luar biasa dan sepanjang masa.
Terus apa bedanya? Padahal khan, ama Allah sudah dikasih kesempatan yang sama. Mesti ada sesuatu yang membikin beda. Apa ya?
Mimpi = visi & misi
Strategi & Taktik
Kebiasaan
Yuk, mulailah dengan membedakan!
Jangan sampai merugi.
Thursday, March 06, 2008
Always blogging?
Sangat sulit utk menulis blog scr kontinyu. Jika tidak karena kesibukan, maka komitmen adalah yg mjd ganjalan.
Sebetulnya menulis blog adl mudah, jadikan ia sebagaimana kebutuhan berkomunikasi spt halnya : email dan sms. Dan sbtulnya emang mudah karena ada PDA. Intinya adl : stay connected!
Sebetulnya menulis blog adl mudah, jadikan ia sebagaimana kebutuhan berkomunikasi spt halnya : email dan sms. Dan sbtulnya emang mudah karena ada PDA. Intinya adl : stay connected!
Wednesday, January 16, 2008
Code generator
Ide untuk menghasilkan code tanpa harus menulis code sudah banyak dan beberapa sudah terwujud. Untuk ini kita bisa melihat pencapaian Model Driven Architecture dan juga pendekatan Generative Programming.
Namun permasalah dalam dua pendekatan diatas adalah masih adanya kendala kompleksitas sistem yang akan diubah menjadi kode dan kemudahan dalam pemakaian tools.
Hal ini sudah sering kita jumpai dan tergambar dalam penggunaan tools yang menawarkan konsep wizards dibandingkan dengan menulis kode dari awal. Keduanya mempunyai kelebihan dan kekurangannya.
Terakhir, masih terdapat beberapa tema yang terbuka dalam Code Generator yang masih dapat dikembangkan dan ditemukan.
Namun permasalah dalam dua pendekatan diatas adalah masih adanya kendala kompleksitas sistem yang akan diubah menjadi kode dan kemudahan dalam pemakaian tools.
Hal ini sudah sering kita jumpai dan tergambar dalam penggunaan tools yang menawarkan konsep wizards dibandingkan dengan menulis kode dari awal. Keduanya mempunyai kelebihan dan kekurangannya.
Terakhir, masih terdapat beberapa tema yang terbuka dalam Code Generator yang masih dapat dikembangkan dan ditemukan.
Subscribe to:
Posts (Atom)