Artikel ini membahas metode menggunakan 1C DSS (Sistem Desain Aplikasi) untuk menilai durasi dan biaya proyek menggunakan metode COCOMOII.
Bagaimana membenarkan pelanggan bahwa penilaian Anda tentang waktu proyek itu objektif?
Bagaimana mengukur margin suatu proyek sebelum dimulai, pada tahap presale?
Bagaimana cara mengevaluasi rentang perdagangan dengan harga proyek untuk mencegah kerugian?
Bagaimana cara menghitung secara obyektif kebutuhan proyek bagi anggota tim yang bukan pengembang (analis bisnis, metodologi, penulis teknis, dll.), Bagaimana memformalkan hasil pekerjaan mereka dengan cara yang paling sederhana dan terjangkau?Daftar isi
- Entri.
- Masalah utama menggunakan 1C DSS pada saat ini.
- Kenapa COCOMOII?
- Mengapa 1C DSS?
- Kursus Singkat COCOMOII
- Transisi dari penilaian tenaga kerja pengembang ke penilaian tenaga kerja analis dan ahli metodologi
- Kodesemu
- 1 DSS dan pseudo-code.
- Ringkasan
Entri
Sistem Desain Aplikasi 1C diluncurkan di pasar 6 tahun yang lalu dan pada bulan Juli 2019 ia berkembang ke versi 2. Berdasarkan teknologi SADT dan model pengembangan berjenjang. Namun, ini memungkinkan Anda untuk memimpin pengembangan Scrum / Agile di setiap tahapan.
Dirancang untuk proyek yang rumit dan panjang yang dilaksanakan oleh tim multi-komponen dengan penggantian personel yang sering. Ini mencakup fungsionalitas manajemen proyek, deskripsi proses bisnis, merancang arsitektur dan fungsionalitas sistem informasi, pengembangan perangkat lunak dan pemeliharaan IP, serta pengujian otomatis berdasarkan Vanessa / Gherkin.
Pertama-tama, ini berguna untuk integrator sistem dan pewaralaba, dan kedua untuk semua organisasi yang melakukan pengembangan dan pemeliharaan independen IP mereka sendiri dengan keterlibatan pemain eksternal.
Masalah utama menggunakan 1C DSS saat ini
Masalah utama menggunakan 1C DSSR saat ini (versi 1 terutama digunakan) adalah penggunaan yang sangat salah dari 1C DSS sebagai teknologi.
1C DSS paling sering digunakan pada tingkat fungsionalitas yang ditujukan untuk pengembang, paling baik untuk arsitek. Perannya sering turun ke deskripsi dan pengembangan "Fungsi" dari sistem dan pembentukan tugas untuk programmer. Ini adalah kesalahan pendekatan untuk bekerja dengan DSS.
Sistem yang ada di pasar (JIRA, dll.) Melakukan pekerjaan yang baik dalam mengatur tugas untuk programmer dan memproses tiket pengguna. Dengan penggunaan ini, pengembang DSS memiliki tambahan birokrasi lain yang menghabiskan waktu, yang membutuhkan waktu dari pengkodean "murni".
Pengembang berkewajiban untuk menjelaskan fungsionalitas sistem yang diimplementasikan / diselesaikan untuk memastikan pengaturan tugas bagi programmer dengan tautan ke objek metadata ("bahasa umum" dalam istilah Eric Evans dalam karyanya "Desain Berorientasi Objek (DDD). Penataan sistem perangkat lunak yang kompleks").
Pada saat yang sama, tugas dari bagian lain dari tim proyek - manajer proyek, analis bisnis, ahli metodologi hampir sepenuhnya diabaikan. Sayangnya, kita dapat mengatakan bahwa bahkan 1C itu sendiri dalam versi 2.0 dari DSS sangat mengurangi fungsi untuk kategori peserta ini, secara signifikan mengubah model DSS dibandingkan dengan versi 1.0 terhadap pengembang dan penguji (misalnya: persyaratan dan objek data secara eksplisit dihapus).
Namun demikian, masalah penggunaan DSS secara penuh dan penuh adalah akut. Dalam artikel ini, khususnya, kami akan mempertimbangkan bagaimana teknologi untuk memperkirakan persyaratan dan biaya proyek menggunakan metode COCOMOII dapat digunakan dalam 1C DSS.
Semua orang ingin tahu berapa lama sebuah proyek dapat diselesaikan, tentang hal itu pelanggan sendiri tidak dapat mengatakan apa yang akhirnya dia inginkan, dan sejauh mana masuk akal untuk melakukan tawar-menawar dengan pelanggan?
Dan bagaimana meyakinkan pelanggan bahwa waktu dan biaya yang diusulkan dapat dibenarkan? Namun, yang terakhir tidak berbahaya untuk kita ketahui sendiri.
Dan yang paling penting, bagaimana cara menghitung secara obyektif kebutuhan proyek bagi anggota tim yang bukan pengembang (analis bisnis, metodologi, penulis teknis, dll.), Bagaimana memformalkan hasil pekerjaan mereka dengan cara yang paling sederhana dan terjangkau?
Kenapa COCOMOII?
Pelanggan dalam industri apa pun lebih suka memiliki penilaian biaya dan waktu proyek yang objektif, masuk akal dan diterima secara umum. Mereka ingin melihat koneksi proyek mereka dengan pengalaman integrator sistem di proyek-proyek sebelumnya. Pada saat yang sama, pelanggan yang jarang memiliki gagasan yang jelas tentang hasil akhir proyek, tetapi dalam proyek-proyek dengan pengembangan model konseptual itu jelas tidak. Dan integrator sistem tidak memiliki.
Bagaimana cara mengevaluasi waktu dan biaya pada tahap presale tanpa adanya informasi? Dan dalam perjalanan proyek, dengan mempertimbangkan perubahan akun (momok semua proyek)?
Metode COCOMOII memungkinkan Anda untuk membuat penilaian seperti itu, dengan mempertimbangkan akumulasi pengalaman integrator sistem, dan dengan cara yang paling sederhana, sementara dengan cepat, selama jalannya proyek, membuat spesifikasi harga / waktu dan membenarkannya untuk kesepakatan dengan pelanggan.
Mengapa 1C DSS?
Masalahnya adalah bahwa 1C DSS didasarkan pada SADT dan teknologi "bahasa umum" (ini dijelaskan lebih rinci dalam artikel terpisah saya). SADT yang mengintegrasikan proses pemodelan dengan proses pengembangan berdasarkan "bahasa umum". "Bahasa umum" memungkinkan Anda memiliki dasar untuk menghitung taksiran indikator istilah.
Kursus Singkat COCOMOII
Metodologi COCOMO muncul pada tahun 1963 sebagai tanggapan terhadap kebutuhan untuk penilaian yang cepat dan tidak rumit dari kompleksitas dan waktu pengembangan perangkat lunak dalam proyek yang akan datang. Dasar dari model COCOMO dan tahap selanjutnya, COCOMOII, adalah jumlah baris kode program (KSLOC adalah seribu baris kode logis, mis. Baris kode yang mengekspresikan operasi). Dasar ini adalah hasil dari setiap proyek pengembangan perangkat lunak, ini adalah semacam intisari dari proyek.
(Kami akan ingat bahwa COCOMO berbeda dari COCOMOII karena parameter skalar dari rumus COCOMO digantikan oleh tabel parameter COCOMOII, tetapi esensi dari metode ini tetap sama).
Dengan demikian, dengan akumulasi bagasi proyek, setiap pengembang dapat memiliki kerangka kerja penilaian dasar untuk setiap proyek berikutnya. Tentu saja, ini adalah perkiraan yang sangat kasar, tetapi pada tahap presale, perkiraan seperti itu lebih baik daripada tidak sama sekali. Untuk memperjelasnya, basis KSLOC disesuaikan menurut rumus tertentu untuk koefisien penyempurnaan. Kami tidak akan memberikan formula, itu sederhana dan tersedia di Internet. Intinya adalah bahwa setiap pengembang dapat mengembangkan koefisien rumus ini berdasarkan statistik dari proyek sebelumnya dan membandingkannya dengan parameter kanonik rumus, atau ... tidak membandingkan dan hanya menggunakan rumusnya sendiri.
Kehadiran rumus dengan parameter menunjukkan bahwa semua proyek integrator sistem (atau semua proyek internal organisasi) harus dikodekan dan diklasifikasikan sesuai dengan semua parameter ini. Semakin banyak proyek dalam bawaan pengembang, semakin banyak proyek dari jenis yang sama untuk proyek baru yang dapat dibuka dapat dipilih untuk evaluasi (menyaring proyek non-inti), semakin akurat evaluasi.
Mengetahui waktu yang dihabiskan untuk proyek yang diselesaikan per unit KSLOC (baris kode), Anda dapat mengevaluasi potensi kesulitan dari proyek masa depan. Jika parameter menyimpan data pada kualifikasi (nilai) karyawan yang dipekerjakan, maka Anda bisa mendapatkan perkiraan biaya proyek.
Perincian parameter proyek dapat dilakukan atas kebijakan dan kemampuan Anda. Semakin detail, semakin akurat perkiraan waktu dan biaya proyek di masa depan.
KSLOG apa yang ditetapkan pada tahap presale dengan deskripsi hasil yang tidak akurat? Hanya empiris dari basis data proyek integrator (pelaksana). Dalam hal ini, satu set parameter proyek dapat digunakan. Jika ada deskripsi akurat tentang hasil yang diinginkan dari proyek (produk perangkat lunak), maka serangkaian parameter proyek dapat digunakan.
Itulah inti dari metode COCOMO.
Transisi dari penilaian tenaga kerja pengembang ke penilaian tenaga kerja analis dan ahli metodologi
Pembaca yang penuh perhatian dan berpengalaman akan berseru:
"Baiklah kalau begitu! Dengan semua pro dan kontra dari metode COCOMO, ia dirancang untuk mengevaluasi proyek perangkat lunak. Karya pengembang, programmer dapat didigitalkan dalam KSLOC bersyarat. Tetapi bagaimana dengan analis dan metodologi, manajer proyek dan manajer? Dan apa hubungannya 1C DSS dengan itu? "
Benar!
Jadi, tugasnya adalah memilih dasar yang sama untuk anggota tim yang terdaftar yang akan memungkinkan Anda untuk menggunakan teknik COCOMOII. Ini dia naik panggung.
Kode palsu
Salah satu jenis hasil keluaran dari semua proyek kompleks untuk desain, pembuatan dan pengembangan sistem informasi adalah dokumen proyek. Ini adalah tugas teknis, dokumen konsep, deskripsi, instruksi, register objek data, daftar analis, dll. Daftar isi dokumen-dokumen ini, teks isi, tabel, gambar, persyaratan yang dikumpulkan, daftar adalah kodesemu.
Dan ini adalah pseudo-code yang merupakan ukuran dari hasil pekerjaan anggota "non-programmer" dari tim proyek - analis, metodologi, penulis teknis, manajemen proyek, arsitek, desainer dan peserta serupa.
Jika proyek diajukan sesuai dengan persyaratan GOST, maka struktur dokumen proyek ditentukan oleh standar-standar ini, jika tidak, dibuat berdasarkan kebijaksanaan kontraktor atau sesuai dengan persyaratan kontrak dengan pelanggan.
Hal yang menarik adalah jika tim proyek dan pelanggan memutuskan untuk mengikuti perkembangan zaman dan akan menyusun hasil proyek secara eksklusif menggunakan teknologi tanpa kertas, bagaimana 1C DSS dihubungkan dengan ini?
Jawabannya - dengan cara paling langsung - DSS dan isi direktori yang diisi oleh proyek akan menjadi objek data terstruktur dan hasil pekerjaan. Yang mana sangat nyaman untuk ditransfer ke pelanggan. Semua dokumen yang dibuat selama proyek akan dilampirkan dokumen ke objek konfigurasi DSS.
Dokumen proyek keluaran yang disederhanakan dibagi ke dalam kelompok-kode pseudo berikut:
- Struktur (daftar isi) dokumen;
- Tes dokumen;
- Baris tabel dokumen (tabel);
- Menggambar (objek grafik).
Dalam kasus yang paling sederhana, untuk dasar COCOMO, struktur dokumen keluaran cukup. Kompleksitasnya (jumlah level penyarangan), jumlah baris daftar isi dapat digunakan sebagai dasar untuk menerapkan formula metode untuk memperkirakan persyaratan dan biaya proyek melalui statistik serupa dari proyek sebelumnya dan struktur peserta dalam tim proyek (bukan pemrogram). Tentu saja, penyertaan semua jenis kode semu dalam basis akan meningkatkan akurasi estimasi.
Dengan demikian, analog KSLOC dalam standar COCOMO di sini menjadi daftar isi dokumen proyek keluaran dan / atau baris teks dari dokumen ini (setiap baris dari setiap tabel dalam dokumen ini, setiap objek grafik). Dasarnya tidak harus mencakup elemen desain dan tata letak dokumen.
1 DSS dan pseudo-code
Muncul pertanyaan tentang bagaimana menempatkan pseudo-code dalam 1C DSS.
Ini dapat dilakukan melalui direktori "Data Objects". Grup terpisah "DOKUMEN OUTPUT" dibuat, di dalamnya subkelompok untuk setiap jenis dokumen, kemudian subkelompok lain untuk setiap dokumen terpisah, dan di dalam subkelompok ini sebagai elemen direktori direktori daftar isi dokumen proyek.
Jika suatu keputusan dibuat untuk memasukkan konten teks, tabel, objek grafik dari dokumen proyek keluaran dalam basis COCOMOII, maka daftar isi dokumen proyek juga harus dilakukan dalam kelompok direktori "Objek Data", dan di dalamnya harus diletakkan nama-nama tabel, objek grafik dan paragraf teks.
Teks dokumen proyek itu sendiri dapat diketik dalam paragraf sebagai bidang teks dari elemen direktori "Data Objects".
Apa yang harus diupayakan seseorang ketika menggambarkan struktur dokumen proyek keluaran dalam buku referensi "Data Objects"?
Penting untuk berusaha memastikan bahwa setiap elemen direktori "Objek Data" dapat memiliki tautan ke satu objek metadata dan / atau ke satu objek data (dari grup lain dari direktori "Objek Data" yang menggambarkan bukan struktur lain dari dokumen keluaran, tetapi tipe lain yang dibuat pada proyek data, misalnya: daftar analis).
Desain seperti itu akan memungkinkan untuk membuat dokumen proyek keluaran secara otomatis, langsung dari 1C DSS. Ini akan membantu secara signifikan mengurangi waktu yang dihabiskan untuk kerja tim pada proyek, terutama dalam kondisi kebutuhan pelanggan yang terus berubah, modifikasi sistem informasi, termasuk tim dan pemain lain ketika perlu membuat ulang dokumen keluaran lagi, tetapi pada saat yang sama menjaga koherensi objek dan deskripsi mereka.
Saat menautkan setiap elemen atau grup direktori "Objek Data" dengan Persyaratan (keduanya dirumuskan oleh pelanggan dan anggota tim proyek, dirinci ke metadata), Anda akhirnya bisa mendapatkan tautan ujung ke ujung Persyaratan - Objek Metadata - Output dokumen proyek. Dalam DSS 2.0, "Ide" setara dengan "Persyaratan".
Dengan akumulasi pengalaman dalam implementasi proyek dalam 1C DSS, struktur direktori seperti itu akan mengkristal yang akan sama pada semua proyek serupa. Karena itu, untuk proyek baru, cukup menyalinnya saja. Dan untuk proyek yang identik dengan hasil keluaran, Anda dapat menyalin teks (tabel).
Ringkasan
Integrator dan organisasi dengan database proyek yang dikembangkan dengan baik, setelah mengaudit bahan-bahan dari proyek sebelumnya, dapat memperoleh penilaian objektif tentang waktu dan biaya proyek yang direncanakan dan berkelanjutan.
Ini harus sangat memudahkan A) tawar-menawar dengan pelanggan B) penilaian keuntungan yang diharapkan.