Engineering is a Team Sport

Tune into this episode of UMBC’s Mic’D Up with special guest, Paul Martin, ESEP, CTT+, graduate faculty with UMBC’s Systems Engineering Graduate Program.

He speaks with us today about the field of systems engineering and why it’s critical that we have really great systems engineers dedicated to finding ways to make the world a better place. This starts with having a team mindset because systems are not built within silos. It takes a concerted effort of many experts to bring systems together in a meaningful way. 

Learn more about UMBC’s graduate program in Systems Engineering: https://se.umbc.edu

SUBSCRIBE!
Please subscribe to our channel to receive the latest podcasts as they publish.

Connect with us:
Twitter: https://twitter.com/UMBC_DPS
Facebook: https://www.facebook.com/UMBCProfessionalGradPrograms
Youtube: https://www.youtube.com/c/UMBCDivisionofProfessionalStudies 

Transcript

0:00

Welcome to this episode of UMBC's Mic'd Up. My name is Dennise Cardona from the Office of Professional Programs. We're joined by graduate instructor Paul Martin with UMBC's Systems Engineering Graduate Program. We hope you enjoy this episode. Well, welcome, Paul, to this episode of UMBC's Mic'd Up podcast. It's really wonderful to have you here with us today. Thanks. I really appreciate this opportunity. I really do. So, Paul, could you give me a little bit of a background on your path for teaching at UMBC? Oh, actually, that's a fairly interesting story, because being a engineer, I've been an engineer since the 70s. So it's like super old and stuff. But after a while, I actually was able with the Navy. They actually sent me to school full time to get my master's degree in system engineering. And it took a while because I was out of school about 10 or so years and I was back in the academic realm. It was fairly strupp, stressful. I had six kids, young kids, my wife and all. But it was full time, which was nice. And you think, oh, you're going full time. Isn't that why it was so much work? Because I had to go at night. And, you know, all these were night classes and I was taken three or four, you know, a week at night. So I'd get up and go to school and get back at midnight, you know, get up, help with the kids, leave at noon, get back at me. What was neat about that is after awhile, I just started getting into that rhythm of academia. And afterwards, I after I got my degree and I was back at work, I actually kind of missed the academia research stuff that was just really interesting to me. And then I found out I kind of had a little capability of teaching when I actually started teaching my church at the Sunday school with the kids and stuff. And it was really kind of fun. I realized I liked it. So just out of the blue. The dean of the UMBC system engineering came to me and I just saw them. We were talking about something else. I said, well, you know, and they were just starting the program. And I just casually mentioned I would love to try that, you know, to try to teach. And he said, OK, let's do this. So we got together as a group of us, of different people teaching different classes, and we were trying to map out how to make it work and stuff like that. And I slowly began to realize, oh, my gosh, I don't know as much about system engineering as I thought I did. And I actually, through the process of preparing the class and getting the various topics together and figuring out our objectives, I actually got much better. And of course, that was 15 years ago. And so it's a lot I think I'm a little better at it. My first year was absolutely horrible. I got terrible feedback. I was I was a dictator, blah, blah, blah. And. And my dean was like, no, you don't understand. Every teacher goes through this. Their first year is always horrendous. And I was like, oh, okay. And it did humble me. And so I actually start each class. I said, look, I don't want this to be a monologue. I wanted to be a dialog. So please interrupt me at any point. And and let's talk about the point that maybe I'm not making very well or maybe one of your experiences. I would love you to contribute to the class. So I actually start a lot of that. I really try to encourage that dialog within my classes. So that's how I got started. That was prior a longer story than you needed. Sorry. No, that was really interesting to listen to. A few things that came to my mind was the fact that you because you were an adult student and you were balancing six kids. Yes. Going to school full time. You are probably very empathetic as an instructor because your understanding of a student's struggle to achieve that work life balance, because that is one of the major struggles that adults do. And actually, I try to discourage students when they say, oh, can I take your class? Plus this other class. But I said, you don't know that your graduate class. I'm going to ask you, you know, to perform at the graduate level. And if you're family and work life and now this is too much for you, just do one class at a time. Don't do trying to get it all done at once. So I do try to encourage. It's too to pace it out. Now, there are some students that come in right after they get there. Like bachelors degree. And they may just have work perhaps, and not family yet that might work for them. But I do try to encourage students to keep in mind the amount of effort it takes to get through one of these classes at a graduate level. So, yeah, that's really important. And, you know, you're doing that because you want the best for your students. Yes. And you don't want them to fail. And you want them to succeed. And it's an honest assessment of, you know, the instruction that they're going to get. And the other point that I got from what you said was the more practice you get, the more growth you get. And it sounds like that's what happened with you. That is an honest self-assessment that, you know, that's true. And there are actually certain concepts that were I struggled with at the beginning trying to teach them and work with them and then afterward, look, kind of light bulb went on. And I actually have a better way of teaching them and stuff. I have this one thing I do where I teach the difference between a measure of effectiveness to measure up performance to a technical performance measure. And I'll tell you, I actually lived that as a system engineer and I was still struggling with it. And then finally trying to keep teaching it. I actually started to realize the differences. MOEs are mission oriented thing. M0P is more of the system looking at that. And then TPM is more the system element. If you kind of get that straight in your mind, you kind of get a better sense of that. So I really try to stress to the students to get that out. You'd be amazed. I mean, when you're out in the field, actually working system engineering, no one sits you down and say, here's this vast machine you're part of and you're just one cog within that machine. And my whole aspect of what I try to teach these students, and this comes out through our redesign of 660 is the whole idea of context. And so in the system engineering handbook that Inkosi puts out and it's based on a INCOSE standard 15288. And I mean ISO standard and the ISO standard is actually interactional. And this is the way they want people around the world to think about engineering. And it's within this context of an organization that has an agreement with another organization to produce a system. So you come up with a project and when you have a project, you need to support the technical processes. So the fifteen to eighty eight actually discusses that. And of course, the handbook goes into more detail. So when I teach the handbook, which I must admit can get kind of dry, you're reading all these like processes and you're reading process in the way they they put it in. It's like Chapter Four's technical processes. You're like, Oh, that's great. That's what I do. This is great. And then it's agreements like contracts and stuff. You're like, Oh yeah. I kind of know what the contract people do. That's that's cool. Oh, program management. You know, the management stuff. You're like, yeah, I interface with them all the time. And then all of a sudden you're at the organization. You're like portfolio management h. Ah. What. What's happening to my life here. And you're in chapter seven, you know, and it's just like it's so what I do is I kind of say, well, we start with Chapter seven, just explain where the organization and they have these needs and they want to work this stuff out. And from the organization contracts for a project and then boom the technical processes. So now you're in a cog in this machine and the upper management is asking for metrics and you're like, I'm trying to work here. Why do you given me this metric thing? Well, now you understand metrics go into the program assessment and control, which goes into project planning, which goes in through the portfolio management. So I try to explain how that all kind of interconnects in the context. So at least you don't get lost. And believe me, I wish somebody taught me this when I was a young man because I have very few regrets in my life. But from a career standpoint, I do regret a lot of my system engineering choices I made when I was young because I just didn't have context and I did didn't know where I was. I really should. When I was working for the Navy, I should have been concentrating on the product and helping the system. And instead I was just so focused on process. We got to get this process right, you know, and and I really learned even through teaching and stuff like that. And I really tried to stress to. My students, if a process has no value, please get rid of it. You do not need to waste your customers time, your time, or that what you're trying to accomplish within the mission that you're trying to put your system into by having a useless process. So having your and a lot of people complain about system engineers. We're all about process and documentation and stuff like that. No, we need to be concerned about the mission and making sure that it's actually successful. And to get that mission successful is to get a system that's required to make the mission work. So what kind of process and documentation do you need? And process and documentation is also needed from the organization standpoint because they're actually the ones that want that repeatability. It's like I build a plane. Right. And I want to build another plane for another customer. I can't just start from scratch. You've already showed me how to build that plane. Let's document all that. Get the processes in place and then actually try to work that through. Wow. So you brought up a great point about value. And that's true of anything in life, right? Like, if something is not showing value, you know, that's a question I ask myself a lot. Does this add any value to my life? And if it doesn't, why am I paying attention to it? That's exactly right. And I think that that's true with anything that you approach in life and with systems engineering, it sounds like that is very true in terms of the overall picture of what a systems engineer team is working on. If they don't understand the end result and the end goal. Yes, you will, then that value driven principle is missing. That's true. And value is actually a simple equation. It's the benefit you get divided by the amount of effort or resources or cost. Right. So if you're putting amount of cost into something in that benefit is is lower than that. If you're into a negative value, that's not good. And so you really want that benefit to be higher than the cost you're putting into it. So that's why we also really stress the priority of what you're trying to accomplish. One of the things we really try to stress to our engineers is, is your requirements as you bringing in in and requirements is a big thing for system engineers week, week next to processes. We really love requirements, you know, because requirements are what describes to us what our customers want. Right. Do you know the definition of quality? How would you define quality? Oh, pressure. Yeah. Yeah, but how would I define quality? I would define the quality and definition, a simple definition. Yeah, there's a real simple one, but I wonder if you're kind of geared towards that quality to me. I would define it as something, and when I use that word value, again, something that adds value to either myself, my family, my work, the organization that I support. And if it doesn't have that value, then I don't think of it as quality. Yeah. And that's actually a very good definition of the simple one I was thinking of. Was you satisfied your customer. OK. So so quality. Is that customer satisfaction? And we find that quality is actually something that organizations need to take seriously. And they're the ones that need to impress on their employees that I need you to think about quality. What is the best way we can satisfy our customers? Now, a lot of times you think of customers as, oh, I build, you know, airplanes, my customers, my pilots and the people were going to actually do it. But actually, you have another customer. It's the organization you work for. OK. So so there's a two prong aspect to this for quality. It's like number one, are you actually making a product that satisfies your customer? Number two, are you making that product in such a way with your processes that you're satisfying the organization? So satisfying the organization, of course, normally is either that you're getting the money that they are expecting. Right. They're getting that. But you also may be working for a defense organization. Right. So there's a security aspect in that aspect. What is your mission? What is their mission? Are you satisfying them? So that's where quality to me. Number one is what are those requirements that are coming in from your customer, either from the organization or the customers want to take your system? What are those requirements? And then how do I fulfill them? And if I fulfill them, I should have a quality product because I fulfilled, you know, what what satisfies the customer? So to me, as a system engineer, I actually used to get all kind of upset when they talked about quality and satisfying the customer. I was like, what do you think I'm doing? That's my whole life here as a system engineer, is to make sure requirements are met, you know, and so system maybe my middle name should be quality system, quality engineering or somebody without help. You. And so but I did finally calm down after a few years, you know, and I just realized that we need to really stress to new system engineers. Right. And those who are actually working with the system engineers to understand that it's OK to talk about quality and make sure that there's an understanding on all sides in terms of how requirements are part of that. There's so many projects that are finished and we're like, oh, we got all the requirements done. And then all of a sudden the customer is not happy with it. And it's like, OK, something broke there if I didn't get the requirements correctly. So now you have to go back and say, well, how did I get my requirements listed? Right. You know, you don't gather requirements. They're not just on the ground and you pull them up right now. You have to extract them from the customer correctly. And so that's another thing we really push out. And I think I just got slow off track. I don't even do what you were asked. They always said we went from value to quality to requirements. Oh, so. So I love it. This is such an interesting conversation. You're getting me on my soapbox. And this is really interesting. Now, what I'm going to do is bring it back to you, then be season you indices course the Yes systems engineering principles systematic sixty. And I'm going to refer back to the definition you gave of quality, because it sounds like when you talked about your teaching principles, it sounds like it's really important for you to make sure that your students get that benefit from the course. Oh, wow. Right. But also from you and me, it's good. But also UMBC in general, from their education, it's really important that we're we're producing students. Yes. Have this quality in mind and these courses. And so. Let's talk a little bit about think it's it's good you mention that because our dean. Right. Is. Now wanting us to redesign 660 so that it actually kind of incorporates that whole aspect of the international view system engineering. So we're going to use the INCOSE now. INCOSE is the International Council of System Engineering. They're the only organization out there that actually talks to system engineering in its total assets. So system engineering from a total say standpoint. So INCOSE has a handbook that's based on ISO 15288. And so what the dean is asked as us to create this 660 class that actually focuses on that handbook. And does that context thing I told I told you about at the beginning, talking about the organization in the project and eventually and even agreements in contracts and then get into the technical processes. So I'm redesigning 660 to do that. And what's neat about that, if we do it correctly, we can actually get an agreement within Kozy so that students who finished this class will actually come out and they will have the equivalency of the INCOSE system engineering professional exam complete. So they'll actually have that on their check. You know, when they go to INCOSE and say, I want to become an associate sys engineering professional or an ASEP, they can say, oh, you took this course, you've pretty much done the exam, you're good. Just give me your application and you'll become an ASEP. And so now they do me become an and cozy member at that time. Of course, they can get it as at a student rate, which is nice. That's it. You become an ASEP. And it really kind of nice in where we really want to kind of make that one of our. The way the dean puts it. Woodrow. He puts it as a triple threat. Right. We're trying to get you not only where your being taught correctly, but your experience will back that up. And now you're certified as well from a international organization that says you understand system engineering. So I love that. It's a nice thought that we're sending these students into the workforce with this triple threat as part of their arsenal, that when they go in to show their potential employers that this is what I have to offer. So it's it's gonna be really great once we're done. Sounds like incredible opportunities for our students. And so safe from somebody like myself who is not in the engineering field. How important is it to have this kind of certification behind you and your credentials when you're going out there in the world? What's good about it is that you're actually showing your potential employer that you're actually serious about your career. And that to me, is is number one. It's easy to get a job and just kind of do the work. But this actually shows that I'm not only doing this job, but I'm taking it serious enough that I'm doing this extra curricular type aspect where not only do I have this certificate, but I'm involved in the INKOSI organization and I'm networking. I'm actually get going perhaps to their conferences, symposiums. And I'm I'm keeping up with with my profession. And I know what the latest trends are, what's happening. And I think that an employer will look at that and go, OK. This is a person that's serious about what they're doing. And that's what I need, somebody who's serious. And that can bring not only their understanding of system engineering into the fold, but perhaps even consider giving us some ideas and innovations in how to improve what we have. Believe me, organizations want to improve their processes. It's the only way they can actually make that repeatability aspect of whatever systems they build, make it more efficient. Of course, they get more money, I guess, or whatever. But but you really are helping the organization be much more competitive when they're out there in the field trying to get more more business. I think from an employer standpoint, employers and employees are looking for a win win. Yes. If employers have employees. I completely dedicated it to expanding the sieve and showing that they have this determination and this ability, then they win. the employee wins from having this knowledge of body to move forward to an organization and make a real impact on the world. And that organization. And that actually brings up a good point where at when you're going out as a student, you're looking for a new job or whatever, you may want to look for employers that actually are taking seriously their responsibility to ensure that they are doing the processes and other aspects of business correctly. So there's actually ISO standards and certifications a business can have. There's this one called Capability Maturity Model Integration CMI. If you find an organization that says we're seeing my my four, you're like, OK, that's somebody you can get behind because they are with that certification, they agree the processes are important. They're going to document them and they're going to make sure all their employees follow them. You, as a certified system engineer, understand that. So now there's this great synergy that will occur. And that's another reason your such certificate can highlight to them a whole lot. We can trust you within R lifecycle model that we perform for our own systems that we build and things like that. Yeah, that's a great explanation of the importance of the certification. So thank you for explaining that to me. Now, in terms of the course itself, the Systems 660. Yes, you will be teaching it in the spring semester, spring 20, 21. Yes, it'll be the first time. Yeah. Wonderful. Yeah. I've I've taught 663 for about fifteen years and I've always told the deans, hey, if you need help with 660, I'm here for you. And it really nice what you're just came on board and I showed them my kind of my vision, what I was thinking. And he just really latched on to it. I'm very grateful that he is trusting me with this because this really is a foundation that I'm hoping Will will carry into the other classes. When you take six one, which is about architecture, you kind of have that foundation of where architecture fits within the machinery. And then when 663 gets taught, which is about the other, like once you have the system designed well, how do you get it out into the field? So implementation, integration and test is all about that. So those two, if I if we can really get those two courses more sinked up with that foundation of 660, I think they'll a student will just get a real well wound understanding of system engineering in its totality. So I'm really excited about this. One thing we do with our processes is and this is in the handbook. They have these things called IPOs, input, process, output. And those are very straightforward. It's like, here are my inputs coming from other processes here, my activities that I need to do for my process. And then these are the outputs that go to other processes. So if we kind of use those as a means to say we're about to talk about this process, here are these activities. Now we go into detail. I think the architecture in 661, in the implementation, integration in tests and 663 will make more sense. We just kind of give them a overview in 660, but in six sixty one and sixty three, we go into this deep depth depth of how to actually work those processes. Now, in terms of the class itself, what are you most excited about in teaching it? Well, it's funny you mentioned that because it's I've actually been teaching the handbook for almost 10 years, so I actually have my own business as a scholar. That business is actually to teach the handbook to potential system engineering professional certificate holders. Right. To pass the exam. So I actually teach that class to get the students to understand the handbook enough. So when they go into the two hour exam, they'll feel comfortable with the material and they'll be able. To answer the questions in such a way that they pass, so I've taught hundreds of students hundreds. I wish I could give you a percentage fell many pass. One of the problems I have is I teach these students, but then they they don't understand there's a application involved. And so I try to explain to them this is a very difficult application. Please put your time and effort into that. And sometimes I lose my students even though I taught them how to pass the exam. So it's really sad. But I've been teaching this for so long that this 660 is kind of a iteration of that. And so but what's nice and what I'm excited about teaching it this way and in a college standpoint, not just a boot camp would get you through this. Right. And believe me, when I just did that four days in a row before I talk to you here and it is nonstop talk, talk, talk, talk, talk. And, you know, eight hours of me talking and I. I actually get excited when they go I. Do you have a question? Somebody. I mean, after four days I get maybe five questions up that good, by the way. So nobody asked me questions. So when I get a question, I get excited. And of course, I spent fifteen minutes trying to answer the question because it's something different. And so then the students realized, well, we can't ask him a question. [INAUDIBLE] get all for himself. And so I do it. But what's neat about in the college standpoint, I get what I'm going to do is teach the same material. I'm going to enforce it with these exercises. So I get the students, they'll go into teams and then they'll start working a fake product. I found so I found a product online. It's called Samsung Fingers. And Samsung Fingers is a new phone. They came up with, which is actually a glove. And so you put a glove on the screens in the middle and you can do gestures. You can do. Talk to the hand. If somebody is trying to talk to you, it will say. And of course, when you talk to somebody, you do this. And it's hilarious. And so I actually work with my students. I said, look, they're actual functions within this system. I want you to give me the measures of performance for this thing. I want to talk to me. How would you work the maintenance aspect? I want you to work with me and tell me what would you do to elicit the requirements of what you feel user of this device would be? And by the way, you would start thinking your stakeholders is your stakeholder, just my customer wearing this glove or is the stakeholder that barkeep who has this customer with his glove that's interrupting everything he's trying to do? So it turns out that you find that everybody who's in in acting with this glove is a stakeholder in way. So I'm going to do those type of things. I'm kind of excited about that because I really see when they work as a team and have one product to work with day, they start getting the points I'm trying to put across. And they might start to feed off of each other to us. You said that there's this whole dynamic that must be really fun to watch as an insider to see that come to life. Yeah. I actually stress to my students that system engineering is a team sport. And when I teach 663, I give them a team project. And at the end, I actually have them do an assessment on their team members. And then I take those assessments and gather them up for each student. And I said, here's how your team mates thought of you. And I said, look, you need to take this seriously, because when you go out to the real world, you know, you need to work in a team and really be able to benefit the team and feed off each other, not just try to take it all on yourself or let others do everything you need to be part of that team. And so I find that play it helps them as they go forward in their career, that they have a good sense of what their ability to be part of the team. And I hope to do that in six sixty as well. You know, get them to work as a team and see what that looks like or doing. Yeah, because of that, let's face it, that is the real world. Yes. Work in silos. You know, it's really important that people have those sort of soft skills to be able to work with. Yeah. And to be able to encourage each other and engage with each other so that the best ideas can come to the surface. Absolutely. And that's where in system engineering, there is no way one person could understand everything involved in a system that you're trying to put across. That's why when system engineers get hired, they go into a room and it's filled with system. Engineers are like, what is like? Guess what? Every system engineer has their area that they need to work. And it needs to all come together. So being able to speak that same language and be able to speak system engineering to one another is the key to that. And that's actually what we're trying to, you know, actually make our students actually understand, is being able to have that language and be able to communicate in the system. Engineering talk. So I'd agree that this isn't such a fun conversation. Is there anything that I haven't asked you at this point that you feel would add some value to this conversation? I think the only thing I would add is going back 15 years ago when we first started the new UMBC system engineering classes, we were actually put into place because Northrop Grumman came to UMBC and said, you know what? You know, APL, John Hopkins University. God bless them. They do a good job with system engineering. But we're noticing that it's very ethereal and theoretical and we really need a practical approach to this. So the foundation of UMBC system engineering courses were to provide a practical understanding of how system engineering works in the real world. And so one of the things I do in six sixty three is every class I teach some kind of tool that they would use in in their actual real world experience. So I would teach the students how to do a trade study. And then have them do a homework on the trade study and then actually do it. And then they can now take that into because trade. So they come up all the time in system engineering. It's something you need to have in your back pocket and pull out and use. I teach them about in square charts, which are it's a very old technique from the 60s, for goodness sakes. There's actually a mill standard that talks about in square charts and it's just a fascinating way to look at components or people or, you know, functions, whatever you put down that and how they interact with each other. And you actually can start analyzing that and tried to bring the components or the individuals closer together and make that work better for you. So I teach that. So there are a lot of things like that. We tried to, from a UMBC standpoint, make this a very practical program for people who are serious about system engineering and really want to get to work right away with what's necessary and what employers are going to want them to do. So I think we really have a sort of a surprisingly in-depth program to help system engineers get really practical in terms of what they need to do in the real world. I think that's all I wanted to add. That is a powerful ending state. Thank you. I have one last question and I just thought of that I, I liked it because, you know, you seem incredibly passionate about your students. So what is your hope for each of your students? You know what's interesting is, is system engineering. And this comes into the play, the fact that I've. Really dug into it once I got my masters and started teaching it. I started realizing the importance in this. I've got to get philosophical and I apologize up front. But it's just it turns out that we are in a area of our existence as human beings. I've told you I was going to get philosophical. Sorry. And where we need to be more and more worried about systems. OK. The reason our society and civilization is where we're at is because we leaned into science. OK. And in that science, thinking from Newton, no one has given us the ability to create a world of all these products and things that we have because we understood the science behind it and stuff. And because of that, we now have seven billion people on the planet. OK, and science can only take us so far because the whole principle of science is you need to take a complicated thing and break it down into its little components. And then you explore those components. And now you understand the whole. And that actually is not true. OK. It turns out that your parts, when they interact with each other to create a system, will now have properties and characteristics and functions that are not absolutely understood at the park level. It's only understood when it's synthesized. And you have this system. It's a thing called emergence. And emergence is something that science can't handle. Science is not geared towards emergence, it's geared towards the part and understanding that part in what it is. And so emergence is something that I feel as system engineers we need to own. And now we're kind of beyond science. And we need to almost have something else. Now there is a thing called system science, which to me is kind of an oxymoron because a system is a synthesis of parts. Science looks at the parts. What is system science? You know? But to be fair, they've done a lot of work to try to bring systems into the scientific realm. And I think as system engineers, we're on the cross of leading this world into the systems age, which is what we're in right now. Everything is complicated and complication is one thing. But what about, you know, the whole idea of chaos and things like that. So it's it's more than complicated. We now have, you know, complexity and complexity. It's it's we're going to have to be the leaders to help them hone in that complexity. So system engineering is the key to the future. Sorry, but I really believe that we want a better world. We need a better system, engineers. And I'm just hoping UMBC can produce those system engineers that eventually can help create this better world. Wow. Sorry. No, that is philosophical, man. That's what I meant. I love that. Cause that kind of feeling, that kind of philosophical talk actually brings emotions to the surface and that things are powerful and that's where things are understood. And I want to thank you for expanding my mind and helping you to understand that the science behind things, but also this whole just concept that you just brought up about emergence and. Yeah. You know, I think it's true that everybody wants to make this world a better place in some way. I hope so. I appreciate that you brought to surface some of these concepts and ideas for us to be able to marinate on and think about and go forward in the world and really make sure that our actions count in making the world a better place. Yeah. Thank you so much for being here with us today. I really appreciate you taking the time to share your insights with us. They were really fascinating. No. Thank you so much for giving me this opportunity. I hope whoever joins us here at UMBC, we can all work together towards making what what we envision a better place. And thank you for giving me this opportunity. Appreciate it. Thank you for taking the time to listen to this episode of UMBC's Mic'D Up. We hope you enjoyed it. If you would like to learn more about UMBC's graduate program in systems engineering, please visit us at se.umbc.edu.