标签：这一 nts ack 说服力 工作 code color 自动 根据
在上一代程序设计中（即“过程化或程序化设计”），这个阶段称为“建立需求分析和系统规格”。当然， 那些操作今天已经不再需要了，或者至少改换了形式。大量令人头痛的文档资料已成为历史。但当时的初衷 是好的。需求分析的意思是“建立一系列规则，根据它判断任务什么时候完成，以及客户怎样才能满意”。 系统规格则表示“这里是一些具体的说明，让你知道程序需要做什么（而不是怎样做）才能满足要求”。需 求分析实际就是你和客户之间的一份合约（即使客户就在本公司内部工作，或者是其他对象及系统）。系统 规格是对所面临问题的最高级别的一种揭示，我们依据它判断任务是否完成，以及需要花多长的时间。由于 这些都需要取得参与者的一致同意，所以我建议尽可能地简化它们——最好采用列表和基本图表的形式—— 以节省时间。可能还会面临另一些限制，需要把它们扩充成为更大的文档。 我们特别要注意将重点放在这一阶段的核心问题上，不要纠缠于细枝末节。这个核心问题就是：决定采用什 么系统。对这个问题，最有价值的工具就是一个名为“使用条件”的集合。对那些采用“假如??，系统该 怎样做？”形式的问题，这便是最有说服力的回答。例如，“假如客户需要提取一张现金支票，但当时又没 有这么多的现金储备，那么自动取款机该怎样反应？”对这个问题，“使用条件”可以指示自动取款机在那 种“条件”下的正确操作。 应尽可能总结出自己系统的一套完整的“使用条件”或者“应用场合”。一旦完成这个工作，就相当于摸清 了想让系统完成的核心任务。由于将重点放在“使用条件”上，一个很好的效果就是它们总能让你放精力放 在最关键的东西上，并防止自己分心于对完成任务关系不大的其他事情上面。也就是说，只要掌握了一套完 整的“使用条件”，就可以对自己的系统作出清晰的描述，并转移到下一个阶段。在这一阶段，也有可能无 法完全掌握系统日后的各种应用场合，但这也没有关系。只要肯花时间，所有问题都会自然而然暴露出来。 不要过份在意系统规格的“完美”，否则也容易产生挫败感和焦燥情绪。 在这一阶段，最好用几个简单的段落对自己的系统作出描述，然后围绕它们再进行扩充，添加一些“名词” 和“动词”。“名词”自然成为对象，而“动词”自然成为要整合到对象接口中的“方法”。只要亲自试着 做一做，就会发现这是多么有用的一个工具；有些时候，它能帮助你完成绝大多数的工作。 尽管仍处在初级阶段，但这时的一些日程安排也可能会非常管用。我们现在对自己要构建的东西应该有了一 个较全面的认识，所以可能已经感觉到了它大概会花多长的时间来完成。此时要考虑多方面的因素：如果估 计出一个较长的日程，那么公司也许决定不再继续下去；或者一名主管已经估算出了这个项目要花多长的时 间，并会试着影响你的估计。但无论如何，最好从一开始就草拟出一份“诚实”的时间表，以后再进行一些 暂时难以作出的决策。目前有许多技术可帮助我们计算出准确的日程安排（就象那些预测股票市场起落的技 术），但通常最好的方法还是依赖自己的经验和直觉（不要忘记，直觉也要建立在经验上）。感觉一下大概 需要花多长的时间，然后将这个时间加倍，再加上 10％。你的感觉可能是正确的；“也许”能在那个时间里 完成。但“加倍”使那个时间更加充裕，“10％”的时间则用于进行最后的推敲和深化。但同时也要对此向 上级主管作出适当的解释，无论对方有什么抱怨和修改，只要明确地告诉他们：这样的一个日程安排，只是 我的一个估计！
1 package Com.TomTest; 2 3 4 public class TomTest_38{ 5 public static void main(String args[ ]) { 6 int n=0,m=0,t=555; 7 try{ 8 m=Integer.parseInt("8888"); 9 n=Integer.parseInt("abc789"); 10 t=9999; 11 }catch(NumberFormatException e) { 12 System.out.println("发生异常:"+e.getMessage()); 13 e.printStackTrace(); 14 n=123; 15 } 16 System.out.println("n="+n+",m="+m+",t="+t); 17 } 18 }
标签：这一 nts ack 说服力 工作 code color 自动 根据
原文地址：https://www.cnblogs.com/borter/p/9438764.html
