Определи последовательность этапов разработки программы

В этой статье мы, команда разработчиков Sibdev, расскажем о деталях создания мобильных приложений с опорой на собственный опыт.

Иерархия процессов

1. Продуктовая аналитика.
2. Спецификация и вайрфреймы.
3. Оценка и планирование.
4. Дизайн.
5. Программирование.
6. Тестирование.
7. Запуск.

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

• Продуктовая аналитика

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

1. сегментировать целевую аудиторию (ЦА);
2. определить популярные модели взаимодействия пользователей с аналогичными сервисами;
3. изучить конкурентоспособность продукта;
4. сформулировать уникальное торговое предложение (УТП);
5. построить гипотезы, объясняющие мотивы поведения посетителей;
6. сформировать критерии минимально жизнеспособного продукта (minimum viable product, MVP).

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

Проектирование / Разработка программы. Этапы создания программы. Блок-схема и псевдокод.

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

• Спецификация и вайрфреймы

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

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

1. введение — цели, термины, представление ЦА, масштаб проекта;
2. описание — видение и функциональность программы, детальная классификация пользователей, операционная среда, стандарты, предположения и зависимости;
3. требования к внешним интерфейсам — пользовательскому (UX), программному, оборудования и коммуникаций;
4. нефункциональные требования — производительность, конфиденциальность данных и безопасность системы, критерии качества продукта;
5. прочее — глоссарий, каталог моделей процессов, перечень базовых задач.

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

Что такое UML за 7 минут: Диаграмма классов, последовательностей, состояний и деятельности

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

Пример спецификации мобильного приложения

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

Примеры вайрфреймов мобильного приложения

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

• Оценка и планирование

1. демонстрация структуры продукта (общий объем работ);
2. расписание участия в проекте профильных специалистов;
3. стоимость работ;
4. сроки реализации;
5. оценка вероятности наступления рисковых ситуаций с перечнем мер по предотвращению и ликвидации последствий.

• Дизайн

1. выстраивание дизайн-концепции — уникального художественного стиля продукта, брендирование;
2. сборка UI-кита — набора готовых, часто используемых элементов и шаблонов пользовательского интерфейса;
3. создание дизайн-макета — визуального образа мобильного приложения, демонстрирующего внешний вид страниц после верстки и с разными вариантами наполнения;
4. динамического прототипа — интерактивной анимированной версии продукта, позволяющей оценить качество интерфейса.

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

Пример дизайн-концепции мобильного приложения

• Программирование

Задача этапа — написание кода, построение архитектуры, Back-end и Front-end разработка. Для комплексных и сложных проектов используется тактика MVP.

1. нативный — разработка отдельной версии мобильного приложения для каждой платформы;
2. кроссплатформенный — использование кода, универсального для всех платформ.

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

• Тестирование

Задача этапа — тестирование мобильного приложения с целью выявления недостатков и ошибок.

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

Цель проверки продукта на стабильность, совместимость и безопасность достигается привлечением специалиста-тестировщика, который проверяет функциональность UI/UX, выясняет качество и порядок запросов разрешений, устанавливает отказоустойчивость баз данных и т. д.

По результатам тестирования создается отчет с детальным перечнем ошибок и рекомендациями по устранению.

• Запуск приложения

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

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

Вывод

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

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

Источник: spark.ru

Семь стадий разработки нового продукта

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

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

1. Разработка стратегии в отношении нового продукта

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

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

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

Включение первичного стратегического планирования в процесс разработки нового продукта вызвало резкое повышение «смертности» идей новых продуктов. Исследование, проведенное в 1968 году, выявило, что для создания одного нового продукта, успешно запущенного в коммерческое производство, требуется 58 идей нового продукта. А согласно данным 1982 года, для успешного «рождения» одного нового продукта потребовалось уже лишь семь идей. Производителям продуктов для получения одного успешного продукта обычно требуется примерно вполовину меньше идей новых продуктов, чем производителям потребительских товаров длительного пользования.

2. Генерация идей

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

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

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

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

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

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

3. Отбор идей

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

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

Главное при отборе идей нового продукта — ответить на вопрос: «Осуществима ли эта идея и в достаточной ли степени она интересна, чтобы заслуживать более тщательного анализа?» Задача компании на стадии отбора — не принять или отклонить идею как проект для разработки, а определить, обладает ли идея достаточными достоинствами, чтобы оправдать расходы на бизнес-анализ.

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

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

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

• Имеете ли вы доступ к необходимому сырью?
• Позволяет ли ваше текущее финансовое положение осуществить проект такого масштаба?
• Обеспечивает ли новый продукт синергетический эффект в сочетании с нашей нынешней товарной линией?
• Являются ли ваши нынешние клиенты потенциальным рынком, или вам предстоит осваивать совершенно новые рынки?
• Можно ли продавать новый продукт силами имеющихся продавцов и дистрибьюторов?
• Соответствует ли идея возможностям вашего отдела разработки продуктов?
• Окажет ли успешная разработка этого продукта положительное/ отрицательное влияние на ваши существующие продукты, рынки и систему маркетинга?
• Позволят ли ваши производственные мощности и опыт производить данный продукт?

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

4. Бизнес-анализ

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

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

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

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

5. Разработка

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

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

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

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

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

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

6. Тестирование

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

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

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

1. вторичное исследование;
2. фокус-группы;
3. опросы по почте;
4. телефонные опросы;
5. личные интервью;
6. Product Placement;
7. пробный маркетинг.

Тестирование продукта на рынке, если оно осуществимо, может способствовать получению следующих данных:

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

В 2023 году интернет-маркетинг — основа каждой компании. Как правильно продвигать продукт в сети, анализировать клиентов, убеждать их? На эти вопросы отвечают эксперты в новом курсе профессиональной переподготовки «Профессия маркетолог: все методики продвижения» . Курс состоит из 12 разделов: 256 ак. часов материала. В каждом разделе курса практика.

Всего +40 чек-листов, полезных таблиц по маркетингу, инструментам и метрикам. Уроки по 10 — 30 минут без воды, с примерами из практики экспертов.
Сможете получать обратную связь от преподавателей курса на онлайн-встрече и задавать вопросы.

Посмотрите бесплатный урок из курса

7. Коммерциализация и позиционирование продукта

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

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

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

Источник: www.klerk.ru

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

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

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

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

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

Основные этапы процесса разработки:

1. анализ требований заказчика;
2. проектирование;
3. реализация (программирование).

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

Каждый процесс характеризуется определенными задачами и методами их решения, а также исходными данными и результатами.

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

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

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

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

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

Рисунок 1– Основные этапы разработки каскадной модели

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

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

2. Проектирование состоит в создании:

1. архитектуры программного обеспечения;
2. модульной структуры программного обеспечения;
3. алгоритмической структуры программного обеспечения;
4. структуры данных;
5. входного/выходного интерфейса (входных/выходных форм данных).

При решении задач проектирования основное внимание уделяется качеству будущего программного продукта.

3. Кодирование или разработка состоит в переводе результатов проектирования в код программы.

4. Тестирование – это выполнение программы на выявление дефектов в функциях, логике и форме реализации программного продукта.

5. Сопровождение – это внесение изменений в эксплуатируемое программное обеспечение с целью:

1. исправления ошибок;
2. адаптации к изменениям внешней для программного обеспечения среды;
3. усовершенствование программного обеспечения в соответствии с требованиями заказчика.

Достоинства применения каскадной модели:

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

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

Недостатки каскадной модели:

1. реальные проекты часто требуют отклонений от стандартной последовательности шагов;
2. каскадная модель основана на точной формулировке исходных требований к программному обеспечению, однако реально в ряде случаев в начале проекта требования заказчика определены только частично;
3. результаты реализации проекта доступны заказчику только после завершения всех работ.

Из-за необходимости в процессе создания программного обеспечения постоянного возврата к предыдущим этапам и уточнения или пересмотра ранее принятых решений реальный процесс разработки программного обеспечения на основе каскадной модели может быть представлен следующей схемой (рис.2).

Рисунок 2 – Процесс разработки программного обеспечения на основе каскадной модели

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

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

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

Спиральная модель включает четыре основных этапа, которые периодически повторяются:

1. планирование – это определение целей, вариантов и ограничений;
2. анализ риска – это анализ вариантов и распознавание риска;
3. конструирование – это разработка программного продукта следующего уровня;
4. оценивание – это оценка заказчика текущих результатов конструирования.

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

Следующая фаза планирования и анализа риска базируется на предложении заказчика. Если риск слишком велик, проект может быть остановлен. В большинстве случаев движение по спирали продолжается, с каждым шагом продвигая разработчиков к более общей модели системы. Количество действий по разработке возрастает по мере продвижения от центра спирали.

Рисунок 4 – Этапы спиральной модели

Достоинства спиральной модели:

1. наиболее реально отображает процесс разработки программного обеспечения;
2. позволяет явно учитывать риск на каждом витке эволюции разработки;
3. использует моделирование для уменьшения риска и совершенствования программного продукта.

Недостатки спиральной модели:

1. повышенное требование к заказчику;
2. трудности контроля и управления временем разработки.

ВЗАИМОСВЯЗИ МЕЖДУ ПРОЦЕССАМИ ЖЦ ПО

Процессы ЖЦ ПО, регламентируемые стандартом ISO/IEC 12207, могут использоваться различными организациями в конкретных проектах самым различным образом. Тем не менее, стандарт предлагает некоторый базовый набор взаимосвязей между процессами с различных точек зрения (или в различных аспектах), который показан на рис. 1.2. Такими аспектами являются:

1) договорной аспект;

2) аспект управления;

3) аспект эксплуатации;

4) инженерный аспект;

5) аспект поддержки.

В договорном аспекте заказчик и поставщик вступают в договорные отношения и реализуют соответственно процессы приоб­ретения и поставки.

Рис. 1.2. Связи между процессами жизненного цикла ПО

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

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

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

Взаимосвязи между процессами, описанные в стандарте, носят статический характер. Более важные динамические связи между процессами и реализующими их сторонами устанавливаются в реальных проектах. Соотношение процессов ЖЦ ПО и стадий ЖЦ, характеризующих временной аспект ЖЦ системы, рассматривается в рамках модели ЖЦ ПО.

Значение данного стандарта трудно переоценить, поскольку он формирует подход к выбору и оценке всех современных технологий и процессов создания и сопровождения ПО. Безусловно, на выбор конкретной технологии в проекте влияет целый ряд факторов, но принципы реализации и состав процессов ЖЦ ПО остаются стабильными. Большинство технологий, поставляемых ведущими производителями (IBM, Oracle, Microsoft и др.), соответствуют требованиям этого стандарта. Анализ различных тех­нологий показывает, что общие принципы описания процессов ЖЦ ПО в стандарте ISO 12207 прошли практическую апробацию и стали общепризнанными.

Таблица 1. Содержание основных процессов ЖЦ ПО АИС (ISO/IEC 12207):

Процесс (испол- нитель)

Приобретение (действия и задачи заказчика, приобретающего ИС)

Инициирование. Подготовка заявочных предложений. Подготовка договора. Контроль деятельности поставщика. Приемка ИС.

Решение о начале работ. Результаты обследования. Результаты анализа рынка ИС/ тендера. План поставки/ разработки. Комплексный тест.

Технико-экономическое обоснование внедрения. Техническое задание. Договор на поставку/ разработку. Акты приемки этапов работы. Акт приемно-сдаточных испытаний.

Поставка (поставщик снабжает заказчика прогр. продуктом или услугой)

Инициирование. Ответ на заявочные предложения. Подготовка договора. Планирование исполнения. Поставка.

Техническое задание. Решение руководства об участии в разработке. План управления проектом. Разработанная ИС и документация.

Решение об участии в разработке. Коммерческие предложения/ конкурсная заявка. Договор на поставку/ разработку. План управления проектом. Реализация/ корректировка.

Акт приемо-сдаточных испытаний.

Разра-ботка (разработчик создает ПО, оформляет проектную и эксплуатационную документацию, подготавливает тестовые и учебные материалы и др.)

Подготовка. Анализ требований ТЗ. Проектирование архитектуры. Разработка требований к ПО. Проектирование архитектуры ПО. Детальное проектирование ПО.

Кодирование и тестирование ПО. Интеграция ПО и квалификационное тестирование ПО. Интеграция ИС и квалификационное тестирование ИС.

Техническое задание на ИС. Модель ЖЦ. Подсистемы ИС. Спецификации требования к компонентам ПО. Архитектура ПО. Материалы детального проектирования ПО. План интеграции ПО, тесты.

Архитектура ИС, ПО, документация на ИС, тесты.

Используемая модель ЖЦ, стандарты разработки. План работ. Состав подсистем, компоненты оборудования. Спецификации требования к компонентам ПО. Состав компонентов ПО, интерфейсы с БД, план интеграции ПО.

Проект БД, спецификации интерфейсов между компонентами ПО, требования к тестам. Тексты модулей ПО, акты автономного тестирования. Оценка соответствия комплекса ПО требованиям ТЗ. Оценка соответствия ПО, БД, технического комплекса и комплекта документации требованиям ТЗ.

В соответствии с ИСО 12207 основные процессы так же:

Эксплуатация (действия и задачи организации, эксплуатирующей систему).

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

Вспомогательные процессы жизненного цикла ИС:

Документирование (формализованное описание информации, созданной в течение ЖЦ ИС)

Управление конфигурацией (применение административных и технических процедур на всем протяжении ЖЦ ИС для определения состояния компонентов ИС, управления ее модификациями).

Обеспечение качества (обеспечение гарантий того, что ИС и процессы ее ЖЦ соответствуют заданным требованиям и утвержденным планам)

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

Аттестация (определение полноты соответствия заданных требований и созданной системы их конкретному функциональному назначению)

Совместная оценка (оценка состояния работ по проекту: контроль планирования и управления ресурсами, персоналом, аппаратурой, инструментальными средствами)

Аудит (определение соответствия требованиям, планам и условиям договора)

Разрешение проблем (анализ и решение проблем, независимо от их происхождения или источника, которые обнаружены в ходе разработки, эксплуатации, сопровождения или других процессов)

Организационные процессы жизненного цикла ИС:

Управление (действия и задачи, которые могут выполняться любой стороной, управляющей своими процессами)

Создание инфраструктуры (выбор и сопровождение технологии, стандартов и инструментальных средств, выбор и установка аппаратных и программных средств, используемых для разработки, эксплуатации или сопровождения ПО)

Усовершенствование (оценка, измерение, контроль и усовершенствование процессов ЖЦ)

Обучение (первоначальное обучение и последующее постоянное повышение квалификации персонала)

Каждый процесс включает ряд действий. Например, процесс приобретения охватывает следующие действия:

1. Инициирование приобретения.

2. Подготовка заявочных предложений.

3. Подготовка и корректировка договора.

4. Надзор за деятельностью поставщика.

5. Приемка и завершение работ.

Каждое действие включает ряд задач. Например, подготовка заявочных предложений должна предусматривать:

1. Формирование требований к системе.

2. Формирование списка программных продуктов.

3. Установление условий и соглашений.

4. Описание технических ограничений (среда функционирования системы и т. д.).

Источник: skarlupka.ru