目前我国物业管理信息系统的开发方法是什么？？
发布网友
发布时间：2022-03-18 00:56
共2个回答
热心网友
时间：2022-03-18 02:25
目前我国物业管理信息系统的主要开发方式是什么？
物业管理行业是在传统的房屋管理基础上发展而来的新兴行业,近年来获得了长足的发展.随着人们生活水平的提高、住宅多样化的不断发展,物业管理作为一门科学的内涵已经超出了传统定性描述和评价的范畴.发展成为集多种手段对物业进行综合管理,并能对有关物业的资料进行归类总结、整理分析、定性与定量评价、发展预测等.物业管理在现在生活中作用已经被广泛认可.采用现代化计算机技术进行物业管理是一种行之有效的解决方法。
信息系统（Information System，IS）是由一组相互关联的部件结合而成，用于收集、处理、存储、传输、检索和发布信息，以促进和提高企业或组织的管理水平和业务决策水平。信息系统包括输入、处理、控制、输出、反馈等基本组成部分。它是一个由人和机共同组成的系统。
管理信息系统在《中国企业管理百科全书》的定义是：“一个由人、计算机等组成的能进行信息收集、传递、存储、加工、维护和使用的系统。管理信息系统能实测企业的各种运行情况；利用过去的数据预测未来；从企业全局出发辅助企业进行决策；利用信息控制企业行为；帮助企业实现其规划目标”。 从本质上说，凡是采用计算机进行辅助管理和决策的信息系统都是管理信息系统。
物业管理信息系统是一套用于小区物业管理业务的综合系统.他利用计算机网络的各种优势,根据物业管理原则,物业管理收费标准等,对物业小区的各种服务进行统一、规范的管理,并对物业小区的各种费用进行计、收费处理。
目前国内大多数物业管理公司计算机应用水平还处于单项数据处理,模仿手工管理方式,多用于简单的事务性工作.物业管理信息系统的应用水平能充分体现物业管理的水平.物业管理信息系统除了解决物业管理的一般问题，包括实现计算机对楼房、业主、服务、工程、装修、投诉、水电气、财务收费、汇总、统计、查询、报表等物业工作全方位的管理外,还要包括协议管理,服务管理、数据集中处理和*管理等功能。
管理信息系统的开发方法有生命周期法、原型法、计算机辅助软件工程开发方法、结构化系统开发方法和面向对象的开发方法。
生命周期法（Life Cycle Method）是20世纪60年代发展起来的一种应用广泛且比较成熟的管理系统开发方法，它的基本思想是将系统的开发工作从开始到结束划分为若干个阶段，每个阶段都有明确的任务，而系统开发出来后，并不意味着生命周期的结束，而意味着根据组织的需要对系统的修改和重建的开始。结构分析、结构设计，结构程序设计（简称SA—SD—SP方法）用瀑布模型来模拟。各阶段的工作自顶向下从抽象到具体顺序进行。瀑布模型意味着在生命周期各阶段间存在着严格的顺序且相互依存。瀑布模型是早期MIS设计的主要手段。
原型法(Prototyping Method)是20世纪80年代发展起来的，旨在改变生命周期法的缺点的一种系统开发方法，该法的开发思路是首先根据用户的要求，由用户和开发者共同确定系统的基本要求和主要功能，利用系统快速生成工具，建立一个系统模型，再在此基础上与用户交流，将模型不断补充、修改、完善，如此反复，最终直至用户和开发者都比较满意为止，从而形成一个相对稳定、较为理想的管理信息系统。
计算机辅助软件工程开发方法（Computer Aided Software Engineering，CASE）是指由各种计算机辅助软件和工具组成的大型综合性软件开发环境，随着各种工具及软件技术的发展、完善和不断集成，逐步由单纯的辅助开发工具环境转化为一种相对的方法。是软件工具与开发方法的结合体。解决系统开发问题的基本思想是：结合系统开发的各种具体方法，在完成对目标系统的规划和详细调查后，如果系统开发过程中的每步都相对且一定程度上彼此形成对应关系，则整个系统开发就可以应用专门的软件开发工具和集成开发环境来实现。
结构化系统开发方法（Structured System Development Methodologies）是指把整个系统开发过程分成若干阶段，每个阶段进行若干活动，每项活动应用系统标准、规范、方法和技术，完成一个或多个任务，形成符合给定规范的软件产品。结构化生命周期法是最常用的管理信息系统开发方法，分为四个步骤，即系统调研分析、数据库设计实现、界面设计实现和系统功能设计实现。
面向对象（Object Oriented）的开发方法于20世纪80年代开始兴起的，是一种基于问题对象的自底向上的一种系统开发方法，这种方法的特点是以对象为基础，对象是分析问题和解决问题的核心。面向对象（Object Oriented）的开发方法也称快速原型法是近年来针对（SA—SD—SP）的缺陷提出的设计新途径，是适应当前计算机技术的进步及对软件需求的极大增长而出现的。是一种快速、灵活、交互式的软件开发方法学。其核心是用交互的、快速建立起来的原型取代了形式的、僵硬的（不易修改的）大快的规格说明，用户通过在计算机上实际运行和试用原型而向开发者提供真实的反馈意见。快速原型法的实现基础之一是可视化的*语言的出现。两种方法的结合,使用面向对象方法开发MIS时，工作重点在生命周期中的分析阶段。分析阶段得到的各种对象模型也适用于设计阶段和实现阶段。实践证明两种方法的结合是一种切实可行的有效方法。
MIS系统开发过程
一个MIS系统的开发过程一般包括如下几个步骤：
（1）需求分析：需求分析主要是了解用户的需求。需求了解得越详细，程序的后期开发与维护费用就会越少。一般的开发团队中，需求分析都是由资历较深的系统分析员或项目经理担当，可见它的重要性。需求分析制订好后，需要反复修改。将最后的结果交给用户审定，确认无误后，由系统分析员完成需求分析文档，再开始下一步工作。
（2）概要设计：概要设计紧跟在需求分析之后。用户需求明确后，将得到的数据分析后，开始构建数据库的逻辑结构。此时，数据库中的表格还未成形，通过各种分析工具（如PowerDesigner等）画出数据流图，最后就可抽象出数据库的具体表结构。这时由系统分析人员反复审核。确认所有的需求都考虑在内，没有遗漏后，就可以开始制订概要设计文档。概要设计文档形成后，整个程序的逻辑框架也就形成了。
（3）详细设计：概要设计完成后，根据设计中制订的业务模块。就可以进行详细分析设计了。详细设计就是将各个业务模块的窗口全部建好，各个窗口控件的处理代码全部用语言表达出。所以详细设计是整个系统中最繁琐的环节。详细设计完成后，整个程序就确定了，再由编程人员根据详细设计文档将代码完成。整个开发工作就宣告结束。
1) 程序编码：程序编码相对于其他环节来说比较简单，程序员只需要根据详细分析文档写程序编码，保证代码没有错误即可。程序编码需要注意的是整个程序书写中命名的规范化与编程风格的规范化，这需要较长时间的培养来形成。需要在不断的实践中形成自己独特的风格。总的来说，不要过分地追求复杂的算法，因为那可能会导致后期维护人员无法读懂你的代码而造成维护的困难。
（4）测试：程序编码完成后，就需要测试。测试有几种类型，主要是测试代码有无逻辑错误以及在加载数据环境下程序的稳定性问题。测试工作中发现的错误应及时改正，然后将它记录到测试文档中。
（5）打包：测试完成，确认无误后。程序就可以打包发行了。打包一般使用工具如PWISE等。
管理信息系统的开发
管理信息系统的开发是一个较为复杂的系统工程，它涉及到计算机处理技术、系统理论、组织结构、管理功能、管理知识、认识规律以及工程化方法等方面的问题。尽管系统开发方法有很多种，但遗憾的是至今尚未形成一套完整的、能为所有系统开发人员所接受的理论以及由这种理论所支持的工具和方法。
管理信息系统的开发方式
自主开发：
通过自行开发可以得到适合本单位需要的、满意的系统，在系统开发过程中还可以培养自己的技术力量。缺点是开发周期往往较长。自行开发需要强有力的领导，有足够的技术力量，需进行一定的调研和咨询。
自主开发适合于有较强的管理信息系统分析与设计队伍和程序设计人员、系统维护使用队伍的组织和单位，如高等院校、研究所、计算机公司、等单位。开发的优点是开发费用少，实现开发后的系统能够适应本单位的需求且满意度较高，系统维护方便。缺点是由于不是专业开发队伍，容易受计算机业务工作的*，系统优化不够，开发水平较低。
委托开发：
委托开发从用户角度最省事，但必须配备精通业务的管理人员参加，经常检查和督促。这种开发方式一般费用较高，系统维护比较困难。
委托开发方式适合于使用单位无管理信息系统分析、设计及软件开发人员或开发队伍力量较弱、但资金较为充足的组织和单位。
委托开发的方式的优点是省时、省事，系统的技术水平较高。缺点是费用高、系统维护需要开发单位的长期支持。此种方式需要使用单位的业务骨干参与系统的论证工作，开发过程中，需要开发单位和使用单位双方及时沟通，进行协调和检查。
合作开发：
合作开发对于培养自己的技术力量最有利，系统维护也比较方便。条件是企业组织有一定的系统分析和设计力量，合作双方要精密协作和配合。
合作开发方式适合于使用单位有一定的管理信息系统分析、设计及软件开发人员，但开发队伍力量较弱，希望通过管理信息系统的开发建立完善和提高自己的技术队伍，便于系统维护工作的单位。双方共同开发成果，实际上是一种半委托性质的开发工作。优点是相对于委托开发方式比较节约资金，可以培养、增强使用单位的技术力量，便于系统维护工作，系统的技术水平较高。缺点是双方在合作中沟通易出现问题，需要双方及时达成共识，进行协调和检查。
购买现成软件：
目前，软件的开发正在向专业化方向发展，一些专门从事管理信息系统开发的公司已经开发出一批使用方便、功能强大的专项业务管理信息系统软件。为了避免重复劳动，提高系统开发的经济效益，也可以购买现成的适合于本单位业务的管理信息系统软件，如企业管理信息系统、教育管理信息系统、财务管理系统、进销存管理系统等等。此方式的优点是节省时间的费用、系统技术水平高。缺点是通用软件专用性较差，跟本单位的实际工作需要可能有一定的差距，有时可能需要做二次开发工作。因此，在选择通用软件时，不可只看开发商的宣传，要经过多方详尽的考查后再作决定。购买现成软件最省事。但很难买到完全适合本单位的软件。购买现成软件包需要有较强的鉴别能力。这种方式谈不上什么系统维护。
以上四种开发方式中，合作开发方式最适合我国目前的情况。
各种开发方式的比较
以上介绍的四种开发方式有各自的长处和短处，需要根据使用单位的实际情况进行选择，也可综合运用各种开发方式。
方式
特点比较 开发 委托开发 合作开发 购买现成软件
分析和设计能力的要求 较高 一般 逐渐培养 较低
编程能力的要求 较高 不需要 需要 较低
系统维护的难易程度 容易 较困难 较容易 较困难
开发费用 少 多 较少 较少
说明 开发时间较长，系统适合本单位，培养了自己的开发人员。 省事，开发费用高。 开发出的系统便于维护。 最省事，但不一定完全适合本单位。
热心网友
时间：2022-03-18 03:43
上海殷行物业管理公司的传统业务是国有公房的租赁管理。随着国家房改*的推行，一些租户开始买房，私房管理逐渐成为公司的核心业务。该公司的软件系统开发有两大难题：一、业务规则复杂，特别是历史遗留的各项*法规，许多公司员工也难以理解清楚；二、系统必须能随着公司业务重心从公房租赁到私房管理的转移过程和各项*的变化而进化，这需要一个稳定的软件构架（ Software Architecture ）。传统的瀑布式软件开发过程不能满足该系统在需求和系统进化方面的要求。
由于殷行物业管理系统需求获取的难度和对软件构架的要求，我们选择采用 RUP 来开发该系统，并最终开发出了令人满意的产品。
2 统一过程的特点
RUP 是一个通用的软件开发过程框架，它可通过裁剪和扩充应用于各种不同类型的软件系统、各种不同的应用领域、各种不同的组织和各种不同的项目规模。 RUP 具有以下三个重要特征：用例驱动、以构架为中心和迭代增量开发。
2.1 用例驱动的过程
首先，在业务建模（ Business Modeling ）工作流中，业务流程（ Business Process ）被定义为数个不同的业务用例（ Business Use Case ），其中每个业务用例都代表业务中某个特定的工作流程，业务主角（ Business Actor ）（客户、合作伙伴等）通过业务用例中的动作序列获得组织的服务。所有的业务用例和业务主角构成了组织的业务用例模型（ Business Use － Case Model ）。
在需求（ Requirements ）工作流中，根据业务用例模型确定待开发系统支持业务用例实现（ Business Use － Case Realization ）的功能并限定系统的边界，这些功能用系统用例（ System Use Case ）来描述，用例主角为组织内部的业务工人（员工、直接使用系统的客户等）。所有的系统用例和用例主角构成了系统用例模型（ System Use － Case Model ），它描述了系统的功能需求。
在分析设计工作流（ Analysis & Design ）中，开发人员使用系统用例模型作为输入，对每个系统用例进行用例分析（ Use Case Analysis ）和用例设计（ Use Case Design ），得到相应的用例实现（ Use Case Realization ）。用例实现在设计模型（ Design Model ）中提供了一种结构，用于组织与用例有关但却属于设计模型的工件。这些相关工件包括协作图（ Collaboration Diagram ）和序列图（ Sequence Diagram ），这些图使用协作对象说明用例行为。最终这些协作对象可以归纳为系统要开发的分析类和设计类。
在实施 (Implementation) 工作流中，将设计模型作为输入，将设计类实现为组件，创建实施模型（ Implementation Model ）。
在测试工作流期间，根据用例的功能描述编写测试用例（ Test Case ），验证系统是否实现了的用例的功能。因此，用例将各个工作流整合成一个流――确定用例、分析用例、设计用例、实现用例、根据用例编写测试用例来验证系统设计。
2.2 以构架为中心的过程
在 RUP 中，软件系统的构架是指系统重要组件的组织或结构，这些重要组件通过接口与那些由不断减小的组件与接口所构成的组件进行交互。构架具有以下作用：
1 ）理解系统 RUP 使用 UML 可视化建模系统的构架，并以构架为中心进行开发，这使得开发人员、管理人员及其他相关人员能够详细理解所需要做的工作，以利于他们参与系统的开发。
2 ）组织开发 构架设计师通过将系统划分为带有明确定义接口的子系统，并让开发小组负责每个子系统，可以显著减少开发组之间交流的工作量，而且接口双方的软件可地进化。
3 ）鼓励重用 好的构架为开发人员提供了可以在其上开展工作的稳定的骨架，它有助于开发人员知道在哪里能有效地找到可重用的元素以及发现合适的可重用的组件。
4 ）进化系统 一个具有稳定的构架的系统在分析和设计时就考虑到系统进化的需求，从而具有一定的容变能力，系统可以适度地进化。
2.3 迭代和增量开发
迭代（ Iteration ）是指带有已建立基准（ Base Line ）的计划和评估准则的独特活动序列，迭代生成系统的内部或外部发布版（ Release ）。增量（ Increment ）是指在后续迭代结束后，两个发布版本之间存在的差异（差值）。在 RUP 中，软件的生命周期是由一系列迭代组成的，这些迭代都是由软件项目分解成的许多袖珍项目（ mini-project ）。每个迭代都产生以内部版本形式交付的实际结果，其中每个内部版本会增加一个增量并表明所关注的风险得以降低。这些版本可以展示给客户，从而获得有价值的反馈以确认工作成果。早期阶段的迭代主要是关注确定项目的范围，消除关键风险和建立系统构架基准。后期迭代则不断增加增量结果，直至得到一个可对外发布的产品。迭代有助于管理层规划、组织、监控和控制项目。
迭代和增量开发具有以下的一些优点：（ 1 ）允许变更需求；（ 2 ）允许持续的集成；（ 3 ）及早降低风险；（ 4 ）有助于组织学习和提高；（ 5 ）提高复用性；（ 6 ）生成性能更强壮的产品。
3 殷行物业管理系统的开发过程
该系统主要包括以下几个模块：
• 小区管理 公司经营业务所涉及的小区的信息管理。
• 房屋管理 公司所管理的房屋的资料的管理和维护。
• 房屋租赁管理 实现房屋租赁的功能。
• 租金管理 实现租户租金的收取和各项报表的编制功能。
• 私房管理费管理 实现私房用户的管理费管理。
• 系统维护 系统的用户、安全和公共信息的管理。
我们首先和用户一起对该公司的业务进行建模，建立业务用例模型，然后再一起分析这些业务用例的实现，明确用户对将要开发系统的功能需求。通过分析，我们获得了“接收房屋”、“出租可租房”、“建租户账”、“收取租金“、“租金调整”和“租金减免”
等对于决定系统构架具有重要作用的核心系统用例。因为租金调整和减免方面的业务规则非常复杂而且易变，我们决定采用 EJB 组件构架，将业务规则封装在企业 JavaBeans 中，以利用 EJB 构架在系统维护和进化方面的优势。图 1 是该系统构架的部署视图（ Deployment View ）。
由于 RUP 的特征和 EJB 技术的采用，我们在开发过程中很好地克服了需求变更和更改设计方面的难题，在开发的后期没有出现什么重大的错误设计和返工。
4 房屋租赁管理子系统的开发实例
限于篇幅，我们以房屋租赁管理子系统在第一次生命周期中的开发过程来阐述 RUP 的应用方法，这里给出的只是一个基本的过程框架。
4.1 业务建模
业务建模的目的在于了解目标组织的结构、机制、当前存在的问题、改进的可能性，并确保客户、最终用户和开发人员就目标组织达成共识，最后还要导出支持目标组织所需的系统需求。
下面是房屋租赁子系统业务用例模型中的“客户租房“业务用例（这里我借鉴了 Cockburn 的用例思想）：
用例名称 (Use case) ：客户租房
首要主角 (Primary Actor) ：客户
范围 (Scope) ：殷行物业公司
层次 (Level) ：概要目标
前提条件 (Preconditions) ：当前有空的出租房
触发条件 (Trigger) ：客户申请租房
成功保证 (Success Guarantees) ：客户顺利地租到房屋
最低保证 (Minimal Guarantees) ：客户取消租房
基本流 (Basic Flow) ：
• 客户向公司提出租房申请，并提供相关材料和客户租房条件。
• 业务员审核客户材料，并根据客户租房条件检索可租房 。
• 客户选定中意的可租房。
• 业务员出租选中的可租房 。
• 计账员为客户建立租金账户 。
备选流 (Alternative Flow) ：
// … （略）
2b 、未找到符合客户租房要求的房屋 3a 、客户不满意所选的房屋
a 、客户重新提出租房 条件
a1 、业务员根据客户租房条件检索可租房屋 。
这个过程可重复多次，直到客户接受房屋或取消租房。
b 、客户不再租房，流程终止。
业务用例实现由业务对象模型来描述，它是对业务工人和业务实体之间应该如何联系和协作以执行业务的一种抽象。 系统分析员使用 该模型来确定系统主角和系统用例。
4.2 需求
分析业务用例模型中“客户租房“业务用例的实现，可以确定 业务员 和计账员等业务工人 (Business Worker) 对系统的功能需求，从而得到三个系统用例，如以上斜体部分所示。采用类似方法获得的所有系统用例构成了系统的功能需求。 这时，业务用例中的业务工人映射为系统用例的主角。下面是“出租可租房”系统用例的事件流：
用例名称 (Use Case) ：出租可租房屋
首要主角 (Primary Actor)：业务员
范围 (Scope) ：殷行物业管理信息系统
层次 (Level)：用户目标
前提条件 (Preconditions)：客户选定可租房
触发条件 (Trigger)：业务员开始租房
成功保证 (Success Guarantees)：待租房屋顺利租出
最低保证 (Minimal Guarantees) ：（无）
基本流 (Basic Flow) ：
• 业务员输入租户信息。
• 业务员输入租赁凭证资料。
• 系统 添加新租户 。
• 系统将 可租房转换为已租房 。
• 系统 创建租赁凭证 。
备选流 (Alternative Flow) ：
//…. （略 去了备选流中的用例 ）
4.3 分析设计
分析设计工作流的主要目的是将需求转化为系统的设计以及开发出健壮的构架。涉及到的角色有构架设计师、设计师和数据库设计师等。构架设计师的主要工作是构架分析、确定设计机制等。设计师的主要工作是用例分析、用例设计、类设计和子系统设计等。数据库设计师设计系统的数据模型。
对“ 出租可租房屋 “系统用例进行用例分析和设计，得到其用例实现的协作图（图 2 ）。
从图中可得到如下的设计类：实体类（ RenterWithouAccount －未建账租户、 RentingCard －租赁凭证、 RentedHouse －已租房、 RentableHouse －可租房、 RentableHouseSet －可租房集合）、控制类（ RentingManager －租赁管理器、 TransactionManager －事务管理器）、边界类（ RentingForm －租赁窗体、 RentingCardDlg －租赁凭证资料对话框）。
根据实体类之间的关系，可以得出关于房屋租赁的局部数据模型（图 3 ）。
4.4 实施
在实施阶段，将分析设计阶段产生的设计模型作为输入，探讨如何用源代码、脚本、二进制代码、可执行体等组件来实现系统。由于我们采用了 EJB 技术，因此在 Rational Rose 中，我们将以上的实体类映射成了 EntityBean 类，控制类映射为 SessionBean 类，而边界类则映射为客户端的 JavaBean 。最终， RenterWithouAccount 、 RentingCard 、 RentingManager 等企业 Bean 类被部署在 JBoss 应用服务器中。
至此，房屋租赁管理子系统的第一个版本已经产生，用户可以试用该系统以提出改进意见和新的需求，并在下一轮迭代中加以实现。实际上，我们只经过了四轮迭代，用户便接受了该子系统。
5 结束语
由于 RUP 是一个庞大复杂的软件开发过程框架，在实际开发过程中，我们对 RUP 进行了适当的裁剪以适应系统的规模和特点，省去了开发大规模系统所需的活动和工件。 CASE 工具我们主要选用了 Rational Rose 、 ClearQuest 、 Soda 和 RequistePro ，开发工具选用了 JBuilder5 ，数据库选用了 SQLServer7 ，应用服务器选用了 JBoss ， web 服务器选择了 Tomcat 。最终我们以较低的成本，在客户要求的进度内开发出了令人满意的物业管理信息系统。
