Just a note: systems engineering at NASA has it's own internal definition that is closer to a management role than a technical one. Source: am NASA engineer.
The NASA definition the original one, I would think. How are people using "systems engineering" as a term elsewhere, that is incongruent with the NASA definition?
I mean, a "system" at the scale of a NASA project comprises operationalized learning across both machines and people (and supplier-contracts, and legal corporate entities.) With tolerances and maintenance plans and backups for the people-parts as well as the machine-parts of the system.
I don't know if I would describe the design of such a system as "management"; it's more akin to the sort of incentive-system creation that tax regulators or MMO game designers go through, but with a lot more rigor and data.
Can confirm, any 'real world' engineering will use the NASA definition. The best way I've found to understand systems engineering is in how my org implements them - a project has a systems engineer and a project manager working alongside each other. They have small overlaps but by and large, the PM is responsible for the non-technical management of the project whereas the SE is responsible for the technical management. This encompasses scope definition, requirements specification, system and subsystem interfaces, testing and verification regimes, etc. etc.
They take the intangible requirements of the client and beat them into a robust series of defintiions that outline what the whole raft of pieces that must assemble together to perform that duty must do, and then also confirm it does indeed meet the client needs. Meanwhile, the PM makes sure the team delivers on time, within budget, with the right organisational oversights to confirm processes are followed, quality management is maintained, etc.
I think NASA's use of "systems engineering" is more or less in line with how everyone except the software industry uses "systems engineering". You'll sometimes (not always) see "systems engineering" in the software industry refer to operating systems, or operating system like stuff (for example, game engines, certain types of real time application, etc). You'll also see it called 'systems programming'. In that context, I can understand why the standard systems engineering role might be considered more 'managementish'.
In most large roles, systems engineers are at least one step removed from the majority of design. In many ways, he works on an abstraction layer of the design, but also provides abstraction layers to the other engineers he works with or DIRECTS.
I graduated from a "systems design engineering" program. In it, we had courses in human factors, mechanical engineering, electrical/computer engineering, graph theory, software development, and you could branch out from there as you wanted.
Unfortunately, people seem to think that it means I'm a software developer, in IT, or something along those lines. It's quite unfortunate as both my Master's and Ph.D. were more towards mechanical engineering.
Unless you're working in the Aerospace & Defense, Healthcare Device, or Automotive industries this will continue to be a problem for some time.
It's okay to use equivalent language when seeking out jobs. Try looking for "product design" or "product management" roles that emphasize technical competency.
Reach out to INCOSE and IISE professional organizations for help. Those organizations exist to represent your skill set to industry. Challenge them to improve recruiter and human resources recognition of the term "Systems Engineer".
I didn't know about INCOSE or IISE, so thanks. I've been a member of ASME since I was presenting at their conferences and submitting to their journals as a grad student given the material was focused on mechanical (and textile) engineering. I didn't look for any dedicated systems organizations.
Product Management is what most of our graduates end up doing, but they're usually doing it in software jobs. That said, we have a number of patent and IP lawyers come out of our program and a lot of people go into medicine or biomedical. The latter since we have a dedicated biomedical option as we have a number of faculty in that area.
Yes, I did. In fact, if you're a recent grad you probably had me as your TA at some point as I was a TA throughout most of my grad school and did core courses.
I am a 'systems engineer' for an ISP and my role is a combination of two things 1. software development for distributed programs that manage the network 2. sys admin type things
That's what most software people think my "systems design engineering" degrees are about, but my program fits the NASA definition much better. It's quite frustrating.
> The NASA definition the original one, I would think. How are people using "systems engineering" as a term elsewhere, that is incongruent with the NASA definition?
The term has been co-opted by people in IT doing (I think) operations type work.
It certainly makes a job search much more frustrating since the number of IT positions greatly outnumbers those for the traditional definition.
I'm a former NASA Engineer, Systems Engineer, and Project Manager (via JPL). If you're making the assertion that a Systems Engineer exhibits some of the leadership responsibilities as that of a traditional Project Manager, then I'd agree. If not, then I'd recommend you find an expert Systems Engineer (or CogE or Principal Scientist or even your Line Manager) in your field and ask him/her to mentor you. You could be missing much of the experience.
Thanks for the clarification. I was rather confused with the subject matter of this handbook without that knowledge. I guess I shouldn't have glossed over the introduction and jumped to what looked meaty.
SysML is a modeling language, similar to UML, that some organizations use for Systems Engineering http://sysml.org
Model Based Systems Engineering (MBSE) is the general term for modeling systems (for example with SysML) and then applying computer analysis tools to those models to perform Systems Engineering optimizations.
Google Project Ara made use of MetaMorph Software Tools to help module designers perform PCB layout, component integration, module pricing estimation, package fit check, module performance, and specification compliance. See http://www.metamorphsoftware.com and https://webgme.org
In general, there is a lot of opportunity to modernize MBSE tools and bring them to a wider audience.
Modelica (https://www.modelica.org) is another useful option for MBSE that has more commercial front-ends than one can shake a stick at (e.g., CATIA and Wolfram SystemModeler), as well as free options.
OpenMDAO is very much an option, though it is geared more for model-based analysis and numerical optimization for highly integrated systems. The primary use case is to assist in early conceptual design, particularly for vehicles. But basically, it's a Python framework for passing variables, functions, and derivatives of functions around between disparate codes.
In practice, the most common systems engineering tools that I've seen are actually excel and powerpoint. Not knocking either of those tools (or the role of systems engineer), but that seems to be the current state of the field.
For smaller projects (say, what an engineer might run and manage by themselves), there's always Microsoft Project. That's the lower level default for making/managing schedules.
For much larger projects, or projects of projects (think large engineering systems of systems that take years to design/build/test/deploy), there's all kinds of software available. My company uses Oracle Primavera for this sort of thing.
Also, don't forget Excel. Excel is everywhere and used for all sorts of things it probably shouldn't be used for.
The civil engineering department at my university doesn't have any dedicated programming or numerical analysis course. So, they're taught to use Excel. I took a structural dynamics grad course from them and the instructor explained how to do an explicit ODE solution using Excel. I was horrified. I just asked if I could use Matlab and the prof said yes. The prof just used Excel because that's all the undergrads (and therefore the new grad students) knew.
A key reason Excel is the default is that people have access to it, while Matlab is prohibitively expensive.
One way to break that trend is to choose GNU Octave, the open source alternative to Matlab. The more widely GNU Octave gets used (or similar free tools) the more likely we are to move beyond an Excel by default engineering culture. GNU Octave covers a large percentage of Matlab features and is able to run Matlab code. https://www.gnu.org/software/octave/
There are other tools, like SageMath, that are built on Python and may make an even better Excel alternative for organization that aren't dependent on legacy libraries of Matlab code.
I'm a systems design engineer so there was no way I'd use Excel for ODE solving unless I had no other choice. Matlab and Maple are the two languages I know best, but I'd also consider Fortran, Octave, Python, or Scilab for something like that, with C++ probably last (C++ for numerics is a pain since you have to convert between different packages for basic types like matrices and vectors). I'd probably also consider Julia, but I'm not that familiar with it yet. I had hopes for Fortress, but that died a quick death.
I've been a part of the SymPy team for several years including mentoring GSoC for two of those years.
The problem with SageMath is that you still have to convince people who are familiar with Excel to learn a new environment. Part of the reason why Excel is taught to the undergrads in that civil engineering program is that they use it in their co-op jobs. It becomes a self-perpetuating cycle since they don't learn any alternative as students so they go with what they know in their jobs.
In the handbook, Figure 2.0‐1 "SE in context of overall project management" shows the relationship between systems engineering and project management. While some SE responsibilities overlap with those of project management, the larger set of responsibilities focus on technical work. Microsoft Project isn't intended to be used to define requirements, perform technical trade studies, model and compare alternative system architectures, or configuration manage technical artifacts of the engineering process.
Hope that helps to clarify my prior comment. Happy to discuss more.
> Microsoft Project isn't intended to be used to define requirements, perform technical trade studies, model and compare alternative system architectures, or configuration manage technical artifacts of the engineering process.
I never meant to imply that Microsoft Project is a suitable tool for aiding in any of these things. Anyone crazy enough to try...
But if you want to make a Gantt chart, Project does well enough. The NASA systems engineers I knew certainly used Project for that purpose. Thus I hardly think you can say that it "isn't suitable for systems engineering" as it is useful in creating/viewing/editing one of the key tools of a system engineer's work -- a project schedule.
Now that's waterfall design. Show that to your scrum master.
Really. This is a manual for waterfall design of large, complex, one-off or small-quantity systems. Bridges and buildings are designed this way. It's slow, but it works. Errors in the requirements are really expensive to fix.
Of course - it's just the nature of the medium. With software you can be be far more agile because you aren't making extremely expensive physical parts that take days to months to re-fabricate or modify every time you want to make a change.
