18th International Logistics Congress ILC 2002 6-9 October, 2002 Munich – GERMANY
Implementation of Software Subcontracting Management methods and standards in the Development and Maintenance of Software Intensive Logistics Systems Evangelos Markopoulos Managing Director EMPROSS Strategic IT Consultants Maroussi, ATHENS, GREECE www.empross.gr
[email protected] Abstract: As the complexity of the information systems that support software intensive organizations increases, the management of the software development and maintenance process will also be increasing exponentially especially for the organizations without structured internal IT units. The field of logistics has an impressive constant increase, business and technology wise. As the concept of logistics goes further than inventory, or warehouse management, information technology will hold a dominant role in every modern logistic process. Unfortunately not all logistic organizations or business units have logisticians with software engineering capabilities, or internal (organizational) technology departments through which they can receive the needed help towards the implementation and maintenance of their software intensive logistics systems. Subcontracting the development and maintenance of logistics systems is a common compulsory practice. Many organizational (competitive advantage, know-how, etc) and functional (maintainability, usability, reliability, etc) critical issues are placed on risk once the logistic software system is not controlled by the organization itself. On the other hand developing and maintaining software systems can be quite expensive and risky for logistics organizations. The software subcontracting management is an issue that has troubled not only the logistics organizations but for all software intensive organizations. The software engineering community on the other hand has studied this issue and over the years developed a number of standards, methods, guidelines and practices than can support the subcontracting process towards the benefit of both parties. The Capability Maturity Model (CMM) is considered the most comprehensive process maturity framework with significant approaches to the software subcontracting management issue in developing, maintaining and acquiring software systems. Other models such as the SPICE (Software Process Improvement for Capability dEtermnation) and the ISO 9000-3 (guideline for the ISO 9001 towards software development) approach more (SPICE) or less (ISO) the subcontracting process. Besides the ‘brand-name’ standards methods and guidelines for software subcontracting management, there are many less popular practices developed around the world with significant simplicity and effectiveness. This paper aims to present a number of critical issues logistic organizations need to consider before selecting a subcontracting management approach. Such issues deal with the quality of the delivered logistic product or service, but above all with the risks associated in the subcontracting process. Also in this paper the term ‘subcontracting’ is fully defined and proves that the subcontracting process includes contract management, risk management, contingency planning, change management, and many other fine concepts such as intellectual property management etc. Besides the theoretical part, an empirical subcontracting management models is also presented in this paper along with results from logistics (and other) organizations that have adopted it. This model takes into considerations the international best practices and adjusts them to the needs of logistics organizations, giving logisticians the capability and knowledge required to manage work done for them (fully or partially) by third parties. Logisticians and logistic organizations need not to be information technology experts in order to support their products and services in a competitive marked. Following and adjusting international best practices to their needs can be unpredictably rewarding.
Key Words: Logistic Systems, Software Systems, Subcontracting Management, Software Engineering. Page 1 of 21
1.0 INTRODUCTION Information Technology has been considered as the science of the future, as the upcoming engineering discipline, and as the profession without limits. All of those perceptions of the IT field are quite correct, but in order to be absolutely correct, Information Technology requires business applications on which it can demonstrate its capabilities and benefits. Some of the classical application domains that initially supported by IT systems was the financial sectors (banking, accounting, etc). The need to automate whatever was managing money seemed to be of top priority. After covering almost all of the variations a financial application can have, programmers aimed to conquer vertical markets in an attempt to develop specialized products in almost every field that could use the help of automation. Starting from the classical business sectors such as trade and retail, software reached upcoming professional fields such as the logistics. The concept of logistics a few years ago was based on the management of a warehouse or the management of inventory within a warehouse. Unfortunately this perception about the field of logistic still remains within the ‘experienced’ logisticians. Today the field of logistics has taken a totally new meaning. The globalizations has transformed the logistics concept entirely, ands has increased tremendously the complexity of the modern logistics services. To cope with this complexity the help of information technology is needed more that ever. Software systems that can address specific and ‘virgin’ issues are developed literally every minute, in order to cover the demand of a market with exponential growth.
2.0 THE IMPORTANCE OF IT IN LOGISTICS The field of logistics expands its scope as the needs for better organizational and operational practices rising in organizations and in the society in general. The processes and activities involved in a logistic system tend to be more complex as the expectations constantly increase. Dealing with all logistic activities and processes minute by minute, is something that cannot be done without the help of information technology (IT). IT actually pus in practice and supports the completeness of today’s logistic systems. The computation of complex algorithms, and the processing of tremendous amounts of data in a constant base, handled by IT systems, offers valuable, or vital decision support, and monitoring guidance to logistics systems. Information technology can be characterized as the unknown hero behind every modern logistic system. No one would try today to design and use logistic systems without having the confidence that technology could support them. Modern systems begin and end with information systems. In order to catch up with today’s needs and expectations, any scientific discipline shall take advantage of the technological innovations but also to compromise with the limitations technology can offer. Technological advancements support and initiate the progress in all scientific fields. Once technologies like GIS (Geographic Information Systems) or GPS (Global Positioning Systems) made happen, they changed completely the idea and the definition of logistic processes and capabilities. As technology advances the field of logistics will be moving into new generations that no one can imagine today. Problems that seem impossible to be solved today will be possible to be resolved when technology permits. Figure 1 presents the parallel evolution of the Information Technology and Logistics disciplines. Page 2 of 21
State-of-the Art Technologies. - GIS / GSM / GPS - Wireless Networks - Extranets - Satellite Communication
00s↑ 00s Time 90s
Conventional Technologies. - HW/ Evolution - WorkStation Applications
Adaptation Variation over the time
80s Logistics Adaptation of Technology 70s Information Technology Evolution Figure 1. Evolution of the Information Technology and Logistics Disciplines
It must be noted that technology today permits much more than what is widely known. The problem is that the realization and implementation of many existing technological achievements into logistics systems requires financial investments and skilled personnel to run and support technologies such as: satellite communication, wireless networks, etc.
3.0 IT LOGISTIC SYSTEMS 3.1 What Differentiates Logistic Systems from other Software Systems? Every software system designed to cover a professional or scientific field has its own characteristics that differentiate it form other software systems. In logistic software systems, many characteristics from other categories of software systems can be found. Issues like computational speed, algorithmic complexity, or even storage management (searching, sorting, retrieving, updating, etc) are present in almost all modern logistic systems too. After all no logistic system can be considered reliable and complete if such non-functional characteristics do not exist, at least to an acceptable degree. From a number of functional and non-functional characteristics that can be implemented in a software system, two conceptual actually characteristics can be considered as the ones that can differentiate logistics IT systems from other professional systems. These two are the Users and the Technology. Users Users of logistic systems can be considered mainly the blue-color workers. Developing logistic systems, especially the ones that operate in warehouses, which cannot provide user-oriented and user-friendly interfaces is not characterized as a wise approach. The processes involved in a logistic system are like a chain, covering many operational phases were most of them performed by not computer-literate personnel. Loosing the consistency, correctness and accuracy that derives from the proper usage of a system can easily create the ‘Domino’ effect on errors which can generate in turn unreliable results, ending up to inaccurate decisions, support and even corporate strategy. If a function cannot be interpreted through the appropriate user-interface to those who will be called to support and use the system, it is better not to implement it at all.
Page 3 of 21
Besides the confusion a non-user friendly interface can cause, another issue that can come up is the speed of using such an interface. Assuming that there are users who are loyal to the company and try to support the company’s policy and systems, the time that could take them to correctly perform an operation might not end up to be the time expected and accepted by the company. Logistic software systems shall devote a major part of their development time implementing user interfaces for almost all types of users that could work on the system. One method to develop usable systems is to execute a successful requirements analysis phase prior the development, and to keep on using usability metrics in the development and operational phases of the software, identifying this way the enhancements for the new releases. Technology Many impressive IT systems that have been developed over the time, in various professional fields, required high algorithmic complexity but very basic technological support. An IT system is composed of two parts, the software and the hardware. When referring to technology, many users and professionals mean the hardware behind the systems. Even that this is not the right consideration, for that shake of the argument it will be accepted for the moment. Technology is not a major issue or problem to be tackled in the development of IT systems in most of the professional fields (banking, financial, trade, manufacturing, etc). Besides the medical and the military fields, the field of logistics embeds most of the state of the art technologies in the IT systems supporting it. From the basic remote terminals, operating in warehouses for item management, to the servers and networks, operating in the distribution centers for operational management, all the way up to the satellite communication and GPS technologies used for tracking management, the hardware behind a logistic software can heavy with significant variations in its complexity. Figure 2, presents the differential factors between logistics systems and other software systems
Technology Maturity
Users Maturity
Average Operational Maturity
Minimum Operational Maturity
Maturity Curve Figure 2. Differential Factors in Logistics Software Systems
What is more complex than the hardware used in such logistic systems is the integration of all those technologies used to support such systems. Hardware set up restrictions that need to be overcome with specific source code (programming), or software restructure, is a couple of the main considerations of technology integration. Putting the show on the road had always not been an easy task. 3.2 Diversity of IT Logistic Systems. Supporting the field of logistics with software and IT systems in general, is an initiative and goal of many software firms aiming to expand their development skills in upcoming professional and scientific areas.
Page 4 of 21
The diversity of processes existing in a logistic system, as well as the uniqueness of those processes, were in most cases are designed to fit the needs of handling a specific product, or to meet specific corporate guidelines, is very wide. No software system can be considered today strong enough to cover a logistics model, or complete process. As long as there are users in a process, as long as technology provides more efficient and reliable solutions, and as long as the goal is to minimize costs, then the software developed to support the field of logistics has to constantly be adjusted to the trends of the field and the needs of the customers.
4. THE SOFTWARE DILEMMA Developing Information Technology systems today is actually the development of software systems. An IT system without software applications is like a bunch of iron junk, or like a body without a soul. Software acquisition or development can be obtained by many ways, varying among the developing methods and practices Each system can be characterized as a unique one based on its functionality and algorithmic approach on both computations and operations. Almost every company has its own policy based on the type of customers and on the type of logistic services they either offer or follow. A specific (commercial or custom made) software system today rarely matches the needs of more than one organization. Actually there is no standard process for building logistics software systems. Companies with structured IT departments build their own software. On the other hand, many companies chose subcontractors to build their systems. It all depends on the needs and the capabilities of the organization. Developing a software system is more a corporate strategy than technical capability. 4.1 Software Development Strategies Two actually can be considered as the basic strategies for developing software, covering more or less the majority of the ways logistic systems are build; the In-House Development and the Outsourced Development Specifically: In-House Development. Building software in-house means that the company, which will be using the system, develops the entire software system with internal resources (a structured IT department). Outsourced Development. Outsourcing the development of a software system means that subcontractors (definitely software development firms, and not consultants) will do the development of the system on behalf of the organization. Graph 1 presents the major activities outsourced to IT organizations.
4.2 Pros and Cons among the development strategies None of the strategies for developing logistics software can be considered as the best one, the silver bullet or the standard process. There are positive and negative factors in each one of them.
Page 5 of 21
Percentage of Outsourcing Activities
Single Application 9%
Business Process 2%
Data Center 16%
Applications Maintenace 18% Applications Development 24%
Network Management 15%
Help Desk 16%
Graph 1. Major Outsourcing Activities
Table 1 presents the major positive and negative factors of both software development strategies. The negative factors in both strategies can be managed if software engineering and project management methodologies, tools and techniques are in place during the development. Development Strategy In-House Development
Outsourcing Development
Positive Factors
• • • • •
Negative Factors
Software security • Implementation Cost Know-how assurance • Implementation Time Low maintenance cost • Lack of Innovation Low enhancability cost No dependencies from third parties
• No need to support technical • Uncontrolled
software staff security • No need to develop technical • No Know-how assurance expertise • High maintenance cost • Low operational cost • High enhancability cost • Dependencies from third parties
Table 1. Positive and Negative Factors of Software Development Strategies
4.3 In House Software Development 4.3.1 In-House Software Development Approaches The following list presents three major In-House Software development approaches . • • •
Commercial Products COTS (Commercial-Of-The-Shelve) Custom Development Page 6 of 21
Specifically Commercial Products One approach to develop a software system is to rely basically on commercial products, which are mainly called the ‘Logistic ERPs’. These products support many of the logistic activities and in most of the cases provide more functionality to the user than the requested. Implementing a logistic system based on a commercial product is a process than can be done either with internal organizational resources, which is considered as in-house development (parameterization), or with the help of external consultants, which is considered as outsourcing the implementation, after buying software and licenses. Commercial Of The Shelve (COTS) COTS is the new upcoming approach towards developing software systems. Today’s major trend in the IT society is the concept of reusability. Over the years many impressive, functional and user-friendly programs had been written. Identifying and integrating those small or big (sometimes) software systems developed to support one or maybe a few business and/or logistic processes, can be the basis for developing totally new, multifunctional, reliable, tested, and inexpensive software systems. The main concept in COTS is to identify the needs of the software system with good requirements engineering techniques. Once the ‘What’ has been understood, the ‘How’ seems easier. COTS based systems can be developed with internal organizational resources, which is considered as in-house development (integration), or with the help of external integrators, which is considered as outsourcing the implementation.
Custom Development A classic software development approach. Developing new software has many advantages and disadvantages as well. A major advantage is that what is developed is focused on what is needed. A major disadvantage is maintainability (if not software engineering practices have not been followed during the development). The cost of developing custom made software depends upon the processes used in the development. Mature processes might bring up the development cost, but reduce the maintenance const. Immature processes do the opposite of what the mature processes do. It is all a mater of quality, engineering and strategy. Custom development can be implemented with internal organizational resources, which is considered as in-house development, or with the help of external developers, which is considered as outsourcing the implementation.
7.2.2 Pros and Cons among the development approaches None of the approaches for developing logistics software can be considered as the best one, the silver bullet or the standard process. There are positive and negative factors in each one of them. Table 2 presents the major positive and negative factors of each software development approach. Development Approach Commercial Products
Positive Factors
• • • •
One technology One provider One group of experts Well tested system
Negative Factors
• • • •
One provider One group of experts One technology Dependability to the provider Page 7 of 21
Commercial Of the Shelve (COTS)
Custom Development
• Variety of technologies • Software integrity • Independence form the • Risky Maintainability providers • Difficult contact management • Many groups of experts • Easy implementation • Well tested components • • • • •
Software completeness High maintainability Know-How assurance Software security Provider independence
• Lack of expertise • Maintenance of a development team
• Dependability of employees
Table 2. Positive and Negative Factors of Software Development Approaches
5. THE BEST CASE SCENARIO Usually when describing alternatives in developing software systems, one might start with the worst-case scenario in order to reach the possible solutions that might exist, and from them to select the best-case scenario among the choices. In the field of logistics, this evaluation process comes the other way around. Te worst-case scenario in obtaining software systems is the common practice, where the best-case scenario is the exception. If the definition of the base-case scenario could stand for the cases were organizations have structured IT units supporting them with software systems, then the possibility for identifying such organizations would very low, especially in the small and medium size enterprises. Organizations with structured IT departments have the capability and luxury to developed or integrate any application under any complexity or peculiarity, but unfortunately this is surrealistic situation in a common logistics organization. Today the IT departments in logistics organizations, especially in the small and medium size organizations, are staffed with ore or two IT employees with duties mainly to support the hardware (which is only PCs), and the office applications (which is the MS-Office, or other administration support software). Decisions on whether the organization shall invest in an IT system, are never taken, or not even suggested by the IT people. IT seems like a cost center than a profit center, to many well established logistics organizations. The IT situation as it is formed today in the logistics sector is based on fear and ignorance. The not technocrat managers who wish not to introduce and support to new technologies with permanent personnel cause organizational fear. Ignorance is caused by the ‘management by voice’ practices that seem somehow to still work in some organizations. Both fear and ignorance by logistics managers bring catastrophic results in the investments (financial and procedural) towards Information Technologies. Buying the most successful logistics software in the market does not mean that it will work for every organization. On the other hand outsourcing a project does not guarantee that the delivered software will be the one desired by the organization.
Page 8 of 21
6.0 SUBCONTRACTING AS THE ALTERNATIVE IN SOFTWARE ACQUISITION / DEVELOPMENT The development of software projects as it has clearly been stated above is a risky and costly issue. Developing software ‘in-house’ requires a well structured IT department which very few organizations can afford. On the other hand purchasing software ‘of the shelve’ has a variety of risks and considerations. Outsourcing as it has been described, is the ‘new’ trend in the implementation of software systems and IT systems world wide. Organizations that have not the capability to develop or manage internally their IT strategy and investments turn to outsourcing approaches. Outsourcing means dealing with subcontractors. Subcontractors are the organizations that take part or the entire project, for partial or total development despite the development approach. Subcontracting can be applied in all the ‘In-House Development’ approaches described in the previous sections Table 3 describes the subcontracting process interpretation in the development approaches Development Approach Commercial Products
Subcontracting interpretation The subcontractor has the responsibility for the selection and installation management of a commercial product for the organization (customer). This approach is selected when there is in the market a commercial product that matches the needs of the customer. The subcontractor takes as task the project management activities on behalf of the customer.
Commercial Of the Shelve (COTS)
The subcontractor has the responsibility for the selection of the technologies required to build a system according to the needs of the customer, and integrates those technologies in order to created the final solution. This approach is selected when there is not a specific product in the market that can cover the needs of an organization. In this case the subcontractor takes the integration and parameterization process of the components the will make up the desired solution
Custom Development
The subcontractor has the responsibility for the entire development of a solution that cannot be found in a product, or in the integration of a number of products. The subcontractor in this case takes the total development of the software system.
Table 3. Subcontracting Process Approach Interpretations
The concept of subcontracting is nothing more and nothing less than transferring the IT needs of an organization to a third party for total development (by any development approach). The positive and negative factors of subcontracting work activities, regardless the development approach, are not much different than the ones presented in the n-House Development strategy.
Page 9 of 21
Commercial products for example are well-tested solutions but very risky on the aspect of matching the organizations needs. On the other hand, COTS are more flexible solutions but very risky on the quality of he integration. Finally custom development by third parties is a too risky approach if the organization does not have an internal or external project manager.
7.0 SUBCONTRACTING RISKS At a first glance, the subcontracting approach seems to be a ‘silver bullet’. Transferring the risk of developing software systems and IT systems in general to third parties is a trend today to new and upcoming managers. On the other hand, more experience managers, rarely subcontract an IT task without carefully examine the hundreds of risks that are associated with this approach. Subcontracting means that the organization transfers control and decision making to others. The organization has to take many percussions and management methodologies in order to monitor the subcontracting process. Having identified the risks that come with the subcontracting approaches, and supporting them with a methodology that could be mandated to the subcontractors has many benefits. Some of them are listed. • The subcontractor identifies the manager’s expertise in the subcontracting approaches. • The subcontractor has rules to follow • The subcontractor works under a monitoring process • The subcontractor is tied up to a well-structured contract. Figure 3 presents the Major Risk Management categories in the Subcontracting Management Process Subcontracting Risks Categories Planning
Legal
Engineering Direct Risks
Indirect Risks Financial
Tracking
Quality
Figure 3. Subcontracting Management Risks Categories
These benefits can be high risk if not interpreted properly. Specifically: If the subcontractor identifies the weakness of the customer’s manager to monitor hit/her work, then the project can be, and usually is, out of control. The subcontractor can, and usual does, come up with any kind of excuses for project delays and for budget overruns. In other words, subcontractors ‘love’ to be against non-technical managers. Another high risk in subcontracting a project is the lack of development rules that could be proposed to the subcontractor. The subcontractor’s heve his or her own way of developing projects. Their way is rarely in acceptance with the way of work an organization wants the subcontractor to follow. Not having a development methodology to mandate to the subcontractor, the organization will have to accept the way of work the subcontractor proposes. Unfortunately the subcontractors development method varies upon the availability of their resources, or the budget of the project. Page 10 of 21
In many cases organizations have not a development methodology to suggest, but they do have a monitoring process to propose or to mandate. In those cases the subcontractor is free to work based on its own development model, but is forced to agree in an monitoring process which is composed of inspections, review, presentations, and walkthroughs of his/her development process and work progress. Finally if the organization does not have this management maturity in the development and tracking processes, another alternative is to work and mandate a well-defined contract between the two parties. There are many was to develop ‘smart’ contrast. Today, contract management is emerging to a new science. Software contract standards and guidelines are available in the international bibliography. It only takes management maturity and responsibility to go through the trouble of developing such contracts. The benefits-risks than mentioned in the above paragraphs are only a few of the critical ones. Subcontracting is a high-risk decision which requires more complex management activities than the ones needed to develop an IT system.
8.0 SUBCONTACTING STANDARDS, METHODS AND GUIDELINES There are no models in software engineering dealing directly and specifically with the concept of subcontracting. Comprehensive software engineering models, standards and guidelines cover the subcontracting concept among their processes in their maturity levels or process dimensions Logistics managers can identify though the available software engineering standards strate of the art, or simple and practical subcontracting management processes. Some of the major software engineering standards dealing with subcontracting processes are the following: • Capability Maturity Model for Software (CMM) • Software Process Maturity and Capability dEtermination (SPICE) • International Standards Organization (ISO) A brief description of each model will be presented in the following sections along with the models approach in the subcontracting issue. 8.1 Subcontracting Management in the CMM The Capability Maturity Model for Software (CMM) is a framework that describes the key elements of an effective software process. The CMM describes an evolutionary improvement path from an ad hoc, immature process to a mature, disciplined process. 8.1.1 Structure of the CMM The CMM is composed of five maturity levels. With the exception of Level 1, each maturity level is composed of several key process areas. Each key process area is organized into five sections called common features. The common features specify the key practices that, when collectively addressed, accomplish the goals of the key process area.
8.1.2. Definition of the CMM Maturity Levels As organizations establish and improve the software processes by which they develop and maintain their software work products, they progress through levels of maturity. Figure 4 shows the five maturity levels of the CMM. Page 11 of 21
Optimizing (5)
Continuously Improving Process
Managed (4)
Predictable Process
Defined (3)
Standard, Consistent Process
Disciplined Process
Repeatable (2) Initial (1)
Figure 4. The Five Levels of Software Process Maturity
Level 1 - The Initial Level The software process capability of Level 1 organizations is unpredictable because the software process is constantly changed or modified as the work progresses (i.e., the process is ad hoc). Schedules, budgets, functionality, and product quality are generally unpredictable. Level 2 - The Repeatable Level The software process capability of Level 2 organizations can be summarized as disciplined because planning and tracking of the software project is stable and earlier successes can be repeated. The project's process is under the effective control of a project management system, following realistic plans based on the performance of previous projects. Level 3 - The Defined Level The software process capability of Level 3 organizations can be described as standard and consistent because both software engineering and management activities are stable and repeatable. Within established product lines, cost, schedule, and functionality are under control, and software quality is tracked. Level 4 - The Managed Level The software process capability of Level 4 organizations can be described as predictable because the process is measured and operates within measurable limits. This level of process capability allows an organization to predict trends in process and product quality within the quantitative bounds of these limits. Level 5 - The Optimizing Level The software process capability of Level 5 organizations can be characterized as continuously improving because Level 5 organizations are continuously striving to improve the range of their process capability, thereby improving the process performance of their projects.
Page 12 of 21
8.1.3 The Key Process Areas of the CMM Each key process area identifies a cluster of related activities that, when performed collectively, achieve a set of goals considered important for enhancing process capability. The key process areas have been defined to reside at a single maturity level. Each key process area comprises a set of goals that, when satisfied, stabilize an important component of the software process. Achieving each level of the maturity model institutionalizes a different component in the software process, resulting in an overall increase in the process capability of the organization. Table 4 presents the Key process Areas for each CMM Maturity Level Maturity Level
Key Process Areas
INITIAL (Level 1)
No Key Process Areas
REPEATABLE (Level 2)
1.Requirements Management 2.Software Project Planning 3.Software Project Tracking 4.Software Subcontracting Management 5.Software quality Assurance 6.Software Change Management
DEFINED (Level 3)
1.Peer Reviews 2.Inter-group Coordination 3.Software Product Engineering 4.Integrated Software Management 5.Training Program 6.Organization Process Definition 7.Organization Process Focus
MANAGED (Level 4)
1.Software Quality Management 2.Quantitative Process Management
OPTIMIZING (Level 5)
1.Process Change Management Technology 2.Management Defect Prevention
Table 4 Key Process Areas of the CMM Maturity Levels
The key process areas are supported by key practices which demostrate the way the model shall be implemented. The key practices in each key process area, on the other hand, are organized by a set of common features. The common features are attributes that indicate whether the implementation and institutionalization of a key process area is effective, repeatable, and lasting. The common features also group and order the key practices in a sequence helpful for organizations using them. The five common features are listed below: Commitment to Perform Commitment to perform describes the actions the organization must take to ensure that the process is established and will endure. Commitment to Perform typically involves establishing organizational policies and senior management sponsorship. Ability to Perform Ability to Perform describes the preconditions that must exist in the project or organization to implement the software process competently. Ability to Perform typically involves resources, organizational structures, and training. Page 13 of 21
Activities Performed Activities Performed describes the roles and procedures necessary to implement a key process area. Activities Performed typically involve establishing plans and procedures, performing the work, tracking it, and taking corrective actions as necessary. Measurement and Analysis Measurement and Analysis describes the need to measure the process and analyze the measurements. Measurement and Analysis typically includes examples of the measurements that could be taken to determine the status and effectiveness of the Activities Performed. Verifying Implementation Verifying Implementation describes the steps to ensure that the activities are performed in compliance with the process that has been established. Verification typically encompasses reviews and audits by management and software quality assurance.
8.1.4 Definition of Software Subcontracting Management in CMM The purpose of Software Subcontract Management is to select qualified software subcontractors and manage them effectively. Software Subcontract Management involves selecting a software subcontractor, establishing commitments with the subcontractor, and tracking and reviewing the subcontractor's performance and results. These practices cover the management of a software (only) subcontract, as well as the management of the software component of a subcontract that includes software, hardware, and possibly other system components. The subcontractor is selected based on its ability to perform the work. Many factors contribute to the decision to subcontract a portion of the prime contractor's work. Subcontractors may be selected based on strategic business alliances, as well as technical considerations. The practices of this key process area address the traditional acquisition process associated with subcontracting a defined portion of the work to another organization. When subcontracting, a documented agreement covering the technical and no technical (e.g., delivery dates) requirements is established and is used as the basis for managing the subcontract. The work to be done by the subcontractor and the plans for the work are documented. The standards that are to be followed by the subcontractor are compatible with the prime Contractor's standards. The software planning, tracking, and oversight activities for the subcontracted work are performed by the subcontractor. The prime contractor ensures that these planning, tracking, and oversight activities are performed appropriately and that the software products delivered by the subcontractor satisfy their acceptance criteria. The prime contractor works with the subcontractor to manage their product and process interfaces. Table 5 presents the total of key practices in each category, that compose the requirements of subcontracting management in the CMM.
Page 14 of 21
Common Feature Goals
Number of Key Practices 4
Commitment to perform
2
Ability to perform
3
Activities performed
13
Measurement and analysis
1
Verifying implementation
3
Table 5: Key Practices in the CMM Subcontracting Management Key Process Area
8.1.5 Subcontracting Management Activities in the CMM The key practice who characterizes the actual steps to be performed towards the fulfillment of the requirements in a key process area are the ones stated in the ‘activities’ category. Table 6 presents the Subcontracting Management activities of the CMM S/N
Key Practice Activity
1
The work to be subcontracted is defined and planned according to a documented procedure.
2
The software subcontractor is selected, based on an evaluation of the subcontract bidders' ability to perform the work, according to a documented procedure.
3
The contractual agreement between the prime contractor and the software subcontractor is used as the basis for managing the subcontract.
4
A documented subcontractor's software development plan is reviewed and approved by the prime contractor.
5
A documented and approved subcontractor's software development plan is used for tracking the software activities and communicating status.
6
Changes to the software subcontractor's statement of work, subcontract terms and conditions, and other commitments are resolved according to a documented procedure.
7
The prime contractor's status/coordination reviews management.
8
Periodic technical reviews and interchanges are held with the software subcontractor.
9
Formal reviews to address the subcontractor's software engineering accomplishments and results are conducted at selected milestones according to a documented procedure.
10
The prime contractor's software quality assurance group monitors the subcontractor's software quality assurance activities according to a documented procedure.
management conducts periodic with the software subcontractor's
Page 15 of 21
11
The prime contractor's software configuration management group monitors the subcontractor's activities for software configuration management according to a documented procedure.
12
The prime contractor conducts acceptance testing as part of the delivery of the subcontractor's software products according to a documented procedure. Table 6: CMM Subcontracting Management Activities
8.2 Subcontracting Management in the SPICE The purpose of this part of the SPICE International Standard is to document the set of practices fundamental to good software engineering, which can be used by the other parts of this International Standard. The model contained in this document describes processes that an organization may perform to acquire, supply, develop, operate, evolve and support software and the generic practices that characterize the capability of those processes. A set of practices forms the lowest level of the architecture. The architecture organizes the practices into a number of categories using two different approaches. The architecture distinguishes between: • base practices which are the essential activities of a specific process, grouped into processes and process categories by the type of activity they address; • generic practices, applicable to any process, which represent the activities necessary to manage a process and improve its capability to perform. The model categorizes processes into five process categories. 1.
2. 3.
4. 5.
The Customer-Supplier process category consists of processes that directly impact the customer, support development and transition of the software to the customer, and provide for its correct operation and use. The Engineering process category consists of processes that directly specify, implement, or maintain a system and software product and its user documentation. The Project process category consists of processes which establish the project, and co-ordinate and manage its resources to produce a product or provide a service which satisfies the customer. The Support process category consists of processes which enable and support the performance of the other processes on a project. The Organization process category consists of processes which establish the business goals of the organization and develop process, product, and resource assets which will help the organization achieve its business goals.
Each process in the model is described in terms of base practices, which are its unique software engineering or management activities. Process categories, processes, and base practices provide a grouping by type of activity. Evolving process capability is expressed in terms of capability levels, common features, and generic practices. A capability level is a set of common features (sets of activities) that work together to provide a major enhancement in the capability to perform a process. Each level provides a major enhancement in capability to that provided by its predecessors in the performance of a process. They constitute a rational way of progressing through the generic practices.
Page 16 of 21
Capability levels provide two benefits: they acknowledge dependencies among the practices of a process, and they help an organization identify which improvements it might perform first, based on a plausible sequence of process implementation. There are six capability levels in the model.
• • • • • •
Level 0; Not-Performed Level 1; Performed-Informally Level 2; Planned-and-Tracked: Level 3; Well-Defined: Level 4; Quantitatively-Controlled: Level 5; Continuously-Improving:
In SPICE, the concept of subcontracting management is covered in the Work Products Definitions of the model Table 7 describes the references to subcontracting process in the SPICE Model. WP Characteristics
WP Classification number 49
WP Classification
WP Description
3.2 (Reporting)
51
3.2
Subcontractor • List of potential or supplier subcontractor/suppliers history record • Qualification information • Identification of their qualifications • Past history information when it exists Contract • identifies any interfaces to (product or independent agents and service) subcontractors
109
3.2
Contract • Responsibility review record subcontracted work + (31)
for
Table 7: Subcontracting References in the SPICE Model
8.3 Subcontracting Management in ISO Within the family of the ISO 9000 standards, there is the ISO 9000-3 Guideline that supports directives towards the development, procurement, and maintenance of software systems. The ISO 9000-3 is considered as a well defined set of processes that significantly support the quality concept in software systems. The development of this specialized guideline was the result of many requests to the International Standards Organizations towards supporting the Software Systems and the IT systems in general with an Quality Management standard. ISO 9000-3 was developed to be an extension to the ISO 9001 standard that supports the process of design, development, production and installation activities. Figure 5 presents the position of the ISO 9000-3 guideline within the ISO standards family. The same diagram helps very much the clarification between ISO 9003 and ISO 9000-3, which is a very common misconception. The evaluation of an organization or a software process based on the ISO 9000 standard, and specifically under the ISO 9000-3 guideline, is performed by evaluating the correspondence of the software process upon the Quality Elements of the standard. Page 17 of 21
ISO 9000 Standards Family
ISO 9001 Model for the Quality Assurance on the Design, Development, Production, Installation of Products and Services
ISO 9002 Model for the Quality Assurance on the development and Installation of Products and Services
ISO 9000-3 Guideline for the Implementation of ISO 9001 in the software design, development and maintenance.
ISO 9003 Model for the Quality Assurance on the final inspection and test.
Figure 5: Part of the ISO Family Standards
The ISO 9000-3 guideline is a special interpretation tool of the ISO 90001 towards the quality assurance of the software process. Table 8 presents the twenty (20) quality elements of the ISO 9000 Standard. S/N 1
Quality Elements Management
2
Quality System
3
Contract Review
4
Design Control
5
Document and Data Control
6
Purchasing
7
Control of Customer Supplied-Product
8
Product Identification and Traceability
9
Process Control
10
Inspection and Testing
11
Control of Inspection, Measuring and Test Equipment
12
Inspection and Test Status
13
Control of Nonconforming Product
14
Corrective and Preventive Action
15
Handling Storage, Packaging, Preservation and Delivery
16
Control of Quality Records
17
Internal Quality Audits
18
Training
19
Servicing
20
Statistical Techniques Table 8: Quality Elements in the ISO 9001 Standard Page 18 of 21
Brief Description of the Quality Element ‘Purchasing’ (Article 4.6) which covers the concept of subcontracting management
Purchasing (4.6) Subcontracting management •
General (4.6.1) - Subcontractors / Purchaser’s SW conforms with requirements. - Contract requirements on subcontractor’s procedures - Audit Subcontractor - Check subcontractors past performance - Witness review and testing - Test and review deliverables from the subcontractor
•
Evaluation of Subcontractors (4.6.2) - Audits - Review Plans - Witness reviews and testing - Supplier approval as they are produced - Maintain a list of acceptable subcontractors
•
Purchasing Data (4.6.3) - Requirements on the subcontractors development process be documented
•
Verification of Purchased Product (4.6.4) - Documentation about the decision for each development tool that was purchased
9.0 BACK TO LOGISTICS From the heavy engineering management processes described in the previous sections, one could conclude that this is an IT paper, rather than a logistics one. Actual it might seem like that, but this is no the case. Logistics is useless if not supported by IT systems. Managing logistic processes by pen and paper is like refusing the progress and the evolution of the field. The complexity of today’s logistics processes can be solved only with quality logistic IT systems and specialized logistics software. The distance from the need of a quality logistic system to the development of one of the is very large, full of risks and investments on any kind (human resources, financial, etc). Logistics managers need to expand their expertise also to the IT field. Understanding the difficulties for them to become also systems developers, it is suggested to take a simple route and become integrated managers. A modern manager is what is called an ‘integrated’ manager. This integration is based actually in two aspects. One is the expertise on the field a manager is called to serve, and the other one is the expertise in managing IT projects. No manager can feel secure for either his/her position in a company or for his/her management IT decisions if not being able at least to follow the software process management cycles.
Page 19 of 21
This paper can be more practical to logisticians than other papers who describe and define new logistics algorithms, or concepts. No algorithm today can me implemented without an IT system, and no IT system can run without proper management during its development period, and its life cycle in general. Subcontracting logistics IT systems is very common today. Unfortunately, most logistics managers have no idea of what it means to run a subcontractor, and a project based on this approach. The information technology community developed and integrated subcontracting management models, standards, guidelines and principles, only to help the non-technical managers. Actually there is no need for system engineers, IT managers, and technical managers in general, to follow subcontracting processes, since this specific knowledge is part of their business and job description. In other words the whole subcontracting management concept can be viewed as a gift of the Engineering Community to the business management community. Ignoring the research, the tools, and the methods offered to solve the complexity of corporate development decisions, is definitely like ignoring not only the management principles but also the management ethics. Software subcontracting management, and software process management, are major criteria in the definition of modern logistics managers.
10.0 CONCLUSION The scope of this paper was to introduce the concept of software (and IT systems, in general) subcontracting management process by defining the process, and by supporting it with international standards, methods and guidelines that have been developed to help the no-technical managers. Logistics managers are non-technical managers. The management of modern logistics requires and relies upon software systems and upon the technology in general. Those who pay respect to the science of Logistics shall and have to follow the management trends which in most cases today are mandated, towards not the success of their organizations but towards the survival. As James Martin has stated in his definition of business management transformation, an organization and even most its management staff has to either ‘change’ or ‘die’.
References [Barbacci95] Barbacci, M.; Klein, M.; Longstaff, T.; Weinstock, C. Quality Attributes (CMU/SEI-95-TR-021 ADA307888) Pittsburgh, Pa.: Software Engineering Institute, Carnegie Mellon University, December 1995. [Dunn90] Dunn, Robert H.: Software Quality: Concepts and Plans Publisher: Englewood Cliffs; Prentice-Hall, 1990, [Florac97] Florac, W.; Park, R.; Carleton, A. Practical Software Measurement: Measuring for Process Management and Improvement (CMU/SEI-97-HB-003 ADA325551) Pittsburgh, Pa.: Software Engineering Institute, Carnegie Mellon University, April 1997. [ISO/IEC95] ISO/IEC 15504: Information Technology - Software Process Assessment, June 1995 [ISO/IEC95] ISO/IEC Software Life /cycle Standard, DATAPRO Report, February 1995 [Humphrey89] Humphrey, Watts S. Managing the Software Process. Reading, Mass.: AddisonWesley, 1989. Page 20 of 21
[Markopoulos 98] Markopoulos E., Adjusted Software Quality Models. Proceedings of the 4th Conference of Informatics Applications & Communication, October 1998. Thessaloniki, Greece. [Markopoulos 00a] Markopoulos E., Kaminaris S. Quality Assurance Processes in the Software Development Cycle. Proceedings of the Middle East Quality Forum 2000. June 2000, Nicosia, Cyprus. [Markopoulos 00b] Markopoulos E., Software Quality Improvement using Software Metrics in the Software Characteristics and its Development Processes, Proceedings of the 2nd Conference in Informatics and Telecommunications Quality, February 2000, Athens Greece. [Markopoulos 01] Markopoulos E., Quality Assurance Best Practices for the Implementation of Logistics Information Technology Systems, Proceedings of the 17th Intrnational Logistic Congress, October 2001, Thessalonikis Greece. [MetaGroup99] METAGROUP, IT Performance Engineering & Measurement Strategies Summary of Results, ‘Worldwide IT Trends & Benchmark Report 1999.’ [Overmars01] Overmars J, Swonger C.W., Outsourcing of Applications Software Development and Software Systems Engineering. [online] 2001 [cited 2001 July 10]. Available from: URL: http://www.scx2.com/software/outsourcing.htm [Oberndorf97] Oberndorf, P.; Brownsword, L.; Morris, E.; Sledge, C, Workshop on COTS-Based Systems (CMU/SEI-97-SR-019 ADA332592) Pittsburgh, Pa.: Software Engineering Institute, Carnegie Mellon University, October 1997. [Paulk93] Paulk, Mark C. et al. Capability Maturity Model for Software, Version 1.1 (CMU/SEI93-TR-24, ADA263403). Pittsburgh, Pa.: Software Engineering Institute, Carnegie Mellon University, February 1993. [Perry94] Perry, Dewayne E. & Votta, Lawrence G. “People, Organizations, and Process Improvement.” IEEE Software 11, 4 (July 1994) [Shewhart31] Shewhart, Walter A. Economic Control of Quality of Manufactured Product. New York, N.Y.: Van Nostrand, 1931. (Reprinted in Milwaukee, Wisc.: American Society of Quality Control, 1980.)
About the Author Evangelos Markopoulos completed his undergraduate and graduate studies in Computer Science at USA. As a Computer Scientist he worked (in USA) mainly in ΙΒΜ, Siemens and in Bell Laboratories of AT&T. In his Academic career he taught (Computer Science and Mathematics) as Adjunct Professor, and worked as a research fellow in Research & Development programs, in Universities and Technical Institutions in Greece and aboard (USA, Germany, Spain). He has many lectures, and publications in Greek and in International journals. He is the creator of the IMPROVE Methodologies (Software Development, Project Management, Software Quality Assurance, Software Process Assessment). The IMPROVE products have been implemented in IT organizations and in IT projects with significant success due to their flexibility in their implementation. He is also the Founder of EMPROSS Strategic IT Consultants, the only consultancy firm in Greece purely dedicated only to Software Engineering / Software Quality and Software Project Management.
Page 21 of 21
