The MSIT-SE Program draws from Carnegie Mellon's strengths in technology, innovation, and interdisciplinary collaboration.
The SE (Software Engineering) track provides students with a solid foundation in the principles of software engineering, with an Insight into the important business issues of the day.
Most of the courses are drawn from Carnegie Mellon's highly ranked School of Computer Science. The core is a content-based curriculum designed to enable students to 'learn how to learn' in the rapidly evolving software development field. The capstone practicum is a chance to apply core course material to a substantial project in the workplace.
There are five core courses. The concepts and the skills acquired in these core courses are applied in the Practicum.
The courses are:
Scientific foundations for software engineering depend on the use of precise, abstract models for characterizing and reasoning about properties of software systems. This course considers many of the standard models for representing sequential and concurrent systems, such as state machines, algebras, and traces. It shows how different logics can be used to specify properties of software systems, such as functional correctness, deadlock freedom, and internal consistency. Concepts such as composition mechanisms, abstraction relations, invariants, non-determinism, inductive definitions and denotational descriptions are recurrent themes throughout the course.
This course provides the formal foundations for the other core courses. Notations are not emphasized, although some are introduced for concreteness. Examples are drawn from software applications.
Practical development of software requires an understanding of successful methods for bridging the gap between a problem to be solved and a working software system. This course focuses specifically on methods that guide the software engineer
from requirements to code. The course will provide students with both a broad understanding of the space of current methods, and specific skills in using these methods.
Large scale software development requires the ability to manage resources - both human and computational - through control of the development process. This course provides the knowledge and skills necessary to lead a project team, understand the relationship of software development to overall product engineering, estimate time and costs, and understand the software process. Topics include life cycle models, requirements elicitation, configuration control, risk management, estimation, planning and tracking, work breakdown structure and quality assurance, all of which are used in the Practicum.
Our ability to build, maintain, and reuse software systems relies on our ability to analyze effectively the products of software development. This course will address all kinds of software artifacts - specifications, designs, code, etc. - and will cover both traditional analyses, such as verification and testing, and promising new approaches, such as model checking, abstract execution and new type systems. The focus will be the analysis of function (for finding errors in artifacts and to support maintenance and reverse engineering), but the course will also address other kinds of analysis (such as performance and security).
Various kinds of abstraction (such as program slicing) that can be applied to artifacts to obtain simpler views for analysis will play a pivotal role. Concern for realistic and economical application of analysis will also be evident in a bias towards analyses that can be applied incrementally. The course emphasizes the fundamental similarities between analyses (in their mechanism and power) to teach the students the limitations and scope of the analyses, rather than the distinctions that arose historically (static vs. dynamic, code vs. spec). The course will balance theoretical discussions with lab exercises in which students will apply the ideas they are learning to real artifacts.
Successful design of complex software systems requires the ability to describe, evaluate, and create systems at an architectural level of abstraction. This course introduces architectural design of complex software systems. The course considers commonly-used software system structures, techniques for designing and implementing these structures, models and formal notations for characterizing and reasoning about architectures, tools for generating specific instances of an architecture, and case studies of actual system architectures. It teaches the skills and background students need to evaluate the architectures of existing systems and to design new systems in principled ways using well-founded architectural paradigms.
A software process definition is the cornerstone of implementing and improving a software process. Although this course is primarily intended for students in the of the Master of Software Engineering program, others interested in learning how to define a process are welcome and could benefit as well.
The objective of this course is to prepare students to define software processes.
The primary purpose of this course is to present an overview of real-time computing. Basic concepts, terminology, and problems of real-time computing are introduced. The constraints of real-time computing are used to contrast real-time applications from applications that are not real-time. The course focuses on software solutions to real-time problems. Issues that are addressed include scheduling, specification of system requirements and design, real-time software architectures, languages and operating systems for real-time computing, real-time problems in a distributed processing system, and hardware-software interfaces.
The purpose of this course is to introduce students to applying software measurement; from need identification through analysis and feedback into the process. Much of the course material used to demonstrate the concepts are based on how software measurement is used by managers and practitioners in industry today. The content of the course is taught within the framework of the software engineering process.
The Personal Software Process
I. Summary of High Level Course Objectives
A. Concepts and Definitions
- Making and honoring commitments
- Measuring the work to be done
- Estimating the effort based on the size of the
work to be done
- Production rates and allocation of effort to
phases of the project
- Improving performance and quality by finding defects early
B. Application of these concepts (Students should be able to answer these questions when they have finished the course.)
- What problems did you have estimating the size
of the work to be done and what did you learn from this experience?
- How accurate was your effort estimates and what
could you do to improve this accuracy based on your experiences?
- How did plan versus actual performance variance
change over the course of your PSP assignments and what single factor do
you feel was the largest in causing this?
- Why do we concern ourselves with determining
when a defect was injected? What actions can we take to improve
performance and quality base on this? Why is it easier to find defects
in a review as opposed to in testing?
- What kinds of defects were the most common in your PSP projects? What
actions did you take to avoid or detect these defects early? How successful were you? What single factor was most significant in helping you improve your performance and quality?
II. Agreement on minimum requirements
- At least seven actual programming assignments
(optimal is ten)
- These actual assignments should be in a problem
domain that the students know well so there is no additional learning
required to performing the programing activities
- Students must know their programming language
and their development environment prior to starting the PSP assignments
- At least one report must be produced where the
student reflects on his/her actual performance and what he/she have
learned (abstract the requirements for this report from R4 and/or R5)
- The actual programming assignments may be changed, but the size of the effort should
be similar to what is in the Watts Humphrey’s text, appendix D (A or B series)