В дебрях водопада
Apr. 23rd, 2015 10:26 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
vit_rЧего-то влом мне сейчас про аниме писать. Закину-ка я кусок текста, который послал на один из форумов.
Английский совсем испортился. Вместо хороших книжек британских авторов вынужден работать с немецким англиским и с индийским английским, который на мой непросвещённый взгляд содержит массу того, что бы я посчитал за грамматические и стилистические ляпы...
A bird's point of view does not allow to see the monsters that live in mud.
I won't fully describe the model I preferably use but simply speaking there are real requirements and there are formal requirements. In most cases they do not match.
I have seen projects with nearly perfect requirements specifications. In all cases there are 2 conditions:
1. The requirements specifications (the formal requirements) were written by people who do the real work.
2. Significant part of requirements was in the state "to be clarified" until the later development stages.
I have also seen mission critical projects where requirements specifications were "adapted" to meet project outcomes. (This means formal requirements were changed to match real requirements after their implementation.)
This were mission critical systems for which the real requirements are "tangible". If you miss some real requirement, your product "explodes". If you meet real requirements but ignore formal requirements, the worst outcome would be "bad diagrams" in the management's reporting tool.
In most cases this discrepancies are simply ignored with the devise "We don't have resources for this bureaucratic tasks."
In most "normal" projects I have seen the differences between real requirements and formal requirements were not visible. The requirements were too broad defined and they did not contain real fit criteria. The final acceptance test did not check "invisible" parts. Etc.
This means people who do the real work can easily fool system verification processes.
Надо, наверное, писать с заглавынх букв People who Do the Real Work. Так эпичнее.
Да, покопав оптимистичные цели из прошлого поста, выяснил что они поставлены на основе ошибочных данных. Не то померили, не там и не так. В результате сравнивают яблоки с кирпичами.
Посмотрим, чем закончится.
Английский совсем испортился. Вместо хороших книжек британских авторов вынужден работать с немецким англиским и с индийским английским, который на мой непросвещённый взгляд содержит массу того, что бы я посчитал за грамматические и стилистические ляпы...
A bird's point of view does not allow to see the monsters that live in mud.
I won't fully describe the model I preferably use but simply speaking there are real requirements and there are formal requirements. In most cases they do not match.
I have seen projects with nearly perfect requirements specifications. In all cases there are 2 conditions:
1. The requirements specifications (the formal requirements) were written by people who do the real work.
2. Significant part of requirements was in the state "to be clarified" until the later development stages.
I have also seen mission critical projects where requirements specifications were "adapted" to meet project outcomes. (This means formal requirements were changed to match real requirements after their implementation.)
This were mission critical systems for which the real requirements are "tangible". If you miss some real requirement, your product "explodes". If you meet real requirements but ignore formal requirements, the worst outcome would be "bad diagrams" in the management's reporting tool.
In most cases this discrepancies are simply ignored with the devise "We don't have resources for this bureaucratic tasks."
In most "normal" projects I have seen the differences between real requirements and formal requirements were not visible. The requirements were too broad defined and they did not contain real fit criteria. The final acceptance test did not check "invisible" parts. Etc.
This means people who do the real work can easily fool system verification processes.
Надо, наверное, писать с заглавынх букв People who Do the Real Work. Так эпичнее.
Да, покопав оптимистичные цели из прошлого поста, выяснил что они поставлены на основе ошибочных данных. Не то померили, не там и не так. В результате сравнивают яблоки с кирпичами.
Посмотрим, чем закончится.
