There are five channels are as follows:.
- Documentation
- Interviews
- Observation
- Questionnaires
- Measuring
I would also like to add to this with "System Audits". I will explain more in a moment.
Documentation
It has been said that this channel provides the least value. Ten years ago I would say that this is true, and it may still hold true for a number of organizations today. However our customer management database and work order system have become invaluable tools in keeping documentation up to date and current. So many people rely on it, it has become self updating as work is planned and completed.
The drug company that I used to be a consultant at now has a wonderful change control database and it is company policy that all systems documentation be kept current and the time to keep them current is built into the project. They have come a long ways from no or obsolete documents to very current and detailed documentation on all systems, the networks, severs, and mainframe systems.
The worlds biggest bank that a friend of mine works at carries it to level even more detailed. For example that have a specialist group for each phase of a project. Let's say you are the HR department and you need a new server. There is one groups that does the specs, one group that does the order from the vendor, one group that does the hardware build, testing and certification, one group that loads the baseline OS, one group that does all the updates and certifies the OS. The server is handed off to the group that handles the third party enterprise applications on the server. It is then hand to the security group and certified. Then the installation team does the install, testing for the customer/department. The server is then handed off the final group that does the support. This group is handed all the documentation for every phase and has detailed instructions on how to do each step and includes the log files and certification from the different groups. This is the most extreme documentation on a system that I have known. From the time of request for a server to the time of deliver is five to six months for a single server.
Interviews
These are very important. Spending a few minutes with a key player can yield huge insights that could save you from chasing a rabbit down a dead end hole and save you time and resources during your research.
Observation
Working with people is a must. Setting back and watch them drive the application can be an interesting experience. Each user has developed their own personal method of interacting with the system based upon their knowledge level, skills and usage of the system. As a developer it is very important to watch a user. They will have a different interpretation of the system and interface. The amazing part is they will do things that you would never have conceived possible, or why they are doing a task a certain way. Then you modified the system to trap for their issues or make it better for them. What is really incredible is the ways users will adapt the system to track or do something that it was never indented by the developer to do.
Questionnaires
These are great, but getting people to fill them out is like pulling teeth. You have to have it mandated, corner them or do it during an interview.
Measuring
This is important to size up the scale of the project, the scale for the database need, the number of users, the number of database transactions, etc. all aid in better understanding the systems.
System Audits
This is not part of the lecture or the reading material. This comes from my experience. In the old days most all system audits had to be done manually. Where is the system physically located? How is it connected? What is it used for? What is it's configuration? What are it's specs? What is it's current software update level. This is for all components involved, hardware, software, OS's, databases, network connectivity, etc.
With software interconnected components it has become too time consuming and too overwhelming complex with too many parts. In recent years there are new software tools that can do the job for you. There are network scanning and management tools. There are database reverse engineering and documentation tools. There are project development code management tools. There are tools for just about all aspects for creating data flow diagrams and flow charts automatically. All these tools can create the documentation that you need for your research.
White Papers
White Papers really help as case studies, lessons learned, a detail insight and the gotchas of a certain system. If there are white papers available for your project or a part of your project I encourage you to take a little time and review them. They can shape your ideas and opinions. The really nice thing is you can learn from other peoples pain and mistakes and avoid those in your project.
A Vendor created White Paper about their product DNS:
http://support.microsoft.com/default.aspx?scid=kb;en-us;810733
A Third Party White Paper about the Vendors DNS:
http://itresearch.forbes.com/data/detail?id=1094838407_866&type=RES&src=TRM_TOPN
What is a White Paper:
http://www.whitepapercompany.com/pages/387998/index.htm
Why White Papers:
http://www.whitepapercompany.com/pages/387343/index.htm
Here are IT White Paper Sources. The UoP Library contains some too.
http://itpapers.com/index.aspx
http://www.bitpipe.com/
Example of how you used one on a development project.
I recently did a security audit for a 15 user network with two servers for the purpose of checking overall security of their system, so they could allow a customer to connect and gain access to their network and database systems from a remote office. The auditing tool I used took about 20 minutes to complete the entire network and yielded 183 pages of quality current documentation. A manual audit would have taken me several days, and I still would not have the level of detail. Now do an audit on a very large system and you will have a new problem. That is information overload. The next thing is to learn what information is important and relative to the project.
All these are part of the documentation process and aid in your research and analysis.
No comments:
Post a Comment