※ 引述《OnlyRD (看色戒会欲求不满)》之铭言： : 标题: Re: [讨论] 外包的软体合约通常有具体的需求规范吗? : 其实写程式本来就很繁杂 : 无法做到模组化跟标准化 : 需求跟规格变来变去也很正常 : 过度追求流程问题只是一种精神洁癖 : : 设计的时候当然是可以有一套开发的方法 : 但是实做的时候...免不了就是要一直修改啊 : 尤其台湾的软体工程师...来来去去的... : 我只能说code乱写的人实在太多... : 往往程式到後来就是...乱到连改都快改不动的程度... : : 我个人觉得写软体就是一种服务业 : 产品出去了就要要不断的maintain : 顶多就只能像DHL一样做到工作的分配跟管理有一套流程 : 但是货还是人亲自送到客户手中的... : : 忘记模组化跟流程这件事吧 : 当一个PROGRAMMER就跟一个7-11的店员一样 : 你得把他当服务业来经营... : 而不是工厂一开就不断量产的电子业... : ========================================================= 如众多网友所提, 软体需求的变动不能免. 程式的需求与规格会变动, 开发的方法就要能考虑到变动的弹 性. 卖出去了, 因 bug 要修改或替换模组, 因新的需要必须再更 动等等都成为必要的 maintain . 不管是出货前还是出货後, 都会 碰上修改的要求, 为了便於修改, 就必须强调设计的模组化, 清析 的流程, 甚至为了让别人能接手 出货後的maintain , 那还得讲求 程式的可读性. 不尽力做模组化, 代价是後面的维护难以为继. 如果是做机关软体包案的, 可能会认为与其修修补补不如推倒 重新打造, 包新案比同意後续维护赚的钱更多, 所以只求能结案领 款, 但相反的, 买的那一方可能就得尽力挑毛病要求尽力改好, 以 免用不了多久, 因卖方不肯也无法修改或维护, 就得废掉再新买, 那买卖双方就很难迅速结案付款了. 最後, 当然在保固期间就会变 成 7-11 的店员一样地被随叫随到, 可能还会是拿不回完整最後尾 款的下场. 今天的情况是要问: 做过的包案为何不能大部份再利用, 当成 另一个类似包案的既有基础, 这样做跟修改是差不多的, 但因为在 设计时就要求模组化, 所以容易拆并, 又因注重文件与可读性, 所 以可以让其他少数人就能在既有基础上做出类似的包案, 也因可修 改与可维护性提高了, 就能针对需求做较容易的变动与维护就不再 怕被扣尾款了. 这个模组化与可维护性才是软体工程想提升的能力. ======================= 软体合约有没有具体的规范需求 ? 1.都不给买方修改或维护的弹性, 就怕得罪买方, 抢不到标. 2.若说甚麽都可以改, 那也牛皮太大, 变得像空口白话, 不负责 任, 如果买方需索无度, 那岂不更严重, 闹成血本无归 ? 3.配合买方做出买方满意的软体系统, 那麽有些修改是免不了的, 即使像随机卖, 录在 CD 的套装软体, 也都是有足够的弹性让用 户选用不同的硬体也能自动找对模组匹配. 这是提供买方用户自 行维护的服务法. 软体合约显然会引导供应源与客户的行为模式, 影响软体品质的提 升方向与成长. 对这个标题的疑问, 应该可以大致判定, 外包的软体合约目前在台 湾还是欠缺具体的需求规范, 所以政府机关的软体的委外虽然大案 子有资策会协助的需求规划与规格, 也有大包小包分包下去, 但最 底层写程式去实现的人, 似乎仍然反应是规格不清, 大量修改的机 率还是很高, PG 的怨气都推给 PM 了. 在大学的电算中心里, 有关 e 化的项目还是受制於当年软协 建议政府机关软体一律委外的限制, 不给编制人员名额用於开发软 体. 但事实上在同一个机关里, 替行政单位开发软体就跟人力派遣 快没两样, 去一个陷一个. 都不派, 行政单位还是想方设法用一些 号称资讯人员的临时人力在使用, 但最後这些人也都流失於行政工 作, 为了怕流入行政单位, 这些人都是临时约聘雇, 都等着国家考 试被正式任用. 唯一的好处是这些变相进用的人不会排斥电脑, 但 也造成好像资讯人员永远不够的缺乏现象. 另一个缺点是这些临时 资讯人员(?)拉低了待遇, 也造成需求庞大的假象. e化的问题, 基本上是透过电脑想达成业务自动化, 但大量进用 临时约聘雇, 反而跟节约人力的自动化相违背, 所以人员就变成临 时性质, 这种人力扩充在公务预算单位经常发生, 就因为新工作任 务不会加之於老公务员, 新工作要新人, 不想加新人就会企图想要 引进电脑 e 化代替白领人力, 但在无法草拟规范需求下, 就很难委 外, 只能用类似派遣变相进用能做(或操作)资讯系统的人力, 冀望 电脑化後再利用约聘合法解除人力, 但这种想法的後果就导致不论 是委外或自雇约聘人员开发的系统, 在 "人性上" 无法完成. 因为 验收系统的约聘人员很难做此 "自杀性" 的同意. 比之於大型建筑 物的建置与使用过程, 很难想像为何资讯系统的建置行不通. 这里 忽略的是大型建物都是成熟的概念, 外观再怎麽变化, 其堪用期很 长, 投资金额巨大但值得, 建造时有大量的自动机械帮忙而且工人 是高薪的. 可是, 新增业务性的资讯系统就像新产品 RD 开发案, 寿命周期是很短的, 经常是开发出来一套, 无法推广, 没人续用就 挂了. 私立大学没有国家性超然的人事会计与财产人员, 学校不受这 些公务员管制, 所以能整并所有行政人员与资讯人员为一体, 没有 需要大量约聘或工读生代公务员处理的问题, 在规划新系统时能做 合理性的整体考量, 提供的自动化工具与人力是适当搭配的, 不太 可能是禁令如牛毛, 到处为求生存钻漏洞, 上下交征利. 这种规划与建置新应用资讯系统的压力, 在大学就全都集中到 电算中心. 有规模的私校电算/资讯中心都是庞大的, 但公立学校 则是仍受制於当年软协的委外建议, 在人力是不足的. 公立大学的 电算中心没有软体开发与软体工程能力, 当然是造成资讯科系师生 在软体工程认知的不足. 校内的电算中心替行政单位开发软体系统, 其凄惨的情况可能 比之於 SI 业者做政府包案还不如, 所有的反覆修改, 无法结案, 派一个赔一个黏一个, 全都发生了. 而且人力有限, 直到赔光还是 骂声怨声不断, 比起业者形容刁钻的买方, 恶质的环境还更惨. 就因学校的行政单位要求电算中心做的软体开发案, 几乎是没 有需求规范的. --

※ 发信站: 批踢踢实业坊(ptt.cc) ◆ From: 140.115.1.146