Siklus hidup pengembangan perangkat lunak seluler

Membangun aplikasi seluler bisa semampu membuka Visual Studio, melemparkan sesuatu bersama-sama, melakukan sedikit pengujian, dan mengirimkan ke App Store - semua dilakukan di sore hari. Atau bisa menjadi proses yang sangat terlibat yang melibatkan desain up-front yang ketat, pengujian kegunaan, pengujian QA pada ribuan perangkat, siklus hidup beta penuh, dan kemudian menyebarkan sejumlah cara yang berbeda.

Dalam dokumen ini, kita akan mengambil pemeriksaan pengantar menyeluruh untuk membangun aplikasi seluler, termasuk:

1. Proses – Proses pengembangan perangkat lunak disebut Siklus Hidup Pengembangan Perangkat Lunak (SDLC). Kami akan memeriksa semua fase SDLC sehubungan dengan pengembangan aplikasi seluler, termasuk: Inception, Design, Development, Stabilization, Deployment, dan Maintenance.
2. Pertimbangan - Ada sejumlah pertimbangan saat membangun aplikasi seluler, terutama berbeda dengan aplikasi web atau desktop tradisional. Kami akan memeriksa pertimbangan ini dan bagaimana hal tersebut memengaruhi pengembangan seluler.

Dokumen ini dimaksudkan untuk menjawab pertanyaan mendasar tentang pengembangan aplikasi seluler, untuk pengembang aplikasi baru dan berpengalaman. Dibutuhkan pendekatan yang cukup komprehensif untuk memperkenalkan sebagian besar konsep yang akan Anda temui selama seluruh Siklus Hidup Pengembangan Perangkat Lunak (SDLC). Namun, dokumen ini mungkin tidak untuk semua orang, jika Anda gatal untuk mulai membangun aplikasi, kami sarankan untuk melompat ke depan ke panduan Pengenalan Pengembangan Seluler dan kemudian kembali ke dokumen ini nanti.

Siklus hidup perangkat lunak pengembangan seluler

Siklus hidup pengembangan seluler sebagian besar tidak berbeda dari SDLC untuk aplikasi web atau desktop. Seperti halnya itu, biasanya ada 5 bagian utama dari proses:

1. Inception – Semua aplikasi dimulai dengan ide. Ide itu biasanya disempurnakan menjadi dasar yang solid untuk aplikasi.
2. Desain – Fase desain terdiri dari menentukan User Experience (UX) aplikasi seperti apa tata letak umumnya, cara kerjanya, dll., serta mengubah UX tersebut menjadi desain User Interface (UI) yang tepat, biasanya dengan bantuan desainer grafis.
3. Pengembangan – Biasanya fase intensif sumber daya paling banyak, ini adalah bangunan aplikasi yang sebenarnya.
4. Stabilisasi - Ketika pengembangan cukup jauh, QA biasanya mulai menguji aplikasi dan bug diperbaiki. Sering kali aplikasi akan masuk ke fase beta terbatas di mana audiens pengguna yang lebih luas diberi kesempatan untuk menggunakannya dan memberikan umpan balik dan menginformasikan perubahan.
5. Penyebaran

Seringkali banyak dari potongan-potongan ini tumpang tindih, misalnya, umum untuk pengembangan yang akan terjadi saat UI sedang diselesaikan, dan bahkan dapat menginformasikan desain UI. Selain itu, aplikasi mungkin masuk ke fase stabilisasi pada fase yang sama dengan fitur baru yang ditambahkan ke versi baru.

Selain itu, fase ini dapat digunakan dalam sejumlah metodologi SDLC seperti Agile, Spiral, Waterfall, dll.

Masing-masing fase ini akan dijelaskan secara lebih rinci oleh bagian berikut.

Awal

Kesekian dan tingkat interaksi yang dimiliki orang dengan perangkat seluler berarti bahwa hampir semua orang memiliki ide untuk aplikasi seluler. Perangkat seluler membuka cara baru untuk berinteraksi dengan komputasi, web, dan bahkan infrastruktur perusahaan.

Tahap awal adalah tentang menentukan dan menyempurnakan ide untuk aplikasi. Untuk membuat aplikasi yang sukses, penting untuk mengajukan beberapa pertanyaan mendasar. Berikut adalah beberapa hal yang perlu dipertimbangkan sebelum menerbitkan aplikasi di salah satu App Store publik:

• Keuntungan Kompetitif - Apakah sudah ada aplikasi serupa di luar sana? Jika demikian, bagaimana aplikasi ini membedakan dari yang lain?

Untuk aplikasi yang akan didistribusikan di Enterprise:

• Integrasi Infrastruktur – Infrastruktur apa yang akan diintegrasikan dengan atau diperluas?

Selain itu, aplikasi harus dievaluasi dalam konteks faktor formulir seluler:

• Nilai – Nilai apa yang dibawa aplikasi ini kepada pengguna? Bagaimana mereka akan menggunakannya?
• Formulir/Mobilitas – Bagaimana cara kerja aplikasi ini dalam bentuk seluler? Bagaimana cara menambahkan nilai menggunakan teknologi seluler seperti kesadaran lokasi, kamera, dll.?

Untuk membantu merancang fungsionalitas aplikasi, akan berguna untuk menentukan Actor dan Use Cases. Aktor adalah peran dalam aplikasi dan seringkali merupakan pengguna. Kasus penggunaan biasanya merupakan tindakan atau niat.

Misalnya, aplikasi pelacakan tugas mungkin memiliki dua Aktor: Pengguna dan Teman. Pengguna mungkin Membuat Tugas, dan Berbagi Tugas dengan Teman. Dalam hal ini, membuat tugas dan berbagi tugas adalah dua kasus penggunaan berbeda yang, bersama dengan Actors, akan menginformasikan layar apa yang perlu Anda bangun, serta entitas bisnis dan logika apa yang perlu dikembangkan.

Setelah sejumlah kasus penggunaan dan aktor yang sesuai ditangkap, jauh lebih mudah untuk mulai merancang aplikasi. Pengembangan kemudian dapat berfokus pada cara membuat aplikasi, daripada apa yang harus atau harus dilakukan aplikasi.

Merancang aplikasi seluler

Setelah fitur dan fungsionalitas aplikasi ditentukan, langkah selanjutnya adalah mulai mencoba menyelesaikan Pengalaman Pengguna atau UX.

Desain UX

UX biasanya dilakukan melalui wireframe atau mockup menggunakan salah satu dari banyak toolkit desain. Mockup UX memungkinkan UX dirancang tanpa harus khawatir tentang desain UI yang sebenarnya:

Saat membuat mockup UX, penting untuk mempertimbangkan panduan antarmuka untuk berbagai platform yang akan ditargetkan aplikasi. Aplikasi harus "merasa di rumah" di setiap platform. Pedoman desain resmi untuk setiap platform adalah:

1. Panduan Antarmuka Manusia Apple -
2. Android – Panduan Desain
3. UWP – Dasar-dasar Desain UWP

Misalnya, setiap aplikasi memiliki metafora untuk beralih antar bagian dalam aplikasi. iOS menggunakan bilah tab di bagian bawah layar, Android menggunakan bilah tab di bagian atas layar, dan UWP menggunakan tampilan Pivot atau tab .

Selain itu, perangkat keras itu sendiri juga menentukan keputusan UX. Misalnya, perangkat iOS tidak memiliki tombol kembali fisik, dan karena itu memperkenalkan metafora Pengontrol Navigasi:

Selain itu, form factor juga memengaruhi keputusan UX. Tablet memiliki jauh lebih banyak real estat, sehingga dapat menampilkan lebih banyak informasi. Seringkali apa yang membutuhkan beberapa layar di ponsel dikompresi menjadi satu untuk tablet:

Dan karena segudang faktor bentuk di luar sana, seringkali ada faktor bentuk ukuran sedang (di suatu tempat antara ponsel dan tablet) yang mungkin juga ingin Anda targetkan.

Desain antarmuka pengguna (UI)

Setelah UX ditentukan, langkah selanjutnya adalah membuat desain UI. Meskipun UX biasanya hanya mockup hitam dan putih, fase Desain UI adalah tempat warna, grafis, dll., diperkenalkan dan diselesaikan. Menghabiskan waktu untuk desain UI yang baik penting dan umumnya, aplikasi paling populer memiliki desain profesional.

Seperti halnya UX, penting untuk dipahami bahwa setiap platform memiliki bahasa desainnya sendiri, sehingga aplikasi yang dirancang dengan baik mungkin masih terlihat berbeda di setiap platform:

Pengembangan

Fase pengembangan biasanya dimulai sangat awal. Bahkan, setelah ide memiliki beberapa pemahaman dalam fase konseptual/inspirasi, sering kali prototipe kerja dikembangkan yang memvalidasi fungsionalitas, asumsi, dan membantu memberikan pemahaman tentang cakupan pekerjaan.

Di sisa tutorial, kita akan berfokus pada fase pengembangan.

Stabilisasi

Stabilisasi adalah proses mengatasi bug di aplikasi Anda. Bukan hanya dari sudut fungsional, misalnya: "Ini crash ketika saya mengklik tombol ini," tetapi juga Kegunaan dan Performa. Yang terbaik adalah memulai stabilisasi sangat awal dalam proses pengembangan sehingga koreksi kursus dapat terjadi sebelum menjadi mahal. Biasanya, aplikasi masuk ke tahap Prototipe, Alpha, Beta, dan Kandidat Rilis. Orang yang berbeda mendefinisikan ini secara berbeda, tetapi mereka umumnya mengikuti pola berikut:

1. Prototipe – Aplikasi ini masih dalam fase bukti konsep dan hanya fungsionalitas inti, atau bagian tertentu dari aplikasi yang berfungsi. Bug utama hadir.
2. Alpha – Fungsionalitas inti umumnya adalah code-complete (dibangun, tetapi tidak sepenuhnya diuji). Bug utama masih ada, fungsionalitas terluar mungkin masih belum ada.
3. Beta - Sebagian besar fungsionalitas sekarang selesai dan telah memiliki setidaknya pengujian ringan dan perbaikan bug. Masalah utama yang diketahui mungkin masih ada.
4. Kandidat Rilis – Semua fungsionalitas selesai dan diuji. Melarang bug baru, aplikasi ini adalah kandidat untuk rilis ke alam liar.

Tidak pernah terlalu dini untuk mulai menguji aplikasi. Misalnya, jika masalah utama ditemukan dalam tahap prototipe, UX aplikasi masih dapat dimodifikasi untuk mengakomodasinya. Jika masalah performa ditemukan di tahap alfa, cukup awal untuk memodifikasi arsitektur sebelum banyak kode dibangun di atas asumsi palsu.

Biasanya, ketika aplikasi bergerak lebih jauh dalam siklus hidup, aplikasi dibuka untuk lebih banyak orang untuk mencobanya, mengujinya, memberikan umpan balik, dll. Misalnya, aplikasi prototipe hanya dapat ditampilkan atau disediakan untuk pemangku kepentingan utama, sedangkan aplikasi kandidat rilis dapat didistribusikan kepada pelanggan yang mendaftar untuk akses awal.

Untuk pengujian dan penyebaran awal ke perangkat yang relatif sedikit, biasanya menyebarkan langsung dari komputer pengembangan sudah cukup. Namun, ketika audiens melebar, ini bisa dengan cepat menjadi rumit. Dengan demikian, ada sejumlah opsi penyebaran pengujian di luar sana yang membuat proses ini jauh lebih mudah dengan memungkinkan Anda mengundang orang ke kumpulan pengujian, merilis build melalui web, dan menyediakan alat yang memungkinkan umpan balik pengguna.

Untuk pengujian dan penyebaran, Anda dapat menggunakan App Center untuk terus membangun, menguji, merilis, dan memantau aplikasi.

Distribusi

Setelah aplikasi distabilkan, saatnya untuk mengeluarkannya ke alam liar. Ada sejumlah opsi distribusi yang berbeda, tergantung pada platform.

iOS

Xamarin.iOS dan Objective-C aplikasi didistribusikan dengan cara yang sama persis:

1. Apple App Store – App Store Apple adalah repositori aplikasi online yang tersedia secara global yang dibangun di Mac OS X melalui iTunes. Sejauh ini, ini adalah metode distribusi paling populer untuk aplikasi dan memungkinkan pengembang untuk memetakan dan mendistribusikan aplikasi mereka secara online dengan sedikit usaha.
2. Penyebaran In-House – Penyebaran In-House dimaksudkan untuk distribusi internal aplikasi perusahaan yang tidak tersedia untuk umum melalui App Store.
3. Penyebaran Ad-Hoc – Penyebaran ad-hoc ditujukan terutama untuk pengembangan dan pengujian dan memungkinkan Anda menyebarkan ke sejumlah perangkat yang disediakan dengan benar. Saat Anda menyebarkan ke perangkat melalui Xcode atau Visual Studio untuk Mac, itu dikenal sebagai penyebaran ad-hoc.

Android

Semua aplikasi Android harus ditandatangani sebelum didistribusikan. Pengembang menandatangani aplikasi mereka dengan menggunakan sertifikat mereka sendiri yang dilindungi oleh kunci privat. Sertifikat ini dapat menyediakan rantai keaslian yang mengikat pengembang aplikasi dengan aplikasi yang telah dibangun dan dirilis pengembang. Perlu dicatat bahwa sementara sertifikat pengembangan untuk Android dapat ditandatangani oleh otoritas sertifikat yang dikenali, sebagian besar pengembang tidak memilih untuk menggunakan layanan ini, dan menandatangani sendiri sertifikat mereka. Tujuan utama sertifikat adalah untuk membedakan antara pengembang dan aplikasi yang berbeda. Android menggunakan informasi ini untuk membantu penegakan delegasi izin antara aplikasi dan komponen yang berjalan dalam OS Android.

Tidak seperti platform seluler populer lainnya, Android mengambil pendekatan yang sangat terbuka untuk distribusi aplikasi. Perangkat tidak dikunci ke satu penyimpanan aplikasi yang disetujui. Sebaliknya, siapa pun bebas membuat toko aplikasi, dan sebagian besar ponsel Android memungkinkan aplikasi diinstal dari toko pihak ketiga ini.

Ini memungkinkan pengembang saluran distribusi yang berpotensi lebih besar namun lebih kompleks untuk aplikasi mereka. Google Play adalah toko aplikasi resmi Google, tetapi ada banyak lainnya. Beberapa yang populer adalah:

1. AppBrain
2. Amazon App Store untuk Android
3. Handango
4. GetJar

UWP

Aplikasi UWP didistribusikan kepada pengguna melalui Microsoft Store. Pengembang mengirimkan aplikasi mereka untuk disetujui, setelah itu aplikasi tersebut muncul di Store. Untuk informasi selengkapnya tentang menerbitkan aplikasi Windows, lihat dokumentasi Terbitkan UWP.

Pertimbangan pengembangan seluler

Meskipun mengembangkan aplikasi seluler pada dasarnya tidak berbeda dengan pengembangan web/desktop tradisional dalam hal proses atau arsitektur, ada beberapa pertimbangan yang perlu diperhatikan.

Pertimbangan umum

Multitasking

Ada dua tantangan signifikan untuk multitugas (memiliki beberapa aplikasi yang berjalan sekaligus) pada perangkat seluler. Pertama, mengingat real estat layar terbatas, sulit untuk menampilkan beberapa aplikasi secara bersamaan. Oleh karena itu, pada perangkat seluler hanya satu aplikasi yang dapat berada di latar depan pada satu waktu. Kedua, memiliki beberapa aplikasi yang terbuka dan melakukan tugas dapat dengan cepat menggunakan daya baterai.

Setiap platform menangani multitugas secara berbeda, yang akan kita jelajahi sedikit.

Faktor bentuk

Perangkat seluler umumnya termasuk dalam dua kategori, ponsel dan tablet, dengan beberapa perangkat crossover di antaranya. Pengembangan untuk faktor bentuk ini umumnya sangat mirip, namun, merancang aplikasi untuk mereka bisa sangat berbeda. Telepon memiliki ruang layar yang sangat terbatas, dan tablet, sementara yang lebih besar, masih merupakan perangkat seluler dengan ruang layar yang lebih sedikit daripada laptop kebanyakan. Karena itu, kontrol UI platform seluler telah dirancang khusus agar efektif pada faktor bentuk yang lebih kecil.

Fragmentasi perangkat dan sistem operasi

Penting untuk mempertimbangkan perangkat yang berbeda di seluruh siklus hidup pengembangan perangkat lunak:

1. Konseptualisasi dan Perencanaan – Perlu diingat bahwa perangkat keras dan fitur akan bervariasi dari perangkat ke perangkat, aplikasi yang bergantung pada fitur tertentu mungkin tidak berfungsi dengan baik pada perangkat tertentu. Misalnya, tidak semua perangkat memiliki kamera, jadi jika Anda membangun aplikasi olahpesan video, beberapa perangkat mungkin dapat memutar video, tetapi tidak mengambilnya.
2. Desain – Saat merancang Pengalaman Pengguna (UX) aplikasi, perhatikan rasio dan ukuran layar yang berbeda di seluruh perangkat. Selain itu, saat merancang Antarmuka Pengguna (UI) aplikasi, resolusi layar yang berbeda harus dipertimbangkan.
3. Pengembangan – Saat menggunakan fitur dari kode, kehadiran fitur tersebut harus selalu diuji terlebih dahulu. Misalnya, sebelum menggunakan fitur perangkat, seperti kamera, selalu kueri OS untuk kehadiran fitur tersebut terlebih dahulu. Kemudian, saat menginisialisasi fitur/perangkat, pastikan untuk meminta yang saat ini didukung dari OS tentang perangkat tersebut lalu gunakan pengaturan konfigurasi tersebut.
4. Pengujian - Sangat penting untuk menguji aplikasi lebih awal dan sering pada perangkat yang sebenarnya. Bahkan perangkat dengan spesifikasi perangkat keras yang sama dapat sangat bervariasi dalam perilakunya.

Sumber daya terbatas

Perangkat seluler semakin kuat sepanjang waktu, tetapi perangkat seluler masih memiliki kemampuan terbatas dibandingkan dengan komputer desktop atau notebook. Misalnya, pengembang desktop umumnya tidak khawatir tentang kapasitas memori; mereka terbiasa memiliki memori fisik dan virtual dalam jumlah berlebihan, sedangkan pada perangkat seluler Anda dapat dengan cepat mengonsumsi semua memori yang tersedia hanya dengan memuat beberapa gambar berkualitas tinggi.

Selain itu, aplikasi intensif prosesor seperti game atau pengenalan teks benar-benar dapat dikenakan pajak pada CPU seluler dan berdampak buruk pada performa perangkat.

Karena pertimbangan seperti ini, penting untuk membuat kode dengan cerdas dan menyebarkan lebih awal dan sering ke perangkat aktual untuk memvalidasi responsivitas.

Pertimbangan iOS

Multitasking

Multitasking sangat dikontrol dengan ketat di iOS, dan ada sejumlah aturan dan perilaku yang harus sesuai dengan aplikasi Anda ketika aplikasi lain datang ke latar depan, jika tidak, aplikasi Anda akan dihentikan oleh iOS.

Sumber daya khusus perangkat

Dalam faktor bentuk tertentu, perangkat keras dapat sangat bervariasi di antara model yang berbeda. Misalnya, beberapa perangkat memiliki kamera belakang, beberapa juga memiliki kamera depan, dan beberapa tidak memilikinya.

Beberapa perangkat lama (i Telepon 3G dan yang lebih lama) bahkan tidak mengizinkan multitugas.

Karena perbedaan antara model perangkat ini, penting untuk memeriksa keberadaan fitur sebelum mencoba menggunakannya.

Batasan khusus OS

Untuk memastikan bahwa aplikasi responsif dan aman, iOS memberlakukan sejumlah aturan yang harus ditampung aplikasi. Selain aturan mengenai multitugas, ada sejumlah metode peristiwa di mana aplikasi Anda harus kembali dalam jumlah waktu tertentu, jika tidak, aplikasi akan dihentikan oleh iOS.

Perlu dicatat juga, aplikasi berjalan di apa yang dikenal sebagai Sandbox, lingkungan yang memberlakukan batasan keamanan yang membatasi apa yang dapat diakses aplikasi Anda. Misalnya, aplikasi dapat membaca dari dan menulis ke direktorinya sendiri, tetapi jika mencoba menulis ke direktori aplikasi lain, aplikasi tersebut akan dihentikan.

Pertimbangan Android

Multitasking

Multitugas di Android memiliki dua komponen; yang pertama adalah siklus hidup aktivitas. Setiap layar dalam aplikasi Android diwakili oleh Aktivitas, dan ada serangkaian peristiwa tertentu yang terjadi ketika aplikasi ditempatkan di latar belakang atau datang ke latar depan. Aplikasi harus mematuhi siklus hidup ini untuk menciptakan aplikasi yang responsif dan berkinerja baik. Untuk informasi selengkapnya, lihat panduan Siklus Hidup Aktivitas.

Komponen kedua untuk multitugas di Android adalah penggunaan Layanan. Layanan adalah proses jangka panjang yang tidak bergantung pada aplikasi dan digunakan untuk menjalankan proses saat aplikasi berada di latar belakang. Untuk informasi selengkapnya, lihat panduan Membuat Layanan .

Banyak perangkat dan banyak faktor bentuk

Google tidak memberlakukan batasan apa pun pada perangkat mana yang dapat menjalankan OS Android. Paradigma terbuka ini menghasilkan lingkungan produk yang diisi oleh segudang perangkat yang berbeda dengan perangkat keras, resolusi dan rasio layar, fitur perangkat, dan kemampuan yang sangat berbeda.

Karena fragmentasi ekstrem perangkat Android, kebanyakan orang memilih 5 atau 6 perangkat paling populer untuk didesain dan diuji, dan memprioritaskan perangkat tersebut.

Pertimbangan keamanan

Aplikasi di OS Android semuanya berjalan di bawah identitas yang berbeda dan terisolasi dengan izin terbatas. Secara default, aplikasi dapat melakukan sangat sedikit. Misalnya, tanpa izin khusus, aplikasi tidak dapat mengirim pesan teks, menentukan status telepon, atau bahkan mengakses Internet! Untuk mengakses fitur-fitur ini, aplikasi harus menentukan dalam file manifes aplikasi mereka izin mana yang mereka inginkan, dan kapan mereka diinstal; OS membaca izin tersebut, memberi tahu pengguna bahwa aplikasi meminta izin tersebut, lalu memungkinkan pengguna untuk melanjutkan atau membatalkan penginstalan. Ini adalah langkah penting dalam model distribusi Android, karena model penyimpanan aplikasi terbuka, karena aplikasi tidak dikurasi seperti untuk iOS, misalnya. Untuk daftar izin aplikasi, lihat artikel referensi Izin Manifes di Dokumentasi Android.

Pertimbangan Windows

Multitasking

Multitugas dalam UWP memiliki dua bagian: siklus hidup untuk halaman dan aplikasi, dan proses latar belakang. Setiap layar dalam aplikasi adalah instans kelas Halaman, yang memiliki peristiwa yang terkait dengan dibuat aktif atau tidak aktif (dengan aturan khusus untuk menangani status tidak aktif, atau "dikubur").

Bagian kedua adalah menyediakan agen latar belakang untuk memproses tugas bahkan ketika aplikasi tidak berjalan di latar depan.

Kemampuan perangkat

Meskipun perangkat keras UWP cukup homogen, masih ada komponen yang opsional dan karenanya memerlukan pertimbangan khusus saat pengodean. Kemampuan perangkat keras opsional termasuk kamera, kompas, dan giroskop. Ada juga kelas khusus memori rendah (256MB) yang memerlukan pertimbangan khusus, atau pengembang dapat menolak dukungan memori rendah.

Pertimbangan keamanan

Untuk informasi tentang pertimbangan keamanan penting di UWP, lihat dokumentasi Keamanan .

Ringkasan

Panduan ini memberikan pengantar SDLC karena berkaitan dengan pengembangan seluler. Ini memperkenalkan pertimbangan umum untuk membangun aplikasi seluler dan memeriksa sejumlah pertimbangan khusus platform termasuk desain, pengujian, dan penyebaran.

Langkah berikutnya

• Apa itu Xamarin?
• Mulai menggunakan Xamarin
• Berbagi kode di seluruh platform