开发流程

Jdon框架快速开发指南 开发主要步骤如下: JdonFramework6.0以上 两步开发见这里 。 快速配置指南 新增/查询/修改/删除(CRUD) ; 批量查询和分页显示 本文Step By Step详细讲解如何使用Jdon框架基于领域 模型 快速开发这两个功能，通过Jdon框架的可以快速完成 系统原型(ArcheType) ，使得开发者将真正精力集中在每个项目系统的特殊业务处理。 本案例源码下载 按这里查看更详细全面文档 快速配置指南 Jdon框架有一个配置文件叫jdonframework. xml ，其中配置的是我们编写的Java类，格式如下： <pojoService name="给自己类取的名称" class="完整类的名称"/> 配置有两个基本项：name和class，class中写全POJO的全名；name是供代码中调用这个服务的名称。 或者使用Annotation注解@Service或@Component，就无需上面这个配置。 假如我们编写了一个类 TestServicePOJOImp ，代码简要如下： //@Service(" testService ") public class TestServicePOJOImp implements TestService{ private JdbcDAO jdbcDao; public

经常有朋友问我性能测试流程是什么样的，每次我都简单说说，但这东西三言两语说不清，刚好现在刚压测完一个项目，快要放假不忙，就拿刚测试完的项目写一下我们性能测试是怎么做的。 一、项目背景 此次需要压测接口共计14个，外加一个消费MQ的批处理。其中14个接口分两部分，对应两个模块，对应两个开发。 二、环境部署 此次项目是重构的PHP项目，所以没环境，需要申请并搭建环境，运维申请服务器并搭建PHP和nginx，然后部署和功能测试一样的环境，然后把环境交给我。拿到环境之后我需要改掉配置，配置上我们压测的MySQL、redis、MQ等，然后在服务器上配置好hosts，因为需要调用其他项目的接口，需要配置上对应压测环境的hosts才能正常访问，调试接口能正常访问基本环境就没问题。 三、脚本调试 一般我们都会让开发把SQL打印出来，方便我们调试，这次PHP项目最初开发说打不出来，框架打印出SQL就会报错，所以最初在没有SQL的前提下调试接口，效率非常低。后来经开发调试后，SQL能打印出来了，但是这个项目涉及到两个数据库，一个是本地项目的数据库，另一个是其他项目的从库，用来查询数据，到现在为止，那个从库的SQL依然打印不出来。 说下打印SQL的必要性。其中最重要测是方便接口调试，其次，通过SQL的打印，可以发现一些问题。之前一个项目，其中一个SQL开发查询一次，框架会在打印一次，相当于查询了两次

开发API URL 调用接口 | 代码开发API | FEE 开发API 登录与门户API 首先要进行代码集成与组织机构的集成 其次在自己的系统登录界面，登录成功后要执行ccbpm的框架登录。 所谓的登录就是调用ccbpm的登录接口，如左边的代码所示。 // 如下代码需要写入您的系统校验密码与用户名之后。 string userNo = "zhangsan"; BP.WF. Dev2Interface .Port_Login(userNo); 菜单API 发起：一个操作员可以发起的工作 待办：等待处理的工作。 在途：我参与的，但是这条流程还没有结束的流程。 抄送：不需要我处理，但是需要我知晓的工作。 发起: //获得指定人员的可以发起的流程列表,调用这个接口返回一个datatable, 可以参考一个demo实现发起列表的输出。 System.Data. DataTable dtStart = BP.WF. Dev2Interface .DB_GenerCanStartFlowsOfDataTable( "zhangsan" ); 待办： //获得指定人员的待办,调用这个接口返回一个datatable, 可以参考一个demo实现发起列表的输出。 DataTable dtTodolist = BP.WF.Dev2Interface.DB_GenerEmpWorksOfDataTable

关键词： 工作流引擎 BPM系统 接口调用 工作流快速开发平台 工作流流设计 业务流程管理 asp.net 开源工作流 一、程序调用开发接口 二、 接口说明 所谓的驰骋工作流引擎的接口，在BP.WF.Dev2Interface.*上面的静态方法，前台页面通过这些静态方法通过页面于操作者提供交互数据功能交互。 Port_* 开头的方法都是组织结构相关的操作，比如：登录、登出、发送消息。 DB_*的都是提供数据列表的接口，比如：发起列表、待办列表、在途列表、完成列表等。 驰骋BPM的发起、待办、在途菜单功能都是通过这个静态方法提供的BP.WF.Dev2Interface.DB_*接口生成的列表。 驰骋的工作处理器创建工作ID、发送、退回、移交、删除、加签、会签等操作也是调用BP.WF.Dev2Interface.Node_*通过流程接口对流程的操作比如：流程的删除、回滚、撤销、冻结、取消冻结等流程的操作都是操作的BP.WF.Dev2Interface.Flow_*开发接口。 以WorkOpt_* 开头的方法，都是工作流引擎部件的代码，比如在退回窗口上，获取可以退回的节点列表，设置指定的节点处理人。 我们在流程属性里有一个接口，请参考如下图： 菜单接口 获取数据是如何根据您自己的需要，通过CCBPM的接口获取想要的数据。 比如：发起流程，待办工作，在途工作。 类名：BP.WF.

给正在考虑用流程开发项目的朋友的一些建议： 1. 开发工作流系统的工作最好不要碰，否则很容易陷进去出不来。如果您决心要开发工作流并且想把它商品化，请做好长期抗战的准备。 2. 如果您的系统用到的流程不多，最好不要用工作流概念来开发您的系统，直接去写死流程和固定代码即可。 3. 如果以上两者皆不是，那您就考虑购买可考的第三方的工作流引擎。他们一般有较好的服务。如果公司没有钱，就考虑开源的，当然您需要费点劲去研究它。 4. 工作流程引擎不可能诞生在实验室里，产品级的流程更是与客户不断磨合、千锤百炼的结果。 5. 如果您要购买工作流 , 请多看演示。不要被一些开发商所用的表面化的概念所迷惑。 好用的工作流一定是简单的、 容易理解的、面向业务人员的。 6. 使用商品化的工作流程，不要考虑购买什么源代码，源代码对您的用途也不大，因为一个队伍有一个开发思路，在您了解完成它的东西时，您的项目也被耽误了，您的这些时间与精力足以能够完成固定流程的开发了。软件就是一种服务，您拿钱购买的就是这种服务，您可以用这种服务获取更多的钱。 7. 购买工作流引擎时 , 要考虑接口的灵活，要与您现有的系统可实现结合。功能丰富的不一定是好用的，无用的功能浪费您的精力去理解它的概念，还不如没有。 8. 如果对方接口比较友好，客户对实施的要求不高，运行平台是个次要的问题。 9. 购买工作流引擎的时

　　一直再做前端，突然想到如果有一天领导让自己独立承担一个web 项目的话是否有足够的能力去接这个任务，要学会自己去搭建一些基础的工具信息。所有的这一切在心里都要有个大致的流程，不然真正做的时候难免会手忙脚乱起来，接不了这个活难免失去了一个表现自己的机会，接下来做的差了，则更影响了钱途，前途啊。所以本文对做PC端的项目进行了一个过程的总结。 　 　一、了解、明确需求。 　　这个应该是第一步了，不了解需求你就不知道为什么要做，要怎么去做这个项目的工作。 　　（1）明确需求是相当重要的，很有必要去和产品经理、设计人员去沟通，需要明白每一个按钮，每一个开关存在的意义，这个需要设计人员足够的了解项目的需求。之前做的一个项目就是这样，工资花了好多钱请了一个UI设计公司设计了一个十分高大上的产品，各种页面各种炫酷，领导觉得很满意，赶紧让我们去做，结果，真正到了我们开发人员手里去开发的时候，才发现有些东西虽然在这里很炫酷，但是根本不应该存在在这里啊，例如你把添加人员的按钮放在人员分组的管理下面，而不是人员管理下面有什么意义呢？结果可想而知，不仅一些功能白设计了而且由于项目时间关系还得我们开发去担任设计，重新设计功能的展示位置，这无疑耽误了项目的进度。 　　（2）后台接口问题，一般大的公司前台和后台是分离的，如果分离需要去跟后台确定各种接口的方式，要有一个文档去管理这些后台接口，要有示例、测试数据

title: 敏捷软件需求管理 date: 2017-10-23 10:29:39 tags: 需求管理 严格的来讲，这个标题的说法并不是很严肃，这篇文章的目的不是建立一个敏捷软件需求管理的流程，而是去探索一种需求管理的实践，解决现在工作中遇到的困惑和困难。为了将问题解释的更清楚，我需要先从流程定义说起。 流程定义  上面这个图是一个典型的IPD（集成产品开发）流程图，从大的视角来看，这就是一个典型的瀑布模型，需要有前一个阶段的成果作为后一阶段的输入，后一阶段的工作才能开展，这样当然没有错，不过有时候会显得低效和无法满足项目的需求。 同样，我也拿出我们研发层的各阶段的定义，进而进一步探讨。  从图和表中点后可以看到，需求分析集中在项目的前期的阶段，理所当然，需求就要作为后续工作的输入，因此需求很重要，这都知道，所以在图中也设置了需求的技术评审，但需求的技术评审并不能保证全部的质量。 总结来说，需求很重要，但需求又大多数集中于前端部分，不好管控，怎么保证需求高质量的分析，发现和实现都是比较困难的事情。 需求层次 产品开发规程中，对需求层次的定义是： op=>operation: 用户需求 op1=>operation: 产品需求 op2=>operation: 软件（子系统）需求 op(right)->op1(right)->op2 用户需求是顶层需求，直接反应用户的需要

什么是 CI/CD？ 在软件开发中经常会提到持续集成Continuous Integration（CI）和持续交付Continuous Delivery（CD）这几个术语。但它们真正的意思是什么呢？ 在本文中，我将解释这些和相关术语背后的含义和意义，例如持续测试Continuous Testing和持续部署Continuous Deployment。 工厂里的装配线以快速、自动化、可重复的方式从原材料生产出消费品。同样，软件交付管道以快速、自动化和可重复的方式从源代码生成发布版本。如何完成这项工作的总体设计称为“持续交付”（CD）。启动装配线的过程称为“持续集成”（CI）。确保质量的过程称为“持续测试”，将最终产品提供给用户的过程称为“持续部署”。一些专家让这一切简单、顺畅、高效地运行，这些人被称为运维开发DevOps践行者。 “持续”用于描述遵循我在此提到的许多不同流程实践。这并不意味着“一直在运行”，而是“随时可运行”。在软件开发领域，它还包括几个核心概念/最佳实践。这些是： 频繁发布 ：持续实践背后的目标是能够频繁地交付高质量的软件。此处的交付频率是可变的，可由开发团队或公司定义。对于某些产品，一季度、一个月、一周或一天交付一次可能已经足够频繁了。对于另一些来说，一天可能需要多次交付也是可行的。所谓持续也有“偶尔、按需”的方面。最终目标是相同的：在可重复

感觉这两章联系比较密切，第五章又比较有趣，放一起了，而且好像不适合记笔记 我好像并没有太深刻的印象，对敏捷流程的感觉挺模糊的，挖个坑以后懂了再填吧 团队 一致的集体目标 分工合作，相互依赖 软件团队的模式 主治医师模式、明星模式、社区模式、业余剧团模式、秘密团队等等 开发流程 最重要的瀑布模型(因为经常看到这个词) 类似传统行业的流程，阶段性的，各个步骤之间的分离增加了回溯修改的困难程度 开发周期长 敏捷流程 找完成产品要做的事情(Product Backlog)-> 决定冲刺要解决的事情(Sprint Backlog)->冲刺(Sprint)->得到软件的增量版本 冲刺期间的每日例会(Scrum Meeting) 冲刺是时间驱动的，断拖延的后路 重要的问题是如何得到任务的良定义 如何确定冲刺的进度 迭代式的开发 我现在的感觉敏捷就是调动团队成员的积极性，有目标的push起来，缩短开发流程 不盲目敏捷，敏捷和形式化的流程都有其适用的任务范围，且还决定于团队的状况 来源： https://www.cnblogs.com/QiLF/p/11440729.html

今天给大家简单分享一下项目开发的流程： 项目开发流程 销售 ---> 客户 客户 ---> 下单 ，支付 30% 定金 产品经理 ---> 客户 实地考察 需求调研 整理需求文档 项目经理 需求文档 开发文档 原型图 美工 原型图 --- 设计项目界面 后端 开发文档 --- 开发接口 前端 设计稿 --- 完成页面的编写 开发文档 --- 完成业务逻辑 测试 有bug ，打回，修改 bug 上线 程序员 ---> 客户 ： 系统培训 老板收钱 来源： https://www.cnblogs.com/KoBe-bk/p/11438222.html