В дебрях водопада
Feb. 28th, 2016 08:11 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
vit_r![[livejournal.com profile]](https://www.dreamwidth.org/img/external/lj-userinfo.gif){kind=small}
gineer пристыдиль меня под постом с неправомерными порицаниями человека энцеклопедических заблуждений ailev.По такому поводу отмотал в черновике десяток экранов наверх и скопировал сюда то, что посмотрел после слайда с табличкой об Очень Дорогих Ошибках в Техзадании из какой-то презентации вышеупомянутого
ailev.Современные компьютерные учёные и примазавшиеся не измеряют. Они только обрабатывают литературу. В лучшем случае, спрашивают. В результате, цифрам верить нельзя абсолютно. Тем более, нельзя использовать их для принятия решений в реальной жизни.
В принципе, это надо было бы переработать, проанализировать и выдать в дистиллированном виде. Но просто для демонстрации даю только цитаты и таблицы. Выводы делайте сами.
Итак Error Cost Escalation Through the Project Life Cycle. Как говорится, следите за руками.
A study was performed to determine the relative cost of fixing errors discovered during various phases of a project life cycle.
The approaches and results described in this paper presume development of a hardware/software system having project characteristics similar to those used in the development of a large, complex spacecraft, a military aircraft, or a small communications satellite.
If the cost of fixing a requirements error discovered during the requirements phase is defined to be 1 unit, the cost to fix that error if found during the design phase increases to 3 — 8 units; at the manufacturing/build phase, the cost to fix the error is 7 — 16 units; at the integration and test phase, the cost to fix the error becomes 21 — 78 units; and at the operations phase, the cost to fix the requirements error ranged from 29 units to more than 1500 units. [!!! - vit-r]
Increased emphasis on finding errors early in the project life cycle means spending more time and a larger percentage of project costs in the definition phases of a project — more than is usually allocated to the early phases.
Late corrections involve a much more formal change approval and control process, and a much more extensive activity to revalidate the correction.
page 2 Table 1: Normalized Cost-to-Fix Estimates [the table was modified - vit-r]
| Source | Phase Requirements Issue Found | |||
|---|---|---|---|---|
| Requirements | Design | Code | Test | |
| [Boehm, 1981] | 1 | 5 | 10 | 50 |
| [Hoffman, 2001] | 1 | 3 | 5 | 37 |
| [Cigital, 2003] | 1 | 3 | 7 | 51 |
| [Rothman, 2002] | 1 | 20 | 45 | 250 |
| [Pavlina, 2003] | 1 | 10 | 100 | 1000 |
These systems cost factors, shown in Table 2, represent the costs of fixing errors in electronics hardware. The costs are referenced without any description of the approach or method used to generate the comparative cost number... [!!! - vit-r]
page 3 Table 2: Systems Cost Factors
| Phase that Change Occurs | Resulting Cost |
|---|---|
| Product Design | $1,000 |
| Product Testing | $10,000 |
| Process Design | $100,000 |
| Low-Rate Initial Production | $1,000,000 |
| Final Production/Distribution | $10,000,000 |
The bottom-up method of determining the cost to fix errors found in different phases of the life cycle is derived from the most detailed form of cost estimation.
Method 2 — Total Costs Breakdown
Description. With first hand knowledge of the phase in which an error occurred and averaging multiple changes for each phase, a cost factor escalation can be calculated between phases. The data used for this method came from a major aircraft design, build, flight test and operations program valued in the billions of dollars.
The top-down hypothetical project method models the escalation of error costs using the architecture of a hypothetical [!!! = vit-r] aerospace project and hypothetical errors. ... Finally, the estimation of the costs to fix each error is based heavily on the author's experience [ (-_^) - vit_r].
Table 12 compares the cost factors determined by each of the three methods. While the results are similar in many respects, there are also differences between the results. This section will discuss some of those similarities and potential reason for the dissimilarities.
page 9 Table 12: Comparison of Methods 1, 2, & 3 Cost Factors
| Method 1 Cost Factors | Method 2 Cost Factors | Method 3 Cost Factors | |
|---|---|---|---|
| Requirements | 1X | 1X | 1X |
| Design | 8X | 3X-4X | 4X |
| Build | 16X | 13X ‐ 16X | 7X |
| Test | 21X | 61X-78X | 28X |
| Operations | 29X | 157X ‐ 186X | 1615X |
...
- Boehm, B. W., Software Engineering Economics, Prentice-Hall, Englewood Cliffs, NJ, 1981.
- Cigital, "Case study: Finding defects earlier yields enormous savings," Available at www.cigital.com , 2003.
- Cloud, Giffen, Larson, and Swan, "Designing Cost-Effective Space Missions: An Integrated, Systems Engineering Approach," Teaching Science and Technology, Inc., 1999.
- Larson, W. and Wertz, J., Space Mission Analysis and Design, Second Edition, Microcosm, Inc. and Kluwer Academic Publishers, Boston, 1993.
- MATLAB, Learning AIM TLAB, The MathWorks, Inc., January 2001. McGibbon, T., "Return on investment from software process improvement," Available at www.dacs.dtic.mil, 2003.
- Mortice Kern Systems Inc., "From Software Quality Control to Quality Assurance," 2001.
- NASA Systems Engineering Handbook, SP-6105, National Aeronautics and Space
Administration, June 1995. - Pavlina, S., "Zero-defect software development," Dexterity Software, Available at www.dexterity.com , 2003.
- Rothman, J., "What does it cost to fix a defect?" StickyMinds.com, February 2002, Available at http://www.stickyminds.com/stgeletter/archive/20020220nl.asp, 2003.
- Schneider, G. M., Martin, J., and Tsai, W. T., "An experimental study of fault detection in user requirements documents," ACM Transactions on Software Engineering and Methodology, Vol 1, No 2, April, 1992, pp 188 — 204.
Ни выводов, ни анализа не будет. Просто, когда кто-то в очередной раз даёт мне ССЫЛКУ НА НАУЧНЫЕ ФАКТЫ, вспоминайте эту статью с анализом достижений компьютерных наук. И не стоит забывать, что современные статьи берут цифры из этой уже потеряв по дороге все первоначальные источники.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2016-02-28 07:22 pm (UTC)no subject
Date: 2016-02-28 07:30 pm (UTC)И что делать с теми измерениями, которые вроде бы честные, но не рассматривают "свободные" параметры в системе.
no subject
Date: 2016-02-28 07:34 pm (UTC)"если не можешь остановить безумие, возглавь его"
no subject
Date: 2016-02-28 08:30 pm (UTC)Во сколько раз исправление ошибок на следующих фазах, на самом деле, дороже?
И насколько точнее идентифицируются ошибки на следующих фазах?
(Про эффект того, что многие "ошибки", "исправленные" во время дизайна, могут ошибками и не являться - вообще мало кто упоминает).
no subject
Date: 2016-02-28 08:35 pm (UTC)no subject
Date: 2016-02-28 08:51 pm (UTC)Только каждый цикл такого водопада очень короткий (в среднем, несколько часов).
И постоянно приходится балансировать между тем, насколько тщательно ковыряться в каждой фазе и насколько много багов можно пропускать в production на потеху конечным пользователям.
no subject
Date: 2016-02-28 08:53 pm (UTC)Водопад - это модель подсчёта бюджета проекта. Не надо её совать туда, куда не стоит.
no subject
Date: 2016-02-28 08:57 pm (UTC)И как распределять усилия между ними - не очевидно.
no subject
Date: 2016-02-28 08:59 pm (UTC)no subject
Date: 2016-02-28 09:05 pm (UTC)no subject
Date: 2016-02-28 10:07 pm (UTC)no subject
Date: 2016-02-28 10:10 pm (UTC)no subject
Date: 2016-02-28 10:28 pm (UTC)no subject
Date: 2016-02-28 10:11 pm (UTC)no subject
Date: 2016-03-01 11:54 pm (UTC)интерпретация данных зачастую процесс очень интересный https://en.wikipedia.org/wiki/Simpson%27s_paradox
no subject
Date: 2016-02-28 07:36 pm (UTC)То есть, мне не известна природа этой информации,
а потому, признавая в общем критику,
вполне может быть что это:
а) просто так называемая "информация для иллюстрации",
то есть просто кочующий между мозгами набор информации
(как в старом анекдоте -- ректор выпускникам медвуза: "Вы учились тут долгих пять лет, но я должен вас разочаровать -- половина из того что вы здесь выучили -- неправильно. И что хуже всего -- я сам не знаю какая это половина")
б) еще хуже, это текущий "стейт оф зе арт"... за это конечно тоже можно порицать, но когда-то и флогистон был научной теорией.
Потому, разделяя общий критицизм... все же не могу отделатся от наблюдения, что огульная констатация чужих вроде бы ошибок -- это не такая уж и продуктивная стратегия...
no subject
Date: 2016-02-28 08:06 pm (UTC)Мы же имеем дело не просто с вычислением количества чертей на острие иглы, но и с принятием решений по бюджету и срокам на основе этих вычислений.
no subject
Date: 2016-02-28 08:16 pm (UTC)Да. Тут вы попали в точку, в суть тех трудностей с которыми приходится рабо...
ну, да, это не совсем его работа... он консультант, но у действующих практиков и так голова пухнет от текущих задач,
а он, как человек может и не практичный, но все же близкий к их проблемам,
пробует думать над тем, как улучшить работу практиков.
По-моему, вполне уважительное занятие.
no subject
Date: 2016-02-28 08:26 pm (UTC)no subject
Date: 2016-02-28 08:35 pm (UTC)no subject
Date: 2016-02-29 05:42 pm (UTC)no subject
Date: 2016-02-29 06:07 pm (UTC)no subject
Date: 2016-02-28 08:18 pm (UTC)