第一篇:浅谈我局的软件开发推广工作
以“四网一库加安全防风险”综合服务管理信息系统建成运行为标志,地税系统进入了一个全新的发展阶段。《北京地税综合服务管理信息系统》本身为我们提供了丰富的功能,但在日常使用中,我们的各类使用人员并未全面掌握,这势必造成了一面是已开发好的功能得不到充分利用,一方面又急于不断地开发新的系统,新系统的各项功能同样又得不到充分利用的现象。为此,对软件的开发、上线运行进行总结就显得尤为重要,本文试图就我局近两年来的软件推广、开发工作从信息化角度进行总结归纳,以利于今后的软件推广及开发。
一、软件推广工作
核心征管系统的推广成功,强调的是“核心”二字。近两年来,在核心征管系统的整体框架内,做为核心系统的补充,我局又有六个工作平台上线运行,分别是:高端展示平台、税务档案归档子系统、核心征管辅助查询系统、税收管理员工作平台1.0升级版、土地增值税台帐管理系统、日常评估工具软件。这些应用系统在推广过程中根据各自的特点采用了不同的培训和后期维护方案。
在这些系统的推广过程中,信息科主要负责系统运行的环境的搭建、服务器的操作系统及数据库的安装、数据库数据更新程序的编写、利用系统管理员用户建立其他各级别用户;相关业务科室负责培训业务流程、系统操作等。以下是在软件推广过程中的经验得失。
(一)我局软件在推广部署过程中,采用了一些措施取得了明显的效果:
1、抓组织领导,我局专门成立了“税收管理员工作平台”推广领导小组,制定了详细的软件推广工作计划与方案,精心组织,周密部署,把软件推广工作稳步推进。
2、抓宣传,多形式多渠道的开展“税收管理员工作平台”相关知识宣传,在内网设置专题栏目,积极宣传使用“税收管理员工作平台”的意义和作用。在宣传过程中突出软件的实用性,便利性与必要性,增强我局干部对“税收管理员工作平台”的了解与认识,使之认同并接受。
3、抓培训,组织师资力量分别对业务技术人员进行业务规范、操作和技术培训,着重就“税收管理员工作平台”的具体操作程序、数据的录入等方面的内容进行了详细深入的讲解和现场演示,以确保一线业务、技术人员熟练掌握“税收管理员工作平台”的操作和管理。
4、抓服务,上门辅导,深入基层帮助安装调试管理软件系统,面对面的讲解辅导,手把手的指导操作,及时解决“税收管理员工作平台”在使用过程中出现的的问题和遇到的困难,并实行跟踪服务,及时掌握使用情况与动态,着力提高申报成功率。
5、提供强大技术支持,力减日常维护工作量。鉴于各地信息建设化程度不同,人员应用水平不同,在推广“税收管理员工作平台”时要注意与基层部门沟通好。“税收管理员工作平台”领导小组和软件开发商应建立热线电话和网站,提供强而有力的技术支撑。
例如:通过狠抓以上各项措施的有效落实,我局“税收管理员工作平台”推广工作进展顺利。
为了进一步提高核心征管回放数据的利用率,充分利用我局现有条件,我们积极参与税收管理员工作平台的培训、完善、推广工作。我们对后台数据库进行了优化和整合,我们又相继开发了核心征管辅助查询系统和纳税评估卷宗打印系统,提供了适合我局自身特点的数据查询平台,有力地充实了核心征管系统的查询功能,提高了查询速度,进一步提高了我局纳税服务水平。
(二)在某些软件的推广过程中有些方面还有待提高:
1、沟通不畅:软件推广过程中协调不够、各行其是,出现问题责任不清、相互推诿。
2、培训不力:在软件使用培训时,相关科室只针对自己涉及到的内容进行培训,致使出现了问题自己解决不了、别的科室也无能为力。
3、态度不端:软件推广过程本位思想严重,把自己喜欢的事情完成后,其他全部是其他科室的工作,与自己无关。
4、后劲不足:软件进入优化阶段,没有深入基层探究其还存在哪些问题、在应用方面还存在哪些不足、在系统维护方面还有哪些方面需要提高等。
以上这些,直接影响软件的推广效率以及后期的软件优化、系统维护等工作的顺利开展,使我们的努力事倍功半。
(三)建议:
在以后的软件推广工作中,应组织推广运维队伍。区局综合软件集中推广。各部门根据实际情况,调集必要骨干人员,建立日常运维队伍并保证人员的相对稳定;制定问题反馈机制、项目负责制度以及激励和考核等工作机制与制度,以保证推行工作的顺利开展。
获取业务软件源代码。我们在与开发商签订协议时,因版权、成本等原因都没有购买源代码,软件的修改与否,修改的时效,掌握在开发商手中,主管部门失去应有的控制权和主动权。因此,我们在推广有关软件时,还应注意获取业务软件源代码,将源代码掌握在自己手里。这对于软件的日后完善和修改,以度跟进维护以及对于我们自己的技术人员软件开发能力的提高都有很大的好处。另外,购买了源代码,特别相关技术文档,可有效防止由于开发商倒闭或因技术人员的流动,导致项目无法跟进的情况发生。
为做好软件的推广准备工作,区局应根据推广软件的具体情况,并结合可调配资源情况,统一制定推广实施方案,依靠推广运行维护体系,做好安装调试、推广指导、技术支持、上线检查和验收工作。
二、软件开发工作
由于我局倡导自主开发,下面我们首先谈谈应用开发人员应具有的能力和知识体系。
因为每个人的职责不一样,所以每个人都有不同的侧重点,但并不等于我们可以对其他人员所做的工作一无所知。适当的了解别人,特别是与我们工作相关人员的工作,以便更好的协调我们与其他同事之间的工作。
(一)个人能力
作为一个软件的开发人员,满足更好胜任工作的能力作为一种技
第二篇:软件开发工作职责
职位描述:
1、独立地设计、开发、实现和测试关键应用系统
2、将作为团队骨干理解业务问题、分析系统需求并编写需求规范
3、有能力对一个应用模块或子系统进行架构设计
4、配合进行软件产品的需求定义、设计,BUG的修改
5、负责软件的测试计划和优化、设计文档编写、测试分析报告
6、为现有系统和客户提供技术支持和维护。
岗位职责:
1、负责.net平台的应用系统编码实现
2、测试用例编写,并完成单元测试
职位描述:
职责
1、编码及单元测试;
2、编写技术文档。
工作职责:
1、带领小组进行.NET项目开发。
2、负责公司现有产品的.NET架构改造
职位描述:
职位描述:
1、网站后台程序与数据库设计。
2、参与网站的创意策划。
岗位职责:
1.根据要求进行编写、测试及维护应用程序;
2.协助高级人员分析及设计系统,参与开发应用程式或系统;
3.解决用户文档。
岗位职责:
1.根据要求进行编写、测试及维护应用程序;
2.协助高级人员分析及设计系统,参与开发应用程式或系统;
3.解决开发技术难点;
4.准备用户文档,参与售前、售后、客户化、产品开发项目。
职位描述:
岗位职责:
1、开发网站前台功能和后台管理系统;
2、编制有关系统架构文档、数据文档,并根据要求编制有关程序;
3、对所开发程序不断优化及做好正常维护工作。
岗位描述:
1、负责项目的程序开发,能够按时完成任务
2、负责一些开发相关的技术文档的编写
3、能够对项目做一些适当的设计
4、负责安装部署已经开发的项目
5、能够跟客户良好的沟通,负责分析解决客户提到的一些程序或数据问题
java程序员【工作职责】
-参与Java Web应用程序开发
-对已有的应用程序、组件进行升级和维护
-准备单元测试的计划、用例、数据和文档
-遵从标准代码规范编写程序
工作职责:
1、负责网站程序开发。
2、维护、推广公司网站。
工作职责:
负责软件开发,程序文档编写。
工作职责: 负责微软CRM软件项目的开发及管理工作,包括微软CRM项目开发管理,开发团队管理等。
工作职责:
1负责对需求进行分析,并且根据开发框架进行模块的设计和分解;
2。编制模块设计文档工作;
2。关键技术难点的突破,对模块编码人员进行指导和工作分配;
3。关键代码的编写,参与核心模块的测试工作;
4。配合项目管理经理完成日常的管理工作;
主要职责:从事基于B/S构架的WEB程序开发和项目实施
工作职责:
· 参与软件系统的详细设计,形成规范化的文档
· 根据文档,编写相应程序,并负责所编写程序的初测
· 根据系统中具体难点问题,参与针对具体技术难点的技术攻关
工作职责
1、参与软件的设计工作
2、.Net开发环境下的应用程序和网页的开发
3、提供系统日常维护的技术支持
第三篇:陌陌推广软件开发要求 摸摸推
陌陌推广软件开发要求:
一、功能要求部分
1、要求可以直接群发指定信息到陌陌用户,无阻碍。
2、可以自由定位各大中小城市。
3、要求可以自由编辑内容,向陌陌用户发送信息。
4、可以自主设定发送的时间间隔。
5、要求能够自动切换账号,在一定的条件下,自动切换,如发送量去到2000,自动切换另外的账号。
6、账号希望以Txt的形式来导入。
7、自动化高,无须人工过多操作,无须看守。
8、要求可以设定轮流发送不同内容的推广信息。
9、要求模拟人工操作,模拟人工发送。
10、发送速度可以调节,最低要求每分钟发送1条。
二、其它要求
1、有类似功能要求的陌陌软件,已经开发出来的可以联系我,测试,是否符合我的要求,符合要求可以直接购买
2、不得用模拟器来开发,必须真机发送。
3、不接受安卓模拟器的解决方案
4、无开发实力的请绕道。
三、时间要求
1、要求一周整理内整理好demo。阐述好实现方法理念。
2、要求半月内完成基本功能版本。
第四篇:NET软件开发工作职责
1.制订开发计划。
2.负责新产品的研发工作。
3.负责针对客户订制的应用集成项目的开发。
4.负责联合开发产品的二次开发工作。
第五篇:我总结的一些软件开发规范
我总结的一些软件开发规范
作者:田进恩
为了提高软件开发质量,降低开发周期,增强代码的可重用性和易读性,使软件便于维护,开发人员间便于交流和协作,特总结出开发规范,以为参考。
一. 原则:
1. 软件工程化 2. 模块化
3. 能简单不复杂 4. 强调团队协作 5. 强调创新和特色
二. 具体规范:
1. 命名规范
命名应尽量使用匈牙利命名法,变量名或函数名中使用大写字符来区分各个部分,以便于记忆和阅读。如bPatchMinute, DeleteDirInfo()。全局(包括类中的)变量用长名字,局部变量用短名字。
类成员变量前一般应加上m_,全局变量加上g_,仅与本模块有关的变量加上l_,紧接着是变量的类型。整型: n,i 长整型: l 无符号整型: u 无符号长整型:dw 字符: ch 布尔量: b 浮点数: f 双精度浮点: d 字符串: str,lpsz,sz,p,lp,ac, 指针: p 字节指针: pb 无符号指针: pv 字符指针: lpsz 整型指针: lpn 文件指针: fp 如:
m_nTotalNum,m_strPath,m_bRcving,m_fPrice,g_lOpenDate,g_dwCardNo,lpszNameStr, lpnSysDoomType,uMsgID,m_pProgress
局部变量应尽量易懂简洁,使用常见的变量,如
Num,nCount,i,j,k,n,len,pos, offset,nReadNum,index,nRet,ret, string,filename
临时变量,如ltmp,ftmp,tmpStr,tempStr,函数命名也应该见名知意。如CalcAllDataStyle(),ReadDocDataFromTime(),GetIndexInfo()常见的函数
Init, OpenAll, Create_, Get_, Set_, Read_, Load_, Write_, Start_, Stop_, Check_, Test_, Fill_, Process_, Sort_, Do_, Select_, Is_, Exist_,_Ex。
宏命名和typedef定义类型应详细,避免重复,一律为大写,如
#define DEL_EMPTY(a){if(a){delete a;a=NULL;}} #define SUCCESS 0 #define FAIL-1
typedef struct { char lpzSource[100];char lpzTitle[100];char lpzURL[194];short nType;long npos;long nlen;}ATTBODY,*LPATTBODY;(指针前加LP)
自定义消息从WM_USER开始
#define MYAPP_MESSAGE WM_USER+0x1001
2. 代码规范
有些不易理解的变量或函数应作注释,难懂的代码要有注解,在文件的开始处有该文件的用途描述。一定要保持注释的一致性。
代码组织要清晰,{,},(,),if,else,do,while,for,case等要对应整齐,少用空格,缩进全部用Tab键。变量的定义要集中,函数间要有空行分开,一个程序中的空行数目最好占8%-16%。多态函数和功能相近的函数集中放在一起。
代码应该简洁、清楚并讲述了所发生的一切,我们的目标应该是写出最清晰的代码,而不是最巧妙的代码。例如如果是MFC多文档程序,就要严格按照其生成的框架写代码。尽量使用编译器已经提供的函数,不必花时间另行编写。例如系统已经有qsort函数,可直接拿来排序用。
某些公用代码要注意多平台易移植,最好使用标准C。
代码的重用要仔细,要将相关的代码也拷贝过来,注意那段代码也许不适合你的应用场合。删掉从来没有用过的函数或变量,大篇幅注释掉的代码行也应删除,以免使程序混乱难读。
3. 工程文件组织规范
一个工程往往包含很多很多文件(*.h,*.cpp,*.inc,*.lib,资源文件等),向工程中加入文件或删除工程中的文件要慎重,避免把工程损坏。工程中不起作用的文件或类应删除,工程目录下的非工程文件也应该移走,保持工程的清洁,避免混淆难于管理。工程文件如果很多,应归类。
在VC环境下,建议将常用的头文件全部放入stdafx.h中,而在每个cpp开始处嵌入stdafx.h。避免头文件的交叉引用,如果有严重的交叉引用,适当使用类的声明。
将独立性比较强的模块抽出来,做成DLL,控件或COM组件,该模块可单独编写和测试,也增强了其可重用性。
一个比较大的工程应留有一定的消息接口或插件接口等。
工程的版本控制要严格,版本格式为xx.xx.xx,必要时使用Build次数或日期。高版本尽量兼容低版本的用法、数据或协议。
工程的编译宏定义和工程参数设置应正确,每作一个新工程时应检查工程参数是否正确。建议字节对齐方式为1字节对齐。
工程文件应经常备份,备份时注明备份日期和主要增加的功能。
4. 类组织规范
类一般有两个文件,一个头文件,一个实现体CPP。
类力求封装好,严格区分public,private,protect等作用域,如果一个函数与本类有莫大的关系,可以作为该类的静态成员函数,不用或少用友元函数等破坏类封装性的方法和技巧。如果一些结构或宏仅与本类有关,可在类头文件中定义。
类的成员变量在构造函数或初始化函数中应赋初值。指针在构造函数中赋NULL,析构时DEL_EMPTY它,以免内存泄露。
5. 用户界面规范
有四大类型的用户界面:对话框、单文档界面、多文档界面、其它界面
对话框要易用且简洁,字体和控件的组织搭配要得体,能简单不复杂,各控件的焦点、Tab顺序等要讲究,视应用场合要适当支持键盘。在简洁易用的前提下,力求个性化,设计得更加友好。程序各对话框的风格要保持一致。
单文档和多文档界面的程序功能可以做得很强,也便于扩充和管理。其中菜单、工具栏、状态栏等设计要有特色。菜单按一定的分类弹出,必要时设计成多套菜单,在重要的窗口或区域应能弹出右键,实现常见操作。工具栏上放最常用的操作按钮,必要时动态更换按钮。状态栏显示足够多的有用信息。
消息主控在Mainframe中,单文档的主控也可在View中,所有的对话框的弹出或非模态对话框的控制都在主控窗口中完成,具体的数据处理放在单独的文件中或设计成类。在App类中实现Ini读写,各数据对象的定义和析构,全局变量的赋值和初始计算,存盘退出等。各视图的OnDraw和GDI画图尽量使用内存位图的方式,以免闪烁。
其它还有ATL,控制台,嵌入式程序界面等,也有作为其它容器如IE中的插件等,此类程序可能不用MFC,而采用COM组件等方法实现。
6. 疑难解答和Bug调试方法
勤问、善于问。在不打扰正常工作的前提下,开发人员间应相互帮助,聚思广益,也许你的问题或Bug就是他人的前车之鉴。
从各种途径请求解答。专业书、教材、期刊、电子文档以及国际标准文献、RFC等,Internet上专业网站、论坛、专家组等。
Bug的出现总是有一定的原因的,冷静查找,不要总是拘泥于某一个小局部,换一个想法、从另外一个角度也许让你柳暗花明。使用一些辅助开发或调试工具,如Spy++,Process Viewer,系统监视器等。
拓宽知识面。多参阅其它编程语言、数据库知识、编译原理、网络协议等,熟悉硬件设备、底层汇编、数字逻辑电路等。使用和揣摩其它软件功能和界面,集百家之长,做出有创新意义和有特色的功能性软件。
三. 一些习惯:
我认为比较好的习惯:
1.if(0 == GetDataType(…))比if(GetDataType(…)== 0)好,纵使误将==写成=,在编译一层就会报错。2.#define MAX_DOWNLOADNUM 20 struct DownInfo m_DownInfo[MAX_DOWNLOADNUM];在代码中尽量不用具体的大小数值,定义成宏,便于以后维护。3.CUSTXG_CONTABLE g_lpCustCon[] = { {“数值串1”,C_ZGB,C_CUSTJBM,C_VT_FBJ,“万”}, {“数值串2”,C_ZSZ,C_CUSTJBM,C_VT_FBJ,“万”}, …
{“数值比例”,C_WTB,C_CUSTHQ,C_VT_FBJ,“%”} };int g_nCustNum = sizeof(g_lpCustCon)/sizeof(CUSTXG_CONTABLE);g_ nCustNum自动适应g_lpCustCon的大小。4.函数定义short GetInputType(const char * lpzInput)比short GetInputType(char * lpzInput)好,以免lpzInput在函数体中被破坏。5.协议包头定义成:
typedef struct tagDataHeader { struct{ unsigned char Version:4;unsigned char HeaderFlag:2;unsigned char Reserved:2;//保留Bits位 }Info;long nOther;long Reserved;//保留4个字节 } DATAHEADER;定义有一定的保留字段,供以后扩充使用。6.变量在定义时赋初值,类析构时或程序退出时判断释放所有变量。7.编码空间一定要充分预留,编码时注意可扩充性。
我认为不好的习惯:
1.代码中是“+2”,“+4”,而不是“+sizeof(short)”,“+sizeof(int)”。2.filename[40],而不是filename[MAX_PATH]。
3.GDI资源使用完后不释放,位图、笔刷等用完后不Select出来。这样会将导致系统Gdi资源丢失或内存泄露。
4.大量使用无符号型变量。无符号变量在判断时易造成错误,甚至死循环,尽量少用。5.使用malloc,free不使用new,delete,大量使用realloc。new,delete是规范的C++语法,通用性强,realloc易造成内存抖动。6.#define square(x)(x)*(x)宏的体应加括号,否则容易出问题,如1/square(x)将被替换1/(x)*(x)
以上仅是我总结的一些,比较少,希望能抛砖引玉,请大家补充