101–110 of 134 posts
Let the product owner (PO) handle them. The PO has to make the hard decision about what to work on and when. He/She must understand the product deeply and be able to make the hard decisions. Also the PO should be able to test the system to accept the changes. Furthermore. You don't really need to have endless lists of requirements. The most important thing to know is what is the next thing that you have to work on.
This is a LOT to put on a PO. I hope they have help.
Used that 15-20 years ago and loved it. Any present day insight on this?
Earlier quoted context omitted.
Just wanted to ask, this pretty much ensures you're doing waterfall development, as opposed to agile, right?
Actually most functional safety projects use the v-model (or similar, topography can vary a little as to needs), which is waterfall laid out a slightly different way to more clearly show how verification and validation closes out all the way back to requirements with high degrees of traceabilty. I've always wanted to break that approach for something a little more nimble, probably by use of tools - but I can't see ag…
I review software for at least 3-5 companies per week as part of FDA submission packages. The FDA requirements require traceability between reqs and the validation. While many small companies just use excel spreadsheets for traceability, the majority of large companies seem to use JIRA tickets alongside confluence. While those arent the only methods, they seem to be 90% of the packages I review.
We have been working software for FDA submissions as well. We use Jama https://www.jamasoftware.com/ for requirements management and traceability to test cases.
In a safety-critical industry, requirements tracking is very important. At my current employer, all of our software has to be developed and verified in accordance with DO-178 [0]. We have a dedicated systems engineering team who develop the system requirements from which we, the software development team, develop the software requirements; we have a dedicated software verification team (separate from the development…
Well… the 737MAX seems to suggest it doesn’t catch all the bugs.
We're an FDA regulated medical device startup, with a pretty low budget for the moment. Our current setup is two pronged, in-house, and automated. The first piece is the specification documents, which are simple word docs with a predictable format. These cover how the software SHOULD be implemented. From these documents, we automatically generate the mission critical code, which ensures it matches what we say it does…
I have an unexposed WIP type of cell that is a rich text document. The rich document you edit has corresponding code, which you can also edit in the other direction. (screenshot https://mobile.twitter.com/InflexHQ/status/14923564133263360...) The neat part is that I added the ability to embed a “portal” to display another cell, such as a number or a table, which can be edited inside the rich text doc or at the cell’s origin. For tutorials, I figured it would also be nice to display the source code of a given cell in a rich editor. E.g.
The formula [plasma * 3.23224 + alpha] yields [7.289221].
You could edit the text (The Formula ... yields ...), or the formula and see the result.
Finally, the rich editor is already in a format ready to be printed as a PDF or Word doc.
Also, the source code being the source of truth means it’s very easy to version the whole system down to SHA512 hashes.
This could unify a use-case like yours, where you have the Google Doc and the Google Sheet bridged by Python, this would cut down that iteration feedback loop.
Being content addressable means that only tests that need to run would be run (see Unison lang), rather than running all tests every time, further cutting down on the feedback loop.
One question that comes to mind is: what if you could export code in the spreadsheet as a general purpose language like C or Python? Or even Lua? Also, would an on-prem/desktop version of the product would be valuable for this use case?
Thanks for the food for thought. This is a niche I never considered! And I’ve worked on a medical device for Amgen before! I forgot all about this.
Earlier quoted context omitted.
Well… the 737MAX seems to suggest it doesn’t catch all the bugs.
AFAIK the bugs were caught, known about, and deliberately ignored. In fact even when the bug caused a fatal error that brought an instance crashing (to the ground, literally!), it was ignored both by Boeing and the US government.
which sounds reckless, after all if you make a system more complicated by introducing a "feature" at least try to make it fail gracefully, etc, etc.
then you learn that this glorious safety critical software thing thing was fed by one single angle-of-attack measurement device (oh and to make the system even more mystical the planes had two of these digitalized wind detector flappy flaps, but only one was active, and it switched on reboots, so if one pilot noticed that the system was behaving badly, and then the second one noticed that it was great after all ... the third one had no clue what to expect!)
:|
Earlier quoted context omitted.
This actually has a nugget of wisdom. I wish I was more open to soaking up wisdom - and less likely to argue a point - when I was a junior dev. Or still now, really. Moreover, if your PO can't define the goals, and what needs to be tested to get there, well you have a problem. Assuming the team is committed to some form of Agile and you have such a thing as a PO. However, I also disagree with the main thrust of this…
> Moreover, if your PO can't define the goals, and what needs to be tested to get there, well you have a problem. In some work environments, there may be unspoken requirements, or requirements that the people who want the work done don't know they have. For example, in an online shopping business the head of marketing wants to be able to allocate a free gift to every customer's first order. That's a nice simple busin…
In my experience, engineer does it as part of implementation until they burn out and just YOLOs and leaves them for bug reports :p
But to be more serious, I don’t think this is POs or one persons job. This is exactly why engineers should learn about their domain.
Earlier quoted context omitted.
Well… the 737MAX seems to suggest it doesn’t catch all the bugs.
AFAIK the bugs were caught, known about, and deliberately ignored. In fact even when the bug caused a fatal error that brought an instance crashing (to the ground, literally!), it was ignored both by Boeing and the US government.
Here's an excerpt from the article...
--- “No, again, we provide all the information that’s needed to safely fly our airplanes,” he answered.
Bartiromo pressed: But was that information available to the pilots? “Yeah, that’s part of the training manual, it’s an existing procedure,” Muilenburg said.
“Oh, I see,” she said. But in fact, MCAS wasn’t in the manual, unless you counted the glossary, which defined the term but didn’t explain what the software did. ---
A safety critical feature that can down a plane if not disabled in time... tucked away in a glossary.
The documentary 'Downfall: The Case Against Boeing' goes into great detail about the whole ordeal.
1. Requirements first written in Excel, later imported to Jama and later imported to HP QC/ALM for manual tests
Pros: Test reports in HP QC helped protected against an IT solution which was not on par with what needed and requested
Cons: Tests where not helping the delivery - only used as a "defence", requirements got stale, overall cumbersome to keep two IT systems (Jama, HP QC) up to date
---
2. Jira for implementation stories, with some manual regression tests in TestRail and automated regression tests with no links besides Jira issue ID in commit Polarion was used by hardware and firmware teams but not software teams.
Pros: Having a structured test suite in TestRail aided my work on doing release testing, more lightweight than #1
Cons: Lots of old tests never got removed/updated, no links to requirements in Jira/Polarion for all tests (thereby losing traceability)
---
3. Jira with Zephyr test management plugin for manual tests, automated tests with no links besides Jira issue ID in commit
Pros: Relative lightweight process, since plugin to Jira was used
Cons: Test cases in Zephyr was not updated enough by previous team members
---
4. Enterprise tester for requirements/test plans, Katalon for e2e tests by separate QA team With automatic tests with Jira issue ID in commit (no links to Enterprise tester) inside team
Pros: Again, rather lightweight when it comes to automated regression tests inside team
Cons: Process not optimal, Enterprise tester only for documentation but no actual testing
---
Today, there are good practices which helps building quality in - DevOps, GitOps, automatic tests (on several levels), statistical code analysis, metrics from productions... Try to leverage those to help guide what tests needs to be written.
Many times requirements/user stories are incomplete, no longer valid or simply wrong. Or a PO may lack some written communication skills.
Overall, I want to focus on delivering value (mainly through working software) rather than documenting too much so I prefer a lightweight process - issue ID on commit with the automated tests. Bonus points if you use eg markers/tags/whatever in test framework like JUnit/pytest to group and link to eg Jira issue ID.