Global delivery model is fusion of onsite and offshore models but unlike onsite/offshore model where as in the offshore model the service provider is located at only one place, but in the case of global delivery model the service provider has the offshore development centers all over the globe. The service provider may not have a offshore development center of their own but can use the resources of their partners located all over the globe [3, 34].
According to McCarthy, “Global delivery model means having multiple locations that coordinate to deliver low-cost solutions to customers using consistent processes. While there may have been some degree of sophistication for some of the customers, it must be remembered that the market is maturing. The vendors are maturing and so are the customers.” However, it may be noted that this transition is still at a nascent stage and the companies will require at least two to three years before they attain a ‘fully developed sophisticated global delivery model’, he said.
Figure 4.6: Relationship in Global Delivery Model [15]
As the Global delivery model is a combination of both the onsite and offshore delivery models, the work of the onsite center is that , firstly the onsite have to understand the client’s requirements and then to interact with the client regularly in order to get a better understanding of the client’s requirements and the changes made if there are any. The onsite center acts as a mediator between the client and the offshore center and also plan the initial design and then to distribute the work to the available resources. Finally testing the outcome of the project at the client’s premises [6].
Offshore outsourcing is the most important part in the Global Delivery model, be- cause in this firstly the work is divided into logical components and to distribute this work to the offshore centers that are geo-locationally located in order to perform the work where it creates a maximum value. The offshore center tests the project before handling it to the onsite team and also by providing continuous technical support. Thus this model provides the client with a large pool of team with different qualities and expertise in multiple fields.
This model is usually considered when the client wants the project to be done very quickly, which is possible by making the different offshore teams working together in order to finish the task. This model is also considered when is project is very big where varied expertise are required to finish the project.
4.6. Global Delivery Model 21
–
Minimum Risks:
As the offshore center is spread all over the globe, if there is an emergency at one of the centers, the work can be distributed to the other offshore centers in order to reduce the risk.–
Geo-locationally located:
Round the clock productivity will be possible because of the time-zone difference.–
Quick completion of the project:
Since the work is distributed logically to the different offshore centers the project can be completed very soon.–
Cost benefits:
The client can have an appreciable cost saving benefits. –Continuous interaction:
The onsite team will be interact with the clientregularly and to see if the client needs any additional changes to be done to the given requirements and can be in regular contact with client in order to better understand the client.
Table 4.1: Various Delivery Models Onsite
Model
-Onsite team is located at the client’s premises
-Continuous Inter- action with Client
-Suitable for Short term projects - Project is implemented
at the client’s premises i.e., from req. engg. to Maintenance and support
-Instant Availabil- ity of information
-Suitable for projects with con- stant change in requirements -Direct interaction with
the client which helps in implementing the required changes as and when re- quired during project ex- ecution
-No communication gap
Offsite Model
- Both the Client and Ser- vice Provider have Face to face interaction on regular basis
-Quick response -Not suitable for projects if the re- quirements are not stated before hand. -Understanding of
client’s require- ments clearly
-Not suitable for long term projects. -Good synchroniza-
22Chapter 4. Models for Software Development in Outsourcing Environment
Table 4.1: (continued) Offshore
Model
-Client and Service provider will not have any face to face contact after the requirements are captured
-Quality of service is high
-Risk of communi- cation gap
-The development of the application is performed offshore -Work Progresses 24/7 - Risks related to requirements - Availability of high sills Hybrid Model
-Combination of both off- site and onsite model
-No Communica- tion gap
-The project com- pletely get ruined if the knowledge transfer is not good.
-The development team is divided into two parts.
- Proper use of re- sources
-Onsite team is in contact with the client from the beginning till the mainte- nance
- Cost savings
- Offsite team concen- trates on the development process according to the onsite team specifications.
-24/7 productivity
Offsite/ off- shore Model
-Combination of offsite and offshore model
-Clients have all the advantages of off- shore model
-If client’s require- ments change, and if the communica- tion with the client is not proper then the project fails -Offsite office close to the
clients location and the offshore development at the service providers loca- tion.
-Quick response
-Continuous Moni- toring of the work progress
Global De- livery Model
-Fusion of onsite and off- shore models
-Minimum risks compared with all the models
-Could be the worst model if the projects are small -Initial phases (Req.
Engg., High level design) of SDLC are performed onsite -Quick completion of project - Cultural differ- ences.
-Later phases (Low-Level Design, coding, initial testing) are performed off- shore
-Cost benefits
- Constant interac- tion
Chapter 5
Phases Elaborated
This Chapter gives a brief introduction to each and every phase in the software life cycle and how these phases are implemented at the offshore development center. Each phase starts with the general process and ends with implementation of that phase in an outsourcing environment.
5.1
Systems/Requirements Engineering in Outsourc-
ing Environment
Requirements engineering plays a major role in any software development. This phase is the initial phase for any software project and is regarded as the most crucial phase in the total development process. This phase actually begins by determining what has to be done and implemented.
Requirement is defined as “1. A capability needed by a user to solve a problem or achieve an objective. 2. A capability that must be met or possessed by a system or system component to satisfy a contract, standard, or specification or other formally imposed document” [37]. The requirements engineering process was totally technical but this is not the case any longer with the projects being sent overseas. Many other re- quirements like, performance, security, reliability, usability and many others are needed [23].
Generally, it is the duty of the requirement analyst to take care of the requirements in any software development project. Based on the different levels and types of the requirements the Requirements analyst prepares the specification document both onsite and offshore before and after the project transfer. Figure 5.1 Shows the different levels and types of requirements [42], according to this we have three levels of requirements, they are Business level, User level and Product level. The business level requirements, define the business process and the problems to be solved by the software product. User level requirements look at the functions to be performed by the software product from the user’s point of view. The product level requirements define the products functionality to be built into the product to enable users to accomplish their tasks, and there by satisfying the business requirements.
The different types of requirements are Business Requirements, User requirements Business rules, quality attributes, Functional requirements, non functional requirements, interface requirements, data requirements, constraints, etc.
24 Chapter 5. Phases Elaborated
Figure 5.1: Levels and Types of Requirements [42]
–
Functional:
These requirements specify how the system should perform, how the data is to be manipulated.–
Non-Functional:
These requirements are the functions that must and should support the functional requirements. Quality requirements are the non functional characteristics which only define the software products quality.–
User Requirements:
These requirements define what the software or the sys- tem has to do in order for the users to perform their tasks or objectives. Sometimes multiple user level requirements are needed to satisfy one business requirement. –Interface:
These requirements define the flow of data or information to theexternal devices like printer, fax, shared resources and other software applications that are connected outside the software product.
–
Performance:
requirements that deal with the performance of the system. How the system should act in certain instances and how should it respond to the users actions, etc,–
Data:
These requirements deal with data manipulation, where to be stored etc. –Security requirements:
These requirements are the most important when the project is being sent overseas since the security risks are very high. These requirements deal with all the security issues in the project.5.1. Systems/Requirements Engineering in Outsourcing Environment 25
Requirements Engineering Process:
Many research theories and liter- ature’s states that many of the software projects fail because of poor requirements engineering [28, 24]. Even though the requirements analyst tries to gather all the re- quirements from the users and the customer, the final product doesn’t meet all. This is because, firstly, the requirements gathering is not a one step process, secondly, the requirements are not easy to be described in words, thirdly, there are different require- ments at different levels and finally, requirements change (requirements volatility) all the time during the project life cycle.As stated earlier, requirements engineering process is a disciplined task to identify, define, document and maintain the software requirements throughout the software de- velopment. This generally encompasses of two different tasks, namely, requirements development and requirements management see figure 5.2 [41]. The requirements de- velopment consists of Elicitation, analysis, Specification and validation.
Figure 5.2: Requirements Engineering Process [42]
Requirements Development:
1.
Requirements Elicitation:
Requirements elicitation is the process of gath- ering the information in the development process. This phase includes various activities that are involved in identifying the requirements from each and every stakeholder who is involved in using the proposed system. Different techniques like interviews, workshops, observations on the current business process, group tasks are used in gathering the requirements. Once the gathering activity comes to an end, a work document in produced which includes all the things like, a statement of need, scope for the proposed system, systems technical environment, domain constraints, and usage scenarios.2.
Requirements analysis:
The requirements analysis phase categorizes the identified requirements into the related subsets, explores each relationship to the26 Chapter 5. Phases Elaborated
others, examines the consistency, ambiguity and prioritizes them based on the needs of the users of the proposed system. Later, this step includes representing the requirements in various forms including prototypes and models, looking for gaps in the requirements.. Priorities are set for each and every requirement after discussing with the users. Risks are identified and analyzed. This step may iterate the requirements elicitation process to remove/add more requirements.
3.
Requirements Specification:
In this step, the requirements are formally documented so that it can serve as the foundation for the hardware engineering, software engineering and database engineering. This defines the functionality and the performance of the proposed system, and also the information flow. A standard template is used for the specification purpose. This specification document may vary from single software requirements specification (SRS) to multiple documents. One good process of documenting SRS is to use up a predefined template that can ensure that key items are not overlooked as the requirements are documented. 4.Requirements validation:
This is the last step in the requirements devel-opment process which validates the identified requirements to ensure that all of them are correctly written, unambiguous, and complete and satisfy the customer needs. This step may lead to iterate the other steps in the development process due to the defects, gaps, additional information, or other issues. Many validation techniques are used in the requirements validation process. One of the valida- tion mechanisms is to conduct peer evaluation of the requirements specification document. Empirical evidences show that the peer evaluation of the requirements documentation has the highest priority of defect detection activity. Another major tool used for validation is to start writing the test cases for the functional (black box) testing of the software.
Requirements Management:
Requirements management is the process of tracking the requirements from the start to the deployment of the project. Requirements management is a set of activities that help the project team to identify, control, and track requirements and changes to requirements at any time as the project proceeds [35]. This involves an analysis of the requested changes, approving or disapproving those changes, and implementing those changes. Requirements management also takes care of keeping the project plans consistent and tracking the status of the requirements in the ongoing software development process. Requirements management begins with the identification activity. Each requirement is assigned a unique identifier that has the form<Requirement type> <Requirement # >
Where requirement type takes on values such as: F = functional, D = Data, B = Behavioral, I = interface and P = output. It’s a common practice to develop the traceability tables once the requirements have been identified. Some of the traceability tables are source traceability table, dependency traceability table, subsystem traceability table, interface traceability table. These tables are maintained in the requirements database so that they can be quickly searched to understand how a change in one requirement will affect different aspects of the system.
Many research studies have been suggesting that gathering the requirements in ge- ographically distributed locations is a challenging task and a process model should be proposed for the requirements engineering in global software development (GSD) [28]. Mainly 4 types of categories have been identified in the analysis made by many of the
5.1. Systems/Requirements Engineering in Outsourcing Environment 27
researchers and they are communication, culture, knowledge management, and technical aspects see figure 5.3. Each category has several factors and the relationship between them is so close, that it is very hard to define the limits.
Figure 5.3: Categories Related to Requirements Engineering in Global Software Devel- opment
– Communication: Requirements engineering process in any software development mainly depends on the communication. When the project is being sent overseas communication between the customer and the service provider becomes the most important activity. Clear communication is a pre-requisite to avoid misunder- standings and conflicts during the requirements gathering process. The major important factors considered for communication are time zone, language and com- munication media. Language barrier should be removed so that the requirements are gathered correctly. The use of state of art communication media may help them in removing the barrier.
– Culture: The culture of the teams also affects the requirements gathering process. Since, the teams are geographically distributed, culture plays an important role, both the organizational cultures and national cultures will affect the requirements engineering. The main factors related to culture are context, attitude and values. – Knowledge management: There is large information flow in the requirements engineering process. Making available this information flow or the knowledge is also a tedious task. There must be some sort of knowledge management that can collect, process, and store and make available and also unify the organizational vision. The main factors identified are expectations, awareness and management of cultural information.
– Technical aspects: Several technical aspects affect the RE process in distributed environments. The main factors found are patterns, process and configuration
28 Chapter 5. Phases Elaborated
Figure 5.4: Proposed Process
management. Tools, products that are used to gather the requirements do not ful- fill the total aspects in getting the total requirements in distributed environments. A Process model is needed for the requirements engineering process in an outsourcing environment irrespective of the outsourcing models being used. Where the interaction between the customer and the developer increases thereby reducing the four factors stated above. A process model was proposed by a team of members at the school of computer science, Brazil [28] which intends to reduce distribution difficulties and understanding the SRS in development team. According to their findings, offshore outsourcing has several roles related to software requirements engineering and these roles are performed by one person and sometimes by groups. Therefore two teams are identified with tasks in requirements engineering in offshore environments, business analyst team also called as specification team and application analyst team also called as development team. This process model is composed of five steps as shown in figure 5.4. According to this process it has to be considered that the specification team is in United States while the development team could be in any other part of the world (here India, Brazil, or China) . The specification team is responsible for conducting elicitation, analysis, specification and validation of requirements and the development team is responsible for developing the software based on the specification document with the help of coding and testing.
1. SRS First version is concluded and sent to development team. The spec- ification team after conducting the elicitation, negotiation writes the SRS initial document. After concluding these tasks, the document is sent to development team offshore where the coding could begin. However difficulties due to distribu- tion could reduce the understanding of the SRS document.
2. SRS analysis and adaptation by development team. This would be the first contact by the specification team with the development team. After receiving the