Thinking in product developing

 Thinking in product developing
2006-10-06
[e-mail]

Complexity (Hard(H), Simple(S), Middle(M))

1. Satisfy the customer's requirement  

Feature                                       [S]
Easy to use                                 [M]     

2. Satisfy the service team's requirement
Easy to maintain                           [M]
Easy to upgrade                            [H]

3. Satisfy the follower developer's requirement
Easy to maintain                           [M]
Easy to add more new features     [H]

对于一个软件产品， 我们在设计开发时应该满足以上需求，才能称的上一个优秀的产品。

现以所经历的一个中大规模的产品为例，谈谈我在其中所碰到的一些问题。
这是一个PACS (医学影像存档通讯系统)，是现在医院信息化系统中不可缺少的信息管理系统。

首先从项目初期开发工具的选择谈起，项目启动相对任务比较紧迫，因为系统在前期只需要实现单机版，无须支持WEB，系统需要用到大量的第三方的开发库，比如影像的传输，影像的显示，影像的压缩，影像的管理等等。

权限控制
未采用LDAP,未与系统无缝集成，在于其它系统集成，扩展时，遭遇权限控制问题
数据库的选择
从MSDE到SQL Server 2000到Sybase ASE，SQL server 2005, 中间涉及到大量存储过程的移植，带来不少的工作量。

数据库接口库的选择
ADO, ODBC，low level API 未采用统一的接口库
中间部分客户因数据库死锁，耗费了很多的人力，财力资源

图像库的选择
DCMTK, UCDAVIS, LeadTools 还有公司自己的开发库（其他跨国团队开发，部分项目开发人员不熟悉，所以采用自己比较熟悉的开发库）
导致在与第三方集成时出现很多问题，还有后期开发库升级，标准升级，无法及时更新。
   要明确我们是在做产品，会有一个产品系列，文件，通讯标准都会升级。
项目开始，必须要求自己的强制规定，任何人员必须遵从。 因为我们内部的强制规定，在后期的功能扩充，需求变更中充分体验了内部标准带来的惊喜。

通讯库的选择
没有使用统一的借口库， 各模块随意使用同步，异步socket, completion port
导致开发过程中出现多次因通讯导致的棘手问题.
以后可强制采用ACE.

开发工具的选择

因开发包均为C++/C编写，针对开发人员的熟练程度，采用Visual C++ 6.0
压缩库的选择
购买第三方软件，前期调研不足，公司已经拥有自己的压缩库，后期导致一些license 收费问题，给产品带来一定的影响。
附属第三方工具库的选择
程序中使用不同的STL库，给后期程序维护引进一些问题。
      开发工具一定要明确。

测试工具的准备
采用自己编写和使用第三放成熟工具， QE对通讯协议不熟悉，导致工具引起一些问题（与第三方）
测试工具不充分，致使很多问题未被发现
     QE部门要有充分的准备，必要时可寻求Dev的支持。

测试开发设备的部署准备
中间出现更换刻录设备，机器断货等多种问题。

架构设计
因对未来需求分析不足，导致某些核心模块出现流量瓶颈。
只能采用折中方案，采用分布式部署。
要有很好的原型，可供测试及市场部门评估

存储的扩充
存储架构设计时对流行NAS, SAN，磁带库了解不足，出现单机不连网络无法正常工作等问题，尽管可以通过其他途径 解决。
系统工程师前期需要介入

压缩工具升级
归档程序会频繁调用压缩工具压缩/解压文件，压缩工具已exe的形式存在，可有效解决压缩异常，内存泄漏等极端潜在问题。

系统升级
数据库在各个子版本之间，变动较大，导致升级工作量巨大。
数据库更换
决策层随意更换数据库厂商，致使开发，测试工作量增加很多。
明确用户的需求（诱拐也可以，一定要挖掘出用户的真正需求），充分评估第三方软件带来的影响。这部分需要投入，核心开发，测试人员需与用户有效互动，可在开发前期，在用户场所工作几天。

第三方系统的集成 （信息系统和同类第三方系统）
接入设备的扩充
未充分考虑新设备的接入，致使后期需改动代码加以支持
需要实施，市场部门提供足够的集成信息

WEB接口
通过标准服务实现Web集成，效率低下
系统的可扩展性（从单机到科室到医院到集团医院到数据中心）
潜在需求不清晰，致使各版本跨度较大，升级，总体开发工作量加大。
Milestone要明确

系统的维护计划
前期无清晰系统维护计划，导致销售被动。

开发过程的控制

设计评审
设计评审比较到位，各模块功能清晰，开发人员工作量适度

代码评审
代码评审欠缺，致使产品发布后，现场发现不少低级的严重问题。
Defect评审
只是发现，指出问题，没有认真分析问题为什么会出现，QA工作不到位。

开发节奏的控制
一般每个季度会有一个月份比较紧张，一个月比较轻松。
过于紧张，过于清闲，都会导致项目人员情绪低下，节奏一定要控制好。

SCM版本控制
有效的流程，BVT,监督机制

服务工程师的培训

服务工程师没有有效的培训，致使研发人员承担部分service 工作。

严重问题的补救

各团队配合不默契(各级的services, 开发)，致使问题发现较晚，小问题被 放大。

针对开发设计的几点想法：
需求挖掘,
设计开发人员最好能到实际应用现场体验用户的工作流程。
测试人员参与需求分析
需要一定要可测试，
评审到位，反馈至开发
杜绝类似问题重复出现
避免出现相同的DEFECT，
出现类似的问题，需要对开发或测试人员予以警示，让他们知道这会影响他们的performance.
编码规范，测试人员可评审
代码不规范， 日志描述不清，测试人员一定要提出来，要求予以及时修改。