it-swarm-id.com

Apa yang membuat proyek besar?

Hanya ingin tahu apa perbedaan antara proyek ukuran kecil, sedang dan besar? Apakah diukur dengan baris kode atau kompleksitas atau apa?

Saya sedang membangun sistem barter dan sejauh ini memiliki sekitar 1000 baris kode untuk login/registrasi. Meskipun ada banyak LOC saya tidak akan menganggapnya sebagai proyek besar karena tidak rumit meskipun ini adalah proyek pertama saya jadi saya tidak yakin. Bagaimana cara diukur?

32
Jonathan

Kompleksitas.

Semakin banyak kompleksitas, semakin sulit untuk mempelajari segala sesuatu dalam proyek.

20
user1249

Kira-kira cara saya menyetujui sesuatu - perlu diingat ini kurang lebih sewenang-wenang. "Ukuran" proyek dalam gabungan dari faktor-faktor lain seperti kompleksitas, baris sumber kode, jumlah fitur/nilai bisnis, dll. Produk yang sangat kecil dapat memberikan nilai yang besar, dll. Yang dikatakan:

  • 2m + sloc adalah proyek besar ke besar. Ini umumnya sangat kompleks sehingga hanya sedikit jika ada orang yang 'lancar' di seluruh sistem; alih-alih tanggung jawab cenderung dimodulasi di sepanjang struktur kode. Proyek-proyek ini sering memberikan nilai bisnis yang sangat besar dan mungkin penting untuk misi. Mereka juga terkadang berada di bawah tekanan hutang teknis yang besar dan masalah warisan lainnya.

  • 100k - 2m sloc adalah proyek berukuran sedang. Ini adalah jalan tengah saya: proyek ini cukup rumit untuk membutuhkan pengetahuan ahli, dan kemungkinan telah menimbulkan beberapa tingkat utang teknis; kemungkinan juga memberikan beberapa nilai bisnis.

  • 10k - 100k adalah proyek kecil, tetapi tidak terlalu kecil untuk memiliki kompleksitas yang cukup sehingga Anda memerlukan pertimbangan ahli; jika Anda open source, pertimbangkan untuk meminta orang yang Anda percaya untuk meninjau komitmen Anda.

  • Apa pun yang kurang dari 10k sloc kecil, sungguh. Itu tidak berarti itu tidak dapat memberikan nilai sama sekali, dan banyak proyek yang sangat menarik memiliki jejak yang sangat kecil (misalnya Berkemah, yang sumbernya ~ 2 kb (!)). Non-ahli umumnya dapat mendorong masalah nilai - memperbaiki bug dan menambahkan fitur - tanpa harus tahu terlalu banyak tentang domain.

34
Joseph Weissman

Ukuran proyek diukur dengan tingkat unmaintainability.

14
mojuba

Kompleksitas yang dapat diperkirakan dalam beberapa cara:

  1. Anggaran. Proyek dengan anggaran $ 10.000.000 + mungkin sangat berbeda dari yang di bawah $ 10.000 misalnya. Ini dapat mencakup tenaga kerja, perangkat lunak, perangkat keras, dan biaya lain yang dikeluarkan dalam melakukan suatu proyek.
  2. Jam kerja orang untuk menyelesaikan proyek. Akankah ini membutuhkan sejam jam atau sesuatu yang lain? Ini juga dapat dilihat sebagai faktor garis waktu di mana beberapa proyek mungkin memakan waktu bertahun-tahun yang menurut saya besar dibandingkan dengan yang lain yang mungkin membutuhkan waktu kurang dari seminggu. Perhatikan bahwa jam orang dapat menyesatkan karena seseorang mungkin berpikir dengan menggandakan staf sehingga ada dua kali lebih banyak mengerjakan proyek maka jadwalnya dapat dibagi dua yang jarang akan bekerja untuk pikiran saya.
  3. Jumlah perangkat keras, sistem lain, dan orang-orang yang menggunakan proyek yang sedang dibangun. Jika ada sesuatu yang mengikat ke dalam sistem 101 maka kemungkinan akan lebih rumit jika itu berdiri sendiri dan tidak mengikat ke hal lain.

Sementara persyaratan dapat terdengar seperti cara yang bagus untuk mengukur ini, sering ada lebih banyak persyaratan yang akan ditemukan ketika sebuah proyek dilakukan dengan asumsi metodologi non-Waterfall yang saya percaya.

12
JB King

Ukuran proyek mungkin paling baik diukur dengan jumlah persyaratan yang dimiliki sistem, di mana persyaratan tidak dapat dikurangi lebih jauh.

Tentu saja, lebih banyak persyaratan kebanyakan berarti lebih banyak kerumitan, tetapi tidak selalu demikian.

11
David_001

Saya akan mengukur ukuran proyek dengan seberapa sulitnya untuk melihat keseluruhan proyek sebagai satu gambaran besar. Sebagai contoh, saya memiliki basis kode eksplorasi/prototyping untuk masalah pembelajaran mesin yang sedang saya kerjakan. Ini hanya 5k baris kode, tetapi rasanya seperti proyek besar. Ada banyak opsi konfigurasi yang berinteraksi dengan cara yang tidak terduga. Anda dapat menemukan hampir setiap pola desain yang dikenal manusia di suatu tempat dalam basis kode untuk mengelola semua kerumitan itu. Desainnya sering suboptimal karena hal itu tumbuh banyak oleh evolusi dan tidak dire-refoured sesering yang seharusnya. Saya satu-satunya yang bekerja pada basis kode ini, namun saya sering terkejut dengan bagaimana segala sesuatu berinteraksi.

Di sisi lain, salah satu proyek hobi saya memiliki sekitar 3-4x kode lebih banyak, namun rasanya jauh lebih kecil karena pada dasarnya merupakan perpustakaan fungsi matematika yang sebagian besar ortogonal satu sama lain. Hal-hal tidak berinteraksi dengan cara yang rumit, dan cukup memahami setiap fungsi secara terpisah. Sangat mudah untuk melihat gambaran besarnya sejauh ada, karena tidak banyak yang bisa dilihat.

4
dsimcha

Jawaban sewenang-wenang: Seberapa besar proyek ini seberapa besar Anda berharap Anda telah melakukannya dengan event-sourcing dan SOA sejak awal. Atau bahwa penulis sistem telah membaca buku Evan "DDD: Tackling Kompleksitas di Jantung Perangkat Lunak ";)

3
Henrik

Compexity & Lingkup

Kompleksitas dan Cakupan Saya percaya adalah apa yang menentukan seberapa besar proyek sebenarnya. Namun, ada beberapa hal tak berwujud yang dapat mempengaruhi ukuran proyek juga.

Persyaratan

Kejatuhan terbesar yang saya hadapi adalah kurangnya persyaratan. Dalam situasi khusus saya, manajer penjualan menentukan persyaratan. Fokusnya adalah pada penjualan ... harus mendapatkan penjualan. Dalam benaknya apa yang diminta oleh pelanggan tampaknya tidak terlalu rumit karena kami telah membangun sesuatu yang serupa. Persyaratan yang tidak jelas menyebabkan pekerjaan yang tidak terlalu mahal dan ekspektasi yang berlebihan.

Kurangnya CCMU

CCMU adalah apa yang saya sebut "Coo Ca Moo" (Hapus Pemahaman Saling Lengkap). Anda harus memiliki CCMU dengan pelanggan Anda.

Jika Anda memiliki proyek kecil dengan CCMU yang buruk maka Anda dapat menyelesaikan proyek tersebut sebanyak 2,3,4 kali atau lebih. Jadi pekerjaan sederhana 20 jam berubah menjadi proyek 60 jam dengan staf yang stres dan pelanggan yang sangat tidak puas.

Cakupan Creep

Ini terjadi lebih sering daripada yang Anda pikirkan. Pelanggan memutuskan bahwa karena Anda sudah melakukan A, B & C seharusnya tidak terlalu sulit untuk menambahkan D atau bahkan F. Jika perilaku ini tidak dicentang, itu juga dapat mengubah proyek kecil menjadi proyek ukuran sedang. Dan tergantung pada bagaimana manajer penjualan menjual pekerjaan, ekspektasi creep ruang lingkup ini tampaknya "GRATIS" kepada pelanggan.

Aneh, membaca banyak jawaban ini, saya menemukan ukuran proyek sangat berbeda. Mungkin ini adalah pekerjaan saya di sebuah perusahaan besar, tetapi saya cenderung memandang ukuran proyek sebagai lebih dari skala visibilitas/keinginannya kepada kliennya (tergantung pada area kerja Anda, ini bisa menjadi rekan kerja atau pelanggan yang membayar sebenarnya).

1
Kavet Kerek

Kompleksitas adalah jawaban yang tepat, tetapi bagaimana cara memperkirakannya?

Faktor-faktor tersebut adalah:

  1. Poin ekstensi dihitung
  2. Lapisan modul menghitung (fungsi, kelas, sistem kelas, perpustakaan, perpustakaan bersama, aplikasi, aplikasi jaringan, dll.)
  3. Jumlah ketergantungan (termasuk platform)
  4. Fitur jumlah saling ketergantungan.
  5. Sumber daya non-kode yang diperlukan (termasuk grafik/seni, skrip mengemudi - seperti skrip desain level - dan sumber daya lain yang diperlukan untuk melengkapi versi aplikasi).

Semakin banyak yang Anda miliki, semakin kompleks proyeknya.

1
Klaim

LOC is terkenal tidak akurat untuk banyak pengukuran, tapi saya pikir Anda mencoba mengukur sesuatu yang sebenarnya tidak ada cara akurat untuk mengukur. Mungkin alternatifnya adalah kompleksitas cyclomatic .

Namun pada akhirnya, saya pikir "besar" suatu proyek sulit untuk diukur. Ini hampir seperti menanyakan bagaimana Anda menentukan apakah seekor anjing besar atau tidak. Tidak hanya ada beberapa cara untuk mengukurnya (massa, volume, dll), tetapi saya pribadi tidak merasa sangat berguna. Kenyataannya adalah bahwa kriteria saya mungkin akan menjadi sesuatu seperti "Seberapa besar kemungkinan saya lari dari anjing ini jika saya melihatnya di lorong yang gelap?"

Dan sebagai catatan, saya umumnya tidak akan menganggap 1k baris kode menjadi banyak. Itu akan menjadi potongan kode yang cukup besar, tetapi itu tidak akan bahwa banyak dalam skema besar hal. Tentu saja, saya kira itu tergantung pada bahasa. Misalnya, 1k baris kode adalah kode jauh kurang dalam bahasa seperti C daripada dalam bahasa seperti Pyhon.

0
Jason Baker