Software House

Posted: October 4, 2010 in Uncategorized

Jenis software house

Ada beberapa jenis software house:


Semua ini dapat dikategorikan dalam satu atau banyak dari yang berikut :

  • Kontrak – ketika software house dikontrak untuk memberikan beberapa perangkat lunak tertentu dari luar (software outsourcing )
  • pengembangan produk – ketika menghasilkan siap pakai, dikemas perangkat lunak; Commercial off-the-shelf

Common peran dalam sebuah software house

Pengorganisasian software house sangat khusus jenis keterampilan manajemen, di mana orang mengalami bisa mengubah masalah organisasi menjadi manfaat unik. Sebagai contoh, memiliki sub-tim yang tersebar di berbagai zona waktu memungkinkan sebuah perusahaan jam 24 hari kerja, jika tim, sistem dan prosedur yang mapan. Sebuah contoh yang baik adalah tim uji dalam zona waktu 8 jam depan atau di belakang tim pengembangan, yang memperbaiki bug perangkat lunak ditemukan oleh para penguji.

Sebuah software house profesional biasanya terdiri dari setidaknya tiga dedikasi tim sub:

Dalam software house yang lebih besar, spesialisasi yang lebih besar bekerja, dan cukup sering ada juga:

Yang kontra:

  • orang tidak begitu banyak terfokus pada spesialisasi
  • setiap orang harus sangat fleksibel dan memiliki kemampuan untuk memainkan peran masing-masing (tidak setiap orang bersedia untuk melakukan itu)
  • pendekatan ini mungkin hanya untuk yang lebih kecil, organisasi kurang formal

Pro:

  • setiap orang memiliki pengetahuan lengkap tentang siklus produksi penuh
  • orang yang melakukan berbagai tugas apa yang membuat terutama kaum muda bersemangat tentang pekerjaan mereka
  • ada kemungkinan sangat baik untuk mengelola beban kerja terutama dalam situasi krisis seperti “semua tangan di pompa”

Struktur software house

Manajer sebuah software house biasanya disebut Kepala Pembangunan (Hod), dan laporan kepada pemangku kepentingan. Dia memimpin sub-tim langsung atau melalui manajer / pemimpin tergantung pada ukuran organisasi. Biasanya tim sampai dengan 10 orang yang paling operasional. Dalam organisasi yang lebih besar, ada pada umumnya dua model hirarki:

Khas struktur software house

Semua tim sepenuhnya independen dan mereka bekerja secara terpisah pada proyek yang berbeda. Struktur ini cukup sederhana dan semua laporan karyawan untuk satu orang, apa yang membuat situasi cukup jelas namun bukan solusi yang baik dalam hal pertukaran pengetahuan dan penggunaan optimal dari sumber daya manusia.

Struktur Matrix

Dalam model ini terdapat berdedikasi manajer / pemimpin untuk setiap spesialisasi utama, “menyewa” orang-orang mereka untuk proyek-proyek tertentu yang dipimpin oleh produk / manajer proyek, yang secara formal maupun informal membeli dan membayar orang untuk waktu mereka. Hal ini menyebabkan setiap karyawan swasta yang memiliki dua bos – produk / manajer proyek dan khusus “sumber daya” manajer. Di satu sisi itu mengoptimalkan penggunaan sumber daya manusia, di sisi lain ia dapat menimbulkan konflik tentang apa yang seorang manajer memiliki prioritas dalam struktur.

Ada juga sejumlah varian dari struktur, dan sejumlah organisasi memiliki struktur dan menyebar perpecahan di dalam berbagai departemen yang berbeda dan unit.

Metodologi

Artikel utama: proses pengembangan perangkat lunak

Perangkat Lunak rumah dapat menggunakan beberapa berbagai metodologi untuk menghasilkan kode. Ini dapat termasuk:

Ada juga beberapa metodologi yang menggabungkan keduanya, seperti model spiral , RUP atau MSF .

Produk daur hidup di software house

Terlepas dari metodologi yang digunakan, siklus hidup produk selalu terdiri dari setidaknya tiga tahap:

  • Desain – termasuk spesifikasi baik bisnis dan teknis
  • Coding – pembangunan itu sendiri
  • Pengujian – manajemen kualitas

Setiap tahap idealnya membutuhkan 30% dari total waktu, dengan 10% yang tersisa di cadangan.

UML Diagram urutan interaksi antara kelompok-kelompok ini mungkin terlihat seperti:

Interaksi umum antara tiga kelompok utama

Pada setiap tahap kelompok yang berbeda memainkan peran penting, namun setiap jenis peran harus terlibat selama proses pembangunan secara keseluruhan:

  • Analis, setelah menyelesaikan spesifikasi bisnis, mengelola situasi bisnis yang berubah untuk meminimalkan kemungkinan perubahan dari waktu ke waktu. Mereka juga mendukung programer dan penguji selama proses pembangunan secara keseluruhan untuk memastikan bahwa produk akhir memenuhi kebutuhan bisnis tertentu di awal. Proses ini idealnya menempatkan analis bisnis sebagai pemain kunci saat melahirkan akhir dari solusi untuk pelanggan, karena mereka yang tepat untuk memberikan lapisan bisnis terbaik.
  • Programmer melakukan spesifikasi teknis selama fase desain, itulah sebabnya mereka disebut programmer / desainer, dan selama waktu pengujian mereka memperbaiki bug.
  • Penguji menyelesaikan skenario pengujian selama fase desain, dan mengevaluasi mereka selama fase coding

Sistem dan prosedur

software house memiliki berbagai sistem dan prosedur diimplementasikan dan bekerja secara internal di semua sub-tim. Ini termasuk:

Analis Bisnis

Pemrogram

Testers

Proyek Produk manajer

Ada juga Application Lifecycle Management (ALM), yang menanamkan beberapa fungsi dalam satu paket dan digunakan di seluruh kelompok. Mereka dikirim dari berbagai vendor seperti Borland , ECM atau Compuware .

Audit rumah efisiensi perangkat lunak

software house telah terjalin dengan baik biasanya memiliki beberapa cara untuk mengukur efisiensi mereka sendiri. Hal ini biasanya dilakukan dengan mendefinisikan seperangkat indikator kinerja utama (KPI), seperti :

  • Jumlah rata-rata bug dilakukan oleh pengembang per unit waktu atau baris kode
  • Jumlah bug ditemukan oleh tester per siklus tes
  • Jumlah rata-rata siklus uji sampai Bug Zero Bounce (ZBB)
  • Waktu rata-rata siklus uji
  • Perkiraan waktu tugas membandingkan dengan waktu nyata tugas (ketepatan perencanaan)
  • Jumlah koreksi baseline

Sejumlah organisasi difokuskan pada mencapai tingkat optimum Capability Maturity Model (CMM), dimana “optimal” tidak selalu berarti yang tertinggi. Ada juga sistem lain seperti Carnegie-Mellon University ‘s SEMA , atau tertentu ISO standar. software house kecil kadang-kadang akan menggunakan pendekatan formal kurang, seperti Joel Test: 12 langkah untuk kode yang lebih baik . Setiap organisasi bekerja keluar gaya sendiri, yang terletak di suatu tempat antara teknokrasi total (di mana semua ditentukan oleh angka) dan anarki total (di mana tidak ada angka sama sekali). Apapun cara organisasi berjalan, mereka menganggap piramida menggambarkan biaya dan risiko memperkenalkan perubahan proses pembangunan yang sudah dimulai:

piramida menunjukkan risiko dan waktu perubahan biaya

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

w

Connecting to %s