manajemen proyek sistem informasi

Data SIMRENAS siap saji
Last Updated : 2005-06-03 15:27:15 (7572 read)
[Printer friendly page | Send to a friend]

Sejak otonomi daerah diberlakukan, kebutuhan akan data dan informasi yang akurat, mutakhir, dan dapat diperoleh secara cepat makin dirasakan. Pemerintah pusat selalu membutuhkan data dan informasi dari daerah untuk menentukan besaran dana perimbangan (DAU, DAK, Bagi Hasil). Sebaliknya, pemerintah daerah memerlukan data untuk membantu pemda menyelenggarakan pemerintahan daerah.

Sehubungan dengan hal tersebut, telah disediakan tabel-tabel yang dirancang untuk merekam data dan informasi perencanaan pembangunan nasional dan daerah dalam pelaksanaan otonomi daerah. Agar dapat mengisi tabel-tabel tersebut dengan sebaik-baiknya, disediakan Buku Panduan Pemahaman dan Pengisian Data Dasar Perencanaan Pembangunan. Pencatatan data dan informasi ke dalam tabel-tabel tersebut akan mendukung Simrenas yang telah menjalin kerja sama dengan Sekretariat Kabinet dan Sekretariat Negara, yaitu mengintegrasikan informasi Pusat Data Perencanaan dan Pengendalian Pembangunan Daerah yang ada di setiap daerah dengan Sistem Informasi Sidang Kabinet (SISKAB).

Dengan mengacu pada Panduan ini, diharapkan daerah dapat menyusun pangkalan data (database) yang berkualitas baik, lengkap, dan terstruktur. Dengan demikian maka daerah dapat dengan mudah dan cepat melihat peluang investasi dan potensi daerahnya untuk meningkatkan perekonomiannya, yang pada akhirnya akan memberdayakan daerah di era otonomi ini untuk menuju e-government di Indonesia.

Saat ini, sebagai pilot project telah terdapat 4 (empat) kabupaten yang telah mempunyai data dasar perencanaan pembangunan, yaitu kabupaten Badung, Banyuwangi, Ciamis, dan Lumajang.

——————————————————————————————-

Sejarah rekayasa perangkat lunak

Dari Wikipedia Indonesia, ensiklopedia bebas berbahasa Indonesia.


Rekayasa perangkat lunak telah berkembang sejak pertama kali diciptakan pada tahun 1940-an hingga kini. Fokus utama pengembangannya adalah untuk mengembangkan praktek dan teknologi untuk meningkatkan produktivitas para praktisi pengembang perangkat lunak dan kualitas aplikasi yang dapat digunakan oleh pemakai.

1945 – 1965: Awal

Istilah software engineering digunakan pertama kali pada akhir 1950-an dan awal 1960-an. Saat itu, masih terdapat debat tajam mengenai aspek engineering dari pengembangan perangkat lunak.

Pada tahun 1968 dan 1969, komite sains NATO mensponsori dua konferensi tentang rekayasa perangkat lunak, yang memberikan dampak kuat terhadap perkembangan rekayasa perangkat lunak. Banyak yang menganggap bahwa dua konferensi inilah yang menandai awal resmi profesi rekayasa perangkat lunak.

[sunting] 1965 – 1985: krisis perangkat lunak

Pada tahun 1960-an hingga 1980-an, banyak masalah yang ditemukan para praktisi pengembangan perangkat lunak. Banyak projek yang gagal, hingga masa ini disebut sebagai krisis perangkat lunak. Kasus kegagalan pengembangan perangkat lunak terjadi mulai dari projek yang melebihi anggaran, hingga kasus yang mengakibatkan kerusakan fisik dan kematian. Salah satu kasus yang terkenal antara lain meledaknya roket Ariane akibat kegagalan perangkat lunak.

[sunting] 1985 – kini: tidak ada senjata pamungkas

Selama bertahun-tahun, para peneliti memfokuskan usahanya untuk menemukan teknik jitu untuk memecahkan masalah krisis perangkat lunak.

Berbagai teknik, metode, alat, proses diciptakan dan diklaim sebagai senjata pamungkas untuk memecahkan kasus ini. Mulai dari pemrograman terstruktur, pemrograman berorientasi object, perangkat pembantu pengembangan perangkat lunak (CASE tools), berbagai standar, UML hingga metode formal diagung-agungkan sebagai senjata pamungkas untuk menghasilkan software yang benar, sesuai anggaran dan tepat waktu.

Pada tahun 1987, Fred Brooks menulis artikel No Silver Bullet, yang berproposisi bahwa tidak ada satu teknologi atau praktek yang sanggup mencapai 10 kali lipat perbaikan dalam produktivitas pengembangan perangkat lunak dalam tempo 10 tahun.

Sebagian berpendapat, no silver bullet berarti profesi rekayasa perangkat lunak dianggap telah gagal. Namun sebagian yang lain justru beranggapan, hal ini menandakan bahwa bidang profesi rekayasa perangkat lunak telah cukup matang, karena dalam bidang profesi lainnya pun, tidak ada teknik pamungkas yang dapat digunakan dalam berbagai kondisi.

——————————————————————————————-

Meluruskan Salah Kaprah Rekayasa Perangkat Lunak

Posted in Software Engineering by Romi Satria Wahono on the May 30th, 2006
Popularity: 35%. Visited 65630 times. Print This Post/Page E-Mail This Post/Page

classdiagram.jpgRekayasa Perangkat Lunak (Software Engineering), sedikit mengalami pergeseran makna di realita dunia industri, bisnis, pendidikan maupun kurikulum Teknologi Informasi (TI) di tanah air. Di industri, para tester, debugger dan programmer sering salah kaprah menyandang gelar Software Engineer. SMK di Indonesia juga latah dengan membuka jurusan Rekayasa Perangkat Lunak, meskipun secara kurikulum hanya mengajari bahasa C atau Pascal (mungkin lebih pas disebut jurusan pemrograman komputer) ;) Tulisan ini berusaha meluruskan salah kaprah yang terjadi tentang Rekayasa Perangkat Lunak (Software Engineering) berdasarkan kesepakatan, acuan, dan standard yang ada di dunia internasional.

Sejarah munculnya Rekayasa Perangkat Lunak sebenarnya dilatarbelakangi oleh adanya krisis perangkat lunak (software crisis) di era tahun 1960-an. Krisis perangkat lunak merupakan akibat langsung dari lahirnya komputer generasi ke 3 yang canggih, ditandai dengan penggunaan Integrated Circuit (IC) untuk komputer. Performansi hardware yang meningkat, membuat adanya kebutuhan untuk memproduksi perangkat lunak yang lebih baik. Akibatnya perangkat lunak yang dihasilkan menjadi menjadi beberapa kali lebih besar dan kompleks. Pendekatan informal yang digunakan pada waktu itu dalam pengembangan perangkat lunak, menjadi tidak cukup efektif (secara cost, waktu dan kualitas). Biaya hardware mulai jatuh dan biaya perangkat lunak menjadi naik cepat. Karena itulah muncul pemikiran untuk menggunakan pendekatan engineering yang lebih pasti, efektif, standard dan terukur dalam pengembangan perangkat lunak.

Dari berbagai literatur, kita dapat menyimpulkan bahwa Rekayasa Perangkat Lunak adalah:

Suatu disiplin ilmu yang membahas semua aspek produksi perangkat lunak, mulai dari tahap awal requirement capturing (analisa kebutuhan pengguna), specification (menentukan spesifikasi dari kebutuhan pengguna), desain, coding, testing sampai pemeliharaan sistem setelah digunakan.

Kalimat “seluruh aspek produksi perangkat lunak” membawa implikasi bahwa bahwa Rekayasa Perangkat Lunak tidak hanya berhubungan dengan masalah teknis pengembangan perangkat lunak tetapi juga kegiatan strategis seperti manajemen proyek perangkat lunak, penentuan metode dan proses pengembangan, serta aspek teoritis, yang kesemuanya untuk mendukung terjadinya produksi perangkat lunak.

Kemudian tidak boleh dilupakan bahwa secara definisi perangkat lunak tidak hanya untuk program komputer, tetapi juga termasuk dokumentasi dan konfigurasi data yang berhubungan yang diperlukan untuk membuat program beroperasi dengan benar. Dengan definisi ini otomatis keluaran (output) produksi perangkat lunak disamping program komputer juga dokumentasi lengkap berhubungan dengannya. Ini yang kadang kurang dipahami oleh pengembang, sehingga menganggap cukup memberikan program yang jalan (running program) ke pengguna (customer).

Rekayasa Perangkat Lunak bukan merupakan cabang ilmu Computer Science yang mempelajari tentang technical coding. Ini yang sering salah kaprah dipahami, sehingga pelajar, mahasiswa atau bahkan calon dosen ;) shock ketika dihadapkan dengan buku-buku textbook Rekayasa Perangkat Lunak yang selalu tebal dengan penjelasan sangat luas tentang bagaimana perangkat lunak diproduksi, dari aspek requirement capturing, desain, arsitektur, testing, kualitas software, sampai people/cost management. Dan ini adalah suatu kesepakatan yang sudah diterima umum tentang Rekayasa Perangkat Lunak, sejak jaman Roger S Pressman menulis buku “Software Engineering: A Practitioner’s Approach”, sampai Ian Sommerville yang kemudian datang dengan buku “Software Engineering” yang sudah sampai edisi ke 7, maupun pendatang baru semacam Hans Van Vliet, Shari Lawrence Pfleeger maupun James F Peters.

Terus bagaimana kalau kita ingin memperdalam masalah technical coding dan programming? Ada dua cabang ilmu lain yang membahas lebih dalam masalah ini, yaitu: Algoritma dan Struktur Data, dan Bahasa Pemrograman.

Kok bisa begitu, dasarnya darimana? Jadi pada hakekatnya, sebagai sebuah disiplin ilmu, Computer Science itu juga memiliki definisi, ruang lingkup, klasifikasi dan kategorisasinya. Klasifikasi yang paling terkenal dikeluarkan Task Force yang dibentuk oleh IEEE (Institute of Electrical and Electronics Engineers) dan ACM (Association for Computing Machinary (http://acm.org)) yang dipimpin oleh Peter J Denning, yang kemudian terkenal dengan sebutan Matriks Denning. Sangat jelas bahwa Matriks Denning memisahkan antara cabang ilmu Software Engineering dengan Algoritma dan Struktur Data, serta Bahasa Pemrograman. Itulah di paragraf awal saya sebut bahwa lebih tepat SMK, akademi atau universitas menggunakan nama jurusan (atau mata kuliah): Pemrograman Komputer, Algoritma dan Struktur Data, atau Bahasa Pemrograman, kalau memang materinya hanya mempelajari masalah bahasa pemrograman secara teknis.

Nah terus pertanyaan kembali muncul, jadi sebenarnya apa yang menjadi ruang lingkup ilmu Software Engineering itu apa? Pertanyaan ini merupakan pertanyaan banyak orang, semakin banyak peneliti dan praktisi menulis maka semakin bervariasi pemahaman yang muncul, semakin banyak buku yang terbit semakin membingungkan pelajar dan mahasiswa dalam memahami secara komprehensif apa itu Rekayasa Perangkat Lunak.

Kegelisahan ini dijawab tuntas oleh IEEE Computer Society (http://computer.org) dengan membentuk tim di tahun 1998 dimana tim tersebut mulai menyusun pemahaman standard (body of knowledge) tentang bidang ilmu Software Engineering, yang kemudian terkenal dengan sebutan SWEBOK (Software Engineering Body of Knowledge). Sudah ada dua versi SWEBOK ini, yaitu yang diterbitkan tahun 1999 dan terakhir tahun 2004.

Tiada gading yang tak retak kata orang bijak, project IEEE Computer Society tentang SWEBOK ini sebenarnya juga banyak dikritik oleh pakar yang lain. Paling tidak dua tokoh besar dunia Software Engineering yaitu Cem Kaner and Grady Booch tidak terlalu setuju dengan materi yang ada di dalam SWEBOK, bahkan menyebutnya sebagai sebuah guide yang misguided ;) Terlepas dari hal itu, boleh dikatakan SWEBOK cukup bisa diterima banyak pihak.

Selain SWEBOK, sebenarnya ada project lain yang mirip dalam usaha menyusun pemahaman standard dalam bidang Software Engineering, yaitu CCSE (Computing Curriculum Software Engineering). Project ini juga disponsori oleh IEEE Computer Society dan ACM , hanya orientasinya sedikit berbeda, yaitu untuk membentuk kurikulum standard berhubungan dengan bidang ilmu Software Engineering. Hal ini berbeda dengan orientasi SWEBOK yang lebih umum melingkupi dunia akademisi dan praktisi.

Catatan: Edisi lengkap dari tulisan ini dapat dibaca di majalah SDA Magazine edisi Juni 2006.

REFERENSI
[1] Guide to the Software Engineering Body of Knowledge 2004 Version (SWEBOK), A Project of the IEEE Computer Society Professional Practices Committee, http://www.swebok.org, 2004.
[2] IEEE Standard Glossary of Software Engineering Technology, IEEE Std 610.12-1990, Institute of Electrical and Electronics Engineers, New York, 1990.
[3] Hans Van Vliet, Software Engineering – Principles and Practice, John Wiley & Sons, 2000.
[4] Peter J Denning, Computer Science: the Discipline, In Encyclopedia of Computer Science (A. Ralston and D. Hemmendinger, Eds), 1999.
[5] James F. Peters and Witold Pedrycz, Software Engineering: An Engineering Approach, John Wiley & Sons, 2000.
[6] Roger S. Pressman, Software Engineering: A Practitioner’s Approach Fifth Edition, McGraw-Hill, 2004.
[7] Ian Sommerville, Software Engineering 7th Edition, Addison-Wesley, 2004.

ttd-small.jpg

——————————————————————————————-

Peran-peran dalam Rekayasa Perangkat Lunak Print E-mail
 
Akhir-akhir ini di sebuah milis bahasa pemrograman yang penulis ikuti sering muncul pertanyaan-pertanyaan yang intinya adalah “Jabatan-jabatan (peran) apa saja yang ada di dunia pemrograman (lebih luas lagi, rekayasa perangkat lunak)?” Berikut ini adalah beberapa jabatan yang penulis ketahui. Harap dicatat bahwa daftar ini tidak menyeluruh dan sangat subjektif dengan pengalaman penulis yang baru seumur jagung. Daftar ini tidak berdasarkan pengurutan apapun.

Peran Tugas (tidak menyeluruh)
Program/Product/Project Manager Mengatur keseluruhan proyek, termasuk pembentukan tim, alokasi staf, penjadwalan (secara garis besar), penentuan anggaran, dan lain sebagainya.
Development Manager Mengelola (proses) pengembangan software.
Lead Architect Menentukan fungsi-fungsi produk, arsitektur keseluruhan dan rancangan komunikasi antar paket/modul (untuk perancangan secara modular).
Lead Developer Menjamin kualitas kode, menjamin diterapkannya standar (konvensi), dan memeriksa (review) kode.
Domain Expert “Konsultan”. Ahli dalam bidang yang akan dibuat programnya (misalnya seorang akuntan untuk program akuntansi).
Customer Representative Wakil klien. “Mengawasi” proyek agar berjalan sesuai keinginan klien. Jika software dibuat untuk suatu departemen/divisi (penggunaan dalam perusahaan, bukan untuk dijual/memenuhi kontrak luar), perwakilan biasanya dari departemen yang bersangkutan.
Corporate Quality Assurance Liaison Mengawasi diterapkannya standar untuk sertifikasi internasional (misalnya ISO, CMM atau SEI), jika perusahaan yang bersangkutan menggunakannya.
Subsystem Teams Leads Mengembangkan paket-paket, mengelola tim (yang mengerjakan modul yang bersangkutan) dan penjadwalannya.
Package Architects Merancang kelas-kelas dalam paket.
User-Interface Expert Merancang spesifikasi user interface (input-output ke pengguna software).
Subsystem Teams Test Liaisons Mewakili tim yang merancang subsystem dalam pertemuan-pertemuan; review dan audit unit dan pengujian integrasi.
Developers Perancang dan mengimplementasikan (coding) kelas-kelas.
Quality Assurance Team Members Melakukan fungsi-fungsi quality assurance selama pengembangan; mengaudit dan mendokumentasikan kesesuaian proses.
Transition/Team Lead Mengelola pengujian sistem dan manajemen konfigurasi (configuration management), termasuk transisi ke pengguna.
Release Manager Mengelola tiap rilis, mengatur pertemuan yang membahas rencana rilis.
CM Lead Mengelola proses manajemen konfigurasi.
Testers Menguji program selama dan setelah pengembangan.
Subsystem Teams Quality Assurance Liaisons Mengoordinasikan aktivitas quality assurance dengan staf QA.
Toolsmith Mengurus masalah instalasi, kustomisasi alat-alat (program-program pendukung) dan berbagai library yang dibutuhkan.
Technical Writers Mendokumentasikan proses.

Beberapa catatan berkaitan dengan peran-peran di atas:

  • Umumnya untuk pengembangan dengan pendekatan berbasis objek (object oriented software engineering). Pendekatan lain dapat memiliki peran-peran seperti di atas juga, mungkin dengan sedikit modifikasi.
  • Dalam judul tabel tertulis “Peran”, bukan “Jabatan”. Kenapa? Karena pada prakteknya, seseorang di dunia pemrograman sering memiliki peran lebih dari satu, apalagi jika perusahaan tempat ia bekerja (atau proyek dimana ia terlibat) kecil.
  • Tidak setiap proyek mensyaratkan keberadaan seluruh peran di atas.
  • ISO yang umum dipakai adalah ISO 9001 (untuk proses) atau 9000-3 untuk lebih spesifik ke pengembangan perangkat lunak.
  • Tim QA biasanya sebuah bagian/departemen tersendiri dalam perusahaan, bukan spesifik ke suatu proyek perancangan perangkat keras (karena itu dalam tabel disebut “liason”).
  • Dimana “Analyst” dan “Programmer”? “Analyst” adalah definisi luas dari peran yang mengumpulkan requirements specification dan merancang sistem. “Programmer” adalah definisi luas dari peran yang mengimplementasikan (coding) sistem. Dalam praktek, biasanya seseorang juga analyst dan programmer (dengan perbandingan bobot sesuai kapasitasnya).
  • Dalam proyek skala besar, beberapa sub-komponen (subsystem) biasanya dikerjakan oleh sub-kontraktor.

Semoga artikel ini bermanfaat bagi para peminat Teknologi Informasi, khususnya mereka yang menekuni dunia rekayasa perangkat lunak (software engineering). Pada kesempatan mendatang penulis akan menjabarkan beberapa peran yang ada di dunia Teknologi Informasi. Masukan-masukan baik saran dan kritik sangat penulis harapkan. Sampai jumpa!

Daftar Pustaka

  • Cantor, Murray. Object-Oriented Project Management with UML. John Wiley & Sons, Inc.. 1998.
  • Galin, Daniel. Software Quality Assurance: From Theory to Implementation. Pearson Education Limited. 2004.

——————————————————————————————-

RPL

Ditulis oleh wawanakh di/pada Kamis, 1 November 2007

Rekayasa perangkat lunak adalah suatu disiplin rekayasa yang memperhatikan semua aspek dari produksi perangkat lunak. Perekayasa perangkat lunak melakukan pekerjaan yang diorganisir dengan pendekatan sistematis dan menggunakan ‘tools’ dan teknik yang sesuai dengan masalah yang akan diselesaikan, kendalanya pada pengembangan dan ketersediaan sumberdaya.

Perbedaan rekayasa perangkat lunak dengan ilmu komputer dan rekayasa sistem adalah dimana ilmu komputer mengenai teori dan dasar sedangkan rekayasa perangkat lunak mempelajari praktek pengembangan dan menghasilkan perangkat lunak yang bermanfaat. Teori ilmu komputer masih belum cukup lengkap untuk dijadikan sebagai dasar dalam rekayasa perangkat lunak. Dan untuk rekayasa sistem mempelajari sistem tentang semua aspek dari sistem berbasis komputer yang dikembangkan termasuk perangkat keras, perangkat lunak dan rekayasa proses. Jadi Rekayasa Perangkat Lunak bagian dari proses yang berkaitan dengan pengembangan infrastruktur, kendali, aplikasi dan database dalam sistem. System engineers meliputi spesifikasi sistem, desain arsitektur, integrasi dan penyebaran.

Proses perangkat lunak adalah sekumpulan aktivitas yang tujuannya adalah pengembangan atau evolusi perangkat lunak. Aktivitas umum dalam semua proses perangkat lunak adalah : Spesifikasi (apa yang seharusnya sistem kerjakan dan kendapa pengembangannya), Validasi (memeriksa perangkat lunak apakah sudah sesuai dengan keinginan kostomer), Evolusi (mengubah perangkat lunak untuk merespon perubahan kebutuhan.

Model proses perangkat lunak adalah suatu gambaran sederhana dari proses perangkat lunak, ditinjau dari persfektif tertentu. Contoh dari persfektif proses adalah : Perspektif aliran kerja (urut-urutan kegiatan), Perspektif aliran data (aliran informasi), Perspektif peran/aksi (siapa melakukan apa). Model proses umum : Waterfall; pengembangan Iteratif; Rekayasa perangkat lunak berbasis komponen.

Metode rekayasa perangkat lunak dengan pendekatan terstruktur dalam pengembangan perangkat lunak meliputi model sistem, notasi, aturan, saran desain dan petunjuk proses. Diskripsi model dibuat dalam bentuk grafis; Aturan (penerapan konstrain pada model sistem); Rekomendasi (saran praktik desain yang baik); Petunjuk Proses (Aktivitas apa yang diikuti).

Ciri-ciri perangkat lunak yang baik harus memenuhi kebutuhan fungsional, kinerja user dan harus mudah dirawat, dapat diandalkan dan dapat diterima.

Ditulis dalam Uncategorized

Tinggalkan Balasan

Isikan data di bawah atau klik salah satu ikon untuk log in:

Logo WordPress.com

You are commenting using your WordPress.com account. Logout / Ubah )

Gambar Twitter

You are commenting using your Twitter account. Logout / Ubah )

Foto Facebook

You are commenting using your Facebook account. Logout / Ubah )

Foto Google+

You are commenting using your Google+ account. Logout / Ubah )

Connecting to %s

%d blogger menyukai ini: