Tugas Mata Kuliah Analisa Sistem Informasi
Buku : Systems analysis & Design With UML Version 2 : An Object - Oriented Approach Hal : 73 s/d 80
Dosen : Amanda, S.Kom
Kelompok 10
Ifan Sugianto 2112051
Santo Widodo 2112050
Rian Hidayat 2112018
Indah Winarni 2212031
PENDEKATAN FUNGSI TITIK
Titik fungsi pendekatan untuk estimasi yang digunakan lebih kompleks - dan , diharapkan , lebih dapat diandalkan - tiga langkah proses . Pertama , perkiraan manajer proyek, ukuran proyek dalam hal jumlah baris kode sistem baru yang akan membutuhkan perkiraan. Perkiraan ukuran ini kemudian dikonversi menjadi jumlah usaha yang dibutuhkan untuk mengembangkan sistem dalam hal jumlah orang atau bulan . Upaya ini kemudian diubah menjadi jadwal yang memperkirakan waktu dalam hal jumlah bulan dari awal sampai akhir .
Langkah 1 : Perkiraan Sistem Ukuran Langkah pertama adalah untuk memperkirakan ukuran sebuah proyek menggunakan poin fungsi , konsep yang dikembangkan pada tahun 1979 oleh Allen Albrecht dari IBM . Sebuah titik fungsi adalah ukuran - ukuran program berdasarkan jumlah sistem dan kompleksitas input, output, query , file, dan program yang interface .
Manajemen Proyek
Dua buku yang berfokus pada fungsi poin adalah J. Brian Dreger , Fungsi Point Analysis ( Englewood Cliffs ,NJ : Prentice Hall , 1989) dan CR Symons , Software Sizing : MK II FPA
( New York : Wiley , 1991) . Informasi tambahan tentang analisis titik fungsi dapat ditemukan di www.ifpug.org.We yang memperkenalkan variasi pada fungsi poin , poin use case, Untuk menghitung fungsi poin untuk suatu proyek, beberapa komponen tercantum pada lembar kerja untuk mewakili unsur-unsur utama dari suatu sistem. Misalnya, layar entri data adalah jenis input, laporan output, dan query database jenis query. Manajer proyek mencatat jumlah total setiap komponen yang akan masuk ke sistem, dan kemudian ia memecah nomor untuk menunjukkan jumlah komponen yang memiliki tingkatan rendah, sedang, dan kompleksitas tinggi. Ada sembilan belas output yang perlu dikembangkan untuk sistem, empat di antaranya memiliki kompleksitas rendah, sepuluh yang memiliki kompleksitas sedang, dan lima yang sangat complex. Setelah setiap baris diisi , total jumlah poin yang dihitung per baris dengan mengalikan setiap nomor dengan kompleksitas indeks . Total baris ditambahkan untuk menentukan fungsi total poin disesuaikan ( TUFP )untuk proyek tersebut . Kompleksitas dari sistem secara keseluruhan lebih besar daripada jumlah bagian-bagiannya . hal-hal seperti sebagai keakraban tim proyek dengan area bisnis dan teknologi yang akan digunakan untuk melaksanakan proyek tersebut hal ini juga dapat mempengaruhi seberapa kompleks proyek tersebut akan dibangun. Sebuah proyek yang sangat kompleks untuk sebuah tim dengan sedikit pengalaman mungkin memiliki sedikit kompleksitas untuk tim dengan banyak pengalaman . Untuk membuat ukuran yang lebih realistis untuk proyek tersebut, sejumlah tambahan faktor sistem , seperti efisiensi pengguna akhir, usabilitas, dan komunikasi data, yang dinilai dalam hal efeknya pada kompleksitas proyek. penilaian ini dijumlahkan dan ditempatkan ke dalam rumus untuk menghitung kompleksitas proyek yang disesuaikan dengan ( APC ) skor. Nilai TUFP dikalikan dengan nilai APC untuk menentukan ukuran utama proyek dalam hal fungsi total poin yang disesuaikan ( TAFP ). Jumlah ini harus memberikan manajer proyek ide yang masuk akal tentang bagaimana besar proyek akan dibangun. Kadang-kadang jalan pintas yang digunakan untuk menentukan kompleksitas proyek . alih-alih menghitung kompleksitas selama empat belas faktor yang tercantum dalam Gambar 3-3 , manajer proyek memilih untuk menetapkan nilai APC yang berkisar dari 0,65 untuk sistem yang sangat sederhana , untuk 1,00 untuk normal sistem , sebanyak 1,35 untuk sistem yang kompleks , kemudian , mereka berkembang biak nilai ke skor TUFP . Sebagai contoh, sistem yang sangat sederhana yang memiliki 200 fungsi poin yang disesuaikan.
Titik Fungsi menurut Nielsen Media
Nielsen Media menggunakan analisis titik fungsi ( FPA ) untuk upgrade ke Sistem Manajemen Sample Global ( RUPS ) untuk Nielsen Media / NetRatings , yang melacak Sampel Peringkat Internet , sekelompok 40.000 rumah nasional bahwa relawan untuk berpartisipasi dalam peringkat berlangsung. Pada akhir musim gugur 1998 , Nielsen Media melakukan count FP berdasarkan RUPS saat ini . ( FPA selalu lebih mudah dan lebih akurat untuk sistem yang ada . ) Nielsen Media memiliki counter atau tiga jaminan kualitas staf FPA dan kemudian masukan jumlah mereka ke Knowledge Plan , produktivitas modeling tool . Pada awal tahun 1999, tujuh programmer mulai menulis kode untuk sistem, yang mereka diharapkan untuk menyelesaikan dalam sepuluh bulan. Seperti mendekati November, Proyek ini menambah staf untuk mencoba untuk memenuhi tenggat waktu . kapan menjadi jelas bahwa batas waktu tidak akan terpenuhi, perhitung FP baru dilakukan . The RUPS telah berkembang menjadi 900 FP . Selain asli 500 ditambah 20 persen , ada adalah 300 FP disebabkan fitur dan fungsi yang telah merayap ke dalam proyek. Bagaimana itu bisa terjadi ? Cara yang selalu terjadi adalah : pengembang dan pengguna telah menambahkan sebuah tombol dan beberapa fitur di sana, dan segera proyek ini jauh lebih besar daripada itu awalnya . Tapi Nielsen Media telah menempatkan saham di tanah pada awal dari yang mereka bisa mengukur pertumbuhan sepanjang jalan .Praktek terbaik adalah dengan menjalankan FPA dan produktivitas memodelkan pada saat peluncuran proyek dan lagi ketika ada penuh daftar persyaratan fungsional . Kemudian melakukan analisis lainsetiap kali ada modifikasi utama dalam fungsional definisi proyek .Sumber: Bill Roberts , " Ratings permainan , " CIO Magazine (Oktober 2000).
Dalam perencanaan, sifat yang tepat dari sistem belum ditentukan, sehingga tidak mungkin untuk tahu persis berapa banyak input, output, dan sebagainya yang akan berada di sistem. Semua terserah kepada manajer proyek untuk membuat dugaan cerdas. Beberapa orang merasa bahwa menggunakan fungsi poin pada awal proyek tidak praktis untuk reason. mereka percaya fungsi poin dapat menjadi alat yang berguna untuk memahami ukuran proyek pada setiap titik dalam SDLC. Kemudian dalam proyek,sekali lagi yang diketahui tentang sistem, manajer proyek akan merevisi perkiraan menggunakan pengetahuan yang lebih baik ini untuk menghasilkan hasil yang lebih akurat . Setelah Anda telah memperkirakan jumlah titik fungsi, Anda perlu mengkonversi nomorfungsi poin ke baris kode yang akan dibutuhkan untuk membangun sistem. jumlah tersebutbaris kode tergantung pada bahasa pemrograman yang Anda memutuskan untuk menggunakan .
menyajikan panduan konversi yang sangat kasar untuk beberapa bahasa populer .Sebagai contoh, sistem memiliki 243 fungsi total poin disesuaikan . untuk mengembangkan sistem di C biasanya akan membutuhkan sekitar 35.964 ( 148 * 243 ) baris kode untuk menulis itu . Sebaliknya, Visual Basic biasanya akan mengambil 12,150 ( 50 * 243 ) baris kode. Mengembangkan sistem menggunakan paket seperti Excel atau Access akan mengambil antara 11.421 ( 47 * 243 ) dan 8505 ( 35 * 243 ) baris kode , masing-masing. Ada besar berkisar paket karena paket yang berbeda memungkinkan Anda untuk melakukan hal yang berbeda , dan tidak semua sistem dapat dibangun dengan menggunakan paket-paket tertentu . Kadang-kadang banyak kode tambahan harus ditulis untuk melakukan beberapa fungsi sederhana karena paket tidak diperlukan kemampuan . Ada juga pesan yang sangat penting dari data dalam gambar ini . Karena ada hubungan langsung antara baris kode dan jumlah usaha dan waktu yang dibutuhkan untuk mengembangkan sistem , pilihan bahasa pembangunan memiliki dampak yang signifikan pada waktu dan biaya proyek.
Menghitung ukuran sistem
Bayangkan bahwa pekerjaan telah berjalan dengan baik sehingga Anda perlu mengembangkan sistem untuk mendukung usaha Anda . sistem harus memungkinkan Anda untuk memasukkan segala informasi tentang perusahaan dengan yang Anda wawancara , wawancara dan kunjungan kantor ini di fungsikan bahwa Anda telah dijadwalkan , dan penawaran yang Anda terima . itu harus mampu menghasilkan laporan , seperti kontak perusahaan, jadwal wawancara, dan jadwal kunjungan kantor, serta menghasilkan surat ucapan terima kasih untuk dibawa ke dalam pengolah kata untuk penyesuaian . Anda juga perlu sistem untuk menjawab pertanyaan, seperti jumlah wawancara menurut kota dan rata-rata jumlah tawaran Anda .pertanyaan1 . Tentukan jumlah input, output, interface, file, dan pertanyaan bahwa sistem ini membutuhkan. Untuk setiap elemen , menentukan apakah kompleksitas adalah rendah, sedang, atau tinggi. Catat informasi ini padalembar kerja.2 . Hitung total fungsi poin untuk setiap baris pada worksheet Anda dengan mengalikan jumlah masing-masing elemen dengan skor kompleksitas yang sesuai .3 . Meringkas fungsi total poin disesuaikan .4 . Misalkan sistem akan dibangun oleh Anda menggunakan Visual Basic ( VB ) . Mengingat kemampuan VB Anda, kalikan TUFP skor dengan skor APC yang paling perkiraan bagaimana kompleks sistem akan bagi Anda untuk mengembangkan ( .65 ? Sederhana , 1 ? Rata , 1,35 ? Kompleks ), dan enghitung nilai TAFP .5 . Menggunakan tabel pada Gambar 3-4 , menentukan jumlah baris kode yang sesuai dengan VB . Multiply ini nomor dengan TAFP untuk menemukan total baris kode bahwa sistem anda akan membutuhkan.
Langkah 2 : Perkiraan diperlukan upaya Setelah pemahaman yang mencapai sekitar ukuran sistem, langkah berikutnya adalah untuk memperkirakan upaya yang diperlukan untuk membangunnya. Upaya adalah fungsi dari sistem. Ukuran dikombinasikan dengan tingkat produksi ( berapa banyak pekerjaan seseorang dapat menyelesaikan dalam tempo yang diberikan ). Banyak penelitian telah dilakukan pada tingkat produksi perangkat lunak . Salah satu yang paling populer dalam algoritma ialah model COCOMO, dirancang oleh Barry W. Boehm untuk mengubah kode garis menjadi dasar perkiraan orang. Ada versi yang berbeda dari COCOMO model, yang bervariasi berdasarkan kompleksitas perangkat lunak , ukuran sistem, pengalamanpengembang , dan jenis perangkat lunak yang dikembangkan ( misalnya, aplikasi bisnis software seperti sistem pendaftaran di universitas; software komersial seperti kata, atau sistem perangkat lunak seperti Windows). Untuk bisnis kecil dengan software proyek berukuran sedang ( yaitu , 100.000 baris kode dan sepuluh atau lebih sedikit programmer ), modelnya cukup sederhana : usaha (dalam orang - bulan ) ribuan baris kode. Misalnya, untuk mengembangkan sistem perangkat lunak bisnis yang membutuhkan 10.000 baris kode akan biasanya mengambil 14 bulan untuk menyelesaikan . Jika sistem dikembangkan di COCOMO( yang setara dengan 35.964 baris kode ) , itu akan membutuhkan sekitar 50,35 bulan usaha .
Langkah 3: Perkiraan Waktu yang dibutuhkan Setelah upaya dipahami , jadwal optimal untuk proyek dapat diperkirakan . Data historis atau perangkat lunak estimasi dapat digunakan sebagai alat bantu . Salah satu aturan praktis adalah untuk menentukan jadwal dengan menggunakan persamaan berikut :jadwal waktu ( bulan ) * orang - months 1 / 3.
Persamaan ini digunakan secara luas, meskipun nomor tertentu bervariasi (misalnya, beberapa estimator
dapat menggunakan 3,5 atau 2,5 bukan 3,0). Persamaan ini menunjukkan bahwa proyek yang memiliki usaha 14 bulan harus dijadwalkan untuk mengambil sedikit lebih dari 7 bulan untuk menyelesaikan. usaha yang dibangun sekitar 35 bulan akan memerlukan waktu sedikit lebih baik dari usaha 11 bulan. Penting untuk dicatat bahwa perkiraan ini adalah untuk analisis, desain, dan pelaksanaan, tidak termasuk perencanaan.
MENCIPTAKAN DAN MENGELOLA PROGRAM KERJA
Setelah manajer proyek memiliki gambaran umum tentang ukuran dan jadwal perkiraan untuk proyek tersebut, dia menciptakan rencana kerja , yang merupakan jadwal dinamis yang mencatat dan melacak semua tugas yang perlu dilakukan selama proyek . Daftar rencana kerja setiap tugas , bersama dengan informasi penting tentang hal itu , seperti saat perlu diselesaikan, orang yang ditugaskan untuk melakukan pekerjaan itu, dan setiap deliverable yang akan menghasilkan. Itu adalah tingkat detail dan jumlah informasi yang ditangkap oleh rencana kerja tergantung pada kebutuhan suatu proyek ( dan detail biasanya meningkat selama proyek berlangsung ) . Rencana kerja adalah komponen utama dari perangkat lunak manajemen proyek yang disebutkan sebelumnya .
Untuk membuat rencana kerja , manajer proyek pertama mengidentifikasi tugas-tugas yang harus dicapai dan menentukan berapa lama mereka akan mengambil keputusan . Kemudian tugas diatur dalam rencana kerja dan disajikan secara grafis dengan menggunakan Gantt dan PERT grafik . Semua teknik ini membantu manajer proyek memahami dan mengelola kemajuan proyek dari waktu ke waktu .
Mengidentifikasi Tugas
Tujuan keseluruhan untuk sistem harus terdaftar di sistem permintaan , dan itu adalah pekerjaan manajer proyek untuk mengidentifikasi semua tugas yang perlu dilakukan untuk memenuhi tujuan . Ini terdengar seperti tugas yang menakutkan - bagaimana bisa seseorang tahu segala sesuatu yang perlu dilakukan untuk membangun sistem yang belum pernah dibangun sebelumnya?Salah satu pendekatan untuk mengidentifikasi tugas-tugas adalah untuk mendapatkan daftar tugas yang telah dikembangkan dan untuk memodifikasinya. Ada daftar standar tugas , atau metodologi , yang tersedia untuk digunakan sebagai point.As mulai kita dinyatakan dalam Bab 1 , metodologi adalah pendekatan formal untuk menerapkan SDLC ( yaitu , itu adalah daftar langkah-langkah dan kiriman ) . Seorang manajer proyek dapat mengambil metodologi yang ada , pilih langkah-langkah dan kiriman yang berlaku untuk proyek ini ,dan menambahkannya ke rencana kerja. Jika metodologi yang ada tidak tersedia dalam organisasi, metodologi dapat dibeli dari konsultan atau vendor, atau buku-buku seperti karena buku ini dapat berfungsi sebagai guide.metodologi yang ada adalah cara yang paling populer untuk membuat rencana kerja karena sebagian besar organisasi memiliki metodologi yang mereka gunakan untuk proyek-proyek .Jika seorang manajer proyek lebih memilih untuk memulai dari awal , ia dapat menggunakan terstruktur, Pendekatan dimana tugas tingkat tinggi yang pertama kali didefinisikan dan kemudian dipecah menjadi sub-tugas. Sebagai contoh, daftar tugas tingkat tinggi yang diperlukan untuk menerapkan IT barukelas pelatihan . Beberapa langkah-langkah utama dalam proses termasuk mengidentifikasi vendor , menciptakan dan administrasi survei, dan membangun ruang kelas baru. Setiap langkah kemudian dipecah pada gilirannya dan bernomor secara hirarkis . Ada delapan sub-tugas (yaitu , 7,1-7,8 ) untuk membuatdan administrasi survei , dan ada tiga sub-tugas ( 7.2.1-7.2.3 ) yang terdiri dari meninjau tugas survei awal . Sebuah daftar tugas hirarkis bernomor dengan cara ini disebut karya breakdown structure ( WBS ) , dan itu adalah tulang punggung dari rencana kerja proyek. Jumlah tugas dan tingkat detail tergantung pada kompleksitas dan ukuran proyek.
semakin besar proyek, semakin besar pula kompleksitas yang ada. Yang lebih penting menentukan tugas-tugas pada tingkat rendah detail sehingga langkah penting tidak diabaikan. Ada dua pendekatan dasar untuk mengorganisir WBS : dengan SDLC fase atau produk. Sebagai contoh, jika sebuah perusahaan memutuskan bahwa yang
dibutuhkan untuk mengembangkan situs Web, perusahaan dapat menciptakanWBS didasarkan pada SDLC : perencanaan , analisis, desain , dan implementasi . Dalam hal ini, tugas khas yang akan berlangsung selama perencanaan akan analisis kelayakan . tugas ini akan dipecah menjadi berbagai jenis analisis kelayakan : teknik , ekonomi , dan organisasi . Masing-masing akan lebih lanjut dipecah menjadi satu set subtasks . Atau, perusahaan bisa mengatur rencana kerja sepanjang garis produk yang berbeda untuk dikembangkan. Sebagai contoh, dalam kasus situs Web, produk dapat mencakup applet, server aplikasi, database server, berbagai set halaman Web harus dirancang, situs peta, dan sebagainya. Kemudian ini akan lebih didekomposisi menjadi tugas yang berbeda terkait dengan fase SDLC . Seperti dijelaskan sebelumnya , Gambar 3-6 menggambarkan tugas-tugas yang diperlukanuntuk membuat kelas pelatihan IT baru . Setelah struktur keseluruhan ditentukan, tugas diidentifikasi dan dimasukkan dalam WBS dari workplan.We kembali ke topik WBS dan penggunaannya dalam perencanaan berulang kemudian dalam bab ini.
Proyek Rencana Kerja
Proyek rencana kerja adalah mekanisme yang digunakan untuk mengelola tugas-tugas yang tercantum dalambekerja kerusakan struktur . Ini adalah alat utama manajer proyek untuk mengelola proyek. Menggunakan itu, manajer proyek dapat mengetahui apakah proyek tersebut di depan atau di belakang jadwal, seberapa baik proyek diperkirakan, dan perubahan apa yang perlu dilakukan untuk memenuhi tenggat waktu proyek .Pada dasarnya , rencana kerja adalah tabel yang berisi daftar semua tugas dalam WBS , bersama dengan penting tugas informasi, seperti orang-orang yang ditugaskan untuk melakukan tugas-tugas , yang sebenarnyajam bahwa tugas mengambil , dan varians antara estimasi dan aktual waktu penyelesaian. Minimal, informasi harus mencakup durasi tugas, dengan status saat ini tugas (yaitu, terbuka, lengkap), dan dependensi tugas, yang terjadi ketika satu tugas tidak dapat dilakukan sampai tugas lain selesai. Sebagai contoh, Gambar 3-6 menunjukkan bahwa menggabungkan perubahan pada survey (tugas 7.4 ) memakan waktu seminggu untuk melakukan, tetapi tidak dapat terjadi sampai setelah survey terakhir (tugas 7.2 ) dan diujicobakan (tugas 7.3). Kunci tonggak, atau tanggal-tanggal penting, juga diidentifikasi pada rencana kerja . Presentasi kekomite persetujuan , mulai dari pelatihan pengguna akhir, retret perusahaan, dan tanggal jatuh tempo prototipe sistem adalah jenis tonggak yang mungkin penting untuk melacak.
Gantt Chart
Gantt chart adalah grafik batang horizontal yang menunjukkan informasi tugas yang sama sebagai proyek program kerja tetapi dengan cara grafis . Kadang-kadang gambar benar-benar bernilai seribu kata , dan Gantt chart dapat berkomunikasi status tingkat tinggi proyek lebih cepat dan lebih mudah dari rencana kerja . Membuat bagan Gantt sederhana dan dapat dilakukan dengan menggunakan spreadsheet paket, perangkat lunak grafis ( misalnya, Microsoft Visio ), atau paket manajemen proyek. Pertama, tugas terdaftar sebagai baris dalam tabel, dan waktu yang tercantum di atas secara bertahap berdasarkan kebutuhan proyek ( lihat Gambar 3-7 ) . Sebuah proyek singkat dapat dibagi menjadi jam atau hari, padahal proyek menengah dapat diwakili menggunakan minggu atau bulan. Horizontal bar tertarik untuk mewakili durasi setiap tugas , bar itu awal dan akhir tanda kapan tepatnya tugas akan mulai dan berakhir. Sebagai orang bekerja pada tugas, bar yang tepat diisi secara proporsional dengan berapa banyak tugas selesai . terlalu banyak tugas pada Gantt chart dapat menjadi membingungkan , jadi yang terbaik untuk membatasi jumlah tugas untuk sekitar dua puluh atau tiga puluh . Jika ada lebih banyak tugas , istirahat mereka ke dalam sub-tugas dan menciptakanGantt chart untuk setiap tingkat detail.
Ada banyak hal yang dapat dilakukan seorang manajer proyek yaitu dapat melihat dengan cepat grafik Gantt. Selain melihat bagaimana tugas panjang dan seberapa jauh mereka, manajer proyek juga bisa membedakan mana tugas-tugas yang berurutan, yang tugas terjadi pada saat yang sama, dan tugas-tugas
tumpang tindih dalam beberapa cara. Dia bisa mendapatkan tampilan cepat tugas-tugas yang lebih cepat dari jadwal dan di belakang jadwal dengan menggambar garis vertikal pada tanggal hari ini. Jika bar tidak diisi dan dapat di sebelah kiri garis, tugas yang berada di belakang jadwal.
Ada beberapa notasi khusus yang dapat ditempatkan pada grafik Gantt. tonggak proyek ditampilkan dengan menggunakan segitiga terbalik atau berlian. Panah yang ditarik antara bar tugas untuk menunjukkan dependensi tugas. Terkadang, nama-nama orang yang ditugaskan untuk setiap tugas yang tercantum di samping bar tugas untuk menunjukkan sumber daya manusia telah dialokasikan untuk tugas-tugas.
Tidak ada komentar:
Posting Komentar