Assessing Project Risks Android

In addition to the normal risks any software project must identify, mobile projects need to be aware of the outside influences that can affect their project schedule and whether the project requirements can be met. Some of the risk factors include identifying and acquiring target devices and continually reassessing application feasibility.

Identifying Target Devices

Just as most sane software developers wouldn’t write a desktop application without first deciding what operating systems (and their versions) the application would run on, mobile developers must consider the target devices their application will run on. Each device has different capabilities, a different user interface, and unique limitations.

Target devices are generally determined in one of two ways:

  • There’s a popular “killer” device you want to develop for.
  • You want to develop an application for maximum coverage.

In the first instance, you have your initial target device (or class of devices) figured out; in the second instance, you want to look at the available (and soon to be available) devices on the market and adjust your application specification to cover as many as is reasonably feasible.

Understanding How Manufacturers and Operators Fit In

It’s also important to note that we’ve seen popular product lines, such as the Droid line of Android devices, customized by a number of manufacturers. A carrier often ships its custom version of a device, including a different user experience or skin, as well as big bundles of custom applications (taking up a bunch of space on the device).The carrier might also disable specific device features (such as Bluetooth or Wi-Fi), which effectively makes it impossible for your application to run. You must take all these factors into account when considering your application requirements and abilities. Your application’s running requirements must match the features shared across all target devices and handle optional feature use appropriately in all cases.

Understanding How Devices Come and Go Over Time

New devices are developed all the time. Carriers and manufacturers retire (sunset) devices all the time. Different carriers might carry the same (or similar) device but might sunset (retire) the devices at a different time.

Developers need to understand how different kinds of device models can move through the worldwide marketplace. Some devices are available (or become popular) only in certain geographic regions. Sometimes devices are released worldwide, but often they are released regionally. The T-Mobile G1, for example, was first released in the United States but later released worldwide. Similarly, the Motorola Droid was only available in the United States, whereas the similar Motorola Milestone was available only outside the United States.

Historically, it’s been common for a device (or new generation of devices) to become available initially in market-driving regions of eastern Asia, including South Korea and Japan, and then show up in Europe, North America, and Australia, where device users often upgrade every year or two and pay premium rates for applications. Finally, these same devices become available in Central and South America, China, and India, where subscribers often don’t have landlines nor do they have the same levels of income. Regions such as China and India must often be treated as entirely separate mobile marketplaces—with more affordable devices requiring vastly different revenue models. Here applications sell for less, but revenue is instead derived from the huge and growing subscriber base.

Acquiring Target Devices

The earlier you can get your hands on the target devices, the better off you are. Sometimes this is as easy as going to the store and buying a new device. Other times, you need to acquire devices in other ways.

It is quite common for an application developer to target upcoming devices—devices not yet shipping or available to consumers. There is a great competitive advantage to having your application ready to run the moment consumers have the device in their hands for the first time. For preproduction devices, you can join manufacturer and operator developer programs. These programs help you keep abreast of changes to the device lines (upcoming models, discontinued models). Many of these programs also include preproduction device loan programs, enabling developers to get their hands on the device before consumers do.

There are risks for developers writing applications for specific preproduction devices because device shipment dates often slide and the platform might have unstable or bug prone firmware. Devices are delayed or canceled. Device features (especially new and interesting ones) are not set in stone until the device ships and the developer verifies that those features work as expected. Exciting new devices are announced all the time— devices you might want your application to support. Your project plan must be flexible enough to change and adapt with the market as necessary.

Determining Feasibility of Application Requirements

Mobile developers are at the mercy of the device limitations, which vary in terms of memory and processing power, screen type, and platform version. Mobile developers do not really have the luxury traditional desktop application developers have of saying an application requires “more memory” or “more space.” Device limitations are pretty much fixed, and if a mobile application is to run, it runs within the device’s limitations, or not at all. Technically speaking, most Android devices have some hardware flexibility, such as the ability to use external storage devices such as SD cards, but we’re still talking about limited resources.

You can do true feasibility assessment only on the physical device, not the software emulator. Your application might work beautifully in the emulator but falter on the actual device. Mobile developers most constantly revisit feasibility, application responsiveness, and performance throughout the development process.

Understanding Quality Assurance Risks

The quality assurance team has its work cut out for it because the testing environment is generally less than ideal.

Testing Early, Testing Often

Get those target devices in-hand as early as possible. For preproduction devices, it can take months to get the hardware in hand from the manufacturer. Cooperating with carrier device loaner programs and buying devices from retail locations is frustrating but sometimes necessary. Don’t wait until the last minute to gather the test hardware.

Testing on the Device

It cannot be said enough: Testing on the emulator is helpful, but testing on the device is essential. In reality, it doesn’t matter if the application works on the emulator—no one uses an emulator in the real world.

Although you can perform factory resets on devices and wipe user data, there is often no easy way to completely “wipe” a device and return it to a clean starting state, so the quality assurance team needs to determine and stick to a testing policy of what is considered a clean state on the device. Testers might need to learn to flash devices with different firmware versions and understand subtle differences between platform versions, as well as how underlying application data is stored on the device (for example, SQLite databases, private application files, and cache usage).

Mitigating the Risk of Limited Real-World Testing Opportunities

In some ways, every quality assurance tester works within a controlled environment. This is doubly true for mobile testers. They often work with devices not on real networks and preproduction devices that might not match those in the field. Add to this that because testing generally takes place in a lab, the location (including primary cell tower, satellite fixes and related device signal strength, availability of data services, LBS information, and locale information) is fixed. The quality assurance team needs to get creative to mitigate the risks of testing too narrow a range of these factors. For example, it is essential to test all applications when the device has no signal (and in airplane mode, and such) to make sure they don’t crash and burn under such conditions that we all experience at some point in time.

Testing Client-Server and Cloud-Friendly Applications

Make sure the quality assurance team understands its responsibilities. Mobile applications often have network components and server-side functionality. Make sure thorough server and service testing is part of the overall test plan—not just the client portion of the overall solution that is implemented on the device. This might require the development of desktop or web applications to exercise network portions of the overall solution.



Face Book Twitter Google Plus Instagram Youtube Linkedin Myspace Pinterest Soundcloud Wikipedia

All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd DMCA.com Protection Status

Android Topics