Definisi System Analysis

System Analysis adalah suatu teknik atau metode pemecahan masalah dengan cara menguraikan system ke dalam komponen-kemponen pembentuknya untuk mengetahui bagaiman komponen-komponen tersebut bekerja dan saling berinteraksi satu sama lain untuk mencapai tujuan system. System Analysis biasanya dilakukan dalam mebuat System Design System Design adalah salah satu langkah dalam teknik pemecahan masalah dimana komponen-komponen pembentuk system digabungkan sehingga membentuk satu kesatuan system yang utuh. Hasil dari System Design merupakan gambaran system yang sudah diperbaiki. Teknik dari System Design ini meliputi proses penambahan, penghilangan, dan pengubahan komponenkomponen dari system semula.

Information System Analysis

Sampai saat ini, belum ada ketentuan umum mengenai definisi Information System Analysis. Belum ada aturan yang menentukan kapan System Analysis selesai dan kapan System Design dapat dimulai. Information System Analysis adalah proses pengembangan suatu proyek yang difokuskan pada masalah bisnis dan independensi teknologi, yang dapat diimplementasikan untuk mencari solusi atas permasalahan tersebut. Titik berat System Analysis adalah pada masalah bisnis, bukan pada masalah teknis atau implementasi. System Analysis dikendalikan oleh proses bisnis yang dilakukan oleh pemilik dan pengguna system. Proses bisnis ini dibagi menjadi tiga bagian yaitu DATA, PROCESS, dan INTERFACE pada diagram blok. Dalam hal ini System Analysts berperan sebagai fasilitator dari System Analysis. Dokumentasi yang dihasilkan oleh bagian System Analysis disimpan dalam sebuah repository. Repository adalah tempat atau lokasi dimana system analysts, system designer, dan system builder menyimpan dokumentasinya yang memiliki hubungan dengan system atau proyek lain. Repository dapat dibuat khusus hanya untuk satu proyek atau dibuat untuk menyimpan dokumentasi seluruh proyek atau system. Repository umumnya merupakan hasil implementasi kombinasi seperti di bawah ini : Satu atau lebih CASE tool Dictionaries atau Ensiklopedia Dokumentasi tertulis Jaringan kerja komputer yang berisi laporan, korespondensi dan data proyek Intranet website interface (biasanya digunakan sebagai sarana komunikasi)

Pada intinya System Analysis merupakan proses pemecahan masalah. System Analysis dapat dilakukan melalui beberapa pendekatan. Pendekatan yang paling sering digunakan adalah structured analysis, information engineering, discovery prototyping dan object-oriented analysis. Dalam aplikasinya, pendekatan-pendekatan ini digunakan bersamaan agar dapat saling melenkapi.

Structured analysis, information engineering dan object-oriented analysis merupakan contoh pendekatan model (model-driven approaches). Model-driven analysis menitikberatkan pada penggunaan gambar dalam mereprentasikan model system untuk mendokumentasikan dan menvalidasi keadaan system yang sekarang berlaku dan usulan system yang diajukan. Pada akhirnya, model system ini akan menjadi denah untuk proses perancangan perbaikan system. Model adalah representasi dari kenyataan dan visi. Sebagian besar model menggunakan gambar untuk merepresentasikan masalah nyata atau visi. Karena satu buah gambar dapat berarti ratusan kata. Beberapa model yang sudah umum digunakan antara lain flowcharts, structure chart, dan organization chart. Sekarang ini, pendekatan model selalu digunakan dalam merepresentasikan berbagai masalah. Beberapa analis menggambar model dari suatu system cukup menggunakan software grafik umum seperti Visio Professional atau Corel Flow. Sedangkan analis atau organisasi lain menggunakan software khusus seperti System Arcbitect, Visio Enterprise, Visible Analyst dan Rational ROSE. Software khusus tersebut menawarkan kelebihan dalam hal konsistensi dan kelengkapan analisis. Structured Analysis (SA) Structured Analysis adalah salah satu system pengendalian model dimana pendekatan

berbasis proses dilakukan untuk menganalisis system yang berlaku sekarang dan menganalisis kebutuhan bisnis dari system yang baru. Model yang digunakan berupa gambar yang menilustrasikan komponen-komponen system, yaitu proses beserta input, output dan filenya. Teknik pendekatan berbasis proses menitikberatkan pada elemen PROCESS dalam diagram blok yang terdapat pada framework system informasi yang digunakan. Seiring dengan berjalannya waktu, teknik ini berkembang dengan menyertakan DATA dan INTERFACE sebagai penekanan kedua. Namun, PROCESS tetap merupakan focus utama dari model system yang dihasilkan dalam structured analysis. Structured Analysis memiliki konsep yang sederhana. Analis system menggambar sebuah garis yang merupakan model proses yang disebut data flow diagram (DFD), yang melukiskan proses yang sekarang ada atau usulan proses dalam system bersama dengan input, output dan filenya. Pada akhirnya model proses ini akan menjadi rencana/rancangan bagi proses bisnis yang akan diimplementasikan dan program komputer yang akan dibuat. Perancangan ulang proses bisnis memberikan banyak manfaat bagi suatu organisasi atau perusahaan. Melalui perancangan ulang proses bisnis, suatu organisasi mencoba untuk mempelajari proses bisnis yang paling penting dan kritis dengan tujuan untuk meningkatkan produk yang dihasilkan, meningkatkan efisiensi, mengurangi biaya dan pemborosan. Model proses juga membantu organisasi untuk mevisualisasikan proses mereka dan pada akhirnya dapat mengurangi kerumitan struktur birokrasi organisasi tsb.

Information Engineering (IE) Information Engineering adalah pendekatan model yang berbasis data. Analisis sensitifitas proses digunakan sebagai teknik untuk merencanakan, menganalisis, dan merancang system informasi. Model IE berupa gambar yang mengilustrasikan dan menyelaraskan data dan proses system. Model data pada IE disebut dengan entity relationship diagram. Model proses IE menggunakan diagran alir data yang sama dengan yang digunakan pada SA. Kelebihan IE adalah kemampuannya untuk mengintegrasikan dan menyelaraskan model data dan proses. IE merupakan pendekatan berbasis data karena IE menekankan pada analisis kebutuhan akan data sebelum kemudian menganalisis kebutuhan proses dan interface. Hal ini dilakukan dengan pertimbangan bahwa data tidak sulit direncanakan dan diatur. Analis system biasanya membuat ERD untuk memodelkan data mentah terlebih dahulu untuk menggambarkan bagaiman data-data dikumpulkan, disimpan, digunakan dan dipelihara. IE dan SA, keduanya berusaha untuk menyesuaikan model data dengan model proses. Perbedaan keduanya hanya pada model mana yang dibuat pertama kali. IE membuat model data terlebih dahulu, sedangkan SA membuat model proses dulu. Analisis Berbasis Objek (Object-Oriented Analysis) Pada dasarnya kebanyakan metode analisis system memisahkan antara data dan proses. Walaupun SA dan IE telah melakukan usaha untuk menyelaraskan keduanya, namun usaha tersebut belum sepenuhnya berhasil. Analisis berbasis objek kemudian muncul dan digunakan untuk mengurangi batas pemisah abtara data dan proses. Seluruh data spesifik dan proses yang membuat, membaca, meng-update atau menghapus data-data tersebut diintegrasikan dan disebut dengan objek. Beberapa bahasa pemrograman yang berbasis objek ini antara lain adalah Visual Basic, C++, dan Powerbuilder. Object-Oriented Analysis (OOA) adalah teknik pemodelan yang mengintegrasikan antara data dan proses kedalam suatu kesatuan yang disebut dengan objek. Model OOA berupa gambar yang mengilustrasikan objek system dari berbagai macam persepsi. Dengan semakin dikenalnya OOA, kemudian muncul Unified Modeling Language (UML) yang menyediakan sintaks grafik untuk membuat model berbassi objek.

Accelerated Analysis Approaches

Accelerated analysis approaches menitikberatkan pada konstruksi prototype sehingga pengidentifikasian kebutuhan user dan bisnis untuk system baru dapat dilakukan dengan cepat.

Prototipe

adalah

model

system

dalam

skala

kecil,

tidak

lengkap

namun

dapat

merepresentasikan system yang sebenarnya. Prototipe disebut tidak lengkap karena di dalamnya tidak terdapat pemeriksaan kesalahan, validasi input data, factor keamanan. Namun, prototype memiliki kemampuan untuk mengidentifikasikan kebutuhan bisnis yang krusial. Accelerated analysis approaches menekankan pada INTERFACE pada framework system informasi dengan cara membuat konstruksi dan laporan. Terdapat 2 jenis accelerated analysis approaches yang umum digunakan, yaitu : a. Discovery prototyping, juga biasa disebut dengan requirements prototyping, digunakan untuk mengidentifikasikan kebutuhan bisnis user. Misalnya, sudah menjadi hal yang umum apabila seorang analis system menggunakan pengembangan software sederhana seperti Microsoft Access untuk membuat database sederhana secara cepat, menginput lembar laporan user dan contoh laporan untuk mendapatkan respon user apakah database dan laporan merepresentasikan kebutuhan bisnis atau tidak. Discovery prototyping diharapkan mampu mengurangi kekhawatiran user tentang tampilan hasil akhir dari prototype yang dapat berubah sepanjang proses system desain. b. Rapid Architecture Analysis, adalah suatu percepatan pendekatan analisis yang juga membangkitkan model system. Rapid Architecture Analysis mencoba untuk menurunkan model system dari system awal atau discovery prototype. c. Reverse Engineering Technology, membaca kode program dari database yang tersedia,program aplikasi dan atau user interface dan secara otomatis meng-generate model system yang ekivalen. Baik Model driven dan pendekatan analisis system prcepatan digunakan untuk mengekspresikan kebutuhan pengguna pada system yang baru baik sebagai model dan prototype. Tapi kedua pendekatan tersebut bergantung pada lebih dari satu kebutuhan untuk mengidentifikas dan mengatur kebutuhan-kebutuhan tersebut. Lebih jauh lagi Kebutuhan akan system bergantung pada kemampuan analis untuk untuk menemukan masalah dan kesempatan yang terdapat pada system tersebut ; Analis harus memiliki keahlian dalam mengidentifikasikan masalah, kesempatan dan kebutuhan. Maka dari itu, setiap pendekatan analisis siatem membutuhkan beberapa bentuk syarat-syarat penemuan. Syarat-syarat penemuan meliputi teknik-teknik yang akan digunakan oleh analis system untuk mengidentifikasi atau mengekstrak masalah dan solusi system yang dibutuhkan oleh komunitas pengguna (user). Penemuan Fakta merupakan teknik-teknnik klasik yang digunakan untuk mengumpulakan informasi mengenai masalah sistem, kesempatan solusi yang dibutuhkan dan prioritas. Teknik Penentuan Fakta meliputi : 1. Sample dari dokumen-dokumen, laporan, file, database dan memo. 2. Mencari literature yang relevan, benchmarking solusi-solusi yang lain, dan mengunjungi situs-situs.

3. Observasi system-sistem sekarang beroperasi dan lingkungan kerja. 4. Mewawancara manajer, user dan staff - staff teknik 5. Mensurvey manajemen dan komunitas pengguna. Perencanaan syarat-syarat penggabungan Teknik penemuan fakta klasik di atas tidak memberikan nilai. Dalam bemtuk klasik, teknik ini membuang waktu. Kemungkinan lain, syarat-syarat penemuan dan manajemen dapat di artikan teknik pertumbuahan/percepatan dengan menggunakan perencanaan syarat-syarat penggabungan. Teknik perencanaan kebutuhan bersama menggunakan fasilitas ruang kerja untuk mengumpulkan pemilik system, pengguna system , analis system dan beberapa designer system dan pembangun untuk secara bersama-sam memelakukan analisis system. Secara umum, JRP merupakan bagian dari Aplikasi Pengemabangan Bersama yaitu, teknik-teknik aplikasi keseluruhan dari seluruh proses pengembangan system. JRP menyediakan lingkungan kerja untuk mengpercepat pekerjaan analisis system dan kemampuan mendeliver. Dalam analisis sistem dibutuhkan partisipasi dari pemilik dan pengguna system. Selain itu, juga diperlukan fasilitator dengan kemampuan mediasi dan negosiasi yang baik untuk memastikan bahwa setiap kelompopk mendapatkan kesempatan yang sesuai untuk berkontribusi dalam pengembangan system. Salah satu aplikasi yang menarik dari metode analisis sistem adalah perancangan kembali proses bisnis. Perancangan kembali proses bisnis merupakan aplikasi dari metode analisis sistem untuk tujuan perubahan secara dramatis dan meningkatkan dasar-dasar proses bisnis dari suatu organisasi, informasi teknologi yang independen. Perhatian pada BPR didorong oleh penemuan bahwa kebanyakan sistem informasi dan aplikasi di terjadi secara otomatis dan proses nisnis yang tidak efisien. Beberapa projek BPR fokus pada semua proses bisnis tanpa memperhatikan otomasi mereka. Setiap proses bisnis sepenuhnya mempelajari dan menganalisis bottleneck, value return, kesempatan untuk mengeliminasi dan streamlining. Setiap proses bisnis telah di desain ulang, BPR mengambil kesimpulan dengan menilai bagaimana teknologi informasi dapat diimplementasi dengan cara yang terbaikuntuk meningkatkan proses bisnis. Hal ini dapat menndorong terbentuknya sistem informasi baru dan proyek pengembangan aplikasiuntuk mengimplementasi da mendukung proses bisnis yang baru. BPR juga dilengkapi oleh kinteks proyek pengembangan sistem informas. Ini merupakan cara yang tidak umum di proyek-proyek IS yang berbasis pada pembelian dan integrasi dari Software commercial of the shelf (COTS). Pembelian software ini biasanya menghendaki bisnis agar menyesuaikan proses bisnisnya pada software.

FASE PRE-ELIMINARY INVESTIGATION

Merupakan fasa pertama dalam proses pengembangan sistem. Dapat disebut juga initial phase, survey phase atau planning phase. Fase ini menitikberatkan pada cara pandang pemiliki sistem terhadap sistem yang telah ada, dimana pemilik lebih concern pada gambaran umum bukan

detail. Selanjutnya, mereka akan menentukan sumber-sumber mana yang akan dimasukkan ke dalam proyek. Piagam/ anggaran proyek mendefinisikan lingkup proyek, perencanaan metologi, standar dan sebagainya. Fasa investigasi pendahuluan meliputi hal-hal sebagai berikut : 1. Mendata masalah, kesempatan dan arah. 2. Menegosiasikan lingkup pendahuluan 3. Memperkirakan biaya proyek 4. Merencanakan proyek 5. Memperkenalkan proyek dan perencanaan.

Tugas 1.1 Mendata Masalah, Kesempatan dan Arah

Salah satu tugas yang terpenting dalam fasa investigasi pendahuluan adalah menetapakan dasar permaslahan, kesempatan atau arah yang dituju oleh proyek. Masing-masing hal ini harus mematuhi kepentingan, visibilitas, keuntungan nyata dan prioritas. Sebagai tambahan analisisdetail tidak relvan terhadap ini. Gambar 5. 8 merupakan contoh dokumen ringkasan masalah, kesempatan dan arah dalam : a. Keadaan Mendesak Pada waktu kapan masalah harus diselesaikan atau kapan kesempatan dan arah terealisasikan. b. Visibilitas Pada tingkat apa solusi atau sistem yang baru visible pada konsumen atau manajer. c. Keuntungan Seberapa besar solusi atau sistem akan meningkatkan pendapatan harian atau mengurangi biaya harian. d. Prioritas. berdasarkan jawaban di atas, apa yang menjasi prioritas bagi masing-masing maslah, kesempatan dan arah/ tujuan. e. Solusi yang mungkin Solusi yang mungkin dapat berupa : (1) Menginggalkan yang sudah baik (2) Memperbaiki dengan cepat (3) Perubahan kearah ang lebih modern dari sistem terdahulu (4) Mendesain ulang sistem terdahulu, (5) Mendesain sistem yang baru .

Tugas 1.2 Menegosiasikan Lingkup Pendahuluan

Lingkup mendefinisiakan batas-batas dari proyek. batsa tersebut merupakan aspek-aspek dalam bisnis mana yang akan atau tidak termasuk dalam proyek. Perencanaan proyek harus menetapakan lingkup pendahuluan. Lingkup dapat didefinisikan dengan cara sebagai berikut : a. Tipe data apa yang akan menggemabrkan sistem yang akan dipelajari. b. Proses bisnis apa yang yang termasuk dalam sistem yang akan dipelajari c. Seberapa perlu tampialn sistem bagi pengguna, lokasi, dan sistem lain.

Tugas 1.3 Memperkirakan Biaya Proyek

Pada tahap ini, analis sistem atau manajer proyek akan memimpin, kan tetapi, pemilik sistem termasuk sponsor eksekutif, manajer bisis unit, dan manajer sistem informasi akan membuat keputusan. Pada tahap ini, pekerjaan lanjutan yang telah didefinisiakn pada fasa investigasi awal dap dilanjutkan hanya apabila proyek tersebut menguntungkan.

Tugas 1.4 Merencanakan Proyek

Jika proyek sudah ditetapkan untuk dilanjutkan, maka perencanaan proyek dapat dilakukan berdasarkan hal-hal seperti : a. Perencanaan pendahuluan yang termasuk penjadwalan dan memenuhan sumber untuk seluruh proyek. b. Perencanaan detail dan penjadwalan untuk fasa proyek selanjutnya.

Tugas 1.5 Menyajikan Rencana dan Proyek

Steering body adalah komite bisnis eksekutif dan manajer sistem yang mempelajari dan memprioritaskan proposal proyek yang kompeten untuk menentukan proyek mana yang akan memberikan nilai terbaik bagi organisasi dan disetujui untuk pengembangan sistem yang berkelanjutan. Steering body terdiri dari professional dan manajer sistem noninformasi. Kebanyakan organisasi menetapkan para wakil presiden sebagai steering body. Terlepas dari perlu tidaknya persetujuan proyek dari steering body, peluncuran proyek secara formal dan mengkomunikasikan proyek, tujuan, dan jadwal kepada seluruh komunitas bisnis. Oleh karena itu, perlu diadakan project kickoff event dan intranet project website. Tugas ini dipicu oleh penyelesaian project plan. Problem statement dan scope tersedia pada penyimpanan data. Keluarannya adalah project charter berupa dokumen berisi berbagai elemen termasuk problem, kesempatan, arah, cakupan, metode,dll. Kecerdasan interpersonal dan kemampuan berkomunikasi efektif adalah kunci dalam tugas ini.

FASE ANALISIS MASALAH

Fase ini memberikan kesempatan kepada analis untuk lebih memahami masalah ,kesempatan, dan arah proyek. Tujuan fase analisis masalah adalah untuk mempelajari dan memahami domain masalah dengan baik dan menganalisis masalah, kesempatan, dan kendala. Fase ini terdiri dari beberapa tugas yaitu: 2.1 Mempelajari domain masalah 2.2 Analisis masalah dan kesempatan 2.3 Analisis proses bisnis (optional) 2.4 Menetapkan tujuan perbaikan sistem 2.5 Up-date project plan 2.6 Menyajikan temuan dan rekomendasi

Tugas 2.1 Mempelajari Domain Masalah

Dalam fase analisis masalah, mula-mula tim mempelajari sistem yang sekarang sedang berjalan. System owner, user, dan analis memiliki pemahaman yang berbeda terhadap sistem. Sangatlah penting untuk mempelajari domain masalah dimana terdapat problem bisnis, kesempatan, tujuan,dan kendala. Tugas tersebut dilaksanakan oleh project manager, difasilitasi oleh lead system analyst. Pembelajaran yang komprehensif harus melibatkan system owners dan users dari seluruh unit bisnis yang akan didukung sistem dan proyek. Analis bisnis dapat bertindak sebagai fasilitator untuk mendapatkan orang yang tepat untuk terlibat dan mempertahankan komunikasi yang efektif terhadap unit bisnis dan manajemen. Perancang dan pengembang sistem jarang terlibat dalam tugas ini kecuali untuk menentukan batasan teknik pada sistem yang ada. Tugas ini dipicu oleh izin untuk melanjutkan proyek dari fase preliminary investigation. Izin tersebut berasal dari system owner atau steering committee. Kunci input adalah project charter dan dokumentasi sistem saat ini yang mungkin berada pada tempat penyimpanan ( repository) dan library program. Dokomentasi sistem harus dicek dengan hati-hati karena tidak semua analis dan programmer rajin meng-update dokumen. Pemahaman terhadap problem domain harus didokomentasikan untuk verifikasi. Beberapa cara untuk mendokumentasikan problem domain: 1. Data Mendaftar segala yang berkaitan data penyimpnan sistem yang ada. Mendefinisikan hal-hal tersebut dalam istilah bisnis. Selainitu, perlu juag mendaftar semua laporan yang dihasilkan oleh sistem yang ada dan menggambarkan tujuan dan kegunaan laporan tersebut. 2. Proses Mendefinisikan kejadian bisnis diaman proses bisnis diimplementasikan. 3. Interface Mendefinisikan semua lokasi yangdisediakn oleh sisten dan semua pengguna pada setiap lokasi tersebut. Bentuk lain dari interface adalah sistem interface,yaitu interface yang sudah ada saat ini antar sistem informasi sekarang dan sistem informasi yang lain serta aplikasi komputer, dapat secara cepat didata dan digambarkan oleh staf sistem informasi. Untuk menghindari kecacatan analisis, model sistem berikut mungkin sesuai : DataModel data satu halaman sangat berguna untuk mentapkan peraturan dan kosakata. ProsesDiagram dekomposisi fungsional satu atau dua halaman harus dibuktikan cukup untuk mendapatkan FEEL dari proses sistem yang sekarang. Interfacediagram konteks atau diagram use-case satu halaman sangat berguna untuk mengilustrasikan input dan output sistem dengan organisasi lain, unit bisnis, dan sistem. Beberapa teknik dan keterampilan yang berguna untuk membangun pemahaman sistem diantaranya fact-findings teknik,JRP teknik.

Tugas 2.2 Analisis Masalah dan Kesempatan

Di samping mempelajari sistem saat ini, tim harus bekerjasama dengan system owners dan system users untuk menganalisis masalah dan kesempatan. Masalah dan kesempatan diidentifikasi lebih dulu pada fase preliminary investigation, tetapi masalah-masalh awal mungkin hanya gejala dari masalah-masalah lain yang tidak diketahui dengan benar oleh user. Analisis masalah yang sebenarnya termasuk keterampilan yang sulit dikuasai terutama bagi sistem analis yang belum berpengalaman. Menyelesaikan masalah lebih efektif jika menganalisis masalah sebenarnya sebelum menyatakan solusi yang mungkin. Para problem solver menganalisis masalah malalui sebab dan akibat. Analisis sebab akibat adalah suatu teknik dimana masalah dipelajari untuk menentukan sebab-sebab dan akibat-akibatnya.. Analisis sebab akibat membawa kepada pemahaman yang benar dan solusi yang lebih kreatif dan bernilai. Selain sistem analis, system owner dan user juga sebaiknya berpartisipasi aktif.

Tugas 2.3 Analisis Proses Bisnis

Tugas ini hanya sesuai untuk proyek atau pengembangan sistem business process redesign (BPR) yang memerlukan BPR yang signifikan.Pada proyek tersebut, tim diminta untuk memeriksa proses bisnis secara lebih detail untuk mengukur nilai tambah. Analis harus fokus pada prosees, bukan pada orang-orang yang menjalankan sistem tersebut dan mengingatkan setiap orang bahwa tujuan utama adalah utnuk mengidentifikasi kesempatan bagi perubahan fundamental bisnis yang akan memberikan keuntungan bisnis. Tugas analisis proses bisnis hanya bergantung pada beberapa pengetahuan mengenai domain masalah. Hasil dari tugas ini berupa model proses dan analisis proses. Model proses dapat berbentuk data flow diagram kecuali bila menunjukkan hal-hal berikut: 1. volume aliran data melalui proses 2. waktu respon pada setiap proses 3. delay atau bottleneck terjadi pada sistem Data proses analisis memberikan informasi tambahan seperti: 1. biaya setiap proses 2. nilai tambah setiap proses 3. konsekuensi atas menghilangkan proses

Tugas 2.4 Menetapkan Tujuan Perbaikan Sistem

Kriteria sukses dapat diukur dari tujuan. Tujuan (objective) adalah ukuran kesuksesan. Sesuatu yang ingin dicapai apabila sumberdaya mencukupi. Di samping tujuan, kita juga perlu mengidentifikasi kendala-kendala. Kendala adalah sesuatu yang akan membatasi fleksibilitas menghasilkan solusi sesuai tujuan. Dalam melaksanakan tugas ini, kita tidak berkaitan dengan teknologi. Tahapan tugas ini dipicu oleh analisis problem yang dilaksanakan pada tugas 2.2 dan 2.3. Untuk masing-masing

problem yang signifikan dan sudah diverifikasi, analis dan user harus mendefinisikan tujuan perbaikan sistem secara spesifik dan mengidentifikasi kendala-kendala.

2.5 Meng-update rencana proyek Perlu diingat bahwa jangkauan dari proyek merupakan target yang selalu berubah,karena itu jangkauan dapat semakin luas atau semakin sempit ukuran dan jangkauannya. pemahaman ini, maka disadari perlunya pembaharuan (update) rencana proyek. Tugas ini harus dikerjakan oleh manajer proyek, pemilik system dan seluruh tim dalam proyek. Analis dan pemilik system harus mempertimbangkan keseuaian antara tujuan dengan system yang dibuat karena mungkin terjadi bahwa system yang dibuat terlalu besar atau terlali kecil dan tidak sesuai dengan deadline yang ditetapkan. 2.6 Mempresentasikan hasil dan rekomendasi Langkah ini merupakan langkah untuk mengkomunikasikan hasil kepada business community. Presentasi ini harus difasilitasi oleh manajer proyek dan sponsor eksekutif, diikuti oleh semua tim dalam proyek dan terbuka bagi semua staff yang tertarik. Tugas ini dapat dilakukan dengan berbagai format seperti laporan, presentasi verbal, atau walkthrough (inspeksi dari auditor). Dalam menjalankan tugas pada langkah ini sangat diperlukan kemampuan berkomunikasi. Analis sistem harus mampu memberikan laporan formal sekaligus memperesentasikannya. Setelah melalui tahapan analisis masalah, salah satu keputusan dibawah ini harus diambil : menyetujui proyek sesuai dengan presentasi yang dilakukan untuk dilanjutkan ke tahapan analisis keperluan melakukan penyesuaian terhadap jangkauan, biaya, dan/atau jadwal dari proyek dan meneruskannya ke tahapan analisis keperluan membatalkan proyek yang dapat dikarenakan : a. kekurangan sumber daya untuk membangun system yang baru b. menarik kesimpulan bahwa permasalahan yang ada tidak signifikan untuk diselesaikan dengan membuat system baru c. menarik kesimpulan bahwa system baru tidak akan memberikan benefit yang sesuai dengan biaya yang dikeluarkan Berdasarkan

TAHAP ANALISIS KEPERLUAN

Analisa keperluan merupakan hal yang penting untuk diketahui. Seringkali terjadi kesalahan pada tahap analisa keperluan. Bila hal ini terjadi, sistem dan solusi yang dirancang walaupun baik tidak akan berguna karena tidak sesuai keperluan. Tahap analisis keperluan merupakan tahap menentukan keperluan bisnis untuk suatu system yang baru. Hal ini dilakukan dengan memfokuskan pada pertanyaan apa, dan bukan bagaimana. Tahap analisis keperluan terdiri dari langkah-langkah berikut : Mendefinisikan keperluan Menganalisis keperluan fungsional Menyalin dan melengkapi requirements Memprioritaskan keperluan Meng-update rencana proyek

3.1 Mendefinisikan keperluan Merupakan tahap inisiasi, dimana dilakukan pengidentikasian keperluan. Langkah ini sangat penting, karena kesalahan pada langkah ini dapat mengakibatkan banyak sekali error, kelalaian, dan konflik. Tahapan ini haruslah menerjemahkan tujuan menjadi functional dan non functional requirement. Functional Requirement, yaitu deskripsi dari aktivitas dan servis yang harus disediakan suatu system Non functional Requirement, yaitu deskripsi dari fitur-fitur lainnya, karakteristik, dan pembatas yang mendefinisikan suatu system memuaskan. Dalam bagian ini, jarang sekali diidentifikasi seluruh keperluan fungsional dan non fungsional secara keseluruhan, melainkan hanya berupa outline yang akan memberi batasan pemikiran dalam pengerjaan tahapan selanjutnya. Bagian ini menghasilkan draft tentang keperluan fungsional dan non-fungsional yang dapat dibuat dalam berbagai format. Salah satu contoh simple format, outline dibagi menjadi 4 logical section yaitu input, proses-proses, output, dan data yang dibutuhkan untuk mencapai tujuan. Format lainnya yang dapat digunakan adalah PIECES, JRP (Join Requirements Planning), dll. 3.2 Menganalisis functional requirement Analisis functional requirement perlu dilakukan agar requirement dapat diverifikasi dan dikomunikasikan baik pada audiens bisnis maupun pada audiens teknik. Ada dua pendekatan kepada dokumentasi dan validasi functional requirement yaitu system modeling dan prototyping. Logical System Model, menggambarkan apa suatu system itu atau apa yang suatu system tersebut harus lakukan bukan bagaimana suatu system akan diimplementasikan. Logical modell menggambarkan esensi persyaratan suatu system dan biasa disebut essential system models.

Logical model mengeksperikan requirement bisnis (atau terkadang logical design) , dan bukan solusi teknis. Secara teoritis, dengan berfokus pada logical design dari system, maka tim dalam proyek akan: Memisahkan masalah bisnis dengan solusi teknik Lebih mempertimbangkan cara baru dan berbeda untuk mengembangkan proses-proses bisnis Lebih mempertimbangkan solusi teknik alternative dan berbeda

Prototyping pada tahap ini serupa dengan yang digunakan pada tahapan analisis requirements. Discovery prototyping biasa digunakan dalam system pengembangan proyek, terlebih apabila terjadi kesulitan dalam memvisualisasikan keperluan bisnis. Requirement dianalisis untuk akurasi, urgensi, konsistensi, fleksibilitas, dan feasibilitas dan menghasilkan beberapa criteria. System modeling hamper selalu didasari peraturan mengenai kelengkapan, keakuratan dan konsistensi dari komponen yang dibuat ke dalam model. Tugas ini difasilitasi oleh system analis yang juga mendokumentasikan dan menganalisis hasil. Pengguna system merupakan pemberi input factual. Apabila functional requirements telah disetujui, maka analis dan pengguna dapat segera memngkonstruksi system model dan prototype. Dengan teknik model driven, dapat digunakan beberapa kombinasi dari model berikut : Data Meng-capture dan menyimpan data. Model data seperti entity relationship diagram digunakan untuk mendokumentasi dan menganalisa data keperluan untuk system baru secara mendetail. Process Model proses seperti data flow diagram digunakan untuk memodelkan pekerjaan melalui system, content yang mendetail dari input, output, dan file, dan detail logika dari tiap proses. Interfaces Model interface seperti context diagram dan use case diagram menggambarkan eksternal input output dari dan ke system, beserta sumber dan tujuannya. Kini, banyak system analis yang bereksperimen dengan object model sebagai alternative dari model data dan model proses. Untuk menganalisis keperluan dapat digunakan beberapa teknik berikut : Data, proses, dan teknik modeling tampilan, sangat penting untuk divisualisasikan secara grafis agar dapat dianalisa dengan baik. Mengkonstruksi dan menjaga system model menggunakan software-software diagramming untuk mendasari dokumentasi yang lebih detail. CASE tools dapat digunakan karena memberikan keuntungan yaitu dapat melakukan cek kelengkapan, kekonsistenan, dan kebenaran dari model system. Menggunakan teknik prototyping. Menggunakan fact finding techniques.

3.3 Menyalin dan melengkapi requirements Berdasarkan analisis yang masuk berdarakan kombinasi system model dan prototype, maka kemudian perlu dilakukan validasi keperluan. Apabila setiap requirement telah diverifikasi pada model atau prototype, maka tahapan ini lebih merupakan completeness check terhadap verifikasi tersebut. Requirements tracing merupakan suatu cara untuk memastikan bahwa draft requirements telah didefinisikan dalam suatu form. Hal ini dilakukan dengan cara menyalin system model atau prototype kepada fungsional requirement sebelumnya untuk memastikan bahwa semua fungsional requirement telah berada dalam model system. Sebagai tambahan untuk kelengkapan, perlu juga dilakukan asosiasi antara keperluan fungsional dan non-fungsional. Tugas ini difasilitasi oleh manajer proyek dan system analis. Pemilik system merupakan pemegang peranan kunci untuk memastikan kelengkapan dari spesifikasi keperluan. 3.4 Memprioritaskan requirement Prioritas keperluan berguna untuk mengetahui keperluan apa yang lebih penting dari yang lainnya sehingga perlu untuk diselesaikan. Hal ini dimaksudkan untuk meminimasi biaya. Pemrioritasan ini dapat dilakukan dengan suatu teknik yang disebut timeboxing. Timeboxing merupakan suatu teknik yang memberikan informasi mengenai fungsional system dan keperluan melalui versioning. Hasil dari timeboxing adalah bahwa prioritas dapat terlihat dan dimengerti dengan jelas. Tugas ini difasilitasi oleh sistem analis. Dalam pelaksanaannnya dibutuhkan informasi yang lengkap dan valid karena tidak mungkin memprioritaskan suatu kumpulan data yang tidak lengkap. Prioritas dapat diklasifikasikan berdasarkan kepentingan relatifnya. Mandatory Requirements Merupakan persyaratan yang harus dipenuhi oleh sistem yang paling minimalsekalipun karena tanpanya sistem tidak akan berguna sama sekali. Desirable Requirements Bukan merupakan persyaratan yang paling esensial, namun dapat menjadi esensial di versi sistem yang akan datang. 3.5 Meng-update rencana proyek Kembali mengingat bahwa jangkauan proyek merupakan target yang selalu berubah.Harus disaari bahwa terdapat kemungkinan bahwa system baru dapat lebih besar dari yang sebenarnya diharapkan. Apabila demikian,maka perlu kembali dilakukan penyesuaian pada jadwal,biaya, dan jangkauan proyek.

Tugas ini difasilitasi oleh manajer proyek, pemilik system dan seluruh tim dalam proyek. Analis dan pemilik system harus mempertimbangkan kemungkinan bahwa keperluan yang dianalisis lebih besar daripada yang ditetapkan sebelumnya. Apabila demikian, maka jangkauan proyek perlu dipersempit agar terdapat keseuaian dengan deadline dan budget.

Manajemen Kebutuhan
Ekonomi sekarang ini telah meningkat sangat cepat. Bisnis diukur pada kemampuan mereka untuk beradaptasi secara cepat kepada perubahan yang konstan pada kebutuhan dan peluang. Manajemen kebutuhan didefinisikan sebagai sebuah proses bagi pemilik, pengguna, analis, perancang, dan pengembang sistem untuk mengajukan usulan perubahan pada sebuah sistem

FASE ANALISIS KEBUTUHAN

Fase Analisis Keputusan mengidentifikasi kandidat-kandidat solusi, menganalisis setiap kandidat solusi, dan merekomendasikan sebuah target sistem yang akan dirancang, dibangun, dan diimplementasikan. Sistem informasi building blocks dapat memberikan kerangka bekerja yang berguna pada fase analisis keputusan. Building block mengindikasikan target kita dalam mengembangkan sebuah propolsal yang akan memenuhi permintaan. Hasil akhir yang dapat disampaikan ialah untuk membuat propolsal sebuah sistem yang dapat memenuhi kebutuhan bisnis yang telah diidentifikasi pada fase sebelumnya. Fase analisis keputusan mencakup tugas-tugas berikut : 1. Identifikasi Kandidat solusi. 2. Analisis kandidat solusi. 3. Membandingkan kandidat-kandidat solusi. 4. Meng update rencana proyek. 5. Merekomendasikan sebuah solusi.

Tugas 4.1_Identifikasi Kandidat solusi

Kebutuhan akan bisnis telah diberikan pada fase definisi dari analisis sistem , pertama kita harus mengidentifikasi terlebih dahulu kandidat solusi. Beberapa kandidat solusi akan diposkan pada ide rancangan dan opini dari pemilik dan pengguna sistem. Yang lainnya dapat berasal dari berbagai macam sumber termasuk analis sistem dan analis rancangan, konsultan teknis, dan lain-lain. Analis sistem memfasilitasi tugas ini. Sumber ide dan opini dapat berasal dari pemilik dan pengguna sistem, perancangan dan pengembang sistem (mis. Database administrators, network administrators, technology architects, dan programmer). Di samping tim proyek, baik sumber internal dan eksternal

dapat menghasilkan ide dan opini. Setiap ide yang dihasilkan telah matang untuk dijadikan sebagai kandidat solusi untuk kebutuhan bisnis. Sejumlah informasi mendeskripsikan karakteristik dari setiap kandidat solusi yang bisa meliputinya. Matriks kandidat merupakan alat yang berguna dalam memenangkan secara efektif, mengorganisasikan, dan membandingkan karakteristik dari kandidat solusi yang berbeda.

Tugas 4.2_Analisis Kandidat Solusi

Setiap kandidat solusi sistem harus dianalisis kefisibelannya. Ini dapat terjadi setelah setiap kandidat diidentifikasi. Analisis fisibilitas seharusnya tidak terbatas pada biaya dan manfaat. Pada umumnya analisis mengevaluasi solusi pada empat kriteria : Fisibilitas teknis. Fisibilitas operasional. Fisibilitas ekonomi; Fisibilitas jadwal. Ketika menyelesaikan tugas ini, analis dan pengguna hati-hati untuk tidak membandingkan para kandidat. Analisis fisibilitas menunjukkan setiap kandidat tanpa berhubungan dengan fisibbilitas kandidat yang lain. Pendekatan ini tidak meyakinkan para para analis dan pengguna dari pengambilan keputusan yang terlalu dini berkaitan dengan kandidat mana yang terbaik. Setiap analisis fisibilitas dari tiap kandidat disimpan di dalam untuk kemudian dibandingkan dengan kandidat yang lain.

Tugas 4.3_Membandingkan Kandidat Solusi

Setelah analisis fisibilitas tiap kandidat solusi telah selesai, kita dapat membandingkan dan memilih satu atau beberapa solusi untuk direkomendasikan kepada pemilik dan pengguna sistem.Solusi yang dipilih ini merupakan yang terbaik di antara semua kombinasi teknik dari teknik, operasionel, ekonomi, dan fisibilitas jadwal. Jarang sekali ada satu kandidat yang terbaik dari semua kriteria. Sekali lagi, analis sistem memfasilitasi tugas ini. Perancang dan pengembang sistem seharusnya bisa menjawab setiap pertanyaan kefisibilitasan. Tapi pada akhirnya, pemilik dan pengguna sistem yang berrwenang untuk menjalankan analisis akhir dan rekomendasi. Sebuah matriks dapat digunakan untuk mengkomunikasikan informasi dalam julah besar mengenai para kandidat solusi. Matriks fisibilitas memungkinkan membandingkan setiap sisi perbedaan analisis fisibilitas dari sejumlah kandidat. Hasil dari tugas ini adalah rekomendasi solusi. Jika terdapat lebih dai satu solusi harus dibuat prioritasnya.

Tugas 4.4_Meng-update Rencana Proyek

Berdasarkan rekomendasi solusi kita seharusnya mengevaluasi kembali jangkauan rencana proyek dan meng-update sesuai dengan itu. Tugas ini merangsang penyelesaian solusi yang akan direkomendasikan. Jadwal proyek terakhir dan penetapan tugas harus ditinjau kembali dan di-update. Rencana proyek yang di-update merupakan kunci dari output. Rencana yang telah di-update seharusnya sekarang telah mencakup sebuah rencana detail dari fase rancangan sistem yang akan diikuti.

Task 4.5_Rekomendasi sebuah solusi

Manajer proyek dan eksekutif sponsor harus turut memfasilitasi tugas ini. Partisipan yang lain harus termasuk ke dalam seluruh tim proyek, termasuk menempatkan pemilik, pengguna, analis, perancang, dan pengembang sistem. Seperti biasanya, pertemuan ini harus terbuka kepada setiap staff dari komunitas bisnis. Tugas ini diransang oleh penyelesaian dari rencana poyek. Target dari solusi sistem diformat ulang untuk mempresentasikan sebagai sebuah propolsal sistem. Formatnya bisa sebuah laporan, persentasi verbal, atau inspeksi oleh auditor atau sesama group. Outline dari penulisan laporan adalah sebagai berikut : I. Pendahuluan A. Tujuan Laporan B. Latar Belakang Proyek C. Jangkauan proyek D. Struktur Laporan II. Alat dan Teknik yang Digunakan III. Kebutuhan Sistem Informasi IV. Solusi Alternatif dan Analisis Fisibilitas V. Rekomendasi VI. Daftar Pustaka Keterampilan komunikasi dan interpersonal sangat penting untuk tugas ini. Soft skill seperti salesmanship dan kemampuan mempengaruhi menjadi penting. Analis siatem harus bisa menuliskan laporan bisnis yang formal dan membuat presentasi bisnis tanpa masuk ke masuk ke permasalahan tekis dan alternatif.

GENERASI BERIKUTNYA DARI ANALISIS SISTEM

CASE teknologi akan terus berkembang, membuat kita lebih mudah untuk memodelkan kebutuhan sistem. Pertama, CASE tools akan mencakup pemodelan obyek untuk mendukung munculnya teknik analisis yang berorientasi pada objek. Sementara itu beberapa CASE tools secara murni berorientasi pada objek, kita yakin bahwa permintaan untuk tipe model pendukung yang lain (mis. Pemodelan data untuk database dan pemodelan proses untuk BPR), akan menempati CASE tools ayng komprehensif yang dapat mendukung banyak model. Kedua, kemunduran dari rekaasa teknologi dalam CASE tools akan berlanjut untuk mengembangkan kemampuan kita untuk lebih cepat menghasilkan draft pertama model sistem dari database yang ada dan program aplikasi. Analisis yang berorientasi pada objek akan pada akhirnya menggantikan analisis struktur dan rekayasa informasi sebagai praktek terbaik bagi analisis sistem. Perubahan ini mungkin tidak terjadi secepat yang diinginkan, tapi akan terjadi semua terlalu cepat pada sebuah generasi dari analis sistem yang memiliki keahlian pada metode lama. Ada sebuah kesempatan besar akan tetap kuat bagi analis yang tahu proses memodelkan yang akan terus digunakan bagi rancangan database. Kita juga memprediksikan prpolsal sistem akan terus lebih menarik. Seperti internet, ecommerce, dan e-business akan semakin menembus ke dalam perekonomian kita, anali sistem akan menawarkan alternatif baru untuk masalah lama. Akan ada perubahan mendasar dalam bisnis dan sistem informasi untuk menggunakan teknologi baru ini. Satu hal yang tidak akan berubah. Kita kan terus membutuhkan analis sistem yang mengerti bagaimana penyelidikan mendasar dan menganalisis permasalahan bisnis dan mendefinisikan logika kebutuhan bisnis sebagai pengantar perancangan sistem. Tetapi yang akan kita semua harus lakukan ialah meningkatkan kecepatan dan ketepatan untuk mencapai akselerasi jadwal pengembangan sistem yang dibutuhkan langkah ekonomi yang lebih cepat di hari esok.

RANGKUMAN
1. Secara formal analisis sistem adalah pemotongan sebuah sistem ke dalam komonenkomponennya. Sebagai sebuah fase pemecahan masalah, ini mengawali perancangan sistem. Dengan menjunjung pengembangan sistem informasi, Sistem analisis adalah permulaan investigasi dari sebuah propolsal proyek, studi dan analisis masalah dari sistem yang ada, analisis kebutuhan dari sistem baru dan anlisis keputusan dari alternatif solusi untuk memenuhi kebutuhan. 2. Hasil dari analisis sistem disimpan di sebuah tempat penyimpanan untuk digunakan pada fase berikutnya dan proyek. 3. Ada beberapa strategi yang muncul untuk analisis sistem yang populer. Teknik ini dapat digunakan untuk kombinasi satu dengan yang lainnya. a. Teknik analisis Model-driven menekankan pada pengambaran dari gambar model sistem yang merepresentasikan realitas sekarang ini atau target visi sistem. 1) 2) Analisis struktur adalah teknik yang fokus pada pemodelan proses. Rekayasa informasi adalah teknik yang fokus pada pemodelan data.

3)

Orientasi objek adalah teknik yang fokus pada pemodelan objek dengan memperhatikan data dan proses yang akan berlaku pada data.

b. Pendekatan Analisis percepatan menekankan pada konstruksi dari model kerja dari sistem adalah sebuah usaha untuk mengakselerasi analisis sistem. 1) Penemuan pembuatan prototype adalah teknik yang fokus pada pembangunan skala kecil, subsistem fungsional untuk menemukan kebutuhan. 2) Analisis arsitektur mencoba secara otomatis menghasilkan model sistem. c. Baik model-driven dan pendekatan analisis percepatan sistem tidak saling bergantung pada kebutuhan penemuan teknik untuk mengidentifikasi atau menyaring masalah dan kebutuhan daripemilik dan pengguna sistem. 1) Fact-finding adalah proses formal dari menggunakan penelitian, wawancara, kuesioner, sampling, dan teknik yang lain untuk mengumpulkan informasi. 2) Teknik Joint Requirements planning(JRP) menggunakan fasilitas workshop untuk membawa bersama semua bagian yang menarik dan accelerate fact-finding. d. Perancangan ulang proses bisnis fokus pada penyederhanaan dan perampingan proses bisnis mendasar sebelum mengaplikasikan teknologi informasi pada proses itu. 4. Setiap fase pada analisis sistem (permulan investigasi, analisis maslah, analisis kebutuhan, dan analisis keputusan) dapat dimengerti dalam konteks dari sistem informasi building blocks data proses dan tampilan. 5. Fase permulaan investigasi menentukan keberhagaan dari proyek dan pembuatan rencana untuk menyelesaikan proyek itu dianggap berharga dari studi yang detail dan anlisis. Untuk menyelesaikan fase permulaan investigasi, analis sistem akan bekerja dengan pemilik dan pengguna sistem untuk : (a) daftar masalah, peluang, dan petunjuk/instruksi; (b) negosiasi pemulaan jangkauan; (c) menaksir keberhargaan proyek; (d) merencanakan proyek; (e) Memberikan proyek pada komunitas bisnis. Hasil dari fase permulaan investigasi adalah karakter proyek yang harus diakui oleh pemilik sistem dan atau pembuat keputusan. 6. Tujuan dari fase analisis masalah adalah untuk menjawab pertanyaan: Apakah masalah tersebut berharga untuk dipecahkan? Dan apakah sebuah sistem baru berharga untuk dibangun? Untuk menjawab pertanyaan ini, fase analisis masalah dengan teliti menganalisis masalah yang diduga dan peluang yang pertama diidentifikasi pada fase permulaan investigasi. Untuk menyelesaikan fase analisis masalah, analis akan terus bekerja denga pemilik siste, pengguna sistem, dan partisipan yang tepat akan : (a) mempelajari problem utama; (b) menganalisis masalah dan peluang dengan teliti; (c) pilihan, menganalisis proses bisnis; (d) membuat pengmbangan sistem objektif dan hambatan; (up-date rencana proyek; dan (f) membawa penemuan dan rekomendasi. Hasil dari fase analisis masalah adalah pengembangan sestem objektif. 7. Fase Analisis kebutuhan mengidentifikasi apa yang baru dari sistem adalah untuk melakukan tanpa pertimbangan dari teknologi,. Dengan kata lain, tetapkan kebutuhan bisnis untuk sistem baru. Seperti pada fase permulaan investigasi dan fase analisis masalah, analis secara aktif bekerja dengan pengguna dan pemilik sistem. Untuk menyelesaikan fase analisis kebutuha, analis dan partisipan yang tepat akan : (a) menetapkan kebutuhan; (b) menganalisis kbutuhan

fungsional menggunakan pemodelan sistem dan atau discovery prtotyping; (c) malacak dan melengkapi pernyataan kebutuhan; (d) membuat urutan prioritas kebutuhan; dan (e) meng-update rencana dan jangkauan proyek. Hasil dari fase analisis kebutuhan adalah pernyataan kebutuhan bisnis. Karena kebutuhan target yang bergerak tanp akhir, analisis kebutuhan juga mencakup tugas yang terus-menerus untuk memanaje perubahan pada kebutuhan. 8. Tujuan dari fase analisis keputusan adalah transisi proyek dari soal bisnis ke solusi teknis dengan mengindentifikasi, menganalisis, dan merekomendasikan sebuah teknis solusi sistem. Untuk menyelesaikan keputusan fase analisis, analis dan partisipan yang tepat akan : (a) menetapkan kandidat solusi; (b) analisis fisibilitas kandidat solusi (teknik, operasional, ekonomi, fisibilitas jadwal; (c) membandingkan kandidat solusi untuk memilih satu atau lebih kandidat solusi yang akan direkomendasikan; (d) update rencana proyek berdasarkan pada solusi yang direkomendasikan; dan (e) memberi dan mempertahankan target solusi. Hasi dari fase analisis adalah propolsal sistem.