|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
IIB Integration Design Document Example/Template/Sample |
« View previous topic :: View next topic » |
Author |
Message
|
smdavies99 |
Posted: Fri Sep 09, 2016 12:19 am Post subject: |
|
|
 Jedi Council
Joined: 10 Feb 2003 Posts: 6076 Location: Somewhere over the Rainbow this side of Never-never land.
|
zhaider wrote: |
So, is there any template guys? |
In my experience, every company will have their own specification template document. Some are better than others but you have to use them (again, in my experience).
some are better than others. some are so bad (in terms of imposed limitations of MS word) that they are a PITA to use espeically where you have to use the same format of doc internally as you do for external docs. One I encountered forbade the use of chapter and section numbering even on highly technical docs.
If you did, documentation control would not assign you a document number. Without that number... no reviewer would even look at it. _________________ WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
Back to top |
|
 |
ruimadaleno |
Posted: Fri Sep 09, 2016 3:35 pm Post subject: |
|
|
Master
Joined: 08 May 2014 Posts: 274
|
zhaider wrote: |
smdavies99 wrote: |
Quote: |
Yeah kind of like the guide lines but not for all projects. I'll tailor it to my specific needs and fit in my solution for that particular project and then share it with my client for etc.
|
Why not for all projects?
Many of us who comment here work within the constraints laid down in our organisations for very good reason.
For example, Logging and exception handling are very often implemented identically on all projects.
Having a common logging and exception handig framework saves endless re-inventing of the wheel by each and every developer.
One of the questions I ask of any potential employer is about this sort of framework.[1]
Sometimes it does not exist so I get to implement it for them. If it exists then great. Then I know they are serious about the use of thie product.
Having a well used set of tools like this in your back pocket is also a good way to make yourself well thought of in a new assignment.
[1] I won't be doing that any longer because as of the end of the month, I'm retiring. |
Yeah, I get what you are saying with rest to all projects like the exception handling and logging framework. What I mean that I'll tailor it to my specific project is I'll also be including the service interfaces and models that I'm specifically building for this particular project.
So, is there any template guys? |
Like others have said, there is no "template" nor "generic document" nor "one size fits all" we can only give you some guidelines...
Have you draw any document/template ? can you show it to us so we can point you some directions (beware of the copyrights) ?
In your post you have a set of questions:
- Workspace Organisation
- Like how do you usually manage models, formats, subflows and main flows in projects and applications
- Exception Handling
- Coding Convention
- Notification Framework
- Store and Forward (SNF) framework
Are there any more questions to answer ? compile, agregate and rethink about it ... this is your document/template macro structure. As soon as you finish the "macro structure" you can get into more detail (diagrams, screenshots from tooklit) etc _________________ Best regards
Rui Madaleno |
|
Back to top |
|
 |
smdavies99 |
Posted: Fri Sep 09, 2016 9:43 pm Post subject: |
|
|
 Jedi Council
Joined: 10 Feb 2003 Posts: 6076 Location: Somewhere over the Rainbow this side of Never-never land.
|
ruimadaleno wrote: |
In your post you have a set of questions:
- Workspace Organisation
- Like how do you usually manage models, formats, subflows and main flows in projects and applications
- Exception Handling
- Coding Convention
- Notification Framework
- Store and Forward (SNF) framework
Are there any more questions to answer ? compile, agregate and rethink about it ... this is your document/template macro structure. As soon as you finish the "macro structure" you can get into more detail (diagrams, screenshots from tooklit) etc |
This level of documentation would only be of interest to other IIB devs.
IMHO they would just be noise to any Business Analyist. They are interested in only what happens at the edges (inputs, outputs and stuff like DB IN and OUT).
This is why I said before that functional specs should be as product agnostic as possible.
As for workspace layout... everyone has a different way they interact with the TK (and pretty well every IDE out there) so please don't try to restrict the way a dev works with their tools. Measure them by the quality and pace of the things they produce.
The above list is perfect for things like support docs. I have to point out that producting them takes a lot of time and effort and in an Agile/RAD environment, you may not get time to even start doing this.
I'm producing such a doc at the moment. For a system of around 20 interfaces (one or more flows), the support doc is already 150+ pages and I'm nowhere near done.
Don't try to re-invent the wheel. Start small and do what is achievable within the resource and time constraints available. Evolution is better than revolution. _________________ WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
Back to top |
|
 |
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|
|
|