Sistem Informasi Manajemen

6. PENGEMBANGAN SISTEM

A.    PENDEKATAN SISTEM

Dalam sebuah buku di tahun 1910, Dewey mengidentifikasikan tiga rangkaian pertimbangan yang terlibat dalam pemecahan sebuah kontroversi secara memadai:

·         Mengenali kontroversi.

·         Mempertimbangkan klain-klain alternatif.

·         Membentuk satu pertimbangan.

Dewey tidak mempergunakan istilah pendekatan sistem, namun ia menyadari adanya sifat berurutan dari pemecahan masalah-mengidentifikasi suatu masalah, mempertimbangkan berbagai cara untuk memecahkannya, dan terakhir memilih solusi yang terlihat paling baik.

1. Urut-urutan Langkah

Urut-urutan langkah yang dapat dikelompokkan menjadi tiga yaitu upaya persiapan menyiapkan pemecahan masalah dengan memberikan suatu orientasi sistem. Upaya definisi terdiri atas pengidentifikasian masalah untuk dipecahkan dan kemudian memahaminya. Upaya solusi melibatkan pengidentifikasian solusi-solusi alternatif, mengevaluasinya, memilih salah satu solusi yang terlihat paling bagus, menerapkan solusi tersebut, dan menindaklanjutinya untuk memastikan bahwa masalah telah terpecahkan.

Tahapan I: Upaya persiapan

Langkah   1.  Melihat perusahaan sebagai suatu sistem Langkah   2.  Mengenal sistem lingkungan Langkah   3.  Mengidentifikasikan subsistem-subsistem perusahaan

Tahapan II: Upaya definisi

Langkah   4.  Melanjutkan dari tingkat sistem ke tingkat subsistem Langkah   5.  Menganalisis bagian-bagian sistem dalam suatu urutan-                      urutan tertentu

Tahapan III: Upaya solusi

Langkah   6.  Mengidentifikasikan solusi-solusi alternatif Langkah   7.  Mengevaluasi solusi-solusi alternatif Langkah   8.  Memilih solusi yang terbaik Langkah   9.  Mengimplementasikan solusi Langkah  10.  Menindaklanjuti untuk memastikan bahwa solusi tersebut                      efektif

B.     SIKLUS HIDUP PENGEMBANGAN SISTEM

Siklus hidup pengembangan sistem (system development life cycle-SDLC) adalah aplikasi dari pendekatan sistem bagi pengembangan suatu sistem informasi.

C.    PROTOTYPING

Prototipe adalah satu versi dan sebuah sistem potensial yang memberikan ide bagi para pengembang dan calon pengguna, bagaimana sistem akan berfungsi dalam bentuk yang telah selesai. Proses pembuatan prototipe mi disebut prototyping. Dasar pemikirannya adalah membuat prototipe secepat mungkin, bahkan dalam waktu semalam, lalu memperoleh umpan balik dari pengguna yang akan memungkinkan prototipe tersebut diperbaiki kembali dengan sangat cepat.

1.      Jenis-jenis Prototipe

·         Prototipe evolusioner (evolutionary prototype) terus-menerus disempurnakan sampai memiliki seluruh fungsional yang dibutuhkan pengguna dan sistem yang baru. Prototipe ini kemudian dilanjutkan produksi. Jadi, satu prototipe evolusioner akan menjadi sistem aktual. Pengembangan prototipe evolusioner dengan langkah-langkah sebagai berikut:

a.       Mengidentifikasi kebutuhan pengguna. Pengembang mewawancarai pengguna untuk mendapatkan ide mengenai apa yang diminta dari sistem.

b.      Membuat satu prototipe. Pengembang mempergunakan satu alat prototyping atau lebih untuk membuat prototipe. Contoh dari alat-alat prototyping adalah generator aplikasi terintegrasi dan toolking prototyping. Generator aplikasi terintegrasi (integrated app1iation generator) adalah sistem peranti lunak siap pakaLyang mampu membuat seluruh fitur yang dunginkan dan sistem baru—menu laporan tampilan, basis data, dan séterusnya. Toolkit prototyping meliputi sistem-sisteni peranti lunak terpisah, seperti spreadsheet elektronik atau sistem manajemen basis data, yang masing-masing marnpu membuat sebagian dan fitur-fitur sistem yang diinginkan.

c.       Menentukan apakah prototipe dapat diterima. Pengembang mendemonstrasikan prototipe kepada para pengguna untuk mengetahui apakah telah memberikan hasil yang memuaskan. Jika ya, Langkah d akan diambil; jika tidak, prototipe direvisi dengan mengulang kembali Langkah a,b, dan c dengan pemahaman yang lebih baik mengenai kebutuhan pengguna.

d.      Menggunakan prototipe. Prototipe menjadi sistem produksi.

·         Prototipe persyaratan (requirements  Prototype) dikembangkan sebagai satu cara untuk mendefmisikan persyaratan-persyaratan fungsional dan sistem baru ketika pengguna tidak mampu mengungkapkan dengan jelas apa yang mereka inginkan. Pengembangan prototipe persyaratan dengan langkah-langkah sebagai berikut:

Tiga langkah pertama (a,b,c) sama dengan langkah yang diambil dalam membuat sebuah prototipe evolusioner. Langkah-langkah berikutnya adalah sebagai berikut:

d.        Membuat kode sistem baru. Pengembang menggunakan prototipe sebagai dasar untuk pengkodean sistem yang baru.

e.         Menguji sistem baru. Pengembang menguji sistem.

f.         Menentukan apakah sistem yang baru dapat diterima. Pengguna memberitahukan apakah  pengembang apakah sistem dapat diterima. Jika ya, Langkah  g  akan diambil; jika tidak, Langkah d dan e  diulang kembali.

g.        Membuat sistem baru menjadi sistem produksi.

2.      Daya Tarik Prototyping

Pengguna maupun pengembang menyukai prototyping karena alasan-alasan di bawah mi:

•         Membaiknya komunikasi antara pengembang dan pengguna.

•         Pengembang dapat melakukan pekerjaan yang lebih baik dalam menentukan kebutuhan pengguna.

•         Pengguna memainkan peranan yang lebih aktif dalam pengembangan sistem.

•         Pengembang dan pengguna menghabiskan waktu dan usaha yang lebih sedikit dalam mengembangkan sistem.

•         Implementasi menjadi jauh lebih mudah karena pengguna tahu apa yang diharapkannya.

3.      Potensi Kesulitan dan Prototyping

Kesulitan-kesaulitan dalam penggunaan prototyping antara lain:

•         Terburu-buru dalam menyerahkan prototipe dapat menyebabkan diambilnya jalan pintas dalam definisi masalah, evaluasi alternatif, dan dokumentasi. Jalan pintas ini akan menciptakan usaha-usaha yang “cepat dan kotor.”

•         Pengguna dapat terlalu gembira dengan prototipe yang diberikan, yang mengarah pada ekspektasi yang tidak realistis sehubungan dengan sistem produksi nantinya.

•         Prototipe evolusioner bisa jadi tidak terlalu efisien.

•         Antarmuka komputer-manusia yang diberikan oleh beberapa alat prototyping tertentu kemungkinan tidak rnencerminkan teknik-teknik desain yang baik.

D.     PENGEMBANGAN APLIKASI CEPAT

Satu metodologi yang memiiki tujuan yang sama dengan prototyping, yaitu memberikan respons yang cepat atas kebutuhan pengguna, namun dengan lingkup yang lebih luas adalah RAD. Istilah RAD, dan rapid application development atau pengembangan aplikasi cepat diperkenalkan oleh konsultan komputen dan penulis James Martin, dan istilah mi mengacu pada suatu pengembangan siklus hidup yang dimaksudkan untuk memproduksi sistem dengan cepat tanpa mengorbankan mutunya. RAD adalah kumpulan strategi, metodologi, dan alat terintegrasi yang terdapat di dalam sutu kerangka kerja yang disebut rekayasa informasi.

1.      Unsur-unsur Penting RAD

RAD membutuhkan empat unsur penting manajemen, orang, metodologi, dan alat:

•         Manajemen khususnya manajemen puncak, hendaknya menjadi penguji coba (experimenter) yang suka melakukan hal-hal dengan cara baru atau pengadaptasi awal (early adapter) yang dengan cepat mempelajari bagaimana cara menggunakan metodologi-metodologi baru.

•         Orang, dari pada hanya memanfaatkan satu tim untuk melakukan seluruh aktivitas SDLC, RAD menyadari adanya efisiensi yang dapat dicapai melalui penggunaan tim- tim khusus. Anggota dan tim mi adalàh para ahli dalam metodologi dan alat yang dibutuhkan untuk melakukan tugas-tugas khusus mereka masing-masing, dengan istilah tim SWAT yang singkatan dari “skilled with advanced tools” (ahli dengan alat-alat canggih).

•         Metodologi dasar RAD adalah siklus hidup RAD.

•         Alat alat RAD terutama terdiri atas bahasa-bahasa generasi keempat dan alat-alat rekayasa peranti lunak dengan bantuan komputer (computer-aided software engineering—CASE) yang memfasilitasi prototyping dan penciptaan kode. Alat-alat CASE menggunakan komputer untuk membuat dokumentasi yang dapat diubah menjadi peranti lunak dan basis data operasional.

E.    PENGEMBANGAN BERFASE

Pengembangan berfase (phased development) adalah suatu pendekatan bagi pengembangan sistem informasi yang terdiri atas enam tahap.

1.      Tahap-tahap Pengembangan Berfase

Enam tahap pengembangan berfase adalah sebagai berikut:

•         Investigasi Awal. Para pengembang, terrnasuk pengguna dan juga spesialis informasi, melakukan analisis usaha dengan tujuan untuk mempelajari tentang organisasi dengan masalah sistemnya; mendefmisikan tujuan, hambatan, risiko, dan ruang lingkup sistem baru; mengevaluasi proyek maupun kelayakan sistem; melakukan subdivisi sistem menjadi komponen-komponen besar; dan mendapatkan umpan balik pengguna.

•         Analisis. Pengembang menganalisis persyaratan fungsional pengguna untuk masing-masing modul sistem dengan menggunakan berbagai macam teknik pengumpulan informasi dan kemudian mendokumentasikan temuan-temuannya dalam bentuk model- model proses, data, dan objek.

•         Desain. Pengembang merancang komponen dan antarmuka dengan sistem-sistem lain untuk setiap modul sistem yang baru dan kemudian mendokumentasikan desain dengan menggunakan berbagai jenis teknik pemodelan.

•         Konstruksi awal. Pengembang membuat dan menguji peranti lunak dan data untuk setiap modul sistem dan mendapatkan umpan balik dan pengguna. Untuk setiap modul yang tidak menerima persetujuan dan pengguna, tahap-tahap analisis, desain, dan konstruksi awal akan diulang kembali.

•         Konstruksi akhir. Piranti lunak modul diintegrasikan untuk membentuk sistem yang lengkap, yang diuji bersama-sama dengan datanya. Selain itu, setiap peranti keras yang dibutuhkan dibeli dan diuji, fasilitas-fasilitas dibuat, dan para pengguna dilatih.

•         Penggunaan dan pemasangan sistem. Pengembang merancang dan melaksanakan uji sistem yang tidak hanya mencalcup peranti lunak dan data melainkan juga sumber daya informasi lainnya. Komponen-komponen sistem dipasang, dan dilakukan uji penerimaan pengguna. Penerimaan oleh pengguna akan menjadi tanda persetujuan untuk melanjutkan ke tahap serah terima Setelah sistem digunakan selama beberapa waktu, mungkin selama béberapa minggu atau beberapa bulan, suatu tinjauan pasca implementasi dilakukan untuk memastikan bahwa sistem telah memenuhi persyaratan fungsionalnya.

2.      Fase-fase Modul

Jika prototyping paling sesuai digunakan untuk sistem kecil, metodologi RAD paling sesuai untuk sistem besar, maka pengembangan berfase dapat digunakan untuk pengembangan segala jenis ukuran sistem. Kuncinya adalah cara bagaimana sistem dibagi menjadi modul-modul yang masing-masing akan dianalisis, dirancang, dan dibuat secara terpisah.

F.    DESAIN ULANG PROSES BISNIS

Proses pengerjaan ulang sistem disebut dengan istilah rekayasa ulang (reengineering) atau diebut juga dengan istilah desain ulang proses bisnis (business process redesign—BPR). BPR memengaruhi operasi TI perusahaan dalam dua hal. Pertarna, TI dapat menerapkan BPR untuk mendesain ulang sistem-sistem informasi yang hidupnya tidak dapat dipertahankan lagi dengan pemeliharaan biasa. Sistem-sistem seperti mi diebut sistem warisan (legacy systems), karena mereka terlalu berharga untuk dihapuskan namun menghisap sumber-sumber daya yang dimiiki oleh IS. Kedua, ketika sebuah perusahaan menerapkan BPR pada operasi-operasi utamanya, usaha mi akan selalu memberikan efek gelombang yang menyebabkan perancangan ulang sistem informasi.

1.  Inisiasi Strategis Proyek-proyek BPR

BPR memiliki potensi  pengaruh dramatis pada perusahaan dan operasinya hingga proyek-proyek seperti ini biasanya dicetuskan di tingkat manajemen strategis. Manajemen strategis memutuskan bahwa BPR layak untuk dilakukan dan menyetujui proses-proses fisik didesain ulang. Manajemen strategis juga dapat mengijinkan sistem informasi dirancang ulang guna mengambil manfaat dari teknologi modern. Ketika proses-proses fisik dirancang ulang, sering kali akan terjadi efek domino yang akhirnya menyebabkan terjadinya perancangan ulang sistem informasi yang terkait. Karena alasan ini, BPR biasanya akan melibatkan layanan informasi.

IS menciptakan dua teknik dalam menerapkan BPR—rekayasa terbalik dan rekayasa ulang. Komponen-komponen ini dapat diterapkan secara terpisah atau secara tergabung.

·           Rekayasa Terbalik

Rekayasa terbalik adalah proses menganalisis sistem yang sudah ada untuk mengidentifikasi unsur-unsur dan saling keterhubungan di antara unsur-unsur tersebut sekaligus untuk membuat dokumentasi pada tingkat abstraksi yang lebih tinggi daripada yang telah ada saat ini. Titik awal dalam rekayasa terbalik sebuah sistem adalah kode komputernya yang diubah menjadi dokumentasi. Dokumentasi ini kemudian dapat diubah ke dalam uraian-uraian yang lebih abstrak seperti diagram arus data, kasus-kasus penggunaan, dan diagram relasi entitas. Pengubahan ini dapat dilakukan secara manual atau dengan menggunakan peranti lunak BPR.

Oleh sebab itu, rekayasa tetbalik akan mengikuti suatu jalur mundur ke belakang sepanjang siklus hidup sistem, merekonstruksi desain dan perencanaan sistem yang dilakukan dalam usaha pengembang awal. Hasilnya adalah suatu sistem yang terdokumentasi secara menyeluh. Tujuan rekayasa terbalik sebearnya adalah untuk dapat lebih memahami sebuah sistem agar dapat melakukan perubahan dengan cara-cara lain, seperti rekayasa ulang.

·           Rekayasa Ulang

Rekayasa ulang (reengineering) adalah merancang ulang sebuah sistem seluruhnya dengan tujuan méngubah fungsionalitasnya. Akan tetapi, ini bukanlah pendekatan yang “bersih”, karena pengetahuan dan sistem yang ada saat mi tidak sepenuhnya diabaikan. Pengetahuan tersebut diperoleh pertama kali dengan melakukan rekayasa terbalik. Lalu sistem yang baru kemudian dikembangkan dengan cara yang normal. Nama rekayasa ke depan (forward engineering) diberikan untuk proses mengikuti SDLC dengan cara yang normal sambil sekaligus menjalankan BPR.

2. Pemilihan Komponen-komponen BPR

Mutu fungsionalitas adalah ukuran dan apa yang dikerjakan oleh sistem. Sedangkan  Mutu teknis adalah ukuran dan seberapa baik sistem tersebut melaksanakannya. Ketika mutu fungsional maupun teknis sama-sama buruk, maka akan dibutuhkan suatu proyek rekayasa ke depan. Keadaan menjadi begitu buruknya sehingga akan lebih baik jika kita mengulang semuanya, menjalankan langkah-langkah dari siklus hidup. sistem dengan cara yang normal. Ketika fungsionalitas baik tetapi mutu teknis buruk, maka rekayasa terbalik hendaknya dicoba untuk dilakukan. Ketika fungsionalitas buruk tetapi mutu teknis baik, maka dibutuhkan rekayasa terbalik. Dalam kasus seperti ini, sistem telah mencerminkan teknik-teknik yang modern tetapi memang tidak dapat mengerjakan tugasnya dengan baik. Kétika mutu fungsionalitas maupun teknis sama-sama baik, hal yang paling baik adalah membiarkan sistem tersebut apa adanya.

G.     PEMODELAN PROSES

Pemodelan proses pertama kali dilakukan dengan menggunakan diagram alur (flowchart). Diagram ini mengilustrasikan aliran data sistem dan progam. International Organitation for Standardization (ISO) menciptakan standart untuk bentuk-bentuk simbul flowcart, memastikan penggunaanya diseluruh dunia. ketika sistem dikembangkan, proses, data dan obyek akan dibuat modalnya. Alat pemodelan proses yang populer adalah pembuatan diagram arus data.

1.       Diagram arus data (data flow diagram-DFD)

Adalah penyajian grafis dari sebuah sistem yang mempergunakan empat bentuk simbol untuk mengilustrasikan bagaimana data mengalir melalui proses-proses yang saling tersambung. Simbol-simbol tersebut mencerminkan (1) unsur-unsur lingkungan dengan mana sistem berinteraksi, (2) proses, (3) arus data, dan (4) penyimpanan data.

Unsur-unsur lingkungan berada diluar batas sistem. Unsur-unsur ini memberikan input data kepada sistem dan menerima output data dari sistem. Dalam DFD, tidak ada perbedaan antara data dan informasi. Seluruh arus maya dapat dianggap sebagai data.

Istilah  terminator sering kali dipergunakan untuk menyatakan unsur-unsur lingkungan, karena menunjukkan titik-titik dimana sistem berakhir. Suatu terminator digambarkan di DFD dalam bentuk kotak atau persegi panjang, yang diberi label dengan nama unsur lingkungan tersebut.

Suatu terminator dapat berupa :

·      Orang, seperti seorang manager, yang menerima laporan dari sistem.

·      Organisasi, seperti departemen lain dalam perusahaan lain.

·      Sistem lain yang memiliki antarmuka dengan sistem.

Pekerjaan penting dalam analisis dan desain sistem adalah  pendefmisian batasan sistem. Terminator-lah yang melakukan pekerjaan ini. Pengembang akan bekerja didalam batasan dan menciptakan hubungan-hubungan dengan lingkungan sistem dalam bentuk arus data.

Proses adalah sesuatu yang mengubah input menjadi output. Proses dapat digambarkan dengan sebuah lingkaran, sebuah persegi panjang horizontal, atau sebuah persegi panjang tegak bersudut melingkar. Masing-masing simbol proses diidentifikasikan dengan sebuah label. Teknik pemberian label yang paling umum adalah dengan menggunakan kata kerja dan objek, tetapi Anda juga dapat mempergunakan nama dari suatu sistem atau program Komputer.

Arus Data terdiri atas sekumpulan unsur-unsur data yang berhubungan secara logis (mulai dari satu unsur data tunggal hingga satu file  atau lebih) yang bergerak dari satu titik atau proses ke titik atau proses yang lain. Simbol panas digunakan untuk menggambarkan arus mi dapat digambar dengan menggunakan garis lurus maupun melingkar.

Arus data dapat menyebar  ketika data yang sama menuju pada beberapa  lokasi di dalam sistem. Arus data juga dapat menyatu  untuk menunjukkan beberapa arus data yang identik menuju ke satu lokasi. Terkadang desain sistem meminta adanya arus data dua arah. Hal mi dapat digambarkan dengan satu garis yang memiliki dua ujung panah, atau dua panah.

Arus data harus melibatkan suatu proses. Data dapat mengalir antara entitas eksternal dan proses, antara penyimpanan data dan proses, dan antara dua proses atau lebih. Kalimat “data bergerak” adalah satu cara yang baik dalam membayangkan arus data, karena data bergerak dari satu titik ke titik yang lain di dalam sistem.

Dalam terminology DFD, penyimpanan data adalah suatu gudang data. Bayangkanlah penyimpanan data sebagai “data yang beristirahat”. Penyimpanan data dapat ditunjukkan oleh sekumpulan garis-garis sejajar, sebuah kotak dengan ujung terbuka, atau bentuk oval.

Proses menggambar sebuah DFD hanyalah mengidentifikasi proses-proses yang terjadi, menghubungkan mereka dengan arus-arus data, mengidentifikasi terminator yang memberikan input dan menerima output, serta menambahkan penyimpanan data bilamana dibutuhkan.

Diagram konteks (context diagram) menempatkan sistem dalam suatu konteks lingkungan. Diagram ini terdiri atas satu simbol proses tunggal yang melambangkan keseluruhan sistem. Diagram ini menunjukkan arus data yang mengarah dan keluar dari terminator.

Ketika menggambarkan sebuah diagram konteks, Anda :

·         Hanya menggunakan satu simbol proses saja.

·         Memberikan label pada simbol proses untuk mencerminkan keseluruhan sistem. Anda dapat menggunakan kata kerja ditambahkan dengan objek seperti “memproses komisi penjualan” atau Anda dapat menggunakan nama sistem seperti dalam figure.

·         Jangan memberikan nomor pada simbol proses tunggal.

·         Memasukkan seluruh terminator untuk sistem.

·         Menunjukkan seluruh arus data yang terjadi antara terminator dan sistem.

Meskipun diagram konteks mendokumentasikan sebuah sistem pada tingkat yang tertinggi, biasanya akan lebih mudah untuk memulai dokumentasi pada tingkat yang lebih rendah, misalnya, tingkat Nomor 0.

Ketika kita perlu mendokumentasikan sistem dengan detail yang lebih besar daripada diagram nomor 0, Anda akan menggunakan satu atau lebih diagram nomor N. Diagram nomor n (figure n diagram) mendokumentasikan satu proses dari sebuah DFD dengan tingkat detail yang lebih besar. n melambangkan nomor proses pada tingkat yang lebih tinggi dari yang sesuatu sedang didokumentasikan.

H.       MANAJEMEN PROYEK

Proyek-proyek pengembangan sistem yang pertama dikelola oleh manager unit TI, dengan dibantu oleh manajer dari analisis sistem, pemrograman, data operasi. Melalui percobaan, tanggung jawab manajemen secara bertahap telah mencapai tingkat manajemen yang lebih tinggi, yaitu tingkat strategis dalam kebanyakan kasus.

Ketika sistem memiliki nilai strategis atau pengaruhnya meliputi keseluruhan organisasi, direktur utama atau komite eksekutif perusahaan dapat memutuskan untuk mengawasi sendiri proyek pengembangan tersebut. Banyak perusahaan membentuk satu komite khusu di bawah tingkat komite eksekutif yang menerima tanggung jawab untuk mengawasi seluruh proyek sistem. Ketika tujuan dari dibentuknya sebuah komite adalah untuk memberikan panduan, arah, dan kendali secara terus-menerus, maka ia disebut  sebagai steering cominite (komite pengarah).

1.      Steering Cominite SIM

Ketika sebuah perusahaan membentuk satu steering cominitte dengan tujuan untuk mengarahkan penggunaan sumber daya komputasi perusahaan, maka nama steering cominittee SIM akan digunakan. Para anggota permanen dari steering cominittee SIM selalu terdiri atas para eksekutif puncak. Sedangkan anggota sementara terdiri atas manajer-manajer tingkat yang lebih rendah dan para konsultan yang ikut berpartisipasi sepanjang keahlian mereka dibutuhkan.

Steering cominittee SIM menjalankan tiga fungsi utama :

·         Menciptakan kebijakan memastikan dukungan Komputer untuk mencapai sasaran strategis perusahaan.

·         Melakukan pengendalian fiskal dengan bertindak sebagai yang berwenang dalam memberikan persetujuan untuk seluruh permintaaan akan pendanaan yang berhubungan dengan Komputer.

·         Menyelesaikan perselisihan yang terjadi sehubungan dengan prioritas penggunaan Komputer.

Jadi secara tidak langsung tugas steering cominittee SIM adalah melaksanakan seluruh strategi yang dibuat oleh komite eksekutif maupun rencana strategis untuk sumberdaya informasi.

Dengan memusatkan managemen siklus hidup sistem dalam steering cominittee, maka akan didapat dua keuntungan utama. Yaitu meningkatnya kemungkinan :

·         Komputer akan digunakan untuk mendukung penggunaan di seluruh perusahaan.

·         Proyek-proyek Komputer akan memiliki ciri-ciri perencanaan dan pengendalian yang baik.

Steering cominittee SIM adalah bukti yang paling nyata bahwa perusahaan memang berniat untuk menjadikan sumber daya informasi tersedia bagi seluruh pengguna yang benar-benar membutuhkanya.

2.      Kepemimpinan Proyek

Steering cominittee SIM jarang ikut terlibat langsung dengan detail pekerjaan. Tanggung jawab itu jatuh ke tangan tim proyek. Tim proyek meliputi semua orang yang ikut berpartisipasi dalam pengembangan sistem informasi. Satu tim dapat memiliki anggota hingga selusin, yang terdiri atas gabungan beberapa orang pengguna, spesialis informasi, dan mungkin auditor internal. Auditor akan memastikan bahwa desain sistem telah memenuhi beberapa persyaratan tertentu dilihat dari segi keakuratan, pengendalian, keamanan, dan auditabilitas. Aktifitas tim akan diarahkan oleh seorang ketua tim atau pemimpin proyek yang memberikan arahan disepanjang masa proyek. Berbedsa dari steering cominittee SIM, tim proyek tidaklah terus-menerus; biasanya akan dibubarkan ketika implementasi telah selesai dilaksanakan.

3.      Mekanisme Manajemen Proyek

Dasar dari manajemen proyek adalah rencana proyek, yang dibuat selama tahap investigasi awal ketika metodologi pengembangan berfase diikuti. Setelah tujuan-tujuan proyek, kendala, dan ruang lingkupnya telah didefmisikan, kita akan dapat mengidentifikasi pekerjaan-pekerjaan yang harus dilaksanakan.

Satu pelengkap bagi grafik Gantt adalah diagram-diagram jaringan. Diagram jaringan (network diagram) yang disebut juga diagram CPM (Critical Path Method) atau PERT (Program Evaluation and Review Technique), adalah sebuah gambar yang mengidentifikasikan aktifitas-aktifitas dan menghubungkanya dengan panah-panah untuk menunjukkan urutan-urutan pengerjaan.

Grafik Gantt dan diagram adalah contoh dari laporan grafis. Laporan naratif, dalam bentuk laporan tertulis mingguan yang dibuat oleh pimpinan proyek, memberikan alternative komunikasi informasi proyek lainnya bagi steering cominittee SIM.

4.      Dukungan Web bagi Manajemen Proyek

Selain sistem manajemen proyek berbasis peranti lunak seperti Microsoft Project, dukungan juga dapat diperoleh dari internet.

I.      MENGESTIMASI BIAYA PROYEK

Mengestimasikan waktu dan ruang yang dibutuhkan untuk mengembangkan sebuah sistem telah lama menjadi satu tugas yang menantang. Akan tetapi, lambat laun telah diciptakan banyak metode yang dapat dipergunakan untuk mengestimasi biaya dan jadwal proyek. Semua metode mi kurang kebih mengandalkan pada tiga komponen :

•         Informasi mengenai sistem tertentu yang sedang dibuat dan orang yang akan melakukan pengembangan.

•         Pengalaman historis.

•         Pengetahuan mengenai proses pengembangan peranti lunak dan alat-alat serta teknik estimasi.

1.       Input Pengestimasi Biaya

Sebuah work breakdown structure (WBS) mengidentifikasikan aktifitas-aktifitas proyek yang akan membutuhkan sumber daya. Contoh WBS adalah grafik Gantt dan diagram jaringan. Kebutuhan sumber daya (resource requirement) mencantumkan sumber daya tertentu yang akan dibutuhkan dan berapa jumlahnya. Tariff sumber daya (resource rates) adalah biaya per unit untuk setiap jenis sumber daya. Estimasi durasi aktifitas (activity duration estimates) menyebutkan periode pekerjaan yang dibutuhkan untuk menyelesaikan aktivitas. Informasi historis (historical information) terdiri atas file-file dari data proyek masa lalu, basis data pengestimasian biaya komersil, dan pengetahuan tim proyek.

2.      Alat-alat Teknik Estimasi Biaya

Estimasi analogis (analogous estimating) menggunakan biaya actual proyek-proyek serupa yang telah dilakukan di masa lalu sebagai dasar untuk memproyeksikan biaya dari proyek yang sedang dipertimbangkan. Teknik ini digunakan ketika hanya terdapat sedikit informasi lain yang tersedia. Teknik ini lebih murah daripada teknik-teknik yang lain, tetapi pada umumnya kurang akurat.

Estimasi dari bawah ke atas (bottom-up estimating) dimulai dengan detail, seperti aktifitas di dalam grafik Gantt, lalu mengalikannya dengan data biaya, seperti tarif per jam untuk karyawan, untuk menghasilkan estimasi biaya proyek. Semakin banyak detai lawal, maka akan semakin akurat hasil yang diperkirakan.

Alat-alat terkomputerisasi (computerazed tools) dapat digunakan secara terpisah atau untuk menyederhanakan alat-alat yang baru saja diuarikan.

Model-model matematis (mathematical models) dapat digunakan untuk menguantifikasi karakteristik proyek dan membuat simulasi dari berbagai macam scenario. Hasil output teknik mi akan paling akurat ketika data historisnya akurat, karakteristiknya, dapat dikuantifikasi dengan mudah, dan model tersebut dapat diatur skalanya sehingga dapat menangani ukuran proyek dalam rentang yang lebar.

3.      Output Pengestimasian Biaya

Estiamasi biaya dibuat untuk seluruh sumber daya yang dibebankan ke proyek dan biasanya dinyatakan dalam unit-unit keuangan yang berlaku, seperti Dolar atau Euro. Estimasi seprti mi dapat disempurnakan kembali selama proyek berlangsung untuk mencerminkan tambahan informasi seiring dengan semakin jelasnya proyek tersebut. Detail-detail pendukung mendokumentasikan bagaimana estimasi tersebut dihitung dan setiap asumsi-asumsi yang diambil. Rencana manajemen biaya (cost-manajement plat) menjelaskan bagaimana varians biaya akan dikelola