A Mobile Development Software Development Lifecycle (SDLC) is composed of distinct work phases used to plan, design, build, test, and deliver a mobile app.
An SDLC aims to produce high quality apps that meet or exceed our customer expectations.
We need to base our apps on customer requirements. To do that, it helps to move through clearly defined phases, and prepare scheduled time-frames and accurate cost estimates:
Usually there are six major phases:
Idea: All apps start with an idea. That idea is usually refined throughout the entire SDLC process.
Design: In this phase we define the general layout and how it works. It usually starts by defining the User Experience (UX), converted into a UI design.
Development: This phase is the most intensive for us. In this phase we build the application.
Testing: When the development phase is far enough along, we can release a test application to the QA or test users. This allows us to address possible issues that our app might contain. Testing early is good for our products. Some software development methodologies are driven by testing, or include feature based testing as soon as a feature is available.
Deployment: This releases the app to the stores, or in some of the preview environments available.
Feedback: In this phase, we collect opinions on the app, and based on them, start the process again. This is an important and often under evaluated phase. Listening to our final users is always more important than the technology we use.
These phases often overlap. For example, it is common to start development before the design is finished, or start testing before the development is at a good point but not completed yet.
Ideas are cheap! Execution is worth millions! Walking on the streets of San Francisco, you will hear that many times. It is actually pretty true. Ideas are cheap.
Potentially everyone has a brilliant idea for the next killer app!
Defining an idea is a key phase in creating a successful app. It is only a small step compared to the execution but it is an important step. Having a clear idea helps us to have clarity from the beginning about what we need to do to transform the idea into reality.
It is all about asking and replying to fundamental questions driven by the market.
To define an idea, we can create our own template in order to have the big picture of the overall app.
In the following table, I am including questions I usually need in order to understand what I am going to develop and why.
We can copy, fill, and pin it in front of us in order to not lose focus during all the phases of the SDLC:
|
Question |
Answer |
|
Are there similar apps? If so, how does the idea of the application differentiate from the others? | |
|
Will the application integrate with or extend the existing infrastructure? If so, what kind of infrastructure needs to be extended or integrated by the app? | |
|
What value does this app bring to users? | |
|
How can I add value using mobile technologies such as location awareness, the camera, and so on? |
This table can obviously grow. The experience will always suggest new questions to us.
An idea sets one or more goals.
When we have the list of goals, we can think about all the steps the user needs to take in order to achieve each one of them. The user is called the Actor. Sometime an actor can be another system connected to our app.
The steps the Actor needs to take to achieve a goal are called the usecase.
Defining Actors and usecases tells us what the requirement specifications are.
After that, we can focus on how to design a technical solution that covers the requirement specifications.
When we know what is needed, we can start to think about UX and UI.
The UX design is the process of maximizing the usability and the interaction between the user and the application.
This is usually done using mockups and wireframes that may be created even with low tech tools: pencil and paper. But don't worry, that is not the only way! There are tools such as Balsamiq and InVisio that help UX designers to define mockups, providing a first feeling of the app.
This helps to define the interactions and the placeholders before starting the UI design.
User experience is not cross-platform.
When designing the user experience, it is important to consider the interface guidelines for each of the platforms we are designing for.
By following the platform-specific guidelines, we can ensure that our apps are well integrated on the operating system where they are running:
Apple: Human Interface Guidelines - http://goo.gl/Mi3HPL
Android: Design Guidelines - http://goo.gl/LA3fYh
Windows: Design library for Windows Phone - http://goo.gl/FQ4IW6
For example, each platform has its own way to switch between sections, to manage images, and so on. Even the available hardware influences the user expectations for our app. For example, Android devices have a back button, while iOS users expect to have a button in the UI that drives them back to the previous section and the only button is expected to go to the main screen.
UI design transforms the mockups into graphics elements. Spending time on a good UI design is always a good investment. Consider that the most popular apps generally also have great designs and usability.
A well-designed app usually looks different on each platform. As for the UX, it's important to understand that each platform has its own design language.
One example of these differences is the dimension of icons and images that we need in order to see them sharply and crisply on each supported platform.
Development often starts with a proof of concept that validates functionality.
The rest of the book will focus on this phase.
This is the process of finding and working out the bugs in our app.
Testing generally includes usability and design reviews.
This phase is the overall test of the app, and generally the application follows different stages:
Proof of Concept: Only the core functionality is working and major bugs are present.
Alpha: Core functionality is code-complete and not fully tested. Major bugs are still present and some features may still not be available.
Beta: Most of the functionality is complete. Known issues are present. The app has had some testing and bug fixing.
Release candidate: All functionality is complete and tested. The app is ready to be published.
Xamarin provides a powerful testing framework called Xamarin Test Cloud. This allows us to write automated UI testing.
During development, we can write small tests to check single functionalities (unit testing). We will experience how to develop testing with C# and NUnit later in the book.
In general, the sooner the app is tested, the earlier we can address the issues. For example, if a major issue is found in the proof of concept, the UX of the app can be still modified to address it.
There are different tools to support the distribution in the test phase:
TestFairy (http://testfairy.com/): Supports Android and iOS apps
HockeyApp (http://hockeyapp.net/): Supports Android, iOS, and Windows apps
Raygun.IO (https://raygun.io/): Supports Android, iOS, and Windows apps
Xamarin Insights (https://xamarin.com/insights) is a technology presented in 2014 and designed to bring analytics and crash reporting to our mobile app. It is a real-time monitoring system that enables us to identify, report, and track issues that are impacting users with a simple and effective API.
We will explore the features of Xamarin Insight later in the book.
Once our application is stable enough, we can publish it. The deployment is a platform specific step. The distribution options depend on the platform. We will explore an example of deployment in the last chapter of this book. For now, we will have a quick overview of the options.
Apple iOS apps are distributed to the Apple "App Store" via "Apple Connect".
When we submit an App to Apple Connect, we have to wait for a validation. Usually Apple is very strict with the validation process and it can take some weeks.
If our app is not compliant with all the Apple guidelines, it will be rejected with a list of issues to address in order to be compliant.
The Apple Store is the most popular distribution method for iOS applications, and it allows us to market and distribute our apps online with very little effort.
The second type of deployment is the enterprise deployment.
This is used for internal distribution of corporate applications that aren't available via the App Store.
A deployment also exists that is intended primarily for development and testing: "ad-hoc deployment".
The official app store for Android is Google Play, but as we will see, there are a few other different stores that we can consider.
Android is also open to app distribution. Devices are not locked to a single, approved app store.
Anyone is free to create an app store, and most Android phones allow apps to be installed from these third-party stores.
This allows us a potentially larger distribution channel for our applications.
Windows Phone applications are distributed to users via the Windows Store.
We need to submit our apps to the Windows Phone Dev Center for approval, after which they appear in the Store. When we submit our apps to the Windows Store, we can also provide an install link to the testers before the app is reviewed and published.