SERVICE ORIENTED ANALYSIS AND DESIGN OF
PROJECT MANAGEMENT SOFTWARE
Riyanarto Sarno1, Rizky Januar Akbar1, Nurul Fajrin Ariyani1, Ratih N.E. Anggraini1, Riska A. Pratistari1, Ikti Oktavianty1, I.G.M. Indra Prasetya1, Eka Gibran Hasany1
Informatics Department, Faculty of Information Technology, Institut Teknologi Sepuluh Nopember (ITS) Gedung Teknik Informatika, Kampus ITS, Surabaya, Indonesia
email: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
ABSTRACT
Project management software is often used in the companies. The escalation of business competition forces the application to quickly adapt the business changes. In order to overcome the challenges, we need project management software that based on service oriented architecture (SOA). To provide the service oriented solutions, we use service oriented analysis and design (SOAD) and service portfolio views for identifying service candidates. We also partially adopted PRINCE2 as case study in this paper. We have successfully identified service candidates and design it into web service dictionary.
Keywords: SOAD, project management, service
candidate.
1
INTRODUCTION
Business needs is always changing along with the escalation of business competition. Those changes must be responded quickly so that not left behind in the competitive era. Information technology as the one of supporting systems of business is required to quickly adapt against the changes in business. SOA is an architectural model for realizing service-oriented solutions [1]. It is useful for anticipating the opportunities and threats in business [2]. Hence, we need a methodology in order to develop applications that fulfill the criteria of SOA.
SOAD is an interdisciplinary service modeling approach that combines existing development processes and notations such as Object-Oriented Analysis and Design (OOAD), Enterprise Architecture (EA), and Business Process Modeling (BPM) [2]. There are other works that use this methodology. In [3], SOAD is used to analyze and design services that are adaptable in variety clients and contexts. Whereas, the combination of SOAD and use case approach is accomplished to identify high-quality services [4].
In our previous work, we use SOAD in Service Portfolio for Enterprise Resource Planning (ERP) [5]. It produced a portfolio of services that include Conceptual View (CV), Logical View (LV), and the Physical View (PV) of an ERP. CV consists of functional domain diagram, mapping of functional domain, business process activity diagram (BPAD) and sub business process activity diagram (SBPAD). LV includes business activities in business processes, the matrix of business services with business entities. Physical view is designed for manufacturing ERP software.
This paper aimed to identify service candidates for project management software by using service oriented analysis and design. We partially adopted the PRINCE2 as the case study for applying the SOAD. PRINCE2 is a structured methodology for project management using process based approach that can be easily adopted by generic projects [6]. PRINCE2 provides a procedure for planning, managing, controlling and monitoring a running project. It also provides steps that must be done when the activities are not going as planned.
2
THEORETICAL
CONSIDERATION
2.1 Service Oriented Analysis and
Design
SOA is an architecture that connects services according to the requirements. It forms an application ecosystem for accomplishing results that are expected by the service consumers (end users or other services). To produce a service based on SOA, it needs steps that cover the requirement analysis process and system design that will be the architectural foundation of the system. It can be overcome by using SOAD.
SOAD uses top-down approach in its analysis and design. It starts from requirement analysis in business level then translating it into the services by classifying the business processes of an enterprise. Services that are produced represent the
ISSN 2085-1944
Figure 1. Elements of SOAD [2]
collection of business process modeling of an enterprise. Then, it is derived into supporting components that can be implemented in the system.
Design of SOAD as shown in Figure 1 is divided into three domains based on the concept that is being used:
Business domain explains the business process and its function in an enterprise. It is represented by BPM.
Architecture domain explains the architecture of system. It is developed using object-oriented design represented by Unified Modeling Language (UML) and modeled using EA. Application domain explains the implementation
of functionalities in the system. It is developed using OOAD approach.
2.2 Service Portfolio Views
Service portfolio is a place to hold the information for service consolidation. It contains information such as, service definition, access and usage policies and non-functional requirement for a service. To identify the problem using top-down approach in SOAD, service portfolio provides three levels of views as shown in Figure 2 [5].
Conceptual View
CV contains business processes outline that will be developed in the system. It makes management level easier to define the business process that can be understood by people that not too understand about technical matters. Elements of CV are integration of functional domains (functional domain diagram), BPAD, SBPAD, stakeholder diagram, and workflow diagram.
Functional domain diagram explains about the involved domains in the system that will be developed. BPAD represents sequence of business processes that happens the functional domain. SBPAD represents sequence of sub business processes in functional domain. Stakeholder diagram describes all the interested parties in the system. Workflow diagram represents sequence of
Figure 2. Service portfolio views
activity inside the sub business process in the functional domain.
Logical View
LV is a bridge for connecting between CV and physical view. Business processes that have already defined in the CV are analyzed deeper to produce output for application developer. Elements of logical view are business layer, service layer, component layer, matrix of business services versus the business entities, and business service activity diagram.
Business layer in SOAD represents the classification of business services according to its process and business functionalities. This layer is divided into three parts namely functional domain, business process, and business service. Service layer represents realization of business service that later will be developed to support the system. Component layer represents the supporting components of service. Furthermore, component is a group of class that can be used to build a service.
Inside the LV business service is derived into software service and business entity is derived into software entity. It is represented in a matrix of business services versus business entities. Software service that is contained in service layer will be implemented as operation of web services. Moreover, activity for each business service is also defined. It involved internal business process, usage of software service, and design of software service in a business service activity diagram (BSAD).
Physical View
PV contains realization of the design in CV and LV. This view is divided into several layers, such as: web service layer, presentation layer, application service layer, domain model layer, and data access layer.
Web service layer shows the web services that are provided by the functional domain. The operations of the web service are also represented with its corresponding input and output. Presentation layer represents the design of user
Figure 3. PRINCE2 process model
interface (UI). Application service layer contains business logic in each functional domain. Domain model layer is a layer that contains the implementation of software entities. It also contains data transfer object (DTO) that might be used by web services. Components are also represented in domain model layer. Moreover, data access layer contains connection in order to save or retrieve the data from database. It can be implemented using any kinds of technologies including object relational framework (ORM).
2.3 PRINCE2
PRINCE2 (PRojects IN Controlled Environments) is a structured method of project management which designed to meet the needs of its users. It applied some generic methods and tested for all types of projects. Furthermore, it is a project management methodology with a simple process-based approach that easily adopted in accordance with the scale of the project.
The methodology of PRINCE2 provides not only several procedures in managing resources of project to design and regulate the course of events, but also some steps that must be done when the activities do not go as planned. It devotes proven methods (best practice) in project management. This methodology is already widely known and provides a common language for people or stakeholders who are involved in a project.
PRINCE2 explains how to divide a project into several stages in order to control resources in an efficient and regular monitoring of progress. Various positions and responsibilities for managing a project are clearly defined and can be adopted in accordance with the scale, the complexity of project, and the organizational capabilities.
The process model of PRINCE2 covering activities from starting the project according its track, to controlling and managing the progress
Figure 4. Stakeholder diagram
until it is completed. The key to success in using PRINCE2 process model is doing adaptation and adjustment to the needs of the project. Figure 3 shows the steps of management processes in PRINCE2 process model. Those management processes are as follows [6]:
Starting Up a Project (SU) Directing a Project (DP) Initiating a Project (IP) Controlling a Stage (CS)
Managing Product Delivery (MP) Managing Stage Boundaries (SB) Closing a Project (CP)
Planning (PL).
3
ANALYSIS
We designed the project management application that refers to PRINCE2 using SOAD. In [7], SOAD is an architectural style that modularizes information system become services. Services that are provided consist of internal process of functional domain and external services. Service which is internal process is used to fulfill the business needs, while the external service can be used by other parties. Therefore, the application can be integrated each other.
PRINCE2 can be applied into various types of project. However, we considered a project as a generic project in this paper. The mapping of PRINCE2 process model into our application is shown in Table 1. Management processes that are not listed in Table 1 are not mapped.
ISSN 2085-1944
Figure 5. BPAD
Figure 6. SBPAD
By using SOAD, problem analysis in functional domain is done by top-down approach. So that every functional domain is modeled in several point of views, such as CV, LV, and PV.
CV provides information for all parties that are involved in functional domain. That information is represented in stakeholder diagram. Our design of the stakeholder diagram is shown in Figure 4.
CV also represents BPAD and SBPAD. BPAD describes business process flow that happened in functional domain. SBPAD describes sub business process flow. Sub business process is a derivative of business process. BPAD and SBPAD are shown in Figure 5 and Figure 6. Workflow diagram in CV represents business process workflow related to the system.
In LV, each of functional domains is divided to several business processes. Division of business processes are done based on function similarities, for example master data management business
Table 1. Map of PRINCE2 to General Terms of Project Management
Project Management Process with Generic
Approach
SU2 Design Project Management Team SU3 Appoint Project
Management Team SU5 Defining Project Approach SU6 Planning an Initiation Stage
Organizing - Planning Project Activities Organizing - Planning Product
IP4 Setting Up a Project Control
Organizing - Creating Portfolio
IP5 Setting Up a Project Files Organizing - Creating Contract
CS CS6 Reporting Highlights Controling - Updating Project DashBoard MP MP2
Executing a Work Package
Actuating - Realizating Project
SB SB2
Updating a Project Plan
Controling - Modifying Project
PL1
Designing a Plan
Planning - Managing Plan Data Planning - Managing Product Data Planning - Managing Material Data Planning - Managing Service Data Planning - Managing Supplier Data Planning - Managing Activity Data Planning - Managing Employee Data
Project Management Process with PRINCE2 SU Organizing - Configuring Organization Structure Organizing - Initiating Project IP
IP2 Planning a Project
PL
PL2 Defining & Analysing Product
PL3 Identifying Activities & Dependencies
process that handles the data management that is needed by application. Each of business process is divided again into business service. This business service is not only the internal process for application but it is also for other entity, for instance master data management has managing product data as business service. This business service is provided by the handled project and to fulfill the internal needs such as insert, update and delete to provide the needs of other entities to gather information using web service. To realize the web service, we need a component that is formed from aggregate class which is represented in component layer. The short explanation of it is shown on Table 2.
Business service is derived into software service. Then, business entity is broke down into software entity which are described in a matrix namely matrix of business services versus business
Table 2. Business Layer, Software Layer, and Component Layer Software Layer Component Layer Functional Domain Business Process Business Service Software Service Software Component 1.1 Managing material data 1.1.1 Provide material data MasterMaterial 1.2 Managing supplier data 1.2.1 Provide supplier data Supplier 1.3 Managing service data 1.3.1. Provide service data MasterService 1.4 Managing plan data 1.4.1 Provide plan data MasterPlan 1.5 Managing activity data 1.5.1 Provide activity data Activities 1.6 Managing product data 1.6.1 Provide product data Product 1.7 Managing employee data 1.7.1 Provide employee data UserProfile Project managem ent 1. Managem ent master data Business layer
Figure 7. BSAD for sub business process managing product data
entities. Software entities can be called as class candidate. LV is also defined activities from each business service in a BSAD.
In order to create BSAD, the business process is broke down into sub-business process. The division of sub-business process is shown in Table 3. In BSAD, each of activity is classified by sub business process. The example of BSAD for sub business process managing product data is shown in Figure 7.
Table 3. Division of sub business process for master data management business process
Business Process
Sub Business
Process Business Service Software Service
Managing material data 1.1 Managing material data 1.1.1 Provide material data Managing suplier data 1.2 Managing supplier data 1.2.1 Provide supplier data Managing service data 1.3 Managing service data 1.3.1. Provide service data 1.4 Managing plan data 1.4.1 Provide plan data 1.5 Managing activity data 1.5.1 Provide activity data Managing product data 1.6 Managing product data 1.6.1 Provide product data Managing employee data 1.7 Managing employee data 1.7.1 Provide employee data 1. Managem ent master data Managing project management data
Figure 8. The software architecture
4
DESIGN
This section explains about the design of PV. The design of PV is used as the software architecture that represents relationship between layers in PV. This design can be implemented directly by developer into code structure. The design of software architecture can be seen in Figure 8.
The web service layer is a place for web service candidates which are the result of the analysis in CV and LV. Web service layer represents software services that are provided by the functional domain. The service candidates are represented as web service dictionary as shown in Table 4.
Furthermore, components are needed in order to provide web service. The list of component which is called component dictionary can be seen in Table 5.
ISSN 2085-1944
Table 4. Web services dictionary for management master data
Web Service Operation Parameter Return Description
Managing Product Data Provide Product Data - entity : List<Product>
This web service is used to provide product data Managing Service Data Provide Service Data - entity : List<Service>
This web service is used to provide service data Managing Material Data Provide Material Data - entity : List<Material>
This web service is used to provide material data Provide Activity Data - entity : List<Activities>
This web service is used to provide activity data Provide Plan Data -entity : List<MasterPlan>
This web service is used to provide master plan data
Managing Supplier Data Provide Supplier Data - entity : List<Supplier>
This web service is used to provide supplier data Managing Employee Data Provide Employee Data - entity : List<UserProfile>
This web service is used to provide employee data Managing Project Management Data
5
CONCLUSION
In order to create service candidate for project management software using SOAD, PRINCE2 process model is mapped into the generic term of project management. Then, we created service portfolio views for project management. The division of service portfolio into CV, LV, and PV simplifies the top-down manner using SOAD. CV and LV are involved in the analysis phase. Deliverables from this phase are service candidates and class candidates. Moreover, PV is done in design phase. Deliverables from the PV are web service dictionary and component dictionary.
In this paper we identified service candidates for generic term of project management that partially adopted from PRINCE2 process model. The service candidates that are produced from analysis phase are transformed into web service dictionary. The web service dictionary can be used to implement the project management software. Web services which are resulted from the dictionary are fine grained services.
Acknowledgements
This research was supported by the Institut Teknologi Sepuluh Nopember (ITS) under the
“Penelitian Guru Besar” grant number 0535/I2.7/PM/2009.
Table 5. Component dictionary for management master data
Component Class Description
Product ProductApproval ProductApprovalStatus
MasterService MasterService This component is used to store master service data MasterMaterial MasterMaterialHierarcy MaterialConfiguration MaterialType TechnicalSpesification MasterPlan MasterPlanActivities Activities ActivitiesItem Predecessor Supplier ProjectSupplier SupplierRating Role RolePrivillege RoleType UserProfile
Activities This component is used to manage activities data
Supplier This component is used to manage supplier data
Role This component is used to manage employee data Product This component is used to
manage product data
MasterMaterial This component is used to store master material data
MasterPlan This component is used to manage master plan data
REFERENCES
[1] David C, John D, Nitin G, Hanu K, Brian L, Christoph S, Herbjorn W, and Mickie W (2010) SOA with .NET and Windows Azure. Michigan: Prentice Hall.
[2] Olaf Z, Pal K, and Clive G (2004) Elements of Service-Oriented Analysis and Design [Online]. Available at: http://www.ibm.com/ developerworks/webservices/library/ws-soad1/ [Accessed: 24 May 2010].
[3] Soo Hoo Chang, and Soo Dong Kim (2007) A Service-Oriented Analysis and Design Approach to Developing Adaptable Services. In: IEEE International Conference in Services Computing (SCC 2007). Salt Lake City, July 9-13, 2007.
[4] Si Huayou, Ni Yulin, Yu Lian, and Chen Zhong (2009) A Service-Oriented Analysis and Modelling Using Use Case Approach. In: Computational Intelligence and Software Engineering (CiSE 2009). Wuhan, December 11-13, 2009.
[5] Riyanarto S, and Anisah H (2010) A Service Portfolio for an Enterprise Resource Planning. International Journal of Computer Science and Network Security (IJCSNS) Vol. 10 No. 3, pp. 144-156.
[6] Office of Government Commerce (2005) Managing Successful Projects with PRINCE2. London: TSO (The Stationery Office).
[7] Brown, Paul C (2008) Implementating SOA: Total Architecture in Practice. Massachusetts: Addison-Wesley.
