Computing Curriculum - Software Engineering

Total Page:16

File Type:pdf, Size:1020Kb

Computing Curriculum - Software Engineering Computing Curriculum - Software Engineering --- Public Draft 1 --- (July 17, 2003) This is a draft document distributed for purposes of review by the public (those interested in the education of software engineers). At this point, the document is not complete or authoritative; it is subject to revision; and it does not necessarily represent the contents of the final document! The Joint Task Force on Computing Curricula IEEE Computer Society Association for Computing Machinery This material is based upon work supported by the National Science Foundation under Grant No. 0003263 CCSE Draft 1 – 7/17/03 Preface This document was developed through an effort originally commissioned by the ACM Education Board and the IEEE-Computer Society Educational Activities Board to create curriculum recommendations in several computing disciplines: computer science, computer engineering, software engineering and information systems. Other professional societies have joined in a number of the individual projects. Such has notably been the case for the CCSE (Computing Curricula – Software Engineering) project, which has included participation by representatives from the Australian Computer Society, the British Computer Society, and the Information Processing Society of Japan. Development Process The CCSE project has been driven by a Steering Committee appointed by the sponsoring societies. The development process began with the appointment of the Steering Committee co- chairs and a number of the other participants in the fall of 2001. More committee members, including representatives from the other societies were added in the first half of 2002. The following are the members of the CCSE Steering Committee: Co-Chairs Rich LeBlanc, ACM, Georgia Institute of Technology, U.S. Ann Sobel, IEEE-CS, Miami University, U.S. Knowledge Area Chair Ann Sobel, Miami University, U.S. Pedagogy Focus Group Co-Chairs Mordechai Ben-Menachem, Ben-Gurion University, Israel Timothy C. Lethbridge, University of Ottawa, Canada Co-Editors Jorge L. Díaz-Herrera, Rochester Institute of Technology, U.S. Thomas B. Hilburn, Embry-Riddle Aeronautical University, U.S. Organizational Representatives ACM: Andrew McGettrick, University of Strathclyde, U.K. ACM SIGSOFT: Joanne M. Atlee, University of Waterloo, Canada ACM Two-Year College Committee: Elizabeth Hawthorne, Union County College, U.S. Australian Computer Society: John Leaney, University of Technology Sydney, Australia British Computer Society: David Budgen, Keele University, U.K. Information Processing Society of Japan: Yoshihiro Matsumoto, Musashi Institute of Technology, Japan IEEE Computer Technical Committee on Software Engineering: Barrie Thompson, University of Sunderland, U.K. The construction of this volume has centered around two major efforts that have engaged a large number of volunteers, as well as all of the members of the Steering Committee. The first of these efforts was development of a set of desired curriculum outcomes and a statement of what every SE graduate should know. These ideas are captured in our statement of required Software Engineering Education Knowledge (SEEK), presented in Chapter 5 of this document. The second effort was the construction of a set of curriculum recommendations, describing how a software engineering curriculum incorporating the material from the SEEK can be structured in various contexts. These are presented in Chapter 6 of this document. CCSE Public Draft 1 – 7/17/03 2 Work began on SEEK in Spring 2002 with the involvement of nine groups of volunteers, leading to an NSF-supported workshop in June 2002 where representatives of the volunteer groups met with some Steering Committee members, resulting in the first “internal” draft of the SEEK. This draft was reviewed by all of the Steering Committee and a group of outside software engineering “experts”; revised by the Steering Committee based on comments from this reviews; and then published for public comment in August 2002. Comments from these public reviews were used to create a second draft by December 2002. Six “pedagogy focus groups” were created in November 2002 to begin the process of developing the curriculum recommendations. Each of these groups consisted of committee of volunteers plus one or two Steering Committee members. Input by these groups and further work by some members of the Steering Committee resulted in an initial curriculum draft in March 2003. This draft was discussed at a workshop at the Conference on Software Engineering Education and Training held that month in Madrid, Spain and with members of the Working Group on Software Engineering Education and Training at their meeting just before the conference. Feedback from these discussions was used to revise the draft in preparation for publishing it for public review in May 2003, along with a draft of the rest of this volume. The first public review of the draft was at the Summit on Software Engineering Education held at the International Conference of Software Engineering in Portland, Oregon, early in May 2003. Acknowledgements The development of this document was support by the National Science Foundation, the Association of Computing Machinery, and the IEEE Computer Society. Since its inception, many individuals have contributed to the CCSE project, some in more than one capacity. This work could not have been completed without the dedication and expertise of these volunteers. Appendix C lists the names of those that have participated in the various development and review stages of this document. Special thanks go to Susan Mengel of Texas Tech University who served as an original co-chair of the Steering Committee and performed the initial organization tasks for the CCSE project. CCSE Public Draft 1 – 7/17/03 3 Table of Contents Preface............................................................................................................................................2 Acknowledgements........................................................................................................................3 Chapter 1: Introduction ............................................................................................................6 1.1 Purpose of this volume..................................................................................................6 1.2 Where we fit in the CC picture......................................................................................6 1.3 Structure of the volume.................................................................................................7 Chapter 2: Guiding Principles..................................................................................................8 2.1 CCSE Principles............................................................................................................8 2.2 Student Outcomes .......................................................................................................10 Chapter 3: The Software Engineering Discipline ..................................................................11 3.1 The Discipline of Software Engineering.....................................................................11 3.2 An Engineering Discipline..........................................................................................12 3.3 Professional Practice...................................................................................................15 3.4 Prior Software Engineering Education and Computing Curriculum Efforts ..............16 3.5 SWEBOK and other BOK Efforts ..............................................................................17 3.6 Accreditation Development ........................................................................................18 Chapter 4: Overview of Software Engineering Education Knowledge .................................19 4.1 Process of Determining the SEEK ..............................................................................19 4.2 Knowledge Areas, Units, and Topics..........................................................................20 4.3 Core Material..............................................................................................................20 4.4 Unit of Time................................................................................................................21 4.5 Relationship of the SEEK to the Curriculum..............................................................21 4.6 Selection of Knowledge Areas....................................................................................22 4.7 SE Education Knowledge Areas .................................................................................22 4.8 Computing Essentials..................................................................................................23 4.9 Mathematical and Engineering Fundamentals ............................................................24 4.10 Professional Practice................................................................................................25 4.11 Software Modeling and Analysis.............................................................................26 4.12 Software Design.......................................................................................................28 4.13 Software Verification and Validation......................................................................29 4.14 Software Evolution..................................................................................................30 4.15 Software Process......................................................................................................31
Recommended publications
  • Revealing the Secrets of David Parnas
    Revealing the Secrets of David Parnas H. Conrad Cunningham Department of Computer and Information Science University of Mississippi March 7, 2014 Those of us in the fast-changing field of computing often dismiss anything writ- ten more than five years ago as obsolete. Yet several decades-old papers by David L. Parnas [1, 4, 5, 6, 7, 8] are as timely as those published in recent issues of the top journals. Parnas articulates the timeless software design concepts known as information hiding and abstract interfaces. Most programmers would describe a module as a unit of code such as a sub- routine or class. Parnas focuses on the programmers rather than the programs. He defines a module as \a work assignment given to a programmer or group of programmers" as a part of a larger software development project [7]. His goals are to enable programmers to develop each module independently, change one module without affecting other modules, and comprehend the overall system by examining one module at a time [5]. Programmers often design a software system by breaking the required pro- cessing into steps and making each step a module. Instead, Parnas uses in- formation hiding to decompose the system into modules that satisfy his goals (2); each module keeps its own secreta design decision about some aspect of the system (e.g., choice of a data structure). A modules design decision can change but none of the other modules should be affected. If some aspect is unlikely to change, the design can distribute this knowledge across several modules and the interfaces among them.
    [Show full text]
  • Download The
    LEADING THE FUTURE OF TECHNOLOGY 2016 ANNUAL REPORT TABLE OF CONTENTS 1 MESSAGE FROM THE IEEE PRESIDENT AND THE EXECUTIVE DIRECTOR 3 LEADING THE FUTURE OF TECHNOLOGY 5 GROWING GLOBAL AND INDUSTRY PARTNERSHIPS 11 ADVANCING TECHNOLOGY 17 INCREASING AWARENESS 23 AWARDING EXCELLENCE 29 EXPANSION AND OUTREACH 33 ELEVATING ENGAGEMENT 37 MESSAGE FROM THE TREASURER AND REPORT OF INDEPENDENT CERTIFIED PUBLIC ACCOUNTANTS 39 CONSOLIDATED FINANCIAL STATEMENTS Barry L. Shoop 2016 IEEE President and CEO IEEE Xplore® Digital Library to enable personalized importantly, we must be willing to rise again, learn experiences based on second-generation analytics. from our experiences, and advance. As our members drive ever-faster technological revolutions, each of us MESSAGE FROM As IEEE’s membership continues to grow must play a role in guaranteeing that our professional internationally, we have expanded our global presence society remains relevant, that it is as innovative as our THE IEEE PRESIDENT AND and engagement by opening offices in key geographic members are, and that it continues to evolve to meet locations around the world. In 2016, IEEE opened a the challenges of the ever-changing world around us. second office in China, due to growth in the country THE EXECUTIVE DIRECTOR and to better support engineers in Shenzhen, China’s From Big Data and Cloud Computing to Smart Grid, Silicon Valley. We expanded our office in Bangalore, Cybersecurity and our Brain Initiative, IEEE members India, and are preparing for the opening of a new IEEE are working across varied disciplines, pursuing Technology continues to be a transformative power We continue to make great strides in our efforts to office in Vienna, Austria.
    [Show full text]
  • 2008 Cse Course List 56
    It is CSE’s intention every year to make the Annual Report representative of the whole Department. With this ideal in mind, a design contest is held every year open to Graduate and Undergraduate students. This year’s winner was James Dickson, a junior CSE major who hails from Granville, Ohio. CONTENTS 2008 ACHIEVEMENT & HIGHLIGHTS 1 ANNUAL CSE DEPARTMENT AWARDS 11 INDUSTRIAL ADVISORY BOARD 12 RETIREMENT DOUBLE HIT 13 RESEARCH 14 GRANTS, AWARDS & GIFTS 19 COLLOQUIUM 27 STUDENTS 29 FaCULTY AND STAFF 38 SELECT FaCULTY PUBLICATIONS 49 2007 - 2008 CSE COURSE LIST 56 395 Dreese Labs 2015 Neil Avenue Columbus, Ohio 43210-1277 (614) 292-5813 WWW.CSE.OHIO-STATE.EDU i Mission Statement ± The Department of Computer Science and Engineering will impact the information age as a national leader in computing research and education. ± We will prepare computing graduates who are highly sought after, productive, and well-respected for their work, and who contribute to new developments in computing. ± We will give students in other disciplines an appropriate foundation in computing for their education, research, and experiences after graduation, consistent with computing’s increasingly fundamental role in society. ± In our areas of research focus, we will contribute key ideas to the development of the computing basis of the information age, advancing the state of the art for the benefit of society, the State of Ohio, and The Ohio State University. ± We will work with key academic partners within and outside of OSU, and with key industrial partners, in pursuit of our research and educational endeavors. ii GREETIN G S FROM THE CHAIR ’S OFFI C E Dear Colleges, Alumni, Friends, and Parents, As we reach the end of the 2007-2008 academic year, I am glad to introduce you a new annual report of the department.
    [Show full text]
  • Keeping Secrets Within a Family: Rediscovering Parnas
    Keeping Secrets within a Family: Rediscovering Parnas H. Conrad Cunningham Cuihua Zhang Yi Liu Computer Science Computer & Information Systems Computer Science University of Mississippi Northwest Vista College University of Mississippi University, MS, 38677 San Antonio, TX 78251 University, MS 38677 Abstract of related programs. The motivation for product lines and frameworks is to take advantage of the David Parnas wrote several papers in the 1970’s commonalities among the members of the product line and 1980’s that are now considered classics. The to lower the overall cost of producing and maintaining concepts he advocated such as information hiding and a group of related software systems. use of abstract interfaces are generally accepted as Since the foundation of software product lines and the appropriate way to design nontrivial software frameworks is what Parnas proposed in his papers, an systems. However, not all of what he proposed has examination of the concepts in these papers (collected been fully appreciated and assimilated into our in [5]) can still reveal much of value to current-day practices. Many of his simple, elegant ideas have software developers and researchers. Many of the been lost amongst the hype surrounding the lessons taught in these works should also be technologies and methods that have arisen in the past incorporated into our college-level teaching. two decades. This paper examines Parnas’s ideas, This paper examines several of the lessons on the especially his emphasis on program families, and design of program families taught by Parnas that are proposes that college-level computing science and still important for contemporary students to learn.
    [Show full text]
  • IEEE-SA Standards Board Meeting Minutes – December 2015
    Board Meeting Minutes – September 2011 IEEE-SA Standards Board Meeting Minutes – December 2015 IEEE-SA Standards Board Meeting Minutes 05 December 2015 IEEE Operations Center, Piscataway, New Jersey, USA Attendees Chair: John Kulick Vice Chair: Jon Rosdahl Past Chair: Rich Hulett Secretary: Konstantinos Karachalios Members: Masayuki Ariyoshi Ted Burse Stephen Dukes [TAB Rep.] Jean-Philippe Faure Travis Griffith Gary Hoffman Michael Janezic David Law Hung Ling Andrew Myles Ted Olsen Glenn Parsons Ron Petersen Annette Reilly Steve Shellhammer Adrian Stephens Yatin Trivedi Philip Winston Don Wright IEEE Standards Association | 445 Hoes Lane | Piscataway NJ 08854 USA Phone: +1 732 981 0060 | Fax: +1 732 562 1571 | standards.ieee.org IEEE-SA Standards Board Meeting Minutes – December 2015 Yu Yuan Daidi Zhong Thomas Koshy, NRC Liaison Jim Matthews, IEC Liaison Members Absent: Joe Koepfinger, Member Emeritus Dick DeBlasio, DOE Liaison IEEE Staff: Melissa Aranzamendez Kathryn Bennett Christina Boyce Matthew Ceglia Tom Compton Christian DeFelice Karen Evangelista Jonathan Goldberg Mary Ellen Hanntz Yvette Ho Sang Noelle Humenick Karen Kenney Michael Kipness Adam Newman Mary Lynne Nielsen Moira Patterson Walter Pienciak Dave Ringle, Recording Secretary Rudi Schubert Sam Sciacca Patrick Slaats Walter Sun Susan Tatiner Cherry Tom Lisa Weisser Meng Zhao IEEE Outside Legal Counsel: Claire Topp Guests: Chuck Adams Dennis Brophy Dave Djavaherian IEEE-SA Standards Board Meeting Minutes – December 2015 James Gilb Scott Gilfillan Daniel Hermele Bruce Kraemer Xiaohui Liu Kevin Lu John Messenger Gil Ohana Mehmet Ulema, ComSoc Liaison to the SASB Neil Vohra Walter Weigel Yingli Wen Phil Wennblom Howard Wolfman Helene Workman Paul Zeineddin 1 Call to Order Chair Kulick called the meeting to order at 9:00 a.m.
    [Show full text]
  • Stephan Goericke Editor the Future of Software Quality Assurance the Future of Software Quality Assurance Stephan Goericke Editor
    Stephan Goericke Editor The Future of Software Quality Assurance The Future of Software Quality Assurance Stephan Goericke Editor The Future of Software Quality Assurance Editor Stephan Goericke iSQI GmbH Potsdam Germany Translated from the Dutch Original book: ‘AGILE’, © 2018, Rini van Solingen & Manage- ment Impact – translation by tolingo GmbH, © 2019, Rini van Solingen ISBN 978-3-030-29508-0 ISBN 978-3-030-29509-7 (eBook) https://doi.org/10.1007/978-3-030-29509-7 This book is an open access publication. © The Editor(s) (if applicable) and the Author(s) 2020 Open Access This book is licensed under the terms of the Creative Commons Attribution 4.0 Inter- national License (http://creativecommons.org/licenses/by/4.0/), which permits use, sharing, adaptation, distribution and reproduction in any medium or format, as long as you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons licence and indicate if changes were made. The images or other third party material in this book are included in the book’s Creative Commons licence, unless indicated otherwise in a credit line to the material. If material is not included in the book’s Creative Commons licence and your intended use is not permitted by statutory regulation or exceeds the permitted use, you will need to obtain permission directly from the copyright holder. The use of general descriptive names, registered names, trademarks, service marks, etc. in this publication does not imply, even in the absence of a specific statement, that such names are exempt from the relevant protective laws and regulations and therefore free for general use.
    [Show full text]
  • IEEE Annual Report- 2017
    THE 2017 IEEE TABLE OF PRESIDENT’S COIN CONTENTS Initiated by 2016 President Barry Shoop, the IEEE President’s Coin 1 MESSAGE FROM THE IEEE PRESIDENT is given to individuals in recognition of their dedication to IEEE. For me, one of the most interesting aspects is the embodiment of the President’s unique design and story. 3 INSPIRING CHANGE. EMPOWERING PEOPLE. “Find Your Reason, Purpose and Passion” 5 GROWING GLOBAL AND INDUSTRY PARTNERSHIPS The front of my coin features a personal motto, inspired by my daughter - “Find Your Reason, Purpose and Passion,” along with the mission of IEEE. 9 GROWING AWARENESS OF IEEE The back highlights five areas of IEEE activities in the outer ring and different facets of IEEE in the center. 15 EXPANDING IEEE’S PRESENCE AROUND THE WORLD The Wi-Fi symbol denotes IEEE’s leadership in standards. 21 ADVANCING TECHNOLOGY FOR THE FUTURE The image next to that represents engineering in medicine and biology. The skyline signifies Smart Cities and IEEE’s global nature. 27 REWARDING EXCELLENCE The circuit diagram symbolizes our computer and electronic engineering disciplines. The plant is for 31 ENCOURAGING OUTREACH AND DRIVING RESEARCH IEEE’s power and energy fields and sustainability initiatives. The sine wave stands for our many communications domains. 35 ELEVATING ENGAGEMENT My favorite icon is the group of people with one individual who is a little different, showing IEEE 39 IEEE BOARD OF DIRECTORS AND MANAGEMENT COUNCIL members welcoming me as a female engineer. With each coin I presented, came the feeling of pride 41 MESSAGE FROM THE TREASURER AND REPORT and humbleness to serve our great institution.
    [Show full text]
  • Active IEEE Sister Society Agreements (Known As of 4-Feb-20)
    Active IEEE Sister Society Agreements (known as of 4-Feb-20) Discount IEEE Society Sister Society Agreement with Acronym Country Valid Until Membership Publication Price IEEE Communications CMAI - Communications Multimedia Applications Society Infrastructure - CMAI Association of India CMAI India 31-Dec-19 IEEE FRUCT - East-West Research and IEEE Education Communications Society on Telecommunications and Open Society Innovations Community FRUCT FRUCT Finland 31-Dec-19 IEEE Communications Society SCS - Singapore IEEE Computer Society SCS Singapore 31-Dec-20 IEEE Communications AEAI - Association of Engineers and Architects in Society Israel AEAI Israel 31-Dec-21 IEEE Communications Society CIC - China Institute of Communications CIC China 31-Dec-21 IEEE Communications Society HTE-Scientific Association for Infocommunications HTE Hungary 31-Dec-21 IEEE IEICE-IEEE Communications Society of the Institute Communications of Electronics,Information and Communication Society Engineers IEICE Japan 31-Dec-21 IEEE Communications IETE-Institute of Electronics and Society Telecommunications Engineers IETE india 31-Dec-21 IEEE AICA - Associazone Italiana Per L-Informatica ED IL Communications Calcolo Automatico Society AICA Italy 31-Dec-22 IEEE AICT-AEIT Society for Information & PER120-PRT $140.00 Communications Communications Technology PER141-PRT $140.00 Society AICT Italy 31-Dec-22 10% off ComSoc PER172-ELE $47.00 IEEE dues PER302-PRT $76.00 Communications CCIS - Communications and Information Society, PER317-PRT $98.00 Society Croatia CCIS Croatia
    [Show full text]
  • Message from Chairman
    Vol. 9 No. 5 August 2014 Message from Chairman Dear Members, As you are probably aware, the Region 10 has announced the 2013 Region 10 Distinguished Large Section, Medium Section and Small Section Awards. Bangalore Section is selected for the Distinguished Large Section Award, Pune Section for the Distinguished Medium Section Award and Northern Australia Section for the Distinguished Small Section Award. Each of these awards carries a cash bonus of USD1,000 along with an Award certificate. It is a great honor and pleasure that two of our Sections in India have won the Large Section and Medium Section awards. Let us record our appreciation and greetings to the Bangalore and Pune Sections for their achievement. As you know, there are a number of awards instituted by the IEEE R-10 and IEEE Head quarters. I wish that the IEEE Units in India should try to win as many awards as possible. It is definitely possible if we sincerely work to increase our activities and to improve our Membership strength. I am happy to place on record that the Second IEEE Region 10 Humanitarian Technology Conference 2014 was conducted successfully by the Madras Section during 6 -9 August 2014. I sincerely appreciate the Chair and his dedicated team of volunteers and convey my Heartiest Congratulations for their achievement. The IEEE Computer Society, Pune Section has proposed to organize “All India Computer Society Student Congress 2014” during 13th and 14th December, 2014. The IEEE Electron Device Society, Bangalore Chapter is organizing the 2nd ICEE-2014 from 4-6 December, 2014, at the Indian Institute of Science, Bangalore, with a pre-conference tutorials on Dec.
    [Show full text]
  • Systems Development Life Cycle
    Systems Development Life Cycle From Wikipedia, the free encyclopedia Jump to: navigation, search For other uses, see SDLC (disambiguation). Model of the Systems Development Life Cycle with the Maintenance bubble highlighted. The Systems Development Life Cycle (SDLC), or Software Development Life Cycle in systems engineering, information systems and software engineering, is the process of creating or altering systems, and the models and methodologies that people use to develop these systems. The concept generally refers to computer or information systems. In software engineering the SDLC concept underpins many kinds of software development methodologies. These methodologies form the framework for planning and controlling the creation of an information system[1]: the software development process. Contents y 1 Overview y 2 History y 3 Systems development phases o 3.1 Requirements gathering and analysis o 3.2 Design o 3.3 Build or coding o 3.4 Testing o 3.5 Operations and maintenance y 4 Systems development life cycle topics o 4.1 Management and control o 4.2 Work breakdown structured organization o 4.3 Baselines in the SDLC o 4.4 Complementary to SDLC y 5 Strengths and weaknesses y 6 See also y 7 References y 8 Further reading y 9 External links [edit] Overview Systems and Development Life Cycle (SDLC) is a process used by a systems analyst to develop an information system, including requirements, validation, training, and user (stakeholder) ownership. Any SDLC should result in a high quality system that meets or exceeds customer expectations, reaches completion within time and cost estimates, works effectively and efficiently in the current and planned Information Technology infrastructure, and is inexpensive to maintain and cost-effective to enhance.[2] Computer systems are complex and often (especially with the recent rise of Service-Oriented Architecture) link multiple traditional systems potentially supplied by different software vendors.
    [Show full text]
  • Inspection's Role in Software Quality Assurance
    focusguest editors’ introduction Inspection’s Role in Software Quality Assurance David L. Parnas, University of Limerick Mark Lawford, McMaster University espite more than 30 years’ effort to improve software quality, companies still release programs containing numerous errors. Many major products have thousands of bugs. It’s not for lack of D trying; all major software developers stress software quality as- surance and try to remove bugs before release. The problem is the code’s complexity. It’s easy to review code but fail to notice significant errors. Researchers have responded to these prob- lems by studying methods of formal correct- ness verification for programs. In theory, we now know how to prove programs correct with the same degree of rigor that we apply to mathematical theorems. In reality, this is rarely practical and even more rarely done. Most research papers on verification make simplifying assumptions (for example, a 1:1 correspondence between variables and vari- able names) that aren’t valid for real pro- grams. Proofs of realistic programs involve long, complex expressions and require pa- tience, time, and diligence that developers don’t think they have. (Interestingly enough, they never have time to verify a program be- fore release, but they must take time to re- spond to complaints after release.) Inspection methods can be more effective than informal reviews and require less effort than formal 16 IEEE SOFTWARE Published by the IEEE Computer Society 0740-7459/03/$17.00 © 2003 IEEE proofs, but their success depends on having a I The TSE papers do communicate the re- sound, systematic procedure.
    [Show full text]
  • Devops E Continuous Delivery Release-Automation Di Software Mediante Implementazione Di Una Pipeline
    POLITECNICO DI TORINO Corso di Laurea Magistrale in Ingegneria Informatica (Computer Engineering) Tesi di Laurea Magistrale DevOps e Continuous Delivery Release-Automation di software mediante implementazione di una pipeline Relatore Candidato prof. Marco Mezzalama Marco Punzi Supervisore aziendale Consoft Sistemi dott. Marco Casu Anno accademico 2017 – 2018 Ai complici della realizzazione di un sogno Abstract «L’avvento della Application Economy impone sempre più l’idea del soft- ware come strumento per generare direttamente valore di business. Occorre quindi garantire servizi di deployment rapidi e in alta affidabil- ità, che permettano il rilascio di software testato e di qualità in qualsi- asi istante. La Continuous Delivery quale estensione della Continuous Integration prevede un approccio strutturato ed automatizzato ai test funzionali, di non regressione e di integrazione, ottimizzando i processi ripetibili di Lifecycle e Deploy. Per assicurare soluzioni flessibili ed in- tegrabili all’interno dei processi aziendali, si necessita di un approccio metodologico di gestione del ciclo del software agendo sulla comunicazione e collaborazione tra gli sviluppatori e gli operatori IT.» (Consoft Sistemi SpA, DevOps Solution, 2017) iii Indice Abstract .................................... iii Introduzione Generale 1 1 Modelli e filosofie a confronto 5 1.1 Introduzione . 5 1.2 Nascita e decadenza del modello Waterfall ............... 6 1.2.1 Le fasi del modello . 6 1.2.2 Gli svantaggi del modello . 7 1.3 Lo sviluppo Agile ............................. 8 1.4 Software release: Anti-pattern e Soluzioni . 12 1.5 L’etica DevOps .............................. 13 1.6 DevOps: il valore di business . 16 1.6.1 Il Return of Investment del DevOps . 18 1.7 Conclusione .
    [Show full text]