系统分析员,让我头痛

本文主要是介绍系统分析员,让我头痛，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

关键词：头痛 失眠 郁闷  烦躁 UI GUI 界面 人机交互 表示层 业务逻辑 模型 视图 控制 MVC 发布 订阅 Observer  Listener Publisher SA COM Sink 回调 Facade 设计模式 JSP ServLet JavaBean EJB CGI FastCGI

来上海快一月，成果：要做什么知道了（战略），怎么部署也知道了（战术），产品 渠道 促销 价格各个层面都开始开展工作（当然，重点在 产品和渠道上）。

副作用：头痛。

病症结论：

一、需求 界面必须直顶向下做。
也就是首先做出系统的对外的特性，界定系统边界。界面原型和用例，后于用例文本。用例必须有比较详细的文本描述。步骤是：
1.边界定义（有什么，无什么） 列表
2.参与者及其目标 列表
3.用例简介
4.成功情节
5.失败情节
6.失败处理
7.界面原型（首先草图，这样，在beta前由UI来设计）

二、需求 界面必须由PM亲自带领需求分析人员来做，同时带领系统分析员亲自带领开发人员做前期技术预研。
需求 界面必须由PM来做。系统分析员最多作个技术辅助作用，判断技术能不能实现，不行的可能要预研；不能让SA来定夺需求和界面，原因太多了。这就是产品经理和技术经理的分工和平衡问题。系统分析员的构架必须满足需求和界面，应该对产品经理直接负责。

三、系统分析员的设计工作必须从下向上。
如果是桌面软件，最好由系统分析员全部设计到模块，把所有的交换接口都搞出来，如网络通信协议，数据库设计，重要的数据结构，表示层和逻辑层的通信接口，等等，要做到不要让编码人员去判断做什么，怎么做，只要做实现一个已经定义好的模块就ok。

四、表示层、逻辑层、网络层必须纳入到系统分析员的设计列表。
必须把各个层的通信接口设计清楚，然后把各个层内部的模块设计好。
最大的问题，就是把把表示层和逻辑层的通信接口的设计工作放到了编码人员手上。
第二大问题，就是把表示层和逻辑层的角色没有分清楚，如，数据更新到底是表示层主体去查询还是逻辑层主动通知，数据的状态是逻辑层记录还是表示层记录；如果都需要记录，怎么分开记录？
这需要系统分析员有足够的魄力。
个人认为，系统分析员不是没有能力，而是没有充分发挥自己的思维，没有按自己的思路去做。

五、问题复杂化。
不需要分层的，一定要分。
不需要什么设计模式的，一定要套。
不需要分工合作的，一定要搞民主分工，如网络层，界面层，其实，最核心的就是各个层的通信机制，各个模块的外部耦合关系，分析员做好这两件事情，就可以了；也只用做这两件事情。但，见过太多，把此类事情推给了不知道做什么不知道怎么做的开发人员，以至于天天讨论select nio iocp，这个算什么？？？设计好一个通信接口，里面用什么model，有那么复杂么？

六、原则问题：请系统分析员，不要让开发人员做自己都不明白怎么做的事情。
此类事情，不明白的，特别是业务逻辑不明白的，一定要在需求结交时候就搞清楚；对表示 操作 存储不明白的，要在设计时候就有确定的解决方案。不能违背这个原则！！！PDCA，计划不仅仅是叫某某去干什么，是首先把怎么干协商好（或者直接告诉他），然后有把握的去做。相信我，如果你都不知道怎么做，那就不要下手去做，更加不要吩咐别人去做。一定要由解决方案（也就是有设计方案）（随便谁来做这个方案），然后再来做。
这是执行力的保证。
任何员工都不喜欢得到一个不明不白的任务。

七、系统分析员，工资几何？
可以比CEO还多！

八、桌面软件的通病：GUI和逻辑层的通信问题。
理论上的MVC PME和摆在面前的COM VCL Swing 以及自己能设计的最最实际的事件处理机制，真的搞透彻了吗？先不说RPC RMI CORBA。
知道 了解 使用 应用 精通 修订，你到了哪个阶段？

九、过渡设计
简单就是美，不要搞的太复杂。模板 泛型真的那么有用么？一个磨合不到一个月的团队，适合么？简单，不仅仅是代码上的，也是操作上的。操作不仅仅是代码上的，也是团队上的，人事上的。
一切是平衡效率的结果。
你能系统思维么？有系统知识结构么？有方法论么？有辨证法么？有辨证的方法论么？

此文写给我自己看的，意外事情，请读者自付！

这篇关于系统分析员,让我头痛的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！

---