This chapter reviews about the research in property management sector in Malaysia, the extent of property management being adopted and the need of integrated property management systems to improve property management as a whole. In addition, this chapter also reviews about the research in which software development methodology that best suits the development of Web-based Property Management System.
2.1 Property Management Practices in Malaysia
At present, there is no specific leading body for property management in Malaysia. However, the practice of property management in the property area has been widely adopted in recent years. The non-existence of a specific organization to provide guidelines and control on the quality level as well as to assess the performance of property management practice is the reason why evaluations on this field is difficult to analyze. Automated computerized system as an integrated approach is the closest to define the adoption of property management. Listed in Table 2.1 is the type of buildings adopting and practicing property management.
Category
Property
System Used
Examples
1
Service / Amenities
Hospital
THIS (Total Hospital Integrated System)
Selayang Hospital, Putrajaya Hospital
Warehouse
CAFM (Computerized Aided Facilities Management)
KLIA Cargo, MIMOS
Hotels
BUS (Building Automation System)
Pan Pacific KLIA, Le Meridian
2
Business
High-Rise Office Tower
BUS (Building Automation System)
Petronas Twin Tower, Central Plaza, Telekom Tower
3
Commercial
Shopping Complex
BUS (Building Automation System)
KLCC, KL Sentral
4
Residential
Condominium
Smart Home System
KL Sentral, Cyberjaya
Table 2.1: List of properties adopting integrated property management.
Property management in Malaysia is perceived only when building is automatically controlled by computerized software. Definition of property management is poorly understood and thus, it is not being practiced in an appropriate way.
In broad use, record or data tracking is poorly or hardly compiled, thus resulting in a poor record of data management, contributing to negative future planning or maintenance works and services management. The practice of property management in Malaysia at present is undertaken by real estate firms. This is due to the fact that buildings such as high rise office towers are managed by property consultants. Property management companies typically provide property and building management services as well as simple operations and maintenance. Their work has traditionally been blue-collar intensive with limited training for operatives. In addition, most companies manage a limited range and number of properties related to their core employer. Hence, with the drive towards a more complex and sophisticated built assets and alignment within the property management sector has come about.
Recently there has been a number of important ground-breaking property management studies dealing with various topics conducted in Malaysia. This development shows some improvement in defining the importance of adopting property management in Malaysia. A number of research projects are also being carried out by academic institutions with close collaboration of academic and property management practitioners in other countries, thus demonstrating a certain degree of synergy.
2.2 Development of Property Management in Malaysia
2.2.1 Problems of Property Management Implementation
In broad term, the main problem of property management adopted and implemented in Malaysia concerns the organizational response to the needs of property management in the property industry. It should be noted that the beneficiaries of any facility provided in a property require direct response and participation of the community that the facility is provided for. This can be achieved through community participation, which according to Cernea (1985) is defined as "an active process by which beneficiary client groups influence the direction and execution of a development project with a view to enhancing their well-being in terms of income, personal growth, self-reliance or other values they cherish".
In short, the problems of property management implementation in Malaysia are summarized as follows, namely:
Lack of participation from the whole organization due to lack of understanding on the importance of providing a comprehensive property management in order to achieve the objectives of this concept.
Lack of technical knowledge and expertise on handling the problems often occur, thus the need to design a flexible property management planning, the need to manipulate the advantages and benefits of using property management and the need to provide immediate responses for arising problems.
The lack of proper property management guidelines and requirements in Malaysia that can be used to measure the quality and performance of property management practices by company as well as to standardize the practice and implementation.
Non-existence of specific property management association to monitor the progress of property management being practiced by consultants in Malaysia.
2.2.2 Changes
The changes that may boost the implementation of the property management can be summarized as follows:
The changes in the social perception in which a well-maintained building is much more sought after by potential tenants or buyers. This has resulted in a need to plan and to design suitable management approach that may suit the needs of the buyers/tenants.
The changes in the services offered for new development where integrated system is much preferred by potential tenants/buyers. As mentioned earlier, automated building services required computerized automation and this supports the development of property management in building management.
There has been constant improvement in the technology sector. The progressive changes in technology has seen more and more new technologies being made available in Malaysia and the implementation or adoption of these new technologies often require advancement in management system and IT system.
2.3 Challenges
The real challenges for property management to be thoroughly implemented in buildings lies in the following areas:
The non-existence of standards that can be used to measure the quality level and performance of both traditional and integrated property management applied by the bulding/property management. The current situation in Malaysia confirms that practices vary from one organization to another, depending on the services provided or applied for the buildings. The slow pace of regulating appropriate property management standard or regulation is another factor that requires immediate response and action.
Lack of local expertise to provide immediate response to failure of service as well as lack of property management practitioners in the local market that can provide advice or assistance in the implementation of property management. Property skills are vital, but the local industry remains conservative and protective. A change in the mindset is needed and therefore more proactive campaigns are needed to change the perception of the professionals involved in the construction and property markets.
The implementation of property management is considered late for some properties as at present, there are many aging buildings with high deterioration level. Property management may help in standardizing future maintenance allocation required but this, however, may not contribute to minimization of maintenance cost if the building services are in poor condition due to improper maintenance carried out in the past.
Malaysia is still lagging behind in the aspect of software development specific to property management and adoption of integrated property management may require high initial cost, unless the computerized programs can be found locally in the market. Most building management claims that their profits are not as much as expected and in order to adopt this integrated system, funding support is required.
2.4 The Rational Unified Process
The Rational Unified Process - or RUP in short - was developed by Philippe Kruchten, Ivar Jacobsen and others at Rational Corporation to complement UML (Unified Modelling Language), an industry-standard software modeling method.
RUP is an iterative approach for object-oriented systems, and it strongly embraces use cases for modeling requirements and building the foundation for a system. RUP is inclined towards object-oriented development. It does not implicitly rule out other methods, although the proposed modeling method, UML, is particularly suited for OO development (Jacobsen et al., 1994).
2.4.1 Process
The lifespan of a RUP project is divided into four phases named Inception, Elaboration, Construction and Transition. These phases are split into iterations, each having the purpose of producing a demonstrable piece of software. The duration of an iteration may vary from two weeks or less up to six months.
Figure 2.1: RUP phases.
In the inception phase, the life-cycle objectives of the project are stated so that the needs of every stakeholder are considered. This entails establishing, e.g. the scope and boundary conditions, and acceptance criteria of the project. Critical use cases are identified. Candidate architectures for the system are devised, and the schedule and cost are estimated for the entire project. In addition, estimates are made for the following elaboration phase.
The elaboration phase is where the foundation of software architecture is laid. The problem domain is analyzed, bearing in mind the entire system that is being built. The project plan is defined in this phase - if the decision is made to proceed to the next phases at all. In order to be able to make that decision, RUP assumes that the elaboration phase will yield a sufficiently solid architecture along with sufficiently stable requirements and plans. The process, infrastructure and development environment are described in detail. As RUP emphasizes tool automation, the support for it is also established in the elaboration phase. After the phase, most use cases and all actors have been identified and described, the software architecture described, and an executable prototype of the architecture created. At the end of the elaboration phase, an analysis is made to determine the realization of risks, the stability of the vision of what the product is to become, the stability of the architecture, and the expenditure of resources versus what was initially planned.
In the construction phase, all remaining components and application features are developed and integrated into the product, and tested. RUP considers the construction phase a manufacturing process, where emphasis is put on managing resources and controlling costs, schedules, and quality. The results of the construction phase are created as rapidly as possible, while still achieving adequate quality. One or more releases are done during the construction phase, before proceeding to the final, transition phase.
The transition phase is entered, when the software product is mature enough to be released to the user community. Based on user response, subsequent releases are made to correct any outstanding problems, or to finish any postponed features. The transition phase consists of beta testing, piloting, training the users and maintainers of the system, and rolling the product out to marketing, distribution, and sales teams. Several iterations are often made, with beta and general availability releases. User documentation is also produced.
Throughout the phases, nine workflows (Kruchten, 2000), are taking place in parallel. Each iteration, more or less extensively, addresses all the nine workflows. The workflows are Business Modelling, Requirements, Analysis & Design, Implementation, Test, Configuration & Change Management, Project Management, and Environment. Most of these are self-evident. Two of them, however, are less commonly seen in other software process descriptions, which is why they are described in more detail in the following.
Business Modelling is used for ensuring that the customer's business needs are catered for. By analyzing the customer's organization and business processes, a better understanding of the structures and dynamics of the business is gained. The business model is built as a business use-case model, consisting of business use cases and actors. The importance of business modeling depends entirely on the purpose for which the software is built, and the phase may be entirely omitted if not deemed necessary. Business modeling is most often done during the inception and elaboration phases.
The Environment workflow is solely designed to support development work. The activities in this workflow include implementing and configuring the RUP itself, selecting and acquiring required tools, developing in-house tools, providing software and hardware maintenance, and training. Practically all the work in the environment workflow is done during the inception phase.
2.4.2 Practices
The cornerstones of RUP can be listed in six practices that lie beneath the phase-workflow structure. The practices are listed in Table 2.2.
RUP practice
Description
Develop software iteratively
Software is developed in small increments and short iterations, which allows identifying risks and problems early on, and reacting to them adequately.
Manage requirements
Identifying the requirements of a software system that change over time, and those requirements that have the greatest impact on the project goals is a continuous process. A disciplined approach for managing requirements is required, where the requirements can be prioritized, filtered and traced. Inconsistencies can then be more easily spotted. Communication has better chances of succeeding when based on clearly defined requirements.
Use component-based architectures
Software architecture can be made more flexible by the use of components - those parts of the system that are most likely to change can be isolated and more easily managed. In addition, building reusable components can potentially save a substantial amount of future development effort.
Visually model software
Models are built, because complex systems are impossible to understand in their entirety. By using a common visualization method among the development team, system architecture and design can be captured unambiguously, and communicated to all parties concerned.
Verify software quality
By testing during every iteration, defects can be identified earlier on in the development cycle, greatly reducing the cost of fixing them.
Control changes to software
Any changes to requirements must be managed, and their effect on software must be traceable. The maturity of software can also be effectively measured by the frequency and types of the changes made.
Table 2.2: RUP practices (Kruchten, 2000).
2.4.3 Adoption and Experiences
(Kruchten, 2000) claims that RUP can often be adopted, in whole or in part, "out of the box". In many cases, however, a thorough configuration, is suggested before implementing it. The configuration yields a development case, which lists all deviations that have to be made with respect to a complete RUP.
The adoption process itself is an iterative six-step program, which is repeated, until the new process has been completely implemented - which is, in essence, a plan-do-check-act cycle. Each increment brings in new practices to implement, and adjusts the previously added practices. Based on feedback from the previous cycle, the development case is updated if needed. Piloting the process first in a suitable project is suggested.
Despite the need for extensive tailoring, however, RUP has been implemented in many organizations. The success of RUP may also be, to some extent, due to the fact that Rational Software sells popular tools to support the RUP phases.
2.4.4 Scope of Use
RUP is not generally considered particularly "agile". The method was originally developed to cater for the entire software production process, and therefore contains extensive guidelines for process phases that are next to irrelevant in an environment that is likely to call for an agile approach. Studies (Martin, 1998; Smith, 2001) have, however, examined the potential of RUP for using the method in an agile manner. It appears that the adoption phase is the key to adjusting RUP towards agility. The complete RUP lists over a hundred artifacts to be produced in the various process stages, necessitating rigorous screening, through which only the essential ones are adopted.
2.5 Comparison of Agile Methods
The purpose of this subtopic is to compare the agile software development methods which played a vital part in the reason why the author chose to apply RUP method in this academic project ahead of other agile software development methods. This subtopic is organized as follows. First, the comparison of the selected general features, is briefly introduced. This is followed by some aspects of adopting the method are considered.
2.5.1 General Features
All agile methods (except for RUP and OSS) are based on a chaordic perspective, they all share a similar set of collaborative values and principles and they value having a barely sufficient methodology (Highsmith, 2002). However, each method is approaching the problems faced in software engineering from a different angle. Table 2.3 summarizes each method using three selected aspects: key points, special features and identified shortcomings. Key points detail the methods' principal aspects or solution and special features describe one or several aspects of the methods that differentiate them from the others. Finally, identified shortcomings relate to some aspects of a method that are clearly missing or other aspects that have been documented in the literature.
Method name
Key points
Special features
Identified shortcomings
ASD
Adaptive culture, collaboration, mission-driven component based iterative development.
Organizations are seen as adaptive systems. Creating an emergent order out of a web of interconnected individuals.
ASD is more about concepts and culture than the software practice.
AM
Applying agile principles to modeling: Agile culture, work organization to support communication, simplicity.
Agile thinking applies to modeling also.
This is a good add-on philosophy for modeling professionals. However, it only works within other methods.
Crystal
Family of methods. Each has the same underlying core values and principles. Techniques, roles, tools and standards vary.
Method design principles. Ability to select the most suitable method based on project size and criticality.
Too early to estimate: Only two of four suggested methods exist.
DSDM
Application of controls to RAD, use of timeboxing, empowered DSDM teams, active consortium to steer the method development.
First truly agile software development method, use of prototyping, several user roles: "ambassador", "visionary" and "advisor".
While the method is available, only consortium members have access to white papers dealing with the actual use of the method.
XP
Customer driven development, small teams, daily builds.
Refactoring - the ongoing redesign of the system to improve its performance and responsiveness to change.
While individual practices are suitable for many situations, overall view & management practices are given less attention.
FDD
Five-step process, object-oriented component based development. Very short iterations: from hours to 2 weeks.
Method simplicity, design and implement the system by features, object modeling.
FDD focuses only on design and implementation. Needs other supporting approaches.
OSS
Volunteer based, distributed development, often the problem domain is more of a challenge than a commercial undertaking.
Licensing practice; source code freely available to all parties.
OSS is not a method itself; ability to transform the OSS community principles to commercial software development.
PP
Emphasis on pragmatism, theory of prgramming is of less importance, high level of automation in all aspects of programming.
Concrete and empirically validated tips and hints.
PP focuses on important individual practices. However, it is not a method through which a system can be developed.
RUP
Complete software development model including tool support. Activity driven role assignment.
Business modeling, tool family support.
RUP has no limitations in the scope of use. A description how to tailor, in specific, to changing needs is missing.
Scrum
Independent, small, self-organizing development teams, 30-day release cycles.
Enforce a paradigm shift from the "defined and repeatable" to the "new product development view of Scrum".
While Scrum details in specific how to manage the 30-day release cycle, the integration and acceptance tests are not detailed.
Table 2.3: General features of agile software development methods.
Table 2.3 shows differences in the key points the studied methods place emphasis on. ASD is the most abstract method from the software development viewpoint. Although very appealing, its key goal - "creating an emergent order out of a web of interconnected individuals" - may, however, be difficult to grasp. This is also its major shortcoming since practitioners may experience difficulties in translating the method's "new" concepts to their use. Agile modeling (AM), XP and pragmatic programming all represent practice-oriented viewpoints. They all contain a number of empirically validated practices found useful by practitioners. As such, they are very valuable. The Crystal family of methodologies is the only one to explicitly suggest method design principles to allow tailoring depending on project size and criticality. This is an important aspect since method scalability is one of the major topics that the agile community needs to address.
DSDM is differentiated from the other methods by its use of prototyping. DSDM also puts forward some roles that others have not considered. Such user roles are ambassador, visionary and advisor. These user roles represent different customer viewpoints. The drawback of DSDM is the requirement to belong to the DSDM consortium in order to gain an access to the white papers discussing different aspects of the method. FDD does not attempt to provide an all-in-one solution to software development, but focuses into a simple five-step approach, which is based on identifying, designing and implementing features. FDD presupposes that some work towards the project has been done already. Consequently, it does not cover the early phases of a project. Scrum is a project management approach that relies on self-organizing independent development teams implementing a software project in 30-day cycles called sprints. The method book is not very clear.
Similar to ASD, OSS is more of a development philosophy than a method itself. However, many successful projects have been reported in literature. A special feature of OSS is the licensing practice, which requires that the source code is made freely available to all parties. The source code can then be read, modified, compiled and then redistributed free of charge. Finally, RUP is not considered a particularly agile software development method, but it can be one. It stands out from the others by being a complete development suite supported by various commercially sold tools. This is something that is mostly missing from the other methods. RUP also extends the method to contain business modeling practices similar to DSDM. Thus, they provide support also to the early phases of a software development project.
2.5.2 Adoption
While agile approaches concur with the current software development practice, they are not all suitable for all phases in the software development life-cycle. Figure 2.2 shows which phases of software development are supported by different agile methods. Each method is divided into three blocks. The first block indicates whether a method provides support for project management. The second block identifies whether a process, which the method suggests to be used, is described within the method. The third block indicates whether the method describes the practices, activities and workproducts that could be followed and used under varying circumstances. A gray color in a block indicates that the method covers the life-cycle phase and a white color indicates that the method does not provide detailed information about one of the three areas evaluated.
Figure 2.2: Software development life-cycle support.
Figure 2.2 shows that agile methods are focused on different aspects of the software development life-cycle. Moreover, some are more focused on practices (extreme programming, pragmatic programming, agile modeling), while others focus on managing the software projects (Scrum). Yet, there are approaches providing full coverage over the development life cycle (DSDM, RUP), while most of them are suitable from the requirements specification phase on (FDD). Thus, there is a clear difference between the various agile software development methods in this regard. Whereas DSDM and RUP do not need complementing approaches to support software development, the others do to a varying degree. However, DSDM is available only for the members of the DSDM consortium, and RUP, then, is a commercially sold development environment.
The agile approach appears particularly suitable in a situation where future requirements are not known. It appears that if future requirements are known and can be specified, agile approaches do not provide added value to a development project itself.
2.6 Conclusion
Based on the various topics that have been discussed earlier, it is shown that agile methodology, RUP in particular, is the most suitable development method for web-based property management system. RUP helps the author in a way that the system is developed iteratively as well as it embraced use cases for modeling requirements in order to build the foundation for the system itself. Thus, this academic project aims to implement the web-based property managament system that can gives significance to its users.
