Aktivitas Pemeliharaan Perangkat Lunak

Training : melatih para pemangku kepentingan tentang implementasi sistem.

Consultative : Biaya dan lamanya waktu diperkirakan untuk pekerjaan pemeliharaan, personel menjalankan help desk, pelanggan dibantu untuk mempersiapkan permintaan pekerjaan pemeliharaan, dan personel membuat pengetahuan ahli tentang sumber daya yang tersedia dan sistem kepada orang lain dalam organisasi untuk meningkatkan efisiensi .

Evaluative : kegiatan umum termasuk meninjau kode program dan dokumentasi, memeriksa efek riak dari perubahan yang diusulkan, merancang dan melaksanakan tes, memeriksa dukungan pemrograman yang disediakan oleh sistem operasi, dan menemukan data yang diperlukan dan debugging.

Reformative :meningkatkan keterbacaan dokumentasi, membuat dokumentasi konsisten dengan perubahan lain dalam sistem, menyiapkan bahan pelatihan, dan menambahkan entri ke kamus data.

Updative : menggantikan dokumentasi yang sudah ketinggalan zaman dengan dokumentasi yang mutakhir, membuat semi formal, misalnya, di UML untuk mendokumentasikan kode program saat ini, dan memperbarui dokumentasi dengan rencana pengujian.

Groomative: mengganti komponen dan algoritma dengan yang lebih efisien dan sederhana, memodifikasi konvensi untuk penamaan data, mengubah otorisasi akses, menyusun kode sumber, dan melakukan backup.

Preventive :melakukan perubahan untuk meningkatkan rawatan dan membangun dasar untuk melakukan transisi di masa depan ke teknologi yang muncul.

Performance : meningkatkan waktu sistem dan mengganti komponen dan algoritma dengan yang lebih cepat. 

Adaptive : Aktivitas biasa dalam jenis ini mem-porting perangkat lunak ke platform eksekusi yang berbeda dan meningkatkan pemanfaatan komponen COTS. 

Reductive : mengurangi jumlah input data ke sistem dan mengurangi jumlah data yang dihasilkan oleh sistem. 

Corrective :  Kegiatan biasa dalam jenis ini adalah mengoreksi bug yang diidentifikasi, menambahkan strategi pemrograman defensif dan memodifikasi cara-cara pengecualian ditangani.

Enhancive : Menambah dan memodifikasi aturan bisnis untuk meningkatkan fungsionalitas sistem yang tersedia bagi pelanggan dan menambahkan aliran data baru ke dalam atau keluar dari perangkat lunak.

 

 

Jenis Pemeliharaan Perangkat Lunak

Perawatan korektif : Tujuan pemeliharaan korektif adalah untuk memperbaiki kegagalan: kegagalan pemrosesan dan kegagalan kinerja.

  • Isolasi dan koreksi elemen yang rusak dalam perangkat lunak. 
  • Produk perangkat lunak diperbaiki untuk memenuhi persyaratan. 
  • Mengoreksi program yang membatalkan atau menghasilkan hasil yang salah. 
  • Proses reaktif, yang berarti pemeliharaan korektif dilakukan setelah mendeteksi cacat pada sistem.

Pemeliharaan adaptif. Tujuan pemeliharaan adaptif adalah untuk memungkinkan sistem beradaptasi dengan perubahan dalam lingkungan datanya atau lingkungan pemrosesan.

  • Memodifikasi perangkat lunak untuk berinteraksi dengan benar dengan lingkungan yang berubah
  • Pemeliharaan adaptif meliputi perubahan sistem, penambahan, penghapusan, modifikasi, ekstensi, dan peningkatan untuk memenuhi kebutuhan lingkungan di mana sistem harus beroperasi.

Perawatan yang penyempurnaan. Tujuan dari pemeliharaan yang sempurna adalah untuk membuat berbagai perbaikan, yaitu, pengalaman pengguna, efisiensi pemrosesan, dan pemeliharaan

  • Program dapat dibuat lebih mudah dibaca untuk pengalaman pengguna yang lebih baik; 
  • program dapat dimodifikasi untuk membuatnya lebih cepat, sehingga meningkatkan efisiensi pemrosesan; 
  • program dapat direstrukturisasi untuk meningkatkan keterbacaannya, sehingga meningkatkan kemampuan pemeliharaannya. 
  • restrukturisasi kode, membuat dan memperbarui dokumentasi, dan mengatur sistem untuk meningkatkan kinerja. Kadang juga disebut “pemeliharaan demi pemeliharaan” atau “rekayasa ulang”

Pemeliharaan preventif. Tujuan pemeliharaan preventif adalah untuk mencegah terjadinya masalah dengan memodifikasi produk perangkat lunak

  • Mengidentifikasi risiko di masa depan dan masalah yang tidak diketahui, dan mengambil tindakan agar masalah tersebut tidak terjadi. 
  • Sebagai contoh : gaya pemrograman yang baik dapat mengurangi dampak perubahan, sehingga mengurangi jumlah kegagalan. Oleh karena itu, program dapat direstrukturisasi untuk mencapai gaya yang baik untuk mempermudah pemahaman program nantinya. 
  • Pemeliharaan preventif sangat sering dilakukan pada sistem perangkat lunak yang kritis dan aman 

 

Analisa Dampak

Permintaan perubahan (CR: Change Request) mengaktifkan proses organisasi untuk memodifikasi sistem perangkat lunak untuk melakukan pemeliharaan.  Proses pemeliharaan dimulai dengan melakukan analisis dampak. Analisis dampak pada dasarnya berarti mengidentifikasi komponen-komponen yang terkena dampak oleh CR . Analisis dampak memungkinkan pemahaman dan penerapan perubahan dalam sistem dan digunakan untuk memperkirakan biaya dan merencanakan jadwal.

Alasan melakukan analisa dampak:

  • Untuk memperkirakan biaya mengeksekusi permintaan perubahan.  
  • Untuk menentukan apakah beberapa bagian penting dari sistem akan terkena dampak karena perubahan yang diminta. 
  • Untuk mencatat riwayat informasi terkait perubahan untuk evaluasi perubahan di masa mendatang. 
  • Untuk memahami bagaimana item perubahan terkait dengan struktur perangkat lunak. 
  • Untuk menentukan bagian-bagian dari perangkat lunak yang perlu dikenakan pengujian regresi setelah perubahan dilakukan.

Cara melihat analisa dampak:

  • Richard Turver dan Malcolm Munro  mendefinisikan analisis analisis dampak penilaian terhadap perubahan kode sumber modul pada modul lain dari sistem. Hal ini menentukan ruang lingkup perubahan dan memberikan ukuran kompleksitasnya.
  • Queille mendefinisikan analisis dampak sebagai tugas menilai dampak dari melakukan serangkaian perubahan pada sistem perangkat lunak.
  • Bohner dan Arnold  mendefinisikan analisis dampak sebagai mengidentifikasi konsekuensi potensial dari suatu modifikasi atau menemukan entitas yang akan dimodifikasi untuk mencapai perubahan.

Implementasi permintaan perubahan berdampak pada semua jenis artefak, termasuk kode sumber, persyaratan, dokumentasi desain, dan skenario pengujian. Oleh karena itu, informasi keterlacakan analisis dampak dapat digunakan dalam melakukan analisis dampak.

Gotel dan Finkkelstein mendefinisikan keterlacakan sebagai kemampuan untuk menggambarkan dan mengikuti kehidupan artefak di kedua arah maju dan mundur. Bohner dan Arnold mendefinisikan keterlacakan sebagai kemampuan untuk melacak antara artefak perangkat lunak yang dihasilkan dan dimodifikasi selama siklus hidup produk perangkat lunak. Dengan demikian, keterlacakan membantu pengembang perangkat lunak memahami hubungan di antara semua artefak perangkat lunak dalam suatu proyek. Setelah mengidentifikasi dokumen tingkat tinggi tentang fitur yang akan dimodifikasi, dengan menggunakan konsep keterlacakan, pengelola menempatkan entitas yang perlu diubah. Contoh entitas tersebut adalah desain dan kode sumber.

Topik yang terkait dengan analisis dampak adalah analisis efek riak. Efek riak berarti bahwa modifikasi pada variabel tunggal mungkin memerlukan beberapa bagian dari sistem perangkat lunak untuk dimodifikasi. Konsep efek riak memiliki relevansi dalam evolusi perangkat lunak karena menyangkut perubahan dan efeknya. Analisis efek riak mengungkapkan apa dan di mana perubahan terjadi. Pengukuran efek riak dapat memberikan informasi berikut tentang sistem perangkat lunak yang berkembang:

(i) antara versi berturut-turut dari sistem yang sama, pengukuran efek riak akan memberi tahu kami bagaimana kompleksitas perangkat lunak telah berubah;

(ii) ketika modul baru ditambahkan ke sistem, pengukuran efek riak pada sistem akan memberi tahu kami bagaimana kompleksitas perangkat lunak telah berubah karena penambahan modul baru.

The Power of Refactoring

Project yang sedang dikerjakan sekarang adalah membuat Mobil App untuk membaca score (notasi musik) dengan beberapa fitur seperti pengaturan tempo, looping, environment, change instrument, adding annotation dan sebagainya. Masalahnya kemudian,hampir semua developer yang terlibat adalah backend programmer yang tidak punya pengalaman mengerjakan mobile app dan juga tidak familiar menggunakan pattern MVVM. Ya, projectnya menggunakan Xamarin dan MvvmCross framewrok.

Nah, pada sprint kesekian project pengerjaan projectnya semakin melambat. Salah satu penyebabnya adalah beberapa task mengharuskan menunggu pengerjaan developer yang lain karena mengharuskan bekerja pada class/module yang sama. Begitu juga bagian FrontEnd mengaku kesulitan dalam mengintegrasikan designnya karena harus bersentuhan dengan code program yang berhubungan dengan funcionality.

Akhirnya diputuskan dalam satu sprint di adakan refactor besar-besaran, tidak ada penambahan fitur. Refacor focus pada aspek Single Responsibility dan Separation of Concern. Juga melengkapi unit testing sehingga dapat dengan mudah dideteksi mana code yang termasuk smell code. Ya, salah satu tandanya adalah jika code tersebut tidak testable. Ternyata setelah mengadakan refactor yang cukup signifikan, Sprint berikutnya pekerjaan menjadi lebih mudah dan cepat.

Error When Call IMvxCommand in Unit Testing

Kode unit testing di bawah ini ketika memanggil SampleClickCommand menyebabkan error Null Object Reference.

[TestMethod]
       public void WhenPlayClick_SampleMusicIsPlaying()
       {
           _mockAudioService.Setup(arg => arg.PlayMusic(It.IsAny<string>()));
           _mockAudioService.Setup(arg => arg.IsMusicPlaying).Returns(true);
           _scoreLibraryCellViewModel = new ScoreLibraryCellViewModel(_mockAudioService.Object, _mockFileAccessService.Object, _mockDialogService.Object);
           _scoreLibraryCellViewModel.SampleClickCommand.Execute();
 
 
 
       }

Untuk meresolve error ini register type untuk IMvxStringToTypeParser saat initialisasi.

var ioc = MvxSimpleIoCContainer.Initialize();
          ioc.RegisterSingleton<IMvxStringToTypeParser>(new MvxStringToTypeParser());

 

How to update ObservableCollection in MvvmCross when property of Item is changes

Ketika develop android app menggunakan Xamarin. Saya menggunakan MvvmCross sebagai framework. Dalam MvvM patterna kita akan selalu berurusan dengan Binding data antara View(UI)- dan ViewModel.

Saat saya melakukan binding data ObservableColletion pada ViewModel dengan ListView pada View ternyata event Collection Changes pada ObservableCollection tidak di rise ketika ada perubahan pada property di itemnya. Jadi setelah saya baca-baca, event Collection Changes ini hanya di rise ketika ada penambahan atau pengurangan jumlah item pada ObservableCollection.

Layout View.

 
 

ViewModel:

ProductListItemViewModel:

public class ProductListItemViewModel : MvxViewModel
   {
       
       public int Id { get; set; }
 
       public string Name { get; set; }
 
       private decimal _quantity;
 
       
       public decimal Quantity
       {
           get
           {
               return _quantity;
 
           }
           set
           {
               _quantity = value;
               RaisePropertyChanged(() => Quantity);
               
           }
       }

ProductListViewModel.

private ObservableCollection _displayedProducts;
       public ObservableCollection DisplayedProducts
       {
           get { return _displayedProducts; }
           set
           {
               _displayedProducts = value;
               RaisePropertyChanged(() => DisplayedProducts);
               Calculate();
           }
       }
       private void Calculate()
       {
           decimal totalSales = 0;
           decimal totalGst = 0;
           foreach (var product in DisplayedProducts)
           {
               var sales = (product.Price * product.Quantity);
               totalSales += sales;
               if (product.GstFlag)
               {
                   totalGst += sales * Utility.Constants.GST_RATE;
               }
           }
           TotalSales = totalSales;
           TotalGst = totalGst;
       }
       private decimal _totalSales;
       public Decimal TotalSales
       {
           get
           {
               
               return _totalSales;
           }
           set
           {
               _totalSales = value;
               RaisePropertyChanged(() => TotalSales);
           }
           
       }
       private decimal _totalGst;
       public Decimal TotalGst
       {
           get
           {
 
               return _totalGst;
           }
           set
           {
               _totalGst = value;
               RaisePropertyChanged(() => TotalGst);
           }
 
       }

Karena saya ingin ketika ada perubahan quantity pada Product (inputnya ditrigger dari editable text field pada listview), calculate() method dipanggil lagi sehingga property TotalSales dan TotalGst akan diupdate otomatis.

Saya menemukan solusinya dengan menset event PropertyChanges pada ProductListItemViewModel sebelum menambahkannya pada ObservableCollection seperti ini.

productViewItemModel.PropertyChanged += ProductViewItemModel_PropertyChanged;
               productViewModels.Add(productViewItemModel);
private void ProductViewItemModel_PropertyChanged(object sender, System.ComponentModel.PropertyChangedEventArgs e)
        {
            Calculate();
        }

code lengkapnya ada di https://github.com/adnansetiawan/sales-app-xamarin