Обеспечение жизненного цикла: Жизненный цикл программного обеспечения — QA evolution

Жизненный цикл программного обеспечение. Это обязан знать каждый на собесе в IT

• Определение бизнес-потребности (Business need definition)
• Предпродажа (Presale)
  • отсутствует в продуктовых компаниях, характерен только для модели аутсорса
• Инициация (Initiation)
• Проектирование и дизайн (Elaboration and Design)
• Имплементация (Implementation)
• Тестирование (Testing)
• Внедрение (Deployment)
• Сопровождение (Support)
• Смерть продукта (Product Death)

Рассмотрим каждый из них подробнее. 

Определение бизнес-потребности (Discovery). На этом этапе совместно работают маркетологи и менеджеры по продажам, подключаются к команде бизнес-аналитики для первичной  проработки требований к продукту. Команда должна понимать для какого рынка будет разрабатываться продукт, как продукт может принести пользу пользователям, для чего вообще будет тратиться время команды и средства клиента. Тут может быть 2 варианта развития.

• если программный продукт создается не под заказ и предполагается выход на рынок программных средств, маркетинг выполняется в полном объеме: изучаются программные продукты-конкуренты и аналоги, обобщаются требования пользователей к программному продукту, устанавливается потенциальная емкость рынка сбыта, дается прогноз цены и объема продаж. Оцениваются материальные, трудовые и финансовые ресурсы, ориентировочная длительность основных этапов жизненного цикла программного продукта;
• если программный продукт создается как заказной программный продукт  для определенного клиента, на данном этапе также важно правильно сформулировать и документировать причины и цели его разработки. 

Основные проблемы, с которыми встречаются команды разработки на данном этапе – это нежелание клиента проводить дискавери фазу  в полном объеме (т. к. это требует времени и средств) или проводить ее вообще (из разряда “я знаю лучше, что надо делать”). Как результат, команда будет делать продукт “как сказал заказчик”, а не “как требует рынок”. Больше половины написанных продуктов не выпускаются заказчиком в релиз именно из-за отсутствия хотя бы минимальной дискавери фазы. 

Предпродажа. Этот этап характерен только для аутсорсной модели разработки ПО. На данном этапе заказчик проекта формирует запрос на коммерческое предложение (Request for Proposal),  дальше сэйлз-специалисты и маркетологи подробно работают с клиентом, чтобы определить, интересен ли такой заказчик с точки зрения прибыли и имиджа для компании. Потом подключаются бизнес-аналитики для формирования бизнес-требований и налаживания коммуникаций между заказчиком и IT-компанией. И наконец, техническая команда (разработчики и проектные менеджеры) определяют, возможна ли реализация продукта с технической стороны. Если все ок, то оформляется коммерческое предложение (Proposal). Если интересы заказчика и IT-компании сходятся, то начинается непосредственно работа над проектом.

Инициация. Одна из самых важных фаз SDLC. На этом этапе сотрудничают все участники процесса, а также подключаются юристы и специалисты по финансам. Хорошее техническое задание четко и однозначно определяет требования к проекту и для команды, и для бизнеса, делая прозрачными конечные цели и задачи. Если техническое задание составлено понятно, то уточнять требования к проекту по ходу разработки нужно существенно реже, а приёмка готового продукта будет быстрее и четче. Сейлз-менеджеру так же следует курировать проект, чтобы без какой-либо существенной причины его стоимость не увеличивалась или не изменялись, например, условия по гарантии (часто юристы так поступают для перестраховки). В противном случае заказчик может запросто разорвать контракт.

Проектирование и дизайн. Когда есть понимание целей проекта и уже сформулированы требования к продукту, наступает время проработать архитектуру самого продукта с технической точки зрения: какая модель данных будет использоваться, какая архитектура бэкэнда и т. д. О графическом дизайне здесь речи не идет. 

Имплементация. Этот этап работы всегда ассоциируется непосредственно с разработкой ПО. Важно, чтобы написанный код был понятным и лаконичным. На этом этапе назначаются программисты, которые работают на выбранных при составлении технического задания языках программирования. 

Тестирование. Итак, продукт написан и теперь можно переходить непосредственно к его тестированию. В работу вступают тестировщики ПО. Этот этап SDLC характеризуется проверкой работоспособности системы, выявлением, фиксацией и исправлением багов до тех пор, пока продукт не достигнет заявленных стандартов качества. В процессе тестирования выявляются нестыковки и баги, которые необходимо оперативно устранять для совершенствования работы системы. 

Внедрение. Когда продукт достаточно протестирован и готов к развертыванию, наступает следующий этап жизненного цикла. Существует 2 варианта выпуска продукта на рынок:

• Продукт сразу выпускают на целевой рынок и делают доступным всей потенциальной аудитории
• Продукт сначала выпускают на ограниченный сегмент (soft launch), тестируют в реальной жизни, а затем с учетом отзывов и улучшений он выпускается для всеобщего использования.
  • В случае аутсорсной b2b-разработки (business-to-business) проект раскатывают сначала на 1-2 департамента, а потом уже на все предприятие целиком. 

Сопровождение. На этом этапе жизненного цикла осуществляется периодическая техническая поддержка программного обеспечения.  Постоянное сопровождение позволяет убедиться, что система соответствует современным стандартам и технологиям, происходят постоянные обновления, которые направлены на оптимальное поддержание работоспособности продукта. Для многих аутсорсных IT-компаний сопровождение – это отдельное довольно прибыльное направление бизнеса, если его правильно продавать: одно дело, когда на стороне поддержки сидят низкоквалифицированные специалисты (чаще всего – индусы), которые могут помочь только в самых простых случаях (типа “перезагрузите компьютер”), и совсем другое – когда поддержкой и сопровождением занимаются высококвалифицированные разработчики, которые 24/7 могут исправлять баги и решать проблемы клиента.  

Смерть продукта. На этом этапе происходит официальное закрытие продукта. 

Мы представили жизненный цикл ПО как набор последовательных этапов. На практике же, этапы могут разделяться или идти параллельно. В зависимости от того, как взаимосвязаны этапы жизненного цикла ПО между собой, выделяют различные модели разработки. Рассмотрим самые популярные из них.

Каскадная или водопадная модель (Waterfall model)

Можно сказать, что это одна из первых моделей жизненного цикла ПО, при которой которой процесс разработки выглядит как поток, последовательно проходящий фазы анализа требований, проектирования, реализации, тестирования, интеграции и поддержки.

Плюсы:

• При такой модели легко управлять проектом, т.к. модель управления простая и последовательная
• Требования к каждому этапу формально определены и документированы заранее
• Четко определено, когда заканчивается предыдущий этап и начинается следующий.  

Минусы:

• Возврат к предыдущему этапу невозможен.
• Тестирование происходит только после разработки продукта, т.е. продукт может иметь недочеты и баги, о которых становится известно лишь в конце
• Недостаточная гибкость модели: тяжело вносить изменения, необходимо полностью проработать требования до передачи продукта в разработку, что определенно затягивает сроки и т.д. 
• Стоимость внесения изменений высока, так как для ее инициализации приходится ждать завершения всего проекта. 

Модели жизненного цикла программного обеспечения / Хабр

Здравствуйте, уважаемые хабровчане! Думаю будет кому-то интересно вспомнить какие модели разработки, внедрения и использования программного обеспечения существовали ранее, какие модели в основном используются сейчас, зачем и что это собственно такое. В этом и будет заключаться моя небольшая тема.

Собственно, что же такое жизненный цикл программного обеспечения — ряд событий, происходящих с системой в процессе ее создания и дальнейшего использования. Говоря другими словами, это время от начального момента создания какого либо программного продукта, до конца его разработки и внедрения. Жизненный цикл программного обеспечения можно представить в виде моделей.

Модель жизненного цикла программного обеспечения — структура, содержащая процессы действия и задачи, которые осуществляются в ходе разработки, использования и сопровождения программного продукта.

Эти модели можно разделить на 3 основных группы:

1. Инженерный подход
2. С учетом специфики задачи
3. Современные технологии быстрой разработки

Теперь рассмотрим непосредственно существующие модели (подклассы) и оценим их преимущества и недостатки.

Модель кодирования и устранения ошибок

Совершенно простая модель, характерная для студентов ВУЗов. Именно по этой модели большинство студентов разрабатывают, ну скажем лабораторные работы.

Данная модель имеет следующий алгоритм:

1. Постановка задачи
2. Выполнение
3. Проверка результата
4. При необходимости переход к первому пункту

Модель также ужасно устаревшая. Характерна для 1960-1970 гг., по-этому преимуществ перед следующими моделями в нашем обзоре практически не имеет, а недостатки на лицо. Относится к первой группе моделей.

Каскадная модель жизненного цикла программного обеспечения (водопад)

Алгоритм данного метода, который я привожу на схеме, имеет ряд преимуществ перед алгоритмом предыдущей модели, но также имеет и ряд весомых недостатков.

Преимущества:

• Последовательное выполнение этапов проекта в строгом фиксированном порядке
• Позволяет оценивать качество продукта на каждом этапе

Недостатки:

• Отсутствие обратных связей между этапами
• Не соответствует реальным условиям разработки программного продукта

Относится к первой группе моделей.

Каскадная модель с промежуточным контролем (водоворот)

Данная модель является почти эквивалентной по алгоритму предыдущей модели, однако при этом имеет обратные связи с каждым этапом жизненного цикла, при этом порождает очень весомый недостаток: 10-ти кратное увеличение затрат на разработку. Относится к первой группе моделей.

V модель (разработка через тестирование)

Данная модель имеет более приближенный к современным методам алгоритм, однако все еще имеет ряд недостатков. Является одной из основных практик экстремального программирования.

Модель на основе разработки прототипа

Данная модель основывается на разработки прототипов и прототипирования продукта.
Прототипирование используется на ранних стадиях жизненного цикла программного обеспечения:

1. Прояснить не ясные требования (прототип UI)
2. Выбрать одно из ряда концептуальных решений (реализация сцинариев)
3. Проанализировать осуществимость проекта

Классификация протопипов:

1. Горизонтальные и вертикальные
2. Одноразовые и эволюционные
3. бумажные и раскадровки

Горизонтальные прототипы — моделирует исключительно UI не затрагивая логику обработки и базу данных.
Вертикальные прототипы — проверка архитектурных решений.
Одноразовые прототипы — для быстрой разработки.
Эволюционные прототипы — первое приближение эволюционной системы.

Модель принадлежит второй группе.

Спиральная модель жизненного цикла программного обеспечения

Спиральная модель представляет собой процесс разработки программного обеспечения, сочетающий в себе как проектирование, так и постадийное прототипирование с целью сочетания преимуществ восходящей и нисходящей концепции.

Преимущества:

• Быстрое получение результата
• Повышение конкурентоспособности
• Изменяющиеся требования — не проблема

Недостатки:

• Отсутствие регламентации стадий

Третьей группе принадлежат такие модели какэкстремальное программирование (XP), SCRUM, инкриментальная модель (RUP), но о них я бы хотел рассказать в отдельном топике.

Большое спасибо за внимание!

Важность обеспечения жизненного цикла вычислений в мире с нулевым доверием

В связи с увеличением количества поверхностей для атак в IoT, ростом числа атак на аппаратное обеспечение с использованием встроенного ПО и растущими угрозами для систем на протяжении всего их жизненного цикла компании начинают осваивать новые модель нулевого доверия для систем.

Обеспечение жизненного цикла вычислений

В течение последнего десятилетия ИТ-отделы часто требовали от конечных пользователей пройти аутентификацию, прежде чем им будет предоставлен доступ к системе или сети. Но в мире с нулевым доверием это требование распространяется не только на пользователя. Ни сама система, ни ее компоненты не считаются безопасными в любой момент времени. Это побудило компании проверять не только личность пользователей системы, но и целостность самих систем — на каждом этапе жизненного цикла.

Чтобы упростить эту модель нулевого доверия, все более важную роль играет гарантия жизненного цикла вычислений (CLA). CLA — это платформа, которая помогает анализировать и решать проблемы безопасности и целостности системы и ее компонентов на протяжении всего ее жизненного цикла.

Жизненный цикл разбит на четыре отдельных этапа: создание, эксплуатация, передача и вывод из эксплуатации. Эти системы (например, процессоры или другие вычислительные элементы) подвержены риску из-за подделок, подделок или даже устаревших версий микропрограмм. И во многих из этих случаев ИТ-отдел не видит проблемы. Атаки могут происходить на производстве на этапе сборки или во время повседневного использования системы на этапе эксплуатации.

Учитывая, что в 2020 году среднее время, необходимое для выявления нарушения, составляло 228 дней (по данным IBM), CLA предлагает еще один важный уровень безопасности.

Но как каждый этап схемы CLA помогает при нулевом доверии? Давайте погрузимся в каждый из них более подробно.

Zero Trust Build

Во время производства и сборки существует некоторый риск того, что системы получат поддельные или запасные части, которые могут быть либо вредоносными, либо непреднамеренно уязвимыми для будущих атак. Например, в настоящее время возобновилась озабоченность по поводу поддельных чипов из-за нехватки цепочки поставок.

Compute Lifecycle Assurance рекомендует компаниям иметь способ проверки того, что они заказали, это то, что они получили — не только на уровне системы, но и на уровне компонента, если компонент работает с активной прошивкой. Активная прошивка может быть путем к оборудованию, поэтому важно, чтобы она не была подделана и была обновлена.

Как компании могут проверить технологию на этапе сборки? Один из подходов заключается в использовании решений, которые собирают информацию об аппаратных компонентах по мере того, как они создаются, непосредственно из блока управления в цехе, а затем надежно и уникально сохраняют ее на каждом устройстве и предоставляют клиентам возможность самостоятельно извлекать данные и просматривать полную ведомость. материалы и отчет о прослеживаемости их систем.

Эти подходы иногда используют модель реестра или базы данных. Возьмем, к примеру, производителя ноутбуков: это позволит им проверять подлинность компонентов (например, материнской платы или сервера), установленной прошивки и конфигурации системы путем сбора всей производственной информации и безопасной отправки ее на удаленный сервер. для проверки позже.

Передача с нулевым доверием

Ограбление на дороге в эпоху цифровых технологий выглядит иначе. Сегодня системы могут быть взломаны или скомпрометированы, когда они физически находятся в пути от места производства до конечного местоположения (Microsoft более подробно исследует эту тему здесь). Например, твердотельный накопитель, отправленный производителю оригинального дизайна для интеграции в вычислительную систему можно было подделать, заменив прошивку на диске вредоносной версией.

Организации усердно работают над устранением этих типов проблем с помощью различных методов, включая требования к безопасности объектов, такие как камеры видеонаблюдения, контроль доступа и т. д., а также с помощью уровней транспортной безопасности, таких как упаковка с защитой от несанкционированного доступа, проверка безопасности доставки проходы, замки, целостность контейнеров, GPS-трекинг и многое другое.

Посмотрите, как Dell использует требования Ассоциации защиты транспортируемых активов (TAPA) или Системы управления поставщиками HP. Кроме того, служба обеспечения жизненного цикла вычислений рекомендует убедиться в том, что система по-прежнему точно соответствует заказу при получении на месте в компании после этапов сборки и передачи.

Операция с нулевым доверием

В операции есть несколько подэтапов, каждый из которых имеет свои риски, такие как подготовка (может быть на месте или удаленно), ежедневное использование и обновление. CLA рекомендует проводить минимальную проверку целостности системы перед предоставлением системы в сеть или ее назначением конечному пользователю. Для еще более высокого уровня безопасности компании могут требовать от систем самоаутентификации каждый раз, когда они пытаются получить доступ к сети, чтобы гарантировать, что они находятся в заведомо хорошем состоянии. Это означает проверку между использованиями, что прошивка системы обновлена ​​и не была подделана, а физические компоненты системы, такие как твердотельный накопитель, не были заменены на неизвестную замену.

Как это сделать? Один из подходов восходит к моделям бухгалтерской книги и базы данных. Например, с помощью модели бухгалтерской книги после доставки вычислительной системы заказчику можно проверить первоначальные записи о сборке и вести непрерывный учет изменений. Другой подход — самоотчет.

Когда устройство оказывается в руках конечного пользователя, оно может предоставить криптографический отчет о текущей конфигурации всех интеллектуальных компонентов в устройстве (или полный отчет на уровне системы).

Zero Trust Retire

Часто системы или их компоненты повторно используются в сценарии второй жизни. Данные необходимо полностью стереть, особенно перед повторной передачей другому пользователю или для другой цели. CLA также рекомендует убедиться, что система возвращена ИТ-отделу в том же состоянии, в котором она была предоставлена ​​во временное пользование. Должна быть запись о любых изменениях физического компонента или микропрограммы, включая обновления, сделанные в системе во время ее работы, и каждое из них должно быть учтено.

Как это сделать? Активы должны быть однозначно идентифицированы и отслеживаться по мере их утилизации. Однако есть много случаев, когда компании утилизировали оборудование, не проверив, что данные были стерты. Сертификаты уничтожения могут быть подделаны, поэтому важно обеспечить доказательства и информацию о цепочке хранения.

Поставщики оборудования должны инвестировать в методы, инструменты и технологии в своих экосистемах, чтобы помочь клиентам и партнерам проверять целостность системы на каждом этапе жизненного цикла. Платформа обеспечения жизненного цикла вычислений призвана помочь организациям достичь этой цели.

Гарантия жизненного цикла для целостности и безопасности платформы

Том Гаррисон, вице-президент и генеральный менеджер по стратегии безопасности клиентов

Современные цепочки поставок глобальны, сложны и часто непрозрачны. Это создает множество проблем, от проектирования и ответственного поиска до развертывания и безопасного вывода из эксплуатации. Большинство платформ несколько раз меняют условия хранения, владения и физического местоположения в ходе сборки, транспортировки и подготовки. Чтобы обеспечить целостность на каждом этапе жизненного цикла вычислений, при проектировании, архитектуре и создании этих технологий необходим подход, ориентированный на безопасность. Чтобы помочь решить эту проблему, Intel работает с экосистемой клиентов и партнеров над новой инициативой Compute Lifecycle Assurance Initiative, призванной предоставить комплексную структуру, включающую инструменты и решения для повышения целостности, отказоустойчивости и безопасности платформы.

Чтобы понять, куда движется эта инициатива, важно сначала взглянуть на то, что было сделано в прошлом. Призыв к обеспечению гарантий во всей цепочке поставок формировался на протяжении десятилетий. На самом деле, несколько примеров связаны с социальной ответственностью и устойчивостью. Например, в 2004 году был создан Альянс ответственных предпринимателей для решения основных проблем, связанных с правами и благополучием работников и сообществ во всем мире. В последнее время политики начали по-новому сосредотачиваться на рисках цепочки поставок. Закон о SECURE Technology Act от 2018 года дал федеральным агентствам США новые полномочия учитывать риски цепочки поставок при закупке продуктов.

Технологические компании тоже внесли свой вклад. Например, за последние несколько лет корпорация Intel предприняла несколько важных шагов по обеспечению прозрачности цепочки поставок, в том числе стала одной из первых компаний, предоставивших инструменты Intel® Transparent Supply Chain (TSC) — набор политик и процедур, внедренных на заводах для обеспечения прозрачности. в критические компоненты, которые использовались для производства ПК или сервера на базе процессоров Intel.

Сегодня Intel TSC доступен клиентам на различных платформах, включая ПК на базе Intel® Core™, Intel® NUC, системы Intel® Xeon® SP и твердотельные накопители Intel®. Помимо наших собственных платформ, мы предоставили партнерам по экосистеме инструменты Intel TSC, включая Hyve Solutions, Inspur, Lenovo (клиент и сервер), Mitac, Quanta, Supermicro и ZT Systems.

Несмотря на то, что это были большие первые шаги к прозрачности и целостности, можно сделать больше. Это цель инициативы Intel Compute Lifecycle Assurance (CLA). Основополагающим принципом этой инициативы является исправность аппаратного и микропрограммного обеспечения устройств во всей системе — не только в первый день, но и на всех этапах жизненного цикла вычислений. Инициатива устанавливает сквозную структуру, которую можно применять на протяжении всего жизненного цикла любой платформы, чтобы существенно улучшить ее целостность, отказоустойчивость и безопасность.

В качестве примечания: отраслевая рабочая группа Национального управления по телекоммуникациям и информации (NTIA) уже подготовила спецификацию программного обеспечения с первоначальным набором результатов, предназначенных для решения аналогичных задач в цепочке поставок программного обеспечения. Подобно подходу Intel к жизненному циклу вычислительной платформы, их работа дополняет друг друга и способствует значительным изменениям в экосистеме программного обеспечения.

Чтобы решить отраслевые проблемы, корпорация Intel стремится инвестировать в инструменты и процессы, повышающие целостность вычислительных продуктов на каждом этапе жизненного цикла, опираясь на инструменты прозрачной цепочки поставок, которые у нас есть сегодня.

Мы видим четыре ключевых этапа Инициативы Compute Lifecycle Assurance: сборка, передача, эксплуатация и вывод из эксплуатации, предназначенные для обеспечения лучшего понимания состояния платформы на каждом этапе: архитектуры и дизайна компонентов Intel с целью использования последних результатов исследований в области безопасности и методов обеспечения безопасности мирового класса для сведения к минимуму возможностей для атак. Мы включаем производство платформ (ПК, серверов, SSD и т.д.). Мы считаем, что эта фаза сборки должна начинаться с уровня компонентов и продолжаться до производства платформы, чтобы обеспечить полную картину создания платформы.

Передача — этот этап начинается с док-станции производственного предприятия и заканчивается прибытием устройства к заказчику. На этом этапе важно обнаружить фальсификацию, модификацию или изменения в оборудовании, прошивке и программном обеспечении с момента изготовления устройства. Мы также внедрим механизмы, предназначенные для определения того, кто должен или не должен иметь права изменять платформу во время распространения.

Вывод из эксплуатации — Эта фаза начинается, когда устройство выводится из эксплуатации либо навсегда, либо для повторного использования для вторичного клиента/рынка. Мы разработаем инструменты, которые помогут обеспечить конфиденциальное удаление всех данных с диска и платформы.

Чтобы увидеть, как Compute Lifecycle Assurance идеально работает на практике, давайте рассмотрим пример закупок. Когда отдел снабжения размещает заказ и получает устройство на своей док-станции, они имеют полную информацию об этом устройстве. В соответствии с новой структурой это включает в себя обеспечение того, чтобы устройство включало в себя необходимые компоненты, которые были заказаны (например, тип процессора, тип твердотельного накопителя и т. д.), и не включало какие-либо компоненты из черного списка от поставщиков, которые представляют высокий риск с точки зрения безопасности или качества. Кроме того, будет предоставлена ​​гарантия того, что состояние устройства не изменилось неожиданно с момента изготовления, включая ключевые аппаратные компоненты и версии встроенного ПО. Наконец, будет доступ к инструментам управления, способным составлять отчеты и оценивать состояние безопасности парка с данными, считываемыми с каждого устройства.

Обеспечение гарантий имеет решающее значение для отрасли, и сотрудничество является ключом к созданию успешной инициативы CLA. Во всем мире политики уже начали по-новому сосредотачиваться на рисках цепочки поставок.

Коммерческие предприятия по всему миру должны оценить этот повышенный уровень гарантии, а также проверки, соответствия и управления. В ближайшие 12–18 месяцев наши команды в Intel ожидают увидеть растущий интерес со стороны клиентов, партнеров и государственных надзорных организаций к прозрачности, выходящей за рамки только цепочки производственных поставок, включая транспортировку, подготовку, аттестацию и обновления на местах. Наше путешествие с CLA только начинается, и мы приглашаем более широкую экосистему присоединиться к нам, поскольку мы создаем более надежную основу для всех вычислительных систем.

Об авторе

Том Гаррисон (Tom Garrison) — вице-президент Client Computing Group и генеральный менеджер по стратегиям и инициативам в области безопасности (SSI) корпорации Intel. Он возглавляет группу, отвечающую за усилия Intel по повышению безопасности клиентов и оказанию помощи заказчикам и производителям в развертывании инструментов и процессов для обеспечения большей безопасности и прозрачности цепочки поставок.