QFD dan Elisitasi Software Requirements

Terdapat beberapa teknik untuk mendefinisikan persyaratan perangkat lunak. Salah satunya adalah yang disebut Quality function deployment (QFD). Pressman menjelaskan bahwa QFD merupakan salah satu teknik manajemen kualitas yang dapat "menterjemahkan" kebutuhan pelanggan ke dalam bentuk persyaratan software yang teknis; dengan berpedoman pada kebutuhan pelanggan. Teknik QFD dimulai dengan mengklasifikasikan requirements ke dalam tiga tipe yakni normal, expected dan exciting. Kebutuhan "normal" adalah persyaratan yang mandatory dikembangkan oleh tim pengembang. Sementara untuk kategori expected dan exciting adalah persyaratan yang dapat "ditunda". Klasifikasi pesyaratan kebutuhan ini didasarkan atas value (atau manfaat) yang bisa diperoleh dari implementasi fitur tersebut pada sistem aplikasi perangkat lunak yang akan dikembangkan. Tentu saja dibutuhkan sebuah proses yang disebut "value analysis" untuk mengidentifikasi secara lengkap setiap persyaratan perangkat lunak tersebut.

Melakukan elisitasi persyaratan perangkat lunak, bukanlah pekerjaan yang mudah, meski demikian dengan sering melakukan latihan, maka tim pengembang akan makin baik. Penyebabnya adalah user yang sering tidak memahami perangkat lunak yang akan dibangun dan komunikasi tim pengembang yang tidak efektif. Kedua faktor ini sering menyebabkan "gagalnya" proses elisitasi mendapatkan persyaratan perangkat lunak dengan lengkap.

Menurut Pressman, terdapat beberapa produk yang dapat dihasilkan dari proses elisitasi persyaratan perangkat lunak ini, diantaranya adalah:

1) Statement of need and feasibility

2) Bounded statement of scope for system or product

3) List of stakeholders involved in requirements elicitation

4) Description of system’s technical environment

5) List of requirements organized by function and applicable domain constraints

6) Set of usage scenarios (use-cases) that provide use insight into operation of deployed system

7) Prototypes developed to better understand requirements 

Setelah melakukan proses elisitasi persyaratan perangkat lunak, maka tim pengembang akan membuat dokumen vision. Sebuah contoh dari dokumen vision tersebut dapat dilihat disini:

https://docs.google.com/file/d/0BxSxy7HfW5oJc0xhQVlqdUN0bTA/edit

Untuk penjelasan lebih mendalam mengenai teknik QFD dapat mengacu pada URL dibawah ini:

1. http://en.wikipedia.org/wiki/Quality_function_deployment

2. http://www.qfdi.org/

3. http://www.qfdi.org/what_is_qfd/what_is_qfd.htm

4. http://www.qfdonline.com/

dan

5. http://www.ciri.org.nz/downloads/Quality%20Function%20Deployment.pdf

Memahami Requirements Perangkat Lunak

Memahami requirements perangkat lunak, merupakan langkah awal dalam pengembangan perangkat lunak. Apa sebenarnya yang dimaksud dengan requirements tersebut? Ada yang mengartikan requirements sebagai pendefinisian perangkat lunak. Beberapa pakar software engineering, mengartikan requirements perangkat lunak sebagai kebutuhan atau persyaratan perangkat lunak; yakni setiap fungsi yang dapat dilakukan perangkat lunak.

Menurut hemat saya, proses pendefinisian perangkat lunak, haruslah merupakan proses penyelesaian masalah. Jika kita berparadigma bahwa perangkat lunak dibangun dengan tujuan khusus tertentu, untuk melaksanakan fungsi khusus tertentu, maka sebagai sebuah produk, tentu saja, perangkat lunak ditujukan untuk menyelesaikan masalah tertentu. Pendekatan problem-solving ini, merupakan pendekatan rekayasa.

Lihat sebuah Gambar dibawah ini:

Gambar diatas merupakan langkah-langkah untuk menyelesaikan masalah tertentu. Proses requirements software pun mengikuti pola yang demikian. Pressman menyebutkan bahwa requirements engineering helps software engineers better understand the problems they are trying to solve. Ini berarti Pressman mengikuti paradigma software for solving problems. Jadi, proses pendefisian kebutuhan perangkat lunak adalah sebuah proses dimana pengembang dan stakeholders berusaha memahami permasalahan dan mencarikan solusi permasalahan tersebut, dengan mengembangkan perangkat lunak. Jiwa "problem solving" inilah yang harus dikembangkan tim pengembang perangkat lunak.

Tentu saja, melakukan pendefisinian kebutuhan perangkat lunak HARUS melibatkan stakeholders secara intim. Karena pada dasarnya, permasalahan stakeholder-lah yang ingin diselesaikan, oleh dan dengan perangkat lunak yang akan dikembangkan. Seperti yang diungkapkan Pressman bahwa ... it is very important to understand the customer’s wants and needs before you begin designing or building a computer-based solution ...
Selanjutnya Pressman menulis bahwa ... the intent of requirements engineering is to produce a written understanding of the customer’s problem ... Ini harus dipahami sebagai tujuan yang harus dicapai oleh stakeholders dan tim pengembang, yakni permasalahan yang ingin diselesaikan haruslah dalam bentuk tertulis (written problems). Tinjauan permasalahan yang tertulis merupakan hal penting lainnya dalam proses pendefinisian perangkat lunak, karena sifat manusia (baik stakeholders dan pengembang) yang cenderung berubah-ubah, maka mendapatkan written problems merupakan hal yang mandatory. Biasanya dokumentasi kebutuhan perangkat lunak itu ditulis sebagai SRS (software requirements specification). SRS akan berisi scenario users, daftar fungsi dan fitures yang akan dikembangkan, model diagram analisis kebutuhan hingga spesifikasi sistem yang akan dikembangkan.

Tahap Requirements Engineering yang dikemukakan Pressman:
1) Inception (software engineers use context-free questions to establish a basic understanding of the problem, the people who want a solution, the nature of the solution, and the effectiveness of the collaboration between customers and developers)
2) Elicitation (find out from customers what the product objectives are, what is to be done, how the product fits into business needs, and how the product is used on a day to day basis)
3) Elaboration (focuses on developing a refined technical model of software function, behavior, and information)
4) Negotiation (requirements are categorized and organized into subsets, relations among requirements identified, requirements reviewed for correctness, requirements prioritized based on customer needs)
5) Specification (written work products produced describing the function, performance, and development constraints for a computer-based system)
6) Requirements validation (formal technical reviews used to examine the specification work products to ensure requirement quality and that all work products conform to agreed upon standards for the process, project, and products)
7) Requirements management (activities that help project team to identify, control, and track requirements and changes as project proceeds, similar to  software configuration management (SCM) techniques

Dalam prakteknya, pendefinisian persyaratan merupakan ketrampilan, sehingga harus dilatih agar supaya menjadi mahir. Semakin sering, seorang pengembang melakukan komunikasi-terbuka dengan stakeholders maka, pendefinisian perangkat lunak akan semakin clear dan sharp.

Selanjutnya, silahkan melihat tulisan saya berikut ini, sebagai bagian lanjutan dari Memahami Requirements Perangkat Lunak:

http://stanlysk.blogspot.com/2012/07/requirements-engineering.html

 

Konsep Manajemen Proyek Perangkat Lunak

Perangkat Lunak, sekarang ini dikembangkan dengan pendekatan manajemen proyek. Apa artinya? Dalam hal ini, kita, sebagai pengembang perangkat lunak, memahami bahwa perangkat lunak itu adalah sebuah produk. Dan sebagaimana halnya sebuah produk, maka untuk menghasilkan produk yang berkualitas, perangkat lunak perlu dibuat dengan mengikuti alur proses tertentu yang terukur. Pengelolaan perangkat lunak merupakan hal penting dalam menjamin kualitas produk perangkat lunak itu sendiri.

Pressman mengemukakan beberapa pokok pikiran terkait konsep manajemen proyek perangkat lunak, diantaranya adalah:

1) Project management involves the planning, monitoring, and control of people, process, and events that occur during software development.

2) Everyone manages, but the scope of each person's management activities varies according his or her role in the project.

3) Software needs to be managed because it is a complex undertaking with a long duration time.

4) Managers must focus on the fours P's to be successful (people, product, process, and project).

5) A project plan is a document that defines the four P's in such a way as to ensure a cost effective, high quality software product.

6) The only way to be sure that a project plan worked correctly is by observing that a high quality product was delivered on time and under budget.

Pokok pikiran yang dikemukakan Pressman dapat menjadi dasar kerangka acuan berpikir dari pengembang perangkat lunak. Lihat pokok pikiran 3) misalnya, disitu disebutkan bahwa perangkat lunak, perlu dikelola karena merupakan produk yang kompleks, yang harus dikerjakan dalam kurun waktu tertentu yang relatif cukup lama. Hal ini sangat tepat, dalam konteks perangkat lunak dewasa ini. Sebuah aplikasi stand-alone saja sudah terdiri dari puluhan halaman kode (diukur dengan satun LOC atau Lines of Code); belum lagi ditambah dengan banyaknya "konektivitas" (misalnya koneksi antar-muka, koneksi basis data, jaringan dan sebagainya). Sesungguhnya isu kompleksitas perangkat lunak, merupakan isu yang tidak terbantahkan di era Web 2.0 sekarang ini. Rancang bangun perangkat lunak yang sederhana merupakan tantangan tersendiri bagi tim pengembang.

Mari kita lihat, pokok pikiran Pressman yang ke 4). Disini Pressman menekankan mengenai spektrum manajemen perangkat lunak, yakni:

1) People (recruiting, selection, performance management, training, compensation, career development, organization, work design, team/culture development) 

2) Product (product objectives, scope, alternative solutions, constraint tradeoffs)

3) Process (framework activities populated with tasks, milestones, work products, and QA points)

4) Project  (planning, monitoring, controlling)

Fokus manajemen perangkat lunak, tidak melulu pada "product" atau working-software itu sendiri. Selain itu, diperlukan fokus untuk mengelola People (yakni semua yang terlibat dalam pengembangan perangkat lunak); Process (atau bisa disebut sebagai kerangka kerja, metodologi yang digunakan dalam mengembangkan perangkat lunak) serta Project (yang dapat dipahami sebagai aktivitas perencanaan, pengawasan dan pengendalian).

Terkait fokus manajemen PEOPLE; maka isu yang harus diperhatikan adalah bagaimana berkomunikasi. Pengalaman saya dalam mengembangkan perangkat lunak, maka semakin banyak stakeholders (dan tim pengembang) maka semakin besar juga bias dalam saluran komunikasi standar antar stakeholders (dan tim pengembang). Dalam berkomunikasi standar, kita menggunakan bahasa, namun demikian kadang ditemui, arti dan makna bahasa tertentu, sering dipahami berbeda. Isu ini akan mencuat jika tim pengembang terdiri dari anggota tim lintas generasi (perbedaan umur yang signifikan), kultur budaya yang berbeda serta lintas organisasi (atau lintas departemen). Diperlukan sebuah mekanisme komunikasi yang handal untuk menjamin saling pengertian antar tim pengembang. Tentu saja, secara pribadi, saya sangat menyarankan untuk menggunakan mekanisme: "tatap muka".

Terkait fokus manajemen PRODUCT, maka isu yang muncul biasanya adalah "scope creep", atau bertambahnya (berubahnya) fitur aplikasi. Scope creep muncul dari stakeholders, user dan tim pengembang sendiri. Mengatasi hal ini, bisa dengan sebuah kesepakatan formal mengenai fitur-fitur aplikasi yang dikembangkan. Atau jika terjadi perubahan, dikompensasi dengan besarnya cost pengembangan aplikasi. Isu lainnya yang penting juga adalah masalah kualitas perangkat lunak yang dihasilkan. Aktivitas pengujian perangkat lunak harus benar-benar dilakukan dan terdokumentasi dengan baik. Tidak bisa hanya sekedar melakukan Uji Acceptance; tapi juga HARUS melakukan uji teknis (dalam beberapa tipe uji perangkat lunak). Stakeholders harus memahami bahwa satu-satunya cara menjamin kualitas perangkat lunak adalah dengan melakukan uji perangkat lunak.

Terkait fokus manajemen PROCESS, maka isu yang harus diperhatikan adalah dokumentasi perangkat lunak. Pada dasarnya perangkat lunak itu adalah algoritma program yang menjalan proses bisnis tertentu, mengolah data dan DOKUMENTASI. Dokumentasi perangkat lunak, bukanlah sekedar Panduan Instalasi atau Panduan Menggunakan Aplikasi, tapi juga menyangkut setiap proses pengembangan perangkat lunak yang dilakukan. Hal ini penting untuk kepentingan manajemen proyek dan terlebih untuk kepentingan pemeliharaan perangkat lunak itu sendiri.

Model Proses Perangkat Lunak AGILE

Roger Pressman mengemukakan beberapa hal terkait model proses perangkat lunak agile (lunak); yakni:

Agile software engineering represents a reasonable compromise between to conventional software. 

Agile development processes can deliver successful systems quickly

Agile development stresses continuous communication and collaboration among developers and customers

Agile software engineering embraces a philosophy that encourages customer satisfaction, incremental software delivery, small project teams (composed of software engineers and stakeholders), informal methods, and minimal software engineering work products 

Agile software engineering development guidelines stress on-time delivery of an operational software increment over analysis and design (the only really important work product is an operational software increment)

Yang dapat dipahami dari pendapat Roger Pressman tersebut adalah model proses agile merupakan suatu model proses perangkat lunak yang menitikberatkan pada membangun perangkat lunak yang cepat, dan di-delivered kepada pengguna dengan cepat.

Apakah paradigma agile berarti "mengabaikan" disiplin software engineering? Tentu saja tidak! Karena yang namanya "process model" tentu saja, masih ber-proses. Dan proses memiliki pentahapan dengan sejumlah aktivitas tertentu yang harus dikerjakan. Pendapat saya, model proses agile, harus dipahami dalam konteks melibatkan user (dan stakeholders lainnya) secara penuh dalam pengembangan perangkat lunak; dengan terus-menerus mengadopsi kebutuhan user (yang akan cenderung berubah-ubah); dengan demikian harus memiliki tim pengembang yang siap dengan perubahan.

Silahkan melihat juga tulisan saya tentang Paradigma Web 2.0: Agile Process disini:

http://stanlysk.blogspot.com/2012/05/paradigma-web-20-agile-process.html

Pressman mengemukakan beberapa prinsip terkait model proses agile, diantaranya adalah:

1. Highest priority is to satisfy customer through early and continuous delivery of valuable software

2. Welcome changing requirements even late in development, accommodating change is viewed as increasing the customer’s competitive advantage

3. Delivering working software frequently with a preference for shorter delivery schedules (e.g. every 2 or 3 weeks)

4. Business people and developers must work together daily during the project

5. Build projects around motivated individuals, given them the environment and support they need, trust them to get the job done

6. Face-to-face communication is the most effective method of conveying information within the development team

7. Working software is the primary measure of progress

8. Agile processes support sustainable development, developers and customers should be able to continue development indefinitely

9. Continuous attention to technical excellence and good design enhances agility

10. Simplicity (defined as maximizing the work not done) is essential

11. The best architectures, requirements, and design emerge from self-organizing teams 

12. At regular intervals teams reflects how to become more effective and adjusts its behavior accordingly

Dari pengalaman saya, dalam mengembangkan perangkat lunak dengan pendekatan agile, maka prinsip utama yang harus dimiliki adalah KOMITMEN. Yakni komitmen tim pengembang dan komitmen stakeholders untuk terlibat dalam pengembangan perangkat lunak sepenuhnya. Tidak ada prinsip kunci lain yang dibutuhkan dalam pengembangan agile.

Silahkan lihat disini, sebuah contoh model proses pengembangan perangkat lunak dengan pendekatan agile:

Bagian Pertama: http://stanlysk.blogspot.com/2012/06/research-paper-web-portal-ans.html

Bagian Kedua: http://stanlysk.blogspot.com/2012/06/research-paper-web-portal-ans-part-ii.html

Pressman mengemukakan beberapa varian dari model proses agile yakni:

Extreme Programming (XP)

Adaptive Software Development (ASD)

Scrum

Dynamic Systems Development Method (DSDM)

Crystal

Feature Driven Development (FDD)

Lean Software Development (LSD)

Agile Modeling (AM)

Agile Unified Process (AUP)

Universitas Indonesia (dalam ini Pusat Ilmu Komputer UI) mengemukakan sebuah model proses agile yang disebut PAUS (Pusilkom Agile Unified Process). Selengkapnya dapat dilihat pada link ini: http://ecl.cs.ui.ac.id/PAUS/index.htm

Rapid Prototyping Methodology

Prototyping merupakan salah satu Model Proses Perangkat Lunak. Pendekatan ini sering digunakan dalam pembuatan tugas proyek perangkat lunak ataupun dalam Laporan Kerja Praktek dan Tugas Akhir mahasiswa. Salah satu varian dari Model Proses Prototyping ini adalah Rapid Prototyping.

Langkah dari Rapid Prototyping adalah sebagai berikut:
1. Requirement Gathering and Analysis
Pengembang aplikasi mengumpulkan dan menganalisa kebutuhan lebih detail dari sistem yang akan dibangun. Deliverable: kebutuhan sistem rinci (detailed system requirements).
2. Quick Design and Rapid Prototyping
Pengembang aplikasi menggunakan pendekatan prototipe cepat untuk membangun rancangan sistem, termasuk tata letak menu dan basis data. Dalam fase ini pengguna akan diminta pendapat terhadap rancangan yang dibuat. Kemudian bila ada perubahan, rancangan akan disesuaikan hingga memenuhi kebutuhan pengguna. Rancangan ini harus menggarisbawahi fitur yang paling penting dari sistem. Deliverable: prototipe sistem (system prototype).
3. Implementation
Keterlibatan pengguna dalam fase implementasi merupakan keharusan. Hasil sementara akan selalu dikonfirmasikan ke pengguna untuk mendapatkan masukan. Deliverable: sistem yang sudah jadi.
4. Test and Release 
Fase ini juga dikenal sebagai konversi ke sistem operasional. Karena pengguna telah berperan aktif dalam Fase Perancangan dan Implementasi, seharusnya pada fase ini hanya sangat sedikit perubahan bila masih ada. Bila masih ada perubahan, maka kembali ke fase sebelumnya. Deliverable: dokumentasi dan hasil uji coba

Beberapa acuan dalam menggunakan metode ini dapat dilihat disini:
https://docs.google.com/file/d/0BxSxy7HfW5oJMGNjMTc0NDAtYmViOC00OTY3LWFkYmYtNDA5MzMwNmFhZTg1/edit


Dibawah ini adalah sebuah Gambar dari langkah-langkah model proses Rapid Prototyping Methodology:

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?

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.

(gambar diambil dari http://www.sitechno.com/blog/content/binary/EF_TBT_ConceptualModel.jpg)

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.

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:

http://www3.software.ibm.com/ibmdl/pub/software/rational/web/whitepapers/ValueOfModeling.pdf

Pemodelan Perangkat Lunak

Saya sudah sering menulis tentang topik ini: pemodelan perangkat lunak, namun karena adanya kebutuhan untuk "mengumpulkan" tulisan-tulisan saya yang tersebar, menjadi lebih mudah dibaca, maka saya (kembalil) menulis topik ini.

Silahkan baca disini, bagi yang ingin mengetahui mengenai UML sebagai Bahasa Pemodelan Perangkat Lunak:

1. UML dan Pemodelan Software: tulisan ini membahas mengenai jenis-jenis diagram yang ada pada UML, beserta kegunaannya, dan pada proses SDLC mana diagram itu dapat digunakan http://stanlysk.blogspot.com/2012/04/pemodelan-dengan-uml.html
2. Model Sistem Perangkat Lunak: tulisan ini membahas tentang LINK official UML, serta maksud dan tujuan digunakannya UML sebagai alat pemodelan perangkat lunak. http://stanlysk.blogspot.com/2012/07/model-sistem-perangkat-lunak.html
3. UML Use Case Diagram; bagian tulisan ini menjelaskan secara mendetail, langkah-langkah logis tertentu dalam memodelkan perangkat lunak, dengan pendekatan user-oriented dan menggunakan UML Use Case Diagram http://stanlysk.blogspot.com/2012/05/use-case-diagram.html
4. Sequence Diagram; bagian tulisan ini menjelaskan secara mendetail, langkah-langkah logis tertentu dalam memodelkan perangkat lunak, dengan menggunakan UML Sequence Diagram  http://stanlysk.blogspot.com/2012/05/sequence-diagram.html

Bagi yang ingin melihat Video Tuturial tentang Pemodelan menggunakan UML, maka saya menganjurkan beberapa LINK Youtube dibawah ini:

1. Pengenalan tentang UML, klik disini: http://www.youtube.com/watch?v=FkRwbVUVFvE&feature=fvwrel

2. Use Case Diagram, klik disini: http://www.youtube.com/watch?v=Zk-580BqSNY&feature=fvwrel

3. Class Diagram, klik disini: http://www.youtube.com/watch?v=w2m-7YcHVck&feature=relmfu

4. Sequence Diagram, klik disini: http://www.youtube.com/watch?v=4WDbte6cPa8&feature=relmfu

Tautan dibawah ini, adalah daftar tools yang bisa digunakan untuk menggambar model UML:

http://en.wikipedia.org/wiki/List_of_Unified_Modeling_Language_tools

Model Sistem Perangkat Lunak

Pertanyaan pertama yang selalu muncul di benak pengembang perangkat lunak adalah "mengapa harus repot-repot membuat model sistem dari perangkat lunak yang akan dibangun?"

Memang, jika hanya melihat dari "satu sisi", maka langkah pemodelan sistem perangkat lunak, seperti membuang waktu. Namun demikian, pada kenyataannya, tidaklah demikian. Para pengembang perangkat lunak yang punya banyak "jam terbang" dan telah mengembangkan berbagai "model" akan menyetujui bahwa langkah pemodelan merupakan langkah yang penting dan strategis, dalam pengembangan perangkat lunak.

Sedikitnya ada beberapa alasan mengapa para pengembang "pemula" tidak memahami pentingnya langkah pemodelan perangkat lunak, diantaranya adalah:

1) terlalu banyak melibatkan pekerjaan "dokumentasi" perangkat lunak;

2) tidak menggambarkan persyaratan non - fungsional

3) tidak dapat menggambarkan keseluruhan aplikasi yang akan dikembangkan

4) jika modelnya terlalu "mendetail" maka justru akan membuat kebingungan.

Para pengembang "pemula" JUSTRU harus mengubah paradigma diatas, dengan meyakini bahwa model perangkat lunak, merupakan syarat penting untuk memulai kegiatan pengembangan perangkat lunak. Misalnya, dengan menggunakan model diagram, maka pengembang dapat "mengkomunikasikan" dengan pengguna, perihal perangkat lunak yang akan dikembangkan. Dari sisi pengembang, maka model perangkat lunak akan menjadi "panduan" pada langkah-langkah selanjutnya.

Banyak notasi yang dapat digunakan untuk memodelkan perangkat lunak, yang umum digunakan adalah:

Diagram Konteks,

Data Flow Diagram

Diagram Aktivitas

Diagram Use Case

Diagram Kelas

Diagram Sekuens

Diagram Navigasi

UML adalah salah notasi pemodelan yang umum digunakan dalam industri perangkat lunak. Untuk acuan RESMI dari notasi pemodelan UML, dapat mengklik tautan dibawah ini:
1. http://www.uml.org/

2. http://www.omg.org/index.htm

3. Document Associated with UML version 2.0:

http://www.omg.org/spec/UML/2.0/

4. UML version 2: In support on model driven development:

http://www.ibm.com/developerworks/rational/library/05/321_uml/

Requirements Engineering

Apakah yang dimaksud dengan requiremens engineering tersebut?

Menurut pemahaman Ian Sommerville, software requirements adalah ...

Requirements engineering is the process of establishing: (1) the services that the customer requires from a system; (2) the constraints under which it operates and is developed

Jadi, pada dasarnya, requirements adalah proses dimana developer sistem/aplikasi mencoba untuk memahami secara jelas, apa yang diinginkan user (atau stakeholders) pada sistem/aplikasi yang ingin dikembangkan.

Perlu diperhatikan disini, bahwa proses requirements merupakan proses yang sangat krusial dalam pengembangan perangkat lunak. Apalagi jika kita berparadigma bahwa ukuran "kualitas" perangkat lunak yang akan dibangun itu adalah "sesuai dengan kebutuhan dan keinginan pengguna".

Yang menjadi tantangan disini adalah bagaiman pengembang dan pengguna dapat memiliki kesaman persepsi mengenai setiap services dan constraints dari perangkat lunak yang akan dikembangkan.

Software Requirements atau Persyaratan Perangkat Lunak daapt dibedakan menjadi:

1) User Requirements: 

statements in natural language plus diagrams of the services the system provides and its operational constraints. Written for customers

2) System Requirements:

A structured document setting out detailed descriptions of the system services. Written as a contract between client and contractor
dan

3) Software Specification Requirements:

A detailed software description which can serve as a basis for a design or implementation. Written for developers

Dalam prakteknya, pendefinisian software requirements itu dilakukan dengan menggunakan berbagai model diagram, seperti misalnya UML Use Case Diagram, ataupuan Data Flow Diagram. Tujuan menggunakan notasi diagram adalah untuk "memudahkan" pemahaman antara user dan pengembang.

 (Gambar diambil dari http://cfc.kizzx2.com/index.php/software-requirements-and-management/)

Proses pendefinisian perangkat lunak, bertujuan untuk "menyelesaikan" berbagai perbedaan antara pengembang dan pengguna seperti yang diilustrasikan pada gambar diatas.

Secara umum, software requirements sering dibedakan menjadi requirement fungsional, non-fungsional dan requirements domain.

Untuk penulisan dokumen Software Requirements Spesification (SRS) dapat mengacu pada standar IEEE, seperti yang ditulis selengkapnya disini:
http://asingh.com.np/blog/ieee-srs-recommendations/
atau bisa juga melihat tulisan blog disini:
http://techwhirl.com/skills/tech-docs/writing-software-requirements-specs/

Beberapa Contoh Template Dokumen SRS dapat diunduh disini:

Template SRS 1: https://docs.google.com/file/d/0BxSxy7HfW5oJZE44Q2hNQjU3bnc/edit

Template SRS 2: https://docs.google.com/file/d/0BxSxy7HfW5oJamRYb2pqbkpXdFE/edit

Template SRS 3: https://docs.google.com/file/d/0BxSxy7HfW5oJYUh1WEY5SV9xTG8/edit

Penjelasan Video Tutorial Pembuatan Software Requirements Specification, dapat dilihat disini:
http://www.youtube.com/watch?v=HcRQ8oLik18
dan, disini:
http://www.youtube.com/watch?gl=ID&v=_XTQjKhh6hQ

Semoga Bermanfaat ...

Software Process

Apa yang dimaksud dengan Software Process?

Sejak tahun 1968, pengembangan perangkat lunak memasuki babakan baru dengan mengadopsi pendekatan system engineering. Pendekatan pengembangan perangkat lunak dengan system engineering bermakna bahwa perangkat lunak dikembangkan menurut kaidah keteknikan yang mengikuti urutan langkah-langkah logis tertentu. 

Dengan demikian, pengembangan perangkat lunak dapat dimodelkan menurut prinsip engineering tertentu. Model pengembangan perangkat lunak inilah yang disebut sebagai software process.
Sommerville mengartikan software process sebagai:
Software processes are the activities involved in producing and evolving a software system. They are represented in a software process model

Selanjutnya, Sommerville mengusulkan bahwa aktivitas umum dari Software Process tersebut adalah:
specification, design and implementation, validation and evolution.

Pressman, melihat software process dari sudut pandang praktis. Lihatlah sebuah Video tayangan berikut ini:

Pendekatan Pressman pada software process adalah communication, planning, modeling dan deployment.

Singkatnya, dalam memahami pengembangan perangkat lunak secara engineering, terdapat langkah-langkah logis yang berurutan tertentu (sebagai proses) yang akan menghasilkan perangkat lunak.

Menurut Sommerville,
terdapat beberapa software process yang berkembang sekarang ini, diantaranya adalah:
1) Model Waterfall
2) Model Perkembangan Evolutionary
3) Model Pengembangan Formal System
4) Model Pengembangan Guna-Ulang (reused-based)

Selanjutnya software process ini "diterjemahkan" menjadi langkah-langkah logis pada metodologi pengembangan perangkat lunak, seperti misalnya RAD, WebEng, RUP ataupun AUP.

Pengantar Rational Unified Process (RUP)

Rational Unified Process sebagai suatu kerangka kerja, makin banyak diminati di lingkungan akademis. Dalam artian, makin banyak para mahasiswa yang ingin menyelesaikan Tugas Proyek, Kerja Praktek bahkan Tugas Akhirnya dengan menggunakan framework Rational Unified Process (RUP). Tentu saja, hal ini merupakan perkembangan yang baik.

(sumber gambar: http://www.ibm.com/developerworks/rational/library/content/03July/1000/1156/1156_fig1.gif) 

Namun, minat yang makin meningkat dalam mengimplementasikan RUP juga harus dibarengi dengan pemahaman teori yang baik mengenai kerangka kerja tersebut.

Berikut ini adalah sebuah link acuan (berbasis slide kuliah) mengenai kerangka kerja RUP tersebut:

http://staf.cs.ui.ac.id/WebKuliah/SPPL/RUP_files/v3_document.htm

Tautan tersebut diatas dikeluarkan oleh Fakultas Ilmu Komputer - Universitas Indonesia. Referensi acuan yang dipakai adalah Rational Unified Process version 2003.06.12.01; sedangkan untuk buku acuan yang digunakan adalah Applying UML and Patterns: An Intriduction to Object-oriented Analysis and Design and the Unified Process karangan Craig Larman, Prentice Hall, 2002 ISBN: 0-13-092569-1

Untuk proses analisis dan disain menggunakan kerangka kerja RUP, biasanya akan menghasilkan beberapa dokumen tertentu; yakni:

RMP atau Requirement Management Plan

STRQ atau Stakeholder Request

Vision

Use Case Diagarm

Use Case Spesification

Supplementaru Spesification

Glossary

Dokumen-dokumen diatas merupakan dokumen standar yang harus dihasilkan pada fase inception, elaboration dan construction.

Disamping itu, apabila menggukan tool Rational Rose, maka, "proses" pendefinisian perangkat lunak yang akan dibangun juga harus menghasilkan dokumen:

Attribute Matrix All Features

Attribute Matrix Stakeholder Request

Attribtue Matrix Supplementary Spesification

dilengkapi dengan,

Traceability Stakeholder Needs VS Features

Traceability Features VS Use Case

Traceability Features VS Supplementary

Link dibawah ini adalah sebuah contoh penulisan dokumen-dokumen tersebut diatas:

https://docs.google.com/open?id=0BxSxy7HfW5oJNER6d1hibU5udVE

Link dibawah ini adalah sebuah Metodologi PAUS yang merupakan "modifikasi" gabungan dari RUP dan Agile:
http://ecl.cs.ui.ac.id/PAUS/index.htm

Semoga bermanfaat dan Selamat Belajar !!!

UML di IDE Netbeans

(Gambar diambar dari javastudy.wordpress.com)

Setelah sedikit mengutak-atik Netbeans Community, akhirnya saya mendapat kabar kalo UML sudah bisa digunakan di IDE Netbeans 6.9.1. Biasanya saya menggunakan Rational Rose untuk membuat model diagram UML, tapi akhirnya saya "tergoda" juga untuk menggunakan IDE Netbeans.

Sedikit perbedaan adalah, pada Rational Rose, disediakan fitur untuk menggambar diagram2 UML yang lebih lengkap, sedangkan untuk IDE Netbeans hanya disediakan Class Diagram, Activity Diagram, Use Case Diagram, Sequence Diagran dan State Diagram. Dari sudut pandang seorang dosen, maka saya mengatakan bahwa diagram2 tersebut sudah cukup untuk digunakan dalam perkuliahan maupun sebagai bagian dari Laporan Tugas Proyek dan Tugas Akhir.

Fitur click-and-drag yang disediakan Netbeans dalam menggambar UML Diagram, tentu saja memberikan kemudahan tersendiri bagi para pengguna IDE ini. Ditambah dengan fitur "reverse engineering" yang akan memudahkan kita untuk men-generate code dari diagram2 yang telah kita gambar.

Berikut ini adalah petunjuk instalasi Plug In UML:

https://docs.google.com/open?id=0BxSxy7HfW5oJT056NEItNF9PQUE

Berikut ini adalah Petunjuk Pemakaian UML di Netbeans:

https://docs.google.com/open?id=0BxSxy7HfW5oJVk1NdTZ0LUxvbjA

Berikut ini adalah Video Petunjuk Penggunaan UML di Netbeans:

http://www.youtube.com/watch?v=31BnR2AKazM

Untuk yang ingin mengetahui UML secara lebih mendalam melalui Video, dapat melihat link ini:

http://www.youtube.com/watch?v=FkRwbVUVFvE&feature=fvwrel

Praktikum Metode Numerik Revisited

Berikut ini adalah kumpulan link terkait Praktikum Metode Numerik

Pengantar Kalkulus dan Metode Numerik, klik disini:
http://stanleykarouw.blogspot.com/2012/04/keterhubungan-kalkulus-dan-metode.html

Metode Bagi Dua, klik disini
https://docs.google.com/file/d/0BxSxy7HfW5oJaF9oYUlpbnNRWmVDTk92a0RYS3lrUQ/edit?pli=1

Metode Posisi Palsu klik disini
http://stanleykarouw.blogspot.com/2012/04/regula-falsi.html

Metode Newton Rhapson, klik disini
http://stanleykarouw.blogspot.com/2012/04/newton-rhapson.html

Metode Secant, klik disini
http://stanleykarouw.blogspot.com/2012/04/secant.html

Metode Eliminasi Gauss, klik disini
http://stanleykarouw.blogspot.com/2012/04/praktikum-metode-numerik-modul-5-metode.html

Metode Iterasi Jacobi, klik disini:
http://stanleykarouw.blogspot.com/2012/05/iterasi-jacobi.html

Metode Eliminasi Gauss Seidel, klik disini
http://stanleykarouw.blogspot.com/2012/05/eliminasi-gauss-seidel.html

Metode Least Square, klik disini
http://stanleykarouw.blogspot.com/2012/05/least-square.html

Beberapa catatan penting, terkait kompetensi Praktikum Metode Numerik:
(1) Membandingkan Algoritma dan Script dari Metode Bagi Dua dan Posisi Palsu dalam Penentuan Solusi;
(2) Ketepatan algoritma dan script Metode Newton-Rhapson dalam Penentuan Solusi Persamaan Non Linier;
(3) Mencari Solusi dengan Pendekatan Metode Secant;
(4) Membandingkan Solusi Persamaan Linier dengan Metode Jacobi VS Gauss-Seidel;
(5) Menerapkan algoritma dan script Metode Gauss Seidel untuk Menemukan Solusi SPL;
(6) Menggunakan algoritma dan script metode Least Square Untuk menemukan solusi.

Automatic Weather Stations - Bagian 2

[Tulisan ini dibuat sebagai contoh Bahan Penelitian untuk Kerja Praktek Mahasiswa Teknik Elektro dan Teknik Informatika, Bagian Pertama dari Tulisan ini, dapat dibaca pada link dibawah ini:

http://stanleykarouw.blogspot.com/2012/06/authomatic-weather-stations.html ]

Perangkat Authomatic Weather Stations - AWS 

Perangkat AWS

Secara umum perangkat atau komponen yang di butuh kan untuk membangun AWS di bagi menjadi beberapa bagian utama yaitu :

1. Sensor

Sensor digunakan pada AWS adalah jantung dan jiwa dari sistem. Oleh karena itu banyak perawatan harus dilakukan ketika memilih sensor yang tepat untuk kebutuhan pengguna.AWS standar Biro menggunakan sensor untuk memantau temperature, kelembaban, kecepatan angin dan arah, tekanan dan curah hujan. Sensor lanjutan lainnya yang tersedia untuk aplikasi khusus. Sensor ini dapat memantau ketinggian awan (ceilometer), visibilitas, cuaca saat ini, badai, suhu tanah (pada kisaran kedalaman) dan suhu terestrial. Biro ini juga menyelidiki jenis lain dari sistem seperti penguapan otomatis.

Ada beberapa karakteristik mendasar yang membentuk akurasi dan presisi dari sensor.

• Resolusi - perubahan terkecil dapat mendeteksi perangkat (ini tidak sama dengan akurasi perangkat).
• Pengulangan - kemampuan sensor untuk mengukur parameter lebih dari satu kali dan menghasilkan hasil yang sama dalam keadaan yang identik.
• Response time - biasanya didefinisikan sebagai waktu yang dibutuhkan sensor untuk mengukur 63% dari perubahan.
• Drift - kestabilan kalibrasi sensor dengan waktu.
• Histeresis - kemampuan sensor untuk menghasilkan pengukuran yang sama apakah fenomena ini meningkatkan atau menurunkan.
• Linearitas - penyimpangan sensor dari perilaku garis lurus yang ideal.

Beberapa jenis sensor yang terdapat pada Automatic Weather Station (AWS) antara lain adalah :

a. Sensor Arah Angin

Sensor ini berfungsi untuk mengukur arah angin dalam rentang ukurantara 0 - 360 derajat. Terdapat aneka merk dari beragam produsenbaik dari luar maupun dalam negeri.

b. Sensor Kecepatan Angin

Sensor ini mengukur kecepatan angin, biasanya menggunakan tiga buah piringan (cup) yang bergerak memutar tiang cup yang menghasilkan frekuensi berubah-ubah yang proporsional dengan kecepatan angin. 

c. Sensor Kelembaban Udara

Kelembaban Udara diukur menggunakan suatu sensor kapasitor tipis. Sinyal dari sensor kemudian diubah menjadi dua keluaran sinyal voltase.

d. Sensor Curah Hujan

Volume atau jumlah hujan yang jatuh diukur menggunakan sensor jenis Tipping Bucket. Di pasaran terdapat beragam merk Sensor Curah Hujan seperti Global Water, AllWeather, Vaisala, Casella dan lain-lain.

e. Sensor Radiasi Matahari

2. Data  Logger

Data logger adalah sebuah alat elektronik yang berfungsi mencatat data dari waktu ke waktu baik yang terintegrasi dengan sensor dan instrumen didalamnya maupun ekternal sensor dan instrumen.

Produk luar : CampbellSci, Seba, dll

Produk lokal : Smartdatalogger

3. Catu Daya

Catu Daya berasal dari battery dan solar panel yang berfingsi memberi tenaga kepada AWS agar bisa bekerja secara terus menerus.

4. Penangkal Petir

Berfungsi untuk menetralisir arus bertegangan tinggi dan mengamankan peralatan AWS baik sensor maupun peralatan lainnya.

Diantaranya : Kurn (Lokal), Neoflash, Leader (Prancis), Leitai (Cina)

5. Sistem Akuisisi Data

Merupakan sebuah sistem pengukuran penomena fisik atau listrik seperti tegangan, arus, temperatur dari sensor AWS oleh perangkat akuisisi data yang diteruskan ke komputer untuk diolah dan ditampilkan dalam bentuk tabel atau grafik.

6. Sistem Komunikasi Data

Terdiri dari modem komuniksi GSM (Global System for Mobile communication) 

dan Software Sistem maupun Software Aplikasi yang berfingsi menyimpan dan mengirim data pengamatan.

7. Sarana Penunjang

Berupa tiang, pagar,komputer untuk AWS portable biasa menggunakan trimpot yang bisa di pindah.   

Konfigurasi Perangkat AWS-IP

Sistem telemetri data AWS tersiri dari GPRS, SMS, dial up, dan RF. Dalam sistem telemetri GPRS dan dial up, layanannya memanfaatkan operator GSM komersial dan internet. Dengan demikian, pengguna memperoleh data secara real time dalam bentuk grafik dan data unduhan. Sistem telemetri SMS dimanfaatkan untuk pengiriman data periodik. Data ini dikirimkan sebagai peringatan dini kepada pengguna. Sementara itu, dengan sistem telemetri RF, pengiriman data AWS ke pengguna dilakukan dengan menggunakan frekuensi radio VHF/ UHF. Keuntungan telemetri RF ini adalah bebas biaya.

Sistem telemetri data AWS

Skema Konfigurasi Pengiriman Data pada Sistem Informasi AWS

Automatic Weather Stations

[Tulisan ini dibuat sebagai contoh Bahan Penelitian untuk Kerja Praktek Mahasiswa Teknik Elektro dan Teknik Informatika]


Tinjauan Proses Bisnis
AWS (Automatic Weather Stations) merupakan suatu peralatan atau sistem terpadu yang di disain untuk pengumpulan data cuaca secara otomatis serta di proses agar pengamatan menjadi lebih mudah. AWS ini umumnya dilengkapi dengan sensor, RTU (Remote Terminal Unit), Komputer, unit LED Display dan bagian-bagian lainnya. Sensor-sensor yang digunakan meliputi sensor temperatur, arah dan kecepatan angin, kelembaban, presipitasi, tekanan udara, pyranometer, net radiometer. RTU (Remote Terminal Unit) terdiri atas data logger dan backup power, yang berfungsi sebagai terminal pengumpulan data cuaca dari sensor tersebut dan di transmisikan ke unit pengumpulan data pada komputer. Masing-masing parameter cuaca dapat ditampilkan melalui LED (Light Emiting Diode) Display, sehingga para pengguna dapat mengamati cuaca saat itu (present weather ) dengan mudah. (sebuah contoh AWS dapat dilihat pada Gambar dibawah)

Secara sederhana cara kerja dari AWS (Automatic Weather Stations) adalah mengumpulkan data pengamatan parameter cuaca secara otomatis melalui sensor-sensor secara berkala selanjutnya di kirim melalui jaringan GPRS(General Packet Radio Service) menggunakan layanan GSM (Global System for Mobile communication)  ke seluruh stasiun meteorology seluruh Indonesia. Seperti yang terlihat pada gambar di bawah ini:

Sistem pengelolaan data cuaca oleh AWS merupakan gabungan dari disiplin ilmu elektroteknik dan informatika. Hasil yang diberikan oleh AWS adalah informasi yang bermanfaat untuk penelitian terkait iklim dan cuaca, yang pada akhirnya bisa bermanfaat untuk kesejahteraan masyarakat. Proses bisnis pengelolaan data oleh AWS dapat dijadikan sumber acuan untuk penelitian mahasiswa yang melakukan Kerja Praktek ataupun Tugas Akhir.

Proses Labelling dengan Mesin Krones

[Tulisan ini dibuat sebagai contoh Bahan Penelitian untuk Kerja Praktek Mahasiswa Teknik Elektro dan Teknik Informatika]

Tinjauan Proses Bisnis 

Aqua adalah air minum dalam kemasan yang memiliki kualitas yang sangat baik. Kualitas yang sangat baik tersebut didapatkan melalui proses produksi yang sangat baik pula. Mulai dari pemilihan mata air sampai packing produk, semuanya dilakukan dengan Premium Quality Assurance yang tersertifikasi.

Sumber air aqua berasal dari Mountain Spring Water yaitu sumber air yang terklasifikasi bila sumber airnya benar-benar dari mata air pegunungan yang mengalir sendiri ke permukaan bumi. Proses ini membuat air tersaring secara alami sambil membawa berbagai mineral. Air kemudian melalui proses Filterisasi (Penyaringan) dan Disinfeksi (Menghilangkan bakteri pembawa penyakit) dengan metode Ozonasi (inti dari pemrosesan air).

Setelah melalui proses Water Treatment, air sudah siap untuk dikemas dalam kemasan melalui filler ke botol. Botol dibuat dari bijih/resin plastik ke bentuk preform(bentuk awal botol), setelah menjadi preform kemudian dipanaskan dan dibentuk menjadi botol lewat proses blowing (high press). Botol diisi dengan air oleh filler lalu ditutup dengan penutup botol (cap) lewat proses capping. Botol kemudian melewati proses coding (pemberian kode produksi dan tanggal kadaluarsa) dengan diawasi petugas untuk visualisasi (pengamatan produk).

Produk yang telah melewati proses visualisasi kemudian diberikan label produk aqua. Setelah pemberian label, produk akan melalui pemasangan segel tutup (seal). Setelah produk selesai maka proses terakhir adalah packing produk dalam karton. Karton yang telah selesai kemudian dibawa ke gudang (pallet) untuk siap dipasarkan.

Jika kita melihat Gambar diatas, maka kita melihat sebuah proses bagaimana mengolah air yang bersumber dari pegunungan menjadi sebuah produk air minum untuk masyarakat. Alam menyediakan bahan dasarnya, dengan sentuhan teknologi (khususnya elektroteknik dan informatika) maka dapat dihasilkan sebuah produk yang bermanfaat untuk kemaslahatan masyarakat.

Dari proses produksi ini, mahasiswa dapat melihat sebuah contoh implementasi ilmu elektroteknik dan informatika, yang dapat digunakan sebagai acuan penelitian untuk Kerja Praktek ataupun Tugas Akhir. Pemilihan proses bisnis tersebut diatas, didasari atas pertimbangan bahwa proses bisnis tersebut "melibatkan" implementasi keilmuan elektroteknik dan informatika secara komprehensif. Sehingga diharapkan dapat memberikan inspirasi bagi mahasiswa yang akan melakukan penelitian terpadu.

Tulisan ini akan dibuat dalam beberapa bagian bersambung.

Monetizing Web 2.0

Apa itu monetizing Web 2.0. Tentu saja, saya sudah banyak menulis tentang Web 2.0. Kumpulan tulisan saya tentang Web 2.0 dapat dibaca dengan melngklik link dibawah ini:

1. Paradigma Web 2.0 dapat dibaca disini
2. Apa itu Web 2.0 dapat dibaca disini.

3. Paradigma Web 2.0: Agile Process dapat dibaca disini

4. Perspektif Teknologi Informasi dapat dibaca disini

Untuk monetizing, yang saya maksudkan disini adalah sebuah proses mendapatkan value dan benefit (dan kemudian) mengalihkannya dalam bentuk uang. Proses monetizing ini merupakan bagian dari riset saya terkait IT Valuation/Investment. Terkait riset saya tentang IT Valuation/Investment dapat dibaca disini.

Sebelumnya, saya telah menulis tentang fenomena "eyeballs". Awalnya, teknik eyeballs digunakan untuk platform Web 1.0. Eyeballs pada dasarnya berarti "tingkat popularitas". Untuk platform Web 1.0, memang eyeballs bisa dijadikan acuan utama dalam monetizing web, tapi untuk platform Web 2.0 maka eyeballs sudah tidak bisa dijadikan lagi acuan utama. Selengkapnya tentang bahasan saya terkait hal ini dapat dibaca disini. Untuk business model web 2.0 akan saya bahas pada bagian tersendiri. 

Memulai bisnis dengan platform Web 2.0 terasa lebih murah. Ini dikarenakan adanya konsep FREEMIUM (yang sudah dibahas disini). Meskipun sebenarnya, pemahaman FREEMIUN bukanlah benar-benar FREE, tapi free (mendekati nol, tapi tidak benar-benar nol) hanya untuk capital cost (atau biaya modal), bukan untuk biaya operasional. Ini yang harus dipahami secara mendasar oleh siapapun yang ingin berinvestasi pada Web 2.0.

Sekarang ini, tren monetizing Web 2.0 adalah pada iklan. Memanfaatkan Google’s AdSense contextual advertising program merupakan salah satu cara tercepat untuk mendapatkan manfaat dalam  bentuk uang. Tentang hal ini, saya persilahkan untuk melihat-lihat tulisan di www.kawanuablogger.com. Komunitas ini benar-benar merupakan praktisi yang profesional terkait monetizing aplikasi Web 2.0 tipe blog dengan teknik Google AdSense contextual advertising program, dan teknik2 lainnya.

Berikut adalah contoh teknik monetizing Web 2.0

1. affiliate network
2. affiliate program
3. banner ad, contohnya Google AdSense, Yahoo! Publisher Network, Vibrant Media, Kontera and Tribal Fusion. 
4. cost-per-action (CPA). 5
5. cost-per-click (CPC)—Advertising that is billed by user click
6. cost-per-thousand impressions (CPM)—misalnya DoubleClick, dan ValueClick
7. e-commerce
8. interstitial ad
9. in-text contextual advertising, misalnya Vibrant Media, Text Link Ads, Kontera and Tribal Fusion. 
10. lead generation—Leads are generated when a visitor fills out an inquiry form so that a salesperson can follow through and potentially convert the lead to a sale. Lead generation adalah bagian dari teknik of cost-per-action advertising.
11. paid blog post misalnya PayPerPost, SponsoredReviews and ReviewMe.
12. performance-based advertising
13. premium content—Content on a website that is available for an extra fee (e.g., e-books, articles, etc.)
14. RSS ad
15. tagging for profit—A site that buys inbound links or tags from other sites to help increase traffic, and thus increase potential advertising revenue. High-traffic sites can sell tags or links to other websites for a profit. (Caution: Search engines may lower the ranking of sites with paid links.) Misalnya adalah 1000tags.com. 
16. virtual worlds monetization— misalnya Second Life, IMVU, Habbo, Gaia Online and There.

Bahasan terkait teknik-teknik monetizing Web 2.0 tersebut diatas akan dibahas pada bagian tersendiri. Sebagai bagian dari Catatan Kuliah IT Investment Management, maka setiap mahasiswa diharapkan untuk dapat mempelajari dengan seksama salah satu dari 16 teknik monetizing tersebut diatas, dan membuat sebuah tulisan terkait dengan teknik monetizing tersebut. Link tulisan diposting dibagian komentar tulisan ini.