International Journals of Advanced Research in Computer Science and Software Engineering ISSN: 2277-128X (Volume-7, Issue-6)
Research Article
June 2017
© www.ijarcsse.com, All Rights Reserved Page | 207
Flexible Approach Provides an Opportunity to Enhance the
Software Development Productivity Kardile Vilas Vasantrao
Computer Science Department, Tuljaram Chaturchand College, Baramati, Pune,
Maharashtra, India
DOI: 10.23956/ijarcsse/V7I6/0204
Abstract: Feasible formation between the ‘Project’ and ‘its development methodology’ is essential to make an efficient
development.In such kind of formation,projects contributory module’s ‘inconstant levelof uncertainty’is a big
challenge.To holdsuch a challenge, there is a need to mold the development process flexibly as per the terms and
conditions of uncertainty. This paper has made an earnest attemptto study the steps to be undertaken to design and
explores an approach to adopt the flexibility in development. The goal of this paper is to rectify the present hurdles
and hassles in the development process by representing the ‘flexible approach’ for an efficient development with
feasible and need based formation. This approach is not ‘mix’ or ‘hybrid’ approach. It providesfreedom tothe
development practitioner forselecting the development approach as per the needs of projects contributory modulefor
its development.
Key words: Software development process Productivity, Software development methodologies best practice, Modeling
process, hidden uncertainty, SOSDMAS-fuzzy expert system, flexible approach
I. INTRODUCTION
The success of project development process depends on the formation of project and its development methodology. The
previous study reveals that, „every project is unique and having a set of contributory module with inconstant uncertainty
level‟.On other hand, it has multiple successful options (development methodology) with pitfalls and best practice [12,
14]. In such situation.It is very critical and crucial to formulate the feasible formation of project and its development
methodology as per its effectiveness for anefficient development [11, 20, and 23]. Such type of environment increases
the confusion level of the development practitioner for choosing the feasible and efficient development approach. Here,
the question is „How development practitioner formulates an alignment between the project‟s interacting componentsand
the development methodology and project success?‟
It is not only philosophy but our personal experience that in such inconstant changeable situation, the approach becomes
flexibleas per the need of terms and condition to reduce failure.With this inspiration to rectify the failure, this study is
carried out. The researchers have made workaholic ardent efforts to distinctive permutations and combinations variables
in the technological factors with relevant literature review on “software development productivity and analyzed its
impact factors” to reformulate and customize software and its policy to gain expectation and design results on the basis
of flexible approach.
This paper is organized in V sections. The section I is an introduction the title of this paper. The section II deals about
constrain in Software development Productivity and opportunity in software development process. Section III, dealsabout
the methodology and observations. The section IV, leads with a discussion supported by Implication, Interpretation and
Suggestion. The conclusion and future scope of the study is depicted in the section V.
SECTION II
2.1 Constrains in Software Development Productivity:
Numerous authors have explored that an „uncertainty is seed of threats in feasible formation of Project and its
development methodology in software development processes[21, 24]. Due to rigidity, plan driven approach is inefficient
to fetch such uncertain environment [14]. Agile practice driven approach provides an efficient result in such environment
[4, 5, 18, and 19]. But the project is set of contributory module that has inconstant aspect and uncertainty level. In the
consideration of those modules that has an uncertain aspect,agile practice driven approach is very efficient, but, what
about reaming modules that having the certain aspect? Furthermore, though we have mix or hybrid approach, that treats
one development methodology [11, 20and 23] but „one development methodology is not suitable for all contributory
module‟s development‟ [18].
2.2 Challenges for Software Development Process:
To tackle the inconstant level of uncertainty is a big challenge in the development process. Though agile practice driven
approach,is based specially toadopt uncertainty [13, 20]but, on the basis of numerous literate survey explorations
„software development industries still fetch the problem of failures or overruns‟ [5, 18]. So, with this consideration this
study requests „rather than adopt uncertainty‟, it is need to fetch the uncertainty by recognizing its sources and level‟.
Here, one thing is important that no so farconcentration on the, „projects contributory modules subsequent formation
Vasantrao International Journals of Advanced Research in Computer Science and Software Engineering
ISSN: 2277-128X (Volume-7, Issue-6)
© www.ijarcsse.com, All Rights Reserved Page | 208
reflects an uncertainty module to module‟by available valuable study. As a result, the development practitioners have a
confused environment to acquaint the original sources.Consequently there are chances of an inaccurate handling of
design approach or hasty decision, which may prove to be wrong later [1, 2]. Hence, the development process become
uncomfortable with variance situation and rise challenging state or overruns. In future, it is one of the strong causes and
constrains for an over run or sometimes it may lead trip downs the software project.
2.3 Opportunity for Software Development Process:
Based on the survey reports, there are some success stories in such an uncertain situation. Question is „How they get the
successes?‟ The answer is absolutely in „formulating the project and its development methodology‟ on the basis of the
feasible consideration. It is very straight forward when one understands the level of uncertainty and its sources [9, 22].
Generally, uncertainty level has a controversy ratio of knowledge level, its stability and time. It is vary at projects
contributory module or sub-activity. With this consideration this study has found an opportunity to overcome challenge
by introducing the flexible approach that allocates contributory module‟s uncertainty level wise development
methodology. It will adapt those ways for solution that are suitable for feasible formulation of development process with
such ability to deal with both predictable and unpredictable changes [6, 10, 15,17, and 19].This study suggests to the
development practitioner thecomprehensive project with its parallel activation formation. Because it recognizes uncertainty
its root sources module,this is very helpful for allocation need based development approach to gain the best productivity
on the basis of flexibility in the sense of „Just Utilization Gaining Approach AndDeploy‟
2.3 Estimated ‘Flexible approach’ for the software development process
With above consideration, the flexible approach is an approach that has the principle aims to provide a choice to decision
maker to adopt the change as per terms and condition in available situation for producing the better performance.
Every software development organization has their own process for project development management. It may differ from
the organization to organization, but it is necessary toaddress the similar issues of project development.
These issues must cover Inception, Elaboration, Construction and Transformation.It is very convenient to implement
flexible approach in thedevelopment process for the development practitioner has following the architecture and activity
flow that is described in the Table 1.
Table 1: Architecture of Flexible approach
Inception: At the initial stage when user stories
cognize at that time development practitioner can
easily recognize uncertainty, its root sources with
parallel formation contributory modules by rule base
fuzzy expert system before modelling process for
allocating suitable development methodology module
wise for development on the basis of CMMI Level-2 &
3.
Elaboration: After recognize module wise the level of
uncertainty, then with consideration of development
methods best practice and ability to tackle the
uncertainty allocate it for development.
Construction: As per module and its needed
development methods allocation construct the modules
development as per development methodology aspect.
Test the module wise functionality as per user
specification. Then collaboration of module as per its
subsequent formation.
Transformation: As per user requirement test the
project with user acceptance then release the project
for deployment.
2.4 Hypothesis:
Thus, our hypothesis is “Flexible approach for software development transfers opportunity for feasible formation of
project and its development methodology”
SECTION –III: METHODOLOGY
This section discuss the methodology of the study. The inductive base positivist phenomenological approach with
qualitative solution by flexible approach hasutilized to test the estimated hypothesis withan experimental case study.
Steps undertake to test the estimated hypothesis are as follows.
Measure Complexity, Function point of estimated case study
Calculate effort estimation and productivity on the basis of productivity
Illustrative case study withPlan (RUP,) Agile Practice (SCURM,), Mix or Hybrid approach and Flexible
approach (suggested).
Comparative Analysis of Development approach.
Vasantrao International Journals of Advanced Research in Computer Science and Software Engineering
ISSN: 2277-128X (Volume-7, Issue-6)
© www.ijarcsse.com, All Rights Reserved Page | 209
Figure 1: Illustrative Project require screen.
3.1 Experimental Case Study:
To validate the „flexible approach‟ here I have taken one simple case study ‘Creative’ Science Academy Management
System’ that has five options as follows:
(a) Login facility (c) Transaction. (e) Report
(b) Master (d) SMS (f)Utility.
In option (a) Login facility system allow login with take user identification and password. In this option system allows
teacher and administrator to user id or password.
In option (b) Master add new student (student detail), class (XI, XII), Subject, Group (PMC, PCMB, PCME….etc), Test,
Batch facility is provided. In this option system provides new from (screen) that is allowed to and new or Update record,
Retrieve information and then system generate „Identity card‟ and then save the information.
In option (c) Transactional facility is provided. This option maintain student attendance, fee, and Mark obtained from
the test that is scheduled in master record. In this option system provides new from (screen) that is allowed to new or
Update record, Retrieve information and then the system generates „Identity card‟ and then save the information.
In option (d) SMS system allow user to send SMS to student and his parents on their „mobile no‟. In this option, system
provides an import facility to send SMS to student and parents on their mobile no about this performance, Attendance
and abut fee recommendation.
In option (e) Report system allow user import, export and print reportsof performance, Attendance and abut fee
recommendation.
In option (f) Utility facility is provided. In this option, system provide an option to take backup facility of system and
add new user record. The backup facility is included an export user defining format file for back up store. In another
option system provides User maintain facility to Update the record, Retrieve the information and then system generate
„Identity card‟ and then save the information.
With own aspect of project and requirement, development practitioner can surly celebrate this module along with plan
driven approach with outward appearance. Due to its sub activity it facilitates certain aspect. But option „SMS‟ celebrates
uncertain aspect due to its dependency on „SMS service provider‟ and its response for execution. It is not confirm.
In such situation, it may possible that plan driven approach is incompetent in this case study. So, development
practitioner utilizes agile practice driven method, but instead of these two sub-activity remains has certain aspect. As a
result there are chances of over budget development. In such confused environment, „How once can formulate feasible
formation for efficient development.
Vasantrao International Journals of Advanced Research in Computer Science and Software Engineering
ISSN: 2277-128X (Volume-7, Issue-6)
© www.ijarcsse.com, All Rights Reserved Page | 210
3.2 Measure Complexity:
To calculate Cyclomatic complexity of a program module, we
use the formula:
(G) = e – n + 2 -------------(1)
(e is total number of edges, n is total number of nodes)
For above case: total number of edges = 111and total number
of nodes = 111
Cyclomaticcomplexity V (G) = e (111) – n (111) + 2 = 2
(According to P. Jorgensen, Cyclomatic Complexity of a
module should not exceed 10.)[16]
Figure 2: Flow graph estimated Case study
3.3 Function Point Analysis
Generally, function point analysis is used to measure the size of software. In function point analysis function Point
concentrates on the systems functionality. Function point counts on two grouping included five parameters, named as
Data Transactions (External Input, External Output, and External Inquiry) and Data function (Logical Internal Files,
External Interface Files)[7,8]. To consider the complexity of software each parameter is further categorized as simple,
average or complex.
Figure 3: Flow chart estimated Case study Figure 4: Data transaction estimated Case study
Steps consider for describe function point
Numerous literature describe numerous steps and procedures for counting the function point, but all these published
literature describe common perspectives: type of function point, boundaries of application, data function and transaction
function with complexity, unadjusted function point(UPF), value adjustment factor(VAF),Adjusted Function
point(APF).As per International function point user group (IFPUG) [7]and „Software sizing and productivity with
function point by H.K.Raju and Y.T. Krishnegowda (Lecture note on software engineering Vol.1, no2, may2013)[8]
following points are considered to measure the function point for estimated case study.
Function Points Calculation Sheet
Table 2: Function Count
Item Item Description Complexity Count Weight Weighted Influence Scaling
Count
1 Number of User
Inputs
Simple 20 3 60 0 No Influence
Average 4
Complex 6 1 Incidental
2 Number of User
Outputs
Simple 7 4 28
Average 5 2 Moderate
Complex 7
3 Number of User
Inquiries
Simple 1 3 3 3 Average
Average 4
Complex 6 4 Significant
4 Number of Files Simple 7 7 49
Average 10 5 Essential
Complex 15
5 Number of External Simple 5
Vasantrao International Journals of Advanced Research in Computer Science and Software Engineering
ISSN: 2277-128X (Volume-7, Issue-6)
© www.ijarcsse.com, All Rights Reserved Page | 211
Interfaces Average 1 7 7
Complex 10
Total Weighted Function
Count (FC)
147
Complexity factor calculation sheet
Table 3: Complexity Factor calculation
Factor Description Rating Factor Description Rating
F1 Reliability and backup recovery 1 F8 Master files updated on-line 0
F2 Data communications 0 F9 Complex inputs, outputs, files &
inquiries
1
F3 Distributed processing 0 F10 Complex internal processing 0
F4 Performance 1 F11 Code needs to be reusable 1
F5 Operate on existing system 1 F12 Need conversion and installation 1
F6 On-line data entry 0 F13 Multiple installations of the
system
0
F7 Data entry over multiple screens 0 F14 Easy to change and use 1
Complexity Factor (CF) = sum of ratings 7
Function point calculation sheet
Table 4 : Function Points calculation
Function Points (FP) = FC x (0.65 + 0.01 x CF) 105.84
3.4 Prepare the effort and cost estimation.
Determine the Performance Factor (PF): The Performance Factor is the ratio of developmentMan-hours required per
Function Point. Statistics from past projects provide the data to estimate the initial PF.PF = 30 Function Points per month
(per person)[3].Therefore, PF = 1.5 FP/Day
Determine the estimated number of hours:
Total Engineering Months = 105.84/30 = 3.5283Total Engineering Days = 0.430 * 20 (one month) = 70.56days
Total Engineering day for each team = 70.56/2 = 35.28 day
Assumption:
Fresher employee (Student) is 250 per day. (175Hr+75)
Experience Employee (teacher) is 500 per day.
Estimated Developmentcost
= (development day)* per day rumination
= 71 * 250 = 17750
3.5 Solve estimated case study
with plan (RUP), Agile practice (SCURM,), Mix or hybrid and suggested flexible approach.
3.5.1 Team Formation for Development
Table 5 : Formation of development team for performance testing of experimental case study development
Team No Team members Allocated development approach
I 1 M.C.A. [Computer], 1 U.G Level Rational Unified process((RUP)
II 2 Software Professional SCRUM Development
III 1 M.Sc. [Computer], 1 U.G Level Mix or hybrid approach (Construction with agile
practice and remain with plan)
IV 1 U.G. Level, 1 Software Professional Flexible Approach
3.5.2 Result given by above team for develop experimental case study:
Table 6 : Effort taken form Estimated team for development
Phase/Days RUP SCRUM Mix Flexible
Inception 04 02 03 04
Elaboration 06 08 10 06
Construction 34 23 27 20
Testing & Deployment 02 02 02 03
Total 46 35 42 33
Vasantrao International Journals of Advanced Research in Computer Science and Software Engineering
ISSN: 2277-128X (Volume-7, Issue-6)
© www.ijarcsse.com, All Rights Reserved Page | 212
3.5.3 Screens developed module by Flexible approach of estimated case study
Figure 5: Illustrative Project screens.
3.6 Comparative analysis
3.6.1 Comparison of method on the basis of effort taken on basis of function point estimation
Table 7 : Effort calculation
Method Actual
Effort
Estimated
Effort
Effort
benefits
Rational Unified Process 46 35.28 -10.72
SCRUM Development 35 35.28 0.28
Mix or hybrid approach (Construction with plan and remain with agile
practice)
42 35.28 -6.72
Flexible approach 33 35.28 2.28
3.6.2 The productivity calculation sheet is prepared and describe as follows (Productivity = FP / person-month)
Table 8 : Productivity calculation
Method Productivity Estimated
productivity
Productivity
over
Rational Unified Process 23.00652174 30 -6.993478261
SCRUM Development 31.192 30 1.192
Mix or hybrid approach (Construction with plan and remain
with agile practice)
25.02 30 -4.98
Flexible approach 32.07 30 2.07
3.6.3 The Development cost calculation sheet is prepared and describe as follows [Unit cost * FP = Development Cost]
Table 9 : Development Cost Calculation
Method Effort
(Day)
Per day
rumination
Dev. cost Total dev.
cost
Rational Unified Process 46 500 26500.00 23000.00
SCRUM Development 35 1000 35000 35000.00
Mix or hybrid approach (Construction with agile practice
and remain with plan)
15 250 3750 17250.00
27 500 13500
Flexible approach 13 250 3250 13250
20 500 10000
Cost comparison chart
Table 10 : Cost comparison
Method dev. cost Estimated
cost
cost
benefits
Rational Unified Process 23000.00 17750.00 -5250
SCRUM Development 37500.00 17750.00 -19750
Mix or hybrid approach (Construction with agile practice and remain
with plan) 17250.00 17750.00 500
Flexible approach 13250.00 17750.00 4500
Vasantrao International Journals of Advanced Research in Computer Science and Software Engineering
ISSN: 2277-128X (Volume-7, Issue-6)
© www.ijarcsse.com, All Rights Reserved Page | 213
3.6.4 TheError value of development module is prepared and describe as follows [error value) = Errors / FP]
Calculate for each teams (development method‟s) Quality by average percentage of reported error with calculated
function point. Average the percentages then subtract from 1 and then multiply 10 tocalculate subtraction Lower
percentages mean lower quality of method.Error value = (1-(No of error reported /12.92))*10
Table 11 :Error value calculation
Method Reported
Error
Error value
Rational Unified Process 36 68.81791552
SCRUM Development 22 79.21194368
Mix or hybrid approach (Construction with plan and remain with agile
practice)
39 55.58915241
Flexible approach 25 74.48738543
3.6.5Cost, Productivity, Quality Compare Analysis
Table 12 : Cost, Productivity, Error value comparison
Method Productivity
Benefit%
Effort benefits % cost benefits% Error value
benefits
Rational Unified Process -33.43333333 -50.22675737 -29.57746479 68.81791552
SCRUM Development 3.973333333 0.793650794 -111.2676056 79.21194368
Mix or hybrid approach
(Construction with agile practice
and remain with plan)
-16.6 -19.04761905 2.816901408 55.58915241
Flexible approach 6.9 6.462585034 25.35211268 74.48738543
Figure 6: Feasibility of Flexible model
SECTION – IV OBSERVATION AND EVALUATION
4.1 Observation
Result explores thatthe flexible approach driven development is Significant because it takes less development time as
compared to plan driven and agile practice driven development teams as per the figure 6.
We observe that,
Plan driven approach following team activate systematically but it wonders behind the change In contrast agile
practice driven approach following team effectively bid on project development but it is irritated by its expert.
The teams that follow Flexible approach succeed to make it efficient or need based development, but it demands
high coordination between the team and the members.
4.2 Evaluation
With this consideration, as per the laboratory experiment the proposed flexible model is efficient to reduce the
development time and minimizesthe risks. This will allow the software development to keep it low with acceptable
quality but it requires high monitoring and coordination inthe development process.
Furthermore less development time reduces stress of development team and reduces development cost. It is directly
interlinked with resource and schedule of development process. It also helps to make efficient development or quality
works that surly enhance productivity.
Above consideration directly indicates that the “Flexible approach for software development transfers an opportunity for
feasible formation of project and its development methodology”
4.3 Suggestion: It is true that we have a great tool in the case of practice driven approach that it adopts the uncertainty on the basis of
agility. It provides an inputto the development process to rapidly change its stage and direction in a particular way but the
problem of failures or overruns remain the same. Furthermore we have newly arrived concept of mix or hybrid approach.
Though it has combination of bothapproaches, it is treated as one type methodology. Here, we never underestimate the
development process naturally involves inconstant changeable environment and one typed solution is not suitableto it.
Vasantrao International Journals of Advanced Research in Computer Science and Software Engineering
ISSN: 2277-128X (Volume-7, Issue-6)
© www.ijarcsse.com, All Rights Reserved Page | 214
This study reveals that the problem is not sited in development methodology. It is sited in the formulation of „Project‟,
„its development methodology‟ and „success‟. It should be possible by flexible formation or couple the project with best
practice of software development methodology on the basis of need to handle the uncertainty rather than adopting it. It
should provide an ability to choose the need based formation by taking into account the certainty or uncertainty aspect
separately.But, in that concern, there is not much attention reported or received so far.
4.4 Implementation: Implementation of flexible approach is convenient for the development practitioner for development. It requires to carry
out only uncertainty recognizes and recipe process with projects parallel activation formation for clarification and
validation of contributory modules level of uncertainty before the modelling process. Through that development
practitioner be able to allocate project‟s need base development approach as per its best practice for making an efficient
development. The remaining process becomes the same.
Step1: At the initial stage, on the basis of use storieselaborate the project with its contributory module wise and then
uncertainty level workout.
Step2: On the basis of module‟s uncertainty leveltry to allocate the development method here this study utilize a
selection of software development methods advisory system „SOSDMAS‟-a rule base fuzzy expert system.
Step3: Allocate module as per needed development approach for construction process.
Step4: Construct the module as per its development methods and its environment test the functionality
Step5: Module collaboration is done with subsequent formation.
Step6: Test the project and user acceptance.
Step7: Test approve move forward to project release and rejection of test move towards step 3.
Step8: Release the project for deployment.
Figure 7: Execution of flexible approach.
SECTION –V
5.1 Conclusion:
This section, this studyhas released that the feasible formation of project and its development methodology as per its best
practice formulation is not crucial or critical with flexible approach. It hopefully conveyto the development
practitioner,that flexible approach transfersan opportunity to enhance the software development productivity. A flexible
approach may not be a complete solution for all software development problems and it could be unfavorable for those
organizations that follow one software development methodology to execute projects.But there is a need tochange as per
the terms and conditions in the available situation for enhancement.
5.2 Scope of further work:
As per literature review, it is yet to publish the notification, which can explore the policy for decreasing the ratio of
project challenges and cost overrun /time element. This study found that, there isan opportunityfor decreasing the ratio of
project challenge and the cost overrun /time element with flexible approach. It is agreed that this is very initial part of
practice. There must be complete validations for proposed approach.
REFERENCE
[1] Barry W. Boehm, TRW(2000)Improving Software productivity (csse.usc.edu/csse/TECHRPTS/1987/usccse87-
502/usccse87-502.pdf last access 31/01/12)
[2] Boehm, B., & Turner, R. (2004). Balancing Agility and Discipline: A guide for the Perplexed. Addison-
Wesley.(book)
[3] Calculation of the Functional Size and Productivity with the IFPUG method (CPM 4.3.1). The DDway
experience with WebRatio
[4] Chow, T., & Cao, D. (2008). A Survey of Critical Success Factors in Agile Software Projects. The Journal of
Systems and Software, 81 (6), 961-971.
Vasantrao International Journals of Advanced Research in Computer Science and Software Engineering
ISSN: 2277-128X (Volume-7, Issue-6)
© www.ijarcsse.com, All Rights Reserved Page | 215
[5] Dr. Kevin Thompson, (2011)agile journal productivity report www.agilejournal.com › Articles › Columns ›
Articles)
[6] FerielDaoudiSelminNurcan(2007) “A benchmarking framework for methods to design flexible business
processes”
[7] Function point analysis ( Manual)International function point user group (IFPUG)
[8] H.K.Raju and Y.T. Krishnegowda (2013) Lecture Notes on Software Engineering, Vol. 1, No. 2, May 2013DOI:
10.7763/LNSE.2013.V1.46
[9] Jens Christian Refsgaard a,*, Jeroen P. van der Sluijs b, Anker LajerHøjberg a, Peter A. Vanrolleghemc,dJ.C.
Refsgaard et al. (2007) Uncertainty in the environmental modelling process e A framework and guidance
Environmental Modelling & Software 22 (2007) 1543-1556
[10] Johan Bekar (1996) “Agility and flexibility what is difference” cranfield school of management ISBN 1 85905
088 3
[11] Juyun Cho reported “A hybrid software development method for large-scale projects: rational unified process
with scrum” lume X, No. 2, 2009 340 Issues in Information Systems
[12] Lemétayer, J. (2010). Identifing the Critical Success Factors in Project Management Methodology Fit. PMI
Global Congress Proceedings. Melbourne, Australia.
[13] Little, T. (2005). Context-Adaptive Agility: Managing Complexity and Uncertainty. IEEE Software, 22 (3),
28-3 5.
[14] M. A. Awad (2005) “A Comparison between Agile and Traditional Software Development Methodologies”
[15] M. Gavkare, N. L.Nanaware, A. R.Waghmare, G.B. Taware, A. D.Surdi (2011)“Study of Flexibility, Agility
and Reaction Time in Circus Artists” International Journal of Recent Trends in Science And Technology, E-
ISSN 2249-8109, Volume 1, Issue 2, 2011 pp 49-55
[16] Paul C. Jorgensen (2014) “SoftwareTesting A Craftsman‟s Approach” © 2014 by Taylor & Francis Group,
LLCCRC Press is an imprint of Taylor & Francis Group, an Informa business(2014)“
[17] Prestone G Smith, Jeff Oltmann (2010) “flexible project management: extended the agile technique beyond
software project” PMI Global Congress Processing-Washington DC 2010.
[18] Scott W. Ambler (2014) Defining Success, by. Dr. Dobb‟s Journal. source :2014 IT project success
survey,www.ambaysoft.com/surveys/success2014.html
[19] Shenhar, A. J. (2001). One Size Does Not Fit All Projects: Exploring Classical Contingency Domains.
Management Science, 47 (3), 394-414
[20] SiddharthSharadChandak.and Vishnu Rangarajan.is a Project Manager at Cognizant “Flexibility in Software
Development Methodologies: Needs and Benefits”cognizant 20-20 insights , november 2011( last access 29
march 2012 at google search)
[21] Walker Royse(1995) “Software project management : Unified framework” forwarded by Barry Bohem The
Addison-Wesley object technology series
[22] Walker, W.E., Harremoe¨s, P., Rotmans, J., Van der Sluijs, J.P., Van Asselt, M.B.A., Janssen, P., Krayer von
Krauss, M.P., 2003. Defining uncertainty a conceptual basis for uncertainty management in model-based
decision support. Integrated Assessment 4 (1), 5e17
[23] William Chaves de Souza Carvalho, Pedro Frosi Rosa, Michel dos Santos Soares reported (2010)“ A hybrid
approach to integrate agile and traditional software development processes ”
[24] Wysocki, R. R. (2009). Efective Project Management: Traditional, Agile, Extreme (5th ed.). Indianapolis, IN:
Wiley.