Your SlideShare is downloading. ×

20120140506013

75

Published on

Published in: Technology, Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
75
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
2
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. International Journal of Advanced Research in Engineering and Technology (IJARET), ISSN 0976 – 6480(Print), ISSN 0976 – 6499(Online) Volume 5, Issue 6, June (2014), pp. 83-90 © IAEME 83 GRADUAL TRENDS IN SOFTWARE DEVELOPMENT AND SOFTWARE IMPROVEMENT MODELS Nomi Baruah1 , Annushree Kurmi2 , Sharbani Purkayastha3 , Paulomi Das4 1,2,3,4 Computer Science & Engineering Department, Dibrugarh University, Dibrugarh, India, ABSTRACT In today’s era to produce a quality product which satisfies the customer is the main goal of software industries because then only they can survive in the current business environment. Different researchers have proposed different software development models right from the beginning of software development era. The different software development models acts as a guide to the software developers which model to choose based on the type of projects they undertake. Each of these models satisfies specific needs demanded by customer on the software product. This paper studies the different trends of software development models starting from the messy model i.e. Build and Fix Model and an analysis of the models are being made. Keywords: Bootstrap, CMM, SPICE, Spiral Model, Waterfall Model I.INTRODUCTION The software and software development is being part of the society since 50 years. As the software’s has become an important element in industry, organizations, etc. the number of companies which produce different types of software products has been increased recently which as a result became urge for the companies to produce quality products so that they can survive in the market. Different types of models have been suggested by different researchers. The software developers can select the model based on the type of the software product they are going to develop. II. SOFTWARE DEVELOPMENT MODELS The different types of software development models which are discussed in this paper are given below: INTERNATIONAL JOURNAL OF ADVANCED RESEARCH IN ENGINEERING AND TECHNOLOGY (IJARET) ISSN 0976 - 6480 (Print) ISSN 0976 - 6499 (Online) Volume 5, Issue 6, June (2014), pp. 83-90 © IAEME: http://www.iaeme.com/IJARET.asp Journal Impact Factor (2014): 7.8273 (Calculated by GISI) www.jifactor.com IJARET © I A E M E
  • 2. International Journal of Advanced Research in Engineering and Technology (IJARET), ISSN 0976 – 6480(Print), ISSN 0976 – 6499(Online) Volume 5, Issue 6, June (2014), pp. 83-90 © IAEME 84 1.1 Build and Fix Model: The build and fix model is the first model in software development methodology used to develop software product. In this model the software product is implemented without any specification or design. The methodology works for projects with few hundred lines of code [1].The methodology is very simple but the rework of the product is done until the customer is satisfied. 1.2 Waterfall Model: The Waterfall model was the first software development life cycle model to be used widely in Software Engineering to ensure success of the project[2].Although it has come under attack in recent years for being too rigid and unrealistic when it comes to quickly meeting customer needs ,the Waterfall model is still widely used[3].The different steps followed in waterfall model to develop a software product are feasibility study, requirement gathering and analysis, design, coding, testing and maintenance. 1.3 Spiral Model: The Spiral Model is a risk-driven process model generator. It is used to guide multi-stakeholder concurrent engineering of software-intensive systems. It has two main distinguishing features. One is cyclic approach and other is a set of anchor point milestones [4].The spiral model is divided into four sectors: objectives setting, risk assessment and reduction, development and validation and planning [5]. 1.4 Capability Maturity Model (CMM): In order to have a proper management of the software processes in an organization, the Software Engineering Institute (SEI) had created a Capability Maturity Model (CMM) for developing and maintaining software. It elaborates how to evolve the processes so that the organization maturity is being increased gradually. The SEI has developed a five-level Capability Maturity Model for software that provides organizations with guidance for measuring software process maturity and establishing process improvement plans. [10] The current processes of an organization are being identified and modified or changed in order to improve the quality of the software. [9] The CMM focuses on the organization’s work processes. The CMM helps the organization by acting as a guide in selecting process improvement strategies by determining current process maturity and identifies the issues which is critical to software quality and process improvement. 1.5 Capability Maturity Model Integration (CMMI): CMMI is a process improvement model that provides a set of best practices that addresses productivity, performance, costs and stakeholder satisfaction. It is a model that consists of best practices for system and software development and maintenance and is used as a framework for appraising the process maturity of the organization. CMMI is the leading industry standard for measuring software development processes. The model is introduced with a purpose to eliminate inconsistency, reduce duplication, increase the transparency and intelligibility, provision of public terminology, etc.The continuous representation of CMMI is designed to allow the user to focus on the specific processes that are considered important for the organization's immediate business objectives, or those to which the organization assigns a high degree of risk. Continuous representation suits well to SME’s, where short term goals are emphasized highly. [8] 1.6 People-Capability Maturity Model (P-CMM): The P-CMM is developed to provide a framework that continuously develops the human assets of the software or information systems organization. The P-CMM is an organizational change model. It is through P-CMM that an organization is able to identify the capabilities of current workforce practices and also able to evolve the workforce practices with the help of maturity levels of P-CMM. The P-CMM is constructed from workforce practices and process improvement techniques that have proven effective in many
  • 3. International Journal of Advanced Research in Engineering and Technology (IJARET), ISSN 0976 – 6480(Print), ISSN 0976 – 6499(Online) Volume 5, Issue 6, June (2014), pp. 83-90 © IAEME 85 organizations. [9] The range of organisational processes that the P-CMM addresses is extensive and covers areas of workforce management. The P-CMM model is divided into five maturity levels .Each level in this model defines a new standard for people management practices. [10] 1.7 BOOTSTRAP: BOOTSTRAP is a software process improvement and assessment model. It is basically developed for European industries. BOOTSTRAP methodology can be applied to small and medium size software companies or software departments within a large organization. A new release (Release 3.0) of the BOOTSTRAP methodology has been developed to assure conformance with the emerging ISO standard for software process assessment and improvement. [11] 1.8 Software Process Improvement Capability determination (SPICE):SPICE is also known as ISO/IEC 15504.SPICE was developed to provide a framework for software process assessment so that the product can be delivered reliably .The main goal of software process improvement is to provide the software industry with gains in productivity and quality. [12]Capability determination reduces the risk associated with large projects and at the same time helps purchasers to get better value for money. [13] III. ANALYSIS OF SOFTWARE MODELS The analysis of the models is done based on four different characteristics. They are 1.1 Based on Characteristics of Requirements Table 1: Comparison of Different Software Development Models Based on Requirements Requirements Build and fix model Waterfall model Spiral model CMM CMMI P-CMM Bootstrap model SPICE Are requirement s easily understanda ble and defined? No(because there is no proper phase for requirement analysis) Yes(because requirement analysis and specification is done at the early stage ) No(because software is built in a series of incremental releases which might be a paper model or prototype but during later iterations more complete versions of the s/w is produced) Yes (but from level 2- repeatable) Yes (because there are phases for requirements development and requirements management) No(since it describes an evolutionary improvemen t path from ad-hoc to mature development of knowledge, skills, motivation of workforce) Yes(the re is s/w require ment analysis phase in this model) Yes (But from level 2- planned and tracked) Do we change requirement s quite often? Yes(because requirements are not fixed and documented and are not properly understood) No(because requirements once defined are documented) Yes(because requirements are not fixed and documented and are not properly understood ) Yes (but depends on feasibility from the developer side and customer side) No (but changed when required) Yes(since each maturity levels increases a level of capability for developing the talent of the organization ) No(sinc e prototy ping activity is not done in this model) Yes (but depends on feasibilit y from the develop er side and custome r side)
  • 4. International Journal of Advanced Research in Engineering and Technology (IJARET), ISSN 0976 – 6480(Print), ISSN 0976 – 6499(Online) Volume 5, Issue 6, June (2014), pp. 83-90 © IAEME 86 Can we define requirement s early in the cycle? No(because developers keep on adding requirements until user is satisfied ) Yes(because requirement analysis and specification is done at the early stage) No(since customers examine the prototype and provide feedback and using the feedback both specifications and the prototype is improved) Yes(since requiremen ts are defined during level-2) Yes(because requirement development and requirement management are done at the proper time) No(since it describes an evolutionary improvemen t path from ad-hoc to mature development of knowledge, skills, motivation of workforce) Yes(bec ause require ment gatherin g, analyzi ng, and recordi ng is done at the early stage) Yes(req uiremen ts are defined in early stage- level 2) Are requirement s indicating a complex system to be built? No (because this model is not suitable for complex projects ) No (because this model is not suitable for complex projects) Yes(because requirements are complex and need evaluation to get clarity and hence end of the project may not be known early) Yes (but not for initial level) Yes(because are stringent requirements) No(since p – cmm provides organization s with guidelines on how to gain control of their processes for developing their workforce) Depend s on type of project and enterpri se Yes (but not for initial level) 1.2 Based on Status of Development Team Table 2: Comparison of Different Software Development Models Based on Status of Development Team Development team Build and fix model Waterfall model Spiral model CMM CMMI P-CMM Bootstrap model SPICE Less experience on similar projects Yes(becaus e developers are not experts) No(becau se project are mostly extension of an existing version) Yes(beca use this model is suitable for complex projects but not for some existing version or low risk projects) No(but depends on the requirement s) No (but depends on the requirements) No(since p- cmm guides an organization through sophisticated practices an techniques which are chosen from experience for developing its workforce) No(since this model deals with software process assessment and improvement method which measures capability and value of processes No (but from level 2) Less domain knowledge( new to the technology) No(technol ogy change is not a characterist ic of this model) No(techn ology change is not a characteri stic of this model) Yes(beca use developer s are not experts) No (since strong domain knowledge is required for building complex systems) No (up to the 4th level) Yes (For level 5) No(since p- cmm focuses on instilling basic discipline into workforce activities like training, staffing, etc which will not be possible with less domain knowledge) No(since this model provides guidelines for process improvement which is supported with computer based tools, updated database ,algorithms etc) No( since strong domain knowledge is required for building complex systems)
  • 5. International Journal of Advanced Research in Engineering and Technology (IJARET), ISSN 0976 – 6480(Print), ISSN 0976 – 6499(Online) Volume 5, Issue 6, June (2014), pp. 83-90 © IAEME 87 Less experience on tools to be used No(well acquainted tools are used) No(well acquainte d tools are used) Yes(beca use developer s are not experts) No(since it is used to build complex systems) No (up to the 4th level) Yes (For level 5) No(since since p-cmm focuses on instilling basic discipline into workforce activities like training,staffin g,etc which will not be possible with less domain knowledge) No(since this model uses computer based assessor tools to evaluate processes) No(well versed with tools to be used) Availability of training if required No(there is no phase for training) No(there is no phase for training) No(there is no phase for training) Yes(training is available in level 3) Yes(there is a training phase) Yes(there is a training phase) Yes(there is a training phase) Yes(trainin g is available in level 3) 1.3 Based on User’s Participation Table 3: Comparison of Different Software Development Models Based on User’s Participation Involvement of users Build and fix model Waterfall model Spiral model CMM CMMI P-CMM Bootstrap model SPICE User involvement in all phases No(there is no facility for this) No(user involvement is only in the requirement analysis and specification phase) Yes(since s/w evolves as the process progresses developer and customer better understand and reacts to risks at each evolutionar y level) Should be pre defined based on type of enterprise No(users are involved in certain phases only) Yes(since it is a maturity framework that focuses on developing and managing the workforce of an organization No(since this model provides guidelines for process improvemen t which is supported with computer based tools, updated database ,algorithms etc Should be pre defined based on type of enterprise Limited user participation Yes(num ber of users is limited) Yes(number of users is limited) No(since s/w evolves as the process progresses developer and customer better understand and reacts to risks at each evolutionar y level) Varies- on type of project and type of enterprise No(group of users participate) No(since without sufficient user participation organizational growth will be impossible) Yes(because some phases of this model does not require participation of users Varies- on type of project and type of enterprise
  • 6. International Journal of Advanced Research in Engineering and Technology (IJARET), ISSN 0976 – 6480(Print), ISSN 0976 – 6499(Online) Volume 5, Issue 6, June (2014), pp. 83-90 © IAEME 88 User have no previous experience of participation in similar projects Yes(as users haven’t used such system before) No(as system is mostly extension of an existing system) Not defined Varies( on type of project and enterprise ) No(users are experienced) Varies- on type of project and type of enterprise Varies on type of project and enterprise Varies (on type of project and enterprise) Users are experts of problem domain No(users discover more problems only after using the first build) Yes(users define and document requirements early in the cycle ) No(since the process and managemen t is very complex and it is suitable for high risk projects ) Yes (users requireme nts are document ed early in the cycle) Yes( users define and document requirements early in the cycle) No(since this model addresses issues like career development , communicatio n, training, coaching, etc) No(since users are not experts) Yes( since user requireme nts are document ed early in the cycle) 1.4 Based on Type of Project Associated Risk Table 4: Comparison of Different Software Development Models Based on Type of Project Associated Risk Project type and risk Build and fix model Waterfall model Spiral model CMM CMMI P-CMM Bootstrap model SPICE Project is the enhancement of the existing system No(new, small sized projects are build using this model) Yes(it is mostly used for enhancing an existing system) No(since it is suitable for complex ,high risk projects) Depends on type of project and enterprise Depends on type of project and enterprise Yes(since it guide organizations in selecting activities for improving their workforce activities based on the current maturity of their workforce practices) Yes(since this model is all about improveme nt of existing software processes with different organizatio n types and various software processes) Depends on type of project and enterprise Funding is stable for the project Yes(but sometimes it may increase) Yes(require cost is documented) No(since significant changes are expected in the product during the developmen t cycle) Yes(cost and time should not exceed the documente d limit) Yes(cost and time should not exceed the documented limit) Yes No(since sometimes company waste a lot of resources in keeping up high capability processes which create a lot of costs and low value) Yes(since cost and time should not exceed the documented limit)
  • 7. International Journal of Advanced Research in Engineering and Technology (IJARET), ISSN 0976 – 6480(Print), ISSN 0976 – 6499(Online) Volume 5, Issue 6, June (2014), pp. 83-90 © IAEME 89 High reliability requirements No(used for small projects with less risk) No(used for small projects with less risk) Yes(require ments indicate that the system should be reliable) Yes(It requires complex and reliable systems are build) Yes(because complex and reliable systems are build) Yes(because complex and reliable systems are build) Yes(becaus e complex and reliable systems are build) Yes(because complex and reliable system are built) Tight project schedule No(develo pment time may exceed) Yes(develop ment time is most often fix) No(since end of project may not be known early and spiral may go indefinitely) Yes (but from higher level) Yes(project needs to be completed within stipulated time) Yes No(since sometimes cost and schedules are not predictable in an immature software organizatio ns having complex processes) Yes since project development time is fixed) Use of reusable components No(small organizatio ns do store the reusable component s) Yes(some components of the existing system may be used in building the enhanced system) Used in large enterprise Yes(comp onents are re-used in large enterprise) Yes(large organization s store the reusable components) Used in large enterprise Yes(compo nents of a particular process can be re-used for its further improveme nt Yes(compone nts are re- used in large enterprise) Are resources (time, money, people etc.) scarce? Yes(becau se developme nt time and cost are not known beforehand ) No(mostly these are not scarce as these are fixed after proper analysis) yes(since it takes a lot of strict managemen t to complete such projects under this model) Varies with organizati on No(resource required do not change in most cases as these are fixed after proper analysis ) Varies with organization Varies with organizatio n Varies with organization IV. CONCLUSION In this paper, we have discussed different models and their characteristics with respect to different types of situation a project may have and at that time which model is best described can be determined based on the analysis given in the above tables. The perspective nature of CMMI and BOOTSTRAP, and the associated characteristics is sufficient enough to implement software process improvement programs are the main reasons for further researches in small and medium software enterprises.
  • 8. International Journal of Advanced Research in Engineering and Technology (IJARET), ISSN 0976 – 6480(Print), ISSN 0976 – 6499(Online) Volume 5, Issue 6, June (2014), pp. 83-90 © IAEME 90 V. REFERENCES [1] http://www.csun.edu/~eugean/comp380/slides/ch2-4spp.pdf,accessed on 21 April, 2014. [2] http://www.tutorialspoint.com/sdlc/sdlc_waterfall_model.htm , accessed on 21 April, 2014. [3] CTG. MFA – 003, "A Survey of System Development Process Models", Models for Action Project: Developing Practical Approaches to Electronic Records Management and Preservation, Center for Technology in Government University at Albany / Suny, 1998. [4] Barry Boehm, "Spiral Development: Experience, Principles, and Refinements", edited by Wilfred J. Hansen, 2000. [5] Ian Sommerville, "Software Engineering", Addison Wesley, 7th edition, 2004. [6] Mike konrad,Mary Beth Chrissis,Jack Ferguson,Suzanne Garcia,Bill Hefley,Dave Kitson and Mark Paulk,”Capability Maturity Modelling SM® at the SEI”, Software Process Improvement and Practice,vol. 2,no. 1,pp.21-34,1996. [7] M.C. Paulk,B. Curtis,M.B. Chrissis, and C.V. Weber, “Capability Maturity Model”, Version 1.1,IEEE Software,vol. 10,no. 4,pp. 18-27,July 1993. [8] L.G. Jones, Software Process Improvement and Product Line Practice: CMMI and the Framework for Software Product Line Practice, US: SEI, Carnegie Mellon University, 2002. [9] B. Curtis, W. Hefley and S. Miller, People Capability Maturity Model.Addison-Wesley: Boston, MA, USA, 2001. [10] Pasi Vakaslahti,”Process Improvement Frameworks-A Small Case Study with People Capability Maturity Model”, Software Process improvement and Practice,vol. 3,no. 4,pp.225- 234,December 1997. [11] V.M. Haase,”BOOTSTRAP: Fine tuning process assessment”, IEEE Software, vol. 11, no. 4, pp.25-37, 1994. [12] A. Dorling,”SPICE: Software Process Improvement and Capability Determination”, Software Quality Journal, vol. 2, no. 4, pp. 209-224, December 1993. [13] Rout and P. Terence, “SPICE: A Framework for Software Process Assessment”, Software Process Improvement and Practice, vol. 1,no. 1,pp. 57-66,1995. [14] S.Saira Thabasum, “Need For Design Patterns and Frameworks For Quality Software Development” International journal of Computer Engineering & Technology (IJCET), Volume 3, Issue 1, 2012, pp. 54 - 58, ISSN Print: 0976 – 6367, ISSN Online: 0976 – 6375. [15] Dillip Kumar Mahapatra and Gopa Krishna Pradhan, “Selection Criterion and Implementation of Case Tools In Gap Analysis Towards Distributed Software Development” International journal of Computer Engineering & Technology (IJCET), Volume 4, Issue 3, 2013, pp. 389 - 409, ISSN Print: 0976 – 6367, ISSN Online: 0976 – 6375. [16] Dillip Kumar Mahapatra, Tanmaya Kumar Das and Gopakrishna Pradhan, “Guidelines For Managing Distributed Software Project Under Deployment” International journal of Computer Engineering & Technology (IJCET), Volume 4, Issue 1, 2013, pp. 34 - 45, ISSN Print: 0976 – 6367, ISSN Online: 0976 – 6375.

×