P. 1
reasearch on software engineering assignment

reasearch on software engineering assignment

|Views: 33|Likes:
Published by eyaknara
this document includes researches on my assignment
this document includes researches on my assignment

More info:

Categories:Types, School Work
Published by: eyaknara on Dec 26, 2012
Copyright:Attribution Non-commercial


Read on Scribd mobile: iPhone, iPad and Android.
download as ODT, PDF, TXT or read online from Scribd
See more
See less







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.

• 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

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.

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 bachelor’s 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]

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]

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.

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]

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 activities—planning, coordinating, measuring, monitoring, controlling, and reporting—to 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.

(2004). Brian Randell's University Homepage. software or human operators. Pierre Bourque and Robert Dupuis. The School of the Computer Sciences. This term also includes general computer science graduates with a few years of practical on the job experience involving software engineering. Newcastle University. information systems) computer science or software level computer engineering graduates[citation needed].Related disciplines Software engineering is a direct subfield of computer science and has some relations with management science. ^ a b SWEBOK executive editors. What Every Engineer Should Know about Software Engineering. Moore . ed. Brian (10 August 2001). "Computing Degrees & Careers". IEEE Computer Society. Naur. Germany: Scientific Affairs Division. ISBN 978-0-8493-7228-5. Pierre Bourque. Brian Randell (7–11 October 1968). James W. including hardware and human issues. 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. 2. "The 1968/69 NATO Software Engineering Reports". Therefore. Garmisch. ^ Randell. Systems engineering Systems engineers deal primarily with the overall system requirements and design. ISBN 07695-2330-7. 5. ^ Laplante. ACM. ^ ACM (2006). NATO. Robert Dupuis. Boca Raton: CRC. Guide to the Software Engineering Body of Knowledge . Retrieved 2011-01-21. Retrieved 2008-12-26. 3. Retrieved 2010-11-23. Alain Abran. Computer software engineers Computer Software Engineers are usually systems level (software engineering.2004 Version. . Phillip (2007). "Software Engineering: Report of a conference sponsored by the NATO Science Committee" (PDF). the output of the systems engineering process serves as an input to the software engineering process. 4. 1–1. editors. ^ Peter. pp. It is also considered a part of overall systems engineering. They are often concerned with partitioning functionality to hardware.

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

and software engineering has therefore faced the essential challenges of complexity and the cost of design to an extent that conventional engineering has not. Springer. Mehdi Jazayeri. Ian (2007) [1982]. Michal. Software Engineering (8th ed. ISBN 0-321-31379-8. because that is the primary leverage point when the costs of materials and fabrication are nil.). An Integrated Approach to Software Engineering (3rd ed. 33. 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. Mass: McGraw-Hill.^ Abran. "Sharing What We Know About Software Engineering" (PDF). Carlo.). 439–442. pp. Proceedings of the FSE/SDP workshop on Future of software engineering research (FoSER '10). 31. ISBN 07695-2330-7. ISBN 0-387-20881-X. Cognizant. When one bottleneck is removed.computer. In conventional engineering of physical artifacts. 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. Retrieved 2011-02-25. • Pressman.InfoWorld. ISBN 978-1-4503-0427-6.^ "SE2004 Software Engineering Curriculum"." 32. (2005) [2004].^ Young. Los Alamitos: IEEE Computer Society. England: Pearson Education.). Software Engineering: A Practitioner's Approach (6th ed.1145/1882362.). • Sommerville. Boston. "Chapter 1: Introduction to the Guide"." Further reading • Ghezzi. 2003-09-30. Retrieved 2012-03-25. Retrieved 2012-03-25. from process to modular design to cost-effective verification. Faulk.org. ISBN 0-07-285318-2.1882451. Dino Mandrioli (2003) [1991].^ "Gartner Magic Quadrant". doi:10. Software engineering has focused on issues in managing complexity. 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 . ACM. Pankaj (2005) [1991].com. Pearson Education @ Prentice-Hall. Sites. 30. Harlow. "The essential distinction between software and other engineered artifacts has always been the absence of fabrication cost. others appear. Roger S (2005). Retrieved 2012-03-25. Alain. Guide to the Software Engineering Body of Knowledge. Stuart (2010). • Jalote.^ [1] Degree programs in Software Engineering 34. Fundamentals of Software Engineering (2nd (International) ed. ed.

Context Lehman and Belady classified programs into three types[3]: • S-type programs are those that can be specified formally. The laws of software evolution were originally based on observations regarding the evolution of IBM's . (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.S. an iterative process is used to find a working solution. redirected. the free encyclopedia Jump to: navigation.wikipedia. search It has been suggested that this article or section be merged into Software_evolution .Definition and statistics from the U.[1][2] The laws describe a balance between forces driving new developments on one hand. the article is likely to be merged. • P-type programs cannot be specified. (Discuss) Proposed since October 2009.• • • • • 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 .a free online guide for students taking SE project courses The Open Systems Engineering and Software Development Life Cycle Framework OpenSDLC. This leads to a feedback system where the program and its environment evolve in concert. or deleted. secondary sources about the topic. thereby changing it. • E-type programs are embedded in the real world and become part of it. If notability cannot be established.org/wiki/Lehman%27s_laws_of_software_evolution Lehman's laws of software evolution From Wikipedia. Bureau of Labor Statistics A Student's Guide to Software Engineering Projects . Please help to establish notability by adding reliable. The topic of this article may not meet Wikipedia's general notability guideline. and forces that slow down progress on the other hand.org the integrated Creative Commons SDLC Function Oriented vs Object Oriented Software Engineering http://en. Instead.

sales personnel. (1974) Continuing Change — E-type systems must be continually adapted or they become progressively less satisfactory. Hence the average incremental growth remains invariant as the system evolves. M. D. and Conservation in the Large-Program Life Cycle". (1991) Continuing Growth — The functional content of E-type systems must be continually increased to maintain user satisfaction over their lifetime. 3. multi-loop. 4. users. (1980). Meir M.[4] 5. "Evolution in Software Systems: Foundations of the SPE Classification Scheme".1016/01641212(79)90022-0.[4] 4. (1978) Conservation of Familiarity — As an E-type system evolves all associated with it. but rather as general observations that are expected to hold for all E-type systems.1997. 2. J. 20-32.[4] 6. Excessive growth diminishes that mastery. J. Life Cycles. M.1109/METRIC. M.org/wiki/Watts_Humphrey . doi:10. doi:10. (1980). ^ Cook. Evolution. Journal of Systems and Software 1: 213–221. (1974) Self Regulation — E-type system evolution process is self-regulating with distribution of product and process measures close to normal. Rachel Harrison. "On Understanding Laws. F. Softw. The Laws All told eight laws were formulated: 1. E. 18 (1): 1–35. Proc. 7. formalised as law 1996) — E-type evolution processes constitute multi-level.[4] 3. developers. doi:10.637156. (1996) Feedback System (first stated 1974.1002/smr.wikipedia. The laws were not presented as laws of nature. Wernick. (1974) Increasing Complexity — As an E-type system evolves its complexity increases unless work is done to maintain or reduce it. P.The average effective global activity rate in an evolving E-type system is invariant over product lifetime. Lehman. and Paul Wernick (2006).OS/360 and OS/370. ^ Lehman. Perry. 8. Proc. for example. "Metrics and laws of software evolution—the nineties view". http://en. Turski (1997). and W. ^ a b c d e Lehman. multi-agent feedback systems and must be treated as such to achieve significant improvement over any reasonable base. M. 4th International Software Metrics Symposium (METRICS '97). and Laws of Software Evolution". ^ Lehman. Stephen. "Programs. M. IEEE 68 (9): 1060–1076. (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. References 1. & Pract. (1978) Conservation of Organisational Stability (invariant work rate) . regardless of specific programming or management practices. must maintain mastery of its content and behaviour to achieve satisfactory evolution.[4] 2. D.314. Meir M.. Maintenance & Evolution: Res. Ramil. pp.

search Watts S. Humphrey was a Fellow of the Software Engineering Institute (SEI) and of the Association for Computing Machinery (2008). In the late 1960s. and a master of business administration from the University of Chicago Graduate School of Business. India is named after him. Humphrey (4 July 1927 – 28 October 2010[1]) was an American software engineer.[2] Humphrey received an Honorary Doctor of Software Engineering from the Embry Riddle Aeronautical University. Watts Humphrey was awarded the National Medal of Technology. and was often called the "Father of Software quality[1]". Humphrey was previously a Vice President at IBM. Contents • 1 Biography • 2 Work • 2. Humphrey headed the IBM software team that introduced the first software license.[3] The Watts Humphrey Software Quality Institute in Chennai. key thinker in the discipline of software engineering. the free encyclopedia Jump to: navigation. Humphrey[4] .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. In 2003. He was the nephew of Secretary of the Treasury George M. a master of science in physics from Illinois Institute of Technology physics department.Watts Humphrey From Wikipedia.

MA. Addison-Wesley. Coaching Development Teams. • 1995. Humphrey. PSP. MA. Teamwork and Software Process.2010". ACM (Association for Computing Machinery). ^ a b "National Medal of Technology Winner Watts Humphrey. 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. AddisonWesley." 3. Reading. Software Engineering Institute. • 2006. Citation: For contributions to software engineering process discipline. Addison-Wesley. Reading. Reading.Innovation. • 1999. References 1. and served as director of that program from 1986 until the early 1990s. MA. Software Engineering Institute. 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). TSP. thereafter. Reading. ^ National Medal of Technology Press Release 2003 . including • 2011. MA. 2. Addison-Wesley. MA. Winning with Software: An Executive Strategy. A Discipline for Software Engineering. lies the best opportunity for significant improvement. Carnegie Mellon University. TSP. AddisonWesley. "Watts S. The program resulted in the development of the Capability Maturity Model."[6] See also • Personal Software Process (PSP) • Software quality • Team Software Process (TSP) Publications Humphrey is the author of several books. Retrieved 28 October 2010. • 2001. MA. • 1997. Leading a Development Team.Work Software Engineering Institute In the 1980s at the Software Engineering Institute (SEI) at Carnegie Mellon University Humphrey founded the Software Process Program. Reading. A Self-Improvement Process for Software Engineers. Addison-Wesley. Leadership. Retrieved 2009-0326. Your Teams. • 2006. • 2005. Reading. Addison-Wesley. MA. ^ "ACM Fellows (2008)". Introduction to the Team Software Process. Reading. Reading. Addison-Wesley. Addison-Wesley. Your Boss. • 2010. MA. and Yourself. MA. Teamwork. Reading. Managing Technical People . 1927 . Reflections on Management: How to Manage Your Software Projects. and Trust: Building a Competitive Software Capability. His personal goal in these developments remained to "improve quality and productivity in software development and to ease what was called the 'Software Crisis'.

^ "Interview with Watts Humphrey. Retrieved 2012-01-30.pdf http://en.swqual. 6. the free encyclopedia Jump to: navigation.org/wiki/Software_development_methodology Software development methodology From Wikipedia.org/presentations/2010-11/Watts-Tribute-Dec-2010. Humphrey at www.com/images/FoodforThought_Dec2010. (Discuss) Proposed since July 2012. ^ Staff Page for Watts S. Part 9".sei. 5.cmu.pdf sqgne. 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 • • • • • • • • .edu.4. www. search It has been suggested that Software development process be merged into this article or section. ^ [1].wikipedia.

• • • • • • • • 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. .

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.Contents • 1 History • 1.4 Integrated development environment • 3.2 Business process and data modelling • 3.2 As a verb • 2 Verb approaches • 2.5 Modeling language • 3.6 Other practices • 3 Subtopics • 3. and control the process of developing an information system . a software development methodology is a framework that is used to structure.1 View model • 3.[1] As a noun As a noun. plan. Information systems activities revolved around heavy data processing and number crunching routines".4 Spiral development • 2. structured and methodical way.2 Prototyping • 2. The main idea of the SDLC has been "to pursue the development of information systems in a very deliberate. According to Elliott (2004) the systems development life cycle (SDLC) can be considered to be the oldest formalized methodology framework for building information systems.[2] .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.6 Programming paradigm • 3.3 Computer-aided software engineering • 3.5 Rapid application development • 2. requiring each stage of the life cycle from inception of the idea to delivery of the final system.7 Software framework • 3.1 As a noun • 1.1 Waterfall development • 2. 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.3 Incremental development • 2. to be carried out rigidly and sequentially"[1] within the context of the framework being applied.

A wide variety of such frameworks have evolved over the years. supports the use. the software development methodology is an approach used by organizations and project teams to apply the software development methodology framework (noun). each with its own recognized strengths and weaknesses. Specific software development methodology frameworks (noun) include: • Rational Unified Process (RUP. IBM) since 1998. The methodology framework is often defined in some kind of formal documentation. the first English translation was published in 1974. One software development methodology framework is not necessarily suitable for use by all projects. originally from PANDATA.The three basic approaches applied to software development methodology frameworks. SDM stands for System Development Methodology .[2] These software development frameworks are often bound to some kind of organization. and promotes the methodology framework. which further develops. project and team considerations. Each of the available methodology frameworks are best suited to specific kinds of projects. • Agile Unified Process (AUP) since 2005 by Scott Ambler As a verb As a verb. based on various technical. organizational. Specific software development methodologies (verb) include: 1970s • Structured programming since 1969 • Cap Gemini SDM.

time schedules. over time and . It has been widely blamed for several large-scale government projects running over budget. target dates. since 1999 Verb approaches Every software development methodology approach acts as a basis for applying specific frameworks to develop and maintain software. since 1991 • Dynamic systems development method (DSDM). Several software development approaches have been used since the origin of information technology. and maintenance. and approval/signoff by the user and information technology management occurring at the end of most phases before beginning the next phase. The first formal description of the method is often cited as an article published by Winston W. The Waterfall model is a traditional engineering approach applied to software engineering. budgets and implementation of an entire system at one time. testing (validation). since 1995 • Team software process.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. Royce[3] in 1970 although Royce did not use the term "waterfall" in this article. • Emphasis is on planning. 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. and became a dominant programming approach during the mid-1990s • Rapid application development (RAD). The basic principles are:[2] • Project is divided into sequential phases. integration. since 1994 • Scrum. in which development is seen as flowing steadily downwards (like a waterfall) through the phases of requirements analysis. implementation. formal reviews. since 1998 • Extreme programming. design. with some overlap and splashback acceptable between phases. • Tight control is maintained over the life of the project via extensive written documentation.

• Attempts to reduce inherent project risk by breaking a project into smaller segments and providing more ease-of-change during the development process. requirements analysis.sometimes failing to deliver on requirements due to the Big Design Up Front approach. more traditional development methodology (i. 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. where all phases of the Waterfall are completed for a small part of a system. • While most prototypes are developed with the expectation that they will be discarded. i. incomplete versions of the software program being developed. • Small-scale mock-ups of the system are developed following an iterative modification process until the prototype evolves to meet the users’ requirements. before proceeding to the next increment. or rapid application development (RAD)). the Waterfall model has been largely superseded by more flexible and versatile methodologies developed specifically for software development. or • Overall requirements are defined before proceeding to evolutionary. Prototyping Software prototyping. incremental. which increases the likelihood of user acceptance of the final implementation.e. Except when contractually required. • User is involved throughout the development process. a working system. is the development approach of activities during software development. followed by iterative Prototyping. or • The initial software concept. Incremental development Various methods are acceptable for combining linear and iterative systems development methodologies.. mini-Waterfall development of individual increments of a system. it is possible in some cases to evolve from prototype to working system. and design of architecture and system core are defined via Waterfall. the creation of prototypes. which culminates in installing the final prototype. but rather an approach to handle selected parts of a larger. • A basic understanding of the fundamental business problem is necessary to avoid solving the wrong problem. The basic principles are:[2] • Not a standalone. . See Criticism of Waterfall model.e. The basic principles are:[2] • A series of mini-Waterfalls are performed. spiral. complete development methodology.

The basic principles are:[2] • Key objective is for fast development and delivery of a high quality system at a relatively low investment cost. • "Each cycle involves a progression through the same sequence of steps. alternatives. The spiral model is a software development process combining elements of both design and prototyping-in-stages. and constraints of the iteration.[5] • Begin each cycle with an identification of stakeholders and their win conditions. and end each cycle with review and commitment. It is a meta-model. Computer Aided Software Engineering . and computerized development tools. 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. and (4) plan the next iteration."[4] • Each trip around the spiral traverses four basic quadrants: (1) determine objectives. active user involvement. These tools may include Graphical User Interface (GUI) builders. as well as providing the opportunity to evaluate risks and weigh consideration of project continuation throughout the life cycle. (2) evaluate alternatives. Rapid application development is a term originally used to describe a software development process introduced by James Martin in 1991. Identify and resolve risks. • Aims to produce high quality systems quickly. for each part of the product and for each of its levels of elaboration. primarily via iterative Prototyping (at any stage of development). (3) develop and verify deliverables from the iteration. • Attempts to reduce inherent project risk by breaking a project into smaller segments and providing more ease-of-change during the development process. which involves iterative development and the construction of prototypes. from an overall concept-of-operation document down to the coding of each individual program. a model that can be used by other models. in an effort to combine advantages of top-down and bottom-up concepts.Spiral development The spiral model.[6] Rapid application development Rapid application development (RAD) is a software development methodology.

• Agile software development refers to a group of software development methodologies based on iterative development. UP organizes the development of software into four phases. Active user involvement is imperative. Produces documentation necessary to facilitate future development and maintenance. • Unified Process (UP) is an iterative software development methodology framework. interaction. Generally includes joint application design (JAD). not in increasing the deadline. If the project starts to slip. also known as object-oriented analysis and design (OOAD). The term was coined in the year 2001 when the Agile Manifesto was formulated. elaboration. state transition. and guidelines.• • • • • • • (CASE) tools. Other practices Other methodology practices include: • Object-oriented development methodologies. Many tools and products exist to facilitate UP implementation. emphasis is on reducing requirements to fit the timebox. or electronically facilitated interaction. and object-oriented techniques. Project control involves prioritizing development and defining delivery deadlines or “timeboxes”. and process. based on Unified Modeling Language (UML). Standard systems analysis and design methods can be fitted into this framework. while technological or engineering excellence is of lesser importance. One of the more popular versions of UP is the Rational Unified Process (RUP). code generators. as opposed to a throwaway prototype.[7] • Top-down programming: evolved in the 1970s by IBM researcher Harlan Mills (and Niklaus Wirth) in developed structured programming. object. Key emphasis is on fulfilling the business need. such as Grady Booch's object-oriented design (OOD). where requirements and solutions evolve via collaboration between selforganizing cross-functional teams. Database Management Systems (DBMS). module. each consisting of one or more executable iterations of the software at that stage of development: inception. The Booch model includes six diagrams: class. fourth-generation programming languages. . where users are intensely involved in system design. via consensus building in either structured workshops. Iteratively produces production software. construction.

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

referred to as business analysis. a foundation is created to visualize. a model is created after conducting an interview.[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. By depicting activities and information flows. The interview consists of a facilitator asking a series of questions designed to extract required information that describes a process. 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. 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. understand. The interviewer is called a facilitator to emphasize that it is the participants who provide the information. or a collection of ideas of what the process should contain. in which case the final product is called the "as-is" snapshot model. and .[9] Usually. The facilitator should have some knowledge of the process of interest. The creation of business models is more than a way to view or automate your information process.[9] The models are developed as defining either the current state of the process.[9] • A business model illustrates the functions associated with the business process being modeled and the organizations that perform these functions. defect-free. Analysis can be used to fundamentally reshape the way your business or organization conducts its operations. define.example of the interaction between business process and data models. • A data model provides the details of information to be stored. and validate the nature of a process. or if re-engineering is required as a corrective action. but this is not as important as having a structured methodology by which the questions are asked of the process expert. See the figure on the right for an example of the interaction between business process and data models. resulting in a "what-can-be" model. 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.

build automation tools. so as to provide a feature set which most closely matches the programming paradigms of the language. model transformation. documenting. source code generation. and programming. CASE tools automate methods for designing.[12] Two key ideas of Computer-aided Software System Engineering (CASE) are:[13] • Foster computer assistance in software development and or software maintenance processes. 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. and Unified Modeling Language. An IDE normally consists of a: • • • • source code editor. The CASE functions include analysis. i. Typically an IDE is dedicated to a specific programming language.e.[11] The term "computer-aided software engineering" (CASE) can refer to the software used for the automated development of systems software. design.. data modeling.[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. IDEs are designed to maximize programmer productivity by providing tight-knit components with similar user interfaces. computer code. Typical CASE tools exist for configuration management. and producing structured computer code in the desired programming language. refactoring. compiler and/or interpreter. Integrated development environment Anjuta. and • An engineering approach to software development and or maintenance. . and debugger (usually).maintainable software products.

0.. executable modeling languages are intended to amplify the productivity of skilled programmers. data flows. and the XML form BPML) is an example of a process modeling language. Textual modeling languages typically use standardised keywords accompanied by parameters to make computer-interpretable expressions. or contain elements of both paradigms. A modeling language can be graphical or textual. such as parallel computing and distributed systems. Paradigms differ in the concepts and abstractions used to represent the elements of a program (such as objects. C++.. On the contrary. and for those that are. and IDEF5 for modeling ontologies. constraints. • Flowchart is a schematic representation of an algorithm or a stepwise process. • IDEF is a family of modeling languages. variables. • Extended Enterprise Modeling Language (EEML) is commonly used for business process modeling across layers. IDEF1X for information modeling. For example programs written in C++ or Object Pascal can be purely procedural.[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. • Fundamental Modeling Concepts (FMC) modeling language for software-intensive systems. while in functional programming a program can be thought of as a sequence of stateless .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. Programming paradigm A programming paradigm is a fundamental style of computer programming. the most notable of which include IDEF0 for functional modeling. A programming language can support multiple paradigms. functions. programmers can think of a program as a collection of interacting objects. in contrast to a software engineering methodology. • EXPRESS and EXPRESS-G (ISO 10303-11) is an international standard general-purpose data modeling language. Example of graphical modelling languages in the field of software engineering are: • Business Process Modeling Notation (BPMN. • LePUS3 is an object-oriented visual Design Description Language and a formal specification language that is suitable primarily for modelling large object-oriented (Java. Software designers and programmers decide how to use those paradigm elements. so that they can address more difficult problems. UML 2. and has widespread tool support. using them doesn't necessarily mean that programmers are no longer needed..). continuations. evaluation. In object-oriented programming. Not all modeling languages are executable. The rules are used for interpretation of the meaning of components in the structure. C#) programs and design patterns. • Unified Modeling Language (UML) is a general-purpose modeling language that is an industry standard for specifying software-intensive systems.) and the steps that compose a computation (assignation.. supports thirteen different diagram techniques. • Specification and Description Language(SDL) is a specification language targeted at the unambiguous specification and description of the behaviour of reactive and distributed systems. which is a style of solving specific software engineering problems. the current version. or purely object-oriented.

Common Lisp. processoriented programming allows programmers to think about applications as sets of concurrent processes acting upon logically shared data structures. or other software to help develop and glue together the different components of a software project. which in the U. Scheme.function evaluations. Without project management. Many of them are in the defense industry. A decades-long goal has been to find repeatable. different programming languages advocate different programming paradigms. effective project management appears to be lacking. Synonyms include software life cycle and software process. A software framework may include support programs. or simply to understand its behavior. Ruby. Visual Basic. Python. With large numbers of software projects not meeting their expectations in terms of functionality. or delivery schedule. Some languages are designed to support one paradigm (Smalltalk supports object-oriented programming. Haskell supports functional programming). Some try to systematize or formalize the seemingly unruly task of writing software. The international standard describing the method to select. There are several models for such processes.S. software projects can easily be delivered late or over budget. and Oz). Various parts of the framework may be exposed via an API. Others apply project management methods to writing software. For instance. cost. Partly for this reason.[citation needed] Avoiding certain methods can make it easier to prove theorems about a program's correctness. Just as different groups in software engineering advocate different methodologies. C#. code libraries. new paradigms are often regarded as doctrinaire or overly rigid by those accustomed to earlier styles. Many programming paradigms are as well known for what methods they forbid as for what they enable. Software framework A software framework is a re-usable design for a software system or subsystem. requires a rating based on 'process models' to obtain contracts. pure functional programming forbids using side-effects. When programming computers or systems with many processors. a scripting language. structured programming forbids using goto statements. while other programming languages support multiple paradigms (such as Object Pascal. each describing approaches to a variety of [[software developm implement process methodologies. predictable processes that improve productivity and quality. implement and monitor the life cycle for software is ISO/IEC 12207. See also Lists • List of software engineering topics • List of software development philosophies Related topics • Domain-specific modeling . Software development process A software development process is a framework imposed on the development of a software product. C++.

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

[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 .

A. Jackson Ivar Jacobson James Martin Bertrand Meyer David Parnas Winston W. Hoare Watts Humphrey Michael A.• • • • • • • • • • • • • • • • • 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. R. Royce James Rumbaugh .

4 Nov 2010 4. In this. which I will. I will describe them from an historical perspective. of course. as one way to understand where we are and where we are going is to know where we have been.77 (11 votes) Introduction Software methodologies are concerned with the process of creating software . I will introduce the different types of methodologies.codeproject. 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.com/Articles/124732/Software-Development-Methodologies Software Development Methodologies By Andrew Phillips. the first of two articles. There will also be a subsequent companion article looking at the current state of the art and what I believe the future holds.• 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. . This second article is given the rather controversial title of "Why Creating Software is not Engineering".not so much the technical side but the organizational aspects. explain.

there is always the caveat that no analogy is perfect. You are to meet your friend Jim at the Station Hotel. Then you get stuck in traffic and also need to use the bathroom. Actually this whole article is one big analogy stretched almost to breaking point. 2. like taking a taxi to the pub. You clarify the situation but the taxi driver is uncommunicative and you end up at the wrong hotel. the first methodology was basically no methodology at all. Obviously he misheard you and after all many of his passengers go there. He suggests that you take the bus. 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". can clarify the ideas. The whole trip is much longer and more expensive than expected. Eventually. Of course. Ad-hoc Historically. Of course. Be careful to understand the similarities and the differences. I like them because many of the concepts in software development are abstract and hard to grasp. The taxi driver kindly informs you that your destination is quite distant and you do not have enough money. The above is the ideal case where the customer knows where they want to go and the developer knows how to get there. You are half way there when you realise you need to post a letter. Unfortunately the real world is never this simple. Consider these variations. You ask the taxi driver to take you to the Station Hotel to which the immediate reply is "Which one?". the bus is slow and does not go directly past the pub. We'll start with a simple scenario. You get there eventually. The driver suggests it might be the "Fire Station Hotel" which was actually not far from where you started. 5.Before beginning I should warn the reader of my penchant for analogy. Then Jim calls your mobile and says that he has gone to a different hotel. You have no idea where that is but you jump in a cab and tell the taxi driver where you want to go. you work out that the driver does not speak English well. If you are really persistent you might get to your destination but by then Jim has already left. At some point you give up. Problems 1. . The taxi takes you straight to the hotel but it's closed for business. 4. You try them all but can't find Jim. 3. You tell the driver where to go but you end up at the train station not the Station Hotel. This is generally called the "ad hoc" methodology. but using a familiar real-world situation. Apparently. there are three within a ten mile radius and you don't know which one Jim went to.

The analyst works out by deduction and/or educated guesswork exactly which "Station Hotel" you want. To ensure that the driver understands the instructions the essential parts are even translated into his native language.6. They also find out the exact address and the opening hours. of course. For a large project you will need a "project . for a fee.eg proceed 2 miles to the roundabout. 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. namely miscommunication (1). changing requirements (5) and inexperienced developers (6). Summary The ad-hoc methodology can work provided you have a simple problem. 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. A good designer might also try to anticipate problems and have contingency plans . However. It's been some time and you still haven't gone anywhere. 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. a customer who doesn't know exactly what they want (2) or thinks they do until they try it (4). most of the time you get there late or not at all. Can you see a problem with this approach? While the analyst/designer is busy at work you (the customer) are getting a bit nervous. I leave it the reader to work out what scenario 3 means. you want to avoid all the above problems. take the 3rd exit.eg. The above scenarios represent several common problems seen in software development. 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. 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. I'm sure you can think of many more things that can go wrong. 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. if the freeway has heavy traffic to take an alternative route. Waterfall OK. etc. Several times he has to backtrack but eventually finds the destination though the trip takes much longer than expected. 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. 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 . 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. Perhaps they even manage to contact Jim to confirm the location.

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

. A major problem is that without hard deliverable milestones most developers will procrastinate at the start (10).) Summary The waterfall model can work if everything goes to plan. The crux of the problem is the reliance on getting the specification perfect before attempting to implement it. 12. The designer knows that the taxi driver has a tendency to deviate from his specification. To the developer there is no point in working hard at the start when in all likelihood the effort will be wasted. The designer knows from past experience that taxi drivers vary widely in ability. even though this demeans the average taxi driver. Prototype The prototype methodology addresses the major problem of the waterfall methodology's "specification". However.11. (Unfortunately this completely invalidates the specification which is discarded. 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. or take a shortcut that may save time but has many risks involved. Obviously. 7). the designer will try to limit the information provided to the driver to only what they need to know. This can be at the behest of his passenger (see 7 above). It is difficult or impossible to prove that the specification is correct so we instead create a simple working example of the product. To counter this. even if you get close to getting it right at the start things will change. 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. You manage to contact Jim and arrange to meet him at a nearby hotel which is actually more convenient for both of you. You start the journey but there are a lot of problems and delays. 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. or simply take a diversion out of some personal interest. 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. which is that you are never sure it will work until you arrive at your destination. 6. For most realworld projects this means this approach is doomed to failure. but in a complex project things rarely do. 11. The specification is written to the lowest common denominator. or at best a late and over-budget project and a very frustrating experience. 12). or he may take the scenic route to make the trip more pleasant (and increase the fare). 13) and does not make best use of the developers (9. 13. Unfortunately. 8. much like an architect would create a scale model of a proposed new building. To continue our taxi analogy the designer. When the motorbike driver has found a good way the actual taxi trip can begin. 5. 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. The process does not cope with change (4.

3. Problems 1. enter the destination. Unfortunately.) 3. 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). Moreover. These so-called "4th generation languages" were supposedly easy enough for anyone to use. The problem with this is the motorbike trip may be far less pleasant. 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. and you get an obscure error message. 2.Problems 1. The idea. You need to go by a long and circuitous route even though your destination is not that far away. Of course. most people can't drive taxis (in the analogy) so we need a simple system where the user just has simplified controls. Different routes can be quickly explored and the best decided on. To you (the customer) it seems that creating a prototype is a waste of time. . if the best route is obvious and well travelled then creating a prototype is unnecessary. 4GL This is not so much a methodology as an approach that tries to use new technology. In the end completing the project may not be made that much easier by having a prototype. 2. is that very high level languages could be developed to allow users to create their own applications. However. the motorbike is not designed to take a passenger and can become unstable with you and your luggage causing an accident. You get in the taxi. 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. You go nowhere. 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. 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). It can bypass traffic snarls or pass through narrow lanes that a car cannot. A motorbike is not a car. pushed heavily in the 1980's. the only way this was possible is to create a huge network of guidance rails to keep the taxis on track. The cost of the rail network is enormous so it doesn't go to very many destinations yet. In our analogy this is like getting rid of the taxi driver altogether. 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.

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. Iterative The precursor to today's agile methodologies (see below) can be loosely grouped as "iterative". On the surface this looks very much like the "ad hoc" methodology in that you just jump in the taxi and go. 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. looks for trouble spots and try to find the best way to the destination.Summary The idea is good but in general it is not workable. It also does not preclude the use of extra team members to ensure the trip is smooth and trouble free. Agile The main problem with the waterfall approach is that it takes a lot of effort up front effort in planning. with advances in AI. by continually reassessing we can adapt to any unforeseen and new developments. and even exacerbated some. 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. there is still a lot of up front effort to design and build the prototype even before we even start the real development. . When it comes to the actual implementation there are so many variables and unknowns that it is very unlikely to go to plan. Perhaps one day. But there are still pitfalls to watch out for. analysis and design. In practice the product is slow and cumbersome (3) and gives generally unsatisfactory results compared to other methods (2). A mechanic could ensure that the taxi is always in good condition and will not break down. As such they had many of the same problems. 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. They are also often described as "cascade" methods as they are really just a series of small waterfalls. When we come to a point where there is uncertainty we stop to assess the position and choose the best path. The above problems mean: the technology is not good enough (1) and expensive to develop (2). this approach can work. The prototype approach meant we could eliminate some of this uncertainty by demonstrating that there is a reasonable chance of success. A navigator could monitors traffic conditions. However. Further.

even if he is late. At every turn you (the passenger) check the roadmap and make suggestions or even tell the driver he is going the wrong way. For a simple.Problems 1. The customer is highly involved in the development and releases are not every few weeks but daily or even more often.Jim rings to say he has gone in the opposite direction. However. One problem is a customer representative who does not really know what is best for the "real" customer (1). 2. You (the passenger) are sure you know where you want to go. In many ways it is like the agile methodology taken to the extreme. 3. hence I have called this methodology "totalitarian". There is a lot already invested in the trip so there is a reluctance to just abandon it and start again . Jim is not there but at another hotel. Problems 1. 2.after all that is the "waterfall" way of doing things. The taxi driver has to stop and check to make sure but mainly to reassure the passenger. An alternative name might be "back seat driver". via the north or south side of the mountain.right over the top of the mountain. the driver wants to go one way and the navigator the other. The direct route is straight down the hill and over the old bridge. well understood project "ad hoc" may still be better (3). 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. there are still potential problems to watch out for. There are two equally good ways to the destination. 4. at every stage he knows where he is and still has a good idea when he will get there. the trip proceeds smoothly but when you get there you find that nobody else thinks it is the right place. Totalitarian Finally. I introduce a class of methodology that I have experienced but never seen described. This typically occurs when the customer is a former taxi driver and wants complete control of the product and the process. Agile methods are evolutionary but sometimes you can't evolve the existing software into what is really required (2). A much slower path is taken to mitigate the risks and so the customer always has the destination in sight. As a compromise they choose the worst possible way . However. Finally group decisions may not always be the best decisions (4). The trip is proceeding smoothly but when you are halfway there things change completely . The customer is happy because he knows the driver is not lost and. With the constant barrage of instructions the driver becomes confused and even forgets where he is . The quickest way would have been the direct route but was not seen as the "right" way to do it.

First. You end up at the end of a dead-end one-way street. I should also mention that there are things that can go wrong that are beyond the bounds of any development methodology . 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.going. 3. Further. like the waterfall approach it disempowers the developers (2. License This article. I hope this article has given you insight into the different software development methodologies. The roads may be unmapped and always changing. The immediate direction is constantly changing. Testing the same thing many times becomes tedious and eventually the customer becomes less diligent and bugs get past them. with consequent effects on their quality of work and hence productivity. is licensed under The Code Project Open License (CPOL) . In my next article I will look at the state of the art. in particular some agile methodologies. Developers need time to do their own testing and integrate input from different team members. by tracking down nonproblems that would eventually "come out in the wash". I will also emphasize what areas I believe are important and what the future may hold. Conclusion Unfortunately when developing software there are many more variables and unknowns than in a simple taxi trip. 2). the customer needs to do a lot of testing to provide daily feedback. The driver stops thinking about where he is going and just follows your direction. who knows? There are car accidents and break downs. For this reason producing a new "release" should not be attempted more often than weekly.it can move or even dispappear or there can be a myriad of hotels all seemingly the same. Using this approach you can waste time chasing your own tail. 3). In this strange world the Station Hotel may not be stationary hotel .the Station Hotel may explode. Summary This approach has no advantage over the agile and has many disadvantages. along with any associated source code and files.

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

(June 2012) Capability Maturity Model Integration (CMMI) is a process improvement approach. Processes are rated according to their maturity levels. Currently supported is CMMI Version 1.It has been suggested that this article or section be merged into Capability Maturity Model.2 CMMI model framework • 3. Patent and Trademark Office by Carnegie Mellon University.S. which are defined as: Initial. Managed.3 Maturity levels in CMMI for development • 3.7 Appraisal • 3.3. Contents • 1 Overview • 2 History • 3 CMMI topics • 3. or is otherwise written in an overly promotional tone. This article reads like a news release. a division. When appropriate.5 Maturity levels in CMMI for acquisition • 3. CMMI is registered in the U. Quantitatively Managed. Defined. blatant advertising may be marked for speedy deletion with {{db-spam}}. Please help by either rewriting this article from a neutral point of view or by moving this article to Wikinews. (Discuss) Proposed since June 2012.8 Achieving CMMI compliance • 4 Applications • 5 See also • 6 References • 7 Official sources • 8 External links .1 CMMI representation • 3. or an entire organization.4 Maturity levels in CMMI for services • 3.6 CMMI models • 3. Optimizing. CMMI can be used to guide process improvement across a project.

2. provide guidance for . In 2002. The main sponsors included the Office of the Secretary of Defense (OSD) and the National Defense Industrial Association. the Software CMM (CMM.3 in November 2010. CMMI models provide guidance for developing or improving processes that meet the business goals of an organization. government and the Carnegie Mellon Software Engineering Institute (SEI). see below). A CMMI model may also be used as a framework for appraising the process maturity of the organization. set process improvement goals and priorities. Service establishment. The project consisted of members of industry. and the acquisition of products and services. CMMI is the successor of the capability maturity model (CMM) or Software CMM. government. and CMMI Version 1. History CMMI was developed by the CMMI project. Product and service development — CMMI for Development (CMMI-DEV). 2008). — CMMI for Services (CMMI-SVC). and the Software Engineering Institute (SEI) at Carnegie Mellon University. The CMM was developed from 1987 until 1997.[1] CMMI currently addresses three areas of interest: 1. and 3.[1] CMMI originated in software engineering but has been highly generalised over the years to embrace other areas of interest. CMMI Version 1. Version 1. It is not as specific to software engineering as its predecessor.3 [2] are the support of Agile Software Development.1 was released. CMMI was developed by a group of experts from industry. Some of the major changes in CMMI V1. which aimed to improve the usability of maturity models by integrating many different models into one framework. the delivery of all kinds of services. The word "software" does not appear in definitions of CMMI. CMMI helps "integrate traditionally separate organizational functions.2 followed in August 2006. management. such as the development of hardware products.[5] According to the Software Engineering Institute (SEI.Overview Characteristics of the Maturity levels.[3] improvements to high maturity practices [4] and alignment of the representation (staged and continuous). This generalization of improvement concepts makes CMMI extremely abstract. Product and service acquisition — CMMI for Acquisition (CMMI-ACQ).

This collection of sixteen process areas is called the CMMI core process areas. The staged representation also provides for an easy migration from the SW-CMM to CMMI. The staged representation is designed to provide a standard sequence of improvements.quality processes. The table below lists the process areas that are present in all CMMI areas of interest in CMMI Version 1. or those to which the organization assigns a high degree of risks. see Process area (CMMI). the process areas it contains will vary."[6] CMMI topics CMMI representation CMMI exists in two representations:. development) used. maturity level ratings are awarded for levels 2 through 5. However.[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. services. and can serve as a basis for comparing the maturity of different projects and organizations. and provide a point of reference for appraising current processes. Depending on the CMMI areas of interest (acquisition. The .[7] Process areas are the areas that will be covered by the organization's processes. 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.continuous and staged.[1] CMMI model framework For more details on this topic.3.

Organizational Process Focus OT .Project Monitoring and Control PP .Measurement and Analysis PPQA .Configuration Management MA .Verification Maturity Level 3 .Process and Product Quality Assurance REQM .Causal Analysis and Resolution • OPM .Managed • • • • • • • • CM .Work Monitoring and Control WP .Integrated Project Management OPD .Requirements Management SAM .Quantitatively Managed • OPP .Decision Analysis and Resolution IPM .Project Planning PPQA .Supplier Agreement Management DAR .process areas below and their maturity levels are listed for the CMMI for Development model: Maturity Level 2 .Supplier Agreement Management SD .Requirements Development RSKM .Defined Maturity Level 4 .Requirements Management SAM .Validation VER .Organizational Training PI .Managed • • • • • • • • • • • • • • • • • • CM .Risk Management TS .Quantitative Project Management Maturity Level 5 .Technical Solution VAL .Configuration Management MA .Organizational Process Definition OPF .Optimizing • CAR .Service Delivery WMC .Organizational Process Performance • QPM .Work Planning .Measurement and Analysis PMC .Product Integration RD .Process and Product Quality Assurance REQM .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 .

Causal Analysis and Resolution • OPM .Defined • • • • • • • • • • • • CAM .Organizational Process Definition Maturity Level 3 .Organizational Training RSKM .Risk Management SCON .Process and Product Quality Assurance REQM .Organizational Process Performance • QWM .Acquisition Technical Management AVAL .Acquisition Validation AVER .Managed • • • • • • • • • • • • • • • AM .Requirements Management SSAD .Service System Development SST .Configuration Management MA .Service System Transition STSM .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 .Defined .Organizational Process Focus OT .Service Continuity SSD .Acquisition Requirements Development CM .Agreement Management ARD .Maturity Level 3 .Quantitative Work Management Maturity Level 5 .Quantitatively Managed • OPP .Acquisition Verification DAR .Project Planning PPQA .Strategic Service Management Maturity Level 4 .Organizational Process Definition OPF .Solicitation and Supplier Agreement Development ATM .Decision Analysis and Resolution IPM .Project Monitoring and Control PP .Measurement and Analysis PMC .Incident Resolution and Prevention IWM .Decision Analysis and Resolution IRP .Capacity and Availability Management DAR .Integrated Work Management OPD .Integrated Project Management OPD .Optimizing • CAR .

. Appraisals are typically conducted for one or more of the following reasons: 1. each of which addresses a different area of interest. Appraisal An organization cannot be certified in CMMI. 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. which focus on identifying improvement opportunities and comparing the organization’s processes to CMMI best practices. by a process group) to plan improvements for the organization. The Standard CMMI Appraisal Method for Process Improvement (SCAMPI) is an appraisal method .Quantitative Project Management Maturity Level 5 . The current release.g.• OPF . It addresses supply chain management. B and C.Organizational Performance Management CMMI models CMMI best practices are published in documents called models. • CMMI for Development (CMMI-DEV). v1. v1.Quantitatively Managed • OPP . and to identify areas where improvement can be made 2.Risk Management Maturity Level 4 .Optimizing • CAR . To inform external customers and suppliers of how well the organization’s processes compare to CMMI best practices 3. an organization is appraised. • CMMI for Services (CMMI-SVC). It addresses product and service development processes. and outsourcing processes in government and industry. A. instead. and services. the organization can be awarded a maturity level rating (1-5) or a capability level achievement profile. The appraisal results can then be used (e. acquisition. provides models for three areas of interest: development. acquisition.3 was released in November 2010.3. To determine how well the organization’s processes compare to CMMI best practices. Appraisal teams use a CMMI model and ARC-conformant appraisal method to guide their evaluation of the organization and their reporting of conclusions.3 was released in November 2010. • CMMI for Acquisition (CMMI-ACQ).Organizational Training • RSKM .Organizational Process Performance • QPM . v1.Organizational Process Focus • OT . There are three classes of appraisals. CMMI Version 1.3 was released in November 2010. class A appraisal is the most formal and is the only one that can result in a level rating.Causal Analysis and Resolution • OPM . Many organizations find value in measuring their progress by conducting an appraisal. Depending on the type of appraisal. It addresses guidance for delivering services within an organization and to external customers. Of these.

while 52. Of the small organizations (<25 employees). schedule. They suggest one should combine the different fragments of the methods into a new hybrid method. Examples are the CMMI Project Roadmap. CMMI Roadmaps. A new product called Accelerated Improvement Method (AIM) combines the use of CMMI and the TSP. and from Level 2 to Level 3 is an additional 20 months.[13] which are a goal-driven approach to selecting and deploying relevant process areas from the CMMI-DEV model. can significantly reduce the time to achieve compliance. More modern approaches that involve the deployment of commercially available. productivity. Anderson (2005) gives hints on how to interpret CMMI in an agile manner. These statistics have not been updated for the CMMI. since 1987. Sutherland et al. that an informal (SCAMPI C) appraisal be performed.8% of the organizations with 1001–2000 employees are rated at the highest level (5: Optimizing). A small company with few resources may be less likely to benefit from CMMI. Other viewpoints about using CMMI and Agile development are available on the SEI website. SCAMPI also supports the conduct of ISO/IEC 15504. Applications The SEI published that 60 organizations measured increases of performance in the categories of cost. each with a specific set of improvement goals. but that there are phases in a project where one of the two is better suited.[16] These roadmaps .[11] These statistics indicate that. However. can provide guidance and focus for effective CMMI adoption. CMMI-compliant processes. There are several CMMI roadmaps for the continuous representation.[14] CMMI Product and Product Integration Roadmaps [15] and the CMMI Process and Measurements Roadmaps. 70. These results do not guarantee that applying CMMI will increase performance in every organization.that meets all of the ARC requirements.5% are assessed at level 2: Managed. quality and customer satisfaction. this view is supported by the process maturity profile (page 10). The Software Engineering Institute’s (SEI) Team Software Process methodology and the use of CMMI models can be used to raise the maturity level. SEI has maintained statistics on the "time to move up" for organizations adopting the earlier Software CMM as well as CMMI. They believe neither way is the 'right' way to develop software. (2007) assert that a combination of Scrum and CMMI brings more adaptability and predictability than either one alone. Interestingly. the CMMI model mostly deals with what processes should be implemented. Turner & Jain (2002) argue that although it is obvious there are large differences between CMMI and agile methods.[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.[12] The median increase in performance varied between 14% (customer satisfaction) and 62% (productivity). and not so much with how they can be implemented. assessments etc. David J. both approaches have much in common. and that process areas be prioritized for improvement. the median times to move from Level 1 to Level 2 is 23 months. also known as SPICE (Software Process Improvement and Capability Determination). 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.

CMMI can be appraised using two different approaches: staged and continuous. a software engineering method. The continuous approach yields one of six capability levels. 2002). 9.3. 12. 13. 3.^ CMMI Process and Measurements Roadmaps 1. For example. 5. 4. See also • • • • • • • CMMI Version 1. NASA presentation.^ "CMMI Performance Results of CMMI". Extreme Programming (XP). ^ Major changes in CMMI Version 1. 6. which relies on oral communication.^ CMMI Project Roadmap 15. has been evaluated with CMM/CMMI (Nawrocki et al. The combination of the project management technique earned value management (EVM) with CMMI has been described (Solomon. Accessed 16 February 2011. 10. Retrieved 16 February 2011..^ "Process Maturity Profile".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 ?. 8.combine the strengths of both the staged and the continuous representations. 7.^ "Getting Started". 2. Version 1. was evaluated as not compliant with CMMI. the best practices are equivalent and result in equivalent process improvement results. The differences in these approaches are felt only in the appraisal.3 ^ CMMI V1.^ CMMI Roadmaps 14. ^ Overview of the CMMI Version 1.^ CMMI Product and Product Integration Roadmaps 16. the XP requirements management approach. Retrieved 2006-09-23. 11. Retrieved 23 September 2006. . The staged approach yields appraisal results as one of five maturity levels. Accessed 8 dec 2008.2: Method Definition Document".3 ^ CMMI Overview. ^ "Standard CMMI Appraisal Method for Process Improvement (SCAMPISM) A. 2006.3: Agile ^ CMMI V1. Software Engineering Institute. To conclude with a similar use of CMMI. High Maturity Practices Clarified ^ Deploying the CMMI V1. CMU/SEI-2006-HB-002. Retrieved 16 February 2011.3 Process Areas ^ For the latest published CMMI appraisal results see the SEI Web site. 2002). Software Engineering Institute.

2006. • "CMMI for Services. and entire organizations. Retrieved 23 August 2007. work groups.3" (pdf). which will improve their performance. Version 1.3. Retrieved 28 October 2006.2 (ARC. Retrieved 16 February 2011. V1.2)" (pdf). Retrieved 16 February 2011. Software Engineering Institute. CMMI for Development SCAMPI Class A Appraisal Results. CMMI applies to teams. Software Engineering Institute. November 2010). CMMI-ACQ (Version 1. 2011. Version 1. • CMMI Guidebook Acquirer Team (2007). Carnegie Mellon University Software Engineering Institute. • "Standard CMMI Appraisal Method for Process Improvement (SCAMPI) A Versiions 1. CMU/SEI-2007-TR-004. Software Engineering Institute. 2010. Retrieved 22 August 2006. Version 1.wikipedia.3. Retrieved 15 March 2011.3" (pdf). Version 1. • "SEI Partner List". Carnegie Mellon University Software Engineering Institute. http://en.Official sources SEI reports • "CMMI for Development. "Understanding and Leveraging a Supplier's CMMI Efforts: A Guidebook for Acquirers" (pdf). Retrieved 16 February 2011. divisions. Carnegie Mellon University Software Engineering Institute. Retrieved 16 February 2011. Find out why . 2010.cmu.sei. SEI Web pages • "CMMI Version 1. Carnegie Mellon University Software Engineering Institute. Software Engineering Institute. Carnegie Mellon University Software Engineering Institute. projects.3. Software Engineering Institute. Retrieved 16 February 2011. 2010.2: Method Definition Document" (doc). November 2010). • "CMMI for Acquisition. 2006.3" (pdf). CMMI-based process improvement includes identifying your organization’s process strengths and weaknesses and making process changes to turn weaknesses into strengths. Retrieved 16 February 2011. • SCAMPI Appraisal Results.edu/cmmi/ Overview CMMI (Capability Maturity Model Integration) is a process improvement approach that provides organizations with the essential elements of effective processes. • "Optimiza formal announcment as CMMI-L3 and published on SEI website.org/wiki/Capability_Maturity_Model_Integration http://www.3 Information Center". CMMI-SVC (Version 1. The complete SEI list of published SCAMPI appraisal results. • "Appraisal Requirements for CMMI.". November 2010). • "Process Maturity Profile (Current and Past Releases)" (PDF). CMMI-DEV (Version 1.

data collection. Tracking Mechanisms & Plans. risk management. where the teams put in extra hard work to achieve the results. Such companies do not have any structured Tracking Mechanisms & defined Standards. supplier management. efficiency. which do not have any structured Processes. CMMI is the result of over 20 years of ongoing work by the CMMI Product Team. Since the company has strong teams. disaster recovery. However these process are not standardized across the organization. CMM Level 2 . 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. see CMMI Solutions.Companies: Work is Performed Informally CMM – Level 1 companies are the ones. hence the product churned out by them is definitely a quality product.Companies: CMM – Level 0 companies are the ones. The software development work is performed informally but it is not properly documented. These products. To learn about CMMI and the People CMM. project management. It is left to the developer or any person responsible for Quality to ensure that the product meets the expectations. requirements management. Getting Started provides you with the steps to adopting CMMI. and appraisal methods used to evaluate implementations. These are primarily the startup companies. quality assurance. and the SEI. CMMI models are collections of best practices that help organizations to dramatically improve effectiveness. they won’t ask for many guidelines. or CMMI solutions. CMM Level 1 . training on their use. which includes members from industry.Companies: Work is Planned and Tracked CMM – Level 2 companies are the ones. The SEI ensures that the CMMI Product Suite continues to reflect effective practices. process performance. government.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. . capacity management. make. The published CMMI appraisal results (PARS) searchable database of appraisal results lists hundreds of organizations that use CMMI. Such companies usually have technically strong & more experienced people. http://www. and more. availability management.CMMI has been adopted by so many organizations worldwide. All the teams within the organization do not follow the same standard. buy. interface compatibility. visit CMMI Compatibility. consist of practices. CMM Level 0 . and quality. verification and validation. Practices cover topics that include causal analysis.softwaretestinggenius. To learn about other improvement technologies that are designed to complement CMMI and the People CMM. configuration management. 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. View the inclusive set of CMMI process areas to get a more complete picture of the topics it covers. or reuse analysis.

Companies: Work is Well-Defined CMM – Level 3 companies are the ones. such as a pie chart for management and a tabular view for accountants. the free encyclopedia Jump to: navigation. such as a chart or a diagram.Companies: Work is Quantitatively Controlled CMM – Level 4 companies are the ones. which are properly measured. Multiple views of the same data are possible. hence future performance can predicted. search Model–View–Controller (MVC) is an architecture that separates the representation of information from the user's interaction with it. Level – 5 organizations lay major emphasis on Research and development & are able to continuously improve their processes.[4] Contents • • • • • • 1 Component interactions 2 Use in web applications 3 History 4 See also 5 References 6 External links . well-defined guidelines.CMM Level 3 . Such companies have strong team.org/wiki/Model%E2%80%93view%E2%80%93controller Model–view–controller From Wikipedia. The central idea behind MVC is code reusability and separation of concerns. Goals to be achieved are well defined and the actual output is measured. In such companies. where the processes are well defined and are followed throughout the organization.[1][2] The model consists of application data and business rules. which have well defined processes.Companies: Work is based upon Continuous Improvement CMM – Level 5 companies are the ones. Focus on reusability & lay major focus on documentation. converting it to commands for the model or view. http://en. and the controller mediates input.[3] A view can be any output representation of data. where the processes are well defined and are followed throughout the organization.wikipedia. Such companies have proper mechanism to collect the Metrics to measure each and every work in the organization. Such organizations have good understanding of IT projects which have good effect on the Organizational goals. CMM Level 5 . CMM Level 4 .

[7] As client technologies have matured. and the controllers to change the available set of commands. In this approach.g. • A model notifies its associated views and controllers when there has been a change in its state. It can send commands to the model to update the model's state (e. by scrolling through a document). editing a document).g. This notification allows the views to produce updated output.Component interactions A typical collaboration of the MVC components In addition to dividing the application into three kinds of components. Several commercial and noncommercial application frameworks have been created to enforce the pattern. History The model-view-controller pattern was originally formulated in the late 1970s by Trygve Reenskaug at . the MVC design defines the interactions between them.. These frameworks vary in their interpretations. view and controller logic on the server. 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. Use in web applications Model View Controller has been adapted as an architecture for World Wide Web applications. because the application does not require them or the software platform does not support them.. mainly in the way that the MVC responsibilities are divided between the client and server. frameworks such as JavaScriptMVC and Backbone have been created that allow the MVC components to execute partly on the client (see also AJAX). A passive implementation of MVC omits these notifications.[5] • A controller can send commands to its associated view to change the view's presentation of the model (e. [6] • A view requests from the model the information that it needs to generate an output representation.[7] Early web MVC frameworks such as Java EE took a thin client approach that placed almost the entire model.

pp.March 20. "Web-Application Development Using the Model/View/Controller Design Pattern". and the visual feedback to the user are explicitly separated and handled by three types of object. James T. IEEE Enterprise Distributed Object Computing Conference. Vrije Universiteit Brussels. ^ a b Leff.. Ph.. The venerable model-view-controller". (2004).Trygve Reenskaug and Jim Coplien ." The DCI Architecture: A New Vision of Object-Oriented Programming ." Applications Programming in Smalltalk-80(TM):How to use Model-View-Controller (MVC) 3. 115–126. p. Matt A. and Design. 2009 2. Rayfield (September 2001). Avraham. ^ Simple Example of MVC (Model View Controller) Design Pattern for Abstraction 4. On the separation of user interface concerns: A Programmer's Perspective on the Modularisation of User Interface Code. as part of the Smalltalk system. 8. 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. Trygve Reenskaug did not release the concept behind the Model View Controller due to his NDA contract with xerox. However. Frank (1996) Pattern-Oriented Software Architecture 6. 15. "Chapter 11. ISBN 9781583484906. the user input. ^ Liu.Xerox PARC. 118-127.D. ISBN 9780672326110. Sams Publishing. 239. . The Object-Oriented Thought Process. 9. 10. ^ Buschmann. Sofie (2007–2008). iUniverse. pp. the framework exists to separate the representation of information from user interaction. Chamond (2000). ^ Best MVC Practices 5. ^ How to Use Model–View–Controller (MVC) 7. ^ "More deeply.^ Goderis. ^ ". Objects.[8][9][10] See also • • • • • • Model View ViewModel Model–view–adapter Model–view–presenter Observer pattern Presentation–abstraction–control Hierarchical_model–view–controller References 1. thesis. p. ^ Weisfeld. SmallTalk. the modeling of the external world.

You're Reading a Free Preview

/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->