Senin, 10 September 2012

Model Proses Perangkat Lunak


Hingga kini, kita mengenal beberapa Model Proses Perangkat Lunak, sebagai berikut:
Waterfall Model (classic life cycle - old fashioned but reasonable approach when requirements are well understood)
Incremental Models (deliver software in small but usable pieces, each piece builds on pieces already delivered)
Evolutionary Models
o Prototyping Model (good first step when customer has a legitimate need, but is clueless about the details, developer needs to resist pressure to extend a rough prototype into a production product)
o Spiral Model (couples iterative nature of prototyping with the controlled and systematic aspects of the Waterfall Model)
Concurrent Development Model (concurrent engineering - allows software teams to represent the iterative and concurrent element of any process model)

Selain itu, juga terdapat beberapa Model Proses Khusus, yaitu:
Component-Based Development (spiral model variation in which applications are built from prepackaged software components called classes)
Formal Methods Model (rigorous mathematical notation used to specify, design, and verify computer-based systems)
Aspect-Oriented Software Development (aspect-oriented programming - provides a process for defining, specifying, designing, and constructing software aspects like user interfaces, security, and memory management that impact many parts of the system being developed)

Memasuki tahun 2000-an, seiring dengan makin berkembangnya paradigma pemrograman berorientasi obyek, maka berkembang juga model proses perangkat lunak yang disebut Unified Proces, dengan ciri-ciri sebagai berikut:
Use-case driven, architecture centric, iterative, and incremental software process
Attempts to draw on best features of traditional software process models and implements many features of agile software development
Phases
1) Inception phase (customer communication and planning)
2) Elaboration phase (communication and modeling)
3) Construction phase
4) Transition phase (customer delivery and feedback)
5) Production phase (software monitoring and support)


Beberapa Pemikiran dalam Rekayasa Perangkat Lunak

Rekayasa Perangkat Lunak
Apa yang dimaksud dengan Rekayasa Perangkat Lunak itu? 
Software engineering is the establishment of sound engineering principles in order to obtain reliable and efficient software in an economical manner.
Software engineering is the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software.
Software engineering encompasses a process, management techniques, technical methods, and the use of tools.

Kerangkat Kerja Umum Proses Perangkat Lunak
1. Komunikasi/Communication (customer collaboration and requirement gathering)
2. Perencanaan/Planning (establishes engineering work plan, describes technical risks, lists resources required, work products produced, and defines work schedule).
3. Pemodelan/Modeling (creation of models to help developers and customers understand the requires and software design)
4. Konstruksi atau Rancang Bangun/Construction (code generation and testing)
5. Deployment (software delivered for customer evaluation and feedback)


Software Engineering Umbrella Activities
  1. Software project tracking and control (allows team to assess progress and take corrective action to maintain schedule)
  2. Risk management (assess risks that may affect project outcomes or quality)
  3. Software quality assurance (activities required to maintain software quality)
  4. Technical reviews (assess engineering work products to uncover and remove errors before they propagate to next activity)
  5. Measurement (define and collect process, project, and product measures to assist team in delivering software meeting customer needs)
  6. Software configuration management (manage effects of change)
  7. Reusability management (defines criteria for work product reuse and establish mechanisms to achieve component reuse)
  8. Work product preparation and production (activities to create models, documents, logs, forms, lists, etc.)
Esensi Dasar dalam Praktek Pengembangan Perangkat Lunak
1. Memahami Konteks Permasalahan (dengan melakukan komunikasi dan analisis)
2. Merencanakan Solusi (perancangan perangkat lunak)
3. Mengeksekusi Rencana Solusi (kodifikasi dan debugging) 
4. Review Hasil untuk Akurasi (dengan melakukan testing dan jaminan kualitas)

Berikut adalah penjelasan masing-masing
(1) Understand the Problem
•    Who are the stakeholders?
•    What functions and features are required to solve the problem?
•    Is it possible to create smaller problems that are easier to understand?
•    Can a graphic analysis model be created?
(2) Plan the Solution
•    Have you seen similar problems before?
•    Has a similar problem been solved?
•    Can readily solvable subproblems be defined?
•    Can a design model be created?
(3) Carry Out the Plan
•    Does solution conform to the plan?
•    Is each solution component provably correct?
(4) Examine the Result
•    Is it possible to test each component part of the solution?
•    Does the solution produce results that conform to the data, functions, and features required?



Senin, 03 September 2012

Pengantar Logika Proporsional


Logika dapat dibagi dalam dua bagian perkembangan. Yang pertama adalah perkembangan logika sebelum Tahun Yesus Kristus yakni oleh sekolah filosofi Stoic (3rd cen-tury SM), dengan paling tokoh terkemuka adalah Chryssipus dan tentu saja, Aristoteles dengan konsep SILOGISME-nya.
Yang kedua adalah perkembangan modern; ddengan tokoh2 yang apling termuka adalah pada pertengahan abad ke-19, yakni G. Boole, yang kadang-kadang dianggap sebagai pendiri Logika Matematika. Juga oleh tokoh logika German G. Frege dengan konsep First Order Logic (sekitar tahun 1879).

Sebagai langkah awal untuk memahami logika informatika formal adalah ...
Kami berasumsi bahwa kalimat selalu diciptakan (dan dapat dievaluasi) sebagai benar atau salah. Kalimat seperti ini disebut kalimat logis atau proposisi. Oleh karena itulah disebut kalimat logis atau proposisi.

Lihat beberapa contoh pernyataan dibawah ini:
Sebuah pernyataan: 2 +2 = 4 adalah proposisi (dengan nilai benar).
Sebuah pernyataan: 2 + 2 = 5 juga proposisi (dengan nilai salah).

Sedangkan pernyataan-pernyataan dibawah ini ...
Sebuah pernyataan: 2 + n = 5 bukanlah proposisi; karena pernyataan matematika tersebut mungkin benar untuk beberapa n, misalnya n = 3, bernilai salah untuk n lain, misalnya n = 2, dan terlebih lagi, kita tidak tahu apakah n itu. 

Logika klasik mencerminkan hitam dan putih dari kualitas matematika. Kita berusaha untuk mendapat teorema matematika yang dapat memiliki nilai benar atau salah dengan penalaran (atau disebut juga reasoning) sehingga dapat menjamin validitas tanpa ambigu.


Logika Informatika diawalai dengan Konsep Silogisme (yang dikemukakan oleh Aristoteles). Bagi yang ingin mendalami konsep silogisme, silahkan menuju tautan dibawah ini:
http://en.wikipedia.org/wiki/Syllogism

Untuk yang ingin mendalami mengenai First Order Logic (sebagai kelanjutan dari silogisme) dapat menuju tautan dibawah ini:
http://en.wikipedia.org/wiki/First-order_logic



Prinsip Pemodelan

Rekayasa perangkat lunak merupakan salah satu keilmuan dengan perkembangan yang pesat. Menurut McConnel [McC99], software engineering body of knowledge telah menemukan “kestabilan utama” yang merepresentasikan sekitar 75% pengetahuan yang diperlukan untuk mengembangkan perangkat lunak yang kompleks. Jadi, dapat disimpulkan, bahwa hanya dalam kurun waktu 50 tahun, maka rekayasa perangkat lunak makin mapan.
Salah satu “titik puncak” dalam rekayasa perangkat lunak, adalah pemodelan perangkat lunak. Pemodelan memberikan kemampuan baru kepada pengembang perangkat lunak dengan pendekatan sistematik dan terorganisasi dalam mengembangkan perangkat lunak, berdasarkan prinsip rekayasa. Pemodelan juga menegaskan proses pengambilan-keputusan terkait segenap aspek dalam pengembangan perangkat lunak. Selain itu, pemodelan memperkuat proses komunikasi antar pihak2 yang terkait dalam pemanfaatan perangkat lunak.
Terdapat beberapa prinsip umum yang memandu aktivitas pemodelan perangkat lunak:
1) Fokus pada esensi utama – dalam pemahaman bahwa model perangkat lunak “hanyalah” mengilustrasikan bagian-bagian terpenting (dan kritis) dalam arsitektur perangkat lunak yang dikembangkan. Dalam konteks ini, prinsip “penyederhanaan” adalah isu yang terpenting dalam membuat model essentials dari perangkat lunak. Membuat model, secara kasar dapat dikatakan sebagai membuat penyederhanaan.
2) Menyediakan perspektif – Pemodelan perangkat lunak harus dapat memberikan wawasan yang menyeluruh dari segenap aspek pengembangan perangkat lunak. Wawasan atau perspektif menyeluruh ini, tentu saja, harus sesuai dengan standar aturan tertentu yang diterima komunitas pengembang dan dapat dipahami pengguna perangkat lunak. Pendekatan perspektif ini harus dapat menggambarkan dimensi perangkat lunak.
3) Memungkinkan komunikasi efektif – Model perangkat lunak berisi kosakata, bahasa dan ekspresi semantik dari perangkat lunak. Kesemuanya ini dimaksudkan untuk memperlancar proses komunikasi intern (dalam tim pengembang) dan ekstern (antar tim pengembang dan stakeholders).
Secara teknis dapat dikatakan bahwa model perangkat lunak merupakan abstraksi (atau penyederhanaan) dari setiap komponen yang membangun suatu perangkat lunak. Abstraksi yang ada bukanlah abstraksi tunggal, melainkan merupakan gabungan (atau kumpulan) beberapa abstraksi terkait komponen-komponen perangkat lunak. Sehingga, melalui kumpulan abstraksi ini, pihak-pihak yang terkait mendapatkan wawasan yang lengkap dan dapat memahami perangkat lunak yang akan dibangun. Model yang baik, tentu saja, dapat digunakan berulang-ulang dengan asumsi yang dapat divalidasi terkait hasil akhir yang dikembangkan.
Karakteristik dari model perangkat lunak:
1) Completeness – yakni terkait dengan seberapa lengkap requirements perangkat lunak yang telah digambarkan (dan diverifikasi) pada sebuah model
2) Consistency – yakni terkait dengan keselarasan antar setiap komponen perangkat lunak yang dikembangkan dengan model yang diabstraksi. Konsistensi misalnya dapat dinyatakan dengan tidak adanya konflik pada deskripsi requirements, ataupun pada deskripsi fungsi dari perangkat lunak yang dibangun.
3) Correctness – aspek ini terkait dengan keterunutan (keterlacakan) antara requirements, spesifikasi perancangan hingga pengujian yang menjamin bebas cacat. Model yang baik harus dapat mengekspresikan keterunutan setiap proses pengembangan perangkat lunak.


Biar bagaimanapun juga, sebuah model yang baik, harus dapat menggambarkan “kondisi nyata” dari karakteristik dan perilaku obyek tertentu, sehingga dapat menjelaskan bagaimana nantinya sebuah perangkat lunak itu menjalankan fungsinya. Sehingga dengan demikian, dapat dikatakan bahwa ekspresi elemen utama sebuah model itu adalah entitas. Entitas mewakili artifak yang konkret (seperti misalnya sensor atau prosesor) dan artifak yang abstrak (seperti misalnya modul perangkat lunak dan protokol komunikasi data). Tentu saja, model yang baik, juga dapat menunjukkan relasi antar entitas tersebut. Ekspresi entitas dan relasi entitas ini digambarkan dengan “bahasa” teks dan grafis.

Sintaks, Semantik dan Pragmatisme
Bagi pengembang senior, maka dia pasti sudah menemukan bahwa seringkali model perangkat lunak bisa menipu. Karena memang, model sebagai hasil abstraksi memilki kecenderungan untuk menampilkan informasi yang tidak lengkap (atau tidak utuh). Oleh karena itu, penting untuk menyadari bahwa model yang lengkap (atau utuh) itu adalah gabungan dari beberapa sub-model dan model fungsi khusus dari perangkat lunak yang akan dibangun. Pengalaman menunjukkan bahwa pemeriksaan dan pengambilan keputusan yang hanya didasarkan pada model tunggal, akan membawa masalah baru dalam proses pengembangan perangkat lunak.
Penting bagi seorang pengembang untuk memahami dengan tepat arti dari konstruksi sebuah model perangkat lunak. Usaha ini merupakan pekerjaan yang cukup berat. Bahasa pemodelan biasanya didefinisikan dengan aturan-aturan sintak dan semantik tertentu. Untuk bahasa model tekstual, digunakan konstruksi bahasa formal yang valid (misalnya BNF atau Backus-Naur Form). Untuk bahasa model grafis, sintaks didefinisikan dengan model grafik yang disebut meta-models. Semantik bahasa pemodelan menyatakan arti yang melekat pada entitas dan relasi yang diungkapkan pada gambar model perangkat lunak. Seperti misalnya sebuah diagram sederhana dari dua buah kotak yang terhubung dengan garis lurus, akan terbuka untuk berbagai interpretasi artian. Pengembang harus mengetahui konteks diagram tersebut, seperti misalnya dalam Diagram Object dan Diagram Aktivitas yang dapat membantu penafsiran arti gambar model tersebut.
Secara praktis, maka pengembang harus dapat beradaptasi dengan abstraksi model yang secara mendasar hanya menampilkan informasi yang tidak utuh. Komunikasi yang tepat pada intinya adalah pihak-pihak yang berkomunikasi dapat  menangkap makna/arti yang sama dari notasi pada gambar model yang digunakan. Pemahaman akan sintaks yang digunakan, semantik yang digambarkan dan konteks gambar model sangat penting untuk para pengembang dan stakeholders terkait pengembangan perangkat lunak.

Types of Models
Sebuah model, pada dasarnya merupakan agregasi dari beberapa sub-model. Setiap sub-model merupakan deskripsi parsial yang dikhususkan untuk tujuan khusus tertentu; dan dinyatakan oleh satu atau beberapa diagram. Kumpulan sub-model dapat terdiri dari beberapa bahasa pemodelan, atau bahasa pemodelan tunggal seperti misalnya UML.
Sekarang ini, model dibedakan menjadi model informasi, model perilaku dan model struktur.
Model informasi menyatakan data dan informasi yang ada pada perangkat lunak. Model ini merupakan representasi abstrak dari konsep, properties, relasi dan constraint dari entitas data. Model informasi sering digunakan untuk menyatakan konteks formal dari perangkat lunak yang dilihat dari sudut pandang permasalahan yang akan diselesaikan tanpa memikirkan bagaimana model ini diimplementasikan pada perangkat lunak.
Model Perilaku menyatakan fungsi dari perangkat lunak yang akan dikembangkan. Model perilaku biasanya dinyatakan dalam bentuk: state machines, model aliran-kontrol dan model aliran data. State Machines menyatakan perangkat lunak yang terdiri dari kumpulan states (keadaan yang terdefinisi), events dan transisi. Model aliran kontrol menyatakan sebuah sequence of events yang menyebabkan proses dieksekusi atau dihentikan. Model aliran data biasanya menggambarkan perilaku data yang bergerak melalui masuk atau keluar proses penyimpanan data.
Model Struktur mengilustrasikan komposisi logis (atau fisik) dari berbagai komponen dari perangkat lunak. Pemodelan struktural menjelaskan batasan dari perangkat lunak yang diimplementasikan dan lingkungan tempat dimana perangkat lunak akan difungsikan/dijalankan.


Jumat, 31 Agustus 2012

The Value of Modeling

Pemodelan software merupakan salah satu perkembangan terkini dalam pengembangan perangkat lunak. Terlepas dari banyaknya kesalahpahaman mengenai apa yang dimaksud dengan "pemodelan" perangkat lunak tersebut, teknik-teknik dalam melakukan pemodelan perangkat lunak, makin berkembang luas.


Salah satu "kebiasaan" para programmer pemula adalah seperti yang disebutkan pada kalimat ini: "rush to code syndrome" atau sindrom yang (selalu) ingin cepat menulis kode program. Kebiasaan ini, terlihat pada hampir semua programmer entry-level (maupun programmer template). Biasanya mereka, tanpa pikir panjang, langsung menulis kode (ataupun menggunakan template) dengan alasan ingin cepat2 mendelivered sebuah aplikasi bagi user.

Dalam software engineering, pendekatan "rush to code syndrome" menyebabkan Software Crisis 1.0 di Era 1960-an s/d 1970-an. Era Software Crisis tersebut, menghasilkan aplikasi perangkat lunak yang amburadul dari sisi biaya pengembangan yang membengkak, terlambat mendelivered perangkat lunak karena tidak adanya kontrol fitur-fitur yang dikembangkan dan buruknya manajemen pengelolaan proses perangkat lunak. Akibat yang paling nyata adalah dihasilkannya "sampah software" yang sungguh tak terhitung jumlahnya. (Sampah software adalah software yang ditinggalkan, karena tidak bermanfaat).

Pemodelan perangkat lunak relatif menghindarkan organisasi untuk mengalami kondisi "software crisis". Secara kasar, dapat dikatakan, proses pemodelan perangkat lunak, merupakan bagian dari pendekatan membuat perangkat lunak dengan berprinsip pada software system engineering, atau berpedoman pada prinsip rekayasa teknik yang reliable dan precise.

Disamping makin kompleksnya dunia pengembangan perangkat lunak, dewasa ini, maka langkah pemodelan software menjadi makin penting. Sedikitnya IBM Rational SOftware Team mengusulkan beberapa Tren terkait Pemodelan Perangkat Lunak. Tren tersebut adalah:
1) Beyond visual modeling; yakni pemodelan model, atau pemodelan dari model visual.
2) Unifying software, data and business modeling atau pemodelan yang menyeluruh, dalam artian model interasi dari aliran data, informasi, logic business dan aplikasi itu sendiri.
3) Modeling across lifecycle; atau pemodelan yang berkesinambungan mencakup seluruh langkah-proses daur hidup pengembangan perangkat lunak.
4) Domain-specific modeling language, atau bahasa pemodelan dengan sintaks dan semantics yang dapat diterima secara internasional
5) Model-driven architecture; atau suatu "next-step" mengenai pemodelan tingkat lanjut.

Selengkapnya dari tulisan tersebut diatas, dapat diunduh pada tautan dibawah ini: