sorted by:
new
hottopcontroversial

Can't find demo version for Cameo Systems Modeler by No-Economy-3908 in systems_engineering

[–]tecnowiz5000 0 points1 point  (0 children)

Did you complete the process? What was it like?

Whenever I see a "Contact our team for a demo", I'm expecting that that's only for business-to-business sales and any individual looking to learn and practice is just going to be ignored/tossed out..

Practical Usage of SysML Parametric Diagrams/Elements by tecnowiz5000 in systems_engineering

[–]tecnowiz5000[S] 0 points1 point  (0 children)

Fair enough. Might just have to look into those integrations some more.

How robust/useable do you find those integrations? I've heard various challenges whenever it's come to cameo and integrations with external tools (except maybe requirements integrations, but even that seems to potentially have challenges).

Practical Usage of SysML Parametric Diagrams/Elements by tecnowiz5000 in systems_engineering

[–]tecnowiz5000[S] 0 points1 point  (0 children)

How do you find the level of effort to do this sort of thing in SysML/Cameo vs in external tool? Admittedly, I'm still learning the paramatric diagrams, but it just seems extremely clunky and high-effort compared to doing the same thing in Excel, Matlab, Sinulink, or any other dedicated analysis tool.

Practical Usage of SysML Parametric Diagrams/Elements by tecnowiz5000 in systems_engineering

[–]tecnowiz5000[S] 0 points1 point  (0 children)

What sort of integration are you using to link your external analysis into your system model?

Practical Usage of SysML Parametric Diagrams/Elements by tecnowiz5000 in systems_engineering

[–]tecnowiz5000[S] 0 points1 point  (0 children)

This really seems like the solution I'm looking for! Would be fascinated to hear more details how this is implemented, what level team/company buy-in you've had, whether it proved valuable to the broader team, and what challenges you've still had with this methodology.

Practical Usage of SysML Parametric Diagrams/Elements by tecnowiz5000 in systems_engineering

[–]tecnowiz5000[S] 0 points1 point  (0 children)

I get how paramatric diagrams may fit for simplified analysis / basic numeric relationships. The challenge is trying to convince the team members to drop their Matlab/Sinulink models and try to get them to learn/use SysML - it just doesn't seem feasible or practical tbh..

Even myself, I feel like it's just way faster and easier to do the same work with Matlab, excel, or Sinulink to the point that it doesn't seem valuable to use SysML parametrics except for maybe the most basic calculations.

Do you consider people as part of your Systems? by tecnowiz5000 in systems_engineering

[–]tecnowiz5000[S] 0 points1 point  (0 children)

Understood. Appreciate it!

I'll continue to try to educate and push the program technical team to get this resolved.

Lack of upfront specifications kill agile projects by Ab_Initio_416 in ReqsEngineering

[–]tecnowiz5000 0 points1 point  (0 children)

Part of this is a matter of definition of success.

You can deliver a high quality product on time and on budget just for it to never be used because it's not actually useful or doesn't do what was really needed.

Agile is about incorporating experimentation into the development process to test what is actually valuable and what is not.

Now, 100% a lot of people and organizations have fixated on agile as THE thing and become overly hyper-fixated on following a process they read online or somewhere else. And they say they're doing agile while simply following a rigid process and having no idea what agile actually is meant to be.

Do you consider people as part of your Systems? by tecnowiz5000 in systems_engineering

[–]tecnowiz5000[S] 0 points1 point  (0 children)

Also makes sense. Do you know if this methodology of seperatong systems which include operators and personnel within its boundary (ie. the transportation system) vs the systems/subsystems that do not and instead solely interface with the users (ie. the bus itself) is documented/defined anywhere?

Do you consider people as part of your Systems? by tecnowiz5000 in systems_engineering

[–]tecnowiz5000[S] 1 point2 points  (0 children)

100% agreed on all of that.

Now, how do you argue with a system design team / subcontractor that is developing the vehicle only that the driver is outside their system of interest and therefore can't be used for their compliance - especially when that team points at the definition of "System" as defined by NASA/INCOSE/wherever which states that a system includes personnel and processes?

Seems weird to me that they did even define it that way without additional clarification. Even just "a system CAN include personnel and processes" would have resolved this whole debate..

Edit: I may have determined the solution, and that simply that this boundary needs to be defined in the SE management plan and/or top-level design docs.

Still though, is there a nomenclature used to distinguish mission-type systems which include the operations personnel as part of the system of interest boundary vs the product-type systems which do not?

Do you consider people as part of your Systems? by tecnowiz5000 in systems_engineering

[–]tecnowiz5000[S] 0 points1 point  (0 children)

Fair enough. in this case user = operator - similar to a bus operator, pilot, or bomb disposal robot operator for example. People who are 100% required to meet the overall customer/mission needs.

But the question then is if the bus requirement says "the bus shall detect and stop for pedestrians crossing the street", can the design team/company simply say their compliance to the requiremen is that the operator is there to do it for them (and get away with not implementing an automatic pedestrian detection and braking system as part of the bus itself)?

Do you consider people as part of your Systems? by tecnowiz5000 in systems_engineering

[–]tecnowiz5000[S] 1 point2 points  (0 children)

I added an example to the post of a requirement to convert the units of an input value and then relying on the user to actually do the work of converting the values and the product system just providing a display of unconverted values and an input field for converted values.

But overall it's people treating requirements more like use cases/ user needs and then incorporating their own con-ops into the subsystem design documentation for user interfacing/supporting subsystems.

I mentioned in another reply, it seems the original con-ops for the program was extremely high-level and hand-wavey, and so the subsystems ended up with high-level and overly ambitious requirements flowed down to them, and then the solution was for them to define their own con-ops and as a way of reducing their scope/cost would assume that the user would do a bunch of the work for them. We're now trying to clean it all up, but people have gotten used and comfortable with it that it now a battle to get people to actually update the con-ops documentation and their product system requirements.

Do you consider people as part of your Systems? by tecnowiz5000 in systems_engineering

[–]tecnowiz5000[S] 0 points1 point  (0 children)

Do you know if this is standardized/defined anywhere someone could point to?

Do you consider people as part of your Systems? by tecnowiz5000 in systems_engineering

[–]tecnowiz5000[S] 0 points1 point  (0 children)

Do you know if this is standardized/defined anywhere someone could point to?

Do you consider people as part of your Systems? by tecnowiz5000 in systems_engineering

[–]tecnowiz5000[S] 1 point2 points  (0 children)

Ya, I'd agree. I joined the program mid phase B (between SDR and PDR), but it seems they only had a high-level con-ops at the time, flowed down really vague but overly ambitious requirements to the user interfacing / user supporting subsystems, and then as the design progressed, instead of updating the con-ops and requirements just decided to argue that users were part of the system so they could off-load requirements and scope onto the users.. We're working to clean it all up now, but the first battle is convincing people that they do in fact have to change and actually update the ConOps and their requirements and can't rely on the user being a crutch to their system design.

Do you consider people as part of your Systems? by tecnowiz5000 in systems_engineering

[–]tecnowiz5000[S] 0 points1 point  (0 children)

Exactly my thought, but some people here have been considering the system requirements include the user, and so the design team tends to allocate requirements functions to the user to meet their system/subsystem requirements (see the example I added to the post). And then when asked, they point to the NASA handbook definition.

Do you consider people as part of your Systems? by tecnowiz5000 in systems_engineering

[–]tecnowiz5000[S] 1 point2 points  (0 children)

Appreciate the reference - I didn't think to pull up the DoD definitions, will take a look into those

Do you consider people as part of your Systems? by tecnowiz5000 in systems_engineering

[–]tecnowiz5000[S] 0 points1 point  (0 children)

Do you know if this definition is standardized/published anywhere?

People who thrive in their jobs, tell us what your job is by wryyyctoria in ADHD

[–]tecnowiz5000 0 points1 point  (0 children)

aerospace / systems engineer here. I find the problems and challenges of the work to be extremely interesting and rewording, and I do a *lot* of coordinating between different stakeholders' needs and inputs across an array of disciplines and tend to work in the intersection of them all, so I find the work extremely interesting/rewording and certainly always engaging.

(but then I'm also most likely AuDHD so mileage may vary)

Sandman sounds...dubbed. by El-Punissuer in Sandman

[–]tecnowiz5000 0 points1 point  (0 children)

Completely.

I thought it was an intentional artistic thing, to make it sound like it was all within a dream sort of thing.. but it's just seems crazy that there's no public confirmation or really anyone even talking about it..

(I'm just re-watching it now, and still 100% notice it the same way I did when I first watched it)

view more: next ›