我即将编写一些项目经理,开发人员和业务分析师将使用的标准/指南和模板.目标是更好地理解已经或正在开发的解决方案.
其中一部分是提供记录解决方案的标准/指南.例如,记录解决/满足业务案例/用户要求的软件.
现在,作为一名程序员,我可以看到,不可能指示并说"每个解决方案必须使用Y来定义X并根据Z来呈现它",因为XYZ并不总是适用于等等.
但是,我知道即使对于我的爱好项目,我总是最终以某种方式描述我的解决方案,模块/组件,源代码注释,API,数据库模型,使用的一些分类,日志日志,xml格式等.
因此,为了继续我的工作,如果您能够分享您的文档以描述您的解决方案(最好也是如何以及为什么),我将非常感激 - 我知道它会因很多事情而有很大差异,但任何一般或具体的回答很有意思.谢谢.
更新 目前尚不清楚,但我没有提到XY Z的用户需求.我指的是系统可能具有的所有可能类型的文档.因此,请将其理解为"无法说明每个解决方案必须具备:所需框架列表;服务器软件操作手册;所需主数据;用户需求与测试的矩阵;用户界面规范.虽然有必要生成这样的限制一套要求,很难清晰和准确,因为不同项目之间最重要/最相关的是什么.
此外,我不久前问了这个问题,从未接受过答案,对不起.或许,既然这是一个悬而未决的问题,那么它作为一个社区维基会更好吗？
如果您的这个项目将享受任何类型的长寿,您可能想要开始考虑使用一些行业一致的方法.最后,您可能会花费更多时间,最终可能会得到相同的最终结果.
它还取决于您所讨论的文档级别:对于基于应用程序的体系结构指导,请查看Microsoft Application Architecture Guide 2.0(最近发布).
如果它低于那个级别,那么从像SandCastle这样的东西开始,只是逻辑地扩展它产生的东西.
就个人而言,我喜欢从交互图开始,只是简单地展示系统的所有组件如何相互作用,然后将每个组件分解为类.将类分解为序列图,并继续运行,直到达到方法级别的状态图表,或者对于您的项目而言低.
如果它是您需要的更高级别,请查看我之前的帖子:企业,系统和应用程序架构(最佳实践)
在一天结束时,只要它对阅读它的人来说具有逻辑意义,并且它是有用的(而不是你必须提供并且永远不会再使用的东西),你已经做得对.
更大的问题通常是使文档保持最新.这将很快带您进入流程和程序创建/改进任务.