![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Это пост скопирован с поста в LJ вручную из-за проблем с автоматическим переносом.
Из дискуссии под предыдущим постом выяснилось, что ИТ специалисты не очень хорошо представляют разницу между плотом и лодкой. Надо, видимо, запретить в блоге упоминать физику, чтобы не объяснять, почему переход от «легче» к «тяжелее» не может осуществляется поперечным наклоном корпуса. Как уже сказано, практика учит не полагаться на априорное наличие знаний на уровне начальной школы и сперва разбираться с определениями.
Зачем используют UML? В основном потому, что так требуют сетрификаторы. А сертификаты, в свою очередь, требуют клиенты и госорганы.
Хоть в документах и прописано, что дизайн перед кодированием улучшает качество, на самом деле в реальной жизни это совсем не так. В результате, основным этапом UML-моделирования является постдокументация.
Когда софт написан и почти оттестирован, наступает время строить левую и правую ветви V-модели. И тут-то выясняется, что технологий извлечения дизайна и требований из кода просто не существует, и всё надо делать руками. В лучшем случае удаётся поднять в тул диаграмму классов.
Потенциально рынок огромен, но автоматизация безумно сложная, потому что каждый делает по-своему. Особенно это касается форматирования и классификации информации.
Интересно, что по терминам Design Archeology или Requirements Archeology Гугл ничего не выдаёт. А это именно то, чем люди на самом деле занимаются. Reverse Engineering встречается, но описывает в основном другие процессы и в той же V-модели поставлен почему-то в начало цикла улучшения софта, а не в финальную стадию перед сдачей.
Пока все модели процессов врут, применимость их на реальных проектах ограничивается очковтирательством. Как было сказано на междусобойчике теоретиков процессов разработки, у нас ещё нет модели, выдерживающей авралы. Ну да. Просто потому, что в критической ситуации факты начинают лезть из всех щелей.
Впрочем, такая модель была бы опасна, потому что менеджмент при получении реальной информации вместо проведения контрмер банально впадает в панику и блокирует своими безумными приказами любые возможности улучшения ситуации.
Исключения бывали, но очень редко. Да и то в основном это касается не отсутствия испуга, а адекватности действий.
Про постдокументацию
Из дискуссии под предыдущим постом выяснилось, что ИТ специалисты не очень хорошо представляют разницу между плотом и лодкой. Надо, видимо, запретить в блоге упоминать физику, чтобы не объяснять, почему переход от «легче» к «тяжелее» не может осуществляется поперечным наклоном корпуса. Как уже сказано, практика учит не полагаться на априорное наличие знаний на уровне начальной школы и сперва разбираться с определениями.
Зачем используют UML? В основном потому, что так требуют сетрификаторы. А сертификаты, в свою очередь, требуют клиенты и госорганы.
Хоть в документах и прописано, что дизайн перед кодированием улучшает качество, на самом деле в реальной жизни это совсем не так. В результате, основным этапом UML-моделирования является постдокументация.
Когда софт написан и почти оттестирован, наступает время строить левую и правую ветви V-модели. И тут-то выясняется, что технологий извлечения дизайна и требований из кода просто не существует, и всё надо делать руками. В лучшем случае удаётся поднять в тул диаграмму классов.
Потенциально рынок огромен, но автоматизация безумно сложная, потому что каждый делает по-своему. Особенно это касается форматирования и классификации информации.
Интересно, что по терминам Design Archeology или Requirements Archeology Гугл ничего не выдаёт. А это именно то, чем люди на самом деле занимаются. Reverse Engineering встречается, но описывает в основном другие процессы и в той же V-модели поставлен почему-то в начало цикла улучшения софта, а не в финальную стадию перед сдачей.
Пока все модели процессов врут, применимость их на реальных проектах ограничивается очковтирательством. Как было сказано на междусобойчике теоретиков процессов разработки, у нас ещё нет модели, выдерживающей авралы. Ну да. Просто потому, что в критической ситуации факты начинают лезть из всех щелей.
Впрочем, такая модель была бы опасна, потому что менеджмент при получении реальной информации вместо проведения контрмер банально впадает в панику и блокирует своими безумными приказами любые возможности улучшения ситуации.
Исключения бывали, но очень редко. Да и то в основном это касается не отсутствия испуга, а адекватности действий.
