关注微信 欢迎致电:400-8310-286

你在这里

Twitter 粉丝管理

项目背景

客户经营的是一个线上市场分析和咨询的网站,并通过社交工具Twitter来宣传和分享相关资讯,但是客户不希望这些信息被网站顾客以外的Twitter用户看到,于是客户需要定期清理他的Twitter粉丝群,移除一些不符合条件的粉丝。在此之前,客户通过http://unfollowers.me/ 这个网站提供的功能来处理,然而,客户需要逐条和当前系统中的数据对比,效率极低

需求

  • Twitter与Dotnetnuke网站集成
  • 根据客户给出的条件,列出指定Twitter帐号的所有粉丝
  • 允许用户强制取消某些粉丝对该帐号的关注

解决方案

根据需求,我们需要结合Twitter API,在客户已有网站的基础上开发一个DNN模块。

技术要求:

  • .NET Framework 4.0
  • SQL Server 2008
  • Visual Studio 2012
  • ASP.NET 4.0

CMS平台:

Dotnetnuke 7.0。

第三方插件:

LinqToTwitter

开发过程中遇到的挑战:

问题

诺怀解决方案

诺怀软件遇到的第一个问题是Twitter API的调用,由于Twitter API对获取粉丝的方法有以下限制:每次调用API最多只能获取20条记录并且在15分钟内最多只能调用API 15次,也就是我们最多能取出300条记录,然而某些Twitter的粉丝数量远远大于300。

通过大量调研,诺怀软件最终找到另一个方法能获取更多的记录,但是15次的限制仍然无法突破,于是诺怀软件采用游标查询+分页的方式尽量取得更多的数据。

开发过程中遇到的另一个问题是测试和验收的问题,由于诺怀软件开发的模块是在客户已有系统的集成,诺怀软件本地开发环境上并没有客户系统中那么完善的数据。客户反馈说结果不对,但是诺怀软件一直无法重现。

通过和客户一次次沟通和澄清(在此过程中客户也非常耐心的澄清自己的观点和提供对诺怀软件有帮助的数据),最终发现是一些用户错误输入导致的一些脏数据无法满足查询条件,针对这些脏数据,能够通过代码处理的(比如多余的空格大小写),诺怀软件一一帮客户解决,其他的客户也了解到不是程序的问题,对此表示理解。

 

客户收益

  • 顾客现在有了一个能完全满足他们需求的模块,极大的提高了他工作的效率。
  • 及时向客户发送日报及周报,让客户清楚了解开发状况。
  • 快捷简单的操作流程为客户节省了大量时间

 

客户满意度

最终,客户对这个项目表示很满意,他得到了他想要的功能,并且非常希望与诺怀有进一步的合作。

MSR Power DNN站点

概要

一个来自美国的客户要求诺怀建立一个新的官方站点。 客户是一个能源公司的管理人员,需要一个网站来介绍及宣传公司,之前客户已经有一个比较老的DNN站点, 但是需要用新的DNN版本更新他们的网站, 并且使用新的皮肤, 修改网站外观, 发布网站到新的服务器上。

因为诺怀拥有丰富的DNN站点开发,发布经验,并且长期保持高质量的提交,所以客户选择跟诺怀合作。

 

使用技术

·         Dotnetnuke

·         Power DNN

·         DNN 免费模块

 

解决方案

Dotnetnuke

客户根据之前低版本的DNN建站经验, 继续让诺怀使用DNN为他建站。 因为诺怀具有丰富的DNN经验, 所以在较短的时间内向客户提交了高质量的产品。

Power DNN

客户已经拥有了域名, 但是需要使用全新的服务器。

诺怀根据经验给客户推荐了PowerDNN作为站点服务器,并且为客户推荐了比较合适的服务器类型和价位。 这为客户免去了选择服务器的痛苦,并且大大降低了成本。

 

亮点

·         使用DNN高效率地建立网站。

·         给客户提供网站部署的建议并成功发布网站到PowerDNN。

·         诺怀在项目中使用了客户提供的项目管理工具, 对bug和任务进行追踪, 较快的解决客户的反馈。

·         诺怀在项目中使用敏捷开发, 坚持给客户交付可用的版本, 使客户实时了解项目进度。

 

客户获益

·         客户通过诺怀的帮助, 最终站点按照需求完成了开发, 并被成功的发布。 通过诺怀的建议, 客户在建站成本上获得了较好的控制;通过诺怀频繁的提交,客户对项目的进度进行了很好的把控,并且获取到了期望的产品。

 

截图

首页1

 

首页2

文档页面

会议页面

联系我们页面

医疗器械风险分析系统

客户背景

客户是美国某公司联合创始人,在质量管理与风险控制专业领域有丰富的经验,主要从事医疗器械质量控制相关的咨询和培训工作。

客户计划开发一套自动化和高集成的风险管理分析的软件,目标客户为医疗器械供应商、生产商、风险咨询顾问以及相关的权威检测机构(FDA)。客户有多位合作伙伴,都是在专业领域拥有丰富经验的专家,但开发软件的费用由客户独自出资。

项目初期,客户在美国请开发团队完成项目数据库以及架构设计,在了解我公司的服务品质与价格方面的优势之后,于是将项目外包给我公司。

项目概况

项目简介:该项目是一套整合不同企业需求的风险管理与分析系统, 主要功能包括定制风险管理参数,风险分析(故障树分析FTA,失效模式与影响分析FMEA等),风险生命周期管理、高级文档管理等,产品特点是拥有完整的风险管理过程,提供图形与表格等多种分析方式,灵活性高。

项目进度:已于2012年正式上线,有稳定的正式客户和多位试用客户。

合作时间:2011~至今

项目规模:共约50人月

合作模式:ODC (“外包IT团队’)

团队配置:团队共2人 ,项目经理1人,开发人员1人

项目费用:约15万美元

技术要点:

  • 部署环境:Window Server 2003,SQL Server 2008 R2, IIS7
  • 开发环境:Virtual Studio 2010, Telerik,  C#, JavaScript/JQuery/GoJs

主要事迹:

  • 2011-04    项目启动,诺怀准备开发团队, 完成项目需求整理以及交接过程
  • 2012-01    完成项目Beta 1.0版本
  • 2012-03    发布正式版本1.1
  • 2012-05    扩展新功能,优化FMEA表格分析和FTA图表分析
  • 2012-10    对操作界面改版,提升用户体验。
  • 2012-12    发布正式版本1.5,项目版本稳定。
  • 2013-06    项目维护、功能添加、优化性能,多次发布版本
  • 2013-08    发布正式版本3.1

问题及方案

 

问题

采取的方案

客户沟通

  • 客户业务繁忙,沟通时间较少
  • 业务知识专业性很强
  • 客户每天会投入2-3小时的时间在项目上,我们会提前准备需求方面的问题,然后与客户进行语音沟通,沟通完成后会整理沟通内容发客户确认,效率很高。
  • 整理客户介绍的业务知识,并通过网络搜索和购买了业务书籍对专业知识进行加强。在沟通过程中多采用原型工具、流程图等与客户确认需求,确保双方对需求理解一致。

文档管理

  • 无详细需求文档
  • 无法跟踪需求、设计和测试文档
  • 因为客户提出需求的方式多为口头表述,主要由我们进行整理汇总,形成需求文档。
  • 在软件开发中期,使用软件自身的文档管理功能来对需求、设计和测试文档的跟踪管理,同时也对软件功能进行验证。

开发与维护

  • 数据库设计与业务需求不完全匹配
  • 项目框架的耦合性很高,不利于扩展
  • 核心功能复杂,不易于维护
  • 与客户多次沟通讨论之后,对数据库设计进行了局部调整,使其能更适应业务需求。
  • 对框架及现有代码进行逐步重构,使项目健壮,易于扩展。
  • 对核心功能封装成业务组件,减少重复代码,提升项目质量,同时维护更加简单

质量控制

  • 客户对UI及设计有一些特殊要求
  • 客户希望试用用户以及合作伙伴能看到更多新功能,但这些功能可能还需要继续优化,不能直接部署到产品网站上。
  • 在发布正式版本时容易有文件遗漏和数据未更新的问题。
  • 整理客户对UI及设计上的要求,同时根据公司的代码规范标准,形成项目规范
  • 除部署产品网站外,另外部署了开发测试网站和试用评估网站,以满足客户的需求。
  • 整理出发布流程,每次发布严格按照流程进行检查,保证版本发布正确性。同时版本发布必须经过在测试网站和试用网站上进行充分测试后才会部署到产品网站。

客户收益

  • 获得成功:客户与多个公司签定了咨询和软件服务合同,并且有多位潜在用户正在进行试用该产品。
  • 提升专业领域影响:客户通过软件实践,验证一些风险管理与质量控制的方法、技术,提升客户在专业领域的影响
  • 质量提升:提高最终用户公司在生产力、产品安全、质量以及法规遵从性等方面的竞争优势
  • 节约成本:通过软件减少最终用户在风险管理方面的投入,节省大量的管理时间
  • 与FDA建立合作关系:因为软件在风险分析与质量控制方面的功能完整,能自动生成FDA期望审核的报表,所以与FDA建立了良好的合作关系,如与FDA联合发表技术文章,为FDA定制一些需求等。

项目业务流程

  • 风险管理过程

  • 危害、事件的后果、危害处境和损害之间

项目核心功能介绍

  • 定制风险管理参数,如状态、优先级、风险方针 (严重性、概率和可接受性矩阵)等。

 

  • 风险分析、故障树分析FTA、失效模式与影响分析FMEA(表格)。

1)自定义故障树和Fmea表格

2)根据已定制的参数和数据生成报表进行风险分析(可导出Pdf文件)

  • 风险分析、故障树分析FTA、失效模式与影响分析FMEA(图表)。

  • 风险生命周期管理与版本控制。

  • 高级文档管理(需求、设计、测试文档管理)。

 

系统架构与部署图

  • 架构图。

  • 部署图

2014年诺怀软件公司河边烧烤

    最是一年春好处,绝胜烟柳满渝都。即是这一年中最美的时节,诺怀迎来了期盼已久的河边烧烤,既丰富员工的业余生活,提升加深员工内部之间的了解,舒缓公司人员的工作压力,也使这一良辰美景也不被辜负。

    

    3月22日,一个凉爽的早晨。三两个一行,四五个结伴,背上了准备好的帐篷,拿起早已购置好的食材,纷纷聚集到了江北大剧院前的河边,这意味着河边烧烤!已经开始了!河边烧烤是公司向来的保留节目,参与人数众多,反响良好,效果明显。这一次烧烤是由公司副总经理冉军带队,公司开发部经理刘宇翔组织,参与员工有数十人。

    

    你帮着搭棚,我帮着生火,他忙着鼓风,还有的忙着理菜,倒水。烧烤井然有序的进行着,这不能不说明大家都是烧烤的好手。 搭棚,支架,生火,烧烤,好不欢乐。在这喧闹的城市里,我们借此机会更加亲近了自然,更加贴近了生活,我们忘却了工作中的焦虑,我们互相了解的彼此,我们互相增进了情谊,我们也更加懂得了什么叫生活。

    

江风拂面,坐着松软的草地,闻着泥土的味道,那么你试过在这样的江边打麻将么?别样的经历使得我们又多了些情趣,也多了许多回忆。

    

    

2014诺怀公司河边烧烤

2014诺怀公司河边烧烤

最是一年春好处,绝胜烟柳满渝都。即是这一年中最美的时节,诺怀迎来了期盼已久的河边烧烤,既丰富员工的业余生活,提升加深员工内部之间的了解,舒缓公司人员的工作压力,使这一良辰美景也不被辜负。

于3月22日,一个凉爽的早晨。三两个一行,四五个结伴,背上了准备好的帐篷,拿起早已购置好的食材,纷纷聚集到了江北大剧院前的河边,这意味着河边烧烤!已经开始了!河边烧烤是公司向来的保留节目,参与人数众多,反响良好,效果明显。这一次烧烤是由公司副总经理冉军带队,公司开发部经理刘宇翔组织,参与员工有数十人。

江风拂面,坐着松软的草地,闻着泥土的味道,那么你试过在这样的江边打麻将么?别样的经历使得我们又多了些情趣,也多了许多回忆。

你帮着搭棚,我帮着生火,他忙着鼓风,还有的忙着理菜,倒水。烧烤井然有序的进行着,这不能不说明大家都是烧烤的好手。

诚信:八千美金的一堂课

诚信:八千美金的一堂课

   最近丢了个价值8000美金的项目,刚开始不到一周就被客户叫停,以前从未发生这样的事情,被上了非常昂贵的一堂课。为了让这堂成本8000美金的课程价值最大化,我觉得有必要把从中得到的经验教训分享出来,希望能警醒更多的项目经理,帮助更多的人少走弯路。

 

从某软件开发项目一期工作中学到的经验

从某软件开发项目一期工作中学到的经验

1. 明确范围

  1. 如果说要把整个项目(假设持续2个月,分为4次迭代)的范围,在一开始就明确下来,对我们、对客户都很困难,因而这个期望不太现实;更可行的办法是把范围的明确,也拆分成更小的单位,譬如按照每个迭代(每两周)来明确;我们双方只要保证,对这两周要提交的内容,有明确的共同认识即可;然后不断循环;
  2. 明确下来的范围,要有个Task List或者Plan来作为以后判断是否发生范围改变的依据;

2. 范围变更

  1. 如上所述,如果每两周一个迭代,每次迭代都有明确的Task List或Plan;那么在这个过程中,任何不在这个List和Plan中的任务,都可以视为需求变更、范围变化;
  2. 这种变更,需要在客户刚提出来时,就进行评估,明确告诉客户这个改变所需要的额外时间,必要时,要协商延后当前版本的提交日期Timeline;
  3. 同时,在平时要注意把这类小变更记录起来,免得以后说不清楚哪些是变更,哪些是初始的要求;

3. 提交版本

Laravel学习笔记(六)数据库填充

Laravel学习笔记(六)数据库填充

数据库驱动的应用程序往往需要预先填充数据到数据库,以便进行测试和演示。

 

什么是种子数据

 

种子数据就是必须要加载了应用程序才能正常运行的数据。大多数应用程序需要在开发、测试和生产中加载一些参考数据。

一般来说,这些数据不是用户创建的,尽管我们可能一次一次的修改它们;我们的数据会依赖这些数据。

种子数据通常是不变的。一般来说,在应用程序中不可被编辑。但是,要求上它是可以被更改的,如果被更改了,种子数据需要被重新加载到部署的应用程序中。

理想的解决方案是自动化的:你没必要去关心它。当你签出代码,启动你的应用,他就准备好了。它应该提供数据完整性:创建的记录应通过您的验证。它应该很容易更新种子数据。

 

数据库填充与迁移

 

在前几节我们讲到了数据迁移,数据迁移可以创建数据表的结构,其实,数据迁移也同样可以插入数据,需要创建一个新的迁移文件:

Laravel学习笔记(五)创建数据结构,更新数据结构

Laravel学习笔记(五)创建数据结构,更新数据结构

默认假设

 

所有的列在定义的时候都有默认的假设,你可以根据需要重写。

  • Laravel假定每个表都有一个数值型的主键(通常命名为”id”),确保新加入的每一行都是唯一的。Laravel只有在每个表都有数值型主键时才会正常运行。所以,对于每一个Laravel应用,都要确保定义的主键使用的是increments()方法。
  • 列在默认情况下为NOT NULL。

现在,让我们一行行分析结构生成器生成的authors表,下面是up()方法中的代码:

Laravel学习笔记(四)数据库迁移案例

Laravel学习笔记(四)数据库迁移案例

创建迁移

 

首先,让我们创建一个MySql数据库“Laravel_db”。接下来打开app/config目录下的database.php文件。请确保default键值是mysql:

页面

备案/许可证编号为:渝ICP备14000366号-1