BACKGROUND
The present technique relates generally to software development and software development cycle in implementing software projects. In particularity the present technique relates to an optimization process in the global delivery model (GDM Environment during the software development scenario.
Currently practiced agile methods have evolved to cater to specific need of the industry and are not suitable for every project and scenario. Moreover, they do not cover all aspects of software development leading to risks in implementing projects and maybe failure to realize the agile benefits. In controversy, none of these methodologies cater to the need of GDM environment with an aspect of implementation. Moreover, agile is overly abused terminology in industry which means no process, no documentations, no metrics etc. In addition, it is cautionary to note that the amount of risk involved in using the agile methods may sometime outweigh the benefits.
Agile process is improvements in time-to-benefits and responsiveness to rapidly changing requirements. Plan-driven approaches promise predictability, stability, and high assurance. In one aspect, right combination of the two and customized process to implement it in GDM situation would yield benefits and control risks.
Accordingly, there is a need for a technique to balance agile and plan driven approach and includes the GDM components to take advantage of strengths and compensate for weakness. In addition, the balanced approach uses the iterative model of software development method, feature based development and leverage on the customized process which is lighter for agility needs.

BRIEF DESCRIPTION
An iterative software development method with balanced approach for feature based development and leveraging on at least one customized process is disclosed. The method combines an agile methodology with a plan driven approach for implementing the agile methodology in a GDM environment by extracting and addressing a plurality of business requirement components of a software development life cycle. Moreover, the method identifies a plurality of project situational risks using a client landscape for determining applicability of the agile methodology. In addition, the method predicts a matrix and a plurality of metrics for handling the plurality of project situational risks of the agile methodology. Furthermore, the method customizes for the GDM environment by translating the identified plurality of project situational risks of the agile methodology as the at least one scenario of the GDM environment.
An iterative software development system with balanced approach for feature based development and leveraging on at least one customized process is disclosed. The system comprises a client landscape adapted to identify a plurality of project situational risks and determine applicability of the agile methodology. Furthermore, the system comprises a matrix and a plurality of metrics adapted to handle the plurality of project situational risks of the agile methodology.
DRAWINGS
These and other features, aspects, and advantages of the present invention will become better understood when the following detailed description is read with reference to the accompanying drawings in which like characters represent like parts throughout the drawings, wherein:
FIG. 1 is a block diagram of a system depicting a process indicative of a balanced approach using an iterative model of software development method, in accordance with an aspect of the present technique;

FIG.2 is a block diagram of a system indicative of the four quadrants of the agile methodology, in accordance with an aspect of the present technique; and
FIG. 3 is architecture of a system indicative of implementation of GOSPEED in project management strategies, in accordance with an aspect of the present technique.
DETAILED DESCRIPTION
The following description is full and informative description of the best method and system presently contemplated for carrying out the present invention which is known to the inventors at the time of filing the patent application. Of course, many modifications and adaptations will be apparent to those skilled in the relevant arts in view of the following description in view of the accompanying drawings and the appended claims. While the system and method described herein are provided with a certain degree of specificity, the present technique may be implemented with either greater or lesser specificity, depending on the needs of the user. Further, some of the features of the present technique may be used to advantage without the corresponding use of other features described in the following paragraphs. As such, the present description should be considered as merely illustrative of the principles of the present technique and not in limitation thereof, since the present technique is defined solely by the claims.
As a preliminary matter, the definition of the term "or" for the purpose of the following discussion and the appended claims may be intended to be an inclusive "or" . That may be, the term "or" may be not intended to differentiate between two mutually exclusive alternatives. Rather, the term "or" when employed as a conjunction between two elements may be defined as including one element by itself, the other element itself, and combinations and permutations of the elements. For example, a discussion or recitation employing the terminology "A" or "B" includes: "A" by itself, "B" by itself and any combination thereof, such as "AB" and "BA." It may be worth noting that the present discussion relates to exemplary embodiments, and the appended claims should not be limited to the embodiments discussed herein.

As will be appreciated by people skilled in the art, to best understand the present technique it is important to be familiar with the environment in which it is used and the basic terminologies herein.
Agile software development is an approach to develop software that emphasizes evolutionary or iterative development. Agile is, when software development is incremental, co-operative, straightforward and flexible. Additionally, smaller teams need to improve collaboration and facilitate team self-management. In similarity, shorter iterations allow customers to provide quicker feedback.
The present technique accesses the applications to determine how suitable the project would be to apply the GOSPEED approach. The factors are based on critical success factors considered by the client and the current organization. The technique does a feasibility study of applying GOSPEED to the project depending on the assessment of various factors like the business and technical requirements of the client and the expectation of the client. The technique also engages team to make an intelligent judgment as to whether they should proceed with the recommendation of applying GOSPEED to the particular project.
GOSPEED is GDM optimized swift process to expedite delivery. GOSPEED prioritizes business requirements based on time to market needs. It also enables evolutionary development through short iterations and is capable of risk aware. The metrics in the GOSPEED includes quality control being self inspection of code, self unit testing and formal integration testing. The in-process of the metrics includes completion of feature, effort deviation at iteration level, requirement change index, defects at iteration level. A suitability matrix aids to decide the applicability of GOSPEED and it contains features related to business technical management aspects. The matrix comprises one or more requirements, their features, codes, logically grouped tasks
FIG.l is a block diagram of a system 100 depicting a process indicative of a balanced approach using an iterative model of software development method, in accordance with an aspect of the present technique. The system 100 comprises a deal

qualification module 102, a scope definition module 104, a process stage module 106, a high level design module 108, an iteration planning module 110, an analysis and design module 112, a build module 114, a system testing module 116, a production module 118, an integration testing module 120 and a bug fix module 122.
The system 100 works in a GDM environment. In addition, the system 100 prioritizes one or more business requirements based on time to market needs. The system 100 further enables evolutionary development through short iterations by reducing cycle time from the requirement phase to the build phase and also continuously integrates and tests with the results. The system 100 is risk aware including context sensitive, increasing customer intimacy and mainly focuses on communication.
In one embodiment of the present technique, the system 100 includes the requirements phase comprising the deal qualification module 102 and the scope definition module 104 as high level requirements. The module 102 is complete and provides the scope of the requirements. The module 104 identifies the master list of the requirements. Moreover, the module 104 completes the overall project plan that includes number of iterations and also the finished dates. The output of the module 102 and 104 may be the master list of the features or requirements of the high level project plan. In this case, the variants may be iterative and revisited.
In another embodiment of the present technique, the process stage module 106 comprises various modules for iterating the workflow according to the present technique. The module 108 in the high level architecture phase comprises high level feature list. The module 108 defines the required architecture being the zero iteration of the list. Additionally, the module 108 performs reference implementation to the complete architecture. The output of the module 108 may be pure architecture and the variants may be skipped if the system 100 exists.
In another embodiment of the present technique, the module 110 decides the architecture required by enabling the high level feature list. The module 110 prioritizes all the high level features based on the size, priority and identifies the

Features for the iteration. The module 110 decides the length of the iteration and also the team size for the iteration. The output of the module 110 may be a prioritized feature list with dates, effort and team details. The variants length of the module 110 may be between two or four weeks. In addition, the risk increases as the length increases and also the overhead cost increases as the iteration is shorter.
In another embodiment of the present technique, the module 112 prioritizes feature for the iteration. The module 112 elaborates the lead features and conceptualizes the design. The output of the module 112 may be the design in the form of hard copy, white board or a formal copy in soft copy. Furthermore, the variants may be design complexity decides the output format, as complexity increases and the need for formality increases.
In another embodiment of the present technique, the module 114 designs complete coding standards, design patterns and also re-use components. The module 114 comprises codes and enables self code review and self unit testing or intuitive testing. The output of the module 114 may be self tested and self documented codes. The variants of the module 114 may be code review to drive the tool as far as possible. In addition, prototyping may be encouraged whenever applicable.
In another embodiment of the present technique, the module 116 integrates tested code. In addition, the module 116 fixes issues and provides user feedbacks. The module 118 supports UAT production and contains all the issues fixed from the module 116.
In yet another embodiment of the present technique, the module 120 tests self unit codes. The module 120 is used for integration test planning, continuous integration and continuous integration testing. The output of the module 120 may be test plans, traceability to feature test results and tested codes. The variants may be separate team for integration, merging of code. In addition, the variants also may be of separate team for fixing the information technology (IT) bugs or this may be planned for the next iteration. The variants also may encourage test automation and test coverage. The module 122 may be used for bug fixing and re-testing. In

Addition, there will be a health check for every release and also the regress test may be automated.
FIG.2 is a block diagram of a system 200 indicative of the four quadrants of the agile methodology, in accordance with an aspect of the present technique. The system 200 comprises the four quadrants including a cost quadrant 202, a time quadrant 204, a quality quadrant 206 and a scope quadrant 208.
In one embodiment of the present technique, the quadrant 202 provides opportunity cost for business to justify ROI. Light software processes with customer collaboration reduces development cycle time. Even in this situation, there is low tolerance towards functional defects. Smaller teams need to improve collaboration and facilitate team self management.
In another embodiment of the present technique, the quadrant 204 includes short iterations, feature based development, continuous integration and short feedback loop. Multiple iterations and constant feedback from the customer accommodates requirements changes at a later stage. In this case, the changing requirements help better scope of the project during the entire development cycle. Shorter iterations may be a week to as long as ninety days to allow customers provide quicker feedback and to allow development teams to respond to changing requirements.
In another embodiment of the present technique, the quadrant 206 includes functional requirements, tolerance to beta errors, continuous testing and positive test case and robust frameworks for non functional requirements. Many organizations are already practicing agile methodology due to the demand from customers and beat the competition. Test driven development improves the quality of the code. Prioritized business requirements are based on time to market needs.
In another embodiment of the present technique, the quadrant 208 includes prioritizing requirements and high level communication with business users. In technology adoption scenarios, short feedback cycles provided by the agile methodology were considered to be more suitable. Additionally, increased, if not full time, customer involvement to improve communication and scope definition.

Continuous code integration to facilitate short iterations. Furthermore, future proofing of application is not a high priority. Plan for short iterative development where each of the iteration has regular system development life cycle (SDLC) and continuous integration.
In yet another embodiment of the present technique, the risks may be as explained herein. The first risk poor performance, scalability of applications developed may be because of the non-functional requirements implementation is not proven. The second risk unpredictability in quality leading to higher rework cost may be because of in-process metrics like intermediate stage defects are not collected. The agile methodology is more towards adaptability and it does not include predictability. The third risk delay in communication leading to schedule slip or waiting time increase in overhead cost, proportional to the team size and locations may be because of loss of information in distributed teams or its highly communication dependent, team chemistry plays a major role. The fourth risk cultural issues, skill mismatch with resources and large team may lead to uncontrollable chaos or poor productivity may be because of the scalability of the team, this will increase the communication channels, posing risk to the agile methodology. The fifth risk attrition may lead to huge information loss leading to schedule slip poor quality may be because of minimum documentation impact will be higher. The sixth risk productivity impact may be high overhead cost on communication, iteration management, testing and rework. The seventh risk adaptability impact because of larger iteration, adaptability to changes with less cost.
FIG.3 is architecture of a system 300 indicative of implementation of GOSPEED in project management strategies, in accordance with an aspect of the present technique. The system 300 comprises a governance structure team 302, a requirement and interface team 304, a change management team 306, a client coordination team308, a merge team 310, a bug fix team 312, an offshore team 314, a trouble shooting team 316, a feature based development team 318, a testing and automation team 320 and first feature based team 322, second feature based team 324, third feature based team 326 and fourth feature based team 328.

In one embodiment of the present technique, the team 302 forms a governance structure with offshore and onsite project or program managers as key decision makers to resolve any delivery related issues and prioritize the continuously evolving scope and manage resource planning. In addition, the resource pairing such as one expert with one newcomer may be done in order to scale up faster and hit the ground running on day one is one of the major decisions that this governance structure monitor. Moreover, the client interaction plan describing the involvement of the client in every phase is documented and signed off between the first company and the client.
In another embodiment of the present technique, the team 304 explores projects or new technologies. In addition, the changing requirements are welcomed and acted upon accordingly as there is no requirements freeze. The applications are implemented where non-functional requirements are not stringent. The team 304 identifies similar features and follows a template framework. There are not multiple interfaces and the interfacing groups have minimum dependencies. The team 304 includes sustainable cost of system failures. The applications may be used for the business customers and the primary focus is on the development of software and not on the documentation or models.
In another embodiment of the present technique, the team 306 is enabled when the customers or users are active participants in requirement and analysis efforts. In this case, intensive involvement needed everyday. Flexible go-live updates or scope of the application are included. The team 306 may be used only for time and material contracts. In this team 306, the communication channels are clearly defined and the responsibilities are identified. The customers agree to measure the effort in terms of functionality delivered and not on the artifacts delivered.
In another embodiment of the present technique, the team 308 enables with highly skilled team technically and also possess good communication skills. The team 308 also comprises teams that are highly committed and energetic. The teams may be smaller sized teams such as six to twelve members who are very cohesive and highly responsive. The teams cannot exist with occasional communication. They

Need continuous access to business expertise. Furthermore, this access is not something that is handled at a management level; it is something that is present for every developer. It should be noted that since the developers are capable professionals in their own disciplines, they need to be able to work as equals with other professionals in other disciplines. In addition, right people with the right skills available when needed, their experience and can play different roles in the life cycle of the project. Projects with experienced resources will have higher degree of success in the dynamic environment.
In another embodiment of the present technique, the team is involved in reconciliation of code, responsible for setting up, and maintaining the smooth running of regular build process. The team 310 is a strong project management that is one of the major factor which leads to the success of the agile project. The team 310 includes strong communication, evolving requirements, status reporting parameters which project manager has to address effectively through out the life cycle of the project. In addition, motivation of the project team and creating visibility of the customer feedback to the entire team forming a cohesive team. Additionally, not all projects are suited for the agile. Project success factors depend upon on the various sweet spot for the agile methods. If the project does not land on the sweet spots it runs into risk of failure. The failure can be in terms of not realizing the benefits of agile and higher cost to the project. Quantitative analysis and collection of metrics as laid out by GOSPEED for analysis and further improvements.
In another embodiment of the present technique, the team 312 is a small team that fixes all the bugs raised by the integration testing, client testing and sanity testing.
In another embodiment of the present technique, the team 314 is offshore team working in staggered and overlapping shifts to overcome any roadblocks due to time difference is a key differentiator in GDM agile implementation. The communication process may not be required for small maintenance projects operating in this mode. Plan for daily handshake meetings between onsite and offshore teams to be organized at the beginning and end of respective days to ensure effective and total

Communication on progress and issues. Client personnel also need to be included in these meetings on a case by case basis. Additionally, usage of instant communication tool is highly recommended in this model. Rapid and clear escalation procedures are laid for GOSPEED upfront with the client in order to resolve any issues at a faster pace. The focus of escalation triggers shifts from missed requirements to delay in iterations or feature development and integration.
In another embodiment of the present technique, the team 316 involves with the client in providing feedback and reporting bugs. Depending on the feedback the rework estimates are calculated and iteration cycles may be extended. One of the key events that are tracked additionally in this method is the completion of iteration cycles. Data is collected in small increments and creation of history is avoided. Tracking of requirements and bug fix backlogs are done for each of the iteration and brought to closure. In similarity, amount of work for the release or iteration in term of number of atomic level features. Average turnaround time to fix the defects in the feature.
In another embodiment of the present technique, the team 318 comprising the first feature based team 322, second feature based team 324, third feature based team 326 and fourth feature based team 328 works with ineffective and incomplete requirements at offshore which is overcome by shorter iterations and prioritized feature based development. Change management is open every iteration, giving comfort to the client in case of hazy requirements. Client signoff on the iterations schedule and priority of features are required. The most important differentiator in GOSPEED for this activity would be preparing and getting client signoff on schedule for rework of each feature development.
In yet another embodiment of the present technique, the team 320 is involved with incremental feature based development being the key differentiator in the methodology due to iterations in testing. In addition, collaborative effort is required between the client development team and the testing team 320 to plan and prioritize for the iterations. Separate team does integration and merging of code for each feature and iteration. The bugs for that particular iteration are consolidated in a

Backlog list of things to be taken up for the next iteration. Automating of testing procedures are highly recommended in this methodology to ensure that the integration test always happen with the same type of test bed and similar tests can be run for each different iteration cycle.
As will be appreciated by a person skilled in the art, the various implementations of the present technique provide a variety of advantages. In the traditional development cycle the delivery cycle is long. Agile has short incremental cycles with more focus on the business values than process values. Many factors like working software over comprehensive documents, reduced overhead of moving information between people, client's availability and frequent checkpoints the development cycle time is considerably reduced. All the requirements cannot and will not be specified at the start of the project. In today's business dynamics the fundamental focus are changing the software requirements too. Agile processes view requirement changes as fluid and changing. In similarity, it can take on inevitable late-changing requirements because of early and frequent delivery of running software. Thereby, the harness changes for customer's competitive advantage. Better user satisfaction since the requirements, implementation gap is reduced.
As will be appreciated by those ordinary skilled in the art, the foregoing example, demonstrations, and method steps may be implemented by suitable code on a processor base system, such as general purpose or special purpose computer. It should also be noted that different implementations of the present technique may perform some or all the steps described herein in different orders or substantially concurrently, that is, in parallel. Furthermore, the functions may be implemented in a variety of programming languages. Such code, as will be appreciated by those of ordinary skilled in the art, may be stored or adapted for storage in one or more tangible machine readable media, such as on memory chips, local or remote hard disks, optical disks or other media, which may be accessed by a processor based system to execute the stored code. Note that the tangible media may comprise paper or another suitable medium upon which the instructions are printed. For instance, the instructions may be electronically captured via optical scanning of the paper or other

Medium, then compiled, interpreted or otherwise processed in a suitable manner if necessary, and then stored in a computer memory.
While, the following description is presented to enable a person of ordinary skill in the art to make and use the invention and is provided in the context of the requirement for a obtaining a patent. The present description is the best presently-contemplated method for carrying out the present invention. Various modifications to the preferred embodiment will be readily apparent to those skilled in the art and the generic principles of the present invention may be applied to other embodiments, and some features of the present invention may be used without the corresponding use of other features. Accordingly, the present invention is not intended to be limited to the embodiment shown but is to be accorded the widest cope consistent with the principles and features described herein.
Many modifications of the present invention will be apparent to those skilled in the arts to which the present invention applies. Further, it may be desirable to use some of the features of the present invention without the corresponding use of other features.
Accordingly, the foregoing description of the present invention should be considered as merely illustrative of the principles of the present invention and not in limitation thereof.
We Claim:
1. An iterative software development method with balanced approach for feature based development and leveraging on at least one customized process, the iterative software development method comprising:
combining an agile methodology with a plan driven approach for implementing the agile methodology in a global delivery model (GDM) environment by extracting and addressing a plurality of business requirement components of a software development life cycle;
Identifying a plurality of project situational risks using a client landscape for determining applicability of the agile methodology;
Predicting a matrix and a plurality of metrics for handling the plurality of project situational risks of the agile methodology; and
Customizing the GDM environment by translating the identified plurality of project situational risks of the agile methodology as the at least one scenario of the GDM environment.
2. The method as recited in claim 1, further comprising a repository for storing the plurality metrics and the matrix of the agile methodology.
3. The method as recited in claim 1, wherein extracting the plurality of business requirement components including at least one current business requirement comprising an assessment kit and a set of questions for storing in the repository.
4. The method as recited in claim 1, wherein the matrix including at least one quantitative aspect for predicting the plurality of project situational risk of the agile methodology.
5. The method as recited in claim 1, further comprising creating the agile methodology to work into the GDM enviroment.

6. The method as recited in claim 1, further comprising re-structuring jobs while extracting the plurality of business requirement components from the agile methodology.
7. The method as recited in claim 1, translating the identified plurality of project situational risks including prioritizing, scheduling and iterating to design into a set of small pieces of jobs.
8. The method as recited in claim 1, implementing a governance team structure in the GDM environment with at least one offshore team and at least one onsite team for resolving delivery related issues and prioritizing evolving scopes and manage resource planning.
9. An iterative software development system with balanced approach for feature based development and leveraging on at least one customized process, the iterative software development system comprising:
A client landscape adapted to identify a plurality of project situational risks and determine applicability of the agile methodology; and
A matrix and a plurality of metrics adapted to handle the pluarity of project situational risks of the agile methodology.
10. The system as recited in claim 9, further comprising a repository adapted to store the plurality metrics and the matrix of the agile methodology.
11. The system as recited in claim 9, further comprsising an assessment kit and a set of questions adapted to extract the plurality of business requirement components including at least one current business requirement
12. The system as recited in claim 9, wherein the matrix adapted to include at least one quantitative aspect for predicting the plurality of project situational risk of the agile methodology.
13. The system as recited in claim 9, a governance team structure adapted to be implemented in the GDM environment with at least one offshore team and at

Least one onsite team for resolving delivery related issues and prioritizing evolving scopes and manage resource planning.
14. A tangible computer-readable medium having stored thereon computer executable instructions of building a computer implemented iterative software development tool with balanced approach for feature based development and leveraging on at least one customized process, the iterative software development method comprising:
program code adapted to combine an agile methodology with a plan driven approach for implementing the agile methodology in a global delivery model (GDM) envionment by extracting and addressing a plurality of business requirement components of a software development life cycle;
Program code adapted to identify a plurality of project situational risks using a client landscape for determining applicability of the agile methodology;
Program code adapted to predict a matrix and a plurality of metrics for handling the pluarity of project situational risks of the agile methodology; and
Program code adapted to customize the GDM environment by translating the identified plurality of project situational risks of the agile methodology as the at least one scenario of the GDM environment.
15. The program product as recited in claim 14, further comprising a repository adapted to store the plurality metrics and the matrix of the agile methodology.
16. The program product as recited in claim 14, wherein extracting the plurality of business requirement components adapted to include at least one current business requirement comprising an assessment kit and a set of questions for storing in the repository.

17. The program product as recited in claim 14, wherein the matrix adapted to include at least one quantitative aspect for predicting the plurality of project situational risk of the agile methodology.
18. The program product as recited in claim 14, wherein the GDM enviroment adapted to replace in it existing one or more of the agile methodology.
19. The program product as recited in claim 14, further comprising jobs adapted to omit while extracting the plurality of business requirement components from the agile methodology.
20. The program product as recited in claim 14, the identified plurality of project situational risks adapted to translate by prioritizing, scheduling and iterating to design into a set of small pieces of jobs.