1 / 24

Dennis J. Frailey May 28, 2009 DJFrailey@Raytheon 972-344-8366

Educating the Next Generation of Software & Systems Engineers. Dennis J. Frailey May 28, 2009 DJFrailey@Raytheon.com 972-344-8366. Agenda. How the world has changed The current state of software engineering education Creating and disseminating a new reference curriculum And next?.

wilona
Télécharger la présentation

Dennis J. Frailey May 28, 2009 DJFrailey@Raytheon 972-344-8366

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Educating the Next Generation of Software & Systems Engineers Dennis J. Frailey May 28, 2009 DJFrailey@Raytheon.com 972-344-8366

  2. Agenda • How the world has changed • The current state of software engineering education • Creating and disseminating a new reference curriculum • And next?

  3. What the OSD Found when evaluating problems with major defense programs • One of the major causes of defense program problems was found to be poor communication between systems and software engineers • Different organizational entities within most defense contractors • Different languages, processes, models, methods, tools • Different academic backgrounds • Etc. etc. • Furthermore, few engineers of either variety are familiar with the latest developments in their own fields • Too busy working on their programs to keep up with rapidly advancing disciplines • Often, each company has its own unique culture for each of these disciplines that does not necessarily align with what is done outside • And, finally, the existing academic programs in these fields are so inconsistent that contractors and the government do not always know what they are getting when they hire someone with a graduate degree in either field.

  4. What the OSD Wants • Better coordination between these fields in defense contractor organizations • “Raising the bar” on the content of graduate programs in these fields • More consistency among graduate programs in these fields The ISSEC project is intended to address the second and third items in the above list. The first product is a model curriculum in SW engineering (because it has a more consistent and widely accepted body of knowledge) 5

  5. The Integrated Software andSystems Engineering Curriculum Project • Begun in May 2007 at Stevens Institute of Technology • Sponsored by DoD Director of Systems and Software Engineering (Office of the Secretary of Defense) • Three products planned: • A modern reference curriculum for a master’s degree in software engineering that integrates an appropriate amount of systems engineering • A modern reference curriculum for a master’s degree in systems engineering that integrates an appropriate amount of software engineering • A truly interdisciplinary degree that is neither systems nor software engineering – it is both

  6. What do we teach for a master’s degree in software engineering? • The last effort to create a reference curriculum for graduate software engineering education was by the SEI in the early 1990s. • There are, in effect, no current community-endorsed recommendations on what to teach software engineers at the graduate level – nothing that recognizes how the world has changed. • Response: create a project to create a new reference curriculum in software engineering 7

  7. 1st Project – Graduate Software Engineering Reference Curriculum Understand the current state of SwE graduate education (November 2007) Create GSwERC 0.25 with a small team, suitable for limited review (February 2008) Publicize effort through conferences, papers, website, etc (continuous) Create GSwERC 0.50 suitable for broad community review and early adoption (October 2008) Create GSwERC 1.0 suitable for broad adoption (2009) Transition stewardship to professional societies (2009) Foster adoption world-wide (2009 and beyond)

  8. Software Requirements Analysis Software Design Software Construction Software Testing Software Maintenance Software Configuration Management Software Engineering Management Software Engineering Process Software Engineering Tools and Methods Software Quality Body of Knowledge - SWEBOK www.swebok.org

  9. SWEBOK coverage* in 2007 across 28 SwE MS programs *Coverage in required and semi-required courses

  10. The current author team • Rick Adcock, Cranfield University and INCOSE participant • Mark Ardis, Rochester Institute of Technology • Larry Bernstein, Stevens Institute of Technology • Barry Boehm, University of Southern California • Pierre Bourque, École de technologie supérieure and SWEBOK volunteer • John Bracket, Boston University • Murray Cantor, IBM • Lillian Cassel, Villanova and ACM participant • Robert Edson, ANSER • Richard Fairley, Colorado Technical University • Dennis Frailey, Raytheon & Southern Methodist University • Gary Hafen, Lockheed Martin and NDIA participant • Thomas Hilburn, Embry-Riddle Aeronautical University • Greg Hislop, Drexel University and IEEE Computer Society participant • Dave Klappholz, Stevens Institute of Technology • Philippe Kruchten, University of British Columbia • Phil Laplante, Pennsylvania State University, Great Valley • Scott Lucero, Department of Defense • Qiaoyun (Liz) Li, Wuhan University, China • James McDonald, Monmouth University • John McDermid, University of York, UK • Ernest McDuffie, National Coordination Office for NITRD • Bret Michael, Naval Postgraduate School • Ken Nidiffer, Software Engineering Institute • Art Pyster, Stevens Institute of Technology • Mary Shaw, Carnegie Mellon University • Robert Suritis, IBM • Richard Thayer, California State University at Sacramento • Barrie Thompson, Sunderland University, UK • Guilherme Travassos, Brazilian Computer Society, Brazil • Richard Turner, Stevens Institute of Technology • Joseph Urban, Texas Technical University • Ricardo Valerdi, MIT & INCOSE participant • David Weiss, Avaya • Mary Jane Willshire, Colorado Technical University

  11. Creating GSwERC 0.50 and 1.0 Understand the current state of SWE graduate education (November 2007) Create GSwERC 0.25 with a small team, suitable for limited review (February 2008) Publicize effort through conferences, papers, website, etc (continuous) Create GSwERC 0.50 suitable for broad community review and early adoption (October 2008) Create GSwERC 1.0 suitable for broad adoption (2009) Transition stewardship to professional societies (2009) Foster adoption world-wide (2009 and beyond)

  12. Expectations at entry (from version 0.5+) • DEGREE: • The equivalent of an undergraduate degree in computing or an undergraduate degree in an engineering or scientific field and a minor in computing • SWE COURSE: • The equivalent of an introductory course in software engineering • EXPERIENCE: • At least two years of practical experience in some aspect of software engineering or software development

  13. Outcomes at graduation (from Version 0.5+) • CBOK: • Master the Core Body of Knowledge • DOMAIN: • Be able to apply software engineering in at least one application domain, such as finance, medical, transportation, or telecommunications, and in one application type, such as real-time, embedded, safety-critical, or highly distributed systems. That ability to apply software engineering includes understanding how differences in domain and type manifest themselves in both the software itself and in their engineering, and includes understanding how to learn a new application domain or type. • DEPTH: • Have mastered at least one knowledge area or sub-area from the Core Body of Knowledge to at least the Bloom Synthesis level.

  14. Outcomes at graduation ETHICS: Be able to make ethical professional decisions and practice ethical professional behavior. SYSTEMS ENGINEERING: Understand the relationship between software engineering and systems engineering and be able to apply systems engineering principles and practices in the engineering of software. TEAM: Be able to work effectively as part of a team, including teams that may be multinational and geographically distributed, to effectively communicate both orally and in writing, and to lead in one area of project development, such as project management, requirements analysis, architecture, construction, or quality assurance.

  15. Outcomes at graduation RECONCILIATION: Be able to reconcile conflicting project objectives, finding acceptable compromises within limitations of cost, time, knowledge, risk, existing systems, and organizations. PERSPECTIVE: Understand and appreciate the importance of feasibility analysis, negotiation, effective work habits, leadership, and good communication with stakeholders in a typical software development environment. LEARNING: Be able to learn and apply new models, techniques, and technologies as they emerge, and appreciate the necessity of such continuing professional development.

  16. Outcomes at graduation TECHNOLOGY: Be able to analyze a current significant software technology, articulate its strengths and weaknesses, compare it to alternative technologies, and specify and promote improvements or extensions to that technology.

  17. Curriculum architecture BSEE and BSCS grads Business grads Old degree,recent experience BSSE and BSCS grads Other degree,some experience BS + extensive experience Prep Material Baseline: Expected capability of CS and SE Grads Core Materials University-Specific Materials Elective Materials Capstone Experience

  18. What Universities are Doing to Help • Comparison of existing graduate software engineering graduate programs with GSwERC recommendations – know how big the gap is between recommendations and practice • Strategies recommended by the authors to implement GSwERC • Hypothetical modifications of existing programs to more fully satisfy GSwERC

  19. What Companies Can Do to Help Review the model and make suggestions About 5 Raytheon experts have done this Dennis Frailey of Raytheon is on the author team Use the model as a guide For evaluating potential employees For recommending employee graduate programs For implementing internal education programs Mention/discuss the model with universities where they recruit employees Reference the model when describing employee qualifications on proposals Participate in post-release governance (through IEEE-CS, ACM, or NCOSE) Support maintenance of the model Industry advisory committee Volunteering employee time

  20. Deliverables – September 2009 • GSwERC will be delivered in 3 standalone volumes: • Primary curriculum recommendations – heart of GSwERC • Implementation guidance organized by specific programs that are compared with GSwERC, propose adopting GSwERC, or have experience adopting GSwERC • Implementation guidance organized by issue, such as how to recruit faculty with the right skills, or how to organize projects with significant distributed development • Primary recommendations are typical of what professional societies traditionally shepherd • Implementation guidance is less typical of what professional societies traditionally shepherd

  21. Systems engineering curriculum • INCOSE sponsored a graduate systems engineering (SE) reference curriculum published in 2007. • The SE curriculum development process did not have the scale of participation that GSwERC has and is limited by the fact that the INCOSE SE Body of Knowledge (see http://g2sebok.incose.org) is much less robust and mature than SWEBOK. • INCOSE would like to mature the SE body of knowledge, which would be a strong foundation on which to base an upgraded SE curriculum. • The U.S. Department of Defense is considering sponsoring a project to update and mature the SE body of knowledge with INCOSE and create a mature SE reference curriculum. The effort would be similar to GSwERC with open collaborative international participation and fully shared resulting intellectual property. • Other professional societies would be welcome to participate.

  22. Raytheon & SE Curriculum If OSD sponsors the SE curriculum effort, it is expected to be similar to the SWE effort, but perhaps will take longer because of the weak body of knowledge for SE Raytheon could participate by Identifying someone to serve on the curriculum author committee Reviewing drafts of the curriculum model Etc (see “what companies can do to help”)

  23. Joint Curriculum If OSD sponsors the joint curriculum effort, it is expected to be similar to the SWE effort, and should benefit from the work of the SE and SWE efforts Raytheon could participate by identifying someone to serve on the curriculum author committee Reviewing drafts of the curriculum model Etc (see “what companies can do to help”)

  24. Summary • GSwERC is on-track to deliver a fresh reference curriculum for world-wide use in 2009. • Professional societies are expected to take ownership of the curriculum after it is published. • There is a need and an opportunity for a similar systems engineering project. • Corporations can support this effort in many ways

More Related