To develop software, there are many methodologies such as Prince2, Extreme Programming, or the Microsoft Solutions Framework.
Most of these methodologies are suitable to be applied to Microsoft Dynamics NAV but they should be used properly. Because of the flexibility of the product, it is easy to leave out steps in the process that should be there.
In Microsoft Dynamics NAV, it is easy to quickly create and modify business software. This is by far the strongest selling point for the solution, but also the biggest pitfall.
When an end user requests a change to the application, it is tempting for most experienced developers to go into the application and create it, preferably in the production database without documentation. This is not the desired way of doing software development.
However, Microsoft Dynamics NAV is a very suitable design environment for prototyping and Rapid Application Design. All the example applications in this book are first built with prototyping and later finalized using testing.
If we design a suitable development methodology for Microsoft Dynamics NAV, we can see that the application life cycle perfectly fits our methodology.
When implementing Microsoft Dynamics NAV, it is very important to involve the end users in each step of the development process.
At the fit/gap phase, usually a quick specification is enough to describe what the user would like the system to do and a possible solution is generated in the application. This document should not count more than two or three pages. During the prototyping phase, it is very normal to come across advanced understanding. It would be a waste of valuable time to find this during the initial analysis with the risk of not finding them anyway.
With the Quick Spec, a developer creates the solution as a draft without going into too much detail. This should be enough to show the end user what the solution will look like when it is finished. Very often, this will lead to new questions and ideas that should be carefully considered and put into the full specification, or a new prototype should be built first.
Depending on the amount of changes after the prototype, development can often start with the work done already. At this stage, all the details should be worked out and tested.
There is no complete checklist for developers to use when developing in Microsoft Dynamics NAV, but let's try to create one with the following fields:
- Captions/Translations: Make sure all objects have the required captions and translations populated.
- Table Relations: Make sure all Table Relations are in place, and check the Ledger Entry and Line tables as well since they are frequently forgotten.
- Modify And Delete Triggers: What happens if a user modifies or deletes the record. Make sure that everything is nicely handled in the
OnModifyand On Delete C/AL triggers.OnRenameshould be automatically handled by C/Side. Renaming a table with many table relations may cause severe locking in the database. If users should not rename a record, this can be blocked by placing anERRORcommand in theOnRenametrigger. - LookupPageID and DrillDownPageID: Even when running the Windows client, it is important to assign a Lookup and Drilldown page ID. Lookup pages are used for table relations and Drilldown pages are used when drilling down from a SUM flow field.
- CardPageID: The Windows client always starts a list page when a user selects a menu item or a cue. Double-clicking a row will open the associated card page. This is controlled by the CardPageID property on a list page.
- Field Groups: To show records from a table relation when entering values, the Windows client does not directly use LookupPageID but first shows a DropDown list. The fields in this list are defined in the associated tables Field Groups. Each table can only have one Field Group called DropDown, as shown in the following screenshot:
- Actions: Actions should make sense to end users. Make sure you use logical names and avoid creating menu buttons and actions that are solely for super users and just confuse end users. Actions should be placed in the correct container. Only promote actions that will be frequently used by all end users.
- Shortcuts: Always assign ampersand (&) shortcuts and avoid double shortcuts. When using function keys such as F3 and F9, follow the Microsoft standard conventions.
- Compression and Posting: If your solution will generate a potentially large amount of data, be sure to provide compression, posting, or cleaning up routines so end users can periodically maintain the data.
- Permissions: Does your solution require additional permissions to be set up in the system? Make sure to document this when delivering the solution.
- Unused Variables: Make sure you don't leave unused variables in the C/AL objects. Although they won't break the functionality, it will make future maintenance of the software more complex.
- FIND Commands and Locking: Double check the usage of the correct find commands before you ship the software. Using the wrong commands and leaving locking to the database engine may cause extra performance overhead.
More detailed information about these features is explained in the book Programming Microsoft Dynamics NAV 2013, David A. Studebaker, Christopher D. Studebaker, Packt Publishing.
Testing is probably one of the most important but undervalued tasks of application design.
Testing involves the following three conditions:
- Does the software meet the original requirements? If this is not the case, it does not make sense to continue testing.
- Does it work as expected? This includes trying to deliberately break the solution. If the software is not monkey proof, things will certainly go wrong when using it. Here Murphy's Law is applicable, "What can go wrong, will go wrong."
- Does it fit the rest of the application? Is the software usable and intuitive? A solution that is bug free but difficult to use will be expensive to maintain.
Testing should be automated using the Testability Framework. This allows developers to rerun complete application tests each time they make a change.
Note
The blog at http://blogs.msdn.com/b/nav/archive/2012/11/07/application-test-toolset-for-microsoft-dynamics-nav-2013.aspx explains how to install and use the Testability Framework for Microsoft Dynamics NAV 2013.
The testing should be also done manually, performed by someone who likes doing it and has the available time. If someone is asked to test the software who is buried in normal work, the chance of bugs slipping in is quite high.
The cost of fixing a bug increases as the software evolves. The sooner a bug is fixed, the better.
When the changes are developed and tested, the documentation should be finalized. This can be either a manual for end users or a technical reference for future developers and support engineers.
After the software is implemented and users are trained, the solution goes into the maintenance and support stage. During this stage, the application manager needs to take care of the data generated by the solution, analyze it, and clean up the data periodically.
If the end users request a change on the solution, the cycle starts again.