Development Process

The Velentium development process follows an iterative and incremental model. The overall process produces the same outputs as a traditional waterfall model, however in an effort to mitigate business risk the waterfall model is not strictly followed. Multiple incremental steps in the process may take place seemingly out of waterfall order, however this is to mitigate both business risk and potential hazards. This is achieved by the incremental approach being used to solicit clarity in user needs from the end customer or to aid in risk assessment of hazards resulting from the potential design. Overall the majority of outputs from the development process will track the waterfall model.

Initial Scope of Work

During this phase the problem statement and / or user needs are analyzed, and Velentium will listen to the stakeholders, perform some preliminary research, determine the scope of the project, forecast a preliminary schedule, and development high level milestones associated with contract payments. This is all considered parts of the sales process and is not under design controls.

Concept and Feasibility

The Concept and Feasibility phase starts after the transfer of a project from Sales to Operations. Operations will create a draft User Needs document that will draw from the contract and an interview with the Sales team. This document will be presented to the customer for review. Although there may be redundancy to what has been discussed with Sales or what is written in the proposal it is important that the development team be given the opportunity to write up the perceived needs and make sure all parties are in alignment and agreement on the objectives at a high level. This document will not contain too much technical content unless the problem statement or need is very specific. This document should be easily understood by any non-technical team member.

If any areas of concern, such as a perceived technical challenge, some effort may be spent during this phase to perform some additional research or experiments.

Project Planning and Management

Once the Concept and Feasibility phase has generated enough content that there is sufficient clarity in scope and objectives the Project Planning and Management process is initiated. During this phase a project schedule will be created and resources will be identified. The customer will be introduced to the development process and a regular line of communication will be establish between the customer and the internal project lead.

Risk Management & Human Factors

Upon completion of the User Needs document enough information is available to initiate the Risk Management & Human Factors process. The primary Risk Management process is to identify and reduce hazards to an acceptable level, but business risks are also considered at this point. An example of a business risk would be to identify that the team is reasonably certain that a particular sensor will be required and being aware of an extraordinarily long lead time decides to place the order prior to formal requirements completion or design review. This is not common, but is a decision that is sometimes made to mitigate the risk of an unacceptable delay in order fulfillment.

The most important element of the Risk Management process is the part that implements the identification of hazards. Hazards, potential sources for physical injury or damage, are considered early on in the development process and at multiple steps throughout the completion of the project. These hazards drive requirements that are not directly necessary to meet the User Needs, but necessary to mitigate a risk that the development team identifies will exist in the design if not addressed. Throughout the development process the risks, both business and hazard related, are assessed and addressed.

Human Factors are considered early on as they are not only relevant to a desirable outcome they are also directly related to Risk Management. Human Factors include things like ergonomics and intuitive interfaces.

Design Inputs – Requirements Capture

The Design Inputs phase is when the development team has sufficient information from the capture of the User Needs and the initial Risk Assessment to being capturing detailed system and software requirements. These requirements will drive all the development activities and are intended to ensure that the Design Outputs will solve the original problem statement / user needs and address any risks that have been identified. The requirements are carefully crafted to be clear and concise statements and ideally separate each requirement into individual inputs that are testable. Later in the process the requirements will be tested during the Verification phase, which will help to increase the likelihood that onsite installation and validation will go smooth.

Upon completion of the requirements a risk assessment will be conducted and may require updates to the requirements.

Design Outputs – System and Software Development

During this phase the development team will develop the design documentation first. Examples of this are drawings and 3D models, a bill of materials, software design and architecture, and other types of documentation that supports the development of software and fabrication of hardware.

Once the design documentation is completed a Design Review will take place. Upon agreement with all stakeholders, and after a risk assessment occurs, the actual procurement, hardware fabrication, and software development takes place.

Design Verification

The Design Verification phase is an internal Velentium effort to test and inspect the design to make sure that it fulfills each requirement. If the requirements were accurately documented and the verification demonstrates coverage of the requirements it is anticipated that the validation will show that the customer's expectations will be met. The verification process begins with the development of a verification protocol and may be written as soon as the requirements are completed.

Design Transfer

The Design Transfer phase is after verification of the design is complete. This is where the overall system comes together and final assembly takes place. From the Design Outputs phase all the documentation and instructions necessary to build and configure the system have been generated and from that the production process is put into place. For many systems Velentium develops, there is no replication required and the single system created during the Design Outputs phase and utilized for the Design Verification will be the only one produced. In these circumstances the Design Transfer phase will be more focused on the knowledge transfer to the end user to ensure the right information is shared for supporting the system.

Design Validation

Design Validation always occurs after final delivery and installation and involves the end user. This is "black-box" testing of the system to ensure that it meets the User Needs that were defined early on in the process. This process, like verification, starts with a protocol that captures the test cases and the expected outcomes. The protocol can be written as soon as the User Needs are captured, but will likely be updated as the design matures and additional requirements are clarified and risks mitigated.

Sustaining and Maintenance

The entire life cycle of product development goes well beyond verification and validation. Velentium frequently puts contracts in place on an as needed basis to assist with incorporating new features, performing updates, and assisting with overall maintenance as needed. For defects or change requests from the field Velentium has a change management system capable of capturing those items effectively.