Entire projects and/or companies could go down the drain (or take years to recover from that). Innovative designs are hard to estimate (estimation frequently is based on experience from the past and if the design is new, there is no experience to "reuse"). Read a novel here:
https://en.wikipedia.org/wiki/Rolls-Royce_RB211
On the other side, why would you want to innovate? To be faster, or to be more (fuel) efficient, to be more reliable, etc. In one word: to gain new customers.
Mostrar mensagens com a etiqueta Project Failures. Mostrar todas as mensagens
Mostrar mensagens com a etiqueta Project Failures. Mostrar todas as mensagens
quarta-feira, 11 de outubro de 2017
sexta-feira, 29 de setembro de 2017
On the importance of interface specifications (ICD)
On the importance of interface specifications (doing it and then... following it). Lots of systems fail due to interfaces to external systems. What is an external system? In this context, anything where you'll have to read data from and/or export / write data to.
In some projects/markets these are mandatory deliverables (the designation and the acronym can vary): SIS (Software Interface Specification), ICS (Interface Control Specification), ICD (Interface Control Document). The interface specification can be a document by itself or part of the broader design documentation (a section of it). The advantage of having it extracted is that it is easier to share externally (you'll have to share just that part of the design with external companies and that eases up distribution issues for organizations that restrict distribution).
As per the external interfaces by themselves:
Identify all intervening external systems and specify the needed interfaces thoroughly: specify the data flows, frequency and means of communication, review and accept those documents so that all teams (persons) working for all components of the information system are aligned.
Case study / example (on the importance of interface specifications):
The Mars Climate Orbiter is one of the many failed Mars missions. It crash landed in Mars in 1999:
PS. The full NASA 1998 report can be found here:
In some projects/markets these are mandatory deliverables (the designation and the acronym can vary): SIS (Software Interface Specification), ICS (Interface Control Specification), ICD (Interface Control Document). The interface specification can be a document by itself or part of the broader design documentation (a section of it). The advantage of having it extracted is that it is easier to share externally (you'll have to share just that part of the design with external companies and that eases up distribution issues for organizations that restrict distribution).
As per the external interfaces by themselves:
Identify all intervening external systems and specify the needed interfaces thoroughly: specify the data flows, frequency and means of communication, review and accept those documents so that all teams (persons) working for all components of the information system are aligned.
Case study / example (on the importance of interface specifications):
The Mars Climate Orbiter is one of the many failed Mars missions. It crash landed in Mars in 1999:
"The primary cause of this discrepancy was that one piece of ground software supplied by Lockheed Martin produced results in a United States customary unit, contrary to its Software Interface Specification (SIS), while a second system, supplied by NASA, expected those results to be in metric units, in accordance with the SIS."They had a spec, they just didn't read it. Or even worse, they produced contradicting documentation.
PS. The full NASA 1998 report can be found here:
terça-feira, 25 de julho de 2017
The F-35 (software) saga
Talking about pressure to deliver? Read below:
https://www.theregister.co.uk/2017/07/25/f35_software_block_3f_complete_end_2017_says_lockheed/
https://www.theregister.co.uk/2017/07/25/f35_software_block_3f_complete_end_2017_says_lockheed/
Quoting:
"Meanwhile, the Pentagon's director of operational test and evaluation told a US Congress committee earlier this year that the aircraft won't be ready before 2019, mentioning 158 "Category 1" software flaws that could cause death, severe injury or illness unless fixed.
"Meanwhile, the Pentagon's director of operational test and evaluation told a US Congress committee earlier this year that the aircraft won't be ready before 2019, mentioning 158 "Category 1" software flaws that could cause death, severe injury or illness unless fixed.
The USAF hit back at these reports, announcing in May that Block 3F would be ready by "September or October" this year. Block 4 is said to be already in development, in spite of the delays to Block 3F. New software "drops" will be rolled out about every two years, with Block 4 scheduled for the beginning of the 2020s."
(...)
"The paper also pegged the cost of each aircraft at around £198m, though post-publication commentary appeared to suggest that the newspaper had included the through-life costs of each aircraft (i.e. spare parts, software upgrades, fuel, etc). The majority of public cost estimates are done on an "upfront" basis and do not include projected spares packages and the like.
(...)
"The paper also pegged the cost of each aircraft at around £198m, though post-publication commentary appeared to suggest that the newspaper had included the through-life costs of each aircraft (i.e. spare parts, software upgrades, fuel, etc). The majority of public cost estimates are done on an "upfront" basis and do not include projected spares packages and the like.
Delays and cost overruns have been a frequent feature of the F-35 saga. Given the sheer quantity of software in not only the aircraft but its ALIS logistics suite too, it should be no surprise that costs have spiralled and unforeseen delays reared their heads. After all, since when did any Big Government IT Project run on time and within budget?"
And more news on the F-35:
And more news on the F-35:
- https://www.theregister.co.uk/2017/07/20/f35_oxygen_system_algorithm_tweak/
- https://www.theregister.co.uk/2017/01/12/f35_alis_software_delayed/
(Updated: 2017-07-31, link fixed, add. links)
quarta-feira, 12 de outubro de 2016
Product Design / System Engineering and the importance of standards - Samsung Galaxy Note 7
A very interesting article on product / system engineering / design and the importance of [international safety] standards.
From the Wall Street Journal:
http://www.wsj.com/articles/what-samsung-must-do-to-win-back-our-trust-1476218021?tesla=y
Read on and be appalled:
- There is no mandatory safety standard (in the US, in the EU) for mobile devices and since things could really catch fire (for instance on a plane) maybe there should be
- Sometimes the standards do exist but are not mandatory
- For some countries who deems a component or a phone all together suitable for a certain purpose is the company that produces it (really?)
- Components are subcontracted and due tot the secrecy involved (trade secrets are... secret), one company might not know what exactly is incorporating into its design (e.g. Batteries are certified / labeled by other companies; are all suppliers the same? Are all lots the same?)
- The problems can either come from hardware, or software but in the end, it doesn't really matter. Sometimes the recall chain is not giving you/collecting you the much needed information which is input for rework. This was a problem for Samsung (in the US) because it does not have a distribution chain in the US unlike Apple
- A compliance statements (the CE marking for instance) is just a statement by the manufacturer indicating they [think they] are compliant. Nobody checks it [before going into market - of course it will be checked after "something" goes wrong]. In fact most of the times there are no requirements for compliance testing (which is a different and safer thing, because some independent entity is analysing your work product)
- The fact that there is no word for re-recall: Because it rarely happens at such a scale, Samsung stopped the production (!). Nobody would trust on a recall of the recall. How many recalls would it take for Samsung to produce something that works properly as most products work (in terms of catching fire)?
The bottom line:
- Samsung shares are going down. There's talks of 15 K M EUR of losses.
- But worst than that: There's the image / reputation thing... Once lost it typically is like... Virginity.
So what do you think on the lack of process (and international standards) on product
/ system design? Is it a bore or is it much needed? We carry those things on the pocket of our trousers. Into planes. We are giving it to our kids...
From the Wall Street Journal:
http://www.wsj.com/articles/what-samsung-must-do-to-win-back-our-trust-1476218021?tesla=y
Read on and be appalled:
- There is no mandatory safety standard (in the US, in the EU) for mobile devices and since things could really catch fire (for instance on a plane) maybe there should be
- Sometimes the standards do exist but are not mandatory
- For some countries who deems a component or a phone all together suitable for a certain purpose is the company that produces it (really?)
- Components are subcontracted and due tot the secrecy involved (trade secrets are... secret), one company might not know what exactly is incorporating into its design (e.g. Batteries are certified / labeled by other companies; are all suppliers the same? Are all lots the same?)
- The problems can either come from hardware, or software but in the end, it doesn't really matter. Sometimes the recall chain is not giving you/collecting you the much needed information which is input for rework. This was a problem for Samsung (in the US) because it does not have a distribution chain in the US unlike Apple
- A compliance statements (the CE marking for instance) is just a statement by the manufacturer indicating they [think they] are compliant. Nobody checks it [before going into market - of course it will be checked after "something" goes wrong]. In fact most of the times there are no requirements for compliance testing (which is a different and safer thing, because some independent entity is analysing your work product)
- The fact that there is no word for re-recall: Because it rarely happens at such a scale, Samsung stopped the production (!). Nobody would trust on a recall of the recall. How many recalls would it take for Samsung to produce something that works properly as most products work (in terms of catching fire)?
The bottom line:
- Samsung shares are going down. There's talks of 15 K M EUR of losses.
- But worst than that: There's the image / reputation thing... Once lost it typically is like... Virginity.
So what do you think on the lack of process (and international standards) on product
/ system design? Is it a bore or is it much needed? We carry those things on the pocket of our trousers. Into planes. We are giving it to our kids...
sexta-feira, 19 de fevereiro de 2016
On software project failures
Software projects fail a lot. And since software is on most modern equipments (read carefully: almost everywhere) most equipments will also fail when running faulty software produced by some of those projects. This is one of the reasons current systems (meaning hardware + software) will also fail a lot.
How much do software projects fail? It's an interesting question and here are some possible "answers":
The latter study, published on Dr. Dobbs (which is now inactive BTW), criticizes the CHAOS report. On any case, a good percentage of projects fail and / or are challenged (they do not meet the on-quality, on-budget, on-schedule initial criteria). Just look at the trailer, I mean, just look at the numbers.
How much do software projects fail? It's an interesting question and here are some possible "answers":
- The CHAOS report: https://www.projectsmart.co.uk/white-papers/chaos-report.pdf
- The Ambysoft "2013 IT Project Success Rates Survey Results": http://www.ambysoft.com/surveys/success2013.html
- The final presentation of the latter: http://www.ambysoft.com/downloads/surveys/Success2013.pptx
The latter study, published on Dr. Dobbs (which is now inactive BTW), criticizes the CHAOS report. On any case, a good percentage of projects fail and / or are challenged (they do not meet the on-quality, on-budget, on-schedule initial criteria). Just look at the trailer, I mean, just look at the numbers.
Subscrever:
Mensagens (Atom)