19th Telecommunications forum TELFOR 2011
Serbia, Belgrade, November 22-24, 2011.
Software Engineering Framework for Digital Service-oriented EcoSystem Ejub Kajan, Member, IEEE, Ljubomir Laziü, and Zakaria Maamar
Abstract — This paper deals with a software development process framework intended to act as a testbed in a serviceoriented digital ecoSystem. After short introduction to software ecosystems a concise overview of the framework and its role in such environment is given. After that, the main software engineering components of the framework are described with few examples of how it works. Keywords —Software Development Process, ServiceOriented Architecture, Software EcoSystem, Software Metrics, Software Quality Assurance
I. INTRODUCTION INCE the beginning the software industry has struggled to provide QA (Quality Assurance) and software test in an efficient manner. SQA (Software Quality Assurance) activities are key assumptions for successful software development and implementation. In the past many studies, an overview is given in [1], shown that a large percentage of software projects failed or significantly exceed budget and timing due to absence of appropriate software testing environment. The dark side of software failures consists not only in high cost of software development and maintenance, but also in indirect costs caused by software bugs, security backdoors, etc. [2]. In such circumstances there is a big divide between large software companies that can fire a significant number of software researches and developers and SMEs that are in contrast unable to do it. The purpose of this paper is to explain motivation, goals and architectural design of a service-oriented framework for Software Development and testing Process (here and after SDP) that acts in a software ecosystem intended to help software companies in their projects from early stage of development through all lifecycle. The rest of the paper is organized as follows. Section two gives a short background of digital ecosystems, especially those that are aligned with SDP goals. The clear motivation for such SDP framework is given. Section three describes a general architecture overview, while section four is dedicated to SQA wheels of framework supported by few concrete results.
S
Ejub Kajan is with the State University of Novi Pazar, Vuka Karadžiüa bb, 36300 Novi Pazar, Serbia, e-mail:
[email protected]. Ljubomir Laziü is with the State University of Novi Pazar, Vuka Karadžiüa bb, 36300 Novi Pazar, Serbia, e-mail:
[email protected]. Zakaria Maamar is with Zayed University, Dubai, UAE, e-mail:
[email protected].
978-1-4577-1500-6/11/$26.00 ©2011 IEEE
II. SOFTWARE ECOSYSTEMS In recent years the concept of ecosystem is used as a metaphor in e-business as well as in systems thinking in general. It relies on SOA (Service-Oriented Architecture) paradigm where actors that belong to different and independent systems (referred as after software artifacts) establish an interaction via loosely coupled services in order to perform some task [3]. Chang and West [4] define a digital ecosystem as open, loosely coupled self-organizing digital environment in which the agents or species composing it are proactive and responsive for their own benefit. Digital ecosystems transcend the traditional rigorously defined collaborative environments from centralized or distributed or hybrid models into an open, flexible, domain cluster, demanddriven interactive environment. A digital ecosystem is new-networked architecture and collaborative environment that addresses the weakness of client-server, peer-to-peer, Grid and Web services. Special kind of digital ecosystems are software ecosystems. ”A software ecosystem consists of a software platform, a set of internal and external developers and a community of domain experts in service to a community of users that compose relevant solution elements to satisfy their needs” [5]. One of the key ideas behind software ecosystems is to provide an environment for distributed collaborative development, usually based on open source software, of large scale software products. At the same time such a software ecosystem may be used as a collaborative development environment, where SMEs of various sizes and expertise may be grouped around larger software projects and produce common products that they never will able to reach alone [6]. According to the abovementioned definition, this paper proposes a Business Intelligent Service Architecture (BISA) to as an expert service of a community capable to offer TaaS (Testing as a Service) artifact in order to support full development lifecycle [7] either for parts of large software project or for their finalization and integration. The design of service ecosystem is out of scope of this paper. Instead, we propose an SDP framework as a useful part of a community of such digital ecosystem, not excluding the possibility to have few more in the same system.
1320
III. BISA ARCHITECTURAL OVERVIEW A. What is BISA BISA provides a Software Testing Centre of Excellence for SMEs with scalability, objectivity, consistency, and constant improvement features capable to support full lifecycle software assurance following software engineering standards and to provide better and cheaper software products on time. It consists of several mutually connected subsystems (Fig. 1). The heart of BISA is an SDP-engine consisting of OptimalSQM expert tools [8] and SQA wheels of BISA, actually service-enabled OQT (Optimal Quality Testing) modules as shown in Fig. 2, the roles of which are given in section four. Both are supported by various knowledge bases [8].
Fig. 1. The overall architecture of BISA. SDP engine communicates with the external environment via either portal or a service bus (Enterprise Service Bus). The last subsystem of the framework is einvoicing that will be explained in C. An important issue of BISA is openness in the sense of Computer Supported Cooperative Work (CSCW). That means the launch of BISA beta version will launch an open call to software SMEs to use BISA services, but to work on BISA software development, as well. This issue is important to understand the rationale of two-way invoicing issues between BISA and customers given in section C. It should be noted here that this approach does not disturb the autonomy of any participating entities, including the BISA itself. B. How BISA fits with a software ecosystem BISA should be seen as an SDP service-oriented, knowledgeable cluster of an ecosystem that brings together business entities they need SDP services either as alone or grouped actors. These business entities may act as software artifacts tending to establish specific B2B relationships asking for the specific SDP BISA service or people that act in a P2P environment via many of social network opportunities. These opportunities may vary from simple comments, via BISA either criticisms or calls to
active participation using blogs, wikis, mashups, crowdsourcing, tagging, and the like. Usefulness of social networks in SOA has been precisely described in [9]. On the other hand the in depth analysis of the potential impact of social networks in collaborative working environments and available mechanisms are given in [10]. The important facet of this proposal is the motivation. In addition to general agreement that an SDP must be applied to any software project [11], there are several facts that also drive the motivation. They are grow of serviceoriented software and the current absence of SDP frameworks that meet SEI CMM for services [12], etc. A recent analysis on B2B service-oriented projects funded by EU found that much attention has been normally devoted to introduce frameworks and tools for SOA implementation, but very often these projects shown the ultimate aim to support software developers in SMEs or for SMEs [13]. C. The B(Business) facet of BISA Business exposure in BISA comes from several reasons as follows: (1) all offered SDP services are treated as business processes, (2) there is an e-invoicing system there, (3) all communications between services and customers are B2B transactions of various kinds and finally (4) the framework is intended to be an SDP for SMEs. E-invoicing subsystem is based on a mediator/wrapper architecture, very similar to those given in [14], but simplified due to specialization in SDP service brokering. Many SMEs suffer for migrating legacy systems and data to the current e-invoicing solutions, offered mainly by large vendors such are SAP and Oracle, etc. The semantic ontology-driven solution as proposed in [14] may reduce this problem, but there is an open problem of how to develop a shared ontology. The problem here comes from the constraints given in SMEs particular e-invoicing systems, i.e. how e-invoice should look like, what information it should carry, and most important how an information is or should be named. Our intention is to ask customers using e-form questionnaires to collect necessary data. Such questionnaires will be issued only on demand and will not be mixed with data (see Fig.3) that are collected exclusively for the use by SDP part of BISA. On the other hand e-invoicing system will take care of customers that are unable to participate in such a way at the moment and will allow sending/receiving invoices by traditional ways (postal messages, e-mail, fax). D. The I (Intelligent) facet of BISA BISA intelligence comes from several knowledge bases (KBs) that are maintained and updated every time when new customers entering the system as well as when some testing service is used. There are two groups of such KBs, one takes care of software engineering matters, whilst the other group is dedicated to support business communication between BISA and its customers and/or collaborators.
1321
E. The S(Service ) facet of BISA BISA itself is service-oriented architecture intended to serve both, a non-service- and service-oriented software projects. For the latest, the leading guide is the SEI CMM for Services [12]. Service operations are managed via service bus that is based on a modified version of ESB standard. Another important aspect is loosely-coupled principles of services. All connections between SMEs and BISA software are established on demand via public parts of their either software or business processes, thus the private parts of both parts remain transparent.
(no personal information is gathered); (5) project functional size: ask for the estimated amount of functionalities the project will deliver); (6) project completion: ask for the overview information how much a project is completed at the moment.
IV. SQA WHEELS OF BISA Driving software quality assurance wheels consists of five modules as shown in Figure 2. OQT MNGR (Manager) provides integrated and coherent management of multidisciplinary aspects of testing. It drives the other four wheels as well as takes care of communication and harmonization with other key modules of BISA such as portal, service bus and einvoicing subsystem. In order to allow calculation of risk estimation MNGR is also able to give all necessary questionnaires to external environment, either to people entering through portal or software artifacts knocking on demand to BISA door via service bus. An example of such question form is given in Figure 3. These forms, depending on customer preferences are either MS Word Forms or php e-forms, with some validation and dropdown lists where appropriate. Fig 3 Part of BISA e-BasicQuestionnarie.
Fig. 2. Five SQA wheels of BISA. Typical data that are collected may be summarized in several sections as follows: (1) submitter information: collects details about business entity which ask for BISA services; (2) project process: collects information about the technology used in particular project; (3) technology: obtain information about technologies used; (4) people and work effort: Collects descriptive information about the people who worked on the project, and the effort they will expend with separate data about test effort expenditure.
OQT SIM (Simulation) is used for the simulation of testing scenarios. That task relies on rules known in advance that are created based on previous empirical experiences. These rules are dynamically updated every time when empirical measurements are resulting by new findings, enriching the knowledge base after every touch with real-world software development. SIM offers pattern simulation of various kinds, such as algorithms, maturity levels, reducing testing time, statistical software process control, and the like, the part of which is shown in Fig.3. For the given large (~11300 FP, Java implementation about 600KLOC of source code) project example [15], and for original data of process defect removal effectiveness simulated calculations of two Scenarios 1 and 2 for Improvement potential in cost units [cu] are shown in Fig. 4. The Scenario 1- Standard quality assurance activities plan includes: Requirement specification review, Design review, Unit test – code, Integration test, Documentation review, System test and Operation phase. Scenario 2 is Comprehensive quality assurance plan which is realized through feasible series of experiments: software test method, field test, through simulation, or through a combination, represent a new test sequence determined by Simulated Defect Removal Cost Savings model.
1322
Fig.4. Graph with calculation of Improvement Potential in [cu] for improvement Scenario 1 and 2 OQT BOX module uses best current practices and a set of common testing techniques either by Black, or White or Gray boxes methods. It is completely independent either of SDP methods used by particular software project or kind of software or implementation tools. OQT MAINT takes care of all testing results and uses them in order to propose quality improvement during software development, implementation and maintenance. Among others, MAINT is also leaded by theory and practice of software reliability [11] in order to foreseen and estimate software reliability. Examples of such estimations are related, but not limited to: error rates, error density based on KSLOC of FP data [2], etc. OQT OPST (OPeratinonal Software Testing) is intended for operational and fine tuning, based on real strengths of a particular project/company and results provided by other BISA SDP modules, of future activities that should lead a software project to success phase. ACKNOWLEDGMENT This work was supported in part by the Ministry of Science and Technological Development of the Republic of Serbia under Grant No. TR-35026.
[2] [3]
[4] [5]
[6]
[7]
[8]
[9] [10]
[11] [12] [13]
[14]
REFERENCES [1]
National Institute of Standards & Technology, US Dept of Commerce, The Economic Impacts of Inadequate Infrastructure for Software Testing, May 2002.
[15]
1323
C. Jones, Estimating Software Costs, 2nd ed. McGraw-Hill, New York, 2007. M. Papazoglou et. al., Service-Oriented Computing: A Research Roadmap. http://drops.dagstuhl.de/opus/volltexte/2006/524/ (retrieved August 2011). E. Chang and M. West, Digital EcoSystems a next generation of collaborative environment. Proceeding of iiWAS’06, pp. 3-24. J. Bosch and P. Bosch-Sijtsema, From integration to composition: On the impact of software product lines, global development and ecosystems. Journal of Systems and Software, 83(1):67-76, 2010. T. Heistracher, T Kurz, G. Marcon, and C. Masuch, “Collaborative Software Engineering with a Digital Ecosystem”, in Proceedings of IEEE IGSE’06, 2006, pp. 119-126. E. Kajan, L. Lazic, and Z. Maamar, “Software Testing as a Service (TaaS): The BISA Approach”, in Proceedings of IEEE TELSIKS’11, Nis, Serbia. October 2011. Lj. Laziü, E. Kajan and N. Mastorakis, "OptimalSQM: Optimal Software Quality Management Framework Architecture", WSEAS SEPADS Conference Proceedings, Cambridge, UK, pp. 189-199, 2011. Z. Maamar et al., "Why Web Services Need Social Networks", IEEE Internet Computing, March/April, 2011, pp. 90-94. M-A. Storey et al. ”The Impact of Social Media on Software Engineering Practices and Tools”, in Proceedings of ACM FoSER, Santa Fe, New Mexico, USA, October 2010, pp. 359-363. I. Sommerville, Software Engineering, 9th ed. Pearson, 2011. SEI, CMMI for SVC, ver. 1.3, CMU, November 2010. F. Bonfati et al., “Business Documents Exchange between Small Companies”, in “Electronic Business Interoperability: Concepts, Opportunities and Challenges”, E. Kajan, Ed., IGI Global, Hershey, PA, 2011, pp. 482-510. E. Kajan & L. Stoimenov, Towards Ontology-Driven Architectural Framework for B2B, Communications of the ACM, Vol. 48, No. 12, 2005, pp. 60-66. Lj. Laziü, Software Testing Optimization by Advanced Quantitive Defect Manager, ComSIS, Vol. 7, No.3, June, 2010, pp. 459-487.
