7 ms·
There's no real silver bullet other than applying the systems engineering process diligently. You start by writing down your user requirements (what the system
by jdiez17 5y ago
There's no real silver bullet other than applying the systems engineering process diligently. You start by writing down your user requirements (what the system needs to deliver), and you follow the thread of figuring out that "to do X, this subsystem has to provide conditions A, B, C..." recursively, in a breadth-first search. The level of detail codified in these functional, performance and interface requirements depends on the level of assurance you need.
Then, you need to validate that each requirement is met by your system. This can be done by test, analysis (mathematically proving some property), review of design, or inspection. It's true that you can't fully validate most space systems on Earth, because we can't simulate all environmental conditions simultaneously. That's why you ideally you want each requirement to be validated by two methods.
When you find anomalies due to integration effects, it's usually because your interface requirements are not specified well enough ;)
- peterburkimsher 5y agoI agree, it's a recursive search! Translated into software testing: "level of detail codified in functional, performance and interface requirements" functions, usage frequency, APIs. "usually because your interface requirements are not specified well enough" It's probably a bug in the API. https://martinfowler.com/bliki/TwoHardThings.html https://martinfowler.com/bliki/TwoHardThings.html "There are only two hard things in Computer Science: cache invalidation, naming things, and off-by-one errors" https://en.wikipedia.org/wiki/Ctags https://en.wikipedia.org/wiki/Ctags Suggestion: use ctags to list all functions, variable names in your code. Look for ambiguity (e.g. variable name "i"). Look at neighbouring code. Zoom in and out. A small bug in the most-used code is actually more serious than a big bug in code that rarely gets used. "How long can you work on making a routine task before you're spending more time than you save?" https://xkcd.com/1205/ https://xkcd.com/1205/
- ausbah 5y agothis level of rigor always makes me snicker at the engineering in "software engineering"
- markus_zhang 5y agoYou can probably snicker at most engineering in "X engineering".
- jl6 5y agoThis is how you are supposed to build software too.
- danielheath 5y agoWho supposed that? Broken software can be fixed cheaply after the fact. Yeah, it’s cheaper if you find the bugs earlier but it shouldn’t come as any surprise that pre-validation is more extensive in systems that are expensive to change.
- s1artibartfast 5y agoThere are lots of different types of software. There are phone note apps and control systems for jets and artificial hearts
- whimsicalism 5y agoAll that falls within the same paradigm, it's just now that now your user requirements have a little flexibility around fault tolerance. You still have SLAs to manage and meet.
- cortesoft 5y agoWhether you are “supposed” to do that or not really depends on what kind of software you are building.
- russtrotter 5y agoFair point, but the software that eventually ends up in flying space hardware has usually been put to a similar test.
- thelittleone 5y agoLikewise... I was pretty impressed with myself in the 90s as a young guy passing the Microsoft Certified Systems Engineer exam. "According to Encyclopedia Britannica, the first recorded 'engineer' was Imhotep. He happened to be the builder of the Step Pyramid at Ṣaqqārah, Egypt." [link] I look forward to drinking ale with Imhotep (and NASA JW Space Telescope engineers) in the great heavenly hall of engineers. https://interestingengineering.com/the-origin-of-the-word-engineering https://interestingengineering.com/the-origin-of-the-word-en...
- zppln 5y agoIs any of the systems documentation for any NASA project publicly available? As someone who spends a considerable amount of time sifting through systems documentation where the process hasn't been applied so diligently, I've always wanted to read a NASA SSDD or similar.
- nortlov 5y agoNot a specific project but relevant: https://www.nasa.gov/consortium/SystemsEngineeringManagementPlanTechnicalContent https://www.nasa.gov/consortium/SystemsEngineeringManagement...
- jes 5y agoYour description is a good one. My experience in industry is that we validate requirements when we confirm that they are necessary to achieving a particular mission. We then verify that the system under construction does in fact satisfy the set of validated requirements.
- jdiez17 5y agoTrue, verification is the correct term in this case :)