Что не так с ГОСТ-34?
В теме ГОСТ-34 и Software Requierements Specification (SRS) я вкратце описал,
что для разработки технического задания (ТЗ) для программного обеспечения (ПО) лучше использовать ISO, правда и ГОСТ-34 сгодится после адаптации.
Здесь я хочу дать расширенное объяснение, почему НЕЛЬЗЯ создавать современное программное обеспечение по ГОСТ-34.
[Читать далее...]
Через 9 лет после выпуска ГОСТ-34 был принят другой ГОСТ Р ИСО/МЭК ТО 12207-1999, который позволяет перейти из XX века в XXI.
Но увы, многие в России не желают этого делать, и уже более 20 лет все еще "молятся" на ГОСТ-34.
Что же именно в нем не позволяет создать современное ПО?
Для простоты я буду сравнивать не сам ГОСТ Р ИСО/МЭК 12207-1999, а ГОСТ Р ИСО/МЭК ТО 15271-2002 (Руководство по применению ГОСТ Р ИСО/МЭК 12207).
1. В ГОСТ-34 существует только одна модель жизненного цикла (разработки): жесткая водопадная (каскадная, waterfall).
В ИСО к ней добавлены еще две фундаментальные: инкрементная и эволюционная.
При этом упомянуто, что есть и другие, и что возможны различные комбинации.
Отдельно подчеркивается, что конкретную модель надо выбирать с учетом разных факторов.
Сейчас достаточно часто как модификацию каскадной модели используют V-модель.
2. В ГОСТ-34 есть единое "большое" ТЗ, на основе которого составляется договор.
Детализация ТЗ не предусмотрена, поэтому придумывают некое "частное ТЗ", которое формально должно содержать требования к подсистемам.
Если подсистем нет, то их искусственно придумывают. Но для подсистем уже нужна своя отдельная документация (по ЕСПД).
Пусть даже формальная.
Понятий "анализ требований", "управление требованиями" в ГОСТ-34 просто не существует.
3. Эскизный проект (ГОСТ-34).
Сначала может показаться, что это - прототип (макет, mockup). Но нет.
Проект требует исполнения пунктов "Разработка предварительных проектных решений по системе и её частям" и "Разработку документации на АС и её части".
Тогда как в разработке современного ПО это могут быть просто эскизы GUI и/или краткие сценарии по основному workflow.
5. Технический проект (ГОСТ-34).
В нем должно быть ВСЁ, чтобы программисты на следующем этапе "тупо" кодировали по "Описаниям постановки задач (комплекса задач)".
В ИСО же есть понятия "Системная и программная архитектура" , которая содержит больше "стратегии", чем "тактики".
Причем, она может дорабатываться параллельно с разработкой (программированием) ПО.
6. Рабочая документация (ГОСТ-34).
Именно так забавно называется этап программирования.
В него входит "Разработка или адаптация программ", а также составление "Инструкции по формированию и ведению базы данных (набора данных)", "Руководства пользователя", и прочее.
Понятно, что в этом ГОСТ-е не мог появиться процесс управления конфигурацией/сборкой, но процесс документирования-то можно было выделить.
7. Управление качеством (ISO).
В ГОСТ-34 отсутствует как класс. Именно поэтому ПО, разработанное по этому ГОСТу, низкого качества с ужасным usability.
Кстати, валидация в ГОСТ-34 тоже не предусмотрена (опытная эксплуатация это немного другое), поэтому есть шанс получить вообще не то, что ожидалось.
Различные приемочные испытания (которые есть и в ISO) НЕ ГАРАНТИРУЮТ качество, как некоторые думают.
Они просто демонстрируют заказчику готовность продукта, и в разработке по ISO обязательно должны сопровождаться отчетами о тестировании (альфа и бета) и test cases.
И наличие 3 (трех) видов испытаний в ГОСТ-34 просто избыточно.
P.S. Это не полноценное сравнение ГОСТ-34 и ISO, это всего лишь направление движения сюда: Ответ замшелым IT ГОСТ-ократам
P.P.S. Неожиданно появилось продолжение: Что не так с ГОСТ-34? - 2
Предполагаю, что ГОСТ-34 тоже здесь оставил свой след:
Пуск «Ангары-А5» с Восточного отменен во второй раз.
"Выявилась новая техническая неполадка, связанная по предварительным анализам телеметрии - это сбой в системе контроля запуска двигателя.
Скорее всего это программная ошибка, которая сегодня будет найдена", - сообщил гендиректор "Роскосмоса" Юрий Борисов.
10.04.2024
что для разработки технического задания (ТЗ) для программного обеспечения (ПО) лучше использовать ISO, правда и ГОСТ-34 сгодится после адаптации.
Здесь я хочу дать расширенное объяснение, почему НЕЛЬЗЯ создавать современное программное обеспечение по ГОСТ-34.
[Читать далее...]
Через 9 лет после выпуска ГОСТ-34 был принят другой ГОСТ Р ИСО/МЭК ТО 12207-1999, который позволяет перейти из XX века в XXI.
Но увы, многие в России не желают этого делать, и уже более 20 лет все еще "молятся" на ГОСТ-34.
Что же именно в нем не позволяет создать современное ПО?
Для простоты я буду сравнивать не сам ГОСТ Р ИСО/МЭК 12207-1999, а ГОСТ Р ИСО/МЭК ТО 15271-2002 (Руководство по применению ГОСТ Р ИСО/МЭК 12207).
1. В ГОСТ-34 существует только одна модель жизненного цикла (разработки): жесткая водопадная (каскадная, waterfall).
В ИСО к ней добавлены еще две фундаментальные: инкрементная и эволюционная.
При этом упомянуто, что есть и другие, и что возможны различные комбинации.
Отдельно подчеркивается, что конкретную модель надо выбирать с учетом разных факторов.
Сейчас достаточно часто как модификацию каскадной модели используют V-модель.
2. В ГОСТ-34 есть единое "большое" ТЗ, на основе которого составляется договор.
Детализация ТЗ не предусмотрена, поэтому придумывают некое "частное ТЗ", которое формально должно содержать требования к подсистемам.
Если подсистем нет, то их искусственно придумывают. Но для подсистем уже нужна своя отдельная документация (по ЕСПД).
Пусть даже формальная.
Понятий "анализ требований", "управление требованиями" в ГОСТ-34 просто не существует.
3. Эскизный проект (ГОСТ-34).
Сначала может показаться, что это - прототип (макет, mockup). Но нет.
Проект требует исполнения пунктов "Разработка предварительных проектных решений по системе и её частям" и "Разработку документации на АС и её части".
Тогда как в разработке современного ПО это могут быть просто эскизы GUI и/или краткие сценарии по основному workflow.
5. Технический проект (ГОСТ-34).
В нем должно быть ВСЁ, чтобы программисты на следующем этапе "тупо" кодировали по "Описаниям постановки задач (комплекса задач)".
В ИСО же есть понятия "Системная и программная архитектура" , которая содержит больше "стратегии", чем "тактики".
Причем, она может дорабатываться параллельно с разработкой (программированием) ПО.
6. Рабочая документация (ГОСТ-34).
Именно так забавно называется этап программирования.
В него входит "Разработка или адаптация программ", а также составление "Инструкции по формированию и ведению базы данных (набора данных)", "Руководства пользователя", и прочее.
Понятно, что в этом ГОСТ-е не мог появиться процесс управления конфигурацией/сборкой, но процесс документирования-то можно было выделить.
7. Управление качеством (ISO).
В ГОСТ-34 отсутствует как класс. Именно поэтому ПО, разработанное по этому ГОСТу, низкого качества с ужасным usability.
Кстати, валидация в ГОСТ-34 тоже не предусмотрена (опытная эксплуатация это немного другое), поэтому есть шанс получить вообще не то, что ожидалось.
Различные приемочные испытания (которые есть и в ISO) НЕ ГАРАНТИРУЮТ качество, как некоторые думают.
Они просто демонстрируют заказчику готовность продукта, и в разработке по ISO обязательно должны сопровождаться отчетами о тестировании (альфа и бета) и test cases.
И наличие 3 (трех) видов испытаний в ГОСТ-34 просто избыточно.
P.S. Это не полноценное сравнение ГОСТ-34 и ISO, это всего лишь направление движения сюда: Ответ замшелым IT ГОСТ-ократам
P.P.S. Неожиданно появилось продолжение: Что не так с ГОСТ-34? - 2
Предполагаю, что ГОСТ-34 тоже здесь оставил свой след:
Пуск «Ангары-А5» с Восточного отменен во второй раз.
"Выявилась новая техническая неполадка, связанная по предварительным анализам телеметрии - это сбой в системе контроля запуска двигателя.
Скорее всего это программная ошибка, которая сегодня будет найдена", - сообщил гендиректор "Роскосмоса" Юрий Борисов.
10.04.2024