An Information Systems Acquisition Framework EVANGELOS MARKOPOULOS Department of Informatics University of Piraeus 80 Karaoli & Dimitriou Str., Piraeus GREECE JOHN-CHRIS PANAYIOTOPOULOS Department of Informatics University of Piraeus 80 Karaoli & Demetriou Str., Piraeus GREECE Abstract:- Each participant in a project has a different point of view on what is successful project and how it shall be accomplished. This paper takes into consideration the prime processes of 43 methodologies used mainly for information technology project and creates a methodological framework for managing the an information technology project primarily from the user (customer) perspective. The framework is supported by best practices, and has been designed in such a way that captures all project activities before, during and after the implementation of a project in an adjustable manner. The structure of this framework allows the of any type size, and complexity projects. Key-Words: - Systems Acquisition,, Methodologies, Process Framework 1. Introduction and software project in particular is primarily based on understanding the nature, scope and goals of the project in order to perform the proper allocation of resources needed towards its successful implementation [1]. A very important but trivial principle is the definition of success. Resource allocation, effort [2], managing technical people [3], requirements elicitation and tracking [4], acceptance criteria definition [McGrew], and performance measurement [5] can be considered as differential factors towards defining project success under the spectrum of project control, which is [6], and always was [7], the project success definition. Controlling a project successfully is to ensure the minimum surprises along the way [8]. The whole concept of project is based on a number of activities, operating as satellites to the project implementation process., change, quality assurance, risk and other managerial activities can not be categorized in a staged interpretation [9], [10], [11], since they can be applied on the entire project implementation process. 2. Conceptions organizations today that can be considered as Software and/or Technology Intensive Organizations[12], can be roughly placed in two categories. The ones developing systems and the ones acquiring systems. The first category of organizations cover the ones which have internal software development or systems development teams that either produce IT products, services, applications and systems which support their operations and functionality. Software houses, telecommunication organizations and systems integrators are top of the list in this category. On the other hand, financial institutions and governmental authorities (public companies or agencies) which have structured systems development departments or even business units, could also be part of this category. Organizations in this first category usually perform project by following systems
engineering models [13], [14], [15]. They have a systems development methodology, composed of the major systems development phases in a development life cycle model. to those organizations is primarily the proper execution of the development phases and the system s life-cycle model in general, within budget, schedule and quality, which is measured primarily by implementation performance and compliance to the requirements. Software and or Systems Engineering form the basis of this type of project [16],[17]. The second category covers all the other organizations excluded from the first one. The organizations in this category do not have the maturity, capability and needs above all, to develop their own information technology systems. Such organizations derive mainly from the industry and the service sectors, supported by either small internal IT departments or external consultants. These organizations acquire technology instead of creating it. The primary goal of these organizations is to receive / accept a system that will function according to their needs within a predefined budget and schedule. for those organizations is directed towards managing the tender process through which the vendor is selected, managing the signed contract, managing the deliverables of the project and actually managing time and material related to project cost and schedule. Software and or Systems Acquisition form the project basis [18].[19] for this second category of organizations. This engineering-acquisition relationship defines a project concept for all types of organizations. 3. A Framework for System Acquisition An Information Systems Acquisition Framework (ISAMF) has been developed by taking into consideration the practical need for a project approach to be used by all types of organizations. In order to develop ISAMF, a detailed analysis of 43 project managing methodologies, guidelines, and frameworks, has been conducted towards the identification of the commonly used practices in project, systems acquisition and software engineering under different goals and dimensions. The goal of ISAMF is to be used mainly be the software intensive small to medium size enterprises which rely primarily on tracking the acquisition processes than inspecting the engineering ones. Thus the whole concept of ISAMF is based on the requirements and contract process which are heavily applied throughout the entire project effort. 4. in the Information Systems Acquisition Framework The structure of ISAMF is composed of fifteen (15) phases. Table 1 presents this basic set of phases that can form this project framework. The first column indicates the generic name of each phase, the second column indicates the methodologies supporting this phase generic name, and the third column indicates other methodologies that support the name of the phase but with slight naming and activities deviations. Phase Name Methods Supporting Methods Supporting Relations Scope. SDLC, IPM, LFA, 5STEP, SCALABLE, TENSTEP SEFER, LCM-AIS, WWPMM, AUSGuidelines AIM, SW-CMM, PROMPT, Ariadne SE-CMM, SD, LFA, AIM, ISO9000-3, DoD2167 A, NATO-CALS, SA- CMM DSDM CBAM, SEFER Ariadne-PM SDLC, ITIL, DoD2168, ITPM, SW-CMM, ISO9000-3, LFA, CBAM, IE Ariadne-PM, SE- CMM PRINCE, SDLC, SDPP, resources PRODIGY, RDPP, SUPRA, and technical SUPRA, 5STEP, AIS issues. SCALABLE PRINCE, SUPRA, 5STEP, structure. PRODIGY AIS Contract SA-CMM WWPMM, Ariadne- Tracking and PM, AUSGuidelines Oversight Evaluation Software WWPMM, SW- SUPRA, ITPM, project tracking CMM, and oversight WWPMM, PRINCE, SDLC, DoD2167 A, DoD2168, ISO9000-3, CBAM, Ariadne-PM, AUSGuidelines, SE-CMM IDEAL, MITP, ITPM, Princeton
PRODIGY, EUROMETHOD Quality Assurance WWPMM, PRODIGY, AUSGuidelines, DoD2168, Ariadne- SUPRA, IPM, PM, SE-CMM SCALABLE, TENSTEP, ITPM, ITIL, SW-CMM, ISO9000-3 Change WWPMM, Ariadne-PM. ISO9000-3, DSDM, AIS Risk WWPMM, IPM, CBAM, SCALABLE, TENSTEP, AUSGuidelines, Ariadne-PM EUROMETHOD, ITPM, SE-CMM Transition & SDLC, AIM, IPM, SA-CMM, LCM- Support ASAP AIS Acceptance ISO9000-3 Ariadne-SD Post- Implementation Review/Evaluat ion Phase ITPC AUSGuidelines Table 1. composing the Information Systems Acquisition Framework The methodologies listed in the second column of table 1, support the phases listed in the first column in a very precise way. Most of the phase activities are quite relevant between the definitions and goals in all methods. Unlike the second column, the methodologies listed in the third column support conceptually the related phases from a different perception. The activities, for example, of the Quality Assurance phase can be more or less found in other related methodologies which do not refer to them as Quality Assurance, but as Quality System, Quality, Software Quality Program Implementation, or even Standards. these different versions of the Quality Assurance phase have the same goal and scope of what a Quality Assurance phase covers in both activities and deliverables. Another more theoretical phase, like the Scope of the project, which is referred in the supporting methodologies as Concept Phase, Definition, Goals, or even Objective Analysis. In a similar way, the Contract Tracking and Oversight Evaluation phase has been referred by the supporting methodologies as Managing Contractors, Contract, or ever Sponsor agreement. 5. Information Systems Acquisition Framework phases description and dependencies Table 2 describes the phases of the Framework for System Acquisition, while indicating the dependencies among them. Phase Description Dependent Dependenc Phase y Type Scope. Identification of project scope, stakeholders, adjacent systems and acceptance criteria. Requirement - s resources and technical issues. structure. Contract Tracking and Oversight Evaluation Software project tracking and oversight elicitation, analysis, and through the development process. Creation of the Request of and / evaluation of the proposals. actual decomposition, planning, estimating and scheduling on resources, effort, budget and quality. Human resource at all project levels and hierarchies. Establishing and following a structure based on organizational and workflow corporate models. Contract through the develop. process based on the proposed & contractual vendor obligations. Monitoring the development process based on inspection and Scope Partial Requirement Requirement Partial resources Partial to to
Quality Assurance Change. Risk Transition & Support Acceptance reviews. of all contractual and non-contractual documents produced by the projects engineering and methodology. Monitoring the compliance to the quality plan through the implementation of the defined quality standards. Documentation, Implementation, scheduling, monitoring and impact analysis of systems changes. Identification of technical and nontechnical risks in systems implementation and maintenance. Monitoring and supporting the transition process (migration) to the new system. to to to to Testing Phase of the /Partia Developmen l t model System acceptance. Transition & End of project Support evaluation Acceptance based on the systems performance and implementation metrics. Table 2. Phase Dependencies of the Framework for System Acquisition From the dependencies of the phases included in this project methodological framework it can be noted that the entire framework is based on reviews and inspections towards the of the system s quality via requirements. Figure 2 presents the relationships and dependencies of the phases composing this framework. Scope resourcing structure Beginning of Implementation Contract Tracking and Oversight Evaluation tracking and oversight Quality Assurance Change Risk Transition & Support End of Implementation Acceptance Post- Implementatio n Review/Evalu ation Phase Post-Impementation Eval. Figure 2. Process model of the Information Systems Acquisition Framework. It must be noted that figure 2 indicates only a few start-to-finish dependencies. This is due to the fact, that most project activities performed by the customer, can be applied in the entire project sphere not depending from other activities. For example, project tracking, risk, quality assurance, change, deliverables, contract tracking and other phases have activities not restricted to a specific period of time during the system s implementation. 6. System Acquisition Framework Milestones and Prime The project framework for system acquisition is supported by a minimum set of milestones, listed in table 3, whose implementation indicates its proper usage. It can be noted that the prime deliverables in this framework are not closely related to the phase s milestones, since this framework depends on reviews and inspections that produce reports instead of documents. Phase Milestone Prime (Documents)
Scope resourcing and technical issues. structure. Contract Tracking and Oversight Evaluation Software project tracking and oversight Quality Assurance Change. Risk Transition & Support Stakeholders identification. Basic System Functionality. Acceptance criteria Elicitation. Acceptance. Creation of Request for. RFP Dissemination. Tender Evaluation. Decomposition Acceptance. Estimations Acceptance HR team definition. HR model. Identification of workflow procedures. staffing. Contract updates (if needed). Tracking Plan. Implementation of Reviews and Inspections. Deliverable inspection. Deliverable acceptance. Accept change. Test change implementat. Risk Acceptance. Risk Plan. Risk Implementation. Transition environment identification. Transition data identific. Transition procedures ident. Transition Acceptance. System Scope Request for. Tender Evaluat. Plan. HR model. structure Contract observance Tracking Plan Progress Reports Deliverable acceptance Quality Plan. Quality observance Change log. Risk Risk implement. Transition Plan. Transition Log. Standards definition. Quality Plan. Quality Reviews. Quality Re- Inspections. Acceptance Acceptance Test. Acceptance test plan. Post- Metrics Evaluation. Metrics Implementatio Know-How n Documentation. Upgrade plan Review/Evalua Upgrade plan. tion Phase Table 3. Phase Milestones and of the Framework for System Acquisition 7. Advantages and Disadvantages for Using the Information Systems Acquisition Framework The ISAMF has been developed though an analysis and integration of the best practices from 43 project methodologies. This background can be considered an advantage towards using the frameworks since it encloses trends and best practices from the international project community. Another advantage can be considered the fact that the framework excludes the engineering practices from the effort, which could only be understood by engineers, and focuses on the requirements and contract concepts which have be considered critical to the success of a project [20],[21]. Advantages and disadvantages are fuzzy considerations. Disadvantages of this framework can be considered its advantages. The fact probably that the framework is build based on international best practices might not provide flexibility to be used by small organizations. On the other hand the fact that the framework has excluded the engineering practices from the ones well can be considered as an incomplete or insufficient framework to cover the entire concept of a project (acquisition and implementation ). A long list with advantages and disadvantages can be easily generated from an academic point of view, with all of them to be substantially valid and contradictory at the same time. This framework was developed not to be evaluated as a best practice or silver bullet on systems acquisition. It has been developed to serve as a tool to the majority of software intensive organizations that have no luxury to study, evaluate, analyze, adjust or even compose well defined process frameworks.
8. Results The Information Systems Acquisition Framework, as presented in this paper can be considered a ready-to-use, practical and well documented approach towards project and specifically towards acquisition which is a hyper-set of project activities for almost all organizations obtaining technology, and investing in its proper usage. Despite the fact that the framework is composed from the best practices in project internationally, a significant result is the differentiation from the engineering project which is targeted mainly to the suppliers and a group of customers with high technological maturity. Another result is the breakdown of the framework into three process groups. The processes during the planning and the acquisition of the technology, the of the project implementation and the post completion processes. This process categorization created a clear distinction among the project activities, and encourages each manager to enhance the group of process that seems to be more close to the project goals of each project. Once the acquisition and goals have been identified, the project can successfully be implemented. Organizations suffer not because they cannot solve their problems, but simply because they cannot identify them [22] References: [1] Pressman, R., and Ince D., Software Engineering. A practitioner s approach. European Adaptation Fifth Edition, McGraw Hill, 2000 [2] Zahniser, R., Timeboxing for To Team Performance, Software Development, March 1994, pp. 35-38 [3] Curtis, B. et al, People Capability Maturity Model, Software Engineering Institute, Pittsburgh, PA, 1994 [4] Holttzblatt k., and Carmel E., Gathering: The human factor, a special issue of CACM, vol. 38, no. 5, May 1995 [5] Olve N-G,. Roy J., and Wetter M., Performance Drivers: A practical guide to using the Balanced Scorecard, John Wiley, 1999 [6] Reel, J.S, Critical Success Factors in Software s, IEEE Software, May 1999, pp.106-113 [7] Putnam, L., Fitzsmmons, A., Estimating Software Costs, Datamation, vol 25, No, September 1979, pp 89-98 [8] De Marco T., Controlling Software s, Yourdon Press, 1982 [9] Keil M., A Framework for Identifying Software Risks, CACM vol.41, no.11, November 1998, pp 76-83. [10] Bach J., The highs and lows of change control, Computer vol. 31, no. 8, August 199, pp.113-115 [11] Dewhurst E., Total quality and information technologies: an exploration of the issue, International Journal of Quality and Reliability, vol. 16, no. 4, pp. 329-405, 1999 [12] Markopoulos E., An Empirical Adjustable Software Process Assessment Model for Software Intensive Small and Medium Size Enterprises, 7th European Conference on Software Quality, Conference Notes, Finland, pp16-19, 2002 [13] Royce W. W., Managing the Development of Large Software Systems, Proceedngs of IEEE WESCON, pp 1-9, 1970 [14] Boehm B., A Spiral Model of Software Development and Enhancement, IEEE Computer, vol. 21, no. 5, May 1988 pp 61-72 [15] Davis A., and Sitaram P., A Concurrent Process Model for Software Development, Software Engineering Notes, ACM Press, vol. 19, no. 2, Aprl 1994, pp. 38-51 [16] Humphrey W., Managing The Software Process, Addison Wesley, 1989 [17] SEI., SE-CMM, Technical Report, SECMM- 95-01, CMU/SEI-95-MM-003, 1995 [18] SEI., SA-CMM, Technical Report, CMU/SEI- 99-TR-002, ESC-TR-99-002, 1999 [19] NASA., NASA Software Acquisition Life Cycle, NASA Office of Safety, Reliability, Maintainability and Quality Assurance, Washington D.C. 229-1988. [20] ISO/IEC 12207:1995, Information Technology-Software life cycle processes Amendment 1, 2002 [21] ISO/IEC 15504, Draft Standard for Software Process Assessment, 1997. [22] Gartner, J. Renewal of Organizations., 20th Annual Meeting of the Board of Trustees, Midwest Research Institute, Kansas City, MO. May 3, 1965