PERANCANGAN MANAJEMEN PROYEK SISTEM INFO

PERANCANGAN MANAJEMEN PROYEK SISTEM INFORMASI

(Tinjauan Manajemen Resiko dalam Pembangunan Software Engineering)

( Dosen Pembimbing : Amirul Mukminin )

Disusun Oleh: Chandra Hilmawan

( 16160096 )

Fakultas Teknik Sistem Informasi

DAFTAR ISI

Daftar Isi ... I Kata Pengantar ...II BAB I PENDAHULUAN

Latar Belakang ...1.1 Rumusan Masalah ...1.2 Tujuan ...1.3 BAB II PEMBAHASAN

Apa Saja, Bagaimana Prinsip dan Konsep Desain Software...2.1 Penjelasan Tentang Metode Desain Perangkat Lunak...2.2 Pendekatan Yang Digunakan Dalam Desain...2.3 Manajemen Pengembangan Sistem ...2.4 Software Manajemen...2.5 Tata Kelola Pengembangan Software...2.6 BAB III PENUTUP

Kesimpulan ...3.1 Saran ...3.2 Daftar Pustaka

KATA PENGANTAR

Engineering” yang digunakan sangat luas dan berbagai forum publik lainnya. Diharapkan makalah ini dapat memberikan informasi kepada kita semua tentang “Manajemen Resiko dalam Pembangunan Software Engineering”. Saya menyadari bahwa makalah ini masih jauh dari sempurna, oleh karena itu kritik dan saran dari semua pihak yang bersifat membangun selalu Saya harapkan demi kesempurnaan makalah ini. Akhir kata, Saya sampaikan terima kasih kepada semua pihak yang telah berperan serta dalam penyusunan makalah ini dari awal sampai akhir. Semoga Allah SWT senantiasa meridhai segala usaha kita. Amin.

Bandung, 01 Mei 2018 Penyusun

( Chandra Hilmawan )

BAB I

PENDAHULUAN

A. Latar Belakang

tertentu. Manajemen resiko tradisional terfokus pada resiko-resiko yang timbul oleh penyebab fisik atau legal (seperti bencana alam atau kebakaran, kematian serta tuntutan hokum).

Manajemen resiko adalah rangkaian langkah-langkah yang membantu suatu perangkat lunak untuk memahami dan mengatur ketidak pastian (Roger S. Pressman).

Pada saat kita mengerjakan pengembangan perangkat lunak sering kita menghadapi berbagai situasi yang tidak nyaman seperti keterlambatan pengembangan atau pengeluaran biaya pengembangan yang melebihi anggaran. Hal ini dikarenakan kurang siapnya kita menghadapi berbagai kemungkinan resiko yang akan terjadi. Untuk itu perlu dilakukan identifikasi tindakan yang harus dilakukan untuk mencegah ataupun meminimalkan resiko tersebut.

Mengapa manajemen resiko itu penting? Sikap orang ketika menghadapi resiko berbeda-beda. Ada orang yang berusaha untuk menghindari resiko, namun ada juga yang sebaliknya sangat senang menghadapi resiko sementara yang lain mungkin tidak terpengaruh dengan adanya resiko. Pemahaman atas sikap orang terhadap resiko ini dapat membantu untuk mengerti betapa resiko itu penting untuk ditangani dengan baik.

B. Rumusan Masalah

Sesuai dengan latar belakang yang telah dikemukakan, dapat dirumuskan beberapa permasalahan , diantaranya ialah :

 Bagaimana cara manajemen resiko yang baik dalam pembangunan software engineering ?

C.Tujuan

Adapun tujuan dari pembuatan paper ini adalah :

 Memenuhi salah satu tugas mata kuliah Perancangan Manajemen Proyek Sistem Informasi.

 Agar mengetahui pengukuran resiko dalam pembangunan Seoftware Engineering.

BAB III

PEMBAHASAN

2.1 Apa saja, Bagaimana prinsip dan Konsep Desain Software Prinsip dan Konsep Desain

Tujuan : Menghasilkan suatu model atau representasi dari entitas yang kemudian akan dibangun

David [DAV95] memaparkan sekumpulan prinsip untuk desain software :

 Proses desain seharusnya tidak bertahan dari “tunnel vision”.  Desain harus dapat di trace ke model analisa.

 Desain seharusnya tidak menemukan/invent wheel.

 Desain harus “memperkecil jarak intellectual” antara software dan masalah-masalah pada dunia nyata.

 Desain harus mengeluarkan uniformity dan integrasi.  Desain harus terstruktur untuk mengakomodasi perubahan.

 Desain harus terstruktur untuk mendegradasi secara halus(degrade gently).  Desain bukan coding.

 Desain harus di-assessed untuk kualitas.

 Desain harus diulang untuk meminimalis kesalahan konsep.

Faktor kualitas eksternal: diobservasi oleh user. Faktor kualitas internal: penting untuk engineer.

Proses Desain Desain software

Sebuah proses iteratif dimana kebutuhan diterjemahkan ke sebauh “blueprint” untuk mengkonstruksi software. Desain direpresentasikan pada level atas abstraction.

Saat iterasi desain terjadi, perbaikan subsequent membawa ke representasi desain pada level abstraksi yang lebih bawah. Kualitas desain sangat penting.

Dua metode digunakan untuk mengecek kualitas: a) Tinjauan ulang teknis formal,

b) Desain walkthrough.

Tiga fitur umum sebuah desain yang baik dari McGlaughlin’s [McG91]:

 Desain harus mengimplementasikan semua kebutuhan(eksplisit/implisit)  Desain harus dapat dibaca dan dimengerti

 Desain harus menyediakan suatu gambar lengkap software pada aspek aspek data, fungsi dan perilaku.

Abstraction adalah gambaran dari fungsi suatu program. Gambaran ini bisa

bertingkat-tingkat. Tingkat yang paling atas adalah gambaran suatu fungsi program dengan menggunakan bahasa alami.

Pada tingkat terendah, menghasilkan abstraksi yang bersifat prosedural/ langkah perlangkah dengan menggunakan istilah yang teknis dan bisa diimplementasikan menjadi fungsi

program.contoh :

Program : Iklan Part-time Job Fungsi : Pendaftaran calon part-timer

Abstraction 1 (highest level) : Calon part-timer dalam melakukan upload syarat-syarat yang diperlukan untuk melamar: surat lamaran, CV, foto, transkrip, data diri.

Abstraction 2 (lower level) : Procedural abstraction :

1. Tampilkan pilihan part-time job 2. Input data

3. Verifikasi format

Refinement

Penjelasan detil dari abstraction refinement membantu designer untuk memperlihatkan detil dari lowest level dari abstraction. Abstraction dan refinem ent merupakan konsep yang saling melengkapi.

Konsep Desain – Modularity

Software dibagi komponen dengan nama dan alamat yang berbeda, disebut modul. Meyer [MEY88] mendefenisikan empat kriteria yang memungkinkan kita mengevaluasi sebuah metode desain.

 Modular composability : Sebuah metode desain memungkinkan komponen desain yang telah ada dirakit ke sebuah sistem baru.

 Modular continuity : Perubahan kecil terhadap kebutuhan sistem menghasilkan perubahan pada tiap modul, dibanding perubahan system-wide.

 Modular protection : Sebuah kondisi aberrant terjadi dalam sebuah modul dan efeknya di-constrain dalam modul.

2.2. Penjelasan tentang Metode Desain Perangkat Lunak

Langkah - Langkah Untuk Mendesain Suatu Perangkat Lunak

Metode Desain

Metode Desain merupakan proses multi langkah di mana representasi struktur data, struktur program, karakteristik interface, dan detail prosedur disintesis dari persyaratan informasi.

Metode yang dibutuhkan untuk membuat masing – masing lapisan model desain (desain data -> desain interface ->desain arsitektural ->desain prosedural).

Sasaran -> memberikan suatu pendekatan sistematis bagi penarikan desain – cetak biru untuk membangun suatu PL ( Perangkat Lunak ).

Penting Dalam Metode Desain Perangkat Lunak :

 Desain data  Pedoman desain interface  Desain prosedural

Desain Arsitektur adalah

Membentuk struktur program dan struktur data dengan menentukan interface yg memungkinkan data mengalir melalui program

Kontributor -> konsep desain awal yg menekankan pd modularitas, desain top-down dan structural programming

Area aplikasi ->semua PL dapat direpresentasikan o/ suatu DAD, maka metode desain yg menggunakan diagram dpt secara teoritis diaplikasikan pd pengembangan PL.

Proses Desain Arsitektur

Desain yang berorientasi pada aliran data merupakan suatu metode desain arsitektur yg mengijinkan transisi yg baik dari model analisis ke deskripsi desain dari struktur program Transisi dari aliran informasi (DAD):

Tipe aliran informasi dibangun

 Batas aliran diindikasikan

 DFD dipetakan ke dalam struktur program  Hirarki kontrol ditentukan dengan pemfaktoran

 Struktur resultan disaring dengan menggunakan pengukuran desain

Pemetaan Transformasi

Serangkaian langkah desain yg mengijinkan sebuah DFD dengan karakteristik aliran informasi untuk dipetakan ke dalam template yg telah ditentukan sebelumnya untuk struktur program.

Langkah 1 : Kajilah model sistem fundamental (mencakup DFD tingkat 0 dan informasi yg mendukung)

Langkah 2 : Kajilah dan saring diagram aliran untuk Pl tsb (lanjut ke DFD tingkat2)

Langkah 3 : Tentukan apakah DFD memiliki karakteristik aliran transformasi dan transaksi (DFD tingkat 3)

Langkah 4 : Isolasi pusat transformasi dengan mengkhususkan batas aliran masuk dan keluar Langkah 5 : “pemfaktoran tingkat pertama” (pemfaktoran menghasilkan struktur program di mana modul tingkat puncak membuat keputusan, modul bawah melakukan kerja input, komputasi, input dan menengah menjalankan beberapa kontrol dan sejumlah kerja)

Langkah 6 : Lakukan pemfaktoran tingkat 2, dengan memetakan transformasi (gelembung) individual dari suatu DFD ke dalam modul2 yg sesuai dlm struktur program

Langkah 7 : Saringlah struktur program iterasi pertama dengan menggunakan heuristik desain bagi kualitas PL yg telah ditingkatkan.

2.3. Pendekatan yang Digunakan Dalam Desain

Pendekatan sistem yang diterapkan dalam pembelajaran bukan saja sesuai dengan perkembangan ilmu pengetahuan dan teknologi, tetapi juga sesuai dengan perkembangan dalam psikologi belajar sistematik, yang dilandasi dengan prinsip-prinsip psikologi

behavioristik dan humanistik. Aspek-aspek pendekatan sistem pembelajaran, meliputi aspek filosofis dan aspek proses. Aspek filosofis ialah pandangan hidup yang melandasi sikap si perancang, sistem yang terarah pada kenyataan. Sedangkan aspek proses ialah suatu proses dan suatu perangkat alat konseptual.

Ciri-ciri pendekatan sistem pembelajaran, yaitu ada dua ciri utama, yakni :

 Pendekatan sistem sebagai suatu pandangan tertentu mengenai proses pembelajaran dimana berlangsung kegiatan belajar mengajar, terjadinya interaksi antara siswa dan guru, dan memberikan kemudahan bagi siswa untuk belajar secara efektif.

2.4. Manajemen Pengembangan Sistem

Proses software engineering berkaitan selalu dengan 2 faktor utama :

 Quality

Kualitas / quality adalah nutu suatu barang yang disepakati antara supplier dan customer, mutu tersebut mencakup QCDSM.

Quality : Kualitas produk. Cost : Biaya produk.

Delivery : Ketepatan waktu pengiriman. Safety : Keamanan produk

Moral suatu produk.

 Manajemen keseluruhan proses

2.5. Software Manajemen

Software untuk manajemen proyek masuk yang ada diperusahaan, sehingga pemilik (owner) bisa mengetahui dengan mudah apa saja proyek yang sedang ditangani, proyek yang belum selesai, dan proyek yang sudah selesai. dan bisa melihat profit perusahaan tiap

bulannya.

Ruang Lingkup Rekayasa Perangkat Lunak( Software Engineering )

 Software Requirements berhubungan dengan spesifikasi kebutuhan dan persyaratan perangkat lunak.

 Software desain mencakup proses penampilan arsitektur, komponen, antar muka, dan karakteristik lain dari perangkat lunak.

 Software construction berhubungan dengan detail pengembangan perangkat lunak, termasuk. algoritma, pengkodean, pengujian dan pencarian kesalahan.

 Software testing meliputi pengujian pada keseluruhan perilaku perangkat lunak.  Maintenance mencakup upaya-upaya perawatan ketika perangkat lunak telah

 Software configuration management berhubungan dengan usaha perubahan konfigurasi perangkat lunak untuk memenuhi kebutuhan tertentu.

 Software engineering management berkaitan dengan pengelolaan dan pengukuran RPL, termasuk perencanaan proyek perangkat lunak.

 Software engineering tools and methods mencakup kajian teoritis tentang alat bantu dan metode RPL.

Rekayasa Perangkat Lunak dan Disiplin Ilmu Lain

Cakupan ruang lingkup yang cukup luas, membuat RPL sangat terkait dengan disiplin dengan bidang ilmu lain. tidak saja sub bidang dalam disiplin ilmu komputer namun dengan beberapa disiplin ilmu lain diluar ilmu komputer.

 Bidang ilmu manajemen meliputi akuntansi, finansial, pemasaran, manajemen operasi, ekonomi, analisis kuantitatif, manajemen sumber daya manusia, kebijakan, dan strategi bisnis.

 Bidang ilmu matematika meliputi aljabar linier, kalkulus, peluang, statistik, analisis numerik, dan matematika diskrit.

 Bidang ilmu manajemen proyek meliputi semua hal yang berkaitan dengan proyek, seperti ruang lingkup proyek, anggaran, tenaga kerja, kualitas, manajemen resiko dan keandalan, perbaikan kualitas, dan metode-metode kuantitatif.

2.6. Tata Kelola Pengembangan Software

Tata kelola TI pada dasarnya berfokus pada dua hal yaitu bagaimana TI memberikan nilai tambah bagi bisnis dan penanganan risiko pada implementasi (TI ITGI 2006).

Dari gambar di atas kita bisa menarik kesimpulan bahwa dalam pelaksanaan tata kelola teknologi informasi pada suatu organisasi, digerakkan oleh pemberian nilai tambah bagi stakeholder. Misal: Pengembangan teknologi informasi harus dapat memberikan jaminan keakurasian dan ketepatan waktu Laporan Manajemen. Atau pengembangan teknologi

informasi harus dapat mengurangi kemungkinan adanya fraud. Dalam pendapat pribadi saya, pemberian nilai tambah inilah yang sebenarnya akan membuat stakeholder mau melirik ke program-program kerja yang terkait implementasi TI. Utamanya pihak manajemen puncak. Karena biasanya pihak manajemen puncak lah yang pada ujungnya akan mempertanyakan return of investment dari biaya-biaya yang dikeluarkan dalam implementasi TI. Mereka biasanya melihat IT sebagai cost center karena terkadang implementasi TI belum berhasil menunjukkan dampak penurunan biaya atau pun meningkatkan laba.

Pemberian nilai tambah ini akan sangat beresiko jika tidak dikelola dengan baik. Karenanya-lah perlu adanya Manajemen Resiko yang bertujuan untuk menghindari kegagalan

Selanjutnya, tak kalah pentingnya juga perlunya manajemen sumber daya untuk

mengoptimalkan pengetahuan (knowledge) dan infrastruktur teknologi informasi. Sumber daya ini jangan hanya dilihat dari sisi software dan hardware saja lho ya, namun juga brainware (manusia, baik karyawan TI maupun user yang akan terlibat dalam implementasi TI).

Dari berbagai uraian di atas, kita dapat menggarisbawahi bahwa Tata Telola Teknologi Informasi adalah bagian dari tata kelola perusahaan yang terfokus pada penanganan

implementasi TI dan penyelarasan sistem teknologi informasi (TI) dengan tujuan perusahaan agar dapat memberikan nilai tambah bagi perusahaan. Sehingga topik yang muncul di sini tidak hanya software, hardware, dan orang saja, namun juga manajemen proyek TI, penyusunan rencana anggaran dan biaya TI, manajemen risiko TI, IT Policy, dan masih banyak lagi.

Di masa lalu, penanganan pengambilan keputusan bidang teknologi informasi dan

pengembangan proyek TI di perusahaan dilakukan para profesional TI di organisasi tersebut. Sebenarnya tidak hanya di masa lalu sih, tapi di masa kini pun masih banyak perusahaan yang menitikberakan keputusan mengenai TI hanya pada Departemen TI.

MACAM-MACAM MODEL PENGEMBANGAN SOFTWARE

Secara prinsip metode pengembangan perangkat lunak bertujuan untuk membantu menghasilkan perangkat lunak yang berkualitas. Berikut faktor-faktor yang perlu di cermati dalam pengembangan perangkat lunak.

luas yang menyangkut analisis kebutuhan, konstruksi program, desain, pengujian, dan pemeliharaan.

Pengembangan sistem dapat berarti menyusun suatu sistem yang baru untuk menggantikan sistem yang lama secara keseluruhan/memperbaiki sistem yang telah ada. Sistem yang lama perlu diperbaiki atau diganti disebabkan karena beberapa hal, yaitu :

 Adanya permasalahan-permasalahan (problems) yang timbul di sistem yang lama.  Untuk meraih kesempatan-kesempatan (opportunities).

 Adanya instruksi-instruksi (directives).

Metode Pengembangan Perangkat Lunak

Adapun metode pengembangan perangkat lunak yaitu :

 Model Sekuensial Linier / Waterfall Method  Model Prototipe

 Model RAD (Rapid Application Development)  Model Spiral

BAB III

PENUTUP

3.1. Kesimpulan

Secara sederhana sistem dapat diartikan sebagai suatu kumpulan atau himpunan dari unsur atau variabel-variabel yang saling terorganisasi, saling berinteraksi, dan saling bergantung satu sama lain Informasi yang berkualitas memiliki 3 kriteria, yaitu:

 Tepat pada waktunya (timeliness) Informasi yang datang pada penerima tidak boleh terlambat.

 Relevan (relevance) Informasi yang disampaikan harus mempunyai keterkaitan dengan masalah yang akan dibahas dengan informasi tersebut.

3.2 Saran

Menurut saya, model proses perangkat lunak masih menjadi objek penelitian, tapi sekarang ada banyak model umum atau paradigma yang berbeda dari pengembangan

perangkat lunak. Karena banyaknya variasi dalam model proses yang digunakan maka tidak mungkin menghasilkan gambaran-gambaran yang reliabel untuk alokasi biaya dalam

aktivitas-aktivitas ini.

DAFTAR PUSTAKA

Bibliography

Informatika, B. S. (2018, 05 01). Ruang Mahasiswa Universitas BSI Bandung. Retrieved from students.ubsi.ac.id:

http://students.ubsi.ac.id/jadwal_kuliah.aspx

Priambada, W. G. (2015, 05 06). Tata Kelola Teknologi Informasi. Retrieved from wisnuajix.wordpress.com:

https://wisnuajix.wordpress.com/2015/05/06/tata-kelola-teknologi-informasi-poin-penting-yang-kadang-terlupa/