论信息系统项目的进度管理研究.docx

上传人:b****6 文档编号:6780834 上传时间:2023-01-10 格式:DOCX 页数:12 大小:26.12KB
下载 相关 举报
论信息系统项目的进度管理研究.docx_第1页
第1页 / 共12页
论信息系统项目的进度管理研究.docx_第2页
第2页 / 共12页
论信息系统项目的进度管理研究.docx_第3页
第3页 / 共12页
论信息系统项目的进度管理研究.docx_第4页
第4页 / 共12页
论信息系统项目的进度管理研究.docx_第5页
第5页 / 共12页
点击查看更多>>
下载资源
资源描述

论信息系统项目的进度管理研究.docx

《论信息系统项目的进度管理研究.docx》由会员分享,可在线阅读,更多相关《论信息系统项目的进度管理研究.docx(12页珍藏版)》请在冰豆网上搜索。

论信息系统项目的进度管理研究.docx

论信息系统项目的进度管理研究

论信息系统项目的进度管理

[摘要]

2012年6月,本人作为项目经理开始参与某航空公司航空票务系统项目的开发,主要负责系统的组织规划实施开发与项目管理,该系统具有严格的安全,稳定,时实高效和可靠性能要求,该系统由票务管理系统和呼叫中心系统两部分组成,呼叫中心系统主要实现电话,传真和短信业务,票务管理系统是整个系统的核心,采用了struts+hibernate+spring主流WEB应用框架,实现了WEB应用服务器websphere与协作应用服务器lotusdomino的高度集成.

项目的成功很大程度上归功于本人在项目过程中各阶段对进度的有效管理和控制,本文以该项目为例,结合作者实践,讨论信息系统项目中的进度管理问题,主要通过在计划阶段做好工作量估算,在项目的全过程中有效管理和控制风险因素,在实施阶段进行进度跟踪和控制,必要是调整进度表等方法和策略来有效管理和控制项目的进度,目前该系统已正式投入运行,状况良好受到客户一致好评.

[正文]

2012年6月,2012年6月,本人作为项目经理开始参与某航空公司航空票务系统项目的开发,主要负责系统的组织规划实施开发与项目管理,当然还做一些编码工作,主要是公用基础代码和核心代码的编写与维护。

航空票务系统是将呼叫中心系统和票务管理系统有效的结合起来,采用先进的CTI技术和语音板卡技术,充分利用电话,短信,传真,因特网等信息化手段,解决航空公司的机票销售问题,规范了业务流程,强化了内部管理,与电子商务的完美结合,使应用系统功能更加完善,提高了整个航空业务的工作效率。

其中,票务管理系统包括:

客户管理,机票管理,票证管理,销售管理,财务结算,调度管理,远程营业部(代理商/分销商)管理,系统管理八大功能模块,并统一于服务器端软件模块。

呼叫中心系统由电话呼叫系统,短信分发系统,传真呼叫系统三部分组成。

票务管理系统是整个系统的核心,在本次开发中,本人把它视为整个项目的重点。

票务管理系统采用struts+hibernate+spring主流WEB应用框架,使用RUP软件工程方法,开发工具采用了WSAD5.0,WSAD5.0集成并扩展了Eclipse2.0的功能。

硬件配置方面,IBMRS/6000用于安装websphere5.0,DELL服务器用于安装DOMINOR6和ORACLE10g数据库,系统平台采用WINDOWSNT实现了WEB应用服务器与协作应用程序服务器LOTUSDOMINO的高度集成,并使用SINGLESIGNON(SSO)实现单点登陆。

总体架构思想:

用spring搭建整个框架,用hibernate取代原始的JDBC操作,并进行持久化管理,在spring中采用Bean来管理整个持久化层和访问层,与hibernate相连接进行数据库操作,视图层和控制器层通过STRUTS筐架实现,模型层是数据访问层DAO和hibernate的结合,数据库层功能使用ORACLE数据库实现。

在本系统中将订单数据的生成分析采用关系数据库实现,通过webspher架构实现业务逻辑处理,机票订单的生成和审核流程则由DOMINO进行驱动,将基于业务为主的J2EE服务系统和基于协作为主的DOMINO流程处理系统有效的结合起来,确保整个业务流程的有效运行和各种数据查询分析统计的有机结合。

由于考虑到寒假和春运期间将会是旅客的高峰期,客户要求系统必须在12月底前交付,项目开发周期为6个月,为此本人做了如下安排:

前4个月主要集中精力用于开发票务管理系统,后两个月主要完成票务管理系统和呼叫中心系统的集成以及项目收尾工作。

软件的进度管理是软件项目管理中一个非常重要的组成部分,进度管理的目的是通过执行项目进度管理过程和使用一些基本的项目管理工具和技术来控制项目的进度,保证项目如期完成。

项目组整体上把按进度和预算交付项目作为本人们最大的挑战,因此本人十分重视项目进度的管理和控制,在本项目中本人们借助项目管理软件MicrosoftProject2003来辅助进度和成本的计划与管理,本人们主要通过在计划阶段做好工作量估算,在项目的全过程中有效管理和控制风险因素,在实施阶段进行进度跟踪和控制,必要是调整进度表等方法和策略来有效管理和控制项目的进度。

1.计划阶段做好活动历时(工作量)估算.

项目需求分析阶段结束,《软件需求说明书》得到客户的正式签字确认后,本人们开始创建工作分解结构WBS和制定详细的进度表,本人们认为工作量的估算是制定进度表的基础,对于项目的进度管理十分关键,由于本人们对代码行(LOC)估算和功能点(FP)估算等估算方法研究不是很深入,工作量的估算还是主要采用基于公司项目历史绩效数据库和个人经验的估算方法,对于部分涉及流程的活动单位一般很难一次性把握其活动历时,事实上流程调试的工作量一般在页面基本功能(增加/删除/修改)的3倍工作量以上,例如销售模块—机票预定—顶单生成流程页面提交工作量为2日/人,而流程调试要涉及20多个角色和8条路径,对于把握不是很好的估算,本人们一般通过一个乐观估算A,一个悲观估算B,一个正常估算M三次估算后利用PERT公式[1(4*M+A+B)/6]计算后取整,每项活动本人都先确定具体的人员,然后需要对活动本身进行详细的分析,必要时查看公司项目历史绩效数据库,最后需要为各项活动建立依赖关系,明确各项活动的前置任务,活动的开始时间,结束时间。

总体上讲活动历时的估算工作量较大,本人花了数个工作日.

项目组流动率较底,在J2EE和STRUTS架构下的WEB应用开发已有一定的项目积累和团队合作基础,如项目组自行开发了功能完善的STRUTS-CONFIG..XML统一维护工具,实现了FormBean和AcationBean的方便管理,有大量可供复用的东西,如公用基础代码,权限管理模块等,这些也是本人们在工作量估算中应该考虑的因素.

2.项目全过程有效管理和控制风险因素.

项目中本人们对项目进行了必要的风险管理,以避免风险时间的发生导致进度的失控,公司项目管理部门提供了完整的项目风险管理计划模板和风险时间列表模板,为了让项目组在项目各个阶段保持良好的风险意识,本人尝试采用了“十大风险事项跟踪”,把项目中各主要的风险时间按照排名张贴在公告栏上,由于当时有部分未明晰的需求包括:

客户订票流程,调度管理部分需求,客户方面可能提出新的需求…需求范围界定不清,计划不充分,用户参与不足,缺乏领导支持,技术问题等成为本人们项目的主要风险事件,事实表明,这种做法非常有效。

特别是客户方面,本人定期把风险事件列表EMAIL给客户方负责人李某,为了能尽快落实未明晰的客户需求,本人与客户方负责人李某进行了面对面的沟通,通过一番利弊关系的陈述,达成了尽快明晰悬留部分需求的共识,需求问题很快得到解决,项目组整体信心十足,积极性和责任感增强,公司领导方面对项目组也表现出特别的关心,特别是公司胡总开始频繁的出现在项目组每周的进度评审会议上,他们也开始担心因对项目支持不够而导致项目失败。

3.实施阶段进行进度的跟踪和控制,必要时调整进度表。

实施阶段要进行进度的跟踪和控制,在确定项目开发计划时,本人们制定了详细的工作进度表,在确定每项任务时都确定了该任务的工作量,开始时间,结束时间,持续时间,同时要让每个小组成员都知道自己承担的任务时间表,根据自己的任务制定详细的工作计划.

工作日志是了解每个小组成员工作情况的最好方式,本人要求每个小组成员都要对自己的工作情况做日志,详细记录自己每天的工作。

在每周5下班前通过内网B/S项目管理信息系统PMIS提交《项目周报》,把各自本周内完成的任务进度情况和下周任务计划做出汇报,报告要严格按照百分比量化任务完成的情况,因为PMIS只提供具体的百分比选择,每个小组成员都要对自己的总结报告做出负责,本人把各项任务实际完成数据输入到项目进度计划中,Project自动完成甘特图的绘制,通过查看甘特图就可以交好的把握项目的总体进度绩效,随时了解项目进度,并确定是否调整下一阶段的进度计划,

在本项目中,为保证项目快速完成,在定义甘特图任务的依赖关系时,本人在没个任务的任务信息对话框中“前置任务”一栏中的“延阁时间”本人填入10%,也就是说当任务完成90%的时候就可以结束转入执行下一任务,因为本项目的所有人员几乎是全程参与,本人所以不是很担心,每个任务遗留的少量问题,在下一阶段每人去负责解决。

航空票务系统在2012年12月下旬正式上线,提前完成了项目,目前系统运行正常,受到客户和有关部门的一致好评,对项目的满意度较高。

项目成功很大程度归功与在项目各阶段的对进度和成本的有效管理和控制,没有进度管理,项目很难如期交付,对项目质量,进度,成本三大目标的实现有巨大的风险。

通过这次开发本人也发现了一些问题和不足,实际工作量与计划工作量偏差较大,看来还是受到缺乏经验数据或者经验数据不够精确的影响,所以在以后的工作中要展开有效的度量工作,为公司积累覆盖面广而精确的经验数据,还有就是团对成员的协作程度不高,未最大限度的发挥团队的凝聚力,在沟通方面本人还做的不够,在以后的项目中本人会不断的努力和改进。

 

信息化建设的项目管理计划、实施和控制

目前,电子政务、企业管理信息化等已成为信息化建设的热点。

这些以业务、数据流程信息化为主的建设项目相当复杂。

有数据表明,这类信息化建设项目在国内外成功的比例都不是很高。

正因如此,项目管理引起这个行业人士的普遍关注。

同样,也有数据表明,西方国家的一些企业采用项目管理后,项目成功的比例有显著提高。

作者根据十多年项目管理实践经验,以及研究、培训和咨询的知识积累写就这篇文章,相信对信息化工程项目的建设者会有帮助。

本文涉及信息化建设项目管理的内容包括:

项目经过的阶段;项目的计划、实施和控制;开发商对项目的管理;用户对项目的管理;项目的组织问题等。

一、信息化建设的几个阶段

信息化建设项目按时序划分,一般经过可行性研究、系统分析、系统设计、开发和测试、安装调试、运行维护6个阶段。

1、可行性研究阶段

可行性研究阶段段的主要任务是:

识别需求,对项目产品进行描述,确定分阶段实施的进度,从业务、技术、经济效益等方面进行可行性研究,形成可行性报告。

2、系统分析阶段

系统分析阶段的任务是:

对现行系统进行详细调查,分析业务流程,分析数据与数据流程,分析功能与数据之间的关系。

指出现行系统存在的问题和不足之处,确立新系统的基本目标和逻辑功能要求,最后提出分析处理方式和新系统的逻辑模型。

这个阶段也称为逻辑设计阶段。

逻辑设计解决系统“做什么”的问题。

因此,这个阶段是整个系统建设的关键阶段。

系统分析阶段的工作成果为“系统说明书”,这是系统建设的必备文件。

系统说明书既要准确又要通俗易懂,用户根据系统说明书可以了解未来系统的功能,判断是不是他们所要求的系统。

“系统说明书”一经通过,就是系统设计的依据,也是将来评价和验收系统的依据。

3、系统设计阶段

系统分析阶段的任务概括地讲,已解决了系统“做什么”的问题,系统设计阶段要回答的问题则是系统“怎么做”。

也就是说,根据系统说明书所规定的功能要求,考虑实际情况,具体设计实现逻辑模型的技术方案,即新系统的物理模型。

这个阶段也称为物理设计阶段。

这个阶段又可分成总体设计和详细设计两个阶段。

这个阶段的技术文档为“系统设计说明书”

4、开发和测试阶段

开发和测试阶段是按物理设计方案付诸系统实现的具体工作,包括开发与调试程序,采购硬件。

这个阶段的工作量很大。

在这个阶段,开发工作要重视文档的建设,测试工作需要写出测试分析报告,包括功能“测试分析报告”和“系统测试分析报告”。

5、安装调试阶段

本阶段的工作包括:

硬件设备与软件平台的安装调试,用户培训,数据文件转换,系统调试与转换等。

安装调试阶段实现现有系统被新系统所替换,需要用户许多部门的参与或配合。

为了使系统顺利转换,必须精心安排,合理组织,统筹调度和协调。

6、运行维护阶段

系统投入运行后,需要进行经常性维护和评价,记录系统运行的情况,根据一定的程序对系统进行必要的修改,评价系统的工作质量和经济效益。

上述6个阶段,构成信息化建设项目的全(整个)生命周期。

根据美国项目管理知识体系指南(PMBOK)的定义:

项目生命周期开始于项目启动(例如签订承包合同),结束于项目收尾(例如按合同验收)。

因此,信息化建设项目生命周期包括系统分析、系统设计、开发和测试、安装调试这4个阶段。

参见下图。

本文第二部分内容——项目计划、实施和控制,是基于项目生命周期来考虑的。

由于项目管理其实是一种方法论,因此可行性研究阶段的工作也可以按本文第二部分介绍的方法来处理。

二、项目计划、实施和控制

1、整体计划

整体计划的核心内容包括:

范围计划、时间计划、成本计划和组织计划。

1)范围计划

项目范围由工作分解结构(WBS)界定。

工作分解是一种以结果为导向的分析方法,用于分析项目所涉及的工作。

工作分解结构中所包含的全部工作构成了项目的整个范围。

工作分解结构是项目管理的一个非常基础性文件,因为它是计划和管理项目进度、成本和变更的基础。

项目管理专家认为,没有包含在WBS中的工作是不应该做的。

信息系统建设项目的工作分解结构,第一层通常是由前面所述的项目生命周期的4个阶段组成,第二层则包括每个阶段需要完成的可交付成果,第三层包括第二层可交付成果进一步分解的结果——所有细化的可交付成果,…。

工作分解结构层次的多少,以便于管理为划分标准。

相同的项目,不同的人会做出不同的工作分解结构来。

工作分解结构最底层的可交付成果叫做工作包。

2)时间计划

时间计划是确定工作分解结构中每个可交付成果的开始和结束时间。

时间计划通常用表格或甘特图、里程碑图来表示。

网络计划技术中的关键路径分析、并行工程等技术方法,可用来优化时间计划安排。

由于有项目管理软件的支持,生成时间计划图表,以及用网络计划技术优化时间安排都变得十分地容易。

3)成本计划

①制订资源计划资源计划确定了为完成项目中各活动所需要的资源(人、设备、材料)。

WBS是项目资源计划最基本的输入。

②成本估算成本估算是利用WBS、资源需求、资源单价、活动历时估计等成本要素,通过有关算法与工具(项目管理软件或电子表格)算出完成项目所需各种资源的成本估计值。

③成本预算成本预算是为了确定测量项目实际绩效的基准计划,而把整个成本估算分配到由WBS确定的各工作包上去。

成本预算和成本估算通常是同步进行的。

④成本基准计划成本基准计划是一种按时间分段的预算,可以用来测量和监控项目成本的绩效。

按时段把估算的成本叠加起来即可求得成本基准计划。

4)组织计划组织计划是,利用责任矩阵确定WBS中各工作项的责任单位;利用组织图确定报告关系。

但是,组织计划结果的具体形式受企事业单位的组织结构制约。

(关于项目的组织问题,在本文第五部分解析)。

2、项目实施

项目实施总是一个阶段接一个阶段地进行的,前一个阶段的结果为下一阶段提供输入。

信息化建设项目中,第一阶段的结果“系统说明书”,为第二阶段系统设计提供输入;第二阶段的结果“系统设计说明书”,为第三阶段的开发工作提供输入…。

每个阶段实施工作也都要首先做个计划,这个计划是为完成WBS工作包而采取的行动计划,包括:

基于各项活动的基准进度计划,角色、职责分配计划。

类似于前面讲到的组织计划,角色、职责分配也利用了责任矩阵这种方法,只不过在这里是把职责分配到个人。

项目子产品、产品实际上产生于项目实施过程中。

3、项目控制

项目控制包括绩效控制和变更控制

1)绩效控制

绩效控制目的是使工作结果与计划保持一致。

上面讲到,项目子产品、产品产生于项目实施过程,因此在这个过程中必须持续测量相对于项目基准计划的绩效,以便将实际绩效和基准计划进行比较,并以此为基础采取相应的纠正措施。

测量绩效的方法主要有两种,一是挣值测量,一是进度跟踪。

而且,这两种方法通常是结合起来使用。

①挣值测量

挣值测量在西方国家是测量绩效最常用的方法。

它综合了范围、成本和进度测量,帮助项目管理队伍评价项目绩效。

挣值测量涉及三个关键值:

l计划值(PV):

在规定时间内花费的获得批准的成本预算部分l实际成本(AC):

在规定时间内完成工作发生的实际成本l挣值(EV):

在规定时间内实际完成工作的价值不难看出上述三个关键值是三个关于时间的函数。

由于函数曲线呈S形状,所以通常称之为S曲线图。

这三个值提供了评价工作绩效的测量尺度。

包括l进度偏差(SV):

SV=EV-PVl成本偏差(CV):

CV=EV-ACl进度绩效指数(SPI):

SPI=EV/PVl成本绩效指数(CPI):

CPI=EV/AC

②进度跟踪

进度跟踪是输入实际工作进度,然后与基准进度计划比较,找出各项活动进度上存在的偏差。

利用项目管理软件进行进度跟踪极为方便、有效。

有了绩效测量结果,接着便是对偏差原因进行分析,进而根据分析结果决定纠正措施。

纠正措施没有什么新东西,都是平时习以为常的一些方法,比如对进度偏差有赶工、快速跟进(有些书上叫做并行工程)等措施。

理论著作上对这些方法的外延问题讲得很多,原因是在采取这些措施时,要考虑可能带来的许多问题,但这些都不是本文所要描述的内容了。

2)变更控制

变更控制的目的是维护绩效测量基准的完整性。

也就是说对基准计划的变更予以控制。

基准计划变更包括:

范围基准计划变更,时间基准计划变更和成本基准计划变更。

一般说来,只有项目范围变更才会影响测量基准。

但是,在某些情况下,进度延误或成本偏差非常严重,需要“重新确定基准计划”才能提供测量进度或成本执行情况的切合实际的数据。

基准计划变更是很慎重的事,应该:

l建立正式的变更程序l由变更控制领导小组负责批准或否决变更申请l定义正式文档变更的步骤

前面已经讲了,一般情况下只有范围变更才会影响测量基准。

而在信息化建设这样的高科技项目中,范围变更往往是因技术(功能、性能)要求的变化而起。

项目管理中讲到的配置管理,讲的是项目过程中的技术管理问题。

配置管理内容包括:

l识别工作项或系统的物理特征和功能特征l控制这些特征的任何变更l记录和报告这些变更l审计这些工作项和系统以证实其与需求相一致。

进行配置管理的目的是,项目过程中任何技术上的变更都要在范围变更中反映出来,并要得到有关各方的一致认可。

三、开发商对项目的管理

无疑,开发商是信息化建设项目中的主角。

对项目计划、实施和控制方面的工作,开发商都需要重视。

计划方面信息化建设项目往往带有较多的创新成份和不确定性,项目成果在出来之前,并不确切知道它会是什么样子。

因此,用户的需求和任务目标在整体计划中都不容易表述得十分具体,特别是对要实现的功能的规定往往有相当程度的灵活余地。

由于这些原因,整体计划中的工作范围、完成各项工作(由WBS定义)所需的时间和费用都较难以准确估计,所以整体计划工作必定是一个反复修改的过程。

实际工作中,人们往往因为“计划赶不上变化”而不愿做计划或只做一个大致的计划。

专家认为,项目管理的首要任务是计划!

计划!

还是计划!

先哲说:

“凡事预则立,不预则废”。

因此,尽管信息化建设项目中存在诸多变数,但细致的整体计划工作是必须要做的。

实施方面项目实施过程中,项目管理队伍必须协调、管理存在于项目中的各种技术和组织接口(界面)。

对于信息化建设项目,在系统设计与开发、测试阶段,对各种技术接口的管理极为重要。

而在系统分析与安装调试阶段,协调组织界面是项目管理队伍的重点工作。

实施过程中,项目队伍成员必须按计划做事!

比较本人们与西方人做事的习惯不难发现,西方人总是按文档(当然首推计划)规定去做事,而本人们做事主观随意性较大。

应该学习和接受西方人的做事习惯!

控制方面挣值测量作为一种项目监控工具在本人国使用得不多。

主要原因是本人们的项目管理者粗放式管理惯了,不习惯于做较精细的管理工作。

当然,在信息化建设这类高科技项目的管理工作中,对工作量完成百分比做比较准确的估计(这是使用挣值测量法的前提)有些困难,也是人们不愿使用这种工具的一个原因。

但笔者的体会是:

对工作量完成情况做个百分比估计,比不做要好;对于类似项目第二次做时,对许多工作完成情况的估计还是有较好的置信度的。

变更控制可能是信息化建设项目中最需要但又是最困难的事。

范围无止境的蔓延常常是让开发商苦不堪言。

控制范围蔓延涉及到许多方面的因素,这里不一一讨论了。

四、用户对项目的管理

在项目生命周期内,用户对项目的管理主要在进度控制、范围核实、质量把关等方面。

由于通常是采用固定总价合同把项目承包给开发商,因此对成本的控制不是用户主要考虑的问题(当然,非固定总价合同情况除外)。

而对范围、进度、质量等方面的管理是基于同样的标准的,即是说项目所有的技术和管理文档以及任何变更后的版本,都是开发商和用户达成一致意见后形成的。

在项目生命周期内,用户项目队伍重在参与。

在系统分析阶段,没有用户项目队伍的重要参与就不可能产生好的“系统说明书”,也就不可能有好的项目成果。

在安装调试阶段,没有用户项目管理队伍的协调、调度,转换工作就可能陷于混乱状态。

在系统设计与开发、测试阶段,用户应着眼于未来的运行维护,派技术人员全程参与工作,其必要性有二:

一是未来系统运行维护的重要责任,要求技术人员必须深度了解系统的技术情况;一是系统将来必然会不断升级,要求技术人员能够为升级方案做重要贡献。

系统维护人员是了解公司业务的技术专家,不可等同于一般维护人员,也不同于一般网管人员,这点应引起用户的重视。

有些情况下,用户可以雇佣项目监理来协助自己完成项目工作。

特别是项目启动前的可行性论证阶段,用户对怎样实现信息化或什么样的信息化解决方案对自己是实用的,可能并不很清楚,这时购买项目监理或咨询公司的服务是很有效的。

在项目生命周期内的各阶段,从职能上说,项目监理与项目管理是差不多的。

五、项目的组织问题

对于信息化建设项目,多数开发商、用户单位的内部组织都是传统型(职能型)的,即组织的结构是按职能划分的。

在这种结构体系里,对项目的组织往往是非正式的(用户方面更是如此)。

所谓的项目经理一般也就是部门内部一个领头干活的人。

而另一个极端的现象是,当认为某个项目很重要时,就可能由高层人物来负责这个项目。

在一些媒体甚至某些高等教育教材中,本人们都能看到有这样的说法:

信息化很重要,信息化建设工作应该由一把手亲自抓。

对信息化建设的项目管理工作,由一个领头干活的人负责显然不行,但由一把手亲自抓的观点,也非常值得商榷。

本文开头提过,信息建设工作是很复杂的事情。

“复杂”体现在两个方面:

一是把业务流程、规范、标准等搞清楚,并据此确定要建一个什么样的系统很复杂;一是技术实现上复杂。

负责信息化建设的项目经理,应有这两方面的知识与经验。

从开发商方面看,该项目经理应有很好的技术背景,同时要熟悉所服务行业的业务情况;从用户方面看,这个项目经理应非常清楚本单位的业务流程,同时对技术有一定的掌握。

一把手是企业战略层面上的管理者,很难要求他管好信息化建设这样具体而复杂的项目。

保证信息化建设项目的顺利进行,应从组织结构上着手。

矩阵型组织(参见下图)是西方国家许多企业采用的一种项目组织类型

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > PPT模板 > 卡通动漫

copyright@ 2008-2022 冰豆网网站版权所有

经营许可证编号:鄂ICP备2022015515号-1