SOFTWARE PRODUCT DEVELOPMENT & QUALITY TESTING

Get pricing, more information, or talk to one of our data visualization experts:

Entrance’s software development services team utilizes a tailored version of the Microsoft Solution Framework (MSF) Agile methodology to manage and deliver projects. The Agile process enables Entrance to focus on delivering working software that provides the highest business value at all times. Customer engagement and collaboration is key and, employing Agile allows our Clients to see and touch the software at the end of each iteration, typically 2-3 weeks long, which allows us to be highly responsive to our client’s changing needs.

To ensure the solution delivered meets our high standards, all solutions are delivered with our quality testing services.

The Team

We have team members solely focused on the following areas to delivery better software for our customers:

Project Governance

Mainly involved with management of resources, quality, and communication between the client and the team.

Development

Develops the line of business solution based on the design and Entrance custom software development best practices.

User Experience/User Interface

Focused on user interface and usability.

Architecture and Design

Responsible for the design of the overall solution and ensuring that design optimally satisfies all requirements at scale.

Quality Assurance in Software testing

Performs independent testing, ensures quality and smooth deployment.

Product Development Phases

This model defines five distinct phases for a project. These phases overlap, define what needs to be accomplished and define a goal for quality. When used in combination with Entrance’s Agile methodology, these stages are small in scope and performed quickly.

Envision

Plan

Build

Stabilize

Deploy

Envision

Plan

Build

Stabilize

Deploy

Agile Software Development Methodology

The Agile process works well when not all requirements are known at the onset of the project, and there is a need to be flexible to accommodate changes in requirements as the Client learns more about what they need or want in a technology solution. This process allows for changes to requirements to be made throughout the lifecycle of development. Changes are then incorporated at the beginning of each sprint where there is a deliberate and purposeful discussion about the relevant and most current requirements; as long as the Client is willing to make trade-offs regarding priority and scope of requirements, this change process will easily accommodate a need to iteratively develop a working technology solution in a phased approach, continually focusing on the highest priority features.

MANAGING THE WORK

Agile processes, by definition, employ short, time-boxed iterations called Sprints to define the scope of work that will be completed, and to then complete that work. Each Sprint is 2-3 weeks long and starts with a Spring Planning meeting and ends with a Demonstration of working software, the “Shippable Increment.”

PRODUCT PLANNING

The Product Planning process is a pre-cursor to any development activity. Depending on the scope of the problem and solution this process can take from one to five days of effort. This typically involves all of the members of the team, but can be limited to the Product Owner, Scrum Master, and Team Members who specialize in Business Analysis and Architecture.

The Product Planning process is a pre-cursor to any development and produces the following outcomes and artifacts:

Understanding and documenting the business problem and processes
- Problems/limitations of the current solution or process
- A vision for the end state
Developing an initial Product Backlog consisting of User Stories that detail the functionality required by each type of user based on role
- If possible each User Story should be assigned a Business Value to help determine the priority for the follow-on Sprint Planning
- Each user story should have clear acceptance criteria that will drive both developer testing and our software testing service

SPRINT PLANNING

The Sprint Planning process allows Entrance and our Client to work together to prioritize and schedule User Stories in the Product Backlog for development. This is accomplished at the beginning of each Sprint by pulling items from the Product Backlog into the Sprint Backlog. As the User Stories are placed into the Sprint Backlog, Acceptance Criteria are written against the User Story to ensure that developers, testers, and users have a shared understanding of the definition of “Done” for a given User Story. The end result of Sprint Planning is a Sprint Backlog that contains User Stories and Bugs the team will work on until the end of the Sprint.

SPRINT

Throughout the Sprint the Team is continuously updating the User Stories in the Sprint Backlog with effort expended and remaining effort. This provides the information needed for reporting on Sprint progress and the metrics Entrance uses to manage its projects. At the end of the Sprint, a Demo is conducted to show the Client the capability that was built and to get feedback on the implementation. This provides the Client the opportunity to see and touch the solution.

SPRINT RETROSPECTIVE

The team will continuously be looking for improvement opportunities, and will set aside a period at the end of each sprint to reflect on lessons learned. This period is called the Sprint Retrospective. Entrance approaches this meeting after the demo as a start-stop-continue meeting. Each team member is asked to identify specific things that the team should start doing, stop doing, continue doing With specific items identified the team will decide which items to focus on during the next sprint.

DEVELOPING SOLUTION

This process involves using tools and Agile development practices to turn the User Stories into functional software. This is driven by the order and priority of the User Stories contained in the Sprint Backlog. Throughout the Sprint, as the User Stories are turned into functional software, the software is tested and evaluated by our developers, Quality Assurance (QA) team, and the Client against the Acceptance Criteria in the User Stories to ensure we are building the right solution. The Team will meet at the Daily Stand-up to discuss yesterday’s accomplishments, today’s planned work and any impediments to getting the work done.

To increase quality and productivity, the Entrance team leverages market-leading tools and Agile practices:

Static code analysis tools

Unit testing

Automated UI Testing

Deployment packages

Continuous Integration

Pair-programming

Kanban boards for Work Item Management

Source Code Management via TFS

Database Source Code Management via Redgate

Quality Assurance Services

Entrance incorporates quality into all aspects of project delivery tailored to the type of software product development we are engaged in delivering. Document-based deliverables go through internal review for content accuracy, style, and voice. Additionally, Entrance incorporates input from Client via draft reviews throughout the delivery cycle.

Software based deliverables are put through a rigorous independent software testing and quality assurance testing process that involves the following steps when appropriate:

Definition of Acceptance Criteria for software based functionality
Unit testing done at the developer level
Functional testing done by Quality Assurance resources
Automated regression testing intended to streamline the development and deployment process as software based solutions evolve
Software Code Reviews when appropriate

User Acceptance Testing Eliminating all defects from non-trivial software can be cost prohibitive, therefore, Entrance monitors the costs and effort associated with resolving defects to keep those costs within acceptable tolerances and Entrance company standards.