Комментарии 6
За более чем 10 лет разработки я встречал только один путь создания продуктов:
1) концептуальное описание;
2) конкретная реализация в коде вместе с тестами;
3) создание на базе первого и второго пунктов фиктивных требований и прочей чепухи для отчётов и поддержки;
4) в продакшн... за деньгами...
Я написал это, потому что хотел, чтобы люди просто увидели правду разработки проектов и успокоились с этой академической чепухой:)
Не существует никаких "правил" и "алгоритмов". Если у вас появляется идея. Сразу в код или забудьте.
ПС: SDLC скорее описывает рост опыта специалиста, чем рост программной системы, которую тот разрабатывает. Но это уже другая тема.
SDLC точно не описывает рост специалиста, это про проект, но картинка умозрительная, тут я согласен. И то, что нет правил и алгоритмов - тоже. Собственно, меня огорчает то, что многие верят в их существование и пытаются ими овладеть, вместо того, чтобы заниматься более полезными вещами. Поэтому и родилась статья, попытка объяснить.
А что касается вашего списка, то там до кода есть 1 - концептуальное описание. Которое должно убедить команду (если в разработке больше одного человека), а еще должно убедить владельца денег одобрить реализацию, если команда не будет делать это за свой счет в свободное время. И это - важная часть. Но потом - код, особенно если идея новая, тут я согласен.
Мне еще интересен пункт 3 про фиктивные требования. Он как-то наводит на мысли, что финансирование могут одобрить на одни цели, а фактически сделать другое, и надо закрыть разрыв. Или это обычные корпоративные игры, когда руководитель может санкционировать работу, но дальше ему нужны отчеты, что все было "по процессу"? Или имеется ввиду что-то другое?
статья ищется по ключу "что такое sdlc?"
но считаю ее однобокой: автор утверждает, что SDLC, как он был определен давно, утратил смысл, предлагая вместо него V-model, которая выглядит точно также как и SDLC - просто квадратики назвали чуть иначе и детализировали )
Но есть несколько но
Автор ссылается на \ссылку вики про system development LC, и верно все говорит, но говорит про ЖЦ разработки системы, а не ПО. Разработка ПО может быть циклична (привет скраму эджайлу и всем гибридам), более того - она давно циклична и полностью подчиняется что картинке, что v модели - тут вопрос детализации
Автор говорит о том, как важно смотреть на пользователей (интеграция продукта в жизнь людей). Но тут смешение понятия: SDLC - это цикл разработки ПО, а интеграция продукта в жизнь людей - это уже Жизненный цикл продукта, в который SDLC входит, но которым не исчерпывается.
стандарт ISO/IEC/IEEE 12207 определяет ЖЦ разработки ПО по фазам:
Анализ требований: Уточнение User Story на планировании спринта (Sprint Planning) и груминге (Refinement).
Проектирование и дизайн: Обсуждение архитектуры фичи внутри команды перед кодированием.
Разработка (Кодирование): Написание кода разработчиками.
Тестирование (Верификация): QA-инженерия, автотесты и Code Review внутри спринта.
Внедрение (Эксплуатация / Релиз): Поставка готового инкремента в конце спринта (CI/CD).
Поддержка и обратная связь: Демонстрация на Sprint Review и разбор полетов на Ретроспективе.
то есть все тоже самое что и в V-model
итого: выглядит так, что статья ни о чем.
Почему я сюда попал и докопался: искал статью про то что такое SDLC которое даже wiki не описывает (там software development LC по ссылке приводит к system development lifecycle ведет, что приводит как раз к терминологической каше)
Думал тут мне разъяснят, но нет :)
Мораль: напишу статью сам ))
SDLC расшифровывается как Software Development LifeCycle, так что статья вики как раз правильная. И там с каким-то качеством описано, что это такое. V-модель - предтеча стандарта ISO - она появилась намного раньше, и стандарт действительно от нее не отличается. А вот SDLC отличается от V-модели тем, что ПЕРЕД фазой Analysis воткнули фазу Planing. Что есть абсурд. И именно этому посвящена данная статья. Я не обещал объяснить, что такое SDLC и, увы, не могу отвечать за то, что поиск по запросу "SDLC" выводит на нее. А по факту из статьи следует, что SDLC - почтенный лейбл для неработающей схемы, которую люди как-то пытаются интерпретировать и применить, вместо того, чтобы выбросить без почтения.
Впрочем, буду рад прочесть вашу статью - любая интерпретация практического опыта интересна.
Есть Software Lifecycle, а есть Software development lifecycle.
Есть цикл производства автомобиля , а есть ЖЦ самого автомобиля. Говорить, что это одно и тоже - некорректно. Даже если это сказано в вики.
В РФ есть стандарт на создание АС, это 34 гГОСТ и там четко прописаны стадии
Эт раз.
Два: 12207 -2010 не содержит очередности, там вообще принцип: мы описали процессы, а про последовательность - сами решайте. А вот в предыдущем она была.
Выяснять, что в 80х кто написал, по моему - пустое занятие.
А вот есть свеженький ГОСТ Р 54869 где планирование идет 2м шагом, как раз между инициацией и исполнением. И планирование там расписано в том числе, как планирование содержания проекта - то есть фаза анализа и планирования связаны.
Разница между Software Lifecycle и Software development lifecycle - очевидна. SDLC, как легко увидеть из аббревиатуры - это Software Development LifeCycle. Хотя да, они закрутили его вы цикл, предполагая то ли итерационную разработку, то ли вечное развитие - точно так же как PMBoK в 6 (по-моему) версии закрутил в цикл работу по проекту - тут уже явно говоря про итерации или этапы реализации.
Кто что написал в 80-х было бы совершенно не актуально, если бы в в многочисленных выступлениях на конференциях и статьях сейчас не ссылались на этот самый SDLC. Не определяя, что именно это такое, но неявно предполагая что столь почтенная и освященная традицией штука не может быть фигней. А вот на ГОСТы - не ссылаются, ни на 34, ни на 54. Впрочем они до сих пор преимущественно калька с западных стандартов.
И с ИТ-проектами есть такая засада. Современный PMBoK и связанные с ним стандарты выросли из RUP, попытки управления именно ИТ-проектами. Проблема в том, что эта попытка провалилась, еще в 90-х, именно поэтому в ИТ выросло семейство Agile-методов. А у нас по-прежнему пробуют это применять с соответствующими последствиями. У меня именно на эту тему было выступление Почему проектный подход не работает в IT и есть две статьи: Развитие и провал регулярного менеджмента в IT и Agile-методы и проектный подход - в чем разница?
SDLC: пойди туда, не знаю куда, но непременно по плану