Apa hal-hal yang Anda letakkan pada dokumen analisis dampak?

9

Jadi Anda memperbaiki bug, maka Anda menemukan satu yang dapat mempengaruhi modul lain dari produk perangkat lunak. Data Anda tidak cukup untuk mendukung klaim Anda tentang efek perbaikan dan Anda diminta untuk membuat dokumen analisis dampak.

Apakah ada proses yang pasti tentang bagaimana melakukan ini?
Apa informasi kunci yang diperlukan?
Apakah ada format / templat yang diketahui untuk dokumen ini?

project-management documentation

— setzamora
sumber

1

Sepertinya saya seseorang yang suka istilah mewah untuk menempatkan Anda di tempat dan membuat Anda untuk memperbaiki bug itu tanpa argumen.

— Aditya P

4

Pertanyaan ini dan jawabannya membuat saya senang saya tidak bekerja di lingkungan seperti itu. "Matriks Keterlacakan Dua Arah"? "Analisis Keputusan dan formulir Resolusi"? Betulkah? Berapa banyak cara berbeda untuk tidak menyelesaikan pekerjaan yang Anda butuhkan?

— Rein Henrichs

2

@Rein, semuanya bekerja. Pekerjaan bukan hanya coding. Selain itu, itu bukan satu orang. Dalam organisasi kecil di mana Analisis, Desain, Pengkodean, Estimasi dilakukan oleh satu orang, memang seperti neraka tetapi dengan tim besar dengan spesialisasi itu bukan masalah besar.

— M.Sameer

4

@AdityaGameProgrammer, @Rein Henrichs: Saya tidak mengerti komentar Anda. Apakah Anda menyarankan untuk tidak melakukan perencanaan dan manajemen sama sekali? Tentu saja, tidak apa-apa untuk memulai pengkodean langsung jika proyek dilakukan oleh satu orang, dan perubahannya mudah diimplementasikan. Tetapi bagaimana dengan proyek skala besar, dan perubahan yang dapat memiliki dampak besar pada bagian proyek yang berbeda?

— Arseni Mourzenko

5

Template yang telah saya lihat untuk analisis dampak di mana dibuat di dalam perusahaan tempat saya bekerja. Kami menggunakannya untuk mengevaluasi Permintaan Perubahan dan sebelum mengerjakannya (dan mungkin untuk menolak sebagian). Itu bagian seperti ini:

Dampak pada Persyaratan: Pada bagian ini Analis menulis apa yang perlu diubah dalam Use Cases untuk mendukung perubahan yang diminta.
Dampak pada Desain dan Arsitektur: Pada bagian ini arsitek dan perancang menyebutkan bagian model mana yang perlu dimodifikasi atau diperbaiki untuk mendukung perubahan.
Dampak pada Tes: QC menulis kasus uji perlu diperbarui.
Estimasi dan Dampak pada Jadwal: Manajer proyek memperkirakan upaya yang diperlukan dan biaya perubahan dan dampak pada jadwal proyek.

Untuk mencakup semua dampak yang mungkin terjadi, Anda perlu menjalani dependensi. Jika Anda memiliki Matriks Pelacakan Dua Arah, itu akan membuatnya lebih mudah.

Kami menggunakan urutan di atas karena perancang harus mengetahui dampak dari sudut pandang analis untuk mendapatkan wawasan yang lebih baik tentang perubahan dan begitu juga tester perlu mengetahui pendapat analis dan arsitek. Demikian pula, PM membutuhkan semua informasi untuk mengetahui biaya dan jadwal.

Kami menggunakan ini dengan CRs tetapi Anda dapat menggunakannya dengan bug dengan cara yang sama. Juga, jika Anda perlu melakukan ini untuk memilih di antara beberapa solusi perbaikan untuk menyelesaikan bug, Anda harus mengulangi analisis dampak untuk setiap solusi yang mungkin dan mengkonsolidasikan semua data menjadi satu bentuk Analisis Keputusan dan Resolusi (DAR) untuk mengetahui solusi mana yang terbaik. Dalam formulir DAR Anda harus menambahkan beberapa faktor evaluasi seperti pemeliharaan masa depan atau faktor lain yang tidak termasuk secara implisit dalam analisis dampak. Kemudian berikan bobot masing-masing faktor dan berikan skor setiap solusi di setiap faktor. Akhirnya gandakan dan jumlah skor * berat dan pilih yang terbaik. Perhatikan bahwa biaya mungkin termasuk dalam faktor atau PM dapat memiliki pendapat lain.

— M.Sameer
sumber

1

Kedengarannya ... burro-cratic. (Artinya, sepertinya Anda dijalankan oleh keledai.)

— Donal Fellows

3

@Donal Fellows, Itu direkomendasikan oleh konsultan CMMi dan oleh konsultan peningkatan proses dari IBM.

— M.Sameer

3

Saya percaya dengan dokumentasi apa pun bahwa pendekatan gesit itu bagus. Sekarang, ada beberapa kesalahpahaman di luar sana bahwa gesit berarti "tidak ada dokumentasi atau analisis sama sekali" tapi itu tidak terjadi. Hal-hal yang saya baca tentang lincah berkata, "gunakan apa yang berhasil." Saya menganggap itu berarti dokumen harus panjang dan detail sesuai dengan tugas.

Templat dapat membantu sebagai daftar periksa, tetapi saya tidak akan meminta setiap bagian diisi untuk perubahan kecil atau berisiko rendah. Untuk perubahan satu baris, mungkin Anda tidak memerlukan dokumen sama sekali. Saya tidak pernah menggunakan templat untuk dokumen analisis dampak, tetapi saya secara teratur menangani persyaratan bisnis atau spesifikasi teknis. Templat bisa terlalu membatasi; pedoman yang baik adalah untuk mempertimbangkan siapa yang akan menjadi penonton. Jika itu untuk manajer yang tidak teknis, fokus pada justifikasi bisnis untuk perubahan. Jika ini untuk orang-orang teknis, berikan sedikit latar belakang sehingga orang baru dalam tim tidak akan hilang dan memberi mereka cukup untuk maju jika mereka harus mendukung perubahan. Juga, jika Anda menginginkan sesuatu yang bahkan lebih sedikit gesekan dan ringan, jangan gunakan dokumen sama sekali, letakkan di wiki.

Informasi termasuk:

Deskripsi singkat masalah
Jelaskan atau perlihatkan contoh bagaimana cacat menyebabkan kegagalan dan / atau ketidakefisienan
Sertakan perkiraan kompleksitas
Sertakan perkiraan biaya dan waktu untuk perbaikan

Itu minimum yang layak. Posting lain menyoroti beberapa hal CMMi yang cukup berat dari IBM; itu bagus jika Anda punya waktu dan sumber daya untuk itu (dan ketika Anda sedang membangun sistem untuk NASA di mana kehidupan manusia dipertaruhkan, maka orang lebih baik serius tentang hal itu) tetapi untuk tim kecil Anda mungkin tidak perlu terlalu berat . Hati-hati dengan perkiraan, seperti biasa. Manajer cenderung berasumsi bahwa estimasi adalah yang sebenarnya.

Perhatikan bahwa ada bahaya dalam pendekatan gesit. Beberapa pengembang berpikir itu berarti, "tidak diperlukan dokumen, cukup mulai meretas" (yang mungkin oke dalam beberapa situasi). Juga, orang lain akan mengambil garis lintang diberikan tugas dan hanya menulis dokumen yang benar-benar jelek yang tidak benar-benar membantu (belum tentu OK dalam kebanyakan situasi). Sebagian masalahnya adalah bahwa menulis dengan baik membutuhkan usaha, keterampilan, dan waktu; kebanyakan dari kita kekurangan setidaknya dua hal;)

Saya selalu fokus pada dokumentasi karena itu membuktikan Anda setidaknya menaruh cukup pemikiran untuk memenuhi syarat memiliki rencana. Tetapi di usia tua saya, saya juga menghargai bahwa terlalu banyak dokumentasi itu sendiri dapat menjadi masalah pemeliharaan, dan tidak cukup banyak orang yang cukup peduli untuk memperbarui dokumentasi.

— Bernard Dy
sumber

-1

Dokumen Analisis Dampak memang diperlukan dalam proyek skala besar khususnya di mana programmer bekerja secara geografis di lokasi yang berbeda.

Dokumen Analisis Dampak harus disetujui oleh pimpinan untuk memastikan bahwa perubahan tidak akan mempengaruhi komponen lain yang berfungsi dengan baik dalam produksi.

Analisis Dampak diperlukan untuk memastikan bahwa persyaratan sepenuhnya dipahami dan semua komponen yang akan diubah diidentifikasi untuk menghindari pengerjaan ulang

Analisis Dampak juga diperlukan untuk akuntabilitas dari para pemangku kepentingan klien. Jika tidak, ketika terjadi masalah pasca penempatan, pengembang menjadi kambing hitam.

Analisis Dampak adalah dasar untuk estimasi. Tanpa itu estimasi tersebut tidak memiliki pendirian. Mungkin terlalu tinggi atau mungkin terlalu rendah. Dengan Analisis Dampak jika upaya aktual melebihi, mudah untuk dijelaskan juga.

— Raghu
sumber

-2

Di sini Anda memiliki template normed untuk laporan analisis dampak. Ini disesuaikan untuk cabang industri tertentu, namun demikian memiliki bagian yang berguna yang dapat berfungsi sebagai inspirasi untuk menulis dokumen Anda sendiri.

Tautan: http://www.itu.int/en/itu-d/projects/documents/templateimpactanalysis.pdf

Bersulang

— Nano
sumber

Bacaan yang disarankan: Jawaban Anda ada di kastil lain: kapankah jawaban bukan jawaban? "biarkan saya jelas: respons semacam ini bukan jawaban . Jika Anda melihat ini, beri bendera. Moderator, jika Anda melihatnya ditandai, hapuslah "

— agas

Sebenarnya saya tidak setuju. Posting saya ADALAH jawaban, jawaban khusus untuk butir # 3 dari pertanyaan awal "Apakah ada format / templat yang diketahui untuk dokumen ini?". Jadi, Anda punya satu dari papan Telco. Mungkin tidak secara khusus dirancang untuk pengembangan perangkat lunak, tetapi ada beberapa bagian menarik dalam pdf yang dapat digunakan sebagai inspirasi untuk membangun templat Analisis Dampak Anda sendiri. Sebelum Anda mengecilkan postingan yang dianalisis berdasarkan opini bias Anda sendiri, akan menarik untuk mengetahui apa pendapat pengguna asli yang memposting pertanyaan tentang input saya. Bersulang.

— Nano

Poin yang bagus - setujui bahwa ini memang membuatnya secara resmi memenuhi syarat sebagai jawaban (sementara menjadikan bagian dari pertanyaan itu menjawab permintaan sumber daya luar topik yang terang-terangan )

— agas