Formal Software Engineering?
-
I been through dozen places in my time, everyone is talking about it, even have policies written enforcing that they practice it, but when comes to the metal, a few actually do what they claimed. Most places where they called themselves fast-pace and agile are examples of not doing what was preached. Does any place(shop) doing formal software engineering? Formal requirement, formal specification (yes I meant the difference documents in requirement and specification), formal design(UML stuff), code and more importantly formal software quality assurance. I know few places where they do them to concur with laws or government regulations. Share your shop's experience.
The most 'formal' development team I've heard of would be the former NASA Space Shuttle software group. I've read a couple of articles about their practices, which were stringent and regimented to a degree hard to believe.
Software Zen:
delete this; -
The most 'formal' development team I've heard of would be the former NASA Space Shuttle software group. I've read a couple of articles about their practices, which were stringent and regimented to a degree hard to believe.
Software Zen:
delete this;I've read about them too and can understand why they would have to be that regimented. I mean, a bug in the software at most places means someone doesn't get a correct paycheck or something but with that software a bug might mean someone dies!
-
Kevin Marois wrote:
we're doing Agile and have a very detailed documentation process.
Illegal!!! Agile does not allow documentation!!! Yes, this was a troll. Except I'm kind of serious. The code is the documentation in Agile. This message is only to create controversy which requires you to reply. However, in replying you will fail. Please reply soon. Yes, I'm kidding. :laugh:
Quote from Manifesto for Agile Software Development[^] "Working software over comprehensive documentation"
-
I been through dozen places in my time, everyone is talking about it, even have policies written enforcing that they practice it, but when comes to the metal, a few actually do what they claimed. Most places where they called themselves fast-pace and agile are examples of not doing what was preached. Does any place(shop) doing formal software engineering? Formal requirement, formal specification (yes I meant the difference documents in requirement and specification), formal design(UML stuff), code and more importantly formal software quality assurance. I know few places where they do them to concur with laws or government regulations. Share your shop's experience.
-
Quote from Manifesto for Agile Software Development[^] "Working software over comprehensive documentation"
-
I been through dozen places in my time, everyone is talking about it, even have policies written enforcing that they practice it, but when comes to the metal, a few actually do what they claimed. Most places where they called themselves fast-pace and agile are examples of not doing what was preached. Does any place(shop) doing formal software engineering? Formal requirement, formal specification (yes I meant the difference documents in requirement and specification), formal design(UML stuff), code and more importantly formal software quality assurance. I know few places where they do them to concur with laws or government regulations. Share your shop's experience.
Others mentioned that most places fall on the spectrum from 0.99% and I would agree. In our line of work, we are often asked to bid a project with incomplete details. We have clients who "don't understand a wireframe" as we walk them through it! Or worse, they okay the wireframe, and then scream when the product works in a similar fashion... Because they were not paying attention, or could not understand it. Most of our projects are 3 months in duration. We do formal code reviews. We do Post-Mortems and we do very little documentation (outside of project documentation). We have a small stable team. But we would not win a bid too often if we had to write a ton of documentation, and do a complete spec review before we ever started. And we had a change management system that worked its way up and down the management chain in order to get things done. So, I will argue that You SHOULD see a range. Based on what is needed. What the customer wants. And the risk of failure or errors. If errors kill people, then I would imagine a stringent process. In the end, our clients trust us to deliver what they NEED and listen to the end-users over the managers (who usually have no idea what their employees ACTUALLY do). Which is no different the those who manage programmers ;-)
-
I been through dozen places in my time, everyone is talking about it, even have policies written enforcing that they practice it, but when comes to the metal, a few actually do what they claimed. Most places where they called themselves fast-pace and agile are examples of not doing what was preached. Does any place(shop) doing formal software engineering? Formal requirement, formal specification (yes I meant the difference documents in requirement and specification), formal design(UML stuff), code and more importantly formal software quality assurance. I know few places where they do them to concur with laws or government regulations. Share your shop's experience.
I've only done that once, when the dev team I was on was given complete freedom in design and implementation of a project. We decided to go that UML design route, starting with stories, then sequence diagrams, then more formalities. It was a fun experience, but it delayed us finding out that our purely OOP reporting system was as slow as all hell, where with an agile approach would have taken about two weeks to find that out.
Follow my adventures with .NET Core at my new blog, Erisia Information Services.
-
I been through dozen places in my time, everyone is talking about it, even have policies written enforcing that they practice it, but when comes to the metal, a few actually do what they claimed. Most places where they called themselves fast-pace and agile are examples of not doing what was preached. Does any place(shop) doing formal software engineering? Formal requirement, formal specification (yes I meant the difference documents in requirement and specification), formal design(UML stuff), code and more importantly formal software quality assurance. I know few places where they do them to concur with laws or government regulations. Share your shop's experience.
I've never seen it. Starting to doubt it's even real!
-
I been through dozen places in my time, everyone is talking about it, even have policies written enforcing that they practice it, but when comes to the metal, a few actually do what they claimed. Most places where they called themselves fast-pace and agile are examples of not doing what was preached. Does any place(shop) doing formal software engineering? Formal requirement, formal specification (yes I meant the difference documents in requirement and specification), formal design(UML stuff), code and more importantly formal software quality assurance. I know few places where they do them to concur with laws or government regulations. Share your shop's experience.
-
I been through dozen places in my time, everyone is talking about it, even have policies written enforcing that they practice it, but when comes to the metal, a few actually do what they claimed. Most places where they called themselves fast-pace and agile are examples of not doing what was preached. Does any place(shop) doing formal software engineering? Formal requirement, formal specification (yes I meant the difference documents in requirement and specification), formal design(UML stuff), code and more importantly formal software quality assurance. I know few places where they do them to concur with laws or government regulations. Share your shop's experience.
Yes, been there, done that, safety critical software to DO178 Level A (so that's aerospace software - flight software specifically). Yes, formal requiremenymts and design (plus full traceability from requirements down through design, code and up through unit test, requirements test and validation). The most stringent part is verification - peer review of all artefacts, unit test with 100% coverage of statements, branches, decisions and as high as possible with MC/DC (modified condition/decision coverage). Oh, and coverage from source to object code because the (Ada) compiler isn't formally qualified. Don't do that now, but still have close contact with it - it's expensive, but it's what's required by the standards...
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
-
I been through dozen places in my time, everyone is talking about it, even have policies written enforcing that they practice it, but when comes to the metal, a few actually do what they claimed. Most places where they called themselves fast-pace and agile are examples of not doing what was preached. Does any place(shop) doing formal software engineering? Formal requirement, formal specification (yes I meant the difference documents in requirement and specification), formal design(UML stuff), code and more importantly formal software quality assurance. I know few places where they do them to concur with laws or government regulations. Share your shop's experience.
Formality seldom survives the first missed deadline. Software engineering is not a programmer's term; it is a manager's term.
-
I been through dozen places in my time, everyone is talking about it, even have policies written enforcing that they practice it, but when comes to the metal, a few actually do what they claimed. Most places where they called themselves fast-pace and agile are examples of not doing what was preached. Does any place(shop) doing formal software engineering? Formal requirement, formal specification (yes I meant the difference documents in requirement and specification), formal design(UML stuff), code and more importantly formal software quality assurance. I know few places where they do them to concur with laws or government regulations. Share your shop's experience.
It is often overseen that a users does not use software like she/he uses a car but uses the services that the software "produces" together with other components like devices, clouds, etc. So software is part of a production site that generates the IT-Services the user needs to run her/his tasks better and more efficiently. So when looking for professionalism in IT-services the first and most important question is what quality of service the user needs to get the wanted benefit out of that IT-service. And the whole process to define, engineer, develop, deploy and run the production site that delivers the IT-service as "promised" is much more complex than the formal software engineering process delivers today. SO what we need is a formalized approach in Business Analysis that is also delivers quality criteria relevant to the user and not only functional specifications. This is far apart from being a trivial task.
Best regards UP
-
I been through dozen places in my time, everyone is talking about it, even have policies written enforcing that they practice it, but when comes to the metal, a few actually do what they claimed. Most places where they called themselves fast-pace and agile are examples of not doing what was preached. Does any place(shop) doing formal software engineering? Formal requirement, formal specification (yes I meant the difference documents in requirement and specification), formal design(UML stuff), code and more importantly formal software quality assurance. I know few places where they do them to concur with laws or government regulations. Share your shop's experience.
Sure. In government or military contracts. Mostly what we produce is a _huge_ pile of documentation showing how no taxpayers money was wasted (not including producing said huge pile of documentation). The unstated aim is to move money from the public sector into the private. An actual working product at the end is pretty much an afterthought. Or if it's a working product, then it's not what the users want - rather what the users bosses they _said_ they wanted several years ago, which leads to the next contract. That's not to say formal specs don't have their place. Many medical devices will have formal specs due to the risk that lives could be lost if there's a serious bug.
-
Book A. Introduction - NASA Software Engineering Handbook - NASA Software Engineering Handbook[^]
"(I) am amazed to see myself here rather than there ... now rather than then". ― Blaise Pascal
-
Sure. In government or military contracts. Mostly what we produce is a _huge_ pile of documentation showing how no taxpayers money was wasted (not including producing said huge pile of documentation). The unstated aim is to move money from the public sector into the private. An actual working product at the end is pretty much an afterthought. Or if it's a working product, then it's not what the users want - rather what the users bosses they _said_ they wanted several years ago, which leads to the next contract. That's not to say formal specs don't have their place. Many medical devices will have formal specs due to the risk that lives could be lost if there's a serious bug.
Government contractor here, and I can concur. A colleague of mine often points out that the the documentation we produce must produce stacks of paper that are tall enough that we can use them to build a fortress to protect ourselves when the auditors attack the castle. :laugh: I produced a 1000-page ATR just last month (I didn't actually print it out, though). Having said that though, I should also mention that I am on a team that is introducing Agile methodology to this heavily waterfall-dominated workplace, and we are making some real headway. One of the keys that has helped us a lot is the use of quality tools: Jama for requirements development, JIRA for issue tracking, etc. Introducing these tools has really helped us to start enjoying the best of both worlds. (That 1000-pg ATR, for example, was automatically generated from our Jama repository.)
-
Wow, I had never come across that resource before. That thing is a monster! -- and a bit scary too! It must have taken years to produce.
Truly. I was most impressed by their "Tools Table"... I think it says something but I'm not exactly sure what. (Reminds me of my toolbox ... the one in the garage). [Tools Table - NASA Software Engineering Handbook - NASA Software Engineering Handbook](https://swehb.nasa.gov/display/7150/Tools+Table)
"(I) am amazed to see myself here rather than there ... now rather than then". ― Blaise Pascal