App Development process

1. Design Sprint Outputs

• Day 1: Problem Selection
• Day 2: Solution Sketching
• Day 3: Solution Story-boarding
• Day 4: Solution Prototyping
• Day 5: Solution User Validation

Goals

• To have a singular focus for 5 days
• To gain confidence we’re headed in the right direction and/or need to pivot/adjust the product
• To rally internal stakeholders around a solution or feature set by making them a part of the process

2. User Experience Design& User Testing Using the insights from the Design Sprint, your UX designer will flesh out the user stories, journeys, and states to create a clear, seamless and delightful experience. And most importantly iterative User Testing.

Outputs

• Competitive analysis
• User personas
• Documentation of user tasks
• Outline of User Stories
• Clickable wireframe prototype of the core flow
• Competitive analysis
• Qualitative feedback (i.e., interviews)
• Quantitative user feedback (i.e., surveys)

Goals

• To iterate on the concept and design before spending any time coding/in-development
• To gather feedback for correct prioritization of features prior to coding/development
• To have a clickable wireframe prototype ready for user testing

3. Visual Design Simplicity is the ultimate sophistication. Work with our visual design team to create an elegant design that incorporates the latest trends and capabilities.

Outputs

• Visual brand identity/user interface (UI) design for the majority of screens
• Full-fidelity, clickable prototype

Goals

• To create the polished brand that users today demand
• To have a full-fidelity clickable prototype ready for user testing

4. Develop & Test Agility is the name of the game. Our scrum-based Agile development methodology ensures frequent builds and gives you plenty of time to test and adjust. While our experienced Quality Assurance (QA) team will identify and manage testing.

Outputs

Fully tested and QA’d front-end and back-end code that matches agreed-upon specifications

Goals

• To ensure a product is as bug free as possible at launch
• To ensure the product works as expected

5. Marketing & PR Launch No app launch plan is complete without the proper marketing, PR and engagement tools to help it get discovered and retain users.

Outputs

Introductions to the right marketing partner(s) with the skillset and testing strategy needed for the product

Goals

To ensure a test driven marketing strategy allowing for quick learning and and efficient use of capital To help prioritize new feature development based on marketing learnings

6. Product Launch Getting an app live on the web or submitting an app to the App Store can be a tricky process, but we will help you along the way to get your app published, so you can start monetizing.

Outputs

• A first version/beta version/MVP live and in-market
• A prioritized backlog of future features based on user feedback

Goals

To launch at the right time based on market timing and growth/adoption strategy

7. Track & Learn Updates are essential to an app’s success. Using both quantitative and qualitative tracking tools, we will help you identify opportunities to improve and update your app based on user data and feedback.

Outputs

• On-going support and management of the post-launch product
• Quantitative user feedback (i.e., surveys)
• Design and development of new features based on marketing data, analytics data and ongoing user testing
• Qualitative feedback (i.e., interviews and reviews)

Goals

• To ensure we have the data to determine which features & functionality to build next and/or change to fit the needs of (new) customers

Software architecture patterns

• Software Architecture patterns

1. Layered (N-tier) architecture The layered architecture pattern, also known as the N-tier architecture pattern, is the standard architecture used for most Java Enterprise applications. A layered architecture style divides components (or applications) into horizontal, logical layers. Each layer has a distinct role within the system. Components of a layer will only deal with logic within that layer. Difficult to scale up. Most layered architectures will consist of four closed layers: Presentation, Business, Persistence, Database

2. Client-server architecture In a client-server architecture, there are multiple nodes or clients connected over a network or internet connection who communicate with a central server. There are two main types of components:

• Service requesters (aka clients) that send requests
• Service providers that respond to requests In this architecture, the server hosts, manages and delivers most of the resources and services a client requests. This is also known as a request-response messaging pattern.

3. Event-driven architecture Event-driven architecture patterns are distributed asynchronous architecture patterns that are highly adaptable. This pattern is best suited for small to large applications with high scalability. Since event-processor components are isolated from each other in this pattern, changes to components can be made without impacting the performance of other components.

• There are two main topologies to this pattern: the mediator and the broker topologies. Mediator topologies have four main types of components: Event queues, Event mediators, Event channels, Event processors Mediator topologies are used when an event has multiple steps that require some level of coordination through a central mediator to be processed.

When a user sends the initial event to an event queue, the initial event is then directed to the event mediator.

Receiving the initial event prompts the event mediator to publish and send processing events to event channels, telling them to start executing each process step. The event processors receiving the processing events from the event channels contain business logic components that execute all of the steps required to process the initial event.

Event-processor components should only perform a single business task without relying on other event processors.

• Broker topologies are used for process flows where an event does not need a central mediator to distribute or coordinate events.

Broker topologies have two main types of components:

Brokers Event processors The broker component contains all of the event channels for this event flow. These event channels can be message queues, message topics, or a combination of both.

In the broker topology, event-processor components receive events directly and are responsible for processing and publishing new events to indicate that an event has been processed.

Events continuously flow through a chain of processor components until no more events are being published for the initial event.

4. Microkernel architecture Microkernel architectures (also known as plug-in architectures) are typically used to implement applications that can be downloaded as a third-party product. This architecture is also commonly found in internal business applications.

• There are two types of architectural components in your typical microkernel architecture: a core system and plug-in modules. The core system contains the minimum business logic needed to make the software system operational. You can extend the software system’s functionality by connecting plug-in components to add more features. Plug-in components can be connected using an open service gateway initiative (OSGi), messaging, web services, or object instantiation. Note: Plug-in components are independent components meant to extend or enhance the core system’s functionality and should not form dependencies with other components.

5. Microservices architecture Microservices architectures are one of the most popular software trends at the moment, and one reason for this can be attributed to the easy scalability of development. When microservices can no longer be maintained, they can be rewritten or replaced.

Microservice -an independently deployable module

A microservices architecture consists of groups of small, independent, self-contained services with small code bases. Unlike with a monolithic application using a layered architecture pattern, keeping small, separate code bases can minimize the number of dependencies.

Each component of a microservices architecture is deployed as a separate unit. Separately deploying units streamlines the delivery pipeline and makes deployment much faster. Development teams can easily build up continuous delivery pipelines with smaller units. Testing also becomes easier because you only need to test the features of an individual microservice.

Microservices architectures are only effective when deployment is automated because microservices significantly increase the number of deployable units.

Another key concept of the microservices architecture is the service component. Service components can range in complexity from single modules to large portions of an application. Microservices architectures are considered a distributed pattern because their service components are fully decoupled from one another.

Microservices also facilitate continuous delivery, which helps make software development more flexible.

Major companies like Amazon, Netflix, and Spotify can be found implementing this architecture.

6. Cloud-native architecture When the data flow deals with a high volume of concurrently running requests, you typically end up with bottleneck issues. This is where cloud-native architecture patterns come in. Cloud-native patterns are designed to minimize scalability- and concurrency-related issues by removing the central database and using replicated, in-memory data grids instead.

The cloud-native architecture is primarily used for distributed computing systems where the interactions between components are mediated through one or more shared spaces.

In this shared space, the components exchange tuples and entries. This brings us to the concept of tuple spaces, or the idea of distributed shared memory.

Tuple spaces provide a repository of tuples that can be accessed concurrently. Application data is kept in memory and replicated across active processing units.

The two main types of components within this architecture pattern are:

• Processing units
• Virtual middleware Processing units will typically contain:
• Application modules
• An in-memory data grid
• Optional asynchronous persistence store for failover
• A data replication engine: what the virtual middleware uses to replicate data changes made in one processing unit across all other active processing units. This type of software architecture is best for social networking sites or any system that needs to handle massive spikes in traffic.