老狼博客

当短信成功下发到手机终端时，一个多星期的联通业务接入程序终于完成，由于以前没有类似的开发经验，中间走了不少弯路，浪费了很多时间。总结下开发经验为下一步开发移动的业务接入打下一个基础。

开发过程遇到的几个难点：

1、序列号的定义

      序列号分成三部分，每部分为一个32位整数，第一部分表示命令源节点的编号，第二部分表示命令产生的日期和时间(网关系统中的任何命令的保存时间都不应该 超过一年)，格式为十进制的mmddhhmmss,比如11月20日20时32分25秒产生的命令，其第二部分为1120203225;第三部分由0开 始，循环进位，直到进位满了之后再清零，重新开始计数。接收方在返回应答时，应答的序列号必须和相对应的命令的序列号相同。　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　    　　　

 　由于java只有byte,short,int,long等数据类型，不像c/c++那样，有unsigned int，所以java语言中普通的int变量不能存储如此大的数据

比如说，我所在的城市济南,区号为0531,公司的企业代码为41211,按照源节点编码规则为3053141211,共10位，而int变量的范围为-2147483648~2147483647

    int srcnode = 3053141211;显然不能通过编译因为已经超过int的表示范围。

    还好，Java提供了超大整型类BigInteger

　 int srcnode =new BigInteger("3053141211").intValue();    //源节点编号

　 byte[] srcnodeBytes = IntToBytes4(srcnode);

	/**	 * 将int转换为byte数组	 * @param i 待转换的int变量	 * @return byte[] 转换后的byte数组	 */	public static byte[] IntToBytes4(int i) {		byte[] mybytes = new byte[4];		mybytes[3] = (byte) (0xFF & i);		mybytes[2] = (byte) ((0xFF00 & i) >> 8);		mybytes[1] = (byte) ((0xFF0000 & i) >> 16);		mybytes[0] = (byte) ((0xFF000000 & i) >> 24);		return mybytes;	}

    用于Java采用补码srcnode的字节长度为5,不要使用toByteArray()方法获得字节数组，应单独编写一个方法用于int转byte[]的方法，注意必须以网络字节序的方式转换，即高位放在低地址，低位放在高地址

2、int转byte[]及字节序

　　在将int转为byte[]，须注意字节的顺序。字节顺序分网络字节序和本地字节序，网络字节顺序是TCP/IP中规定好的一种数据表示格式，它与具体的CPU类型、操作系统等无关，从而可以保证数据在不同主机之间传输时能够被正确解析。网络字节顺序采用big endian排序方式。sgip1.2规定数据传输采用网络字节顺序Big endian(将高字节存储在低地址处，将低字节存储在高地址处)。具体转换及移位操作的使用见http://blog.csdn.net/Mailbomb/archive/2008/05/30/2496168.aspx

3、重复收到联通上行(MO)

　　重复收到联通上行困扰了我好几天，仔细检查命令的格式都没有错误，上网搜索 在csdn看到一个遇到同样问题的帖子，加他QQ，问他这个问题时一直不肯告诉我原因，真的太小气了。想想也是，说不定他解决这个问题费了好多的时间和精 力，怎么能让自己辛苦劳动的结果让别人拿去呢，真没有开源精神，鄙视下!

     最后实在找不出原因，打电话请济南联通的张工在后台跟踪下，最终找出原因:

     在SMG向SP递交上行时，SP收到上行必须给SMG一个deliver_resp应答，且应答的序列号必须和相对应的命令的序列号相同。 问题出在我返回了应答，但是返回的应答序列号和之前的上行的deliver命令的序列号不同，SMG认为SP没有收到上行，所以才会重复发送上行给SP.

4、收到用户的定购命令但无法下行(MT)

 　　实施SPMS系统后，凡是订购（定制）业务都需要SPMS给用户发送确认短信，得到用户确认后，才形成临时订购关系；当SP的订购成功欢迎短信通知成功下发后，才生成正式订购（定制）关系。

　　根据“联通在信”SGIP1.2协议修改部分说明，在给用户下发短信时，必须附加linkID且SP下发时UserCount必须填写1，否则视为业务非法包处理。

　  Submit命令中Reserve字段说明

该Reserve字段为8个字节的保留字段；现将该字段作为MO和MT之间一一对应的LinkID来用。

入职以来一直会遇到这种问题，也许是软件行业的死穴，任何项目如果处理不好解决不了这些问题，就相当于得了慢性绝症，不但项目的结局是死路，经手项目的每 个开发人员到管理者都在经受挑战人体极限的折磨。开发人员就像交通工具，上级传达指令，他就会最高效的将之送到目的地，如果老板自己都不知道想去哪里或者 不会开或者GPRS导航都不会用，就算给他一辆保时捷或者飞机都是白搭，说到这就知道为什么软件行业跳槽之频繁了。

一、问题列表：

1.客户(或上级)自己不知道自己想要什么。
2.客户需求已明确，后由于业务需要，频繁更改，更改后发现还不是想要的。
3.无底洞的需求变更和功能修改。
4.项目催的紧，本来两天的工活一天要完成，项目变成拔苗助长。
5.后期软件改成一锅粥，程序员一走，基本无人能明白需求和可以接手。

二、搜集的例子：

1. 几年前，我和一位同事在外地共同参与一个软件项目的开发。项目本身并不算很大，开始的需求调研进行了很长时间，期间不但几乎拜访了所有部门，还与用户反复 讨论，征求意见，需求文档几易其稿。即便这样仍然有许多不确定因素，搞得人心烦意乱。当时我牢骚很多，总觉得又花时间似乎还没真正做事。
我的同 事经验比较丰富，他给我说了一个他自己的亲身经历。那时候他在深圳参与一个证券项目，当时软件开发管理非常不规范，基本上是了解需求后就编程序，根本没有 太多的交流，需求文档就更没有了。系统开发出以后，用户不断提出新需求。每天追着开发人员解决问题，项目实际是一个无底洞，没完没了地往下做，按他的说法 是项目成员“肥的拖瘦，瘦的拖死”，实在做不下去只能跑了。

2.前段时间，我出任项目经理承接了一个中型软件项目，公司再三叮咛我一定要尊重客户，充分满足客户需求。项目开始比较顺利，辛辛苦苦熬了几个月的通宵，基本保持项目的正常进度，客户相当满意。但进入后期以来，客户频繁的需求变更却带来很多额外工作。
需求变更不但越来越多，更可怕的是为了节省时间，客户不再向我申请变更，而是直接找程序员商量。程序员疲于应付，往往直接改程序而不做任何记录，很多相关 文档也忘记修改。很快就出现一个问题，就是需求、设计和代码无法保持一致，甚至没有人能说清楚现在系统到底改成什么样。后来因频繁出现改好的错误又重新出 现，这让我很无奈。

3. 这是我进入公司以来的第三个项目。做这个项目给我的最大感受就是：做项目前一定要弄清楚需求。否则只有无数次的反工。导致项目一直延期。成本超出预算。
我们公司是甲方。我们只做UAT测试。当已方把代码写完。提交我们测试的时候。我们竟然发现已方都没有做系统测试。最后我们只好又做系统测试，又做UAT4测试。
最初是分析需求，写用例。需求变化的非常频繁，以致于最初的需求和后来做出来的东西相差很大。导致三周写的用例变成了无用功。后来因为急于上线，大家加班 加点的测试，改BUG，回归BUG。还加班了好几个通宵呢。在主要流程凑合跑通的情况下。系统上线了。大家终于松了一口气。近两个月的加班加点，终于让系 统上线了。
接下来就是进一步的测试。很多细节都还没有测到。也不用那么加班加点的赶了。好景不长啊。不到一个月，第一次的需求便更来了。而且变化很大。又一次加班， 接下来就是接二连三的需求变更。就连主要流程都变了。同一个功能的需求两天内就变了三次。以致于到最后，和最初做的系统相比已经面目全非了。呵呵。等于又 重新做了一个嘛！这样不仅一直拖延工期，使得项目一直不能告一段落，而且预算超出很多。开发部、测试部的同事也很厌烦。尤其是测试部门的。大家都说用不着 细测的啦。反正过不了几天这个需求还得变。现在测了也没用。呵呵。看看。大家都有了这样的心里了。这测试的质量很难保证的啊。大家干活一点积极性也没有。

4.转自Javaeye的一篇：
==========================
问题
==========================
越来越像无底洞的需求

首先声明俺们是做项目的，每个项目都大多相同，但是有很多细小的地方是不一样的。
于是乎，每个项目的需求总会有些差异。。。
于是乎，需求就越来越无底洞了。。。

俺正在做的一个计费的程序，就是这样，从一个小蜗牛成长一只大乌龟（当然从遗传说角度来看这是不可能的）。

最开始的时候，这个计费是很简单的，只需要处理以下几个情况：
从数据库固定的域里面读取出用来计费的依据。
从数据库固定的域里面读取出用来筛选的域。
按照三个固定的计费规则去计费，固定的收费，按比例的收费，按区间固定的收费。

本来这不是特别重要的，也没有特别去重视。
但是这个需求开始慢慢鼓胀了。。。每个地方的项目总会有那么几个不一致的地方。。。总要改一下……
后来简直发展成每个地方一个版本了。

首先，计费的依据不再是从数据库固定的域里面去读取了，而是可以自由指定一个数据库的域。伤筋动骨啊。
然后，计费规则也发生变化了，固定的收费，按比例的收费，按区间固定的收费，按区间固定比例的收费，按区间固定比例累加的收费。
计费的方式也有了变化，有把要计费的依据加起来一起收费，也有把各个依据分别收费然后再总和起来。。。又是一个伤筋动骨。

于是在春节前后，趁着没啥事的时候把整个程序扔了，用了decorate模式。心想，这次完事了吧？

没想到……又有了更加BT的需求了。。。
痛苦啊！！！！

遇到这种情况的时候，大家有什么感想……

==========================
回复一：
==========================
对项目的业务不清楚，光靠前期的调研只能知道大致要做的，实际上的细节用户自己也很难说清，等系统上线了，有了实际的原型，就是你认为开发完了不应该再变 动的系统，用户才会有具体的详细要求，当然也不是一次能给你，只会在碰到什么实际业务时突然想起，这是很常见的情况。

这种模式很常见，也就很合理，再做项目的时候，首先要考虑对用户的业务熟悉不熟悉，如果不熟悉，就要考虑好这种情况，换个角度来看，这种由于业务不熟悉导致的需求变更，是公司应该交的学费，怎么在前期做好项目策划，就非常重要。

对 具体做事的程序员来说，首先要清楚，这类项目上线后，才是原型完成，后面将有一轮又一轮的详细需求，开发时间基本上和模块开发时间相当，要做好 持续修改的准备，业务等于在这个阶段才真正开始做测试。第二就是，用户的每个需求变更都是有原因的，要把原因找到。第三，把工时记下，提交给项目经理。

===========================
fight_bird 的回复
===========================
楼主遇到的需求变更、膨胀状态其实是国内定制化软件项目业务逻辑挖掘的一个正常过程，并非存在所谓的无底洞，本质问题还是需求调研没有做好、做细，却匆忙开始系统分析和编码，结果当然是不停的做炒冷饭的事情！

恕我直言，根子还是在项目管理的水准，这么粗的需求分析状态下不应该允许进入详细设计阶段，我怀疑你这个项目是几个人的小项目，你们公司的项目监理机制几乎不起作用。

说得上纲上线一点，你们公司在国内项目业务需求的调研上没有成熟的方法论指导，还处于客户“指哪打哪儿的状态”，这种状态长期下去会拖垮开发团队，这对于处于创业成长阶段的公司倒是可以理解，但对于想做大、做强的公司来说却是必须跨越的阶段，否则这样的公司长不大的。

===========================
一蓑烟雨任平生 说：
===========================

项目管理也许有些问题，但我觉得还是项目策划的问题，对一个业务不熟的项目要有一个策略，成本估算时要充分考虑到后期的反复，这个跟走不走需求管理的流程没有关系。需要清楚的是怎么做这个项目，如果不挣钱，以后能从这个项目中得到什么？

因 为对业务不熟，到最后才能了解业务的细节，这里面有一个长期的学习过程，这个过程是要付出代价的，这个成本在项目的策划时就应该考虑到，同时要 考虑这代价在以后的项目中怎么逐步降下来，产品化不产品化不重要，重要的是业务的积累和团队的稳定，否则以后还会付出更大的代价。

===========================
Joo说：
===========================
说的很在理，基本上在国内这种状况能占了80%的项目（国外不知道，可能会好那么一点点？）
但是一般往往软件费用在第一次上线之前就已经谈定了，再接下来要改你要收钱他就翻脸：不是之前说好的么？

==========================
fight_bird 回复：
==========================
对于国内项目这种事情很常见，就看搞售前和商业策划的本事了，这时候就凸显行业经验的重要性和价值，这样的项目最合适的方式是分期完成，合约也分期签署，前期做好了，后期可能合作更深入，可以达到双赢，反之，可能双亏了。

==========================
hax回复：
==========================

需求调研不可能达到做好做细的理想境界。

a. 需求本身就在变化，比方说在6个月的开发周期中可能客户自己的人、事、组织都有了变化。
b. 客户代表本身不一定能很好的认识和把握需求，有许多细节是不可能在初期确定下来的。
c. 企图做好做细，只会大大增加前期的时间和沟通成本，而且团队在拿到所谓的需求说明书之后往往忽略了开发过程中的沟通和调整，问题被掩盖、推迟和归咎于需求没做好的借口。

大 多数项目为什么会失败？失败并非是单纯的做不出东西，而是指无法在给定资源（时间、费用等）下完成项目，有大量资源被浪费了，做了无用功。所以很多人就认 为要一开始先把好关，避免浪费。然而认为把需求做好做细就能避免资源浪费，是一厢情愿的想法。因为需求是无止境的，你也无法有效验证需求的合理性。从理论 上说，需求做的是不是好，最后还是要看实施结果，所以前期对需求是不是足够好足够细的判断，只能基于猜测或者形式上的要求（比如写了多少页画了多少图开了 几次会）。
==========================
abang回复：
==========================

看了楼上各位的留言，使我受益匪浅

总结了一下：需求的尽量全面细化与时间尽量少是一矛盾，需求越全面越细化，花费的时间就越多，花费的时间越少，需求就很难做到全面细化，解决这一矛盾的关键还是掌握好火候，使需求和时间的配比做到最佳。

说说容易，做起来难….
==========================
zhangshoukai回复：
==========================
国内的客户吧？

三、解决方法：

古人根治绝症的方法无非是从根源将其除之，软件行业的这些问题追其根源还是在于人，人性有很多弱点，如果卡耐基在世并且也做软件，应该不存在这些问题。
说笑了，我想在目前软件行业发展的基础上，最好的方法还是多加强沟通，多学习国外的软件管理和规范，客户和老板要多考虑业务实际需求，项目经理严把关卡，开发人员也要学会拒绝。需要客户、老板、项目经理、开发人员四者配合才可以妥善解决。

在2009年里，有“IN”的趋势就伴随着有“OUT”的。但并非绝对。 进入的（INs）不会无所不在，而出局的（OUTs）也不会销声匿迹。基本原则是，在2009年你会看到比2008年更多的INs，更少的OUTs。那么 我们开始吧……

IN: 掌握商业技能的IT专业人员 – OUT: 技术认证

IN: 基于Web的应用 – OUT: 自建定制软件

IN: 过程自动化，以便节约资金 – OUT: 周期长的项目

IN: Mac进入企业 – OUT: 升级XP机器到Vista

IN: 虚拟化 – OUT: 海量的机架式小型服务器

IN: 酷睿i7 – OUT: 奔腾

IN: 瘦客户端 – OUT: 知识工人人手一台笔记本

IN: WiMAX – OUT: 城域Wi-Fi

IN: Ubuntu – OUT: Red Hat

IN: 商业智能 (BI) – OUT: SNMP 数据超载（overload）

IN: 远程办公 – OUT: 5天8小时工作制

IN: HP 笔记本及台式机 – OUT: Dell 笔记本及台式机

IN: 多功能服务器设备 – OUT:  单性能最佳的网络设备

IN: 智能手机 – OUT: 替代台式电脑的笔记本

IN: 视频会议 – OUT: 空中飞行赴会

IN: 更多实习生 – OUT: 固定职位

IN: 节能 – OUT: 超前IT建设

IN: WAN 加速 – OUT: 空闲光纤（Dark fiber，指光缆中尚未连接设备的纤芯）

IN: 3G 宽带 – OUT: 帧中继

IN: 小型笔记本Netbooks – OUT: 台式电脑

IN: 网上微软Office – OUT: Azure, Live Mesh,以及 Windows Live

IN: 缺少技术背景的CIOs – OUT: 作为首席工程师的CIO

IN: IT/商业 集成 – OUT: 集中化的IT部门

月前参加Xue24的创业与职业的话题讨论，我第一感觉是，创业是比短处的，职业则是比长处的。

    创业当老板，即便你有很多长处，但如果你不会拿合同，公司就可能死了。做老板，圣诞节就没法休假，每天都会在想事业，下了班晚上你心理还是很紧张，这是你 的一切，老板是完全责任的，像念书，没有放下的时候。作为职业经理人，你可以选择你擅长的事情干，干完活，时间过了，责任就会减轻甚至消失，到家里就基本 放松了，这是心态上最大的不同。

    现实中有个情况，大家都想当老板，一个根本原因是在整个市场上利益划分更倾向于资本划分，极端的情况下，哥俩合伙创业，老二那人最后还是独立创业了，这不是反应一个人的问题，是反应在现在整个中国情况下，劳动方和资本方之间存在的大问题。

    职业与创业的选择，应该从过程快乐的角度来选择，人最后归宿都得死亡，享受过程快乐的人生才丰富多彩。成功不成功某种意义上是体验问题，曾经痛苦时候要比 幸福的时候更值得回忆，当你现在比较困难，穿得不漂亮，住的房子不好，等有钱时候再回忆，这时候你能体会到过往生活的乐趣，因此，要把快乐建立在过程上 面。

    大学刚毕业时候，学生们眼高手低，他认为他要做很多事，学很多东西，招聘的时候，学生上来就会问，这个岗位我能学到什么东西，而实际上，职场不是学东西那 么简单，不是说你今天会解决一百个问题，明天会解决一千个问题才是进步，而是要找感觉，找平衡感，经历了这个过程，你知道，决策的速度和准确性比知识更重 要。

    为什么那么多人想去创业而最终没能去实施创业？重要的是，无论你创业也好，职业也好，最终你需要获得做事平台，决定一个人阶段性成长的，平台好坏很重要，平台好的话，你一年时间可能走过别人三四年的路。

    创业之前，对于成功的期望值是可能性的最大释放，在大公司，你有很多想法，可能老板不认可你，也没有人支持你，选择创业，第一感觉是想到没有老板限制你，没有不同意见反对你，你能做你认为最有意义的事情，可能性进行了最大化释放。

    而真正创了业，你会发现，成功期望值按照最大可能性的计算方法变成了实施限制最大化，你每一个好的主观想法都需要客观资源来支持，否则同样是空话，创业从零起步的限制也被极端放大。

    这是创业前后最大的反差，也是很多人在实施创业时不得不打退堂鼓的原因。职业状态或者创业状态，最终的评判应该是能否提供更好的平台。

    现实的情况并没有给创业者提供好的环境，尤其刚毕业大学生，为什么大学生毕业创不了业？你连基本的资源都没有你创什么业？没有一个很好创业孵化环境，创业则难上加难。
    转摘自:http://blog.sina.com.cn/s/blog_45db55eb01009dl5.html