· 过时或不准确
· 过于冗长
· 未经解释的缩略语或专用术语
· 查找信息困难
存在这些问题的主要原因是软件文档常常被退居次位。工程预算迫使我们优先考虑开发过程中的主要活动，也就是那些可以看得到利润的地方。编写文档需要成本，因而它常常成为一项主观上的活动，而且通常被认为没有重要作用，应该尽量避免。许多项目经理认为客户不需要文档，它只是用来装点门面的。 软件文档质量差的另外一个原因在于文档撰写者。许多应用程序开发经理认为软件文档的编写是软件开发过程的一个标准组成部分，因此要求开发人员在编码的过程中产出文档。
尽管这种做法在理论上行得通，但它没有考虑开发人员编写文档的能力。简单来说，技术人员是用来开发软件而不是编写文档的。为了解决这个问题，许多应用程序开发经理雇佣专业技术文档编写者或业务分析师，以期改进软件文档的质量。但这又遇到了另一个难题：专业编写者及业务分析师的技术水平有限。
解决这个问题要考虑需要编写的文档以及文档的预期读者。一般的规则是，写文档需要团队协作，这样就允许开发人员和文档编写者利用彼此的长处，取长补短。例如，如果预期读者是系统设计师，开发人员需要提供技术细节，然后文档编写者按照正确语法组织和编辑内容。不考虑预期读者或专门编写者，软件文档的质量取决于其可用性，可从以下6个方面去评价其可用性：
· 应用性：文档是否提供相关信息？
· 及时性：信息是否及时？
· 准确性：信息是否正确？
· 完整性：文档是否足够详细而又不会太过拘泥细节？
· 可得性：文档是否随时可得？
· 可用性：你能否很快凭直觉就找到所需信息？
软件文档的最主要目标是传达一个系统的技术要素和使用方法。第二个目标是提供软件开发过程中的需求，决策，行为，角色和责任的书面记录。只有实现了这两个目标，软件文档才真正提供了有意义的信息。
针对被开除人员的应急计划
在职员离开企业时限制风险的出现是你的责任。在职员因不和睦而离职时这个责任就更加紧迫。找出和分析你的组织由于前任职员不满而面临的风险，是你的系统每天所面对的整体风险的一个延伸。不幸的是，对于很多组织来说，全面的风险和漏洞分析通常会超出预算限制。然而，还是有一些常用的措施可以使用的。
首先要在全面地审计信息系统资产的基础上确定风险暴露和漏洞。然后，基于信息系统安全性的三个主要组成部分来分析这些资产弱点。信息系统安全性的三个主要组成部分是：
· 机密性：保证组织的信息资产不会被不恰当地泄露。
· 完整性：保证信息系统资产的准确性和可靠性。
· 可用性：保证信息系统资产以一种及时、可靠和可预测的方式可用。
接着，考虑每个部分在出现裂口的成本和影响，以确定你的风险优先级。在确定风险优先级时，请向你自己提出以下问题：
· 资产的价值是什么？
· 危及资产价值的安全有多复杂？
· 威胁发生的概率是多少？
· 如果资产被危及安全，其成本是多少？
· 恢复资产的难度有多大？
最后，采取以下步骤减轻这些风险。这些步骤涉及的范围很广，从锁定应用程序安全到删除对系统资产的物理访问都有。
保护组织不受被开除职员不适当动作的危害之关键是速度和准备。人员位置通常不允许你有很多时间去准备；因此，这就是你的计划的用武之地。例如，你应该在一个职员被开除的前几个钟头内采取以下动作：
· 删除对 IT 资产的物理访问。
· 删除网络、Web 和应用程序授权/身份验证。
· 隔离系统。（这可能包括删除 VPN、调制解调器或其它接入。）
· 要求归还所有公司资产。
· 与该职员的主管和同事进行针对该职员的风险评估。
· 实现一个离职访谈，期间你还可以评估风险。
· 保证这个职员尽快地离开其工作岗位。
· 将一个责任资源分配给一直与这个职员一起工作的人。
· 审计该职员的工作站和工作区域以确定风险等级。
· 通知他的所有同事该职员已经离职。
· 保持适当警惕地完成一个保险评估，以保证你的同事是安全的。
· 再次查看事件响应计划，并将它们都准备就绪。
虽然很多步骤看上去可能很无情，但不适当的动作造成的影响也很无情。做好准备就可以以不变应万变。