ЖЦПО – это непрерывный процесс, который начинается с момента принятия решения о необходимости создания ПО и заканчивается в момент его полного изъятия из эксплуатации.
Существует несколько подходов при определении фаз и работ жизненного цикла программного обеспечения (ЖЦПО), шагов процесса программирования, каскадная и спиральная модели. Но все они содержат общие основополагающие компоненты: постановка задачи, проектирование решения, реализация, обслуживание.
ВВЕДЕНИЕ 2
1. ЖИЗНЕННЫЙ ЦИКЛ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ 3
2. ПРОЦЕССЫ ЖЦ ПО 7
3. ВСПОМОГАТЕЛЬНЫЕ ПРОЦЕССЫ ЖЦ ПО 8
ЗАКЛЮЧЕНИЕ 14
ЛИТЕРАТУРА 15
Прикрепленные файлы: 1 файл
1. ЖИЗНЕННЫЙ ЦИКЛ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ 3
2. Процессы ЖЦ ПО 7
3. Вспомогательные процессы ЖЦ ПО 8
ВВЕДЕНИЕ
ЖЦПО – это непрерывный процесс, который начинается с момента принятия решения о необходимости создания ПО и заканчивается в момент его полного изъятия из эксплуатации.
Существует несколько подходов при определении фаз и работ жизненного цикла программного обеспечения (ЖЦПО), шагов процесса программирования, каскадная и спиральная модели. Но все они содержат общие основополагающие компоненты: постановка задачи, проектирование решения, реализация, обслуживание.
Лекция #2 — Жизненный цикл программ | Игнатьев Александр
Наиболее известной и полной, пожалуй, является структура ЖЦПО по Боэму, включающая восемь фаз. Она и будет представлена в дальнейшем наиболее подробно.
Кроме трех процессов ЖЦ ПО мы еще просмотрели вспомогательные процессы жизненного цикла. Я постарался дать четкий ответ на вышеуказанные темы. По ходу работу мы ознакомимся более подробно об ЖЦ ПО и и о вспомогательных процессов ЖЦ ПО
- ЖИЗНЕННЫЙ ЦИКЛ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
Значительное место среди информационных продуктов и услуг занимают компьютерные программные средства.
Жизненный цикл создания и использования компьютерных программ отражает различные их состояния, начиная с момента возникновения необходимости в данном программном изделии и заканчивая моментом его полного выхода из употребления у всех пользователей. Традиционно выделяют следующие основные этапы жизненного цикла программного обеспечения:
- анализ требований,
- проектирование,
- кодирование (программирование),
- тестирование и отладка,
- эксплуатация и сопровождение.
Особенностью разработки программного продукта является принятие решений на начальных этапах с их реализацией на последующих этапах. Ошибки в требованиях к программному продукту способны привести не только к потерям на этапах разработки и эксплуатации, но и к провалу проекта. Внесение изменений в спецификацию программного продукта чаще всего вызывает необходимость повторить все следующие этапы проектирования и создания программного продукта.
В коммерческом программном обеспечении жизненный цикл определяется моментом начала его продаж.
Разработчики стремятся сделать максимально возможным период жизненного цикла информационных продуктов и услуг. Для большинства современных компьютерных программ длительность жизненного цикла равна двум–трём годам, хотя встречаются программы, существующие десять и более лет.
Видео 22. Жизненный цикл ПО. Этапы разработки ПО. Классическая модель разработки ПО
Для увеличения этого периода необходимо постоянно осуществлять маркетинговые и иные мероприятия по их поддержке. Падение продаж и интереса к информационным продуктам и услугам является сигналом к:
а) изменению программного продукта и услуг,
б) изменению цены на них,
в) проведению модификации или снятию с продажи и предоставления.
Графическая модель жизненного цикла продукта или услуги, предложенная зарубежными специалистами в 1991 году, приведена на рис. 1.
Рис. 1. Графическая модель жизненного цикла продуктов и услуг.
Обычно, под термином “программный продукт” для компьютерных информационных технологий принято понимать необходимое им программное обеспечение (ПО).
Основной нормативный документ, регламентирующий ЖЦ ПО – международный стандарт ISO/IEC 12207 (ISO, International Organization of Standardization – Международная организация по стандартизации, IEC, International Electrotechnical Commission – Международная комиссия по электротехнике). Он определяет структуру ЖЦ, содержащую процессы, действия и задачи, выполняемые во время создания ПО.
Согласно этому стандарту, структура ЖЦ ПО базируется на трёх группах процессов:
1) основные процессы ЖЦ ПО (приобретение, поставка, разработка, эксплуатация, сопровождение);
2) вспомогательные процессы (документирование, управление конфигурацией, обеспечение качества, верификация, аттестация, оценка, аудит, решение проблем);
3) организационные процессы (управление проектами, создание инфраструктуры проекта, определение, оценка и улучшение самого ЖЦ, обучение).
Разработка ПО – это, как правило, анализ, проектирование и реализация (программирование). Она включает все работы по созданию ПО и его компонент в соответствии с заданными требованиями, в том числе оформление проектной и эксплуатационной документации, подготовку материалов, необходимых для проверки работоспособности и соответствующего качества программных продуктов, материалов, для организации обучения персонала и т.д.
Эксплуатация включает работы по внедрению компонентов ПО в эксплуатацию, в том числе конфигурирование БД и рабочих мест пользователей, обеспечение эксплуатационной документацией, проведение обучения персонала и т.д., и непосредственно эксплуатацию, в том числе локализацию проблем и устранение причин их возникновения, модификацию ПО в рамках установленного регламента, подготовку предложений по совершенствованию, развитию и модернизации системы.
Управление проектом связано с вопросами планирования и организации работ, создания коллективов разработчиков; контроля за сроками и качеством выполняемых работ.
Техническое и организационное обеспечение проекта включает выбор методов и инструментальных средств для реализации проекта, определение методов описания промежуточных состояний разработки, разработку методов и средств испытаний ПО, обучение персонала и т.п.
Обеспечение качества проекта связано с проблемами верификации, проверки и тестирования ПО.
Верификация – это процесс определения насколько текущее состояние разработки, достигнутое на данном этапе, отвечает требованиям этого этапа.
Оценка качества (ГОСТ 28195-89) осуществляется на всех этапах жизненного цикла программных средств (ПС) при:
- планировании показателей качества ПС;
- контроле качества на отдельных этапах разработки (техническое задание, технический проект, рабочий проект);
- контроле качества в процессе производства ПС;
- проверке эффективности модификации ПС в процессе сопровождения.
Проверка позволяет оценить соответствие параметров разработки с исходными требованиями. Проверка частично совпадает с тестированием, связанным с выявлением различий между действительными и ожидаемыми результатами, а также оценкой соответствия характеристик ПО исходным требованиям.
Под тестированием понимается процесс исполнения программы с целью обнаружения ошибок.
В процессе реализации проекта важное место занимают вопросы идентификации, описания и контроля конфигурации отдельных компонентов и всей системы в целом.
Управление конфигурацией – один из вспомогательных процессов, поддерживающих основные процессы жизненного цикла ПО, прежде всего процессы разработки и сопровождения ПО ИС.
Управление конфигурацией позволяет организовать, систематически учитывать и контролировать внесение изменений в ПО на всех стадиях ЖЦ. Общие принципы и рекомендации конфигурационного учёта, планирования и управления конфигурациями ПО отражены в проекте стандарта ISO/IEC 12207.
Жизненный цикл информационных продуктов и услуг составляет основу жизненного цикла информационных технологий и, соответственно, информационных систем. Следовательно, всё сказанное выше относится и к информационным системам.
Одним из базовых понятий проектирования ИС является понятие жизненного цикла её программного обеспечения (ЖЦ ПО) – это непрерывный процесс, начинающийся с момента принятия решения о необходимости создания ПО и заканчивается в момент его полного изъятия из эксплуатации.
ИС входят в состав СУБД и являются специфическим инструментальным и прикладным (пользовательским) программным обеспечением.
Жизненный цикл ИС представляет собой модель её создания и использования. Модель отражает различные состояния ИС, начиная с момента возникновения необходимости в данной ИС и заканчивая моментом её полного выхода из употребления у всех пользователей.
В соответствии со стандартом ГОСТ Р ИСО/МЭК 12207-99 все процессы ЖЦ ПО разделены на три группы:
- Основные процессы
- приобретение
- поставка
- разработка
- эксплуатация
- сопровождение (модификация и исправление системы в случае обнаружения неполадок или возникновении новых требований)
- документирование (формализован ное описание информации, созданной в течение ЖЦ ПО)
- управление конфигурацией (применение административных и технических процедур на всем протяжении ЖЦ ПО для определения состояния компонентов ПО в системе, управления модификациями ПО, описания и подготовки отчетов о состоянии компонентов ПО и запросов на модификацию, обеспечения полноты, совместимости и корректности компонентов ПО, управления хранением и поставкой ПО)
- обеспечение качества (обеспечение соответствующих гарантии того, что ПО и процессы его ЖЦ соответствуют заданным требованиям и утвержденным планам)
- верификация (определение того, что программные продукты, являющиеся результатами некоторого действия, полностью удовлетворяют требованиям или условиям, обусловленным предшествующими действиями)
- аттестация (подтверждение и оценка достоверности проведенного тестирования ПО)
- совместная оценка (оценка состояния работ по проекту и ПО, создаваемому при выполнении данных работ)
- аудит (определение соответствия требованиям, планам и условиям договора)
- разрешение проблем
- управление (управление выпуском продукта, управление проектом и задачами соответствующих процессов, таких, как приобретение, поставка, разработка, эксплуатация, сопровождение и др.)
- инфраструктура (выбор и поддержка (сопровождение) технологии, стандартов и инструментальных средств, выбор и установка аппаратных и программных средств, используемых для разработки, эксплуатация или сопровождение ПО)
- усовершенствование (оценка, измерение, контроль и усовершенствование процессов ЖЦ ПО)
- обучение (первоначальное обучение и последующее постоянное повышение квалификации персонала)
- Вспомогательные процессы ЖЦ ПО
Процесс документирования предусматрива ет формализованное описание информации, созданной в течение ЖЦ ПО. Данный процесс состоит из набора действий, с помощью которых планируют, проектируют, разрабатывают, выпускают, редактируют, распространяют и сопровождают документы, необходимые для всех заинтересованных лиц, таких, как руководство, технические специалисты и пользователи системы.
Процесс документирования включает действия:
- подготовительную работу;
- проектирование и разработку;
- выпуск документации;
- сопровождение.
Процесс управления конфигурацией предполагает применение административных и технических процедур на всем протяжении ЖЦ ПО для определения состояния компонентов ПО в системе, управления модификациями ПО, описания и подготовки отчетов о состоянии компонентов ПО и запросов на модификацию, обеспечения полноты, совместимости и корректности ПО, управления хранением и поставкой ПО. Согласно стандарте IEEE — 90 под конфигурацией ПО понимается совокупность ее функциональных и физических характеристик, установленных в технической документации и реализованных в ПО.
Управление конфигурацией позволяет организовать, систематически учитывать и контролировать внесение изменений в ПО на всех стадиях ЖЦ ПО. Общие принципы и рекомендации по управлению конфигурацией ПО отражены в проекте стандарта ISO/IEC 12207-2: 1995 “Information Technology — Software Life Cycle Processes. Part2. Configuration Management for Software”.
Процесс управления конфигурацией включает действия:
- подготовительную работу (планирование управления конфигурацией);
- идентификацию конфигурации (устанавливает правила, с помощью которых можно однозначно идентифицировать и различать компоненты ПО и их версии). Кроме того, каждому компоненту и его версиям соответствует однозначно обозначаемый комплект документации. В результате создается база для однозначного выбора и манипулирования версиями компонентов ПО, использующая ограниченную и упорядоченную систему символов, идентифицирующих различные версии ПО.
- контроль конфигурации (предназначен для систематической оценки предполагаемых модификаций ПО и координированной их реализации с учетом эффективности каждой модификации и затрат на ее выполнение). Он обеспечивает адекватность реально изменяющихся компонентов и их комплектной документации;
- учет состояния конфигурации (представляет собой регистрацию состояния компонентов ПО, подготовку отчетов обо всех реализованных и отвергнутых модификациях версий компонентов ПО). Совокупность отчетов обеспечивает однозначное отражение текущего состояния системы и ее компонентов, а также ведение истории модификаций;
- оценку конфигурации (заключается в оценке функциональной полноты компонентов ПО, а также соответствия их физического состояния текущему техническому описанию);
- управление выпуском и поставку (охватывают изготовление эталонных копий программ и документации, их хранение и поставку пользователям в соответствии с порядком, принятым в организации).
Источник: www.referat911.ru
Вопрос 2. Жизненный цикл программного обеспечения. Модели жизненного цикла на примере разработки программного обеспечения » Microsoft Word «.
Вопрос 2. Жизненный цикл программного обеспечения. Модели жизненного цикла на примере разработки программного обеспечения “ Microsoft Word ”.
В основе деятельности по созданию и использованию ПО лежит понятие его жизненного цикла (ЖЦ).
ЖЦ является моделью создания и использования ПО , отражающей его различные состояния, начиная с момента возникновения необходимости в данном программном изделии и заканчивая моментом его полного выхода из употребления у всех пользователей.
Длительность ЖЦ для различных ПП неодинакова и для большинства современных ПП измеряется в годах (2-3 года). Хотя достаточно часто встречаются на компьютерах и давно снятые с производства ПП.
Стандарт определяет структуру ЖЦ , содержащую процессы, действия и задачи, которые должны быть выполнены во время создания и использования ПО . В России создание ПО первоначально, в 70-е гг., регламентировалось стандартами серии ГОСТ 19.ХХХ — Единая система программной документации ( ЕСПД ) и ГОСТ 34.ХХХ — Комплекс стандартов на АС. Однако создание, сопровождение и развитие современного прикладного ПО высокого качества в этих стандартах отражено недостаточно, а отдельные их положения устарели. Эти стандарты вынуждены использовать предприятия, выполняющие государственные заказы при создании ПО для внутреннего применения. Однако в экспортных заказах зарубежные клиенты требуют соответствия технологии проектирования, производства и качества продукции современным международным стандартам.
Основным зарубежным нормативным документом, наиболее полно и подробно регламентирующим ЖЦ ПО , является международный стандарт ISO/IEC 12207 . ( ISO — International Organization of Standardization — Международная организация по стандартизации, IEC — International Electrotechnical Commission — Международная комиссия по электротехнике.)
Под моделью ЖЦ понимается структура, определяющая последовательность выполнения и взаимосвязи процессов, действий и задач, выполняемых на протяжении ЖЦ ПО .
Модель ЖЦ зависит от специфики ПО и специфики условий, в которых оно создается и функционирует. Стандарт ISO/IEC 12207 не предлагает конкретную модель ЖЦ и методы разработки ПО . Его регламенты являются общими для любых моделей ЖЦ, методологий и технологий разработки. Стандарт ISO/IEC 12207 описывает структуру процессов ЖЦ ПО , но не конкретизирует в деталях, как реализовать или выполнить действия и задачи, включенные в эти процессы.
Модель ЖЦ любого конкретного ПО определяет характер процесса его создания. Процесс создания ПО представляет собой совокупность упорядоченных во времени, взаимосвязанных и объединенных в этапы работ , выполнение которых необходимо и достаточно для создания ПО, соответствующего заданным требованиям.
Под этапом создания ПО понимается часть процесса создания ПО , ограниченная некоторыми временными рамками и заканчивающаяся выпуском конкретного продукта (моделей ПО, программных компонентов, документации), определяемого заданными для данной стадии требованиями. Этапы создания ПО выделяются по соображениям рационального планирования и организации работ, заканчивающихся заданными результатами.
В состав ЖЦ ПО обычно включаются следующие этапы: 1. Формирование требований, предъявляемых к ПО. 2. Проектирование структуры ПО. 3. Реализация. 4. Тестирование. 5. Ввод в действие.
6. Эксплуатация и сопровождение. 7. Снятие с эксплуатации.
На каждом этапе могут выполняться несколько процессов, определенных в стандарте 1SO/IEC 12207, и, наоборот, один и тот же процесс может выполняться на различных этапах.
Существующие модели ЖЦ определяют порядок исполнения этапов в ходе разработки, а также критерии перехода от этапа к этапу. К настоящему времени наибольшее распространение получили следующие три основные модели ЖЦ : 1) Каскадная модель (70-80 гг.) — предполагает переход на следующий этап после полного завершения работ предыдущего этапа. 2) Поэтапная модель с промежуточным контролем (80-85 гг.) — итерационная модель разработки ПО с циклами обратной связи между этапами. 3) Спиральная модель (86-90 гг.) — делает упор на начальные этапы ЖЦ (анализ требований, проектирование спецификаций , предварительное и детальное проектирование).
Основные характеристики каскадного способа : разбиение всей разработки на этапы; переход с одного этапа на следующий происходит только после полного завершения работы на текущем этапе (см. рис); возможность планировать сроки завершения всех работ и соответствующие затраты ; результатами каждого этапа являются технические решения и полный комплект проектной документации , отвечающей критериям полноты и согласованности, достаточной для того, чтобы разработка могла быть продолжена другой командой разработчиков; исходными для каждого этапа являются документы и решения, полученные на предыдущем этапе. См. Рис.
Каскадный подход хорошо зарекомендовал себя при разработке не сложного ПО , когда каждая программа представляет собой единое целое. При построении такого ПО в самом начале разработки можно достаточно точно и полно сформулировать все требования, с тем, чтобы предоставить разработчикам свободу реализовать их как можно лучше с технической точки зрения.
Основной недостаток каскадного подхода : требования к ПО «заморожены» в виде технического задания на все время его создания. Пользователи могут внести свои замечания только после того, как работа над ПО будет полностью завершена. В случае неточного изложения требований или их изменения в течение длительного периода создания ПО , пользователи получают систему, не удовлетворяющую их потребностям. Модели (как функциональные, так и информационные) автоматизируемого объекта могут устареть одновременно с их утверждением.
В модели с промежуточным контролем (разновидности каскадной модели) межэтапные корректировки обеспечивают большие гибкость и надежность по сравнению с каскадной моделью, хотя и увеличивают весь период создания.
Спиральная модель ЖЦ (см. рис), делающая упор на начальные этапы ЖЦ: анализ требований, определение спецификаций и проектирование (предварительное и детальное) .
На этих этапах реализуемость технических решений проверяется путем создания прототипов приложений , которые демонстрируются заказчику, обсуждаются.
Под прототипом обычно понимают набор программ, моделирующих (изображающих, эмулирующих) работу готовой системы. Цель прототипирования — более ясно представить себе будущую систему, предугадать ее недостатки на этапе проектирования, внести необходимые коррективы в техническое задание и технический проект, если он уже готов.
Прототип системы удобно демонстрировать сотрудникам предприятия-заказчика, чтобы они могли понять, насколько удобно им будет пользоваться системой, какие функции следует добавить или исключить. Каждый виток спирали соответствует созданию фрагмента или версии ПО , на нем уточняются цели и характеристики проекта, определяется его качество и планируются работы следующего витка спирали.
Таким образом, углубляются и последовательно конкретизируются детали проекта. Разработка итерациями отражает объективно существующий спиральный цикл создания ПО . Неполное завершение работ на каждом этапе позволяет переходить на следующий этап, не дожидаясь полного завершения работы на текущем этапе.
При итеративном способе разработки недостающую работу можно будет выполнить на следующей итерации. Главная задача — как можно быстрее показать пользователям работоспособный продукт, тем самым, активизируя процесс уточнения и дополнения требований, исправления ошибок, обусловленных неопределенностью или некорректностью технических заданий и спецификаций требований.
Спиральная модель не исключает использования каскадного подхода на завершающих стадиях проекта в тех случаях, когда требования к системе оказываются полностью определенными. Основная проблема спирального цикла — определение момента перехода на следующий этап. Для ее решения необходимо ввести временные ограничения на каждый из этапов ЖЦ.
Переход осуществляется в соответствии с планом, даже если не вся запланированная работа закончена. План составляется на основе статистических данных, полученных в предыдущих проектах, и личного опыта разработчиков. Другими недостатками спиральной модели являются: трудоемкость внесения изменений; большой объем документации по проекту, затрудняющий программирование; сложность переноса на другие платформы.
Пример: при разработке “ Microsoft Word ” на этапе формирования требований к ПО, были выдвинуты функциональные требования к ПО (ввод, редактирование текста, проверка орфографии, применение различных стилей печати текста, распечатка, сохранение текста и т.д.). Было утверждено ТЗ, после его утверждения, вносить изменения нельзя. Поэтому, к аскадный подход хорошо зарекомендовал себя при разработке не сложного ПО, когда каждая программа представляет собой единое целое и не подходит для разработки такого ПО как “ Microsoft Word ”. При построении несложного ПО в самом начале разработки можно достаточно точно и полно сформул-ть все треб-ия , с тем, чтобы предоставить разработчикам свободу реализовать их как можно лучше с технической точки зрения.
Источник: dmtsoft.ru
Технология разработки ПО
Специфические модели жизненного цикла определяют более конкретные процессы разработки. Отличаются они от стандартов, прежде всего большей детальностью и четким описанием связей между отдельными видами деятельности, определением потоков данных (документов и артефактов) в ходе жизненного цикла.
Каскадная (водопадная) модель
Эта модель предполагает последовательное выполнение различных видов деятельности, начиная с выработки требований и заканчивая сопровождением, с четким определением границ между этапами, на которых набор документов, созданный на предыдущей стадии, передается в качестве входных данных для следующей.
Поэтапная модель с промежуточным контролем еще известна как итерационная модель или «водоворот»
Поэтапная модель с промежуточным контролем — это итерационная модель разработки ИС с циклами обратной связи между этапами. Преимущество такой модели заключается в том, что межэтапные корректировки обеспечивают меньшую трудоемкость по сравнению с каскадной моделью, однако время жизни каждого из этапов растягивается на весь период разработки.
Модель характеризуется следующими свойствами взаимодействия этапов:
— модель состоит из последовательно расположенных этапов (точно так же, как и «водопад»);
— каждый этап имеет обратную связь с предыдущими этапами;
— исправление ошибок происходит на каждом из этапов, сразу при выявлении проблемы — это промежуточный контроль;
— этапы перекрываются во времени по причине наличия обратной связи: следующий этап не начинается, пока не завершится предыдущий; при первом проходе по модели вниз, как только обнаружена ошибка, осуществляется возврат снизу вверх к предыдущим этапам, которые повлекли ошибку. Таким образом, фактически этапы оказываются растянутыми во времени;
— результат появляется только в конце разработки, как и в модели «водопад».
Критерием появления результата при модели «водоворот» является приемлемое качество продукта, то есть такое состояние продукта, когда наиболее критические для клиента ошибки устранены, а с наличием непринципиальных для жизнедеятельности системы ошибок клиент согласился — данные ошибки описаны в документации и фактически переведены таким образом в разряд особенностей системы.
Спиральная модель
Развитием идеи итераций является спиральная модель ЖЦПО, предложенная Боэмом. — модель состоит из последовательно расположенных этапов (как и «водопад») в пределах одного витка спирали;
— внутри витка спирали этапы не имеют обратной связи. Анализ результата осуществляется в конце витка и инициирует новый виток спирали;
— исправление ошибок происходит на этапе тестирования на каждом из витков спирали. Фактически часть ошибок исправляется в пределах одного витка посредством связи этапов кодирования и тестирования. Ошибки, которые не могут быть исправлены и требуют более глубоких структурных изменений, инициируют новый виток спирали;
— этапы могут перекрываться во времени в пределах одного витка спирали;
— результат появляется в конце каждого витка спирали и подвергается подробному анализу, анализируются новые требования заказчика и инициируется новый виток спирали;
— при переходе от витка к витку происходит накопление и повторное использование программных средств, моделей и прототипов;
— процесс ориентирован на развитие и модификацию системы в процессе ее проектирования, на анализ рисков и издержек в процессе проектирования.
Одним из возможных подходов к разработке прикладного ПО в рамках спиральной модели ЖЦ является получивший широкое распространение способ так называемой быстрой разработки приложений, или RAD (Rapid Application Development). Подход RAD предусматривает наличие трех составляющих:
• небольших групп разработчиков (от 3 до 7 человек), выполняющих работы по проектированию отдельных подсистем ПО. Это обусловлено требованием максимальной управляемости коллектива;
• короткого, но тщательно проработанного производственного графика (до 3 месяцев);
• повторяющегося цикла, при котором разработчики по мере того, как приложение начинает обретать форму, запрашивают и реализуют в продукте требования, полученные в результате взаимодействия с заказчиком.
Команда разработчиков должна представлять собой группу профессионалов, имеющих опыт в проектировании, программировании и тестировании ПО, способных хорошо взаимодействовать с конечными пользователями и трансформировать их предложения в рабочие прототипы.
Источник: technologiarpo.blogspot.com