http://en.wikipedia.

org/wiki/Software_engineering

Software engineering
From Wikipedia, the free encyclopedia Jump to: navigation, search Software engineering (SE) is the application of a systematic, disciplined, quantifiable approach to the design,. development, operation, and maintenance of software, and the study of these approaches; that is, the application of engineering to software[1] [2] [3] The term software engineering first appeared in the 1968 NATO Software Engineering Conference and was meant to provoke thought regarding the perceived "software crisis" at the time.[4][5] Software development, a much used and more generic term, does not necessarily subsume the engineering paradigm.

Contents
1 History 2 Profession 2.1 Employment 2.2 Certification 2.3 Impact of globalization 3 Education 4 Comparison with other disciplines 5 Subdisciplines 6 Related disciplines 6.1 Systems engineering 6.2 Computer software engineers 7 See also 8 References 9 Further reading 10 External links

History
Main article: History of software engineering When the first modern digital computers appeared in the early 1940s,[6] the instructions to make them operate were wired into the machine. Practitioners quickly realized that this design was not flexible and came up with the "stored program architecture" or von Neumann architecture. Thus the division between "hardware" and "software" began with abstraction being used to deal with the complexity of computing.

Programming languages started to appear in the 1950s and this was also another major step in abstraction. Major languages such as Fortran, ALGOL, and COBOL were released in the late 1950s to deal with scientific, algorithmic, and business problems respectively. E.W. Dijkstra wrote his seminal paper, "Go To Statement Considered Harmful",[7] in 1968 and David Parnas introduced the key concept of modularity and information hiding in 1972[8] to help programmers deal with the ever increasing complexity of software systems. A software system for managing the hardware called an operating system was also introduced, most notably by Unix in 1969. In 1967, the Simula language introduced the object-oriented programming paradigm. These advances in software were met with more advances in computer hardware. In the mid 1970s, the microcomputer was introduced, making it economical for hobbyists to obtain a computer and write software for it. This in turn led to the now famous Personal Computer (PC) and Microsoft Windows. The Software Development Life Cycle or SDLC was also starting to appear as a consensus for centralized construction of software in the mid 1980s. The late 1970s and early 1980s saw the introduction of several new Simula-inspired object-oriented programming languages, including Smalltalk, Objective-C, and C++. Open-source software started to appear in the early 90s in the form of Linux and other software introducing the "bazaar" or decentralized style of constructing software.[9] Then the World Wide Web and the popularization of the Internet hit in the mid 90s, changing the engineering of software once again. Distributed systems gained sway as a way to design systems, and the Java programming language was introduced with its own virtual machine as another step in abstraction. Programmers collaborated and wrote the Agile Manifesto, which favored more lightweight processes to create cheaper and more timely software. The current definition of software engineering is still being debated by practitioners today as they struggle to come up with ways to produce software that is "cheaper, better, faster". Cost reduction has been a primary focus of the IT industry since the 1990s. Total cost of ownership represents the costs of more than just acquisition. It includes things like productivity impediments, upkeep efforts, and resources needed to support infrastructure.

Profession
Main article: Software engineer Legal requirements for the licensing or certification of professional software engineers vary around the world. In the UK, the British Computer Society licenses software engineers and members of the society can also become Chartered Engineers (CEng), while in some areas of Canada, such as Alberta, Ontario, [10] and Quebec, software engineers can hold the Professional Engineer (P.Eng) designation and/or the Information Systems Professional (I.S.P.) designation. In Canada, there is a legal requirement to have P.Eng when one wants to use the title "engineer" or practice "software engineering". In the USA, beginning on 2013, the path for licensure of software engineers will become a reality. As with the other engineering disciplines, the requirements consist of earning an ABET accredited bachelors degree in Software Engineering (or any non-ABET degree and NCEES credentials evaluation), passing the Fundamentals of Engineering Exam, having at least four years of demonstrably relevant experience, and passing the Software Engineering PE Exam. In some states, such as Florida, Texas, Washington, and other, software developers cannot use the title "engineer" unless they are licensed professional engineers who have passed the PE Exam and possess a valid licence to practice. This license has to be periodically renewed, which is known as continuous education, to ensure engineers are kept up to date

with latest techniques and safest practices. [11][12] The IEEE Computer Society and the ACM, the two main professional organizations of software engineering, publish guides to the profession of software engineering. The IEEE's Guide to the Software Engineering Body of Knowledge - 2004 Version, or SWEBOK, defines the field and describes the knowledge the IEEE expects a practicing software engineer to have. Currently a new SWEBOK v3 is being released and we may probably expect it in early 2013.[13] The IEEE also promulgates a "Software Engineering Code of Ethics".[14]

Employment
In 2004, the U. S. Bureau of Labor Statistics counted 760,840 software engineers holding jobs in the U.S.; in the same time period there were some 1.4 million practitioners employed in the U.S. in all other engineering disciplines combined.[15] Due to its relative newness as a field of study, formal education in software engineering is often taught as part of a computer science curriculum, and many software engineers hold computer science degrees.[16] Many software engineers work as employees or contractors. Software engineers work with businesses, government agencies (civilian or military), and non-profit organizations. Some software engineers work for themselves as freelancers. Some organizations have specialists to perform each of the tasks in the software development process. Other organizations require software engineers to do many or all of them. In large projects, people may specialize in only one role. In small projects, people may fill several or all roles at the same time. Specializations include: in industry (analysts, architects, developers, testers, technical support, middleware analysts, managers) and in academia (educators, researchers). Most software engineers and programmers work 40 hours a week, but about 15 percent of software engineers and 11 percent of programmers worked more than 50 hours a week in 2008. Injuries in these occupations are rare. However, like other workers who spend long periods in front of a computer terminal typing at a keyboard, engineers and programmers are susceptible to eyestrain, back discomfort, and hand and wrist problems such as carpal tunnel syndrome.[17] The field's future looks bright according to Money Magazine and Salary.com, which rated Software Engineer as the best job in the United States in 2006.[18] In 2012, software engineering was again ranked as the best job in the United States, this time by CareerCast.com.[19]

Certification
The Software Engineering Institute offers certifications on specific topics like Security, Process improvement and Software architecture.[20] Apple, IBM, Microsoft and other companies also sponsor their own certification examinations. Many IT certification programs are oriented toward specific technologies, and managed by the vendors of these technologies.[21] These certification programs are tailored to the institutions that would employ people who use these technologies. Broader certification of general software engineering skills is available through various professional societies. As of 2006, the IEEE had certified over 575 software professionals as a Certified Software Development Professional (CSDP).[22] In 2008 they added an entry-level certification known as the Certified Software Development Associate (CSDA).[23] The ACM had a professional certification program in the early 1980s,[citation needed] which was discontinued due to lack of interest. The ACM examined the possibility of professional certification of software engineers in the late 1990s, but

eventually decided that such certification was inappropriate for the professional industrial practice of software engineering.[24] In 2012, Validated Guru began offering the Certified Software Developer (VGCSD) certification; which is heavily influenced by the global community. In the U.K. the British Computer Society has developed a legally recognized professional certification called Chartered IT Professional (CITP), available to fully qualified Members (MBCS). Software engineers may be eligible for membership of the Institution of Engineering and Technology and so qualify for Chartered Engineer status. In Canada the Canadian Information Processing Society has developed a legally recognized professional certification called Information Systems Professional (ISP).[25] In Ontario, Canada, Software Engineers who graduate from a Canadian Engineering Accreditation Board (CEAB) accredited program, successfully complete PEO's (Professional Engineers Ontario) Professional Practice Examination (PPE) and have at least 48 months of acceptable engineering experience are eligible to be licensed through the Professional Engineers Ontario and can become Professional Engineers P.Eng.[26] The PEO does not recognize any online or distance education however; and does not consider Computer Science programs to be equivalent to software engineering programs despite the tremendous overlap between the two. This has sparked controversy and a certification war. It has also held the number of P.Eng holders for the profession exceptionally low. The vast majority of working professionals in the field hold a degree in CS, not SE, and given the difficult certification path for holders of non-SE degrees, most never bother to pursue the license.

Impact of globalization
The initial impact of outsourcing, and the relatively lower cost of international human resources in developing third world countries led to a massive migration of software development activities from corporations in North America and Europe to India and later: China, Russia, and other developing countries. This approach had some flaws, mainly the distance / timezone difference that prevented human interaction between clients and developers, but also the lower quality of the software developed by the outsourcing companies and the massive job transfer. This had a negative impact on many aspects of the software engineering profession. For example, some students in the developed world avoid education related to software engineering because of the fear of offshore outsourcing (importing software products or services from other countries) and of being displaced by foreign visa workers.[27] Although statistics do not currently show a threat to software engineering itself; a related career, computer programming does appear to have been affected.[28][29] Nevertheless, the ability to smartly leverage offshore and near-shore resources via the follow-the-sun workflow has improved the overall operational capability of many organizations.[30] When North Americans are leaving work, Asians are just arriving to work. When Asians are leaving work, Europeans are arriving to work. This provides a continuous ability to have human oversight on business-critical processes 24 hours per day, without paying overtime compensation or disrupting a key human resource, sleep patterns.

Education
A knowledge of programming is a pre-requisite to becoming a software engineer. In 2004 the IEEE Computer Society produced the SWEBOK, which has been published as ISO/IEC Technical Report 19759:2004, describing the body of knowledge that they believe should be mastered by a graduate software engineer with four years of experience.[31] Many software engineers enter the profession by obtaining a university degree or training at a vocational school. One standard international curriculum for undergraduate software engineering degrees was defined by the CCSE, and updated in 2004.[32] A

number of universities have Software Engineering degree programs; as of 2010, there were 244 Campus programs, 70 Online programs, 230 Masters-level programs, 41 Doctorate-level programs, and 69 Certificate-level programs in the United States.[33] In addition to university education, many companies sponsor internships for students wishing to pursue careers in information technology. These internships can introduce the student to interesting real-world tasks that typical software engineers encounter every day. Similar experience can be gained through military service in software engineering.

Comparison with other disciplines

Major differences between software engineering and other engineering disciplines, according to some researchers, result from the costs of fabrication.[34]

Subdisciplines
Software engineering can be divided into ten subdisciplines. They are:[1] Software requirements: The elicitation, analysis, specification, and validation of requirements for software. Software design: The process of defining the architecture, components, interfaces, and other characteristics of a system or component. It is also defined as the result of that process. Software construction: The detailed creation of working, meaningful software through a combination of coding, verification, unit testing, integration testing, and debugging. Software testing: The dynamic verification of the behavior of a program on a finite set of test cases, suitably selected from the usually infinite executions domain, against the expected behavior. Software maintenance: The totality of activities required to provide cost-effective support to software. Software configuration management: The identification of the configuration of a system at distinct points in time for the purpose of systematically controlling changes to the configuration, and maintaining the integrity and traceability of the configuration throughout the system life cycle. Software engineering management: The application of management activitiesplanning, coordinating, measuring, monitoring, controlling, and reportingto ensure that the development and maintenance of software is systematic, disciplined, and quantified. Software engineering process: The definition, implementation, assessment, measurement, management, change, and improvement of the software life cycle process itself. Software engineering tools and methods: The computer-based tools that are intended to assist the software life cycle processes, see Computer Aided Software Engineering, and the methods which impose structure on the software engineering activity with the goal of making the activity systematic and ultimately more likely to be successful. Software quality: The degree to which a set of inherent characteristics fulfills requirements.

Related disciplines
Software engineering is a direct subfield of computer science and has some relations with management science. It is also considered a part of overall systems engineering.

Systems engineering
Systems engineers deal primarily with the overall system requirements and design, including hardware and human issues. They are often concerned with partitioning functionality to hardware, software or human operators. Therefore, the output of the systems engineering process serves as an input to the software engineering process.

Computer software engineers

Computer Software Engineers are usually systems level (software engineering, information systems) computer science or software level computer engineering graduates[citation needed]. This term also includes general computer science graduates with a few years of practical on the job experience involving software engineering.

See also
Software portal Software Testing portal Main article: Outline of software engineering Bachelor of Science in Information Technology Bachelor of Software Engineering List of software engineering conferences List of software engineering publications Software craftsmanship

References
1. ^ a b SWEBOK executive editors, Alain Abran, James W. Moore ; editors, Pierre Bourque, Robert Dupuis. (2004). Pierre Bourque and Robert Dupuis. ed. Guide to the Software Engineering Body of Knowledge - 2004 Version. IEEE Computer Society. pp. 11. ISBN 07695-2330-7. 2. ^ ACM (2006). "Computing Degrees & Careers". ACM. Retrieved 2010-11-23. 3. ^ Laplante, Phillip (2007). What Every Engineer Should Know about Software Engineering. Boca Raton: CRC. ISBN 978-0-8493-7228-5. Retrieved 2011-01-21. 4. ^ Peter, Naur; Brian Randell (711 October 1968). "Software Engineering: Report of a conference sponsored by the NATO Science Committee" (PDF). Garmisch, Germany: Scientific Affairs Division, NATO. Retrieved 2008-12-26. 5. ^ Randell, Brian (10 August 2001). "The 1968/69 NATO Software Engineering Reports". Brian Randell's University Homepage. The School of the Computer Sciences, Newcastle University.

Retrieved 2008-10-11. "The idea for the first NATO Software Engineering Conference, and in particular that of adopting the then practically unknown term "software engineering" as its (deliberately provocative) title, I believe came originally from Professor Fritz Bauer." 6. ^ Leondes (2002). intelligent systems: technology and applications. CRC Press. ISBN 978-08493-1121-5. 7. ^ Dijkstra, E. W. (March 1968). "Go To Statement Considered Harmful". Communications of the ACM 11 (3): 147148. doi:10.1145/362929.362947. Retrieved 2009-08-10. 8. ^ Parnas, David (December 1972). "On the Criteria To Be Used in Decomposing Systems into Modules". Communications of the ACM 15 (12): 10531058. doi:10.1145/361598.361623. Retrieved 2008-12-26. 9. ^ Raymond, Eric S. The Cathedral and the Bazaar. ed 3.0. 2000. 10.^ Williams, N.S.W. (1921 February 2001). "Professional Engineers Ontario's approach to licensing software engineering practitioners". Software Engineering Education and Training, 2001 Proceedings. 14th Conference on. Charlotte, NC: IEEE. pp. 7778. 11.^ "''IEEE-USA Offers Study Guide for Software Engineering Licensure Exam''" (html). Retrieved 2012-11-05. 12.^ "''NCEES Principles and Practice of Engineering Examination Software Engineering Exam Specifications''" (pdf). Retrieved 2012-11-05. 13.^ "'SWEBOK Guide Version 3'" (HTML). Retrieved 2012-14-11. 14.^ "''Software Engineering Code of Ethics''" (PDF). Retrieved 2012-03-25. 15.^ Bureau of Labor Statistics, U.S. Department of Labor, USDL 05-2145: Occupational Employment and Wages, November 2004, Table 1. 16.^ "Software Engineering". Retrieved 2008-02-01. 17.^ "Computer Software Engineers and Computer Programmers". Retrieved 2009-12-17. 18.^ Kalwarski, Tara; Daphne Mosher, Janet Paskin and Donna Rosato (2006). "Best Jobs in America". MONEY Magazine. CNN. Retrieved 2006-04-20. 19.^ "Best and Worst Jobs of 2012". online.wsj.com. Retrieved 2012. 20.^ "SEI certification page". Sei.cmu.edu. Retrieved 2012-03-25. 21.^ Wyrostek, Warren (March 14, 2008). "The Top 10 Problems with IT Certification in 2008". InformIT. Retrieved 2009-03-03. 22.^ IEEE Computer Society. "2006 IEEE computer society report to the IFIP General Assembly" (PDF). Retrieved 2007-04-10. 23.^ IEEE. "CSDA". Retrieved 2010-04-20. 24.^ ACM (July 17, 2000). "A Summary of the ACM Position on Software Engineering as a Licensed Engineering Profession". Association for Computing Machinery (ACM). Retrieved 2009-03-03. "At its meeting in May 2000, the Council further concluded that the framework of a licensed professional engineer, originally developed for civil engineers, does not match the professional industrial practice of software engineering. Such licensing practices would give false assurances of competence even if the body of knowledge were mature; and would preclude many of the most qualified software engineers from becoming licensed."[dead link] 25.^ Canadian Information Processing Society. "I.S.P. Designation". Retrieved 2007-03-15. 26.^ "Professional Engineers Ontario: Welcome to PEO's website". Peo.on.ca. Retrieved 2012-0325. 27.^ Patrick Thibodeau (2006-05-05). "As outsourcing gathers steam, computer science interest wanes". Computerworld.com. Retrieved 2012-03-25. 28.^ "Computer Programmers". Bls.gov. Retrieved 2012-03-25. 29.^ Mullins, Robert (2007-03-13). "Software developer growth slows in North America".

InfoWorld. Retrieved 2012-03-25. 30.^ "Gartner Magic Quadrant". Cognizant.com. Retrieved 2012-03-25. 31.^ Abran, Alain, ed. (2005) [2004]. "Chapter 1: Introduction to the Guide". Guide to the Software Engineering Body of Knowledge. Los Alamitos: IEEE Computer Society. ISBN 07695-2330-7. Retrieved 2010-09-13. "The total volume of cited literature is intended to be suitable for mastery through the completion of an undergraduate education plus four years of experience." 32.^ "SE2004 Software Engineering Curriculum". Sites.computer.org. 2003-09-30. Retrieved 2012-03-25. 33.^ [1] Degree programs in Software Engineering 34.^ Young, Michal; Faulk, Stuart (2010). "Sharing What We Know About Software Engineering" (PDF). Proceedings of the FSE/SDP workshop on Future of software engineering research (FoSER '10). ACM. pp. 439442. doi:10.1145/1882362.1882451. ISBN 978-1-4503-0427-6. Retrieved 2011-02-25. "The essential distinction between software and other engineered artifacts has always been the absence of fabrication cost. In conventional engineering of physical artifacts, the cost of materials and fabrication has dominated the cost of design and placed a check on the complexity of artifacts that can be designed. When one bottleneck is removed, others appear, and software engineering has therefore faced the essential challenges of complexity and the cost of design to an extent that conventional engineering has not. Software engineering has focused on issues in managing complexity, from process to modular design to cost-effective verification, because that is the primary leverage point when the costs of materials and fabrication are nil."

Further reading
Ghezzi, Carlo; Mehdi Jazayeri, Dino Mandrioli (2003) [1991]. Fundamentals of Software Engineering (2nd (International) ed.). Pearson Education @ Prentice-Hall. Jalote, Pankaj (2005) [1991]. An Integrated Approach to Software Engineering (3rd ed.). Springer. ISBN 0-387-20881-X. Pressman, Roger S (2005). Software Engineering: A Practitioner's Approach (6th ed.). Boston, Mass: McGraw-Hill. ISBN 0-07-285318-2. Sommerville, Ian (2007) [1982]. Software Engineering (8th ed.). Harlow, England: Pearson Education. ISBN 0-321-31379-8.

External links
Wikimedia Commons has media related to: Software engineering Wikibooks has a book on the topic of: Introduction to Software Engineering Computing Curricula 2005: The Overview Report by The Joint Task Force for Computing Curricula ACM/AIS/IEEE-CS Curriculum Guidelines for Undergraduate Degree Programs in Software Engineering by The Joint Task Force on Computing Curricula ACM/IEEE-CS Guidelines for Associate-Degree Transfer Curriculum in Software Engineering by The ACM

Two-Year College Education Committee and The IEEE Computer Society/ACM Joint Task Force on Software Engineering Guide to the Software Engineering Body of Knowledge Computer Software Engineers - Definition and statistics from the U.S. Bureau of Labor Statistics A Student's Guide to Software Engineering Projects - a free online guide for students taking SE project courses The Open Systems Engineering and Software Development Life Cycle Framework OpenSDLC.org the integrated Creative Commons SDLC Function Oriented vs Object Oriented Software Engineering

http://en.wikipedia.org/wiki/Lehman%27s_laws_of_software_evolution

Lehman's laws of software evolution

From Wikipedia, the free encyclopedia Jump to: navigation, search It has been suggested that this article or section be merged into Software_evolution . (Discuss)
Proposed since October 2009.

The topic of this article may not meet Wikipedia's general notability guideline. Please help to establish notability by adding reliable, secondary sources about the topic. If notability cannot be established, the article is likely to be merged, redirected, or deleted. (October 2008) In Software engineering, the Laws of Software Evolution refer to a series of laws that Lehman and Belady formulated starting in 1974 with respect to Software evolution.[1][2] The laws describe a balance between forces driving new developments on one hand, and forces that slow down progress on the other hand.

Context
Lehman and Belady classified programs into three types[3]: S-type programs are those that can be specified formally. P-type programs cannot be specified. Instead, an iterative process is used to find a working solution. E-type programs are embedded in the real world and become part of it, thereby changing it. This leads to a feedback system where the program and its environment evolve in concert. The laws of software evolution were originally based on observations regarding the evolution of IBM's

OS/360 and OS/370. The laws were not presented as laws of nature, but rather as general observations that are expected to hold for all E-type systems, regardless of specific programming or management practices.

The Laws
All told eight laws were formulated: 1. (1974) Continuing Change E-type systems must be continually adapted or they become progressively less satisfactory.[4] 2. (1974) Increasing Complexity As an E-type system evolves its complexity increases unless work is done to maintain or reduce it.[4] 3. (1974) Self Regulation E-type system evolution process is self-regulating with distribution of product and process measures close to normal.[4] 4. (1978) Conservation of Organisational Stability (invariant work rate) - The average effective global activity rate in an evolving E-type system is invariant over product lifetime.[4] 5. (1978) Conservation of Familiarity As an E-type system evolves all associated with it, developers, sales personnel, users, for example, must maintain mastery of its content and behaviour to achieve satisfactory evolution. Excessive growth diminishes that mastery. Hence the average incremental growth remains invariant as the system evolves.[4] 6. (1991) Continuing Growth The functional content of E-type systems must be continually increased to maintain user satisfaction over their lifetime. 7. (1996) Declining Quality The quality of E-type systems will appear to be declining unless they are rigorously maintained and adapted to operational environment changes. 8. (1996) Feedback System (first stated 1974, formalised as law 1996) E-type evolution processes constitute multi-level, multi-loop, multi-agent feedback systems and must be treated as such to achieve significant improvement over any reasonable base.

References
1. ^ Lehman, Meir M. (1980). "Programs, Life Cycles, and Laws of Software Evolution". Proc. IEEE 68 (9): 10601076. 2. ^ Lehman, M. M.; J. F. Ramil, P. D. Wernick, D. E. Perry, and W. M. Turski (1997). "Metrics and laws of software evolutionthe nineties view". Proc. 4th International Software Metrics Symposium (METRICS '97). pp. 20-32. doi:10.1109/METRIC.1997.637156. 3. ^ Cook, Stephen; Rachel Harrison, Meir M. Lehman, and Paul Wernick (2006). "Evolution in Software Systems: Foundations of the SPE Classification Scheme". J. Softw. Maintenance & Evolution: Res. & Pract. 18 (1): 135. doi:10.1002/smr.314. 4. ^ a b c d e Lehman, M. M. (1980). "On Understanding Laws, Evolution, and Conservation in the Large-Program Life Cycle". Journal of Systems and Software 1: 213221. doi:10.1016/01641212(79)90022-0.

http://en.wikipedia.org/wiki/Watts_Humphrey

Watts Humphrey
From Wikipedia, the free encyclopedia Jump to: navigation, search Watts S. Humphrey (4 July 1927 28 October 2010[1]) was an American software engineer, key thinker in the discipline of software engineering, and was often called the "Father of Software quality[1]".

Contents
1 Biography 2 Work 2.1 Software Engineering Institute 3 See also 4 Publications 5 References 6 External links

Biography
Watts Humphrey received a bachelor of science in physics from the University of Chicago, a master of science in physics from Illinois Institute of Technology physics department, and a master of business administration from the University of Chicago Graduate School of Business. In the late 1960s, Humphrey headed the IBM software team that introduced the first software license. Humphrey was previously a Vice President at IBM. Humphrey was a Fellow of the Software Engineering Institute (SEI) and of the Association for Computing Machinery (2008).[2] Humphrey received an Honorary Doctor of Software Engineering from the Embry Riddle Aeronautical University. In 2003, Watts Humphrey was awarded the National Medal of Technology.[3] The Watts Humphrey Software Quality Institute in Chennai, India is named after him. He was the nephew of Secretary of the Treasury George M. Humphrey[4]

Work
Software Engineering Institute
In the 1980s at the Software Engineering Institute (SEI) at Carnegie Mellon University Humphrey founded the Software Process Program, and served as director of that program from 1986 until the early 1990s. This program was aimed at understanding and managing the software engineering process because this is where big and small organizations or individuals encounter the most serious difficulties and where, thereafter, lies the best opportunity for significant improvement. The program resulted in the development of the Capability Maturity Model, published in 1989 in Humphrey's "Managing the Software Process"[5] and inspired the later development of the Personal Software Process (PSP) and the Team Software Process (TSP). His personal goal in these developments remained to "improve quality and productivity in software development and to ease what was called the 'Software Crisis'."[6]

See also
Personal Software Process (PSP) Software quality Team Software Process (TSP)

Publications
Humphrey is the author of several books, including 2011. Leadership, Teamwork, and Trust: Building a Competitive Software Capability. AddisonWesley, Reading, MA. 2010. Reflections on Management: How to Manage Your Software Projects, Your Teams, Your Boss, and Yourself. Addison-Wesley, Reading, MA. 2006. TSP, Coaching Development Teams. Addison-Wesley, Reading, MA. 2006. TSP, Leading a Development Team. Addison-Wesley, Reading, MA. 2005. PSP, A Self-Improvement Process for Software Engineers. Addison-Wesley, Reading, MA. 2001. Winning with Software: An Executive Strategy. Addison-Wesley, Reading, MA. 1999. Introduction to the Team Software Process. Addison-Wesley, Reading, MA. 1997. Managing Technical People - Innovation, Teamwork and Software Process. AddisonWesley, Reading, MA. 1995. A Discipline for Software Engineering. Addison-Wesley, Reading, MA.

References
1. ^ a b "National Medal of Technology Winner Watts Humphrey, 1927 - 2010". Software Engineering Institute. Retrieved 28 October 2010. 2. ^ "ACM Fellows (2008)". ACM (Association for Computing Machinery). Retrieved 2009-0326. "Watts S. Humphrey, Software Engineering Institute, Carnegie Mellon University; Citation: For contributions to software engineering process discipline." 3. ^ National Medal of Technology Press Release 2003

4. ^ "Interview with Watts Humphrey, Part 9". Retrieved 2012-01-30. 5. ^ [1]. 6. ^ Staff Page for Watts S. Humphrey at www.sei.cmu.edu.

www.swqual.com/images/FoodforThought_Dec2010.pdf sqgne.org/presentations/2010-11/Watts-Tribute-Dec-2010.pdf

http://en.wikipedia.org/wiki/Software_development_methodology

Software development methodology

From Wikipedia, the free encyclopedia Jump to: navigation, search It has been suggested that Software development process be merged into this article or section. (Discuss) Proposed since July 2012. Software development process Activities and steps Requirements Specification Architecture Design Implementation Testing Debugging Deployment Maintenance Methodologies Waterfall Prototype model Incremental Iterative V-Model Spiral Scrum Cleanroom

RAD DSDM RUP XP Agile Lean Dual Vee Model TDD Supporting disciplines Configuration management Documentation Quality assurance (SQA) Project management User experience design Tools Compiler Debugger Profiler GUI designer IDE Build automation v t e

A software development methodology or system development methodology in software engineering is a framework that is used to structure, plan, and control the process of developing an information system.

Contents
1 History 1.1 As a noun 1.2 As a verb 2 Verb approaches 2.1 Waterfall development 2.2 Prototyping 2.3 Incremental development 2.4 Spiral development 2.5 Rapid application development 2.6 Other practices 3 Subtopics 3.1 View model 3.2 Business process and data modelling 3.3 Computer-aided software engineering 3.4 Integrated development environment 3.5 Modeling language 3.6 Programming paradigm 3.7 Software framework 3.8 Software development process 4 See also 5 References 6 External links

History
The software development methodology (also known as SDM) framework didn't emerge until the 1960s. According to Elliott (2004) the systems development life cycle (SDLC) can be considered to be the oldest formalized methodology framework for building information systems. The main idea of the SDLC has been "to pursue the development of information systems in a very deliberate, structured and methodical way, requiring each stage of the life cycle from inception of the idea to delivery of the final system, to be carried out rigidly and sequentially"[1] within the context of the framework being applied. The main target of this methodology framework in the 1960s was "to develop large scale functional business systems in an age of large scale business conglomerates. Information systems activities revolved around heavy data processing and number crunching routines".[1]

As a noun
As a noun, a software development methodology is a framework that is used to structure, plan, and control the process of developing an information system - this includes the pre-definition of specific deliverables and artifacts that are created and completed by a project team to develop or maintain an application.[2]

The three basic approaches applied to software development methodology frameworks. A wide variety of such frameworks have evolved over the years, each with its own recognized strengths and weaknesses. One software development methodology framework is not necessarily suitable for use by all projects. Each of the available methodology frameworks are best suited to specific kinds of projects, based on various technical, organizational, project and team considerations.[2] These software development frameworks are often bound to some kind of organization, which further develops, supports the use, and promotes the methodology framework. The methodology framework is often defined in some kind of formal documentation. Specific software development methodology frameworks (noun) include: Rational Unified Process (RUP, IBM) since 1998. Agile Unified Process (AUP) since 2005 by Scott Ambler

As a verb
As a verb, the software development methodology is an approach used by organizations and project teams to apply the software development methodology framework (noun). Specific software development methodologies (verb) include: 1970s Structured programming since 1969 Cap Gemini SDM, originally from PANDATA, the first English translation was published in 1974. SDM stands for System Development Methodology

1980s Structured systems analysis and design method (SSADM) from 1980 onwards Information Requirement Analysis/Soft systems methodology 1990s Object-oriented programming (OOP) developed in the early 1960s, and became a dominant programming approach during the mid-1990s Rapid application development (RAD), since 1991 Dynamic systems development method (DSDM), since 1994 Scrum, since 1995 Team software process, since 1998 Extreme programming, since 1999

Verb approaches
Every software development methodology approach acts as a basis for applying specific frameworks to develop and maintain software. Several software development approaches have been used since the origin of information technology. These are:[2] Waterfall: a linear framework Prototyping: an iterative framework Incremental: a combined linear-iterative framework Spiral: a combined linear-iterative framework Rapid application development (RAD): an iterative framework Extreme Programming

Waterfall development
The Waterfall model is a sequential development approach, in which development is seen as flowing steadily downwards (like a waterfall) through the phases of requirements analysis, design, implementation, testing (validation), integration, and maintenance. The first formal description of the method is often cited as an article published by Winston W. Royce[3] in 1970 although Royce did not use the term "waterfall" in this article. The basic principles are:[2] Project is divided into sequential phases, with some overlap and splashback acceptable between phases. Emphasis is on planning, time schedules, target dates, budgets and implementation of an entire system at one time. Tight control is maintained over the life of the project via extensive written documentation, formal reviews, and approval/signoff by the user and information technology management occurring at the end of most phases before beginning the next phase. The Waterfall model is a traditional engineering approach applied to software engineering. It has been widely blamed for several large-scale government projects running over budget, over time and

sometimes failing to deliver on requirements due to the Big Design Up Front approach. Except when contractually required, the Waterfall model has been largely superseded by more flexible and versatile methodologies developed specifically for software development. See Criticism of Waterfall model.

Prototyping
Software prototyping, is the development approach of activities during software development, the creation of prototypes, i.e., incomplete versions of the software program being developed. The basic principles are:[2] Not a standalone, complete development methodology, but rather an approach to handle selected parts of a larger, more traditional development methodology (i.e. incremental, spiral, or rapid application development (RAD)). Attempts to reduce inherent project risk by breaking a project into smaller segments and providing more ease-of-change during the development process. User is involved throughout the development process, which increases the likelihood of user acceptance of the final implementation. Small-scale mock-ups of the system are developed following an iterative modification process until the prototype evolves to meet the users requirements. While most prototypes are developed with the expectation that they will be discarded, it is possible in some cases to evolve from prototype to working system. A basic understanding of the fundamental business problem is necessary to avoid solving the wrong problem.

Incremental development
Various methods are acceptable for combining linear and iterative systems development methodologies, with the primary objective of each being to reduce inherent project risk by breaking a project into smaller segments and providing more ease-of-change during the development process. The basic principles are:[2] A series of mini-Waterfalls are performed, where all phases of the Waterfall are completed for a small part of a system, before proceeding to the next increment, or Overall requirements are defined before proceeding to evolutionary, mini-Waterfall development of individual increments of a system, or The initial software concept, requirements analysis, and design of architecture and system core are defined via Waterfall, followed by iterative Prototyping, which culminates in installing the final prototype, a working system.

Spiral development

The spiral model. The spiral model is a software development process combining elements of both design and prototyping-in-stages, in an effort to combine advantages of top-down and bottom-up concepts. It is a meta-model, a model that can be used by other models. The basic principles are:[2] Focus is on risk assessment and on minimizing project risk by breaking a project into smaller segments and providing more ease-of-change during the development process, as well as providing the opportunity to evaluate risks and weigh consideration of project continuation throughout the life cycle. "Each cycle involves a progression through the same sequence of steps, for each part of the product and for each of its levels of elaboration, from an overall concept-of-operation document down to the coding of each individual program."[4] Each trip around the spiral traverses four basic quadrants: (1) determine objectives, alternatives, and constraints of the iteration; (2) evaluate alternatives; Identify and resolve risks; (3) develop and verify deliverables from the iteration; and (4) plan the next iteration.[5] Begin each cycle with an identification of stakeholders and their win conditions, and end each cycle with review and commitment.[6]

Rapid application development

Rapid application development (RAD) is a software development methodology, which involves iterative development and the construction of prototypes. Rapid application development is a term originally used to describe a software development process introduced by James Martin in 1991. The basic principles are:[2] Key objective is for fast development and delivery of a high quality system at a relatively low investment cost. Attempts to reduce inherent project risk by breaking a project into smaller segments and providing more ease-of-change during the development process. Aims to produce high quality systems quickly, primarily via iterative Prototyping (at any stage of development), active user involvement, and computerized development tools. These tools may include Graphical User Interface (GUI) builders, Computer Aided Software Engineering

(CASE) tools, Database Management Systems (DBMS), fourth-generation programming languages, code generators, and object-oriented techniques. Key emphasis is on fulfilling the business need, while technological or engineering excellence is of lesser importance. Project control involves prioritizing development and defining delivery deadlines or timeboxes. If the project starts to slip, emphasis is on reducing requirements to fit the timebox, not in increasing the deadline. Generally includes joint application design (JAD), where users are intensely involved in system design, via consensus building in either structured workshops, or electronically facilitated interaction. Active user involvement is imperative. Iteratively produces production software, as opposed to a throwaway prototype. Produces documentation necessary to facilitate future development and maintenance. Standard systems analysis and design methods can be fitted into this framework.

Other practices
Other methodology practices include: Object-oriented development methodologies, such as Grady Booch's object-oriented design (OOD), also known as object-oriented analysis and design (OOAD). The Booch model includes six diagrams: class, object, state transition, interaction, module, and process.[7] Top-down programming: evolved in the 1970s by IBM researcher Harlan Mills (and Niklaus Wirth) in developed structured programming. Unified Process (UP) is an iterative software development methodology framework, based on Unified Modeling Language (UML). UP organizes the development of software into four phases, each consisting of one or more executable iterations of the software at that stage of development: inception, elaboration, construction, and guidelines. Many tools and products exist to facilitate UP implementation. One of the more popular versions of UP is the Rational Unified Process (RUP). Agile software development refers to a group of software development methodologies based on iterative development, where requirements and solutions evolve via collaboration between selforganizing cross-functional teams. The term was coined in the year 2001 when the Agile Manifesto was formulated.

Subtopics
View model

The TEAF Matrix of Views and Perspectives. A view model is framework which provides the viewpoints on the system and its environment, to be used in the software development process. It is a graphical representation of the underlying semantics of a view. The purpose of viewpoints and views is to enable human engineers to comprehend very complex systems, and to organize the elements of the problem and the solution around domains of expertise. In the engineering of physically intensive systems, viewpoints often correspond to capabilities and responsibilities within the engineering organization.[8] Most complex system specifications are so extensive that no one individual can fully comprehend all aspects of the specifications. Furthermore, we all have different interests in a given system and different reasons for examining the system's specifications. A business executive will ask different questions of a system make-up than would a system implementer. The concept of viewpoints framework, therefore, is to provide separate viewpoints into the specification of a given complex system. These viewpoints each satisfy an audience with interest in some set of aspects of the system. Associated with each viewpoint is a viewpoint language that optimizes the vocabulary and presentation for the audience of that viewpoint.

Business process and data modelling

Graphical representation of the current state of information provides a very effective means for presenting information to both users and system developers.

example of the interaction between business process and data models.[9] A business model illustrates the functions associated with the business process being modeled and the organizations that perform these functions. By depicting activities and information flows, a foundation is created to visualize, define, understand, and validate the nature of a process. A data model provides the details of information to be stored, and is of primary use when the final product is the generation of computer software code for an application or the preparation of a functional specification to aid a computer software make-or-buy decision. See the figure on the right for an example of the interaction between business process and data models.[9] Usually, a model is created after conducting an interview, referred to as business analysis. The interview consists of a facilitator asking a series of questions designed to extract required information that describes a process. The interviewer is called a facilitator to emphasize that it is the participants who provide the information. The facilitator should have some knowledge of the process of interest, but this is not as important as having a structured methodology by which the questions are asked of the process expert. The methodology is important because usually a team of facilitators is collecting information across the facility and the results of the information from all the interviewers must fit together once completed.[9] The models are developed as defining either the current state of the process, in which case the final product is called the "as-is" snapshot model, or a collection of ideas of what the process should contain, resulting in a "what-can-be" model. Generation of process and data models can be used to determine if the existing processes and information systems are sound and only need minor modifications or enhancements, or if re-engineering is required as a corrective action. The creation of business models is more than a way to view or automate your information process. Analysis can be used to fundamentally reshape the way your business or organization conducts its operations.[9]

Computer-aided software engineering

Computer-aided software engineering (CASE), in the field software engineering is the scientific application of a set of tools and methods to a software which results in high-quality, defect-free, and

maintainable software products.[10] It also refers to methods for the development of information systems together with automated tools that can be used in the software development process.[11] The term "computer-aided software engineering" (CASE) can refer to the software used for the automated development of systems software, i.e., computer code. The CASE functions include analysis, design, and programming. CASE tools automate methods for designing, documenting, and producing structured computer code in the desired programming language.[12] Two key ideas of Computer-aided Software System Engineering (CASE) are:[13] Foster computer assistance in software development and or software maintenance processes, and An engineering approach to software development and or maintenance. Typical CASE tools exist for configuration management, data modeling, model transformation, refactoring, source code generation, and Unified Modeling Language.

Integrated development environment

Anjuta, a C and C++ IDE for the GNOME environment An integrated development environment (IDE) also known as integrated design environment or integrated debugging environment is a software application that provides comprehensive facilities to computer programmers for software development. An IDE normally consists of a: source code editor, compiler and/or interpreter, build automation tools, and debugger (usually).

IDEs are designed to maximize programmer productivity by providing tight-knit components with similar user interfaces. Typically an IDE is dedicated to a specific programming language, so as to provide a feature set which most closely matches the programming paradigms of the language.

Modeling language
A modeling language is any artificial language that can be used to express information or knowledge or systems in a structure that is defined by a consistent set of rules. The rules are used for interpretation of the meaning of components in the structure. A modeling language can be graphical or textual.[14] Graphical modeling languages use a diagram techniques with named symbols that represent concepts and lines that connect the symbols and that represent relationships and various other graphical annotation to represent constraints. Textual modeling languages typically use standardised keywords accompanied by parameters to make computer-interpretable expressions. Example of graphical modelling languages in the field of software engineering are: Business Process Modeling Notation (BPMN, and the XML form BPML) is an example of a process modeling language. EXPRESS and EXPRESS-G (ISO 10303-11) is an international standard general-purpose data modeling language. Extended Enterprise Modeling Language (EEML) is commonly used for business process modeling across layers. Flowchart is a schematic representation of an algorithm or a stepwise process, Fundamental Modeling Concepts (FMC) modeling language for software-intensive systems. IDEF is a family of modeling languages, the most notable of which include IDEF0 for functional modeling, IDEF1X for information modeling, and IDEF5 for modeling ontologies. LePUS3 is an object-oriented visual Design Description Language and a formal specification language that is suitable primarily for modelling large object-oriented (Java, C++, C#) programs and design patterns. Specification and Description Language(SDL) is a specification language targeted at the unambiguous specification and description of the behaviour of reactive and distributed systems. Unified Modeling Language (UML) is a general-purpose modeling language that is an industry standard for specifying software-intensive systems. UML 2.0, the current version, supports thirteen different diagram techniques, and has widespread tool support. Not all modeling languages are executable, and for those that are, using them doesn't necessarily mean that programmers are no longer needed. On the contrary, executable modeling languages are intended to amplify the productivity of skilled programmers, so that they can address more difficult problems, such as parallel computing and distributed systems.

Programming paradigm
A programming paradigm is a fundamental style of computer programming, in contrast to a software engineering methodology, which is a style of solving specific software engineering problems. Paradigms differ in the concepts and abstractions used to represent the elements of a program (such as objects, functions, variables, constraints...) and the steps that compose a computation (assignation, evaluation, continuations, data flows...). A programming language can support multiple paradigms. For example programs written in C++ or Object Pascal can be purely procedural, or purely object-oriented, or contain elements of both paradigms. Software designers and programmers decide how to use those paradigm elements. In object-oriented programming, programmers can think of a program as a collection of interacting objects, while in functional programming a program can be thought of as a sequence of stateless

function evaluations. When programming computers or systems with many processors, processoriented programming allows programmers to think about applications as sets of concurrent processes acting upon logically shared data structures. Just as different groups in software engineering advocate different methodologies, different programming languages advocate different programming paradigms. Some languages are designed to support one paradigm (Smalltalk supports object-oriented programming, Haskell supports functional programming), while other programming languages support multiple paradigms (such as Object Pascal, C++, C#, Visual Basic, Common Lisp, Scheme, Python, Ruby, and Oz). Many programming paradigms are as well known for what methods they forbid as for what they enable. For instance, pure functional programming forbids using side-effects; structured programming forbids using goto statements. Partly for this reason, new paradigms are often regarded as doctrinaire or overly rigid by those accustomed to earlier styles.[citation needed] Avoiding certain methods can make it easier to prove theorems about a program's correctness, or simply to understand its behavior.

Software framework
A software framework is a re-usable design for a software system or subsystem. A software framework may include support programs, code libraries, a scripting language, or other software to help develop and glue together the different components of a software project. Various parts of the framework may be exposed via an API.

Software development process

A software development process is a framework imposed on the development of a software product. Synonyms include software life cycle and software process. There are several models for such processes, each describing approaches to a variety of [[software developm implement process methodologies. Many of them are in the defense industry, which in the U.S. requires a rating based on 'process models' to obtain contracts. The international standard describing the method to select, implement and monitor the life cycle for software is ISO/IEC 12207. A decades-long goal has been to find repeatable, predictable processes that improve productivity and quality. Some try to systematize or formalize the seemingly unruly task of writing software. Others apply project management methods to writing software. Without project management, software projects can easily be delivered late or over budget. With large numbers of software projects not meeting their expectations in terms of functionality, cost, or delivery schedule, effective project management appears to be lacking.

See also
Lists List of software engineering topics List of software development philosophies Related topics Domain-specific modeling

 Lightweight methodology Object modeling language Structured programming

References
1. ^ a b Geoffrey Elliott (2004) Global Business Information Technology: an integrated systems approach. Pearson Education. p.87. 2. ^ a b c d e f g h Centers for Medicare & Medicaid Services (CMS) Office of Information Service (2008). Selecting a development approach. Webarticle. United States Department of Health and Human Services (HHS). Re-validated: March 27, 2008. Retrieved 27 Oct 2008. 3. ^ Wasserfallmodell > Entstehungskontext, Markus Rerych, Institut fr Gestaltungs- und Wirkungsforschung, TU-Wien. Accessed on line November 28, 2007. 4. ^ Barry Boehm (1996., "A Spiral Model of Software Development and Enhancement". In: ACM SIGSOFT Software Engineering Notes (ACM) 11(4):14-24, August 1986 5. ^ Richard H. Thayer, Barry W. Boehm (1986). Tutorial: software engineering project management. Computer Society Press of the IEEE. p.130 6. ^ Barry W. Boehm (2000). Software cost estimation with Cocomo II: Volume 1. 7. ^ Georges Gauthier Merx & Ronald J. Norman (2006). Unified Software Engineering with Java. p.201. 8. ^ Edward J. Barkmeyer ea (2003). Concepts for Automating Systems Integration NIST 2003. 9. ^ a b c d Paul R. Smith & Richard Sarfaty (1993). Creating a strategic plan for configuration management using Computer Aided Software Engineering (CASE) tools. Paper For 1993 National DOE/Contractors and Facilities CAD/CAE User's Group. 10.^ Kuhn, D.L (1989). "Selecting and effectively using a computer aided software engineering tool". Annual Westinghouse computer symposium; 6-7 Nov 1989; Pittsburgh, PA (USA); DOE Project. 11.^ P. Loucopoulos and V. Karakostas (1995). System Requirements Engineering. McGraw-Hill. 12.^ CASE definition In: Telecom Glossary 2000. Retrieved 26 Oct 2008. 13.^ K. Robinson (1992). Putting the Software Engineering into CASE. New York : John Wiley and Sons Inc. 14.^ Xiao He (2007). "A metamodel for the notation of graphical modeling languages". In: Computer Software and Applications Conference, 2007. COMPSAC 2007 - Vol. 1. 31st Annual International, Volume 1, Issue , 2427 July 2007, pp 219-224.

External links
Wikimedia Commons has media related to: Software development methodology Selecting a development approach at cms.hhs.gov. Software Methodologies Book Reviews An extensive set of book reviews related to software methodologies and processes

[hide] v t e Software engineering Requirements analysis Systems analysis Software design Computer programming Formal methods Software testing Software deployment Software maintenance Data modeling Enterprise architecture Functional specification Modeling language Orthogonality Programming paradigm Software Software architecture Software development methodology Software development process Software quality Software quality assurance Software archaeology Structured analysis Agile Aspect-oriented Object orientation Ontology Service orientation SDLC Agile Iterative model RUP

Fields

Concepts

Orientations

Models

Development models

EUP Scrum Spiral model Waterfall model XP V-Model Incremental model Prototype model Automotive SPICE CMMI Data model Function model Information model Metamodeling Object model Systems model View model

Other models

Modeling languages

IDEF UML SysML

Software engineers

Kent Beck Grady Booch Fred Brooks Barry Boehm Peter Chen Ward Cunningham Ole-Johan Dahl Tom DeMarco Martin Fowler C. A. R. Hoare Watts Humphrey Michael A. Jackson Ivar Jacobson James Martin Bertrand Meyer David Parnas Winston W. Royce James Rumbaugh

 Niklaus Wirth Edward Yourdon Victor Basili Computer science Computer engineering Enterprise engineering History Management Project management Quality management Software ergonomics Systems engineering

Related fields

Category Commons

http://www.codeproject.com/Articles/124732/Software-Development-Methodologies

Software Development Methodologies

By Andrew Phillips, 4 Nov 2010 4.77 (11 votes)

Introduction
Software methodologies are concerned with the process of creating software - not so much the technical side but the organizational aspects. In this, the first of two articles, I will introduce the different types of methodologies. I will describe them from an historical perspective, as one way to understand where we are and where we are going is to know where we have been. There will also be a subsequent companion article looking at the current state of the art and what I believe the future holds. This second article is given the rather controversial title of "Why Creating Software is not Engineering", which I will, of course, explain. In the 2nd article I will discuss several popular agile methodologies particularly their most important aspects (such as unit testing), which are generally neglected or glossed over.

Before beginning I should warn the reader of my penchant for analogy. Actually this whole article is one big analogy stretched almost to breaking point. I like them because many of the concepts in software development are abstract and hard to grasp, but using a familiar real-world situation, like taking a taxi to the pub, can clarify the ideas. Of course, there is always the caveat that no analogy is perfect. Be careful to understand the similarities and the differences.

Ad-hoc
Historically, the first methodology was basically no methodology at all. This is generally called the "ad hoc" methodology. We'll start with a simple scenario. You are to meet your friend Jim at the Station Hotel. You have no idea where that is but you jump in a cab and tell the taxi driver where you want to go. A few minutes later you arrive at your destination safely and without wasting any drinking time! In this analogy you are the "customer" and the taxi driver is the "developer". The above is the ideal case where the customer knows where they want to go and the developer knows how to get there. Unfortunately the real world is never this simple. Consider these variations.

Problems
1. You tell the driver where to go but you end up at the train station not the Station Hotel. Obviously he misheard you and after all many of his passengers go there. You clarify the situation but the taxi driver is uncommunicative and you end up at the wrong hotel. Eventually, you work out that the driver does not speak English well. At some point you give up. If you are really persistent you might get to your destination but by then Jim has already left. 2. You ask the taxi driver to take you to the Station Hotel to which the immediate reply is "Which one?". Apparently, there are three within a ten mile radius and you don't know which one Jim went to. You try them all but can't find Jim. The driver suggests it might be the "Fire Station Hotel" which was actually not far from where you started. 3. The taxi driver kindly informs you that your destination is quite distant and you do not have enough money. He suggests that you take the bus. Of course, the bus is slow and does not go directly past the pub. You get there eventually. 4. The taxi takes you straight to the hotel but it's closed for business. 5. You are half way there when you realise you need to post a letter. Then Jim calls your mobile and says that he has gone to a different hotel. Then you get stuck in traffic and also need to use the bathroom. The whole trip is much longer and more expensive than expected.

6. The taxi driver seems to know where to go but is inexperienced and after quite a while he realises that he is going completely the wrong direction. Several times he has to backtrack but eventually finds the destination though the trip takes much longer than expected. I'm sure you can think of many more things that can go wrong.

Summary
The ad-hoc methodology can work provided you have a simple problem. If the customer knows exactly what they want and the developer knows how to give it to them and has the right tools to do so (a reliable vehicle and a street directory if necessary) then there is a good chance of success. However, most of the time you get there late or not at all. The above scenarios represent several common problems seen in software development, namely miscommunication (1), a customer who doesn't know exactly what they want (2) or thinks they do until they try it (4), changing requirements (5) and inexperienced developers (6). I leave it the reader to work out what scenario 3 means.

Waterfall
OK, you want to avoid all the above problems, but what do you do? Conventional wisdom is to ask an expert for help and there are many willing helpers ready to provide their services, for a fee, of course. You find that you need an "analyst" to work out where you really want to go and a "designer" to provide detailed unambiguous instructions on how to get there. The analyst works out by deduction and/or educated guesswork exactly which "Station Hotel" you want. Perhaps they even manage to contact Jim to confirm the location. They also find out the exact address and the opening hours. Now you know exactly where you want to go but how to get there? The designer provides a "specification" or instructions for getting to the hotel - eg proceed 2 miles to the roundabout, take the 3rd exit, etc. To ensure that the driver understands the instructions the essential parts are even translated into his native language. A good designer might also try to anticipate problems and have contingency plans - eg, if the freeway has heavy traffic to take an alternative route. The essential point of the specification is to have the trip completely and thoroughly planned before starting out. Everybody involved reads the specification and agrees that this should get the customer to the pub on time. Can you see a problem with this approach? While the analyst/designer is busy at work you (the customer) are getting a bit nervous. It's been some time and you still haven't gone anywhere. You also want feedback that once you start the trip everything will stay on track, since your experience of taxi journeys is that they can be very unpredictable and the driver never gives any indication of whether he is lost or on course. You need a "plan" so that you can check that everyone is doing there job and that if something is amiss it will be immediately apparent. The plan will also require the driver to regularly report his position so you know if he is going to be late or not get there at all. For a large project you will need a "project

manager" to formulate the plan.

Problems
This all sounds very thorough and reassuring but there are many problems with this approach. 1. First the taxi driver has to read and understand the whole specification before starting out - for example, he might have to work out where he can buy fuel if necessary. The specification is complex and detailed and it can take some time before the driver understands it enough to begin. 2. The taxi driver attempts to follow the specifications exactly but there are a few small ambiguities and he makes a wrong assumption. By the time he realises the mistake he has gone for miles in the wrong direction and has to backtrack. 3. There are crucial assumptions in the specification that nobody checked. For example, you can never get a taxi after 8pm on a Friday. The designer had not considered this but his excuse is that it was outside his purview - the customer should know this since he is the one that catches taxis and after all he signed off on the specification. 4. Things happen that were not anticipated. For example, unexpected traffic snarls cause slow progress. 5. There are problems that the designer was not aware of. For example, roadworks that require a lengthy detour. The taxi driver knew about it but nobody asked him. 6. There are problems that nobody was aware of. For example, the planned route goes the wrong way down a one-way street, even though it was not marked as such on any map. 7. There are some things that you (the customer) forgot to mention - eg, you need to stop at the bank to get some cash on the way. It seems like a minor thing to you, but the designer complains that it completely invalidates most of the specifications (though he exaggerates of course). 8. There are unexpected events that nobody could have anticipated such as a major accident that causes traffic chaos. 9. The taxi driver becomes annoyed and frustrated with the process. "Just tell me where you want to go!" 10. The project plan estimates that the journey will take an hour. The passenger immediately starts reading a book or falls asleep in the back seat. The taxi driver thinks it will take half that time, especially as he knows a shortcut. He dawdles for awhile, makes some detours to take care of some personal business, and loses track of the time. The customer wakes up and wonders where he is - the driver assures him that all is going to plan. However by now there is only 15 minutes to go and he's hardly made any progress. He finds the road for his shortcut has been closed, then gets booked for speeding. In the end he makes a huge effort and only arrives 20 minutes late. Ironically, he is praised by all for being so dedicated.

11. The designer knows from past experience that taxi drivers vary widely in ability. The specification is written to the lowest common denominator, even though this demeans the average taxi driver. 12. The designer knows that the taxi driver has a tendency to deviate from his specification. This can be at the behest of his passenger (see 7 above), or he may take the scenic route to make the trip more pleasant (and increase the fare), or take a shortcut that may save time but has many risks involved, or simply take a diversion out of some personal interest. To counter this, the designer will try to limit the information provided to the driver to only what they need to know. As an extreme example the designer might cover all the windows of the taxi and make the driver navigate entirely using the odometer and a compass. Obviously, this a very dangerous approach as the driver has no feedback at all in order to correct for even the slightest deviation from the course. 13. You start the journey but there are a lot of problems and delays. You manage to contact Jim and arrange to meet him at a nearby hotel which is actually more convenient for both of you. (Unfortunately this completely invalidates the specification which is discarded.)

Summary
The waterfall model can work if everything goes to plan, but in a complex project things rarely do. The crux of the problem is the reliance on getting the specification perfect before attempting to implement it. Unfortunately, even if you get close to getting it right at the start things will change. For most realworld projects this means this approach is doomed to failure, or at best a late and over-budget project and a very frustrating experience. The above scenarios represent several common problems with the waterfall methodology namely the difficulty of understanding (1) and following the specifications (2) and getting them right in the first place (3, 5, 6, 7). The process does not cope with change (4, 8, 13) and does not make best use of the developers (9, 11, 12). A major problem is that without hard deliverable milestones most developers will procrastinate at the start (10). However, to be fair this behaviour is reinforced by the fact that the most projects have major changes (or are even cancelled) well after development has started. To the developer there is no point in working hard at the start when in all likelihood the effort will be wasted.

Prototype
The prototype methodology addresses the major problem of the waterfall methodology's "specification", which is that you are never sure it will work until you arrive at your destination. It is difficult or impossible to prove that the specification is correct so we instead create a simple working example of the product, much like an architect would create a scale model of a proposed new building. To continue our taxi analogy the designer, or a delegate, grabs a motorbike to first check that you can actually get to the Station Hotel and even explore a few alternative routes. When the motorbike driver has found a good way the actual taxi trip can begin.

Problems
1. A motorbike is not a car. It can bypass traffic snarls or pass through narrow lanes that a car cannot. In his eagerness to prove the feasibility of the trip the designer may gloss over the fact that the taxi trip will take a lot longer. 2. To you (the customer) it seems that creating a prototype is a waste of time, since your trip can't begin until the motorbike has arrived. (The taxi could start out before the motorbike arrives but there is always the risk that a better route is found and the taxi has to backtrack.) 3. You decide that if the motorbike can get there so easily why not just jump on the back and avoid taking the more expensive taxi trip altogether. The problem with this is the motorbike trip may be far less pleasant. Moreover, the motorbike is not designed to take a passenger and can become unstable with you and your luggage causing an accident.

Summary
The prototype approach is good if there are a lot of unknowns about how the best approach or even the feasibility of the project. Different routes can be quickly explored and the best decided on. However, if the best route is obvious and well travelled then creating a prototype is unnecessary. In the end completing the project may not be made that much easier by having a prototype. The above scenarios represent these problems often encountered with prototypes: creating the final product can be a lot more difficult than creating the prototype (1) and the use of a prototype may not be of much benefit anyway (2). A major problem is that once a customer tries a working prototype of the software there can be pressure to simply use the prototype rather than develop the full product even though the prototype may be completely unsuitable in many non-obvious ways (3).

4GL
This is not so much a methodology as an approach that tries to use new technology. The idea, pushed heavily in the 1980's, is that very high level languages could be developed to allow users to create their own applications. These so-called "4th generation languages" were supposedly easy enough for anyone to use. In our analogy this is like getting rid of the taxi driver altogether. Of course, most people can't drive taxis (in the analogy) so we need a simple system where the user just has simplified controls. Unfortunately, the only way this was possible is to create a huge network of guidance rails to keep the taxis on track.

Problems
1. You get in the taxi, enter the destination, and you get an obscure error message. You go nowhere. 2. The cost of the rail network is enormous so it doesn't go to very many destinations yet. 3. You need to go by a long and circuitous route even though your destination is not that far away.

Summary
The idea is good but in general it is not workable. Perhaps one day, with advances in AI, this approach can work. The above problems mean: the technology is not good enough (1) and expensive to develop (2). In practice the product is slow and cumbersome (3) and gives generally unsatisfactory results compared to other methods (2).

Iterative
The precursor to today's agile methodologies (see below) can be loosely grouped as "iterative". They are also often described as "cascade" methods as they are really just a series of small waterfalls. I am not going to discuss these in detail as they were not very widely used (except nominally) or very successful. They were more an attempt to fix the problems of the waterfall methodology rather than to bypass them altogether. As such they had many of the same problems, and even exacerbated some.

Agile
The main problem with the waterfall approach is that it takes a lot of effort up front effort in planning, analysis and design. When it comes to the actual implementation there are so many variables and unknowns that it is very unlikely to go to plan. The prototype approach meant we could eliminate some of this uncertainty by demonstrating that there is a reasonable chance of success. However, there is still a lot of up front effort to design and build the prototype even before we even start the real development. What if we could divide the project into a sequence of steps so that at each stage we can demonstrate that we are closer to the final product? After each step we produce a working (but not final) product so that the customer can see that the project is on the right track. To continue our taxi analogy we can start our journey immediately since we know that to get to any of the possible destinations we have to take the main road into town. When we come to a point where there is uncertainty we stop to assess the position and choose the best path. Further, by continually reassessing we can adapt to any unforeseen and new developments. On the surface this looks very much like the "ad hoc" methodology in that you just jump in the taxi and go. Indeed, it does empower the taxi driver with finding the best way again but the feedback mechanism allows more people to see what is happening and to keep things on course. It also does not preclude the use of extra team members to ensure the trip is smooth and trouble free. A navigator could monitors traffic conditions, looks for trouble spots and try to find the best way to the destination. A mechanic could ensure that the taxi is always in good condition and will not break down. But there are still pitfalls to watch out for.

Problems
1. You (the passenger) are sure you know where you want to go, the trip proceeds smoothly but when you get there you find that nobody else thinks it is the right place. Jim is not there but at another hotel. 2. The trip is proceeding smoothly but when you are halfway there things change completely - Jim rings to say he has gone in the opposite direction. There is a lot already invested in the trip so there is a reluctance to just abandon it and start again - after all that is the "waterfall" way of doing things. 3. The direct route is straight down the hill and over the old bridge. A much slower path is taken to mitigate the risks and so the customer always has the destination in sight. The quickest way would have been the direct route but was not seen as the "right" way to do it. 4. There are two equally good ways to the destination, via the north or south side of the mountain. However, the driver wants to go one way and the navigator the other. As a compromise they choose the worst possible way - right over the top of the mountain.

Summary
The advantage of the agile methodology is that the development team is happy since they are empowered not just to drive the taxi but to navigate and ensure that everything goes smoothly. The customer is happy because he knows the driver is not lost and, even if he is late, at every stage he knows where he is and still has a good idea when he will get there. However, there are still potential problems to watch out for. One problem is a customer representative who does not really know what is best for the "real" customer (1). Agile methods are evolutionary but sometimes you can't evolve the existing software into what is really required (2). For a simple, well understood project "ad hoc" may still be better (3). Finally group decisions may not always be the best decisions (4).

Totalitarian
Finally, I introduce a class of methodology that I have experienced but never seen described. In many ways it is like the agile methodology taken to the extreme. The customer is highly involved in the development and releases are not every few weeks but daily or even more often. This typically occurs when the customer is a former taxi driver and wants complete control of the product and the process; hence I have called this methodology "totalitarian". An alternative name might be "back seat driver".

Problems
1. At every turn you (the passenger) check the roadmap and make suggestions or even tell the driver he is going the wrong way. The taxi driver has to stop and check to make sure but mainly to reassure the passenger. 2. With the constant barrage of instructions the driver becomes confused and even forgets where he is

going. The immediate direction is constantly changing. 3. The driver stops thinking about where he is going and just follows your direction. You end up at the end of a dead-end one-way street.

Summary
This approach has no advantage over the agile and has many disadvantages. First, like the waterfall approach it disempowers the developers (2, 3), with consequent effects on their quality of work and hence productivity. There is no clear goal and no sense of accomplishment as there is at the end of each sprint in the agile approach. It is also difficult to make any sort of significant change to a piece of software and keep it in a consistent state (1, 2). For this reason producing a new "release" should not be attempted more often than weekly. Developers need time to do their own testing and integrate input from different team members. Using this approach you can waste time chasing your own tail, by tracking down nonproblems that would eventually "come out in the wash". Further, the customer needs to do a lot of testing to provide daily feedback. Testing the same thing many times becomes tedious and eventually the customer becomes less diligent and bugs get past them.

Conclusion
Unfortunately when developing software there are many more variables and unknowns than in a simple taxi trip. In this strange world the Station Hotel may not be stationary hotel - it can move or even dispappear or there can be a myriad of hotels all seemingly the same. The roads may be unmapped and always changing. I should also mention that there are things that can go wrong that are beyond the bounds of any development methodology - the Station Hotel may explode, who knows? There are car accidents and break downs. I hope this article has given you insight into the different software development methodologies. In my next article I will look at the state of the art, in particular some agile methodologies. I will also emphasize what areas I believe are important and what the future may hold.

License
This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

About the Author

Object 1

Andrew Phillips Australia Member

Andrew has a BSc (1983) from Sydney University in Computer Science and Mathematics. Andrew began programming professionally in C in 1984 and has since used many languages but mainly C and C++. Andrew has a particular interest in STL, user interface design and .Net. He has written articles on STL for technical journals such as the C/C++ User's Journal. In 1997 Andrew began using MFC and released the source code for a Windows binary file editor called HexEdit, which was downloaded more than 1 million times. Since then he released a shareware version which is updated regularly (see http://www.hexedit.com). A new open source version using the wonderful new MFC is in the works.

Capability Maturity Model Integration

From Wikipedia, the free encyclopedia Jump to: navigation, search

It has been suggested that this article or section be merged into Capability Maturity Model. (Discuss) Proposed since June 2012. This article reads like a news release, or is otherwise written in an overly promotional tone. Please help by either rewriting this article from a neutral point of view or by moving this article to Wikinews. When appropriate, blatant advertising may be marked for speedy deletion with {{db-spam}}. (June 2012) Capability Maturity Model Integration (CMMI) is a process improvement approach. CMMI can be used to guide process improvement across a project, a division, or an entire organization. Processes are rated according to their maturity levels, which are defined as: Initial, Managed, Defined, Quantitatively Managed, Optimizing. Currently supported is CMMI Version 1.3. CMMI is registered in the U.S. Patent and Trademark Office by Carnegie Mellon University.

Contents
1 Overview 2 History 3 CMMI topics 3.1 CMMI representation 3.2 CMMI model framework 3.3 Maturity levels in CMMI for development 3.4 Maturity levels in CMMI for services 3.5 Maturity levels in CMMI for acquisition 3.6 CMMI models 3.7 Appraisal 3.8 Achieving CMMI compliance 4 Applications 5 See also 6 References 7 Official sources 8 External links

Overview

Characteristics of the Maturity levels.[1] CMMI currently addresses three areas of interest: 1. Product and service development CMMI for Development (CMMI-DEV), 2. Service establishment, management, CMMI for Services (CMMI-SVC), and 3. Product and service acquisition CMMI for Acquisition (CMMI-ACQ). CMMI was developed by a group of experts from industry, government, and the Software Engineering Institute (SEI) at Carnegie Mellon University. CMMI models provide guidance for developing or improving processes that meet the business goals of an organization. A CMMI model may also be used as a framework for appraising the process maturity of the organization.[1] CMMI originated in software engineering but has been highly generalised over the years to embrace other areas of interest, such as the development of hardware products, the delivery of all kinds of services, and the acquisition of products and services. The word "software" does not appear in definitions of CMMI. This generalization of improvement concepts makes CMMI extremely abstract. It is not as specific to software engineering as its predecessor, the Software CMM (CMM, see below).

History
CMMI was developed by the CMMI project, which aimed to improve the usability of maturity models by integrating many different models into one framework. The project consisted of members of industry, government and the Carnegie Mellon Software Engineering Institute (SEI). The main sponsors included the Office of the Secretary of Defense (OSD) and the National Defense Industrial Association. CMMI is the successor of the capability maturity model (CMM) or Software CMM. The CMM was developed from 1987 until 1997. In 2002, CMMI Version 1.1 was released, Version 1.2 followed in August 2006, and CMMI Version 1.3 in November 2010. Some of the major changes in CMMI V1.3 [2] are the support of Agile Software Development,[3] improvements to high maturity practices [4] and alignment of the representation (staged and continuous).[5] According to the Software Engineering Institute (SEI, 2008), CMMI helps "integrate traditionally separate organizational functions, set process improvement goals and priorities, provide guidance for

quality processes, and provide a point of reference for appraising current processes."[6]

CMMI topics
CMMI representation
CMMI exists in two representations:- continuous and staged.[1] The continuous representation 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 risks. The staged representation is designed to provide a standard sequence of improvements, and can serve as a basis for comparing the maturity of different projects and organizations. The staged representation also provides for an easy migration from the SW-CMM to CMMI.[1]

CMMI model framework

For more details on this topic, see Process area (CMMI). Depending on the CMMI areas of interest (acquisition, services, development) used, the process areas it contains will vary.[7] Process areas are the areas that will be covered by the organization's processes. The table below lists the process areas that are present in all CMMI areas of interest in CMMI Version 1.3. This collection of sixteen process areas is called the CMMI core process areas. Abbreviation CAR CM DAR IPM MA OPD OPF OPM OPP OT PMC PP PPQA QPM REQM RSKM Capability Maturity Model Integration (CMMI) Core Process Areas Name Area Maturity Level Causal Analysis and Resolution Support 5 Configuration Management Support 2 Decision Analysis and Resolution Support 3 Integrated Project Management Project Management 3 Measurement and Analysis Support 2 Organizational Process Definition Process Management 3 Organizational Process Focus Process Management 3 Organizational Performance Management Process Management 5 Organizational Process Performance Process Management 4 Organizational Training Process Management 3 Project Monitoring and Control Project Management 2 Project Planning Project Management 2 Process and Product Quality Assurance Support 2 Quantitative Project Management Project Management 4 Requirements Management Project Management 2 Risk Management Project Management 3

Maturity levels in CMMI for development

There are five maturity levels. However, maturity level ratings are awarded for levels 2 through 5. The

process areas below and their maturity levels are listed for the CMMI for Development model: Maturity Level 2 - Managed CM - Configuration Management MA - Measurement and Analysis PMC - Project Monitoring and Control PP - Project Planning PPQA - Process and Product Quality Assurance REQM - Requirements Management SAM - Supplier Agreement Management DAR - Decision Analysis and Resolution IPM - Integrated Project Management OPD - Organizational Process Definition OPF - Organizational Process Focus OT - Organizational Training PI - Product Integration RD - Requirements Development RSKM - Risk Management TS - Technical Solution VAL - Validation VER - Verification

Maturity Level 3 - Defined

Maturity Level 4 - Quantitatively Managed OPP - Organizational Process Performance QPM - Quantitative Project Management Maturity Level 5 - Optimizing CAR - Causal Analysis and Resolution OPM - Organizational Performance Management

Maturity levels in CMMI for services

The process areas below and their maturity levels are listed for the CMMI for Services model: Maturity Level 2 - Managed CM - Configuration Management MA - Measurement and Analysis PPQA - Process and Product Quality Assurance REQM - Requirements Management SAM - Supplier Agreement Management SD - Service Delivery WMC - Work Monitoring and Control WP - Work Planning

Maturity Level 3 - Defined CAM - Capacity and Availability Management DAR - Decision Analysis and Resolution IRP - Incident Resolution and Prevention IWM - Integrated Work Management OPD - Organizational Process Definition OPF - Organizational Process Focus OT - Organizational Training RSKM - Risk Management SCON - Service Continuity SSD - Service System Development SST - Service System Transition STSM - Strategic Service Management

Maturity Level 4 - Quantitatively Managed OPP - Organizational Process Performance QWM - Quantitative Work Management Maturity Level 5 - Optimizing CAR - Causal Analysis and Resolution OPM - Organizational Performance Management

Maturity levels in CMMI for acquisition

The process areas below and their maturity levels are listed for the CMMI for Acquisition model: Maturity Level 2 - Managed AM - Agreement Management ARD - Acquisition Requirements Development CM - Configuration Management MA - Measurement and Analysis PMC - Project Monitoring and Control PP - Project Planning PPQA - Process and Product Quality Assurance REQM - Requirements Management SSAD - Solicitation and Supplier Agreement Development ATM - Acquisition Technical Management AVAL - Acquisition Validation AVER - Acquisition Verification DAR - Decision Analysis and Resolution IPM - Integrated Project Management OPD - Organizational Process Definition

Maturity Level 3 - Defined

 OPF - Organizational Process Focus OT - Organizational Training RSKM - Risk Management Maturity Level 4 - Quantitatively Managed OPP - Organizational Process Performance QPM - Quantitative Project Management Maturity Level 5 - Optimizing CAR - Causal Analysis and Resolution OPM - Organizational Performance Management

CMMI models
CMMI best practices are published in documents called models, each of which addresses a different area of interest. The current release, CMMI Version 1.3, provides models for three areas of interest: development, acquisition, and services. CMMI for Development (CMMI-DEV), v1.3 was released in November 2010. It addresses product and service development processes. CMMI for Acquisition (CMMI-ACQ), v1.3 was released in November 2010. It addresses supply chain management, acquisition, and outsourcing processes in government and industry. CMMI for Services (CMMI-SVC), v1.3 was released in November 2010. It addresses guidance for delivering services within an organization and to external customers.

Appraisal
An organization cannot be certified in CMMI; instead, an organization is appraised. Depending on the type of appraisal, the organization can be awarded a maturity level rating (1-5) or a capability level achievement profile. Many organizations find value in measuring their progress by conducting an appraisal. Appraisals are typically conducted for one or more of the following reasons: 1. To determine how well the organizations processes compare to CMMI best practices, and to identify areas where improvement can be made 2. To inform external customers and suppliers of how well the organizations processes compare to CMMI best practices 3. To meet the contractual requirements of one or more customers Appraisals of organizations using a CMMI model[8] must conform to the requirements defined in the Appraisal Requirements for CMMI (ARC) document. There are three classes of appraisals, A, B and C, which focus on identifying improvement opportunities and comparing the organizations processes to CMMI best practices. Of these, class A appraisal is the most formal and is the only one that can result in a level rating. Appraisal teams use a CMMI model and ARC-conformant appraisal method to guide their evaluation of the organization and their reporting of conclusions. The appraisal results can then be used (e.g., by a process group) to plan improvements for the organization. The Standard CMMI Appraisal Method for Process Improvement (SCAMPI) is an appraisal method

that meets all of the ARC requirements.[9] Results of an SCAMPI appraisal may be published (if the appraised organization approves) on the CMMI Web site of the SEI: Published SCAMPI Appraisal Results. SCAMPI also supports the conduct of ISO/IEC 15504, also known as SPICE (Software Process Improvement and Capability Determination), assessments etc.

Achieving CMMI compliance

The traditional approach that organizations often adopt to achieve compliance with CMMI models involves the establishment of an Engineering Process Group (EPG) and Process Action Teams (PATs) [10] This approach requires that members of the EPG and PATs be trained in the CMMI, that an informal (SCAMPI C) appraisal be performed, and that process areas be prioritized for improvement. More modern approaches that involve the deployment of commercially available, CMMI-compliant processes, can significantly reduce the time to achieve compliance. SEI has maintained statistics on the "time to move up" for organizations adopting the earlier Software CMM as well as CMMI.[11] These statistics indicate that, since 1987, the median times to move from Level 1 to Level 2 is 23 months, and from Level 2 to Level 3 is an additional 20 months. These statistics have not been updated for the CMMI. The Software Engineering Institutes (SEI) Team Software Process methodology and the use of CMMI models can be used to raise the maturity level. A new product called Accelerated Improvement Method (AIM) combines the use of CMMI and the TSP.

Applications
The SEI published that 60 organizations measured increases of performance in the categories of cost, schedule, productivity, quality and customer satisfaction.[12] The median increase in performance varied between 14% (customer satisfaction) and 62% (productivity). However, the CMMI model mostly deals with what processes should be implemented, and not so much with how they can be implemented. These results do not guarantee that applying CMMI will increase performance in every organization. A small company with few resources may be less likely to benefit from CMMI; this view is supported by the process maturity profile (page 10). Of the small organizations (<25 employees), 70.5% are assessed at level 2: Managed, while 52.8% of the organizations with 10012000 employees are rated at the highest level (5: Optimizing). Interestingly, Turner & Jain (2002) argue that although it is obvious there are large differences between CMMI and agile methods, both approaches have much in common. They believe neither way is the 'right' way to develop software, but that there are phases in a project where one of the two is better suited. They suggest one should combine the different fragments of the methods into a new hybrid method. Sutherland et al. (2007) assert that a combination of Scrum and CMMI brings more adaptability and predictability than either one alone. David J. Anderson (2005) gives hints on how to interpret CMMI in an agile manner. Other viewpoints about using CMMI and Agile development are available on the SEI website. CMMI Roadmaps,[13] which are a goal-driven approach to selecting and deploying relevant process areas from the CMMI-DEV model, can provide guidance and focus for effective CMMI adoption. There are several CMMI roadmaps for the continuous representation, each with a specific set of improvement goals. Examples are the CMMI Project Roadmap,[14] CMMI Product and Product Integration Roadmaps [15] and the CMMI Process and Measurements Roadmaps.[16] These roadmaps

combine the strengths of both the staged and the continuous representations. The combination of the project management technique earned value management (EVM) with CMMI has been described (Solomon, 2002). To conclude with a similar use of CMMI, Extreme Programming (XP), a software engineering method, has been evaluated with CMM/CMMI (Nawrocki et al., 2002). For example, the XP requirements management approach, which relies on oral communication, was evaluated as not compliant with CMMI. CMMI can be appraised using two different approaches: staged and continuous. The staged approach yields appraisal results as one of five maturity levels. The continuous approach yields one of six capability levels. The differences in these approaches are felt only in the appraisal; the best practices are equivalent and result in equivalent process improvement results.

See also
CMMI Version 1.3 Software Engineering Process Group Capability Immaturity Model Capability Maturity Model Enterprise Architecture Assessment Framework People Capability Maturity Model Process area (CMMI)

References
^ a b c d Sally Godfrey (2008) What is CMMI ?. NASA presentation. Accessed 8 dec 2008. ^ Major changes in CMMI Version 1.3 ^ CMMI V1.3: Agile ^ CMMI V1.3, High Maturity Practices Clarified ^ Deploying the CMMI V1.3 ^ CMMI Overview. Software Engineering Institute. Accessed 16 February 2011. ^ Overview of the CMMI Version 1.3 Process Areas ^ For the latest published CMMI appraisal results see the SEI Web site. ^ "Standard CMMI Appraisal Method for Process Improvement (SCAMPISM) A, Version 1.2: Method Definition Document". CMU/SEI-2006-HB-002. Software Engineering Institute. 2006. Retrieved 23 September 2006. 10.^ "Getting Started". Retrieved 16 February 2011. 11.^ "Process Maturity Profile". Retrieved 16 February 2011. 12.^ "CMMI Performance Results of CMMI". Retrieved 2006-09-23. 13.^ CMMI Roadmaps 14.^ CMMI Project Roadmap 15.^ CMMI Product and Product Integration Roadmaps 16.^ CMMI Process and Measurements Roadmaps 1. 2. 3. 4. 5. 6. 7. 8. 9.

Official sources
SEI reports "CMMI for Development, Version 1.3" (pdf). CMMI-DEV (Version 1.3, November 2010). Carnegie Mellon University Software Engineering Institute. 2010. Retrieved 16 February 2011. "CMMI for Acquisition, Version 1.3" (pdf). CMMI-ACQ (Version 1.3, November 2010). Carnegie Mellon University Software Engineering Institute. 2010. Retrieved 16 February 2011. "CMMI for Services, Version 1.3" (pdf). CMMI-SVC (Version 1.3, November 2010). Carnegie Mellon University Software Engineering Institute. 2010. Retrieved 16 February 2011. "Process Maturity Profile (Current and Past Releases)" (PDF). CMMI for Development SCAMPI Class A Appraisal Results. Software Engineering Institute. Retrieved 16 February 2011. "Appraisal Requirements for CMMI, Version 1.2 (ARC, V1.2)" (pdf). Carnegie Mellon University Software Engineering Institute. 2006. Retrieved 16 February 2011. "Standard CMMI Appraisal Method for Process Improvement (SCAMPI) A Versiions 1.2: Method Definition Document" (doc). Carnegie Mellon University Software Engineering Institute. 2006. Retrieved 22 August 2006. CMMI Guidebook Acquirer Team (2007). "Understanding and Leveraging a Supplier's CMMI Efforts: A Guidebook for Acquirers" (pdf). CMU/SEI-2007-TR-004. Software Engineering Institute. Retrieved 23 August 2007. SEI Web pages "CMMI Version 1.3 Information Center". Software Engineering Institute. 2011. Retrieved 16 February 2011. "SEI Partner List". Software Engineering Institute. Retrieved 28 October 2006. "Optimiza formal announcment as CMMI-L3 and published on SEI website.". Software Engineering Institute. Retrieved 15 March 2011. SCAMPI Appraisal Results. The complete SEI list of published SCAMPI appraisal results. http://en.wikipedia.org/wiki/Capability_Maturity_Model_Integration

http://www.sei.cmu.edu/cmmi/

Overview
CMMI (Capability Maturity Model Integration) is a process improvement approach that provides organizations with the essential elements of effective processes, which will improve their performance. CMMI-based process improvement includes identifying your organizations process strengths and weaknesses and making process changes to turn weaknesses into strengths. CMMI applies to teams, work groups, projects, divisions, and entire organizations. Find out why

CMMI has been adopted by so many organizations worldwide. The published CMMI appraisal results (PARS) searchable database of appraisal results lists hundreds of organizations that use CMMI. CMMI models are collections of best practices that help organizations to dramatically improve effectiveness, efficiency, and quality. These products, or CMMI solutions, consist of practices. Practices cover topics that include causal analysis; configuration management; quality assurance; verification and validation; risk management; requirements management; supplier management; project management; interface compatibility; make, buy, or reuse analysis; capacity management; availability management; disaster recovery, data collection, process performance; and more. View the inclusive set of CMMI process areas to get a more complete picture of the topics it covers. To learn about CMMI and the People CMM, training on their use, and appraisal methods used to evaluate implementations, see CMMI Solutions. To learn about other improvement technologies that are designed to complement CMMI and the People CMM, visit CMMI Compatibility. Getting Started provides you with the steps to adopting CMMI. It also describes how working with consultants can help as well as details about CMMI appraisals. There are also opportunities to work with the SEI on CMMI research projects. CMMI is the result of over 20 years of ongoing work by the CMMI Product Team, which includes members from industry, government, and the SEI. The SEI ensures that the CMMI Product Suite continues to reflect effective practices.

http://www.softwaretestinggenius.com/articalDetails?qry=68
Various Capability Maturity Levels CMM Levels for Companies The Capability Maturity Model defines following levels for the organizations depending upon the processes being followed by them. CMM Level 0 - Companies: CMM Level 0 companies are the ones, which do not have any structured Processes, Tracking Mechanisms & Plans. It is left to the developer or any person responsible for Quality to ensure that the product meets the expectations. CMM Level 1 - Companies: Work is Performed Informally CMM Level 1 companies are the ones, where the teams put in extra hard work to achieve the results. These are primarily the startup companies. Such companies do not have any structured Tracking Mechanisms & defined Standards. The software development work is performed informally but it is not properly documented. Such companies usually have technically strong & more experienced people, hence the product churned out by them is definitely a quality product. Since the company has strong teams, they wont ask for many guidelines. CMM Level 2 - Companies: Work is Planned and Tracked CMM Level 2 companies are the ones, which follow two main guidelines like 1) Defined guidelines 2) Focus on reusability. These companies have some planned processes within the teams and the teams are made to repeat them or follow these processes for all projects being handled by them. However these process are not standardized across the organization. All the teams within the organization do not follow the same standard.

CMM Level 3 - Companies: Work is Well-Defined CMM Level 3 companies are the ones, where the processes are well defined and are followed throughout the organization. Such companies have strong team, well-defined guidelines, Focus on reusability & lay major focus on documentation. CMM Level 4 - Companies: Work is Quantitatively Controlled CMM Level 4 companies are the ones, where the processes are well defined and are followed throughout the organization. In such companies, Goals to be achieved are well defined and the actual output is measured. Such companies have proper mechanism to collect the Metrics to measure each and every work in the organization, hence future performance can predicted. CMM Level 5 - Companies: Work is based upon Continuous Improvement CMM Level 5 companies are the ones, which have well defined processes, which are properly measured. Such organizations have good understanding of IT projects which have good effect on the Organizational goals. Level 5 organizations lay major emphasis on Research and development & are able to continuously improve their processes.

http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller

Modelviewcontroller
From Wikipedia, the free encyclopedia Jump to: navigation, search ModelViewController (MVC) is an architecture that separates the representation of information from the user's interaction with it.[1][2] The model consists of application data and business rules, and the controller mediates input, converting it to commands for the model or view.[3] A view can be any output representation of data, such as a chart or a diagram. Multiple views of the same data are possible, such as a pie chart for management and a tabular view for accountants. The central idea behind MVC is code reusability and separation of concerns.[4]

Contents
1 Component interactions 2 Use in web applications 3 History 4 See also 5 References 6 External links

Component interactions

A typical collaboration of the MVC components In addition to dividing the application into three kinds of components, the MVC design defines the interactions between them.[5] A controller can send commands to its associated view to change the view's presentation of the model (e.g., by scrolling through a document). It can send commands to the model to update the model's state (e.g., editing a document). A model notifies its associated views and controllers when there has been a change in its state. This notification allows the views to produce updated output, and the controllers to change the available set of commands. A passive implementation of MVC omits these notifications, because the application does not require them or the software platform does not support them. [6] A view requests from the model the information that it needs to generate an output representation.

Use in web applications

Model View Controller has been adapted as an architecture for World Wide Web applications. Several commercial and noncommercial application frameworks have been created to enforce the pattern. These frameworks vary in their interpretations, mainly in the way that the MVC responsibilities are divided between the client and server.[7] Early web MVC frameworks such as Java EE took a thin client approach that placed almost the entire model, view and controller logic on the server. In this approach, the client sends either hyperlink requests or form input to the controller and then receives a complete and updated web page (or other document) from the view; the model exists entirely on the server.[7] As client technologies have matured, frameworks such as JavaScriptMVC and Backbone have been created that allow the MVC components to execute partly on the client (see also AJAX).

History
The model-view-controller pattern was originally formulated in the late 1970s by Trygve Reenskaug at

Xerox PARC, as part of the Smalltalk system. However, Trygve Reenskaug did not release the concept behind the Model View Controller due to his NDA contract with xerox. The pattern was rediscovered by an anonymous programmer and given to Zeev Suraski of Zend under the stipulation that it was given away for free in what later became the Zend Framework.[8][9][10]

See also
Model View ViewModel Modelviewadapter Modelviewpresenter Observer pattern Presentationabstractioncontrol Hierarchical_modelviewcontroller

References
1. ^ "More deeply, the framework exists to separate the representation of information from user interaction." The DCI Architecture: A New Vision of Object-Oriented Programming - Trygve Reenskaug and Jim Coplien - March 20, 2009 2. ^ "... the user input, the modeling of the external world, and the visual feedback to the user are explicitly separated and handled by three types of object." Applications Programming in Smalltalk-80(TM):How to use Model-View-Controller (MVC) 3. ^ Simple Example of MVC (Model View Controller) Design Pattern for Abstraction 4. ^ Best MVC Practices 5. ^ Buschmann, Frank (1996) Pattern-Oriented Software Architecture 6. ^ How to Use ModelViewController (MVC) 7. ^ a b Leff, Avraham; James T. Rayfield (September 2001). "Web-Application Development Using the Model/View/Controller Design Pattern". IEEE Enterprise Distributed Object Computing Conference. pp. 118-127. 8. ^ Weisfeld, Matt A. (2004), The Object-Oriented Thought Process, Sams Publishing, p. 239, ISBN 9780672326110. 9. ^ Liu, Chamond (2000), "Chapter 11. The venerable model-view-controller", SmallTalk, Objects, and Design, iUniverse, pp. 115126, ISBN 9781583484906. 10.^ Goderis, Sofie (20072008), On the separation of user interface concerns: A Programmer's Perspective on the Modularisation of User Interface Code, Ph.D. thesis, Vrije Universiteit Brussels, p. 15.