Match the prototyping step with the appropriate process:

Algorithm engineering is a term coined for applied algorithm design. It refers to the process of transforming a pencil-and-paper algorithm into a robust, well-tested, and easy-to-use implementation. Implementing an algorithm to provide desired functionality in a prototype can be the most challenging part of the whole product development life cycle, but it also has the potential to be the most rewarding. By applying real-world I/O, you can see the functionality of your algorithm come to life before your eyes. 

Implementing algorithms in a functional prototype can be difficult for a variety of reasons:

Programming limitations—Often control systems or processors that are chosen for their I/O capabilities, such as FPGAs, involve programming limitations for a developer. Programming for different platforms usually requires programming knowledge that few system-level designers have.

Basic algorithm implementation—Implementing low-level algorithms for basic functionality takes time. Speed is paramount in prototyping, and designers often cannot afford to get bogged down in implementing a well-known algorithm from scratch due to the lack of existing code.

Reworking algorithms for multiple platforms—As the functional prototype evolves, algorithms often have to be revisited to port them to a different type of system. Code is rarely functional between different run-time environments, and that makes scaling an application from prototyping to deployment difficult.

Test and verification—You usually don’t know for sure whether a system can meet functional requirements until late in the game, and starting over costs too much. For example, the processor may not be able to perform the required number of parallel tasks fast enough. It may not be able to achieve an adequate cycle time. It also may not be able to handle the processor-intensive analysis in real time.

LabVIEW graphical system design addresses and mitigates many of the potential pitfalls involved in engineering algorithms for a functional prototype. Graphical system design is an approach to solving design challenges that blends intuitive graphical programming and flexible commercial off-the-shelf (COTS) hardware. With this approach, you can use a single environment across all stages of design. Now take a more in-depth look at how this approach specifically addresses the challenges raised above.

Multiple Models of Computation

One of the virtues of graphical system design is that it gives programmers the ability to create their algorithms regardless of the model of computation (MoC) they are implemented with. As code complexity for algorithms continues to grow, programmers have to use different MoCs to expand their coding capabilities. The following are just a few MoCs you can use with graphical system design:

Data flow—Data flow is the MoC most often associated with LabVIEW software. With data flow, operations require the developer to insert data in all the inputs before it executes. Data flow is an intuitive coding structure that makes implementing applications such as parallel processes easy.

Textual math—Textual math is another tool for creating complex functions easily. Text-based math is a human-readable implementation of often complex algorithms that are easier to write in a script description form. Examples of textual math are the formula node and LabVIEW MathScript RT Module. With LabVIEW MathScript, you can choose the most effective syntax for algorithm development, whether you are developing algorithms, exploring signal processing concepts, or analyzing results.

Figure 8. Reusing Text-Based Code With the LabVIEW MathScript RT Module

C code—Sometimes the algorithm you use was originally created in C or C++. In this case, you no longer have to discard the previous work. You can instead use the Inline C Node or the Call Library Function Node to directly call your previous code within LabVIEW. Use the Inline C Node for preexisting C code or implementing a small numeric or array algorithms and use the Call Library Function Node to access C code in DLLs or shared libraries.

Open Software Architecture

Over the years, the LabVIEW platform has seen wide-scale adoption in numerous design disciplines, which has led to a need to incorporate data with different design and simulation tools. LabVIEW accomplishes this intercompatibility with numerous integration tools, libraries, and file formats. LabVIEW also offers standard integration with a large array of other software tools and measurement resources including the following:

• DLLs, shared libraries
• ActiveX, COM, .NET (Microsoft)
• DDE, TCP/IP, UDP, Ethernet, Bluetooth
• CAN, DeviceNet, Modbus, OPC
• USB, IEEE 1394, RS232/485, GPIB
• Databases (ADO, SQL, and so on)

Using these tools, integration with data from almost every kind of measurement and control device is possible. By combining LabVIEW with general-purpose standards for hardware communication, developers can ensure compatibility and scalability for many years in the future.

The LabVIEW Approach

The hundreds of functions in LabVIEW that cover a wide variety of traditional algorithms in math, signal processing, probability, and control are essential building blocks for any custom algorithm. These functions alleviate the burden of writing low-level code and give engineers the time to focus on a solution instead of implementation.

Because using LabVIEW makes acquiring real-world data so easy, engineers find it valuable to test their algorithms with actual data as an iterative approach to tuning them. With this interactive test approach, you can experiment with different functions to see if they provide the required expected result. For example, when processing a signal with a filter, you can select from a wide variety of solutions, acquire the actual signal that you need, and look at the results in either a graph or file. If the results are not suitable for the application, then you can select another filter. Often it is easier to acquire the actual signal to apply to an algorithm and then take the time to simulate it on software.

Figure 9. NI ships LabVIEW with hundreds of built-in algorithms that you can use in your prototype.

Prototyping Model is a software development model in which prototype is built, tested, and reworked until an acceptable prototype is achieved. It also creates base to produce the final system or software. It works best in scenarios where the project’s requirements are not known in detail. It is an iterative, trial and error method which takes place between developer and client.

Prototyping Model Phases

Prototyping Model has following six SDLC phases as follow:

Step 1: Requirements gathering and analysis

A prototyping model starts with requirement analysis. In this phase, the requirements of the system are defined in detail. During the process, the users of the system are interviewed to know what is their expectation from the system.

Step 2: Quick design

The second phase is a preliminary design or a quick design. In this stage, a simple design of the system is created. However, it is not a complete design. It gives a brief idea of the system to the user. The quick design helps in developing the prototype.

Step 3: Build a Prototype

In this phase, an actual prototype is designed based on the information gathered from quick design. It is a small working model of the required system.

Step 4: Initial user evaluation

In this stage, the proposed system is presented to the client for an initial evaluation. It helps to find out the strength and weakness of the working model. Comment and suggestion are collected from the customer and provided to the developer.

Step 5: Refining prototype

If the user is not happy with the current prototype, you need to refine the prototype according to the user’s feedback and suggestions.

This phase will not over until all the requirements specified by the user are met. Once the user is satisfied with the developed prototype, a final system is developed based on the approved final prototype.

Step 6: Implement Product and Maintain

Once the final system is developed based on the final prototype, it is thoroughly tested and deployed to production. The system undergoes routine maintenance for minimizing downtime and prevent large-scale failures.

Types of Prototyping Models

Four types of Prototyping models are:

1. Rapid Throwaway prototypes
2. Evolutionary prototype
3. Incremental prototype
4. Extreme prototype

Rapid Throwaway Prototype

Rapid throwaway is based on the preliminary requirement. It is quickly developed to show how the requirement will look visually. The customer’s feedback helps drives changes to the requirement, and the prototype is again created until the requirement is baselined.

In this method, a developed prototype will be discarded and will not be a part of the ultimately accepted prototype. This technique is useful for exploring ideas and getting instant feedback for customer requirements.

Evolutionary Prototyping

Here, the prototype developed is incrementally refined based on customer’s feedback until it is finally accepted. It helps you to save time as well as effort. That’s because developing a prototype from scratch for every interaction of the process can sometimes be very frustrating.

This model is helpful for a project which uses a new technology that is not well understood. It is also used for a complex project where every functionality must be checked once. It is helpful when the requirement is not stable or not understood clearly at the initial stage.

Incremental Prototyping

In incremental Prototyping, the final product is decimated into different small prototypes and developed individually. Eventually, the different prototypes are merged into a single product. This method is helpful to reduce the feedback time between the user and the application development team.

Extreme Prototyping:

Extreme prototyping method is mostly used for web development. It is consists of three sequential phases.

1. Basic prototype with all the existing page is present in the HTML format.
2. You can simulate data process using a prototype services layer.
3. The services are implemented and integrated into the final prototype.

Best Practices of Prototyping

Here, are a few things which you should watch for during the prototyping process:

• You should use Prototyping when the requirements are unclear
• It is important to perform planned and controlled Prototyping.
• Regular meetings are vital to keep the project on time and avoid costly delays.
• The users and the designers should be aware of the prototyping issues and pitfalls.
• At a very early stage, you need to approve a prototype and only then allow the team to move to the next step.
• In software prototyping method, you should never be afraid to change earlier decisions if new ideas need to be deployed.
• You should select the appropriate step size for each version.
• Implement important features early on so that if you run out of the time, you still have a worthwhile system

Advantages of the Prototyping Model

Here, are important pros/benefits of using Prototyping models:

• Users are actively involved in development. Therefore, errors can be detected in the initial stage of the software development process.
• Missing functionality can be identified, which helps to reduce the risk of failure as Prototyping is also considered as a risk reduction activity.
• Helps team member to communicate effectively
• Customer satisfaction exists because the customer can feel the product at a very early stage.
• There will be hardly any chance of software rejection.
• Quicker user feedback helps you to achieve better software development solutions.
• Allows the client to compare if the software code matches the software specification.
• It helps you to find out the missing functionality in the system.
• It also identifies the complex or difficult functions.
• Encourages innovation and flexible designing.
• It is a straightforward model, so it is easy to understand.
• No need for specialized experts to build the model
• The prototype serves as a basis for deriving a system specification.
• The prototype helps to gain a better understanding of the customer’s needs.
• Prototypes can be changed and even discarded.
• A prototype also serves as the basis for operational specifications.
• Prototypes may offer early training for future users of the software system.

Disadvantages of the Prototyping Model

Here, are important cons/drawbacks of prototyping model:

• Prototyping is a slow and time taking process.
• The cost of developing a prototype is a total waste as the prototype is ultimately thrown away.
• Prototyping may encourage excessive change requests.
• Some times customers may not be willing to participate in the iteration cycle for the longer time duration.
• There may be far too many variations in software requirements when each time the prototype is evaluated by the customer.
• Poor documentation because the requirements of the customers are changing.
• It is very difficult for software developers to accommodate all the changes demanded by the clients.
• After seeing an early prototype model, the customers may think that the actual product will be delivered to him soon.
• The client may lose interest in the final product when he or she is not happy with the initial prototype.
• Developers who want to build prototypes quickly may end up building sub-standard development solutions.

Summary

• In Software Engineering, Prototype methodology is a software development model in which a prototype is built, test and then reworked when needed until an acceptable prototype is achieved.
• 1) Requirements gathering and analysis, 2) Quick design, 3) Build a Prototype, 4) Initial user evaluation, 5) Refining prototype, 6)Implement Product and Maintain; are 6 steps of the prototyping process
• Type of prototyping models are 1) Rapid Throwaway prototypes 2) Evolutionary prototype 3) Incremental prototype 4) Extreme prototype
• Regular meetings are essential to keep the project on time and avoid costly delays in prototyping approach.
• Missing functionality can be identified, which helps to reduce the risk of failure as Prototyping is also considered as a risk reduction activity in SDLC.
• Prototyping may encourage excessive change requests.