Senin, 19 Agustus 2019

thumbnail

Panduan Untuk Memahami Proses Pengembangan Perangkat Lunak


Banyak pebisnis tidak sepenuhnya memahami kompleksitas proses pengembangan perangkat lunak. Itu wajar, karena buku-buku khusus tentang pengembangan dibaca oleh pengembang dan orang-orang TI lainnya, dan banyak yang lain mungkin masih menyebut proyek perangkat lunak sebagai '' pengkodean '' atau '' penulisan ''. Dengan keberuntungan yang lebih baik, seseorang dapat menambahkan 'desain' dan 'pengujian'. Cukup tidak akurat.



Orang dapat memikirkan beberapa perbandingan metaforis untuk menggambarkan pengembangan perangkat lunak, seperti menulis buku atau membangun rumah. Beberapa dari mereka adalah cahaya yang baik dalam gelap, beberapa agak menyesatkan. Dan sementara banyak orang mungkin berpendapat apakah membuat selengkapnya adalah seni, ilmu pengetahuan, atau proses yang diuraikan secara tepat, kami akan menyerahkan pilihan itu kepada orang lain. Itu tidak dapat dijelaskan dengan jarang. Tetapi kami akan mencoba memberikan beberapa deskripsi dan perbandingan dengan cara yang ringkas dan jelas.

Apakah Kita 'Menulis' Perangkat Lunak?

Salah satu hal yang umum tetapi agak kabur adalah membandingkan membuat perangkat lunak dengan menulis. Menulis kode, menulis buku, dan sebagainya. Anda dapat mulai menulis buku tanpa rencana dan mengikuti arus; dengan pengembangan perangkat lunak khusus, Anda tidak bisa, kecuali jika pengembang melakukan sendiri perangkat lunak yang agak kecil - dan untuk diri mereka sendiri. Selain itu, proyek perangkat lunak outsourcing tidak pernah dimulai dengan menulis kode.

Buku dan perangkat lunak mungkin memiliki tenggat waktu yang ketat. Tetapi begitu sebuah buku diterbitkan, apa yang tertulis ditulis; menulis ulang bukanlah suatu pilihan. Tetapi perangkat lunak terus berada dalam perbaikan terus-menerus dengan versi baru dirilis - itu adalah hal yang wajar. Hampir tidak mungkin untuk mendapatkan setiap kebutuhan pengguna akhir Anda, mengejar ketinggalan dengan perubahan bisnis dan teknologi sekali dan seumur hidup. Buku tidak terlalu tergantung pada perubahan; perangkat lunak. Tapi itu bagus: perangkat lunak Anda, tidak seperti buku, tidak bisa menjadi hal biasa-biasa saja di pasar, tidak bisa menjadi tidak relevan dan ketinggalan zaman. Prosesnya benar-benar berbeda: kami lebih suka menggunakan kata '' create '' atau '' build '' software daripada '' write ''.

Apakah Kita 'Tumbuh' Perangkat Lunak?

Perangkat lunak 'Tumbuh' dengan dasar yang baik dan serangkaian dokumentasi yang baik dimungkinkan sampai batas tertentu. Seperti halnya menulis, ini bukan deskripsi terbaik yang bisa disarankan. Ini sebagian mendapatkan tambahan, sifat lincah membuat dan memelihara perangkat lunak yang relevan. Tetapi ketika 'tumbuh', produk jarang lezat sampai matang, dan pemilik harus menunggu sebentar.

Perbedaannya adalah, dalam pengembangan perangkat lunak ada berbagai tahapan menjadi '' matang ''. Startups biasanya meminta bergulir produk perangkat lunak minimum yang layak di pasar, mendapatkan umpan balik dan membuat perbaikan dan perbaikan. Setiap versi lebih '' matang '' dari pendahulunya, dan itu harus '' disiram '' oleh dukungan dan pemeliharaan, tetap segar di tengah-tengah semua perubahan bisnis dan teknologi.

Apakah Kami 'Membangun' Perangkat Lunak?

Yang ini dianggap oleh banyak spesialis sebagai cara terdekat untuk menggambarkan pengembangan perangkat lunak, dan kami dapat menyetujuinya. Pekerjaan konstruksi menunjukkan pentingnya perencanaan, persiapan, panduan kerja, dan pelaksanaannya. Batas perangkat lunak bergantung pada bagaimana arsitekturnya dibangun. Jumlah pekerjaan tidak tumbuh secara bertahap, karena setiap bangunan berbeda, dan memerlukan pendekatan yang berbeda. Mungkin ada rumah sakit, gedung kantor, sekolah atau gudang, dan ukuran fisik yang sama tidak berarti jumlah tenaga kerja yang sama. Sesuatu dilakukan dengan beton, sesuatu dapat dilakukan dengan kayu dan paku, dan yang terakhir tidak bekerja dengan baik dengan perangkat lunak yang kompleks dan berharga untuk startup seluler dan bisnis lainnya.

- Semuanya tergantung pada jenis bangunan yang Anda butuhkan. Anda perlu mencari tahu masalah yang akan diselesaikan oleh perangkat lunak, dan melakukan persiapan yang diperlukan, melakukan riset pasar, mengumpulkan info, dll. Semakin kompleks perangkat lunak Anda, semakin banyak sumber daya yang harus dikeluarkan untuk perencanaan. Perencanaan yang buruk - dan seluruh aplikasi gagal, jatuh seperti rumah kartu oleh hembusan angin pertama.

- Kemudian Anda dan kepala arsitek (manajer proyek) Anda dapat melanjutkan ke desain yang secara sempurna menggabungkan persyaratan fungsional dan antarmuka, menghasilkan pengalaman pengguna yang tepat. Tentu Anda ingin mereka yang bekerja atau tinggal di gedung puas sepenuhnya dengannya. Hal yang sama dengan perangkat lunak. Satu hal lagi yang baik, setelah desain disetujui, akan lebih mudah untuk memberikan estimasi yang lebih tepat untuk sisa pekerjaan konstruksi (pengembangan).

- Saat memberikan rumah, Anda tidak perlu membangun barang yang bisa Anda beli: peralatan dan perabot rumah tangga. Jauh lebih murah dan jauh lebih cepat. Sama dengan perangkat lunak: jika tim pengembangan perangkat lunak Anda berpengalaman, ia akan menggunakan semua sumber daya yang tersedia untuk menghindari penulisan hal-hal dasar yang tidak perlu: ada banyak perangkat perangkat lunak, kerangka kerja, kelas, dan perpustakaan untuk itu, masing-masing untuk kasus tertentu. Dan jika tim itu berarti bisnis, mereka akan dengan mudah menemukan alat dan teknologi yang akan menyelesaikan tugas Anda secepat mungkin. Perabotan khusus membutuhkan lebih banyak waktu dan upaya, tetapi dalam kebanyakan kasus sudah ada cara yang sudah ada sebelumnya untuk menghemat waktu dan uang Anda tanpa mengorbankan keamanan dan efisiensi perangkat lunak Anda.

- Akan selalu ada perubahan dalam persyaratan fungsional. Sekali lagi, perubahan tanpa rasa sakit dapat terjadi dalam arsitektur yang direncanakan. Di sini kami sekali lagi menekankan pentingnya persiapan - meskipun topik ini layak untuk artikel terpisah. Dan kita tidak dapat pergi ke mana pun tanpa menyebutkan jaminan kualitas, yang secara terus-menerus memeriksa berbagai aspek cara kerja perangkat lunak. Terlebih lagi - bahkan perubahan kecil melibatkan pengujian, jadi itu bukan tempat untuk memotong biaya (pada kenyataannya, QA biasanya membutuhkan sekitar 30% dari seluruh waktu pengembangan).

- Optimalisasi perangkat lunak (dinding bagian dalam bangunan) terbatas pada arsitektur yang disetujui, dan di sini pengeluaran utama adalah semua tentang tenaga kerja, bukan bahan. Tetapi apa yang Anda terima pada akhirnya adalah perangkat lunak yang lebih baik dan pengguna yang puas. Sementara itu, pengguna berbicara tentang apa yang mereka inginkan dari apartemen - dan orang tidak boleh mengabaikan pendapat ini.

- Satu hal lagi yang perlu diperhatikan - seorang arsitek yang baik (atau ahli kreatif yang baik dalam pengembangan perangkat lunak) selalu siap untuk berkonsultasi dengan Anda tentang hal-hal yang harus diselesaikan segera, dan apa yang dapat dibiarkan nanti tanpa melanggar rencana Anda atau kualitas Anda perangkat lunak. Anda kemungkinan besar tidak mengetahui seluk-beluk sisi teknis - jadi tinggalkan saran dan penjelasan untuk tim Anda. Kecuali jika Anda adalah orang IT yang berpengalaman dan Anda tidak perlu membaca artikel ini untuk mendapatkan wawasan ini.

Seperti yang Anda lihat, contoh terakhir adalah yang paling dekat, dan daftar kesamaan dapat dilanjutkan selamanya. Tetapi yang kami sajikan di sini harus cukup untuk memahami proses pengembangan perangkat lunak, yang tidak mungkin tanpa kesabaran, keahlian tim, dan saling pengertian.



Article Source: http://EzineArticles.com/8606715Banyak pebisnis tidak sepenuhnya memahami kompleksitas proses pengembangan perangkat lunak. Itu wajar, karena buku-buku khusus tentang pengembangan dibaca oleh pengembang dan orang-orang TI lainnya, dan banyak yang lain mungkin masih menyebut proyek perangkat lunak sebagai '' pengkodean '' atau '' penulisan ''. Dengan keberuntungan yang lebih baik, seseorang dapat menambahkan 'desain' dan 'pengujian'. Cukup tidak akurat.

Orang dapat memikirkan beberapa perbandingan metaforis untuk menggambarkan pengembangan perangkat lunak, seperti menulis buku atau membangun rumah. Beberapa dari mereka adalah cahaya yang baik dalam gelap, beberapa agak menyesatkan. Dan sementara banyak orang mungkin berpendapat apakah membuat perangkat lunak adalah seni, ilmu pengetahuan, atau proses yang diuraikan secara tepat, kami akan menyerahkan pilihan itu kepada orang lain. Itu tidak dapat dijelaskan dengan jarang. Tetapi kami akan mencoba memberikan beberapa deskripsi dan perbandingan dengan cara yang ringkas dan jelas.

Apakah Kita 'Menulis' Perangkat Lunak?

Salah satu hal yang umum tetapi agak kabur adalah membandingkan membuat perangkat lunak dengan menulis. Menulis kode, menulis buku, dan sebagainya. Anda dapat mulai menulis buku tanpa rencana dan mengikuti arus; dengan pengembangan perangkat lunak khusus, Anda tidak bisa, kecuali jika pengembang melakukan sendiri perangkat lunak yang agak kecil - dan untuk diri mereka sendiri. Selain itu, proyek perangkat lunak outsourcing tidak pernah dimulai dengan menulis kode.

Buku dan perangkat lunak mungkin memiliki tenggat waktu yang ketat. Tetapi begitu sebuah buku diterbitkan, apa yang tertulis ditulis; menulis ulang bukanlah suatu pilihan. Tetapi perangkat lunak terus berada dalam perbaikan terus-menerus dengan versi baru dirilis - itu adalah hal yang wajar. Hampir tidak mungkin untuk mendapatkan setiap kebutuhan pengguna akhir Anda, mengejar ketinggalan dengan perubahan bisnis dan teknologi sekali dan seumur hidup. Buku tidak terlalu tergantung pada perubahan; perangkat lunak. Tapi itu bagus: perangkat lunak Anda, tidak seperti buku, tidak bisa menjadi hal biasa-biasa saja di pasar, tidak bisa menjadi tidak relevan dan ketinggalan zaman. Prosesnya benar-benar berbeda: kami lebih suka menggunakan kata '' create '' atau '' build '' software daripada '' write ''.

Apakah Kita 'Tumbuh' Perangkat Lunak?

Perangkat lunak 'Tumbuh' dengan dasar yang baik dan serangkaian dokumentasi yang baik dimungkinkan sampai batas tertentu. Seperti halnya menulis, ini bukan deskripsi terbaik yang bisa disarankan. Ini sebagian mendapatkan tambahan, sifat lincah membuat dan memelihara perangkat lunak yang relevan. Tetapi ketika 'tumbuh', produk jarang lezat sampai matang, dan pemilik harus menunggu sebentar.

Perbedaannya adalah, dalam pengembangan perangkat lunak ada berbagai tahapan menjadi '' matang ''. Startups biasanya meminta bergulir produk perangkat lunak minimum yang layak di pasar, mendapatkan umpan balik dan membuat perbaikan dan perbaikan. Setiap versi lebih '' matang '' dari pendahulunya, dan itu harus '' disiram '' oleh dukungan dan pemeliharaan, tetap segar di tengah-tengah semua perubahan bisnis dan teknologi.

Apakah Kami 'Membangun' Perangkat Lunak?

Yang ini dianggap oleh banyak spesialis sebagai cara terdekat untuk menggambarkan pengembangan perangkat lunak, dan kami dapat menyetujuinya. Pekerjaan konstruksi menunjukkan pentingnya perencanaan, persiapan, panduan kerja, dan pelaksanaannya. Batas perangkat lunak bergantung pada bagaimana arsitekturnya dibangun. Jumlah pekerjaan tidak tumbuh secara bertahap, karena setiap bangunan berbeda, dan memerlukan pendekatan yang berbeda. Mungkin ada rumah sakit, gedung kantor, sekolah atau gudang, dan ukuran fisik yang sama tidak berarti jumlah tenaga kerja yang sama. Sesuatu dilakukan dengan beton, sesuatu dapat dilakukan dengan kayu dan paku, dan yang terakhir tidak bekerja dengan baik dengan perangkat lunak yang kompleks dan berharga untuk startup seluler dan bisnis lainnya.

- Semuanya tergantung pada jenis bangunan yang Anda butuhkan. Anda perlu mencari tahu masalah yang akan diselesaikan oleh perangkat lunak, dan melakukan persiapan yang diperlukan, melakukan riset pasar, mengumpulkan info, dll. Semakin kompleks perangkat lunak Anda, semakin banyak sumber daya yang harus dikeluarkan untuk perencanaan. Perencanaan yang buruk - dan seluruh aplikasi gagal, jatuh seperti rumah kartu oleh hembusan angin pertama.

- Kemudian Anda dan kepala arsitek (manajer proyek) Anda dapat melanjutkan ke desain yang secara sempurna menggabungkan persyaratan fungsional dan antarmuka, menghasilkan pengalaman pengguna yang tepat. Tentu Anda ingin mereka yang bekerja atau tinggal di gedung puas sepenuhnya dengannya. Hal yang sama dengan perangkat lunak. Satu hal lagi yang baik, setelah desain disetujui, akan lebih mudah untuk memberikan estimasi yang lebih tepat untuk sisa pekerjaan konstruksi (pengembangan).

- Saat memberikan rumah, Anda tidak perlu membangun barang yang bisa Anda beli: peralatan dan perabot rumah tangga. Jauh lebih murah dan jauh lebih cepat. Sama dengan perangkat lunak: jika tim pengembangan perangkat lunak Anda berpengalaman, ia akan menggunakan semua sumber daya yang tersedia untuk menghindari penulisan hal-hal dasar yang tidak perlu: ada banyak perangkat perangkat lunak, kerangka kerja, kelas, dan perpustakaan untuk itu, masing-masing untuk kasus tertentu. Dan jika tim itu berarti bisnis, mereka akan dengan mudah menemukan alat dan teknologi yang akan menyelesaikan tugas Anda secepat mungkin. Perabotan khusus membutuhkan lebih banyak waktu dan upaya, tetapi dalam kebanyakan kasus sudah ada cara yang sudah ada sebelumnya untuk menghemat waktu dan uang Anda tanpa mengorbankan keamanan dan efisiensi perangkat lunak Anda.

- Akan selalu ada perubahan dalam persyaratan fungsional. Sekali lagi, perubahan tanpa rasa sakit dapat terjadi dalam arsitektur yang direncanakan. Di sini kami sekali lagi menekankan pentingnya persiapan - meskipun topik ini layak untuk artikel terpisah. Dan kita tidak dapat pergi ke mana pun tanpa menyebutkan jaminan kualitas, yang secara terus-menerus memeriksa berbagai aspek cara kerja perangkat lunak. Terlebih lagi - bahkan perubahan kecil melibatkan pengujian, jadi itu bukan tempat untuk memotong biaya (pada kenyataannya, QA biasanya membutuhkan sekitar 30% dari seluruh waktu pengembangan).

- Optimalisasi perangkat lunak (dinding bagian dalam bangunan) terbatas pada arsitektur yang disetujui, dan di sini pengeluaran utama adalah semua tentang tenaga kerja, bukan bahan. Tetapi apa yang Anda terima pada akhirnya adalah jasa software yang lebih baik dan pengguna yang puas. Sementara itu, pengguna berbicara tentang apa yang mereka inginkan dari apartemen - dan orang tidak boleh mengabaikan pendapat ini.

- Satu hal lagi yang perlu diperhatikan - seorang arsitek yang baik (atau ahli kreatif yang baik dalam pengembangan perangkat lunak) selalu siap untuk berkonsultasi dengan Anda tentang hal-hal yang harus diselesaikan segera, dan apa yang dapat dibiarkan nanti tanpa melanggar rencana Anda atau kualitas Anda perangkat lunak. Anda kemungkinan besar tidak mengetahui seluk-beluk sisi teknis - jadi tinggalkan saran dan penjelasan untuk tim Anda. Kecuali jika Anda adalah orang IT yang berpengalaman dan Anda tidak perlu membaca artikel ini untuk mendapatkan wawasan ini.

Seperti yang Anda lihat, contoh terakhir adalah yang paling dekat, dan daftar kesamaan dapat dilanjutkan selamanya. Tetapi yang kami sajikan di sini harus cukup untuk memahami proses pengembangan perangkat lunak, yang tidak mungkin tanpa kesabaran, keahlian tim, dan saling pengertian.

Subscribe by Email

Follow Updates Articles from This Blog via Email

No Comments

About

Diberdayakan oleh Blogger.