mse faq

CMU MSE FAQ	Home \| Resume \| MSE FAQ \| Links

	This is a list of questions whose answers I, and some of my fellow Masters of Software Engineering (MSE) students, wish we had known prior to coming to the MSE program. This is in no way associated with CMU or the MSE program in any official manor. These are my personal answers/advice, they may not help everyone. Let the reader beware. I hope these answers will make life a little easier for people who want to go through the MSE program. Let me start by saying that I would highly recommend the MSE program. As it says on my homepage, I majored in computer sceince (CS) at Rochester Institute of Technology (RIT). RIT has an undergraduate SE program as well as their more traditional CS programs. I chose CS for my undergrad mainly because I didn't know about the SE program. Even if I had, I probably would have gone for the CS program anyway because I felt that a more traditional, theory-based curriculum would allow me to be more flexible professionally. While RIT's CS program does have a significant amount of theory, they were focused on teaching us how to use what we learned in "real-world" scenarios. This served me very well during my required co-ops as well as the first few years after graduation. During my work with the C-Print project at RIT, I started to see how my undergraduate degree had not equipped me with the necessary skills to lead a development group (which I was doing, though it was only 3 developers at most). It also didn't equip me with the skills to ensure the products I was helping to produce would be high quality. The biggest problem for me was that I didn't know how to fix it. I knew that we should have a testing regime, code reviews, documented defects and requirements, etc. but I didn't know how to implement them in any useful way. Now, I don't fault RIT's program for any of this, in fact I would do it the exact same way if I were to do it again - I would still go into the CS program as an undergrad. But I knew I had to find out how to get better. I wanted to know how to create better software that people would like to use and could rely on. Enter the CMU MSE program. I won't go into the history of the program, that can be found on their site. Needless to say, CMU is very well respected in the SE community. They have the Software Engineering Institute (SEI) and many leading people in the field. The MSE is a highly selective program that focuses on the following aspects of SE (just a sample): Architecture Planning Estimation Tracking Risks Quality assurance Design Requirements Development methods The above topics encompass both theoretical and practiced techniques. The curriculum of each core class (there are 5) has apparently changed quite a bit over the years as they incorporate new knowledge and techniques developed at CMU itself, the SEI, or elsewhere in industry. This means that while some questions and their answers below might be outdated quickly, this is a starting point.

	The FAQ

	Q: Can I work while participating in the MSE program full-time? A: Yes and no. Don't expect to work 40 hours, there's 40-50 hours per week of homework and classwork. I worked an average of 12 hours per week while going through the program. It was very difficult because of burnout, but it is doable.

	Q: Where should I live? Can I drive or should I take the bus? A: The book that the program sends to accepted students ("Guide to Living in Pittsburgh") outlines this pretty well. The bus service works pretty well if you live in the 3 areas immediately surrounding CMU: Squirrel Hill (recommended) Shadyside (recommended) Oakland Where it becomes an issue is when you live further out. I, for example, lived in Monroeville, a suburb of Pittsburgh. It's only 12 miles from CMU but because of the traffic going through the tunnels, it can take 40 minutes or more to get to Squirrel Hill by car. For me, there was only one bus that I could take to and from Monroeville and it ran every 30 minutes during peak times (i.e., 6-8 am and 4-6 pm) but only every hour on off-peak times. It also didn't run after 9:30 pm which made staying late difficult. This was an inconvenience more than anything. Parking at CMU is expensive so I decided not to purchase a parking pass. What I did end up doing, was driving into Squirrel Hill and parking there, then catching a bus into CMU. This worked best when I had classes that started later (10am at the earliest) as that way, I could avoid most of the traffic. I also did this on Friday, regardless of how early I needed to be at CMU as I usually stayed later to hang out with my team and other MSE/MSIT students.

	Q: Is there financial aid? Any suggestions for loans? A: This was one of my major concerns. CMU doesn't have a lot of funding for financial aid. Most students used Federal Stafford loans and private loans. I would also recommend getting loans one semester at a time when possible. The reason is that, at the minimum, you'll have to get loans 3 separate times if you're not fortunate enough to have the cash on hand to finance any of this yourself. The reason is that even though the program goes right through the summer semester, CMU's financial services won't certify loans that are meant to include that semester - they will only certify enough to cover the fall and spring semesters. So save yourself some interest and get loans one semester at a time.

	Q: Any hints about the classes? A: Be aware of Methods. There is a ton of reading for the class, do not try to do it all. If you want, you can split up the reading amongst team members and then discuss. However, it is usually enough to read for the main points - skim most of it. Chances are, you will get frustrated with the course load in the fall. From my experience, it is normal. Some of the classwork doesn't seem relevant at first or is not what you expect. Models and Analysis are more theory-based. They present techniques and their backgrounds. If you are expecting all of the classes to focus on purely proven, standardized methods and techniques, these classes will surprise you. The frustration with the classes and course load will pass.

	Q: Any suggestions about electives? A: Read the descriptions carefully - very carefully. I took a few courses that turned out to be completely different than what I had expected from reading their descriptions. Sign up for more than you need and drop the ones you don't want. This seems like a no-brainer but I didn't think of it at first.

	Q: What kind of computer do I need? A: Any kind is fine. There are some utilities or tools that only run on Windows, but I didn't run into any major problems with my Mac. Get what you like.

	Q: How do you choose a process, method, or technique? A: That can't really be answered easily. Like anything, you pick what fits best. Don't choose one just because it's new or cool. However, don't automatically avoid a process (or anything else) because you're really interested in trying it. Wanting to try something is a valid reason for picking a process, but don't make it your only reason. Weigh the benefits and drawbacks of each process against what your project/customer requires.

	Q: What about planning, tracking and estimation? A: This is extremely important especially for the spring and summer semesters. The mentors will want to know "where you are, where you're going, if you will get there, and how do you know?" To this end, look into some kind of tracking tool for tasks and action items. The difference is that a task is a long term activity and an action item is something that should be done by the next meeting (usually less than one week). Some teams have used MS Excel, Project, or web-based systems. We originally used a web-based system because we wanted each person to be in charge of tracking their action items and tasks. We used a system called dotProject. The problem with dotProject was that it was slow. Painfully slow. We then decided to change to MS Project. Apparently MS Project's web-based interface isn't much better, so we decided to assign one person the responsibility of managing the planning and tracking on our server using the desktop version of Project. This worked well, but was a lot of work for that one person. I wouldn't recommend using it to track short-term items like action items. For that, use something lightweight. We used a web-based application specifically designed for action items. Very easy and fast. For estimations, look into Wideband Delphi. For tracking where you are look at Earned Value Tracking (EVT). Managing Software Development will introduce you to these along with other useful methods.

	Q: Do you have any useful suggestions that haven't been covered already? A: The following is a list of suggestions I would make to incoming MSE students and teams: First and foremost, define a good meeting process. Define meeting roles and use agendas. Definitely have a scribe and a facilitator. Nothing wastes more time than ill-run, ill-prepared-for meetings. Status meetings are good, but shouldn't be too long. Figure out your team's threshold for meeting length. My team's threshold was one hour - anything longer and we were not effective and the meeting would become worthless. Have a way to grade meetings so that you can improve. Reflect. This goes for everything. Define a process to review what you've done as a team (and individually). This can be processes, techniques, etc. Determine what you would do differently - or if something worked particularly well, why. This is the key to improving as a team and individually. Always know why something worked or didn't work and what you will do to fix it. The mentors are looking for teams to use what they have learned but also to understand why a particular method (process, technique) worked or didn't. They want to know you are learning from your mistakes and successes and thinking about it all. Take time to bond with your teammates. Do something together once a week where all of your teammates can talk and get to know each other. We did team dinners/lunches on Fridays. It helped us get to know each other in more than just a work capacity. It also helps to develop trust between your teammates which will become very important. It's also a good idea to define specific times where the entire team is in the Cave together. This can be for working on studio, or just working on homework together. Like suggestion 3, this is to build trust in the team members. By being in the Cave together, you can easily help each other with assignments and learn to rely on each other. Be very aware of burnout and stress. This program is hard. Burnout hit our team starting around week 10 in both the fall and spring semesters, and week 5 or 6 in the summer. Make sure you take this into consideration when defining risks and mitigation strategies. Despite the lack of classes, the summer semester is not easy. You have long days which make for long weeks and the stress piles up quickly. Be aware of this going into it. Do not expect to come out of the program knowing everything there is to know about SE. The goal, in my opinion, is to introduce you to as many methods and techniques as possible, and give you a taste of using a few. For the most part, you will graduate from the program knowing about a lot of techniques but never getting to use them. This means that it is up to you and your team to choose what techniques and methods to try with your project. Otherwise, chances are that you won't have too much experience in using them when you finish the program.