Software Reuse

Video : The CMMI Process Improvement

Model CMMI dimaksudkan untuk menjadi kerangka kerja untuk perbaikan proses yang diterapkan secara luas di berbagai perusahaan.

Model CMMI sangat kompleks, dengan lebih dari 1.000 halaman deskripsi.

Sebuah penilaian CMMI melibatkan memeriksa proses dalam sebuah organisasi dan penilaian proses ini atau area proses yang terdapat pada enam poin skala tersebut berhubungan dengan tingkat kesempurnaan di area masing-masing proses. Idenya adalah bahwa semakin sempurna proses maka semakin baik. Enam poin skala tersebut yaitu:

1. Incomplete, Setidaknya satu tujuan tertentu yang terkait dengan area proses tidak memuaskan karena Tidak ada tujuan umum pada tingkat ini sebagai pelembagaan proses yang tidak lengkap.
2. Performed, Tujuan yang terkait dengan area proses memuaskan, dan untuk semua proses lingkup pekerjaan yang akan dilakukan secara eksplisit ditetapkan dan dikomunikasikan kepada anggota tim.
3. Managed, Pada tingkat ini, tujuan yang terkait dengan area proses terpenuhi dan kebijakan organisasi berada pada tempat yang menentukan kapan setiap proses harus digunakan.
4. Defined, Tingkat ini berfokus pada standarisasi organisasi dan penyebaran proses. Setiap proyek memiliki proses yang dikelola yang disesuaikan dengan kebutuhan proyek.
5. Quantitatively managed. Pada tingkat ini, ada sebuah tanggung jawab organisasi untuk menggunakan metode kuantitatif statistik dan lainnya untuk mengendalikan subproses; yaitu, pengumpulan proses dan pengukuran produk harus digunakan dalam proses manajemen.
6. Optimizing, Pada tingkat tertinggi ini, organisasi harus menggunakan proses dan pengukuran produk untuk mendorong perbaikan proses.

The Staged CMMI Model

The Staged CMMI Model sebanding dengan Software CMM dalam menyediakan sarana untuk menilai kemampuan proses organisasi pada salah satu dari lima tingkat, dan mengatur tujuan yang harus dicapai pada masing-masing tingkat. Proses perbaikan dicapai dengan menerapkan praktek-praktek di setiap tingkat, bergerak dari bawah ke tingkat yang lebih tinggi pada model.

Setiap tingkat kesempurnaan memiliki tujuan dan praktik sendiri. The staged model mengasumsikan bahwa semua tujuan dan praktik di satu tingkat dilaksanakan sebelum transisi ke tingkat berikutnya. Namun, keadaan organisasi sedemikian rupa sehingga memungkinkan lebih tepat untuk menerapkan tujuan dan praktek di tingkat yang lebih tinggi sebelum praktek-tingkat yang lebih rendah.

The Continous CMMI Model

Hasil dari penilaian continous CMMI adalah profil kemampuan yang menampilkan setiap area proses dan penilaian kemampuan yang terkait.

Keuntungan utama dari continous model adalah bahwa perusahaan dapat memilih dan memilah proses untuk perbaikan sesuai dengan kebutuhan dan persyaratan mereka sendiri. berbagai jenis organisasi memiliki kebutuhan yang berbeda untuk perbaikan prosesnya. 

Video Dokumentasi Presentasi Kelompok 3 Service Oriented Architecture

Service Oriented Architecture

Software Standart & Software Measurement and Metrics

- Software Standart 
  Standar perangkat lunak memiliki peranan yang sangat penting dalam manajemen kualitas perangkat lunak.Sebagai bagian dari proses QA ini, alat dan metode untuk mendukung penggunaan standar ini juga dapat dipilih. Setelah standar telah dipilih untuk digunakan, proses proyek tertentu harus didefinisikan untuk memantau penggunaan standar dan memeriksa bahwa mereka telah diikuti.

Alasan standar menjadi penting diantaranya :
- membuat sebuah perusahaan menjadi lebih bijak dalam mengembangkan software .
- memberikan sebuah kerangka kerja untuk sesuatu yang disebut kualitas.
- membantu kelangsungan ketika proyek di lanjutkan oleh orang lain .

Ada dua jenis standar yang terkait dengan rekayasa perangkat lunak yang dapat didefinisikandan digunakan dalam manajemen kualitas perangkat lunak:
- standar produk
- standar proses

  ISO 9001 standar sendiri bukan standar untuk pengembangan perangkat lunak tetapi adalah kerangka kerja untuk mengembangkan standar perangkat lunak. Ini menetapkan prinsip-prinsip kualitas umum, menjelaskan proses kualitas pada umumnya, dan menjabarkan standar organisasi dan prosedur yang harus didefinisikan. Ini harus didokumentasikan dalam panduan organisasional kualitas.

 - Software Measurement and Metrics 
   Pengukuran perangkat lunak berkaitan dengan menurunkan nilai numerik atau profil untuk atribut dari komponen perangkat lunak, sistem, atau proses. Dengan membandingkan nilai-nilai ini sama lain dan dengan standar yang berlaku di seluruh organisasi, Anda mungkin dapat menarik kesimpulan tentang kualitas software, atau menilai efektivitas perangkat lunak proses, peralatan, dan metode.

   Sebuah metrik perangkat lunak merupakan karakteristik dari dokumentasi sistem perangkat lunak, sistem, atau proses pembangunan yang dapat diukur secara obyektif.

Video Managing People (Manajemen Orang-Orang)

Release Management

Release Management

Setelah berhasil membuat sebuah produk, langkah selanjutnya adalah mendistribusikan produk tersebut kepada pelanggan, proses ini bisa disebut dengan rilis program. Untuk rilis perangkat lunak yang memiliki pasar massal atau bersifat general umunya ada 2 tipe rilis yaitu mayor rilis dan minor rilis. Mayor rilis adalah rilis produk memberikan fungsi baru yang signifikan sedangkan minor rilis adalah rilis yang memberikan perbaikan sistem atau bug sesuai dengan keluhan pelanggan atau hasil riset internal.

Rilis mayor biasanya bernilai ekonomis tinggi bagi vendor atau pengembang dan biasanya pelanggan akan dikenakan biaya untuk mendapatkannya, sedangkan minor rilis biasanya diberikan secara gratis Karena fokusnya bukan untuk nilai ekonomis melainkan kepuasan pelanggan.

Untuk perangkat lunak kustom mengelola sistem rilis merupakan proses yang kompleks dan dalam suatu kasus vendor atau developer di tuntut  untuk mereproduksi persis software yang telah dikirim ke pelanggan tertentu. Oleh karena itu ketika rilis sistem diproduksi, harus didokumentasikan untuk memastikan bahwa hal itu dapat diciptakan kembali persis di waktu yang akan datang. Untuk mendokumentasikan sebuah rilis, kita harus merekam versi tertentu dari komponen kode sumber yang digunakan untuk membuat kode dieksekusi. kita harus menyimpan salinan dari file kode sumber, executable yang sesuai, dan semua data dan file konfigurasi. kita juga harus mencatat versi dari sistem operasi, pustaka, kompiler, dan alat-alat lain yang digunakan untuk membangun perangkat lunak. Ini mungkin diperlukan untuk membangun persis sistem yang sama di kemudian hari.

Dalam merilis sebuah produk kita harus memperhitungkan waktu yang tepat. Jika rilis terlalu sering atau memerlukan upgrade hardware, pelanggan tidak bisa bergerak ke rilis baru, terutama jika mereka harus membayar untuk mendapatkan update kemudian Jika sistem rilis terlalu jarang, pangsa pasar mungkin akan hilang sebagai pelanggan pindah ke sistem alternatif.

Secara umum rilis sistem meliputi kode dieksekusi, file data, file konfigurasi, dan dokumentasi. manajemen rilis melibatkan membuat keputusan tentang tanggal rilis sistem, menyiapkan semua informasi untuk distribusi, dan mendokumentasikan setiap rilis sistem.

Untuk penjelasan lebih detail, tonton video berikut ini:

Video - Software Quality, Reviews and Inspection oleh Riza Hidayat

Jika Gambar tidak muncul klik link Tonton

Video : Software Pricing & Plan-driven Development

Muhammad Ikhsan Maulana Akbar - Teamwork dalam manajemen proyek

Video : Process analysis & Process Change

 
Process Analysis
Proses analisis adalah studi proses untuk membantu memahami karakteristik utama proses dan bagaimana proses tersebut dilakukan dalam prakteknya oleh orang-orang yang terlibat. Ini adalah sebuah penyederhanaan karena, dalam kenyataannya, kegiatan ini saling terkait. kita perlu membawa beberapa analisi untuk mengetahui apa yang harus diukur, dan, ketika melakukan pengukuran, kita pasti mengembangkan pemahaman yang lebih dalam proses pengukuran.

Ketika menganalisis proses, sering berguna untuk memulai dengan model proses yang mendefinisikan kegiatan dalam proses dan input dan output dari kegiatan ini. Itu Model juga dapat mencakup informasi tentang aktor-proses orang atau peran bertanggung jawab untuk kegiatan pertunjukan, dan kiriman kritis yang harus diproduksi. Anda dapat menggunakan notasi informal untuk menggambarkan model proses atau lebih formal notasi tabel, diagram aktivitas UML, atau proses bisnis modeling notasi seperti BPMN (dibahas dalam Bab 19). Ada banyak contoh proses model dalam buku ini yang saya gunakan untuk menyajikan dan menjelaskan proses software.

model proses adalah cara yang baik untuk memfokuskan perhatian pada kegiatan dalam prosesdan transfer informasi antara kegiatan tersebut. model proses tersebut tidak harus formal atau lengkap-mereka tujuannya adalah untuk mendorong diskusi daripada mendokumentasikan proses secara rinci. Diskusi dengan orang-orang yang terlibat dalam proses dan pengamatan dari proses yang sering terstruktur sekitar satu set pertanyaan tentang model proses formal. Contoh pertanyaan-pertanyaan ini mungkin:

1. Kegiatan apa berlangsung dalam praktek tetapi tidak ditampilkan dalam model? Tak pelak,model tidak lengkap tetapi jika orang yang berbeda mengidentifikasi kegiatan yang hilang yang berbeda, ini memberitahu Anda bahwa proses ini tidak dilakukan secara konsisten di seluruh organisasi.

2. Apakah ada kegiatan proses, ditampilkan dalam model, yang Anda (aktor proses) berpikir tidak efisien? Dalam hal apa mereka tidak efisien dan bagaimana mungkin ini ditingkatkan? Bagaimana kegiatan yang tidak efisien mempengaruhi pengukuran proses yang mungkin telah dibuat?

3. Apa yang terjadi ketika sesuatu yang salah? Apakah tim terus mengikuti Proses didefinisikan dalam model, atau proses ditinggalkan dan tindakan darurat diambil? Jika proses ini ditinggalkan, hal ini menunjukkan bahwa insinyur perangkat lunak lakukan tidak percaya bahwa proses ini cukup baik atau tidak memiliki cukup fleksibilitas untuk menangani pengecualian.

4. Siapa aktor yang terlibat pada berbagai tahap dalam proses dan bagaimana mereka menyampaikan? kemacetan yang biasa terjadi pada pertukaran informasi?

5. Dukungan apa alat yang digunakan untuk kegiatan yang ditampilkan dalam model? Apakah ini efektif dan universal digunakan? Bagaimana bisa dukungan alat ditingkatkan?Ketika Anda telah menyelesaikan analisis dari proses perangkat lunak, Anda harus memilikipemahaman yang lebih dalam proses itu dan potensi untuk perbaikan proses dimasa depan. Anda juga harus memahami kendala pada perbaikan proses danbagaimana bisa membatasi ruang lingkup perbaikan yang dapat diperkenalkan.

Process exceptions
proses perangkat lunak adalah entitas yang kompleks. Mungkin ada model proses didefinisikan dalam sebuah organisasi tapi ini hanya dapat mewakili situasi di mana tim pengembangan tidak dihadapkan dengan masalah tak terduga. Pada kenyataannya, masalah tak terduga yang kenyataan hidup sehari-hari bagi manajer proyek. Model proses 'ideal' harus diubah secara dinamis sebagai solusi untuk masalah ini ditemukan. Contoh jenis pengecualian bahwa seorang manajer proyek mungkin harus berurusan dengan meliputi:

• beberapa orang kunci menjadi sakit pada saat yang sama, sebelum proyek kritis
ulasan;

• pelanggaran serius dalam keamanan komputer yang berarti semua komunikasi keluar absen selama beberapa hari;

• perusahaan reorganisasi, yang berarti bahwa manajer harus menghabiskan banyak
waktu mereka bekerja pada masalah organisasi bukan pada manajemen proyek;

• permintaan tak terduga untuk menulis proposal untuk proyek baru yang berarti usaha
harus ditransfer dari proyek saat ini untuk penulisan proposal.


Pada dasarnya, pengecualian akan mempengaruhi dan biasanya mengubah, dalam beberapa cara, sumber daya, anggaran, atau jadwal proyek. Sulit untuk memprediksi semua pengecualian di muka dan untuk menggabungkannya ke dalam model proses formal. Oleh karena itu Anda sering harus mengetahui bagaimana menangani pengecualian dan kemudian secara dinamis mengubah 'standar' Proses untuk mengatasi keadaan yang tak terduga. 

Process Change

perubahan proses yaitu berupa modifikasi pada proses yang ada. kita dapat melakukan modifikasi ini dengan memperkenalkan praktek-praktek baru, metode, atau alat; mengubah kegiatan proses pemesanan, memperkenalkan atau menghapus kiriman dari proses, meningkatkan komunikasi, atau dengan memperkenalkan peran dan tanggung jawab baru.. perubahan proses harus didorong oleh tujuan peningkatan seperti 'mengurangi jumlah cacat  yangd itemukan selama pengujian integrasi sebesar 25 persen. Setelah perubahan telah dilaksanakan, kita mengukur proses untuk menilai efektivitas perubahan.

Ada lima tahapan utama  dalam perubahan proses  (Proses Change) yaitu : 

1. Improvement identification (Perbaikan  Identifikasi), Tahap ini berkaitan dengan menggunakan hasil analisis proses untuk mengidentifikasi cara-cara untuk mengatasi masalah kualitas, jadwal kemacetan, atau inefisiensi biaya yang telah diidentifikasi selama analisis proses. Anda dapat mengusulkan proses baru, struktur proses, metode, dan alat untuk masalah proses alamat.

2.  Improvement prioritization (Peningkatan prioritas), Tahap ini berkaitan dengan menilai kemungkinan perubahan proses, dan memprioritaskan mereka untuk implementasi. ketika banyak kemungkinan perubahan telah diidentifikasi, biasanya tidak mungkin untuk memperkenalkan mereka sekaligus, dan Anda harus memutuskan mana yang paling penting.

3. Process change introduction  (Perubahan pengenalan proses ), perubahan pengenalan proses berarti menempatkan baru
prosedur, metode, dan alat-alat ke tempatnya dan mengintegrasikan mereka dengan lainnya
kegiatan proses.

4. Process training ( pelatihan proses),  Tanpa pelatihan, tidak mungkin untuk mendapatkan manfaat penuh perubahan proses. Para insinyur yang terlibat perlu memahami perubahan yang telah diusulkan dan bagaimana melakukan proses baru dan berubah. terlalu sering, perubahan proses yang dikenakan tanpa pelatihan yang memadai dan efek perubahan ini adalah untuk menurunkan daripada meningkatkan kualitas produk. Dalam kasus persyaratan manajemen, pelatihan mungkin melibatkan diskusi tentang nilai manajemen persyaratan, penjelasan tentang kegiatan proses, dan pengantar alat-alat yang telah dipilih. 

5. Change tuning (Perubahan tala Usulan),  perubahan proses tidak akan pernah benar-benar efektif
Begitu mereka diperkenalkan. Anda memerlukan fase tala di mana masalah kecil bisa
ditemukan, dan modifikasi proses dapat diusulkan dan diperkenalkan.
Fase tuning ini harus berlangsung selama beberapa bulan sampai insinyur pengembangan
senang dengan proses baru.

Video : Project Scheduling & Agile Planning

Chapter 23.3-23.4

Project Scheduling & Agile Planning

Managing People (Manajemen Orang-Orang)

        Penting bahwa manajer proyek perangkat lunak memahami masalah teknis yang mempengaruhi pekerjaan pengembangan perangkat lunak. Manajer perangkat lunak sering memiliki keterampilan teknis yang kuat, tetapi mungkin tidak memiliki keterampilan lebih yang memungkinkan mereka untuk memotivasi dan memimpin tim pengembangan proyek. Sebagai manajer proyek, kita harus menyadari potensi masalah manajemen orang dan harus mencoba untuk mengembangkan keterampilan manajemen orang. Ada 4 faktor dalam memanajemen orang :
 

1. Memperlakukan dengan cara yang sebanding orang yang memilki konsistensi tinggi dalam tim proyek.
 

2. Menghormati perbedaan orang yang memiliki keterampilan dan manajemen yang berbeda beda. semua tim harus diberikan kesempatan untuk membuat kontribusi.
 

3. Membuat orang berkontribusi secara efektif dan merasa bahwa diri mereka merasa sangat diperlukan.
 

4. kejujuran sebagai manajer, kita harus selalu jujur dalam tingkat pengetahuan teknis.

Manajemen orang-orang menurut pandangan saya adalah berdasarkan pengalaman tidak dari buku.

Video : Dokumentasi Kelompok 4 : CBSE

Chapter 17

Component-based Software Engineering

Presented by

Kelompok 4

 

Embedded Software

Embedded Software

              Embedded software adalah ‘software yang dibuat' ke elektronik di mobil, telepon, peralatan audio, robot, peralatan, mainan, sistem keamanan, alat pacu jantung, televisi dan jam tangan digital, misalnya. Software ini dapat menjadi sangat canggih dalam aplikasi seperti pesawat, rudal, sistem proses kontrol, dan seterusnya.

         Desain sistem embedded :

    Periodic Stimuli, Ini terjadi pada interval waktu prediksi. Sebagai contoh, sistem dapat memeriksa sensor setiap 50 milidetik dan mengambil tindakan (respon) tergantung pada nilai sensor (stimulus).

    Aperiodic Stimuli, Ini terjadi tidak teratur dan tak terduga dan biasanya mengisyaratkan menggunakan mekanisme interrupt komputer. Contoh stimulus tersebut akan interupsi yang menunjukkan bahwa suatu I / O Transfer adalah lengkap dan data yang tersedia dalam buffer.

 Architectural patterns : 

Observe and React, Pola ini digunakan ketika satu set sensor secara rutin dipantau dan ditampilkan. Ketika sensor menunjukkan bahwa beberapa peristiwa telah terjadi (misalnya, panggilan masuk di ponsel), sistem bereaksi dengan memulai proses.

Environmental Control, Pola ini digunakan ketika sistem termasuk sensor, yang memberikan informasi tentang lingkungan dan aktuator yang dapat mengubah lingkungan. Dalam menanggapi perubahan lingkungan terdeteksi oleh sensor, sinyal kontrol dikirim ke aktuator sistem.

Process Pipeline, Pola ini digunakan ketika data harus diubah dari satu representasi yang lain sebelum dapat diproses. transformasi diimplementasikan sebagai urutan langkah-langkah pengolahan, yang dapat dilakukan secara bersamaan. Hal ini memungkinkan untuk pengolahan data yang sangat cepat, karena inti atau prosesor yang terpisah dapat mengeksekusi setiap transformasi.

Timing analysis :

    Deadlines, waktu dimana stimulus harus diproses dari beberapa respon yang dihasilkan oleh sistem. Jika sistem tidak memenuhi tenggat waktu, ini adalah kegagalan sistem; dalam sistem soft real-time.

    Frequency, Jumlah berapa kali per detik bahwa proses harus mengeksekusi sehingga Anda yakin bahwa selalu dapat memenuhi tenggat waktu tersebut.

   Executin Time, Waktu yang diperlukan untuk memproses stimulus dan menghasilkan tanggapan.

Real-time operating system :

A real time clock, yang menyediakan informasi yang diperlukan untuk jadwal proses berkala.

Interrupt handler, yang mengelola permintaan aperiodik untuk layanan.

Scheduller, yang bertanggung jawab untuk memeriksa proses yang dapat dieksekusi dan memilih salah satu dari ini untuk eksekusi.

Resource Manager, yang mengalokasikan memori yang sesuai dan prosesor sumber daya untuk proses yang telah dijadwalkan untuk eksekusi.

Dispatcher, yang bertanggung jawab untuk memulai pelaksanaan proses

Configuration Management - Change Management (Video)

Configuration Management

Change Management

    Perubahan adalah fakta kehidupan untuk sistem perangkat lunak besar. kebutuhan organisasi dan kebutuhan berubah selama masa sistem, bug harus diperbaiki, dan sistem harus beradaptasi dengan perubahan di lingkungan mereka. Untuk memastikan bahwa perubahan diterapkan untuk sistem dengan cara yang terkontrol, Anda memerlukan seperangkat, proses perubahan manajemen alat-didukung. Perubahan manajemen dimaksudkan untuk memastikan bahwa evolusi sistem adalah proses dikelola dan prioritas yang diberikan kepada perubahan yang paling mendesak dan hemat biaya.

     Faktor penting yang menentukan perubahan harus disetujui atau tidak yaitu :

1. Konsekuensi dari tidak membuat perubahan. Ketika menilai permintaan perubahan, Anda harus mempertimbangkan apa yang akan terjadi jika perubahan tersebut tidak dilaksanakan. Jika perubahan itu terkait dengan kegagalan sistem dilaporkan, keseriusan kegagalan yang harus diperhitungkan. Jika kegagalan sistem menyebabkan sistem crash, ini sangat serius dan kegagalan untuk membuat perubahan dapat mengganggu penggunaan operasional sistem. Di sisi lain jika kegagalan memiliki efek kecil, seperti warna yang salah pada layar, maka tidak penting untuk memperbaiki masalah dengan cepat, sehingga perubahan harus memiliki prioritas rendah.
2. Manfaat perubahan. Adalah perubahan sesuatu yang akan bermanfaat bagi banyak pengguna sistem atau itu hanya sebuah proposal yang terutama akan bermanfaat bagi pengusul perubahan?.
3. Biaya membuat perubahan. Jika membuat perubahan mempengaruhi banyak komponen sistem (sehingga meningkatkan kemungkinan memperkenalkan bug baru) dan / atau mengambil banyak waktu untuk melaksanakan, maka perubahan mungkin ditolak, mengingat biaya tinggi yang terlibat.
4. Rilis produk siklus. Jika versi baru dari perangkat lunak yang baru saja dirilis kepada pelanggan, mungkin masuk akal untuk menunda pelaksanaan perubahan sampai rilis direncanakan berikutnya.

Video : Software Management - Process Improvement

Video : Aspect-Oriented Software Engineering

Teknik Estimasi

Dalam kesempatan kali ini saya ingin membahas salah satu tahap penting dalam perencanaan proyek, yang merupakan bagian dari manajemen proyek dan rekayasa perangkat lunak, yaitu Estimation Techniques atau teknik estimasi dalam proyek perangkat lunak.

Ketika proyek akan dilaksanakan, terlebih dahulu kita melakukan perencanaan proyek. Dalam perencanaan proyek ada lima aktivitas utama, salah satunya adalah estimasi. Estimasi berarti menentukan seberapa besar biaya, jumlah kerja, sumber daya dan waktu yang akan dibutuhkan untuk membangun sebuah sistem. Estimasi biasanya dilakukan oleh manajer proyek, dengan menggunakan informasi dari stakeholder atau data metrik proyek yang sudah pernah dilakukan. Hal-hal yang umumnya diestimasi dalam proyek perangkat lunak yaitu jadwal (waktu), biaya, performa sistem dan resiko.

Ada banyak sekali ketidakpastian dalam melaksanakan sebuah proyek, sehingga tidak mungkin untuk memperkirakan biaya pengembangan sistem dengan akurat di tahap awal proyek. Terlalu banyak variabel, termasuk sumber daya manusia dan kemampuannya yang terlibat dalam proyek. Namun estimasi proyek perangkat lunak bisa berubah menjadi serangkaian langkah yang sistematis sehingga dapat menghasilkan perkiraan dengan resiko yang bisa diterima.

Teknik estimasi meliputi analogi, pengalaman, penilaian dari ahli, dan penggunaan model parametrik seperti model PRICE untuk hardware, COCOMO untuk proyek perangkat lunak, dan COSYMO untuk proyek sistem.

Ada dua teknik yang bisa dilakukan dalam estimasi:

1. Teknik berdasarkan pengalaman
2. Algorithmic cost modelling

Teknik berdasarkan pengalaman adalah teknik dengan memperkirakan jumlah kerja yang akan dilakukan berdasarkan pengalaman manager pada proyek yang pernah ia laksanakan dan domain aplikasi. Teknik ini lebih baik dilakukan dengan bantuan anggota tim proyek dengan menjelaskan masing-masing estimasi yang dilakukan. Ini dapat memunculkan hal-hal baru yang mungkin tidak disadari oleh anggota tim yang lain maupun oleh manajer, kemudian dirumuskan estimasi kesepakatan tim. Kesulitan jika menggunakan teknik ini adalah proyek perangkat lunak yang akan dikembangkan mungkin tidak memiliki banyak persamaan dengan proyek sebelumnya. Hal ini akan menyulitkan estimasi dengan akurat sebab pengalaman di masa lalu akan tidak banyak membantu. Pengembangan perangkat lunak berubah pesat dan terkadang menggunakan teknik yang tidak familiar seperti web services dan pengembangan berdasarkan COTS.

Algorithmic Cost Modelling menggunakan formula matematika untuk memprediksi biaya proyek berdasarkan pada perkiraan ukuran proyek; jenis perangkat lunak yang dikembangkan; dan faktor tim, proses dan produk lainnya. Algorithmic Cost Modelling digunakan terutama untuk membuat estimasi biaya pengembangan perangkat lunak. Model ini adalah cara sistematis untuk memperkirakan jumlah kerja yang dibutuhkan untuk mengembangkan sistem. Namun model ini kompleks dan susah digunakan, sehingga model semacam ini hanya digunakan oleh beberapa perusahaan saja.

Untuk beberapa jenis pengembangan tertentu, ada estimasi khusus yang digunakan. Seperti pada agile development. Pada agile development, pendekatan estimasi yang digunakan lebih informal dan ringkas, sesuai dengan sumber daya yang ada. Estimasi khusus ini memudahkan alokasi jumlah kerja agar dapat menyesuaikan kondisi seiring berjalannya proses pengembangan. 

Estimasi proyek perangkat lunak tidak pernah bisa dirumuskan dengan 100 persen akurat, akan tetapi dengan mengkombinasikan data historis yang baik dan teknik-teknik yang sistematis, kita bisa meningkatkan akurasi dari estimasi tersebut.

Sekian penyampaian materi oleh saya, semoga dapat bermanfaat bagi pembaca sekalian.

Link video: https://youtu.be/Vtvio5DjUa0 

Proses Change

perubahan proses yaitu berupa modifikasi pada proses yang ada. kita dapat melakukan modifikasi ini dengan memperkenalkan praktek-praktek baru, metode, atau alat; mengubah kegiatan proses pemesanan, memperkenalkan atau menghapus kiriman dari proses, meningkatkan komunikasi, atau dengan memperkenalkan peran dan tanggung jawab baru.. perubahan proses harus didorong oleh tujuan peningkatan seperti 'mengurangi jumlah cacat  yangd itemukan selama pengujian integrasi sebesar 25 persen. Setelah perubahan telah dilaksanakan, kita mengukur proses untuk menilai efektivitas perubahan.

Ada lima tahapan utama  dalam perubahan proses  (Proses Change) yaitu : 

1. Improvement identification (Perbaikan  Identifikasi), Tahap ini berkaitan dengan menggunakan hasil analisis proses untuk mengidentifikasi cara-cara untuk mengatasi masalah kualitas, jadwal kemacetan, atau inefisiensi biaya yang telah diidentifikasi selama analisis proses. Anda dapat mengusulkan proses baru, struktur proses, metode, dan alat untuk masalah proses alamat.

2.  Improvement prioritization (Peningkatan prioritas), Tahap ini berkaitan dengan menilai kemungkinan perubahan proses, dan memprioritaskan mereka untuk implementasi. ketika banyak kemungkinan perubahan telah diidentifikasi, biasanya tidak mungkin untuk memperkenalkan mereka sekaligus, dan Anda harus memutuskan mana yang paling penting.

3. Process change introduction  (Perubahan pengenalan proses ), perubahan pengenalan proses berarti menempatkan baru
prosedur, metode, dan alat-alat ke tempatnya dan mengintegrasikan mereka dengan lainnya
kegiatan proses.

4. Process training ( pelatihan proses),  Tanpa pelatihan, tidak mungkin untuk mendapatkan manfaat penuh perubahan proses. Para insinyur yang terlibat perlu memahami perubahan yang telah diusulkan dan bagaimana melakukan proses baru dan berubah. terlalu sering, perubahan proses yang dikenakan tanpa pelatihan yang memadai dan efek perubahan ini adalah untuk menurunkan daripada meningkatkan kualitas produk. Dalam kasus persyaratan manajemen, pelatihan mungkin melibatkan diskusi tentang nilai manajemen persyaratan, penjelasan tentang kegiatan proses, dan pengantar alat-alat yang telah dipilih. 

5. Change tuning (Perubahan tala Usulan),  perubahan proses tidak akan pernah benar-benar efektif
Begitu mereka diperkenalkan. Anda memerlukan fase tala di mana masalah kecil bisa
ditemukan, dan modifikasi proses dapat diusulkan dan diperkenalkan.
Fase tuning ini harus berlangsung selama beberapa bulan sampai insinyur pengembangan
senang dengan proses baru.

Masalah proses entify, mengusulkan perbaikan, dan sebagainya.Serta kesulitan menilai efektivitas proses berubah , ada dua kesulitan utama  yang terlibat dalam perubahan proses mungkin harus menghadapi:

1.  Resistance to change (Bertahan untuk tidak berubah), Aanggota tim atau manajer proyek mungkin menolak pengenalan perubahan proses dan mengusulkan alasan mengapa perubahan tidak akan bekerja, atau menunda pengenalan perubahan. Mereka mungkin, dalam beberapa kasus, sengaja menghalangi memproses perubahan dan menafsirkan data menunjukkan ketidakefektifan diusulkanperubahan proses.

2. Change persistence ( Perubahan persitensi) Meskipun dimungkinkan untuk memperkenalkan perubahan proses awalnya, itu adalah umum untuk inovasi proses untuk dibuang setelah waktu yang singkat dan untuk proses untuk kembali ke kondisi sebelumnya. 

 


 

Manajemen Versi dan Pembangunan Sistem + Video

www.lyquidity.com

Manajemen versi adalah proses melacak/mengidentifikasi versi yang berbeda dari komponen software / item konfigurasi sistem di mana komponen ini digunakan. Hal ini juga memastikan bahwa perubahan yang dibuat oleh berbagai pengembang untuk versi ini tidak saling mengganggu. Untuk proses manajemen versi terdapat proses pengelolaan codelines dan baseline.

Pada dasarnya, codeline adalah urutan versi source code dengan versi yang berasal dari versi sebelumnya. Codelines biasanya berlaku untuk komponen sistem sehingga ada versi yang berbeda dari masing-masing komponen. Baseline dapat ditentukan menggunakan bahasa konfigurasi, yang memungkinkan kita untuk menentukan komponen apa yang termasuk dalam versi sistem tertentu. Hal ini dimungkinkan untuk menentukan versi komponen tertentu. Baseline penting karena Anda sering harus membuat ulang versi tertentu dari sistem yang lengkap. Misalnya, lini produk dapat diturunkan sehingga ada versi sistem individual untuk pelanggan yang berbeda. Anda mungkin harus membuat ulang versi yang dikirimkan ke pelanggan tertentu jika terdapat laporan bug di sistem yang harus diperbaiki.

Untuk mendukung manajemen versi, Anda harus selalu menggunakan alat manajemen versi (sistem kontrol sumber kode). Alat-alat ini mengidentifikasi, menyimpan, dan mengontrol akses ke versi yang berbeda dari komponen. Ada banyak sistem manajemen versi yang tersedia seperti CVS dan Subversion

Sistem manajemen versi biasanya memberikan berbagai fitur:

1.       Identifikasi versi dan rilis. Versi yang telah berhasil akan diidentifikasi ketika mereka diserahkan ke sistem. Beberapa sistem CM juga memungkinkan asosiasi atribut dengan versi (misalnya, ponsel, smallscreen), yang juga dapat digunakan untuk identifikasi versi. Sebuah sistem identifikasi yang konsisten penting karena menyederhanakan masalah mendefinisikan konfigurasi. Itu membuat lebih mudah untuk menggunakan referensi singkatan

2.       manajemen penyimpanan. Untuk mengurangi ruang penyimpanan versi dari komponen yang berbeda, sistem manajemen versi biasanya menawarkan fasilitas manajemen penyimpanan. Fitur manajemen penyimpanan di sistem kontrol versi mengurangi ruang disk yang diperlukan untuk mempertahankan semua versi sistem. Ketika versi baru dibuat, sistem hanya menyimpan delta (daftar perbedaan) antara versi baru dan versi yang lebih tua yang digunakan untuk membuat versi baru.

3.       Rekaman Perubahan. Semua perubahan yang dibuat ke kode dari sistem atau komponen dicatat dan terdaftar. Dalam beberapa sistem, perubahan ini dapat digunakan untuk memilih versi sistem tertentu. Ini melibatkan komponen penandaan dengan kata kunci yang menjelaskan perubahan yang dilakukan.

4.       Pembangunan Independent. pengembang yang berbeda dapat bekerja pada komponen yang sama pada waktu yang sama. Sistem manajemen versi melacak komponen yang telah diperiksa untuk mengedit dan memastikan bahwa perubahan yang dibuat untuk komponen oleh pengembang yang berbeda tidak mengganggu. Kebanyakan pengembangan perangkat lunak adalah kegiatan tim, sehingga situasi sering timbul di mana anggota tim yang berbeda bekerja pada komponen yang sama pada waktu yang sama.

5.       Dukungan Project. Sebuah sistem manajemen versi dapat mendukung pengembangan beberapa proyek, yang berbagi komponen. Dalam sistem pendukung proyek, seperti CVS (Vesperman, 2003), adalah dapat memungkinkan untuk check in dan check out pada semua file yang terkait dengan proyek daripada harus bekerja dengan satu file atau direktori pada suatu waktu.

www.kmccontrols.com

Pembangunan sistem adalah proses menciptakan sistem executable lengkap dengan menyusun dan menghubungkan komponen sistem, komponen eksternal, file konfigurasi, dll. Pembangunan Sistem dan manajemen versi harus berkomunikasi agar proses pembangunan dapat memeriksa versi komponen dari repositori yang dikelola oleh sistem manajemen versi.

Ada banyak tool dan pembangunan sistem tersedia yang dapat memberikan beberapa atau berbagai fitur berikut:

1.    Membangun generasi skrip. Jika perlu, membangun sistem harus menganalisis program yang sedang dibangun, mengidentifikasi komponen terkait, dan secara otomatis menghasilkan skrip (kadang-kadang disebut file konfigurasi). Sistem ini juga harus mendukung terciptanya manual dan pengeditan membangun script.

2.    Sistem integrasi manajemen versi. Pembanguan Sistem harus memeriksa versi yang diperlukan komponen dari sistem manajemen versi.

3.     Rekompilasi Minimal. Pembanguan Sistem harus bekerja dan apakah kode sumber perlu dikompilasi ulang dan mengatur kompilasi jika diperlukan.

4.  Pembuatan Sistem Executable membangun sistem harus menghubungkan file kode objek dikompilasi dengan satu sama lain dan dengan file lainnya yang diperlukan, seperti perpustakaan dan file konfigurasi, untuk menciptakan sebuah sistem executable.

5.       Uji otomatisasi Beberapa Pembanguan sistem otomatis dapat menjalankan tes menggunakan alat tes otomatisasi seperti JUnit otomatis. Ini memeriksa bahwa membangun belum 'rusak' oleh perubahan.

6.   Pelaporan membangun sistem harus memberikan laporan tentang keberhasilan atau kegagalan membangun dan tes yang telah dijalankan.

7.   Generasi  Dokumentasi membangun sistem mungkin dapat menghasilkan catatan rilis tentang membangun dan sistem halaman bantuan.
      Berikut video singkat tentang penjelasan manajemen versi yang saya buat :

Manajemen Resiko

Video Persentasi

Chapter 22 

Manajemen Proyek "Menejemen Resiko"

Menejemen proyek merupakan bagian penting dalam sebuah proyek perangkat lunak, ketika sebuah proyek perangkat lunak di manajemen dengan baik belum tentu produk yang di hasilkan akan berkualitas baik tetapi jika tidak di manajemen dengan baik maka dapat di pastikan produk yang di hasilkan tidak akan berkualitas atau gagal memenuhi kebutuhan klien. Manajemen proyek sendiri di tanggung jawab kan pada seorang menejer proyek yang bertugas memastikan semua proses dalam pembuatan perangkat lunak serta mengatasi kendala kendala yang akan di hadapi dalam pembuatan perangkat lunak. Manajer proyek memiliki tanggung jawab lain di beberapa tahapan dalam suatu proses pembuatan perangkat lunak di antara nya : 

* Perencanaan Proyek

* Pelaporan Proyek

* Manajemen Resiko

* Manajemen Tim

* Penulisan Proposal

Pada beberapa tahapan yang di tanggung jawabi oleh menejer proyek saya akan lebih mendalami tentang salah satu nya yaitu "Manajemen Resiko"

Manajemen resiko merupakan salah satu tanggung jawab dari seorang menejer proyek dimana seorang menejer proyek di haruskan dapat mengantisipasi kendala yang akan mencul dalam suatu pembuatan proyek perangkat lunak agar kualitas dari produk yang di hasilkan. Resiko yang di hadapi oleh tim pembuat perangkat lunak ada 3 kategori di antara nya :

*Resiko dari proyek itu sendiri 

*Resiko dari produk yang dihasilkan

*Resiko dari bisnis yang di jalankan

Manajemen resiko sendiri terdiri dari beberapa bagian di antara nya :

~ Identifikasi Resiko

   Resiko yang terdapat dalam sebuah proses pembuatan perangkat lunak harus di kenali agar untuk        tidak lanjut nya mudah untuk di rencanakan. Ada 6 resiko yang mungkin terjadi di antara nya :            resiko dari teknologi yang di gunakan, resiko dari individu dalam tim, resiko dari organisasi atau        tim itu sendiri, resiko dari alat yang di gunakan, resiko dari kebutuhan yang di harapkan klien, dan      resiko dari estimasi penjadwalan.

~ Analisis Resiko

   Setelah di identifikasi kemudian resiko tersebut di analisi oleh menejer proyek untuk membuat            penilaian apakah resiko yang di hadapi dapat mengganggu proses pembuatan proyek perangkat          lunak itu sendiri.

~ Tindaklanjut terhadap Resiko

   Setelah perhitungan terhadap resiko yang di hadapi selesai maka dapat di lakukan tindak lanjut            terhadap resiko tersebut. Ada beberapa strategi untuk menindaklanjuti resiko yaitu : strategi                menghindari resiko, strategi mengurangi resiko, dan rencana cadangan.

~ Monitoring Resiko

   Setelah penindaklanjutan dilakukan maka untuk memastikan semua proses dalam pembuatan              perangkat lunak berjalan dengan lancar maka manajer proyek harus melakukan monitoring atau          pengawasan agar produk yang di hasilkan berkualitas serta sesuai dengan keinginan dari klien. 

Sumber : Software Engineering  9th Edition (Ian Sommerville)

Ulasan dan Inspeksi kualitas dalam Perangkat Lunak

         Ulasan dan inspeksi dalam perangkat lunak adalah bagian langkah  untuk memeriksa kualitas sebuah proyek. Hal hal yang termasuk dalam ulasan dan inspeksi perangkat lunak seperti melibatkan memeriksa perangkat lunak, dokumentasi , catatan proses dan lain lain. Hal ini untuk menemukan kesalahan dan kelalaian untuk melihat apakah standar kualitasnya sudah tercapai. ulasan dan inspeksi digunakan bersamaan dengan pengujian program, sebagai bagian dari proses umum verifikasi perangkat lunak dan validasi.

        Tujuan adanya Ulasan dan inspeksi dalam perangkat lunak adalah agar hasil nya dapat menjadi tinjauan bagi manajer proyek untuk dapat membuat keputusan perencanaan dan pengalokasikan sumber daya untuk proses pembangunan. Sehingga hasilnya dapat untuk meningkatkan kualitas perangkat lunak, bukan untuk menilai kinerja orang di tim pengembangan.

Dalam Ulasan biasanya terdiri dari 3 fase yaitu :
1. Pre-view : ulasan terkait persiapan dan perencanaan untuk peninjauan
2. Kajian Pertemuan : peninjauan langsung dengan menghasilkan catatan komentar (dokumen)
3. Pasca-review : ulasan untuk mengatasi permasalah yang ada.
Setiap fase dalam ulasan memerlukan sebuah tim peninjau yan memiliki peran dan tugasnya masing masing sehingga pendekatan dalam ulasan kualitas menjadi lebih baik.

         Bagian berikutnya adalah Inspeksi. Inspeksi perangkat lunak merupakan tahap verifikasi dan validasi sebuah perangkat lunak. Tahap inspeksi adalah untuk mendeteksi dan dan mengidentifikasi keganjilan pada perangkat lunak. Salah satu cara yang paling efektif dalam inspeksi adalah dengan menguji kasus atau sistem secara langsung. Inspeksi dilakukan secara rinci melibatkan tim peninjau, tim pengembang dan stakeholder terkait. Agar selama pemeriksaan sesuai dengan spesifikasi awal pada perencanaan program. Jika inspeksi dilakukan dalam bentuk tim maka, dalam menemukan sebuah cacat harus adanyan hubungan erat antar tim agar tidak ada kesalahan dalam pembuatan keputusan masing masing.

Menentukan Kualitas Perangkat Lunak

         Kualitas atau biasa disebut sebagai mutu adalah tentang baik buruk nya derajat sesuatu hal. Kualitas adalah salah satu hal yang harus diperhitungkan dalam berbagai proses ataupun tehnik bisnis. Bahkan seorang sosok visionaris dunia yaitu Steve Jobs pernah menyampaikan bahwa :
"Quality is more important than quantity. One home run is much better than two doubles".

           Padahal home run dengan doubles itu dalam permainan baseball adalah hal  yang sama dari sisi point. Namun bagi penonton atau penggemar 2 hal itu  memiliki nilai yang berbeda dari kenikmatan menonton pertandingan. Begitu pula dalam pengembangan software, kualitas merupakan suatu hal yang sangat penting. namun sulit untuk menentukan seberapa besar kualitas sebuah software. Hal itu disebabkan oleh beberapa hal seperti :
1. Sulitnya menulis dengan lengkap spesifikasi sebuah perangkat. Misalkan menginginkan sebuah software yang aman, sejauh mana keamanan tersebut tidak dapat dituliskan
2. Dalam spesifikasi adanya kesenjangan antara stakeholder. Sehingga kenyamanan masing masing sulit untuk diukur. Misalkan dalam suatu perusahan terdapat bagian IT nya yang merasa nyaman terhadap software , namun belum tentu atasan merasa nyaman juga menggunakan software.
3. Sulitnya mengukur karakteristik kualitas. 

Sehingga dapat disimpulkan dalam menentukan kualitas sebuah software adalah berdasarkan tergantung penilaian subyektif dari pemakainya.

         Dalam penilaian sebuah software yang biasanya diwakili oleh Tim Manajemen  Mutu, sebuah produk dinilai tidak akan pernah memenuhi spesifikasi , sehingga jika produk "hampir benar" maka itu tergolong software yang dapat diterima. Selain hal tersebut banyak pula yang harus dipertimbangkan dalam penilaian kualitas software seperti tujuan software, dokumentasi software, keandalan software dan lain lain. Kualitas subjektif dari perangkat lunak sistem sebagian besar didasarkan pada karakteristik non-fungsional.

          Menurut Boehm,(1978) menyatakan bahwa ada 15 atribut penentuan kualitas perangkat lunak yang penting, seperti Keselamatan, Understandability , Portabilitas, Keamanan,  Testability,  Usability, Keandalan,  Kemampuan beradaptasi,  Reusability, Ketahanan,  Modularity,  Efisiensi, Kekokohan, Kompleksitas, dan Learnability. Semua atribut ini tidak memungkin kan bisa diopltimalkan semua, misalkan kita meningkatkan ketahanan bisa saja fungsi yang lain melemah akibat peningkatan ketahanan. Sehingga perlu mendefinisikan kualitas terpenting dalam sebuah perangkat lunak.

Pentingnya Teamwork dalam membangun Project Management

Apa itu Teamwork ?

“ Kau yang disana yang berjiwa lemah, mendekat padaku dan raih tanganku karena kudisini pantang menyerah. Bersatu kita kuat, bersama kita hebat dan tak terkalahkan “

( Bondan Prakoso & Fade 2 Black )

dari kutipan diatas dapat kita ketahui beberapa hal, yaitu suatu individu apa bila bersatu untuk mencapai suatu tujuan, maka tidak ada yang tidak mungkin bagi mereka, karena dengan bersama akan jadi lebih hebat dan tak terkalah. Nah itulah makna dari sebuah "Teamwork". Jadi dapat disimpulkan bahwa teamwork bisa diartikan sebagai kerja tim atau kerjasama, team work atau kerja sama tim merupakan bentuk kerja kelompok dengan keterampilan yang saling melengkapi serta berkomitmen untuk mencapai  misi yang sudah disepakati sebelumnya untuk mencapai tujuan bersama secara efektif dan efisien.

Seperti Apa Teamwork dalam membangun Project Management?
Kebanyakan perangkat lunak profesional yang dikembangkan oleh tim proyek tersebut berkisar dalam ukuran dua sampai beberapa ratus orang. Namun, karena jelas tidak mungkin bagi setiap orang dalam sebuah grup besar untuk bekerja sama dalam satu masalah, tim besar biasanya dibagi menjadi beberapa kelompok. Setiap kelompok bertanggung jawab untuk mengembangkan bagian dari sistem secara keseluruhan. Sebagai aturan umum, kelompok proyek rekayasa perangkat lunak tidak boleh memiliki lebih dari 10 anggota. Ketika kelompok-kelompok kecil yang digunakan, masalah komunikasi akan berkurang. Semua orang tahu setiap orang dan seluruh kelompok bisa mendapatkan sekitar meja untuk pertemuan untuk membahas proyek dan perangkat lunak yang mereka kembangkan. Sebuah kelompok yang baik adalah kompak dan memiliki semangat tim. Orang-orang yang terlibat termotivasi oleh keberhasilan kelompok maupun oleh tujuan pribadi mereka sendiri.

Apa manfaat membuat Group Kohesif ? 
Manfaat membuat grup kohesif adalah:

• kelompok dapat menetapkan standar kualitas tersendiri. Karena standar ini areestablished dengan konsensus, mereka lebih mungkin untuk diamati dari standar eksternal yang dikenakan pada kelompok.
• Individu belajar dari dan mendukung satu sama lain. Orang dalam kelompok saling belajar. Hambatan yang disebabkan oleh ketidaktahuan diminimalkan sebagai saling belajar didorong.
• Pengetahuan digunakan bersama. Kontinuitas dapat dipertahankan jika anggota kelompok meninggalkan. Orang lain dalam kelompok dapat mengambil alih tugas-tugas penting dan memastikan bahwa proyek ini tidak terlalu terganggu.
• Merefraktorisasi dan perbaikan terus-menerus sangat dianjurkan. anggota kelompok bekerja secara kolektif untuk memberikan hasil yang berkualitas tinggi dan memperbaiki masalah, terlepas dari individu yang awalnya dibuat desain atau program. 

Faktor apa saja yang mempengaruhi "Teamwork" dari suatu Project Management ?
Baik atau tidak satu kelompok efektif ini tergantung, sampai batas tertentu, pada jenis proyek dan organisasi yang melakukan pekerjaan. Jika sebuah organisasi dalam keadaan kekacauan dengan reorganisasi konstan dan ketidakamanan kerja, sangat sulit bagi anggota tim untuk fokus pada pengembangan perangkat lunak. Namun, terlepas dari proyek dan masalah organisasi.
ada tiga faktor umum yang mempengaruhi tim kerja:

• Orang-orang dalam kelompok. Anda perlu campuran orang dalam kelompok proyek pengembangan perangkat lunak melibatkan kegiatan beragam seperti negosiasi dengan klien, pemrograman, pengujian, dan dokumentasi.
• Kelompok organisasi. Sebuah kelompok harus diatur sehingga individu dapat berkontribusi untuk yang terbaik dari kemampuan dan tugas mereka dapat diselesaikan seperti yang diharapkan.
• Teknis dan manajerial komunikasi. komunikasi yang baik antara anggota kelompok, dan antara tim rekayasa perangkat lunak dan stakeholder proyek lainnya, adalah penting.

berdasarkan penjelasan diatas jadi dapat disimpulkan bahwa kelompok pengembangan perangkat lunak harus cukup kecil dan kohesif. Faktor-faktor utama yang mempengaruhi efektivitas satu kelompok adalah orang-orang dalam kelompok itu, cara yang terorganisir, dan komunikasi antara anggota kelompok. Komunikasi dalam suatu kelompok dipengaruhi oleh faktor-faktor seperti status anggota kelompok, ukuran kelompok, komposisi gender kelompok, kepribadian, dan saluran komunikasi yang tersedia.