How to Make an App | 8 Phases for Enterprise Mobile App Development

Everyone wants to know how to make an app. The meteoric rise of the app market is certainly astounding; according to Flurry Analytics, approximately eight apps are launched daily for iOS and Android devices.  As of June 2014, there were 1.2 million mobile apps in Apple’s App Store alone.
Because it’s so important to get it right the first time, there must be a careful ramp-up to building an app, especially at the enterprise level.  The approach we take with mobile app projects at AIM Consulting is to build a mobile app in phases, each with multiple steps.

PHASE 1: PRE-PLANNING FOR HOW TO BUILD AN APP

The first phase of any project is often the most important.  When building a mobile app, it’s critical to take the time to go through the necessary planning steps.

Step 1: Define the project and create use cases.  Create a written definition of your app idea that clearly spells out what it will do, who the users are and why they will care about it. Make sure you can answer the question “why does this app need to exist?” What unique problem does it solve? Will the app simplify payment transactions for customers? Will it increase productivity for field agents? What is the business case? Use this information to create use cases to guide the project.

Step 2: Do your research.  Is there already an app on the market similar to the one you are thinking to build?  If so, how can you do it better?

PHASE 2: MENTAL PROTOTYPING / DISCOVERY

A mental prototype is a brainstorm to help define a concept in visual terms.  It’s the first opportunity to start to see how the app might evolve…and to get a reality check.

Step 3: Involve the development team or technical architect.  Ideally, the development team is involved at the beginning of the project, but if the technical people who are actually going to build your mobile app aren’t already on board, now’s the time to bring them in. This is when you can determine if your idea is feasible, can be successful and what expectations you should have for time and budget.

Step 4: Storyboard.  With the use cases you created in Phase 1, create rough sketches of the idea on a sketchpad, whiteboard, or template tiles. This is the first visual representation of all the screens and will help uncover usability issues.

PHASE 3: TECHNICAL FEASIBILITY ASSESSMENT

It’s not enough to have cool interactions and an understanding of the visuals. You need to consider whether the back-end systems will actually support the app’s functionality. For basic assessment of technical feasibility, you must do the following:

Step 5: Get access to the data. Your mobile app needs to access usable data. Figuring this out could be as simple as sourcing a Public APIs or as complicated as building your own abstraction layer.

Step 6: Determine what devices you are building your app for. An app will have different requirements depending on its platform (iOS, Android, etc.) as well as the format (smartphone, tablet, wearables, etc.). At AIM Consulting, we recommend Native development for an optimal user experience tailored to a specific platform.

Step 7: Refine project definition and establish go-to-market strategy. By the end of this phase, the team may have new ideas for the app or have determined that some of the initial functionality isn’t feasible.  At this point, take some time to brainstorm, ask questions and review the status.

PHASE 4: TACTILE REFINEMENT OF USE CASES

It’s very difficult to define the touch experience without being able to touch the app and experience how it works and flows.  Phase 4 is about just that.

Step 8: Build a rapid prototype.  “Rapid” is the operative word – build a prototype that gets the app concept into a user’s hands as quickly as possible so you can see how it works for the most common use case.  Use rough, not exhaustive, wireframes.
Bring your stakeholders in to touch the prototype to garner feedback as early as possible.

PHASE 5: DESIGN YOUR APP AND PREPARE FOR DEVELOPMENT

Now is when the real work begins:

Step 9: Design for the user experience. Before you dive into code, you must design.  A User Experience (UX) Designer can create the interaction architecture of the design elements.  A User Interface (UI) Designer for mobile solutions can create the look and feel of your app. This is a multistep process with its own review stages. The end result is visual direction and blueprints that inform your engineers of the envisioned final product and how interaction should feel, move and flow.

PHASE 6: BUILD YOUR MOBILE APP WITH AGILE PRACTICES

The strategy is complete, the stage is set, and you have your design.  It is now time to build an app!

Step 10: Agile Development. Agile is the preferred approach for mobile development due the importance of collaboration, transparency, and rapid iteration to adapt to change.  These practices of adapting to change are critical to finding success in the ever-evolving mobile channel.

PHASE 7: TEST YOUR MOBILE APP

Congratulations! You have built an app. Now it’s time to get some of your target users to help you test it.

Step 11: UAT testing.  User acceptance testing is a process to discover whether your mobile app works for users. In other words, put your app in the hands of a few people in your target audience. Once your app has passed the UAT test, you know that the solution “works”.

Step 12: BETA testing.  Make your app available for a beta trial, either through an open solicitation for participants or the enrolment of previously identified groups. Feedback from beta users will help you determine whether or not the app’s functions are operating well in a real-world environment.

PHASE 8: LAUNCH – YOU BUILT AN APP!

Your app is complete and ready to submit. Pick a day and key up a formal launch. Congratulations! You have learned how to build an app!
Keep in mind, this is not the end. Every app requires updates and new features during the mobile application development lifecycle. Typically, the development cycle begins anew as soon as the first version of the app is released. Ensure you have the resources to maintain your product.  If you are working with an outside vendor to build your app, as we at AIM Consulting do for our clients, make sure that you will have continued access to the mobile development team through a managed services agreement or similar partnership after the app is launched. A mobile app is not a “set it and forget it” type of project. Like any other technology, it will require skilled people to continually build new enhancements, fix problems, and ultimately ensure its success to your business.

Read more...

10 Things to Plan for When Developing a Mobile App

Many companies have mobile apps at the top of their to-do lists, but while churning out a quick app is fairly straightforward, developing a strategic application or digital “solution” is considerably more complex. Smart planning is essential.
Here are 10 things to consider before developing your app.

1. Agree on goals for the program.

When developing a digital solution strategy, first examine your organization’s goals for the program. Are you looking to be seen as innovator, or fend off competition by showing progress in the space? Simply showing initial momentum and previewing the future roadmap can often place you ahead of the competition. Should your digital solutions help build customer loyalty and enable greater customer self-service, or is your highest priority to create new revenue streams? Once you’ve agreed on the goals, prioritize them so you’ll know where to start.

2. Understand your target users.

The next step is to understand who your target users are, their goals and requirements, and the technologies they use. This process includes researching the platforms your users are most likely utilizing, then gaining an understanding of each user experience. Every device is different, and every user has multiple needs. For example, a person might typically use an online banking application to pay a bill, but he might use the bank’s mobile application to find the closest ATM.

3. Build a user testing focus group.

Spending time with your target users is the only way to ensure you really understand what they are looking for in a mobile application. As you move through the process of discovery, you can discuss ideas with this group on a daily basis. Focus groups can provide value from the far beyond the initial discovery phase.

4. Identify a minimally viable solution set.

Don't try to tackle the whole problem at once. Instead, companies should identify a minimally viable solution and start there. In other words, release a basic but functional app as a foundation, then take advantage of the efficient upgrade paths most devices offer to provide regular updates. This enables you to enter the market more quickly and refine as needed. Plus, periodically giving your users access to new developments ensures your organization stays top-of-mind.

5. Plan for multiple releases.

With mobile applications, releasing the initial version is only the beginning. Statistics show that many users will re-engage with your application when new features are added. Spread key functionality across the first handful of releases to keep your users engaged. Be careful not to release too often, lest users feel bombarded. In many cases, a 2-3 month window between major releases will keep your users engaged over a longer period of time.

6. Balance your users and your business.

Balancing business drivers with real user needs can be difficult. In many cases, the two are at odds with one another. Therefore, arm yourself with the right information to make smart trade-offs. Collect research such as user studies, expert opinions, and business viability and technical feasibility studies. This body of data can then be weighed to achieve the best balance between user-centric solutions and business-value gains.

7. Know what is out there.

Spend time exploring apps in each of the platforms you plan to support. Each platform offers different interface paradigms and a different collection of applications. Experimenting with the most popular applications will help you understand not only what is possible on the platform, but also the user's expectations. If possible, use a different mobile platform device during the exploration process.

8. Bring your IT team into the discussions early.

The far greater technical challenge is tying your backend business processes to a digital solution that encompasses smartphones and kiosks, for example. The technology infrastructure for a multichannel solution goes well beyond the platform you choose for front-end development. In order to be successful, companies must consider how to architect data delivery and API management as well as security, scalability, content aggregation, device optimization, API translation, etc. Bring your IT team into the discussion before you get too far down the planning path.

9. Decide on a technology you can live (and grow) with.

As the mobile space matures, there will be many more application develop choices. In many cases, your goals will help determine what you choose here. For example, if your goal is to reach as many users as possible across all platforms, you may choose an HTML framework with little hardware integration. If your goal is to provide deep hardware integration for augmented reality technology, then you'll probably develop a native application. Decisions around technology can directly affect your app's functionality.

10. Plan to analyze.

The final step in the process is determining how to measure success. With a morass of potential features, devices, platforms and technologies, success can be challenging to define, but it will affect your ultimate strategy. Consider the following questions.

• Will this increase our transaction volume and, therefore, revenue?
• Will this increase customer adoption and retention?
• Will this increase our brand recognition and loyalty?
• Will this decrease our costs?
• How many people do we want using our app?
• How do we want to integrate the solution with our social media program?
• How will we integrate with our existing analytics tools?

Read more...

How can I decrease the size of Ratingbar?

There are two ways you can do this.

You have to style the RatingBar with either ratingBarStyleSmall or a custom style inheriting from Widget.Material.RatingBar.Small (assuming you're using Material Design in your app).

Option 1:

<RatingBar android:id="@+id/ratingBar" style="?android:attr/ratingBarStyleSmall" ... />

Option 2:

// styles.xml<style name="customRatingBar" parent parent="android:style/Widget.Material.RatingBar.Small"> ... // Additional customizations</style> // layout.xml<RatingBar android:id="@+id/ratingBar" style="@style/customRatingBar" ... />

Read more...

Android Material Rating Bar - Rating Bar example in Material Design

Rating Bar

How to add?

I. In your build.gradle add latest appcompat library.

dependencies { compile
compile 'com.android.support:appcompat-v7:X.X.X' // where X.X.X version}

II. Make your activity extend android.support.v7.app.AppCompatActivity.

public class MainActivity extends AppCompatActivity { ...}

III. Declare your RatingBar inside any layout.xml file.

<RatingBar android:rating="3.5" android:stepSize="0.5" android:numStars="5" android:layout_width="wrap_content" android:layout_height="wrap_content"/>

How to style?

I. Declare custom style in your styles.xml file.

<style name="RatingBar" parent="Theme.AppCompat"> <item name="colorControlNormal">@color/indigo</item> <item name="colorControlActivated">@color/pink</item></style>

II. Apply this style to your RatingBar via android:theme attribute.

<RatingBar android:theme="@style/RatingBar" android:rating="3" android:stepSize="0.5" android:numStars="5" android:layout_width="wrap_content" android:layout_height="wrap_content"/>

Read more...

Software Testing-Requirements Traceability Matrix

What is the need for Requirements Traceability Matrix in Software Testing?

Automation requirement in an organization initiates it to go for a custom built Software. The client who had ordered for the product specifies his requirements to the development Team and the process of Software Development gets started.

In addition to the requirements specified by the client, the development team may also propose various value added suggestions that could be added on to the software. But maintaining a track of all the requirements specified in the requirement document and checking whether all the requirements have been met by the end product is a cumbersome and a laborious process.

The remedy for this problem is the Requirements Traceability Matrix.

What is Requirements Traceability Matrix in Software Testing?
Requirements tracing is the process of documenting the links between the user requirements for the system you're building and the work products developed to implement and verify those requirements. These work products include Software requirements, design specifications, Software code, test plans and other artifacts of the systems development process. Requirements tracing helps the project team to understand which parts of the design and code implement the user's requirements, and which tests are necessary to verify that the user's requirements have been implemented correctly.

Requirements Traceability Matrix Document is the output of Requirements Management phase of SDLC.

The Requirements Traceability Matrix (RTM) captures the complete user and system requirements for the system, or a portion of the system. The RTM captures all requirements and their traceability in a single document, and is a mandatory deliverable at the conclusion of the lifecycle.

The RTM is used to record the relationship of the requirements to the design, development, testing and release of the software as the requirements are allocated to a specific release of the software. Changes to the requirements are also recorded and tracked in the RTM. The RTM is maintained throughout the lifecycle of the release, and is reviewed and baselined at the end of the release.
It is very useful document to track Time, Change Management and Risk Management in the Software Development.
Here I am providing the sample template of Requirement Traceability Matrix, which gives detailed idea of the importance of RTM in SDLC.

The RTM Template shows the Mapping between the actual Requirement and User Requirement/System Requirement.
Any changes that happens after the system has been built we can trace the impact of the change on the Application through RTM Matrix. This is also the mapping between actual Requirement and Design Specification. This helps us in tracing the changes that may happen with respect to the Design Document during the Development process of the application. Here we will give specific Document unique ID, which is associated with that particular requirement to easily trace that particular document.

In any case, if you want to change the Requirement in future then you can use the RTM to make the respective changes and you can easily judge how many associated test scripts will be changing.

Requirements Traceability Matrix Template Instructions:

Introduction:
This document presents the requirements traceability matrix (RTM) for the Project Name [workspace/workgroup] and provides traceability between the [workspace/workgroup] approved requirements, design specifications, and test scripts.
The table below displays the RTM for the requirements that were approved for inclusion in [Application Name/Version]. The following information is provided for each requirement:
1. Requirement ID
2. Risks
3. Requirement Type (User or System)
4. Requirement Description
5. Trace to User Requirement/Trace From System Requirement
6. Trace to Design Specification
7. UT * Unit Test Cases
8. IT * Integration Test Cases
9. ST * System Test Cases
10. UAT * User Acceptance Test Cases
11. Trace to Test Script

The following is the sample Template of Requirements Traceability Matrix.

Read more...

Requirements Traceability Matrix (RTM)

1. Requirements Traceability Matrix (RTM)

A document showing the relationship/mapping between Test Requirements and Test Cases.

Elements of RTM:

a. Requirements ID

b. Requirements Description

c. Test Case ID

d. Status [Open, Closed, Defer (Later), On hold]

2. Verification and Validation

Verification is the process confirming that something software meets its specification. Validation is the process confirming that it meets the user's requirements.

Difference between Verification and Validation:

Suppose, you are going to buy a pair of shoes having number 9 for you. You have chosen a pair and seen the tag with 9 written on it. This is verification, because your requirement was to buy a pair of shoes with 9 number.

But when you tried to wear it and found that shoe is not fitted into your feet. After inquery, you have found that company has tagged it 9 number by mistake. Actually it was 7 number shoe. This process is called Validation.

Example of Verification: Creating Traceability Matrix

Example of Validation: Executing Test Cases

3. Static and Dynamic Testing

Static black-box testing: Testing the specification is static black-box testing.

Two Types of Static black-box testing:

1. High-level review techniques

a. Research Existing Standards and Guidelines

b. Review and Test Similar Software

2. Low-level techniques

a. Specification Attributes Checklist (e.g. Spec must be complete, accurate, precise, consistent etc)

b. Specification Terminology Checklist (e.g. focus on the terms in Spec like "If…Then…(but missing Else)." or "Etc., And So Forth, And So On" etc)

Dynamic Black-Box Testing: Testing software without knowledge of code is dynamic black-box testing.

Static White-Box Testing: Static white-box testing is the process of carefully reviewing the software design, architecture, or code for bugs without executing it.

Three Types of Static White-Box Testing:

a. Peer Reviews: Peer Reviews are the least formal method. Peer reviews are often held with just the programmer who wrote the code and one or two other programmers or testers acting as reviewers.

b. Walkthroughs: In a Walkthrough, the programmer who wrote the code formally presents it to a small group of five or so other programmers and testers. The presenter reads through the code line by line, or function by function, explaining what the code does and why. The reviewers listen and question anything that looks suspicious.

c. Inspections: Inspections are the most formal type of reviews and more formalized than a 'walkthrough', typically with 3-8 people including a moderator, reader, and a recorder to take notes. The other participants are called inspectors.

Walkthrough:

1. It's a type of Semi Formal Review.

2. 2 to 7 People ate attaining it.

3. Author is Presenter.

4. Lead by Author only.

5. Reviewers are not aware of the subject/topic.

Inspection:

1. It's totally a Formal Review.

2. 2 to 10 or more People attaining it.

3. Author is not presenter. Some one else is giving presentation.

4. Lead by Moderator.

5. Reviewers are aware & well prepared for the subject/topic.

6. Recorder is noting down everything. Like defects, changes, improvements etc.

Dynamic White-Box Testing: is a method of testing software that tests internal structures or workings of an application.

Difference between Dynamic White-Box Testing and Debugging:

The goal of dynamic white-box testing is to find bugs. The goal of debugging is to fix them.

Read more...

How to write software Testing Weekly Status Report

How to write software Testing Weekly Status Report

Writing effective status report is as important as the actual work you did! How to write a effective status report of your weekly work at the end of each week?

Here I am going to give some tips. Weekly report is important to track the important project issues, accomplishments of the projects, pending work and milestone analysis. Even using these reports you can track the team performance to some extent. From this report prepare future actionables items according to the priorities and make the list of next weeks actionable.

So how to write weekly status report?

Follow the below template:
Prepared By:
Project:
Date of preparation:
Status:

A) Issues:
Issues holding the QA team from delivering on schedule:
Project:
Issue description:
Possible solution:
Issue resolution date:

You can mark these issues in red colour. These are the issues that requires managements help in resolving them.

Issues that management should be aware:

These are the issues that not hold the QA team from delivering on time but management should be aware of them. Mark these issues in Yellow colour. You can use above same template to report them.

Project accomplishments:
Mark them in Green colour. Use below template.
Project:
Accomplishment:
Accomplishment date:

B) Next week Priorities:
Actionable items next week list them in two categories:

1) Pending deliverables: Mark them in blue colour: These are previous weeks deliverables which should get released as soon as possible in this week.
Project:
Work update:
Scheduled date:
Reason for extending:

2) New tasks:
List all next weeks new task here. You can use black colour for this.
Project:
Scheduled Task:
Date of release:

C) Defect status:

Active defects:
List all active defects here with Reporter, Module, Severity, priority, assigned to.

Closed Defects:
List all closed defects with Reporter, Module, Severity, priority, assigned to.

Test cases:
List total number of test cases wrote, test cases passed, test cases failed, test cases to be executed.

Read more...