Solusi desain: bermain sesuai aturan Anda

Bukan rahasia lagi bahwa semakin besar proyek perangkat lunak, semakin besar keberhasilannya bergantung pada hasil kerja analis, khususnya, pada pilihan strategi yang tepat untuk menyusun dan menyetujui keputusan desain. Tetapi bagaimana Anda mengatur pekerjaan para kolaborator kreatif ini? Dan bagaimana membuat hasil aktivitas mereka sama jelasnya bagi perwakilan pelanggan dan pemrogram? Bagaimana menilai kerangka waktu yang mungkin dan pentingnya pekerjaan ini untuk proyek? Dalam artikel ini, saya mencoba merumuskan resep saya untuk mengoptimalkan pengelolaan pekerjaan analitik pada proyek perangkat lunak untuk pelanggan pemerintah. Setiap kritik akan dihargai.



Sumber

Kerangka Penelitian

, .



.

Karena saat ini ada lebih dari dua lusin jenis lowongan "analis" di pasar tenaga kerja TI , saya akan segera membuat reservasi bahwa saya akan berbicara tentang pekerjaan analitik pada proyek negara untuk membuat perangkat lunak khusus. Seperti yang ditunjukkan oleh pengalaman saya, seorang analis bisnis yang tidak memahami mekanisme untuk mengotomatiskan proses bisnis tidak dapat menyiapkan pernyataan masalah yang memadai. Sama seperti seorang analis sistem yang tidak memahami tujuan bisnis otomatisasi tidak cukup. Oleh karena itu, dari sudut pandang saya, seorang analis yang mengerjakan proyek perangkat lunak khusus harus menggabungkan kompetensi seorang analis bisnis, analis sistem, dan perancang UX. Selain itu, sebagai aturan, analis utama pada proyek semacam itu harus menjalankan fungsi Pemilik Produk.(jika pelanggan mengizinkan Anda). Ini tentang pengorganisasian kegiatan "prajurit universal" yang akan dibahas lebih lanjut.



Saat membuat perangkat lunak untuk kepentingan organisasi pemerintah, aktivitas utama analis dikaitkan dengan pemecahan masalah seperti:

• manajemen persyaratan;
• pembentukan pernyataan tugas untuk programmer, perencanaan implementasi dan kontrol atas implementasi tugas-tugas ini;
• persiapan dokumentasi proyek.

Detail pengelolaan persyaratan untuk perangkat lunak khusus, prosedur penyempurnaan awal mereka dan peran kunci dari analis yang bertanggung jawab atas penerapannya telah dibahas secara rinci di artikel sebelumnya .



Namun, kekhususan keinginan pelanggan bukanlah jaminan bahwa dia akan menyukai hasil akhirnya. Dalam proyek saya , pola berikut ini "diidentifikasi": semua komentar fungsional pelanggan, dicatat selama semua jenis pengujian (jangan bingung dengan kesalahan yang teridentifikasi!), Terkait dengan persyaratan yang solusi desainnya tidak disetujui secara proaktif dengan pelanggan. Dalam hal ini, statistik yang diberikan oleh Natalya Rukol bersifat indikatif.ketika, ketika menganalisis hasil dari salah satu proyek, ternyata hampir 70% "kesalahan" yang terungkap pada tahap pengiriman disebabkan oleh kurangnya pemahaman tentang persyaratan awal di pihak pengembang. 



Tampaknya setelah persyaratan untuk produk perangkat lunak diklarifikasi, perlu untuk membentuk paket dokumentasi desain sesuai dengan GOST RD 50-34.698 , mengoordinasikannya dengan pelanggan dan kemudian mengembangkan perangkat lunak secara penuh sesuai dengan proyek yang disetujui. Seringkali tentang urutan tindakan yang didengar dari siswa yang sangat baik kemarin (kelas C, sebagai aturan, tidak tahu tentang keberadaan dokumen semacam itu) dan banyak pejabat tinggi "berpengalaman" yang tidak pernah bertanggung jawab secara pribadi atas hasil akhir pengembangan perangkat lunak. 



Seperti yang ditunjukkan oleh pengalaman saya, pembentukan dokumentasi proyek hanyalah bagian akhir dari pekerjaan analis. Sebagai analogi, seseorang dapat mengutip sebuah karya penelitian, sehingga laporan harus dibuat sesuai dengan GOST 7.32 atau disertasi harus ditulis. Namun, dokumen tersebut hanyalah bentuk formalisasi dari hasil ilmiah yang diperoleh. Melakukan eksperimen tanpa hasil, pemrosesan statistik "white noise", mencari butiran informasi yang diperlukan dalam berton-ton kertas bekas pseudoscientific - semua bagian integral dari karya ilmiah ini selalu berada di belakang layar. Sama halnya dengan dokumentasi proyek. Di satu sisi, ini merupakan bagian integral dari produk perangkat lunak... Di sisi lain, ini hanya berisi hasil akhir dari pekerjaan analitis.  





Sumber



Menurut pendapat saya, aspek ini adalah salah satu dari sejumlah alasan mengapa, menurut persyaratan kontrak pemerintah untuk proyek perangkat lunak, pelanggan "bodoh" berencana untuk menyetujui dokumentasi desain pada tahap pengujian awal, yaitu pada saat pengembangan perangkat lunak selesai.



Itulah sebabnya, dalam proyek perangkat lunak kami di JIRA, dua jenis tugas dibentuk, yang memungkinkan kami untuk memisahkan pekerjaan analitis langsung dari aktivitas menyiapkan dokumentasi proyek. Dan apa yang memuaskan, saya bukan satu-satunya yang sampai pada kesimpulan seperti itu... Jadi, apa sebenarnya yang harus dilakukan analis pada proyek perangkat lunak setelah menentukan persyaratan dan sebelum menyusun dokumentasi proyek?

Solusi desain VS dokumentasi desain?

Betapa indahnya di atas kertas,

Betapa mudahnya mengikuti kata-kata.

Betapa mudahnya membuat Anda sempurna.



B. Grebenshchikov

Terlepas dari kenyataan bahwa definisi konsep "solusi desain" diberikan dalam GOST 34.003-90 , dalam kasus saya, arti konsep ini "ditemukan" dalam proses upaya yang menyakitkan dan sia-sia untuk menyetujui perwakilan pelanggan dari beberapa persyaratan yang saling terkait tetapi ambigu, ketika klien mengabaikan saja kami menjelaskan penetapan tujuan ( TMP ), dibentuk sesuai ketat dengan RD 50-34.698-90. Setelah menyadari bahwa keputusan dari pihak pelanggan tidak akan dibuat sampai dimulainya pengujian, manuver berikut dilakukan: solusi desain kami dikirim ke pelanggan (yaitu solusi yang secara resmi tidak diwajibkan untuk disepakati). 



Atribut ritual dipertahankan dalam solusi desain, tetapi penyesuaian signifikan dilakukan pada dokumen ini dibandingkan dengan HMO yang dihosting. Solusi desain dilengkapi dengan diagram proses bisnis otomatis dengan deskripsi singkat, tata letak antarmuka pengguna, formulir laporan yang diterima untuk dicetak, proposal untuk distribusi akses, serta skenario singkat untuk pengiriman solusi desain ini. Deskripsi yang tidak ambigu dan rinci dibuat tentang persyaratan yang ambigu dan saling bertentangan. Namun, sisa teks diminimalkan dengan segala cara yang memungkinkan. Algoritme trivial tidak dijelaskan sama sekali, seperti bidang formulir layar tidak dijelaskan, tujuan dan aturan validasinya jelas dari tata letak UI yang diberikan.  



Koktail yang dihasilkan pada saat yang sama bentuknya serupa dengan dokumen yang dibuat sesuai dengan persyaratan RD 50-34.698-90, tetapi pada kenyataannya tidak sesuai dengan format mana pun yang diberikan dalam GOST ini. Pada saat yang sama, apa yang tertulis di dalamnya dipahami oleh perwakilan pelanggan yang biasa dan tidak siap. Persyaratan yang ditentukan dalam dokumen ini sangat jelas baik bagi pelanggan maupun kontraktor. Batasan persyaratan, jumlah pekerjaan yang direncanakan dan bagaimana pekerjaan ini harus diselesaikan ditentukan.



Surat pengantar berisi sesuatu seperti ini:



“Kami menghadirkan varian solusi desain untuk memenuhi persyaratan yang terdaftar. Kami memberi tahu Anda tentang awal pengerjaan penerapan opsi yang disajikan. Jika Anda tidak setuju dengan solusi desain yang diusulkan, harap informasikan kepada kami. "



Dalam kasus pembahasan lebih lanjut tentang persyaratan, tidak adanya tanggapan terhadap surat semacam itu diartikan sebagai kesepakatan formal pelanggan dengan solusi desain yang diusulkan. Jika customer mengajukan keberatan, dalam hal ini ia diberitahu bahwa pengerjaan implementasi solusi desain ini ditangguhkan dan tidak dapat dilanjutkan hingga disetujui. Dalam kasus ini, sebagai aturan, persetujuan lebih lanjut jauh lebih cepat.



Yang lucu, pada awalnya dalam surat balasan jika pelanggan tidak mengirimkan klarifikasi yang diperlukan, kami menggunakan frasa "pekerjaan ditangguhkan." Setelah beberapa surat tersebut, salah satu perwakilan pelanggan memulai skandal sehubungan dengan fakta bahwa “sesuai kontrak yang ditandatangani, kami tidak dapat menangguhkan pekerjaan dan kurangnya klarifikasi mengenai persyaratan bukanlah alasan untuk menghentikan pembangunan”. Namun, ia tidak keberatan dengan kalimat "pekerjaan tidak dapat dilanjutkan". 



Ternyata kemudian, terlepas dari kenyataan bahwa struktur yang dibentuk dari solusi desain tidak memenuhi persyaratan GOST, pendekatan yang diusulkan sangat memudahkan gerakan tubuh ritual untuk pembentukan dan persetujuan dokumentasi desain. Isi dari dokumentasi desain, yang diperlukan untuk pengiriman proyek, dibentuk dengan penyalinan selektif dari bagian yang relevan dari solusi desain. Pada saat yang sama, dalam kaitannya dengan bagian-bagian dokumentasi yang dibentuk atas dasar keputusan desain yang "disepakati" secara preventif, tidak ada komentar yang dibuat oleh pelanggan selama penerimaan.

 Deskripsi gajah tidak menurut GOST

Sebenarnya, pelanggan tidak tahu apa yang mereka inginkan. Biasanya mereka tidak tahu pertanyaan apa yang perlu dijawab, dan hampir tidak pernah memikirkan masalah sedetail mungkin seperti yang tertera di spesifikasi. 



Frederick Brooks

Menurut pendapat saya, kriteria utama untuk deskripsi yang baik tentang pernyataan masalah (solusi desain) bukanlah pemenuhan persyaratan formal GOST, tetapi deskripsi yang tidak ambigu tentang kondisi penyelesaian pekerjaan yang berhasil dalam memenuhi persyaratan pelanggan. Dari sudut pandang ini, uraian item uji untuk persyaratan pemeriksaan sebenarnya merupakan bagian integral dari solusi desain apa pun.





Perlu dicatat bahwa ketika bekerja dengan pelanggan pemerintah, semua ambiguitas dan ambiguitas dalam keputusan desain Anda akan selalu ditafsirkan untuk kepentingan pemerintah. Untuk menghindari titik buta seperti itu, melalui uji coba dan kesalahan dalam persyaratan logging, daftar periksa penilaian kualitas desain dikembangkan, yang mencantumkan bagian utama yang akan direfleksikan dalam solusi desain sesuai kebutuhan . Dengan demikian, setiap solusi desain harus diperiksa dari posisi berikut.

1. Daftar persyaratan pelanggan (yang akan diterapkan sebagai bagian dari solusi desain).
2. Daftar definisi dan singkatan.
3. Daftar dokumen normatif yang mengatur proses otomatis.
4. (use case), :
   
   
   
   
   • ( , BPMN – , : , ) ;
   • ;
   • ( ) — ;
   • ( , ).
5. :
   
   
   
   
   • , ;
   • (UI) ( , , ); 
   • () .
6. :
   
   
   
   
   • API;
   • () «» ( );
   • () «» .
   
   
   , « » ( 2011 ., 1). - , ().
7. :
   
   
   
   
   • , () , ;
   • , () .
8. () , , . ( ) . ( ), , () , . «» .

Saya ulangi - ini bukan struktur tetap untuk solusi desain, ini adalah daftar pertanyaan formal ( daftar periksa), jawaban yang harus, jika perlu, tercermin dalam satu bentuk atau lainnya dalam solusi desain. Seperti yang ditunjukkan oleh praktik, jika pengembangan dalam hubungannya dengan salah satu elemen yang dijelaskan di atas tidak diharapkan, akan lebih baik jika Anda menunjukkannya secara eksplisit dalam solusi desain. Atau hampir secara eksplisit (jangan menakuti pelanggan). Kriteria utama adalah interpretasi yang tidak ambigu. Penting untuk tidak melakukannya secara berlebihan sehingga alih-alih menyelesaikan persyaratan yang disebutkan, lima persyaratan baru tidak lahir sebagai hasil dari persetujuannya. Misalnya, frasa "Referensi jenis objek hanya boleh berisi nilai aktual" dan frasa "Referensi jenis tidak menyediakan penyimpanan riwayat perubahan" memiliki arti yang sama, tetapi frasa kedua kemungkinan besar akan mengarah pada fakta bahwa Anda harus mendeskripsikan dan menerapkan mekanisme pembuatan versi buku pegangan ini.Saat membentuk keputusan desain, penting untuk dipahami bahwa tujuannya adalah untuk memperbaiki aturan yang dengannya Anda dijamin untuk menyerahkan persyaratan yang terkait dengan keputusan ini.

, , , .

Banyak (jika tidak semua) proyek bergantung pada bagaimana perwakilan pelanggan membayangkan hasil akhirnya. Oleh karena itu, sudah pada tahap awal, mendesain tata letak antarmuka pengguna adalah kunci keberhasilan proyek. Memperjelas dan menentukan persyaratan pelanggan dalam hal deskripsi eksternal produk perangkat lunak yang dia pahami. Dialog dengan perwakilan pelanggan, berdasarkan pembahasan tata letak layar, terbukti jauh lebih efektif daripada dialog tentang pembahasan format data masukan dan keluaran serta algoritme transformasinya (bagian utama dalam IPR, dibuat sesuai dengan GOST).



Bekerja dalam kerangka tugas desain semua elemen antarmuka pengguna, selain transparansi pemahaman batas implementasi, juga memberikan solusi untuk sejumlah masalah:

1. . , , UI, , .
   
   
   
   
   
   : . . ISBN: 978-5-91180-090-1
2. UX- . , , ( ).
3. «» . UI , , – , ( « » ).
4. , «» . UX- . , 80% . , . ( ) : « ?». , , ( ) , , . , « ». «» . , , « ».

Sumber



Saya ingin menyampaikan beberapa patah kata tentang prinsip merancang antarmuka pengguna untuk sistem kontrol otomatis. Meskipun terjadi lonjakan pertumbuhan penggunaan perangkat seluler, komputer desktop dan laptop tetap berada di luar persaingan untuk sistem kontrol otomatis yang digunakan di lembaga pemerintah (serta untuk memecahkan masalah pemrograman dan administrasi sistem). Saat ini, berbagai alat telah muncul untuk membuat prototipe antarmuka . Namun, menjelaskan secara spesifik penggunaan Figma atau Axure untuk kepentingan perangkat seluler kehilangan 10% cara primitif yang memungkinkan Anda merancang 90% antarmuka pengguna.ACS .



Dalam pengalaman saya, untuk mengurangi masalah pengembangan perangkat lunak secara signifikan, Anda perlu mengikuti beberapa aturan sederhana saat mendesain antarmuka pengguna.



Pertama-tama, Anda perlu memutuskan skema navigasi umum, di mana, seperti pohon Natal, Anda dapat dengan mudah menggantung lebih banyak elemen antarmuka baru. Dalam hal ini, untuk sistem kontrol otomatis dalam praktik saya, skema yang paling efektif telah muncul dengan sendirinya, yang banyak digunakan di berbagai IDE . 



Saya tidak akan memberikan contoh antarmuka IntelliJ IDEA atau PhpStorm di sini, bagaimanapun, saya akan mencoba untuk membedah komponen utama dari UI tersebut menjadi beberapa bagian, dari sudut pandang seorang analis dari sistem kontrol otomatis.



Antarmuka yang dibangun menurut skema ini berisi panel vertikal yang dapat dilipat di sebelah kiri, yang menyediakan navigasi di seluruh sistem. Kehadiran panel vertikal dengan bagian yang berisi menu hierarki benar-benar memastikan penerapan aturan " tiga klik ".





Setiap opsi menu dari bilah navigasi utama menyediakan akses ke daftar bentuk objek. Daftar objek (katalog) dan formulir (kartu) yang menampilkan objek ini merupakan bagian terbesar dari antarmuka pengguna. Penyatuan kedua jenis formulir ini dalam kerangka proyek dan pembentukan struktur navigasi atas dasar mereka dapat secara signifikan mengurangi jumlah permintaan pengguna yang terkait dengan kekurangan dalam dokumentasi pengguna.



Dalam kerangka deskripsi formulir daftar apa pun, desain harus menentukan:

• daftar bidang atribut yang ditampilkan;
• Persyaratan untuk mode tampilan daftar (tampilan default, pengelompokan, pengurutan);
• persyaratan untuk formulir bawahan yang terkait dengan item daftar (kartu tampilan cepat (tabel));
• persyaratan untuk panel filter (pemilihan record sesuai dengan daftar atribut yang diberikan);
• deskripsi operasi grup (tindakan simultan pada beberapa item daftar, misalnya: membandingkan item daftar, mengubah atribut untuk beberapa item daftar, mengubah hak akses untuk beberapa item daftar);
• uraian formulir (panel) laporan statistik operasional (pemantauan) berdasarkan hasil pemilihan daftar;
• uraian tentang persyaratan laporan untuk pencetakan dan algoritme untuk pembuatannya;
• persyaratan untuk memberi tahu pengguna (sistem eksternal) saat objek berubah.

Saat mendesain formulir daftar, aturan berikut telah bekerja dengan baik:

1. — , «» , .   (ribbon). 
2. , , :
   
   
   • — , CRUD: , , , ;
   • ( , );
   • ;
   • ( , , ).
   
   
   
3. ( .. ) . , . .

  :

•   ;
•   , (CRUD, , ..) ;
• /;
• daftar pesan informasi yang mungkin;
• cara untuk melihat sejarah perubahan objek.

Beberapa kata tentang toolkit. Sebagai hasil dari trial and error selama pelaksanaan berbagai proyek pemerintah, tiga pendekatan desain antarmuka berikut ini terbukti paling efektif.

1. Jika selama proses pengembangan perubahan antarmuka yang ada diperlukan, Anda tidak harus menemukan kembali roda. Di sini Paint.NET menunjukkan dirinya yang terbaik (dengan bantuannya, gambar untuk artikel ini telah disiapkan). Tidak masuk akal untuk menggambar ulang formulir lagi, lebih mudah untuk mengubah tangkapan layar yang sudah selesai.
2. , — « »,   MS Visio . , , , , MS Visio, , , Windows. 
3. , -  , . , , . DHTMLX. XML-, , . (view), , . , , MS Visio. , , , « ».

Berulang kali, memberikan semua argumen ini kepada pengembang tingkat lanjut, jauh dari masalah pelanggan, saya melihat pandangan mereka yang memudar dan mendengarkan penilaian ahli mereka tentang kemalangan dan kelebihan UI yang diusulkan. Namun, seiring waktu, setelah menganalisis pengalaman beberapa proyek, saya melihat pola yang luar biasa: jika seorang programmer dengan bersemangat mengkritik keterbelakangan dan kompleksitas antarmuka pengguna yang dikembangkan, ini adalah tanda pasti bahwa pelanggan akan menerima antarmuka seperti itu dengan keras.

Perancah dan bekisting

Biasanya orang banyak berpikir. Tapi masalahnya adalah mereka memikirkan masalah, bukan solusi untuk masalah ini.



David Allen

Selama pembangunan rumah, banyak struktur tambahan digunakan, yang, setelah penyelesaian konstruksi, sama sekali tidak diperlukan. Ini adalah perancah dan bekisting . Hebatnya, bahkan non-profesional pun tidak mencoba membantah perlunya membeli dan memelihara struktur ini. Sebaliknya, dalam industri TI, Anda sering melihat analis "berpengalaman" berjuang untuk segera membuat dokumentasi proyek yang memenuhi semua persyaratan.



Namun, menurut pendapat saya, tanpa registrasi preventif dan persetujuan solusi desain, dokumentasi desain yang dibuat hanya cocok untuk penutupan kontrak secara formal dan di masa mendatang lebih merugikan operasi daripada membantu. Namun, solusi desain dan prototipe yang dijelaskan di atas bukanlah satu-satunya "struktur tambahan" dalam pekerjaan analitis.



Sumber



Sekilas, tampaknya semuanya bergantung pada pengalaman analis, dan tidak mungkin untuk mengatur penggunaan karya tambahan ini. Misalnya, bagaimana cara memperhitungkan dan mengatur pekerjaan seorang analis yang menghabiskan sepanjang hari mengunjungi pelanggan dan keesokan harinya membawa tiga gigabyte dari semua jenis dokumen? Atau analis menghabiskan waktu seminggu untuk mempelajari dokumen-dokumen ini? Apakah ini baik atau buruk? Dan Anda benar-benar tidak dapat menjawab pertanyaan itu jika Anda tidak mengetahui hasil yang masuk akal sehubungan dengan pelaksanaan proyek.



Itulah sebabnya, dalam kerangka proyek kami, dilakukan klasifikasi pekerjaan analitis yang dilakukan dalam kaitannya dengan hasil yang dicapai. Selain solusi desain,Sebagian besar proyek perangkat lunak yang harus saya ikuti mengharuskan analis untuk mengembangkan bahan analisis dari jenis berikut.

• Analisis dokumen - laporan berdasarkan hasil analisis dokumen peraturan pelanggan atau dokumentasi proyek.
• Tinjauan analitis - laporan hasil analisis solusi untuk masalah yang muncul (sebagai aturan, analisis komparatif teknologi baru atau tren pasar).
• Survei informasi - laporan hasil studi proses bisnis pelanggan yang ada (pembentukan model sebagaimana adanya - " sebagaimana adanya ").
• — ,   (use case).  legacy-.  
• — , ( ).  
• — , .

Langkah kedua menuju desain yang dapat diprediksi adalah menentukan persyaratan khusus untuk pekerjaan analitis yang dimaksudkan. Berdasarkan persyaratan ini, template deskripsi masalah JIRA ditentukan untuk setiap jenis bahan analisis yang sedang dikembangkan.





Pernyataan tugas untuk pengembangan bahan analisis melibatkan deskripsi singkat tentang hasil yang diperlukan, dan bukan deskripsi proses analisis. Jadi, misalnya, disarankan untuk menghindari frasa seperti "melakukan analisis domain ..." atau "mempelajari dokumen".

Rencana untuk sang maestro 

Semuanya harus dinyatakan sesederhana mungkin, tetapi tidak lebih sederhana.



Albert Einstein

Seringkali, ketika datang ke analisis penjadwalan dan pekerjaan pemrograman, ada banyak kontroversi tentang bagaimana memperkirakan waktu hasil dalam kasus ini. Namun, analisis di atas dari aktivitas kreatif ini memungkinkan kami untuk membuat asumsi bahwa hal itu masih mungkin dilakukan dalam kerangka proyek perangkat lunak. Langkah pertama menuju ini adalah memecah pekerjaan desain sistem menjadi beberapa bagian yang dapat diperiksa pada frekuensi setidaknya sekali seminggu. Perlu diusahakan untuk memastikan bahwa biaya tenaga kerja analis untuk pembentukan satu solusi desain tidak melebihi 5 hari kerja (dalam hal volume, solusi desain seperti itu harus terdiri dari sekitar 20-30 halaman - menurut GOST R ISO / IEC 15910-2002). Oleh karena itu, menurut standar yang sama, seorang programmer harus membutuhkan waktu maksimal 3 jam untuk meninjau solusi desain yang sama. 



Penting untuk dipahami bahwa tidak perlu membuat proyek teknis dari solusi desain . Solusi desain harus mencakup hanya sekelompok kecil persyaratan yang saling terkait, yang hasilnya dapat disajikan kepada pelanggan.



Penting juga untuk menghindari jatuh ke dalam perangkap yang diperingatkan oleh Mary dan Tom Poppendieck saat membuat keputusan desain.yaitu tidak tersandera mitos bahwa spesifikasi rinci yang dibuat sebelumnya dijamin dapat mengurangi kerugian. Sebagai aturan, saat menyetujui solusi desain, pelanggan mencoba menjejalkan semua yang dapat dia ingat ke dalam dokumen ini. Oleh karena itu, ketika menyetujuinya, penting untuk memastikan bahwa persyaratan minimum yang diperlukan akan memastikan kelulusan yang berhasil dari tes pendahuluan. Pada saat yang sama, kunci sukses bukan hanya kombinasi kualitas, waktu dan biaya, tetapi juga kepuasan peserta proyek dengan hasilnya.



Biasanya, untuk mendapatkan tenggat waktu penyelesaian tugas untuk analisis, penilaian ahli dari kontraktor sendiri sudah cukup, tetapi jika terjadi perselisihan, pendekatan pragmatis dapat diterapkan.... Untuk meningkatkan objektivitas penilaian intensitas tenaga kerja tugas untuk analisis, kalkulator online dapat digunakan , yang memungkinkan Anda untuk merencanakan dan memperkirakan biaya tenaga kerja untuk melakukan pekerjaan analitis. Dengan menggunakan alat ini, Anda dapat membuat daftar pekerjaan yang direncanakan, mengklarifikasi kata-katanya, tergantung pada spesifikasi proyek. Untuk setiap pekerjaan yang direncanakan, perkiraan biaya tenaga kerja minimum, maksimum dan paling mungkin diperhitungkan. Sebagai hasil dari perhitungan, kompleksitas tugas yang diharapkan terbentuk dan cadangan waktu yang optimal dihitung, yang harus ditinggalkan untuk asuransi. Deskripsi pengaturan masalah yang dihasilkan untuk dianalisis dapat disalin langsung ke kolom deskripsi masalah JIRA.



Selain atribut umum yang dijelaskan dalam artikel " JIRA: Batas Proyek", Untuk setiap masalah dari tipe" analisis "di JIRA, set atribut tambahan (khusus) berikut ditentukan secara empiris.





Mempertimbangkan hal di atas, mari kita perjelas urutan tindakan yang diberikan sebelumnya dari analis pada pelaksanaan tugas jenis "analisis" untuk kepentingan pengembangan perangkat lunak.



1. Jika perlu, analis yang bertanggung jawab harus menjadwalkan tugas di JIRA untuk melakukan survei informasi dengan perwakilan pelanggan (tugas ini terkait dengan persyaratan yang relevan).



Disarankan, sebelum rapat, sebagai perkiraan pertama, untuk membentuk tata letak antarmuka pengguna , yang dapat didiskusikan dengan pelanggan. Saat melakukan survei informasi, perlu untuk mendiskusikan dengan pelanggan proses bisnis utama, dari sudut pandangnya (cerita pengguna - cerita pengguna), cara alternatif di mana pelanggan melihat hasil akhirnya. 



Saya sering bertemu dengan pendapat bahwa dasar dari survei informasi adalah mewawancarai karyawan yang kompeten yang akan memberi tahu Anda secara rinci tentang fitur-fitur proses otomatis. Namun, apa yang baik untuk pembangunan demi kepentingan pelanggan komersial dapat memiliki konsekuensi yang paling tidak terduga bagi pemerintah. Saya berulang kali menghadapi situasi ketika ternyata deskripsi proses, yang dibentuk berdasarkan cerita veteran berambut abu-abu, bertentangan dengan persyaratan utama dokumen peraturan saat ini. Dan ini dijelaskan bukan oleh fakta bahwa analis tersebut salah memahami sesuatu, tetapi oleh fakta bahwa veteran itu "melakukan ini sepanjang hidupnya".



Oleh karena itu, sebelum bertemu dengan para ahli di bidangnya, perlu dilakukan analisis terhadap dokumen regulasi dari sudut pandang proses regulasi yang diharapkan dapat diotomatiskan. Pada saat yang sama, penting untuk dipahami bahwa dokumen regulasi juga bukanlah kebenaran tertinggi. Seringkali, dalam analisis yang tidak memihak, dokumen regulasi selalu mengandung ambiguitas dan kontradiksi (pengecualian, sebagai suatu peraturan, adalah dokumen yang “ditulis dengan darah”). Berikut adalah beberapa ketidaksepakatan paling umum yang harus Anda perhatikan:

• pelanggaran prinsip dasar klasifikasi , misalnya, ketika tanda yang berbeda dicampur dalam kelompok yang sama (merah, hijau, hangat);
• konstruksi dokumen pelaporan berdasarkan atribut yang tidak disediakan;
• ;
• - ;
• — - , .

Menyelesaikan konflik peraturan ini adalah salah satu masalah utama saat bertemu dengan perwakilan pelanggan. Untuk mencatat keputusan ini, sebagai hasil survei informasi, harus dibuat protokol dengan indikasi peserta, tempat dan waktu. Protokol disajikan kepada pelanggan untuk klarifikasi (email dilampirkan ke tugas terkait). Setelah itu, tugas survei informasi dapat dialihkan ke status "selesai". Tugas JIRA ini ditransfer ke status "ditutup" setelah menerima konfirmasi dari pelanggan tentang persetujuan protokol.



2.  Berdasarkan persyaratan yang ditentukan dan hasil survei informasi, solusi desain dibentuk. Analis yang bertanggung jawab harus mengoordinasikannya dengan manajer proyek dan pemrogram (untuk masing-masing dari mereka, subtugas yang sesuai dibuat). Jika solusi desain belum melewati persetujuan internal selama hari kerja, tugas akan ditransfer ke status "menunggu keputusan" (sinyal ke manajer proyek). Setelah lulus persetujuan internal, solusi desain dikirim ke pelanggan untuk ditinjau (jika perlu, persetujuan). Semua detail pengiriman dicatat di komentar untuk tugas. Sementara solusi desain ada di pihak pelanggan, tugas dialihkan ke status "menunggu keputusan".



3.Jika solusi proyek disetujui (atau jika jelas bahwa persetujuan ditunda, dan tenggat waktu hampir habis), maka atas dasar itu analis yang bertanggung jawab merumuskan tugas untuk pengembangan, pengujian dan dokumentasi. Dalam hal ini, perlu dilakukan penilaian awal terhadap biaya tenaga kerja untuk implementasi solusi desain (sebagai jumlah biaya tenaga kerja dari tugas pengembangan yang terkait dengan solusi desain ini). Berdasarkan penilaian ini, perlu adanya klarifikasi waktu penerapan persyaratan terkait.



4.  Setelah kesepakatan dengan pelanggan (surat yang mengonfirmasi fakta ini disimpan di JIRA), tugas menyiapkan solusi desain dapat dialihkan ke status "selesai".

Bersambung 

Saat ini, desain perangkat lunak untuk pelanggan pemerintah paling sering diatur sesuai dengan persyaratan seri GOST 34. Pada saat yang sama, mengadvokasi kepatuhan yang tepat dari dokumentasi desain akhir dengan GOST ini, sebagian besar perwakilan pelanggan sering "lupa" bahwa, selain dokumentasi yang disediakan untuk menguji perangkat lunak yang dikembangkan, pelanggan harus menyetujui solusi desain dalam kerangka persetujuan rancangan dan proyek teknis. Dan bahkan dalam kasus ketika draf dan desain teknis disepakati, tidak jarang konten diabaikan demi tenggat waktu yang tidak realistis dalam kepatuhan penuh dengan formulir. Hal ini terutama berlaku untuk desain sistem yang tidak terkait langsung dengan keselamatan jiwa. Jadi di salah satu proyek, seorang wakil kepala "mengajarkan kehidupan"berbicara tentang bagaimana dia membangun proyek teknis 500 halaman menggunakan Wikipedia dalam satu malam. Sebagai aturan, orang yang sangat berbeda harus menguraikan hasil dari "keputusan desain" tersebut.



Dalam kondisi sulit ini, pendekatan yang dijelaskan di sini memungkinkan Anda untuk mengatur peningkatan fungsionalitas perangkat lunak secara berulang sambil mempertahankan konsistensi solusi yang diterapkan, yang sesuai dengan prinsip pengembangan perangkat lunak lean . Di sisi lain, pengaturan target dari solusi desain yang dijelaskan memungkinkan untuk menyusun dokumen atas dasar mereka yang memenuhi persyaratan "Procrustean" dari pelanggan dengan biaya minimal.



Pembagian pekerjaan analitis menjadi tindakan dasar juga memungkinkan untuk mengoordinasikan tindakan beberapa karyawan dengan tingkat pelatihan yang berbeda dan, sebagai hasilnya, secara alami membentuk matriks kompetensi untuk analis proyek kami di LANIT , yang akan saya bahas di artikel berikutnya.



PSArtikel ini adalah bagian dari serangkaian artikel berjudul " Aturan untuk persiapan tepat waktu perangkat lunak yang lezat " yang saya gunakan sebagai regulasi informal tim pada proyek perangkat lunak ubahsuaian untuk kepentingan organisasi pemerintah. Seri ini mencakup artikel berikut:

- " JIRA sebagai obat untuk insomnia dan gangguan saraf " - ide utama untuk mengatur pekerjaan pada proyek menggunakan JIRA;

- " JIRA: batas proyek " - ketentuan dasar untuk penyatuan proyek dan persyaratan umum untuk semua jenis tugas JIRA;

- " JIRA: manajemen persyaratan " - fitur utama dari pendaftaran, klarifikasi dan pengendalian pelaksanaan persyaratan pelanggan dalam model yang diusulkan;

- "Solusi desain: bermain dengan aturan Anda ”- aspek utama dari manajemen kerja analitis dan pembentukan pernyataan masalah untuk pengembang;

Dalam kerangka siklus ini, berikut ini yang sedang disiapkan untuk publikasi:

- " Matriks kompetensi analis " - kriteria untuk menilai tingkat kematangan analis pada proyek perangkat lunak kustom;

- " Di mana masalah bersembunyi di proyek " - kriteria (metrik) penilaian operasional dari keadaan saat ini dari proyek perangkat lunak.



Label utama dari rangkaian artikel ini adalah untuk memberikan peningkatan evolusioner dalam kualitas proyek perangkat lunak berdasarkan peningkatan efisiensi manajemen. Dengan kata lain, untuk membentuk metode pertumbuhan yang diterapkan pada tingkat model CMMI .

Jika Anda telah mengetahui cara menggunakan JIRA secara lebih efisien pada proyek perangkat lunak Anda - bagikan ide Anda. Hanya dalam mendeskripsikan ide-ide ini, hindari frase "entah bagaimana" dan "entah bagaimana". Saya mengundang semua orang untuk berdiskusi. Saya menunggu komentar / saran / keraguan / keinginan di kolom komentar.