Top Menu

  • ATCS

    Visualization

    Enabling clients to experience application concepts prior to investment in a fully developed solution

Proof of Concepts are more than just demos, they are used as “proof” that an idea or solution can be successful in accomplishing it’s goal.

Software visualization, also known as Proof of Concept (PoC) development, allows our partners to test concepts ATCS has proposed during the design concept phase of development.

Phase 1 – Concept Design

During the design concept phase, ATCS will conduct joint workshops with key users and business consultants to understand the need, problem or goal, and establish Key Performance Indicators (KPI) that drive or impact results most.  KPI accompany most development solutions. ATCS is a firm believer that everything must be measured in order to make more intelligent data driven decisions.  After conducting workshops ATCS takes the knowledge gained and creates designs of the concept instead of the traditional time consuming and often misunderstood requirements documentation.  ATCS will then present the design concept to the client for approval.

Phase 2 – Proof of Concept Development

After client acceptance of the proposed concept design, ATCS begins programming development of what is often referred to as software visualization.  Traditionally, development solutions require significant investment of time from both the client and ATCS consultants to document the many facets and processes required in a product.  Today’s visualization techniques that ATCS has built as common frameworks, enable clients to bypass most of that cost and time and move directly towards a working prototype tailored to the specific client project.  Feedback occurs in real-time, with client users requesting changes and developers implementing them in a matter of weeks not months.  Real sample data relevant to the project is incorporated, offering users a real life test drive in their world.

The Proof of Concept appears to users as a real application with limited data and function, but as a prototype it has limited production ready code.  This draws much excitement for users and project managers, but must be managed to meet the expectations as a visual requirements document.   A PoC will mitigate vagueness, answer unforeseeable questions, minimize risk.  Without a PoC phase, clients risk misunderstood requirements text, missed milestones, repeated change orders, increased project costs and a list of critical enhancements that must be purchased before the product can be fully implemented. This phase essentially replaces a typical requirements document stack and provides a much more clear understanding of the UI/UX, functions, and processes.

ATCS clients can now make a more educated and confident decision when progressing to Phase 3 – Development.