Development documentation from NSC?!

Hi, We bought & implemented NF in Q4 2000. Since then we have compiled a list of suggested improvements and modifications to NF, which we now are about to order from our NSC. I would say it’s widely accepted that modifications to a standard product should be documented. I intend to myself keep a list of the functional adjustments we are making with a brief explanation of why/what was adjusted. I have also inquried from the NSC what kind of documentation they would normally make, which we can have, and any other suggestions they have. I have also asked about any recommendations that Navision makes regarding comments/documentations etc. I was most disappointed to hear, that what they can & will do is mark the codeunit/report/table etc with NSC name/developer. No other documentation. If I wanted more, I could buy the source code (!), I would say that’s exactly what I’m doing…?! My question(s): - Is this typical for any NSC? - What wold be a “normal” level of documentatio? - doesn’t Navision recommend any “best practice” to the NSC:s?

Hi Anders, That type of documentation do you think about? Toward end-users or other developers? I can’t really tell from your note. But no matter what, then I understand your frustation. At current (and as you can read about in another topic in this forum) there are not even standards regarding comments. But it’s not true that you can’t do more than mark the changes. The thing is that it doesn’t matter to create a standard for detailed comments if no one will use it. Better keep it simple. When you look at other documentation then it’s varies a lot from NSC to NSC and from project to project. I can only talk for us (BMI), but the normal thing to do is when we get a new project we analyse it and write up a detailed report. On this basis the modifications need are estimated. If the modifications are complex then a more detailed design goes along with the estimate. If the client accept the estimate then these descriptions goes as the documentation. Only with more complex modifications a real end-user documentation is created. But what we do instead is whenever a client needs to be upgraded to the next version, we have a compare tool that we can use to get a full documentation with all changes (before, after) in the code. With this and the written documentation we can useally manage to do a great job anyway. Are standards in this area need? I think so. I’m just not sure exactly what is needed. The only one who can really change this is YOU! If the customers/end-users does not require documentation, and will pay the NSC’s to do it, then this will never change. Best regards, Erik P. Ernst, webmaster Navision Online User Group

Documenting is topic of discussion for longer times already. But I think you should make a clear distiction between minor changes (no real impact on the programflow, but often only small (cosmetic) adaptions to the specific situation at a particular customer), and more extensive tailoring/developments. For the first kind of modifications, keeping a kind of log-book and commenting the code will do. For the second kind of developments, it is strongly advised to do it the proper way, which is: 1- a Diagnostic Study to get an inventory and roadmap of your workflow and procedures 2- a Functional Design study to “translate” the workflow and procedures into standard Navision routines, or to pinpoint what changes will be required 3- a Technical Design study which provides the specifications for the developers Together, these documents will give a clear view, now and in the future, what has been changed, why and how. Yes, this may seem to raise the costs for the project at first sight, but from experience I can tell it pays back by having a smooth implementation and much less changes afterwards. It also helps a great deal to get the system accepted by the workfloor - it’s recognized as being the result of their own input. John

Thanks for the replys. I was not considering end-user-dockuments. Rather, for example, I had expected the NSC to at least suggest something like: 1) A basic description of which codeunits/tables etc that were affected by the project. 2) A brief description of which standards that are being used. For example comments. To assist in future upgrade projects. I agree with John, above, and the simple cosmetic jobs we will do ourselves & log. The most frustrating part is the non understanding , non professional, attitude of the NSC. I’m gonna take care of the issue in this way: concerning the bigger issues concerning functional improvements I’m gonna have one more follow-up and suggest an approach in the way John suggested above. If that doesn’t improve the situation I’m gonna take the issue to the local Navision representation.