IEEE 830-1998

IEEE 830-1998 merupakan SRS (Software Requirements Specification) adalah standarisasi pembuatan dokumen dari hasil analisis pengembangan konteks perangkat lunak atau disebut juga SKPL(Spesifikasi Kebutuhan Perangkat Lunak).

Spesifikasi Persyaratan Software (SRS) adalah deskripsi lengkap tentang perilaku sistem yang akan dikembangkan. Ini mencakup satu set kasus penggunaan menggambarkan semua interaksi pengguna akan memiliki dengan perangkat lunak. Selain menggunakan kasus, SRS juga berisi persyaratan non-fungsional (seperti kinerja rekayasa, kualitas standar, atau kendala desain).

Sebuah organisasi umum dari SRS adalah sebagai berikut :

• Pengantar
• Tujuan
• Cakupan
• Definisi
• Sistem Ikhtisar
• Referensi
• Keseluruhan Keterangan
• Produk Perspektif
• Produk Fungsi
• Karakteristik Pengguna
• Kendala, Asumsi dan Dependensi
• Persyaratan Spesifik
• Eksternal interface
• Fungsi
• Persyaratan kinerja gf
• Database logis persyaratan
• Desain kendala
• Fitur utama

Karakteristik dari SRS yang benar adalah sebagai berikut :

1.    Benar

SKPL dianggap benar jika dan hanya jika setiap kebutuhan yang tercantum dalam

dokumen adalah kebutuhan yang akan dipenuhi oleh perangkat lunak. Tidak ada kakas

(tools) atau prosedur yang dapat menjamin kebenaran. Untuk memverifikasinya,

SKPL harus diperbandingkan dengan spesifikasi-spesifikasi yang mendahuluinya

                (misalnya kontrak, request for proposal, system specification, dan lain-lain). 

2.    Tidak ambigu

SKPL tidak ambigu jika dan hanya jika setiap kebutuhan yang ditetapkan hanya

                memiliki satu interpretasi

3.    Lengkap

SKPL adalah lengkap jika dan hanya jika sudah melibatkan elemen-elemen berikut:

-          Semua kebutuhan-kebutuhan penting sudah tercakup (fungsionalitas, performansi,

batasan perancangan, atribut atau antar muka eksternal). Jika ada spesifikasi lain

yang telah menguraikan kebutuhan eksternal dari perangkat lunak bersangkutan,

maka spesifikasi tersebut harus diacu atau dijadikan dasar (bila ada spesifikasi

tambahan)

-          Definisi semua jenis masukan pada berbagai situasi, baik untuk masukan yang

valid maupun tidak. 

-           Referensi yang lengkap dari setiap gambar, tabel dan diagram pada SKPL, dan

disertai dengan semua istilah yang digunakan dan unit yang digunakan sebagai

                pengukuran (bila ada).

4.    Konsisten

Yang dimaksud di sini adalah konsistensi internal. Jika suatu SKPL tidak mengacu ke

dokumen lain yang sifatnya memiliki tingkat lebih tinggi (lebih dahulu ada, atau

                secara sistem lebih luas cakupannya), maka SKPL tersebut tidak benar.

5.    Terurut berdasarkan kepentingannya atau kestabilannya

Suatu SKPL diurutkan berdasarkan tingkat kepentingan/kestabilan dari setiap

kebutuhannya. Hal tersebut dapat diberikan suatu tanda untuk menunjukkan

kepentingan atau kestabilannya. Umumnya semua kebutuhan yang berhubungan

dengan produk perangkat lunak tidak memiliki tingkat kepentingan yang sama.

Beberapa kebutuhan mungkin bersifat harus, khususnya untuk aplikasi yang kritis,

                sementara yang lain bersifat diinginkan.

Analisa Permodelan Berbasis Objek Dan Terstruktur

Pemodelan

Permodelan adalah paradigma pembuatan sebuah program.Agar pembuatan program dapat berjalan dengan lancar maka kita harus menentukan pemodelan pembuatan program terlebih dahulu.

Pengertian Pemrograman Berorientasi Objek

Pemrograman berorientasi objek atau object oriented programing (OOP) merupakan paradigma pemrograman yang berorientasikan kepada objek.Dimana terdapat berbagai class yang setiap class terdapat berbagai fungsi yang dapat menerima,memproses,mengeluarkan hasil proses dari fungsi tersebut.

Kelebihan Pemrograman Berorientasi Objek 

·         Pemrograman berbasis objek lebih efisien digunakan untuk pembuatan program rumit dan kompleks

·         Maintenance,program lebih mudah dibaca dan dipahami, karena mempunyai pola program class dan fungsi.

·         pengubahan program dapat dilakukan hanya dengan mengubah fungsi yang ingin di rubah slur prosesnya saja,jadi tidak mengubah fungsi2 yang lain

·         fungsi yang sama dapat digunakan dengan sesering mungkin.

Kekurangan Pemrograman Berorientasi Objek

Ø  Sintaks dan alur Pemrograman terstruktur sulit dimengerti oleng programmer lain.

Pengertian Pemrograman Terstruktur

Pemrograman Terstruktur adalah paradigama pembuatan program yang tersusun menurut langkah-langkah yang sudah untuk menyelesaikan masalah.Dan langkah-langkah tersebut dibuat secara seistematis,logis dan mudah dipahami.

Sifat Pemrograman Terstruktur

a. Memuat teknik pemecahan masalah yang logis dan sistematis
b. Memuat algoritma yang efisien, efektif dan sederhana
c. Program disusun dengan logika yang mudah dipahami
d. Tidak menggunakan perintah GOTO
e. Biaya pengujian program relatif rendah
f. Memiliki dokumentasi yang baik
g. Biaya perawatan dan dokumentasi yang dibutuhkan relatif rendah
Kelebihan Pemrograman Terstruktur

Ø  Pemrograman terstruktur lebih efisien digunakan untuk pembuatan program sederhana dan lebih murah dalam hal perawatan program nya

Kekurangan Pemrograman Terstruktur

Ø  Sintaks dan alur Pemrograman terstruktur sulit dimengerti oleng programmer lain.

Tabel Perbandingan Pemrograman Terstruktur dan Pemrograman Berorientasi Objek

Pemrograman Terstruktur	Pemrograman Berorientasi Objek
Ø  Serangkaian tugas diselesaikan dalam bentuk fungsi procedural Ø  Cara pandang program adalan suatu urutan instruksi Ø  Programmer harus mem breakdown suatu problem menjadi sub problem yang lebih simple Ø  Funsi dan procedure menjadi focus utama Ø  Fungsi dan procedure digunkan untuk memanipulasi data	Ø  Fungsi dan data bukan menjadi dua hal yang terpisah Ø  Fungsi dan data menjadi kesatuan yang disebut objek aktif Ø  Cara pandang program adalah serangkaian objek yang bekerja sama untuk menyelaikan suatu problem

 Kesimpulan

Tingkat efisiensi kedua pemodelan pemubuatan program tersebut sesuai dengan kasus yang dihapadai dan sudut pandang nya.jika kita ingin membuat program yang rumit dan komplek lebih efisien kita menggukan OOP,jika hanya program sederhana lebih baik menggunakn pemodelan terstruktur.Tetapi semua itu harus tetap disesuaikan dengan kebutuhan pemakai,anggaran,waktu dan sudut pandang yang lain.

Manajemen Proyek Sistem Informasi

Nama:Awalin Yudhana

NIM:321110006

Prodi:Sistem Informasi

1. PENDAHULUAN

Dalam pembuatan software aplikasi dengan kualitas yang bagus dan tinggi memerlukan sebuah manajemen proyek yang baik.Konsep manajemen proyek adalah tehnik-tehnik mengatur perencanaan dalam pembuaran software itu sendiri,baik penghitungan biaya dan kebutuhan sumber daya serta rencara pengerjaan proyek yang efektif.

2. MANAJEMEN

Definisi kata manajemen atau suatu seni dalam mengerjakan sesuatu untuk mencapai tujuan organisasi.

Ricky W. Griffin mendefinisikan manajemen sebagai sebuah proses perencanaan, pengorganisasian, pengkoordinasian, dan pengontrolan sumber daya untuk mencapai sasaran (goals) secara efektif dan efesien

3. Proyek

Proyek adalah sesuatu yang bersifat temporer dengan jangka waktu tertentu  dan dikerjakan untuk menghasilkan suatu produk dengan mutu yang sudah di di tentukan sebelumnya

4. Manajemen Proyek

Dalam dunia IT manajemen proyek  adalah suatu perencanaan pembuatan software aplikasi dengan tehnik-tehnik se-efisien mungkin,baik dari segi Biaya,Sumber Daya Manusia,dan Tehniknya.

5. Sasaran Proyek

Setiap proyek mempunyai 3 sasaran dan kendala yang harus di capai,yaitu:

·         Mutu,yaitu kualitas produk itu sendiri dengan acuan target yang sudah di gariskan pada awal perencanaan

·         Anggaran,yaitu sesuai anggaran biaya yang sudah di rencanakan,jadi meminimalisasi pembengkakan biaya

·         Waktu,yaitu pengerjaan software sesuai jadwal.Dalam hal ini pengerjaan per modul atau proses,ini bertujuan agar software aplikasi selesei tepat waktu

6. Struktur Manajemen Proyek

Bagian-Bagian dari manajemen proyek yang harus diperhatikan agar semua sasaran tercapai sesuai tujuan awal,yaitu:

1. People(Manusia)
2. Problem(Masalah)
3. Proccess(Proses)

6.1 People(Manusia)

Manusia sangat berperan penting dalam berlangsungnya manajemen proyek,unsur-unsur spektrum people yaitu:

1.  Pemain
2. Pimpinan Tim
3. Tim Perangkat Lunak
4. Organiser Tim
5. Koordinasi dan komunikasi

6.1.1. Pemain

Pemain adalah elemen-elemen yang harus di penuhi dan berfungsi sesuasi tugas nya

•  Manajemen senior,bertugas menentukan mendefinisikan masalah-masalah bisnis yang berpengaruh pada proyek tersebut
• Manajer Teknik,merencanakan,meng organisasi o,dan memotivasi orang-orang yang bekerja pada proyek tersebut
• Pelaksana,orang yang mempunyai kemampuan teknik untuk merekayasa sebuah produk atau aplikasi
• Pelanggan,orang yang membutuhkan produk atau aplikasi tersebut
• Pemakai Akhir,orang yang langsung berinteraksi dengan aplikasi tersebut

6.1.2. Pimpinan Tim

Dalam menjadi pimpinan tim harus mempunyai karakter sebagai berikut:

• Mampu melakukan pemecahan masalah
• Mempunyai rasa percaya diri untuk melakukan kontrol proyek
• Mampu mengoptimasi sebuah proyek(memiliki inisiatif dan prestasi)
• Memiliki pengaruh terhadap tim dan mampu membuat tim yang solid serta dapat mengusai diri meskipun dalam tekanan yang tinggi

6.1.3. Tim Perangkat Lunak

Ada beberapa cara penerapan Sumber daya manusia kepada sebuah proyek,antara lain:

·         beberapa orang mengerjakan tugas-tugas funsional yang berbeda,jadi manajer proyek harus mengkordinasi tim yang mungkin dia sedang memiliki beberapa proyek lain

·         beberapa orang mengerjakan tugas-tugas funsional yang berbeda,tetapi jumlah funsional tidak lebih dari jumlah orang.di sini dapat dibentuk ti satu tim ad hoc yang mengkordinasi,yaitu manajer perangkat lunak

·         beberapa Orang diatur didalam tim, setiap tim bertugas mengerjakan satu tugas  fungsional atau lebih, masing-masing tim memiliki sebuah struktur yang spesifik yang ditentukan untuk semua tim yang bekerja dalam sebuah proyek. Koordinasi disini dikontrol baik oleh tim itu sendiri maupun oleh seorang manajer proyek perangkat lunak.

6.1.4. Organiser Tim

Ada tiga organisasi tim yang umum,yaitu:

• Demokrasi terdesentralisasi (DD),Tim perekayasa perangkat lunak ini tidak memiliki pemimpin yang permanen. Tetapi koordinator dipilih untuk bertugas didalam durasi waktu yang pendek, yang kemudian diganti oleh yang lain yang mungkin bertugas untuk mengorganisasi tugas-tugas yang berbeda.keputusan terhadap masalah dan pendekatan yang dibuat oleh konsensus kelompok. Komunikasi diantara kelompok bersifat horisontal.

• Terkontrol terdesentralisasi (TD),Tim rekayasa perangkat lunak memiliki pemimpin tertentu yang mengkoordinasi tugas-tugas khusus serta memiliki pemimpin-pemimpin sekunder yang bertanggung jawab atas masalah sub-sub tugas. Pemecahan masalah merupakan aktivitas dari kelompok, tetapi implementasi dari pemecahan masalah dipecah diantara sub-sub kelompok oleh pimpinan tim. Komunikasi antar kelompok dan orang bersifat horisontal, tetapi komunikasi vertikal sepanjang hierarki kontrol juga terjadi disini.

• Terkontrol tersentralisasi (CC),Koordinasi pemecahan masalah tingkat puncak dan internal tim diatur oleh pimpinan tim. Komunikasi antara pimpinan dan anggota tim bersifat vertikal.

6.1.5. Koordinasi dan komunikasi

Beberapa teknik pengkoordinasian tim,yaitu:

• Pendekatan impersonal, formal

Mencakup penyampaian dan dokumen rekayasa perangkat lunak (seperti kode sumber), memo-memo teknis, kejadian penting pada proyek, jadwal dan peranti kontrol proyek, kebutuhan akan perubahan dan dokumentasi yang berhubungan, laporan pelacakan kesalahan, dan data cadangan.

• Prosedur interpersonal, formal

Berfokus pada aktivitas jaminan kualitas yang diterapkan kepada produk kerja rekayasa perangkat lunak. Hal ini menyangkut pertemuan status pengkajian serta perancangan dan inspeksi kode.

• Prosedur interpersonal, informal

Menyangkut pertemuan kelompok untuk penyebaran informasi dan pemecahan masalah.

• Komunikasi Elektronik

Mencakup surat elektronik, papan buletin elektronik, web sites, serta konferensi berbasis video.

• Jaringan interpersonal

Diskusi informal dengan orang-orang diluar proyek yang mungkin memiliki pengalaman atau pengetahuan yang dalam yang dapat mendukung anggota tim

6.2. Problem(Masalah)

Dalam manjamen proyek selalu melalakukan analisis kebutuhan perangkat lunak,sedangkan analisisi tersebut memerlukan waktu yang tidak sebentar,mungkin berminggu minggu maupun ber bulan bulan.kebutuhan perangkat lunak kadang berubah rubah,sehingga kita perlu menyusun atau memetakan masalah sejak awal proyek itu secara detail.

Pemetaan masalah di awali dengan :

1. Ruang Lingkup,dalam tahap ini terdapat 3 pertanyaan harus di jawab yaitu:

• Konteks, Bagaimana perangkat lunak yang akan dibangun dapat memenuhi sebuah sistem, produk, atau konteks bisnis yang lebih besar, serta batasan apa yang ditentukan sebagai hasil dari konteks  tersebut?
• Tujuan Informasi, Objek data pelanggan apa yang dihasilkan sebagai output dari perangkat lunak?Objek data apa yang diperlukan sebagai  input?
•  Fungsi dan unjuk kerja: Fungsi apa yang dilakukan oleh perangkat lunak untuk mentransformasi input data menjadi ouput?Adakah ciri kerja khusus  yang akan ditekankan?

     2.       Dekomposisi masalah,

adalah proses pembagian masalah yang kompleks menjadi sub masalah yang lebih kecil agar mudah di atasi

6.3. Procces(Proses)

·         Definition phase: fase dimana saat mengidentifikasikan sofware aplikasi seperti fungsi,perilaku,interface,design dan valisai sistem aplikasi itu sendiri
·         Develompent phase: fase dimana teknisi mendefinisakan kontruksi ,fungsi di implementasikan pembuatan software aplikasi
·         Maintenance phase:fase koreksi dan penyesuaian softwar aplikasi dengan lingkungan dimana software tersebut berkembang.Dalam tahap ini masih ada beberapa tahap lagi,yaitu:

1. Koreksi
2. Adaptasi
3. Perkembangan
4. Pencegahan

7. Aktifitas manajemen Proyek

1.  Komunikasi pelanggan : tugas-tugas yang diperlukan untuk membangun komunikasi yang efektif.
2. Perencanaan : tugas-tugas yang diperlukan untuk menentukan sumber daya, ketepatan waktu,  dan informasi proyek yang lain.
3.   Analisis resiko : tugas-tugas yang diperlukan untuk memperkirakan resiko-resiko manajemen dan teknis.
4. Rekayasa : tugas-tugas yang diperlukan untuk membangun suatu perwakilan aplikasi atau lebih.
5. Kontruksi dan rilis : tugas-tugas yang diperlukan untuk membangun, menguji, memasang dan memberikan dukungan kepada pemakai (seperti dokumentasi dan pelatihan)
6. Evaluasi pelanggan : tugas-tugas yang diperlukan untuk memperoleh umpan balik dari pelanggan dengan didasarkan pada evaluasi representasi perangkat lunak yang diciptakan selama masa rekayasa serta implementasi selama masa instalasi.