Process makes perfect

Conducting a preliminary study

The Getting started section of the User Experience driven development guide provides an outline of the business, technology, and audience factors, which should be considered when starting a project. This section also examines the fine balance between meeting business, technology and user constraints. The Design research section goes on to explain how preliminary research can assist in the development of a product idea that will address true user needs, rather than simply responding to a perceived gap in the market.

Defining development costs and business logic
Throughout these stages it is important to begin assessing potential project costs, from conceptual design through to launch, maintenance, customer support, and marketing. It is also vital to determine how these costs relate to the revenue that can be generated by the final product.

Here are some aspects to consider:

Marketing

• How much are users willing to pay for the application or spend on other costs, such as data transfer?
• What is the point of sale? How do users find and purchase the application and will there be additional costs to increase discoverability?
• How are users billed? What additional transaction fees can be expected?
• Will free trials or demos be offered?

Development

• Is there a proper level of technical competence in-house?

Quality assurance

• Will the application go through a common testing and certification programme, such as Symbian Signed or Java Verified™ Program? What is the associated cost?
• Do you need to obtain the Certificate ID that is mandatory in Symbian Signed? Obtaining a certificate can take some time, so if you plan to have your application signed you should request it in advance.

Maintenance and support

• How often do you anticipate updating the application? When, why, and for what benefit?
• What possibilities are there to promote or market the updates?
• Will the application require the development of a companion support website? Will this require additional costs for web development, hosting, or copywriting?

Conceptual design

How do ideas gathered during the research stages actually turn into a product? The conceptual design stage is where everything starts to come together. The goal of this stage is to synthesise the insights and information gathered throughout the course of your research and begin to mould them into a product your users will love. The Conceptual design section outlines the steps required to develop and refine an idea into a solid concept that your stakeholders will be comfortable proceeding with.

Creating the initial requirements document

With an initial concept in place, you can begin to outline the product requirements. A high-quality requirements document ensures the competitiveness of the application by guaranteeing that the key features respond to actual market demand and user needs.

Requirements vs. specifications
There is a clear distinction between a requirement and a specification. A requirement aims at identifying specific characteristics, qualities, or capabilities that represent a need in the market, and answers the following questions:

• What does the application do?
• What qualities does the application possess?
• What are the known application dependencies?

A requirement also provides guidance for all subsequent project phases, including marketing.
A good requirement accomplishes the following:

• Describes a capability that responds to a problem;
• Is clear and concise;
• States what the product should be able to do;
• Does not restrict UI design or technical implementation.

By comparison, a specification is a document that provides a complete description of the functionality or technical solution. The development of a firm specification will typically occur gradually, as the concept is further elaborated and prototyped.

The product manager (or someone in an equivalent role) usually has the primary responsibility for defining requirements. Other key stakeholders—for example, UI designers and implementation personnel—should be included in the review of this document so that potential design and implementation constraints are identified early on.

Security

When developing mobile products, it is important to pay particular attention to the following security and platform considerations:

Security threats as requirements. Defining good application security requirements may be difficult. Security requirements may be more straightforward to express by describing the threats the application is likely to encounter. The relevant threats can be considered as negative use cases that should be avoided. These can describe different scenarios and interactions that must be prevented in the application design.

Platform security requirements. Platform Security for Symbian OS includes such features as data caging and capabilities, which should be considered early in the design of the application architecture. Flash Lite from Adobe applications must also respect a security model, which varies depending on the version of Flash. It is essential to account for these security models early in the design and define how security will be built into the application.

Platform requirements. To reduce problems at the testing phase, consider the requirements of different security implementations, Symbian Signed, or Java Verified testing criteria early on. Test criteria for Symbian Signed and Java Verified are available at www.symbiansigned.com and www.javaverified.com.

To learn more about what to consider in order to write better or more secure code familiarize yourself with the materials offered by SAFECode (The Software Assurance Forum for Excellence in Code), of which Nokia is a member.

SAFECode has published a series of white papers on software supply chain integrity and on software integrity controls that aim to help others understand and minimize the risk of vulnerabilities being inserted into a software product during its sourcing, development and distribution.

SAFECode has also published a second edition of Fundamental Practices for Secure Software Development: A Guide to the Most Effective Secure Development Practices in Use Today which intends to help others in the industry initiate or improve their own software security programs and encourage the industry-wide adoption of fundamental secure development methods.

Please refer to the following publications for more information:

Fundamental Practices for Secure Software Development
Overview of Software Integrity Controls
Framework for Software Supply Chain Integrity
Refer to www.safecode.org/publications.php for other SAFECode publications.

Interaction design and prototyping

With your initial specifications, concepts, and scenarios in place, you can begin to further iterate your product’s overall user experience and interaction design. Design iteration ideally should be combined with prototyping, which will enable you to validate and test the design. Your test results will in turn help you determine which of the product’s features, interactions, or elements require further exploration.

Prototypes created using tools such as Flowella are ideal to illustrate the application flow and interaction design. The prototypes do not have to offer all the functionality of the final application. A general idea of the concept ‘in action’ on a device is often enough to validate or challenge ideas, evoke comments, and spot flaws in the design or proposed functionality.

Creating the UI specification
As discussed earlier, the specification document combines the application requirements, design decisions, and insights gained through prototyping into a detailed specification. The UI specification should contain all the details that will be needed when the coding starts, including application logic, layout, navigation, and user interaction, as well as exception cases, errors, and notifications.

Reminder: When using an iterative process to design, prototype, test, evaluate, and revise, it is likely that the specification document will not be accurate or complete the first time. The specification also does not have to be simply a document. You may want to include other types of artifacts, including prototypes, sketches, and short videos to illustrate concepts that cannot be accurately outlined using text. See Interaction design and prototyping for more ways to prototype and document project specifications.

Related resources:
Nokia provides a selection of downloadable stencils for use during the design stages of your project. Design and paper prototyping templates are ideal for early brainstorming, paper prototyping, and conceptual design. The full-colour Concepting stencils can be used to create quick mock-ups or more-refined concepts for presentations to stakeholders.  Wireframing stencils are ideal for creating technical sketches or documenting application flows and structure.

Visual and information design

Visual design takes place at many stages of product development. Early on, you may use sketches and renderings for inspiration and to capture the essence of what the product could be. At other stages, you may use presentation sketches to clarify progress to stakeholders such as investors or the marketing team.
Eventually, however, you will have to determine the final design — and the visual styling is only part of the task. Other aspects include:

• Screen layout and information design;
• Copywriting (for example, icon text labels, navigation menus, and error and action dialogues);
• Colour scheme and, where possible, choice of fonts;
• Creation of UI graphics and icons;
• Design of audio, animations, and transitions.

By considering these design aspects carefully, you can provide your product with key advantages, as described in the Visual and information design section.

 Implementation

All projects will require implementation; however, the stage at which this occurs may vary depending on your internal process and chosen software development methodology. Implementation may once have been a specific project stage, however developers are increasingly exploring processes such as Agile, which (similarly to many design processes) depends on iteration rather than strict sequential stages. In Agile development, ‘requirements and solutions evolve through collaboration between self-organising cross-functional teams’, and may therefore coexist with conceptual, interaction design, and prototyping stages.

Regardless of the methodology, here are a few things to keep in mind:

• When problems arise, discuss them with the appropriate stakeholder immediately. Together with the design team, come up with an acceptable alternative solution that does not conflict with the rest of the application design—or the product’s business goals.
• To enable proper change management, keep a change log that describes the problem, the solution, and the impact on the application design and functionality.
• Make sure you write clear, well-commented code—someone else may try to continue your work at some point!

Module testing
Module testing (also known as unit testing) is a standard part of application development, and the basic level of code verification. In module testing, the development engineer constantly checks the application under development, making sure that each ‘unit’ of code is valid and functional, and that the components work together with the rest of the system.

Module testing can be done in the application development environment. Several development environments feature special Software Development Kits (SDKs) that include simulator functionality for testing the application. If possible, also test the application in an actual target device during the implementation phase, because on-device testing may reveal problems related to performance that cannot be accurately assessed in a simulator.

With proper module testing, the most obvious errors and bugs will be detected at an early stage. This allows enough time to correct and optimise the code accordingly, and even to make larger changes to the application architecture, if necessary.

Power management
Power management is a key element in creating a high-quality mobile application. A mobile device OS is often configured to consume a miniscule amount of power, especially when in the idle state. In this regard, a single application can have a tremendous effect on the overall battery life if the application is not careful how and when energy is drawn.

Poor power management has a direct impact on the overall user experience. For example, if the device battery is drained after a short session of listening to music, the user will be frustrated and will no longer be able to use the application—or the device.

• Use the implementation phase to estimate, verify, and optimise the power consumption of the application.
• Do not concentrate on sudden peaks in power consumption, but on average battery use.
• Optimise the use of network resources, since fast data connections demand a lot from the device battery.

The requirement for efficient power management is especially valid for always-on applications that constantly poll the network or run in the background in the device.

Tip: Nokia Energy Profiler is a stand-alone test and measurement application for S60 devices from Nokia. Use the tool for testing and monitoring an application's power usage in real time on the target device. See the Quick Start guide for more details.

Reminder: Some applications may require user documentation, such as online help or user guides. Documentation is usually produced in the implementation phase and integrated as part of the whole application product before testing.

System testing

With the implementation of the application's functionality, the application is ready for system testing. In system testing, the application is tested on the target device, with the aim of evaluating the application’s compliance with its specified requirements.

The actual testing process will depend on the project and the application. For some applications, a light testing round is more than enough. Complex enterprise applications may, however, require extensive testing.

The results of the testing should be documented in a separate test report. If the project schedule is tight, you can categorise the findings on the basis of their severity and assign the highest priority to problems that are the most critical.

Designing test cases
Before you start testing, define a set of test cases. A test case provides a condition that the tester checks to ensure that the application satisfies a certain requirement set for the application. Use the requirement specification and use cases as the input source for the test cases.

Other applications with the same concept may have encountered specific problems in the past. Testing these commonly known problems is also important. Equally important are security issues. If the application has functionality such as access control, the test cases must verify that the prevention mechanism actually works.

Test cases can contain lots of information, however at the very least, each test case should have:

• A title;
• A description or testing instructions;
• A statement describing the expected results.

Tip: If these are relevant to your project, consider Symbian Signed and Java Verified Program requirements when you design test cases. Including the test criteria in your own testing ensures that the application will pass the testing round done in the programmes.

Testing on target devices
When an application is mature enough, it can be tested on the actual target device (or devices). Install the application and run the defined test cases. Nokia provides the Remote Device Access services which allow you to test your applications remotely over the internet on various Nokia devices.

Note that if you aim to test or implement Symbian OS applications that use capabilities which the user cannot grant to the application at the installation time, you must first apply for a Symbian Developer Certificate to test the application on a target device. Additional information is available at www.symbiansigned.com.

Dealing with test findings
Report errors identified in the testing by describing each error and including sufficient information—for example, how and when the error appeared and the error message, if there was one. Include the version number of the software build, if applicable.

When findings from the first testing round are available, the implementation team should make any necessary corrections to the application. Depending on the severity of the errors and the extent of the corrections required, it may be necessary to undergo another round of testing.

For more information, see the following related documents:

• Nokia Test Criteria for Symbian C++ Applications
• Nokia Test Criteria for Java™ ME Applications
• Testing and signing section of the S60 5th Edition C++ Developer's Library

Acceptance testing and Signing

NOTE! Nokia signing Symbian and Java apps for free

Assuring that the application meets the specification
Various application delivery channels require that applications be tested and signed through either Java Verified or Symbian Signed. These industry-wide application testing and signing programmes guarantee the integrity of mobile applications. In addition, the programmes test the application against commonly accepted test criteria and add security by verifying the source of the application.

Platform security
Symbian OS platform security was introduced in S60 3rd Edition with the implementation of Symbian OS v9 as the S60 platform's underlying operating system. Platform security enhances the existing security features of Symbian OS by delivering a more secure platform for mobile devices. The secure platform offers users increased assurance concerning device security and personal data.

Java Verified Program
Java Verified is an industry-wide programme for testing and signing Java™ Platform, Micro Edition (Java™ ME) applications.

Security model for the Java™ ME
In MIDP 2.0, there is a specific security model that defines four application domains. The way a certain protected feature can be used by the application user depends on the domain the application resides in. Applications are signed by a certificate that has been defined to a certain domain in the device. Therefore, if the certificate has been defined to domain A, all the applications signed with that certificate will get the benefits of domain A.

For more information on the security model for Java ME applications, see Testing and signing section of the S60 5th Edition C++ Developer's Library and MIDP 2.0: Signed MIDlet Developer's Guide.

Note: For more details regarding Ovi Store’s application testing, signing, and packaging requirements, please visit the Packaging and Signing pages.

For more information, see these related documents:

• MIDP 2.0: Signed MIDlet Developer's Guide
• Testing and signing section of the S60 5th Edition C++ Developer's Library

Maintenance and postproduction

Once the implementation and testing are complete and the application is ready for delivery or certification testing, the application enters the maintenance phase. The maintenance phase includes the following:

• Bug fixes and correction patches after the initial delivery;
• Software updates;
• Minor version updates with added functionality.

Postproduction of application variants
With the growing variety of target mobile terminals, there is an ever-increasing need for new application variants for new devices and for porting applications to existing secondary devices. In addition to accommodating new target devices with different technical capabilities and restrictions, it may also be necessary to produce variants for new language locales and operator-specific devices.
There are no industry-standard tools and techniques for variant management, so try to develop best practices of your own, documenting them properly to ensure that subsequent projects benefit from the good solutions and avoid the bad ones.

Important: Make sure that customers cannot download nonworking versions or variants of your application. If they do, it is even more critical to ensure that users are not charged for such downloads.

Reminder: If you make changes to the application in the maintenance phase, remember to take the application through the quality assurance process again.

Quality control and reviews

It is important to define tools that can be used to control the quality of the application during development. Quality control is a continuous process that extends throughout the development process, and it should be possible to backtrack later to identify the origin of mistakes that might have been made during the project.
Quality control tools include, for example, technical reviews and review minutes, checklists, expert evaluations, and user feedback. The tools should be linked to specific phases and outputs of the development process.
To evaluate quality, define specific and exact requirements for your application that can be used as quality metrics. The metrics can require the following:

• Reduction in the number and severity of errors, and improvements in the findings of reviews and testing;
• Improving the rate of success at meeting project deadlines and milestones;
• Conforming to the requirement specification;
• Responsiveness to feedback from external experts, including the evaluations of usability experts.

In addition to testing and evaluating the product that is under development, you must regularly evaluate the application development process itself. Audit the existing process and gather feedback from the development team to determine whether there is any need for change.

Marketing the application

A well-planned and implemented application based on thorough and extensive market and user analyses is not enough to guarantee commercial success. You need sound marketing to promote your application to potential customers. For a successful application, begin the marketing phase as soon as possible. Consider the following questions:

• What are the possible marketing and sales channels?
• Is it possible to cooperate with other parties, such as mobile operators, in marketing the application?
• How and when can the conceptual, design, and prototyping work completed throughout the project benefit the marketing of the product?
• In terms of branding, what is the story behind the application? What is the marketing message? What makes this application special?

As soon as possible, you should identify and choose likely parties with whom to cooperate and the appropriate sales channels. The key point is to start negotiations early, verifying any requirements and contractual issues that potential business partners may impose.

Creating the marketing message
To be successful, an application should stand out from the competition. Define a marketing message that convinces potential buyers and partners that the application is special and worthwhile.

• Use information and research that resulted from the preliminary research and conceptual design phases.
• Identify the key selling points that distinguish the product from the competition and emphasise those distinctions.
• Study the target users and make sure that the promotional language you use is appropriate and friendly. Do not, for example, emphasise technical brilliance or use technical jargon for a nontechnical audience.

Always remember that you must deliver what your marketing messages promise.

Support from application development to marketing
The results of several phases of the application development project can support the marketing project. These include the following:

• Schedules and timelines for application availability.
• Requirements and specifications that provide information about application features.
• Demos, prototypes, and simulations that deliver a strong, concrete message to your audience.

Use this information and deliverables from the development team to hone your marketing message. Deliver the right information at the right time.

Communication is a two-way street. Marketing may also become a source of input to the development team, providing updated target-user information that can be turned into new product requirements and considered during subsequent design processes.