В 2020 году, по примерным данным, насчитывалось более 5 миллионов мобильных приложений, а скачивания исчислялись миллиардами. В основном люди устанавливали мобильные игры, сервисы для видеоконференций и мессенджеры. Конечно, не последнюю роль в таком выборе сыграл Covid-19 и карантинные меры. Переход на формат удаленной работы, вынужденные отпуска, адаптация к новым реалиям — и вот, люди активно скачивают игры, общаются в мессенджерах, встречаются в Zoom, заказывают доставку еды и всех необходимых, в это непростое время, вещей.
Многим компаниям пришлось адаптироваться и внедрять разработку приложений в бизнес-стратегию, чтобы не потерять клиентов. В 2021 году тенденция сохраняется. На какие показатели нужно обращать внимание, чтобы разобраться эффективно мобильное приложение или нет?
Как измерить эффективность мобильного приложения – основные метрики и показатели
Число скачиваний
Эту метрику смело можно назвать самой популярной. Маркетологи часто ее отслеживают и стараются работать над увеличением числа установок. Они делают это не только для того, чтобы хвастаться в кейсах впечатляющими цифрами.
Показатели эффективности программиста. KPI разработчика. Метрики работы программиста #prog #kpi
Количество скачиваний прямо влияет на ранжирование приложения в магазинах Google Apps и App Store — чем выше оно в поиске, тем больше вероятность, что его заметит целевая аудитория и решит им воспользоваться. При этом, большое число скачиваний, показывает, что маркетологи неплохо потрудились над маркетинговой стратегией, продвижением и ASO, но, иногда, очень мало говорит как показатель эффективности мобильного приложения. Всё потому что тренды и интересы людей изменчивы. Поэтому здорово помнить, что больше — не всегда лучше, а высокий спрос сегодня совсем не гарантирует стабильного роста завтра.
Показатель числа скачиваний может вам пригодиться, если вы запускаете продукт для лояльной аудитории или хотите ее увеличить. Например, приложение может упростить бронирование столиков, а программа лояльности принести еще больше клиентов. Хотя всегда есть шанс, что половина аудитории все равно будет приходить без предварительной брони, просто потому что консервативна и довольна тем, как все работает сейчас.
А ещё, хорошая идея следить за количеством скачиваний понадобится, если вы хотите разработать самый лучший в мире продукт, а потом выгодно его продать.
Как рассчитать: определите число потенциальных пользователей приложения, а потом найдите процент от этого числа. Этот процент будет означать потенциальные установки.
Если вы используете платные каналы продвижения, то неплохо будет рассчитать среднюю стоимость установки для оценки затрат на эти каналы.
Для этого, траты на продвижение разделите на сумму пользователей, которые установили приложение. Не забывайте сопоставлять количество скачиваний к числу удалений. Если приложение часто скачивают, но сразу же удаляют — повод задуматься, не зря ли вы тратите бюджет на рекламу в определенных каналах.
Как увеличить:
Оцениваем процессы в команде разработки на основе объективных данных / Сергей Семенов (GitLean)
- Продумайте маркетинговую стратегию: публикуйте новости в социальных сетях, размещайте статьи в профильных блогах и пресс-релизы на новостных площадках.
- Используйте информативную иконку, которая хорошо смотрится на разных устройствах.
- Проверьте, что скриншоты ключевых экранов приложения содержат основную информацию о его функциях и задачах.
- Убедитесь, что описание полное и в нём достаточно ключевых слов.
- Разместите качественное видео — многие люди принимают решение пользоваться продуктом именно после того, как просмотрят видео.
- Дайте возможность пользоваться приложением бесплатно. Это может быть как пробный период, так и урезанный функционал на бесплатном тарифе.
- Делитесь пользовательским контентом. Положительные отзывы о вашей разработке — лучшая реклама.
Retention Rate
Эта метрика показывает процент пользователей, которые после скачивания зашли в приложение снова. Буквально — это показатель того, насколько качественный ваш трафик и сформировалась ли у людей привычка часто пользоваться вашим продуктом.
Учитывая, что каждый пятый человек после того, как скачает приложение, открывает его только один раз, лучше не забывать работать над увеличением Retention.
Если ваш продукт предполагает его частое использование, без этой метрики не обойтись. Например, вы разработали фитнес приложение, и вам важно, чтобы люди запускали его каждый день и тренировались по выбранному расписанию. Если они не будут этого делать, то привычка заниматься каждый день не сформируется, как не сформируется привычка каждый день открывать ваше приложение.
И, напротив, Retention Rate чуть менее важен, например, для сферы доставки. Скорее всего, пользователи не будут заказывать продукты из магазина каждый день. В данном случае эту метрику эффективности мобильного приложения не нужно списывать со счетов, просто целесообразнее рассчитывать Retention Rate за неделю, две, три или месяц.
Также эта метрика не очень много даст понять об эффективности мобильного приложения для бронирования мест в ресторане. Человек может им воспользоваться пару раз в год, когда захочет отметить день рождения или годовщину свадьбы. Остальное время он не будет открывать приложение. И удалять не будет тоже, к примеру, из-за удобной бонусной программы. Процент удержания в данном случае окажется невысоким, но можно будет считать, что приложение условно эффективно.
Как рассчитать: Существует несколько вариантов подсчета. Классическая формула — сумму уникальных запусков на определённый день после скачивания, разделить на количество пользователей, которые установили приложение на 1-й, 2-й, 3-й и т.д. день и умножить на 100%.
Как увеличить:
- Позаботьтесь о том, чтобы интерфейс приложения был понятным и удобным. Анализируйте поведение пользователей, например, при помощи тепловых карт и постоянно улучшайте UX и UI.
- Работайте над онбордингом. Если при первом использовании людям не понятно, как оформить заказ, выбрать адрес или ввести номер карты, вряд ли они захотят долго разбираться. Спроектируйте подсказки, которые будут им полезны на разных этапах.
- Используйте геймификацию. Например, начисляйте баллы в конце недели за ежедневные выполнения заданий.
- Напоминайте о событиях через push-уведомления и емейл-рассылки. При этом постарайтесь учитывать их интересы, время активности и реакции на оповещения. Уведомления должны ассоциироваться с помощью и заботой, а не вызывать раздражение и назойливость.
- Но самое очевидное — сделайте продукт, который будет решать проблемы вашей целевой аудитории. Решать настолько хорошо, что люди захотят заходить в приложение чаще — без напоминаний и разных способов мотивации.
Покупки в приложении
Этот показатель экономической эффективности помогает оценить, как разработка влияет на доход компании.
Может понадобиться, если вы выпустили приложение в поддержку продукта или услуги. Например, добавили возможность оплатить заказ через приложение на мобильном устройстве, помимо оплаты курьеру или только на сайте. В таком случае, увеличение заказов может говорить о его эффективности. И, напротив, если оплата услуг через ваше приложение увеличилась за счет снижения оплаты услуг на вашем сайте — говорить об эффективности разработки сложно. Потому что доход по сути не изменился.
Как увеличить:
- Чтобы покупки через приложение принесли ощутимую пользу, нужно привлекать новых покупателей. Причем тех, кто не был вашим клиентом раньше. Ещё один способ: увеличивать число покупок, которые делают действующие клиенты.
- Сделайте процесс выбора товаров и оплаты максимально простым. Например, по возможности реализуйте удобную фильтрацию, автоматическое заполнение форм и сохранение введенных данных.
- Возвращайте пользователей. Мотивировать делать покупки можно с помощью рекламы, емейл-рассылок и push-уведомлений.
- Запустите программу лояльности. Шанс получить скидку или сэкономить на доставке — весомый повод заказывать у вас, а не у конкурента.
- Добавьте дополнительные блоки. Например, карточки с персональными рекомендациями или популярными товарами.
Net Promoter Score – NPS
Net Promoter Score — индекс лояльности клиентов. Чтобы его узнать, клиентам задают вопрос «готовы ли вы порекомендовать компанию, например, друзьям или родственникам». Оценка ставится по шкале от 0 до 10. Анализ полученных ответов позволяет узнать, сколько человек довольны приложением, сколько нейтральны, а сколько настроены негативно.
Здорово учитывать это показатель, особенно, если вы проводили опросы раньше — будет наглядная картина «до-после».
Проблема в том, что процесс разработки и внедрения могут идти в то же время, когда запускаются программы лояльности или повышаются цены. Эти процессы вполне могут повлиять на ответы людей при опросе, но не будут прямо относиться к оценке приложения.
Как считать: Все ответы делятся на три категории:
1-6 — критики. Пользователи, которые недовольны приложением. Могут оставлять негативные отзывы и удалить его.
7-8 — нейтралы. Нейтрально настроенные — не будут ставить низких оценок или негативные отзывы, но есть вероятность, что уйдут к конкурентам.
9-10 — промоутеры. Те, кто довольны приложением и скорее всего будут его рекомендовать.
После этого, от суммы оценок от 9 до 10 «промоутеров» нужно отнять оценки «нейтралов», разделить полученную разницу на число опрошенных и умножить на 100.
NPS можно повысить постоянно анализируя информацию о клиентах. Помимо информации, которые вы можете получить из систем аналитики, просите их оценить удобство и функционал приложения. Задавайте вопросы о том, какие бы ещё функции они хотели видеть и делайте выводы для улучшения продукта и работы компании.
Lifetime Value – LTV
Lifetime Value — пожизненная ценность клиента дает понять, какой доход он принесет за все время, что пользуется приложением. Эта метрика показывает, сколько стоит для компании один новый клиент, а сколько — его потеря. Принято считать, что расходы на привлечение пользователя должны быть ниже его ценности примерно в 3-5 раз. То есть ситуация, когда вы тратите на привлечение 1000 рублей, а получаете 1000 — плохой вариант.
На LTV стоит ориентироваться каждому бизнесу. Если вы рассчитаете выручку от одного пользователя, то сможете использовать показатель LTV с другими метриками. Это поможет сделать точные выводы в оценке эффективности мобильного приложения и определить оптимальный бюджет на маркетинг и рекламу.
Есть несколько способов рассчитать Lifetime Value. Маркетологи часто используют формулу: LTV = a * b * t
где a — сумма дохода от пользователя, b — расход на его привлечение, t — время использования приложения.
Как повысить этот показатель:
- Проводите стимулирующие акции. Например, начисляйте бонусы или дарите скидки за покупки и выполненные действия.
- Не забывайте про UX. Если человек постоянно сталкивается с одной и той же проблемой, он может просто перестать пользоваться вашим продуктом. Поэтому даже после того, как пользователь несколько раз взаимодействовал с приложением, важно анализировать были ли у него трудности на каком-то этапе, есть ли элементы интерфейса, которые можно улучшить.
- Реализуйте своевременную обратную связь. Эта мера поможет увеличить любые метрики эффективности мобильного приложения. Обратная связь от клиентов поможет сделать продукт лучше, а пользователям даст понять, что вам не безразличны их желания и отзывы.
Выбор метрик по которым лучше оценивать эффективность мобильных приложений зависит от сферы и специфики бизнеса. Главное определить группу показателей до релиза и оценивать их по предположительным KPI. Используйте тепловые карты, чтобы посмотреть поведение людей в приложении, размещайте на самых популярных страницах кнопки целевого действия и внимательно следите за клиентским опытом. Именно от него зависит эффективность мобильной разработки.
За девять лет специалисты студии AppCraft запустили несколько собственных проектов, десятки клиентских и накопили большую экспертизу, которой с радостью готовы поделиться. Если вы задумываетесь о создании мобильных приложений под android или iOS, напишите или позвоните нам — мы ответим на все вопросы.
6 секретов успешного маркетплейса услуг
В теории, маркетплейс услуг должен приносить пользу обеим сторонам: снижать накладные расходы, упрощать процесс поиска и оказания услуг, но на практике многие приложения быстро сдуваются. Что нужно, чтобы создать полезное приложение?
Тоже интересно
Как улучшить показатель удержания аудитории в EdTech проектах?
Все сервисы предоставления онлайн услуг в определенный момент сталкиваются с одной общей проблемой — удержание клиента. Привлечение в сервис нового клиента почти всегда стоит дороже, чем прибыль от его первой покупки, и способы удержания становятся основной головной болью для любого бизнеса. В данной статье мы рассмотрим, как мобильное приложение может помочь повысить retention rate и создать дополнительный канал привлечения клиентов на примере отрасли EdTech.
Импортозамещение ПО и мобильные приложения: что разрабатывать?
Высокий уровень цифровизации имеет только 11% бизнеса — и это исследование проводилось уже после начала пандемии, которая простимулировала диджитализацию. По мере того, как с российского рынка стали уходить зарубежные IT-продукты, спрос на отечественное ПО возрос на 300%. Какие проекты стоит запускать в текущих условиях? В каких нишах требуются мобильные приложения? Размышляем в статье.
Как меняется рынок разработки мобильных приложений в 2022 году?
В текущем году практически каждый рынок переживает непростые времена и пытается адаптироваться к новым реалиям. Рассказываем о том, как изменился спрос в отрасли, какие приложения хотят разрабатывать и какие прогнозы есть уже сейчас.
Страхи и боли заказчика мобильного приложения
Мобильное приложение — это всегда крупная инвестиция, поэтому практически каждый заказчик в чем-нибудь да сомневается или даже высказывает опасения. В этом тексте собрали самые распространенные страхи клиентов и объясняем, что с ними делать.
Контакты
8(499)348-82-16
- 107140, Москва,
ул. Русаковская, 1, оф. 306 - 390042, Рязань,
ул. К.Маркса, 3, к.2
Компания
Написать нам
Соцсети
10 незаменимых KPI для разработки программного обеспечения
Измерение производительности вашей команды с помощью показателей программного обеспечения — важный шаг к постановке и достижению целей, которые вы поставили перед собой и своим бизнесом.
Когда люди записывают измеримые цели, они на 30% чаще их достигают . Находчивость заключается не только в наличии ресурсов, но и в выработке стратегии их наилучшего использования. В условиях сложной технической работы ключевые показатели эффективности, или KPI, являются ценным методом сохранения ответственности за достижение поставленных целей.
Установка ключевых показателей эффективности разработки ПО, может быть сложным и исчерпывающим. Соответствие требованиям проекта и удовлетворенность клиентов также являются главными приоритетами для групп разработчиков.
Что такое KPI разработки программного обеспечения?
Ключевые показатели эффективности (KPI) — это значения, которые измеряют эффективность вашего бизнеса в целом. В контексте разработки программного обеспечения ключевые показатели эффективности показывают, насколько хорошо ваши усилия по разработке соответствуют бизнес-целям. Выбор правильных метрик программного обеспечения — это первый шаг.
Вы будете удивлены, как часто компании выбирают неправильные показатели для измерения успеха команды программистов. Использование ключевых показателей эффективности, таких как количество строк кода, количество коммитов и количество развертываний, не редкость. Но это явное заблуждение. Вышеупомянутые показатели не соответствуют реальным задачам.
И KPI, которые вы выбираете для разработки программного обеспечения, требуют гораздо большего количества нюансов. Редко бизнес-менеджеры знают достаточно о тонкостях разработки, чтобы по-настоящему понять, как выглядит успешный проект.
Например, традиционные метрики программного обеспечения, описанные выше, лучше всего подходят для групп программистов, которые используют модель водопада для разработки. Однако современные команды предпочитают использовать гибкую разработку программного обеспечения, чтобы масштабироваться быстрее и лучше.
Гибкий процесс обеспечивает быструю разработку приложений с непрерывной доставкой и развертыванием. Помня об этих целях, становится ясно, что KPI ПО должны опираться на масштабируемость бизнеса как на наиболее существенный компонент показателей производительности. И именно это качество, вероятно, оказывает наибольшее влияние на установление ключевых показателей эффективности разработки программного обеспечения. Вопрос не только в том, чего должна достичь команда разработчиков, но и в том, как она создает ценность для бизнеса?
Почему метрики важны в разработке программного обеспечения?
Как и в любом другом начинании, достижение целей означает намерение в отношении того, как вы их выполняете.
Точно так же, установив инженерные показатели KPI и убедившись, что ваша команда готова к их выполнению, вы обеспечите высококачественное программное обеспечение. Также больше шансов, что вы завершите свой проект вовремя и в рамках бюджета. При возникновении проблемы ваши метрики предоставят ценный контекст для и из понимания.
Метрики помогают вашему бизнесу отслеживать и контролировать определенные проблемы и расставлять приоритеты для метрик, которые, по вашему мнению, должны выделяться больше всего. KPI также способствуют продуктивности команды. Когда команда разработчиков способна лучше распознавать свои коллективные усилия и то, как они влияют на положительный или отрицательный результат, они более продуктивны в устранении любых узких мест. В любом случае наличие организованного метода измерения прогресса в процессе разработки программного обеспечения приведет к увеличению возврата инвестиций (ROI).
10 ключевых показателей эффективности разработки ПО
Теперь, когда вы знакомы с KPI и их ролью в разработке, вам следует взглянуть на то, какие KPI лучше всего подходят для вас лично. Ниже приведены 10 основных KPI:
1. Скорость
Скорость означает, сколько работы ваша команда может выполнить за спринт. В гибкой разработке спринт — это установленный период времени, в течение которого должны быть выполнены определенные задачи. Существуют различные способы измерения скорости. Самая популярная мера — это Story Points, которые измеряют количество усилий, затраченных на программный продукт.
Оценка сюжетных баллов в первую очередь означает оценку размера программного проекта и времени, необходимого для его создания. Требуется всего около трех спринтов, прежде чем вы получите хорошее представление о средней скорости вашей команды. Используя скорость, вы можете оценить, насколько реалистичны цели.
2. Выгорание спринта
Сгорание спринта — это более узкая метрика, которая измеряет, сколько работы фактически выполнено во время спринта. Обратите внимание, что выгорание спринта отличается от скорости, которая представляет собой оценку, основанную на нескольких средних значениях. Использование выгорания спринта в качестве метрики программного обеспечения помогает командам корректировать свою производительность, когда измерение не соответствует прогнозам. Команды разработчиков часто используют диаграммы выгорания спринта для представления собранных ими данных, измеряя время в сравнении с баллами.
3. Burndown
Burndown релиза учитывает ход релиза. Эта метрика больше по объему, чем выгорание спринта. И эта метрика полезна, потому что она может помочь командам управлять выпуском продукта. Команды разработчиков могут использовать диаграмму выработки релизов, чтобы узнать, отстают ли они от графика, опережают его или точно соблюдают график.
Компании будут иметь надежные данные, чтобы показать заинтересованным сторонам, когда они могут ожидать окупаемость инвестиций после выпуска. Точно так же вы можете информировать клиентов о задержках или досрочных выпусках. Диаграммы выгорания релиза похожи на диаграммы выгорания спринта. По оси X представлены спринты, а по оси Y — баллы.
4. Время цикла
Время цикла — это KPI программного обеспечения, который измеряет, сколько времени затрачивается на выполнение определенной задачи. Команды разработчиков используют диаграммы времени цикла для оценки эффективности процесса разработки ПО. Измерение времени цикла может принести много преимуществ.
Во-первых, у вас есть метрика, которая может объективно оценить производительность вашей команды. Тот же показатель даст вам оценку того, насколько быстро ваша команда будет выполнять будущие задачи. В том же духе вы можете обнаружить любые несоответствия, такие как препятствия в быстром рабочем процессе.
5. Совокупный поток
Совокупный поток демонстрирует, в каком состоянии находятся ваши программные задачи или заявки, с помощью визуальной диаграммы. Разные цвета на диаграмме будут обозначать разные этапы, например «Утверждено». «Выполняется», «Незавершенная работа» и т. д. Эти цвета располагаются полосами, ширина полосы которых соответствует времени цикла. Вы можете использовать кумулятивную блок-схему, чтобы стабилизировать свой рабочий процесс, когда или если вы обнаружите узкие места. Визуальное представление данных возлагает на команду ответственность за последовательный результат работы.
6. Эффективность потока
Эффективность потока измеряет соотношение между вашим активным временем и вашим общим временем. Часто незавершенная работа на самом деле означает не незавершенную работу, а на самом деле время стоит на месте. Могут быть периоды ожидания, когда разработчики не могут сразу перейти от одной задачи или проекта к другой. Вы можете рассчитать эффективность потока, разделив время, которое вы активно тратите на работу, на общее время цикла. Вы можете соотнести низкую эффективность с конкретными периодами времени, чтобы лучше понять, что вызвало недостатки.
7. Покрытие кода
Покрытие кода — это KPI программного обеспечения, который команды разработчиков используют для измерения качества кода. Эта конкретная метрика имеет решающее значение для жизненных циклов разработки программного обеспечения, в которых приоритет отдается непрерывной доставке и разработке через тестирование (TDD).
Эта метрика, также называемая тестовым покрытием, определяет, какая часть вашего исходного кода выполняется во время его тестирования. Код, который по какой-то причине не выполняется, скорее всего, содержит необнаруженные ошибки. Хотя вы не должны стремиться к 100% покрытию кода, чем выше покрытие кода, тем лучше. И тем меньше отладки вам придется делать.
8. Стабильность кода
Стабильность кода трудно измерить. Стабильный код означает, что в программный продукт вносятся небольшие изменения, которые потенциально могут нанести вред бизнесу или программному обеспечению. Некоторые разработчики решают наметить частоту изменений кода. Другие думают о стабильности с точки зрения того, какой процент развернутого кода приводит к простоям.
9. Простота кода
Простота кода — это более общий KPI разработки программного обеспечения, и для его измерения можно использовать несколько показателей. Цикломатическая сложность, например, является количественной мерой количества независимых путей, которые должен пройти ваш код. Меньше путей — хороший знак. Как правило, более простой код легче тестировать и поддерживать.
10. Отток кода
Отток кода может быть мерой стабильности кода, поскольку он показывает, как часто код меняется с течением времени. Если вам нужно часто переписывать код, чтобы приспособить новую функцию, тогда программная система требует высоких затрат на обслуживание и, следовательно, представляет высокий риск.
Показатели программного обеспечения и/или ключевые показатели эффективности, описанные здесь, незаменимы, если вы надеетесь масштабировать свой бизнес и одновременно улучшить процесс разработки.
Источник: itanddigital.ru
13.3. Показатели эффективности разработки программного обеспечения
Качество программного продукта формируется на всех этапах его производства и зависит от мероприятий, проводимых разработчиками, то есть — от эффективности его разработки, В свою очередь На эффективность разработки ПО могут влиять: Человеческие факторы эффективности процесса разработки ∙ Планируемость – поддержка плана разработки ПО. ∙ Организованность – разработка и непрерывная поддержка структуры должностей и обязанностей. Главными элементами организованности являются: передача прав и ответственности подчиненным, разделение труда между исполнителями. ∙ Укомплектованность персонала .- обеспечение необходимого количества исполнителей соответствующей квалификации ∙ Руководимость – предполагает качественное выполнение следующих функций: создание и поддержание интереса и стимулов, побуждающих людей прилагать все усилия для успеха проекта ; ∙ Контролируемость персонала – сравнение результатов работы с поставленными в планах целями, исправление отклонений . ∙ Автоматизируемость – возможность использования ВТ для исполнения рутинной работы. ∙ Управление ресурсами для эффективности процесса разработки ПО. ∙ Анализируемость эффективности затрат – обеспечение тщательного анализа затрат ресурсов при выборе оптимального варианта реализации проекта. ∙ Планируемость, оцениваемость – составление плана выполнения проекта и плана координации ресурсов. ∙ Контролируемость – отслеживание выполнения плана выполнения проекта и плана координации ресурсов . ∙ Программотехника процесса разработки ∙ Осуществимость разработки – определение реализуемости проекта с учетом всего ЖЦ и его преимуществ по сравнению с альтернативными вариантами реализации. ∙ Полнота и непротиворечивость требований – разработка спецификации функций, интерфейсов и технических характеристик ПО таким образом, чтобы описание было достаточным для разработки и не содержало противоречий между своими частями. ∙ Проектируемость – возможность получения полных спецификаций
функциональных модулей, структур данных и управления, интерфейсных
87 связей, основных алгоритмов, а также определения условий работы каждой из компонент. ∙ Программируемость – возможность реализации полного набора программных компонент. ∙ Комплексируемость – возможность получения правильно функционирующего ПО из отельных компонентов. ∙ Внедряемость – возможность запуска разработанного ПО в эксплуатацию, обучения пользователей . ∙ Сопровождаемость – возможность поддержания работоспособности системы в процессе ее функционирования . ∙ Снимаемость – возможность планомерной передачи функций данного ПО замещающему его изделию . ∙ Управляемость конфигурации – в любой момент разработки ПИ можно представить его текущую версию, либо любую из предыдущих базовых . Достижение перечисленных выше целей и успех проекта во многом зависит от тщательного анализа и проектирования, обеспечения качества и правильной организации управления работами, использования современных методологий и технологий проектирования ИС, международных стандартов, регламентирующих жизненный цикл и требования к качеству ПО.
| 13.4. Жизненный цикл программного обеспечения | информационных |
| систем |
Одним из базовых понятий методологии проектирования ИС является понятие жизненного цикла ее программного обеспечения (ЖЦ ПО). Жизненный цикл программного обеспечения − это непрерывный процесс, который начинается с момента принятия решения о необходимости его создания и заканчивается в момент его полного изъятия из эксплуатации. Основным нормативным документом, регламентирующим ЖЦ ПО, является международный стандарт ISO/IEC 12207 [25] (ISO − International Organization of Standardization − Международная организация по стандартизации, IEC − International Electrotechnical Commission − Международная комиссия по электротехнике). Он определяет структуру ЖЦ, содержащую процессы, действия и задачи, которые должны быть выполнены во время создания ПО. ЖЦ ПО базируется на трех группах процессов: ∙ основные процессы ЖЦ ПО (приобретение, поставка, разработка, эксплуатация, сопровождение); ∙ вспомогательные процессы, обеспечивающие выполнение основных процессов (документирование, управление конфигурацией, обеспечение качества, верификация, аттестация, оценка, аудит, решение проблем); ∙ организационные процессы (управление проектами, создание инфраструктуры проекта, определение, оценка и улучшение самого ЖЦ, обучение).
13.4.1.Основные этапы жизненного цикла ПО
Среди основных процессов ЖЦ наибольшую важность имеют три: разработка, эксплуатация и сопровождение . Каждый процесс характеризуется определенными задачами и методами их решения, исходными данными, полученными на предыдущем этапе, и результатами. Разработка Разработка включает в себя все работы по созданию ПО и его компонентов в соответствии с заданными требованиями.: ∙ оформление проектной и эксплуатационной документации; ∙ подготовку материалов, необходимых для проведения тестирования разработанных программных продуктов; ∙ разработку материалов, необходимых для организации обучения персонала.
Разработка является одним из важнейших процессов ЖЦ ПО и включает стратегическое планирование, анализ, проектирование и реализацию. Эксплуатация Эксплуатационные работы можно подразделить на подготовительные и основные.
К подготовительным относятся: ∙ конфигурирование Базы Данных и Рабочих Мест пользователей; ∙ обеспечение пользователей эксплуатационной документацией; ∙ обучение персонала. ∙ Основные эксплуатационные работы включают: ∙ непосредственно эксплуатацию; ∙ локализацию проблем и устранение причин их возникновения; ∙ модификацию ПО; ∙ подготовку предложений по совершенствованию системы; ∙ развитие и модернизацию системы. Сопровождение Службы технической поддержки играют весьма заметную роль в жизни любой КИС. Наличие квалифицированного технического обслуживание на этапе эксплуатации ИС является необходимым условием для решения поставленных перед ней задач, причем ошибки обслуживающего персонала могут приводить к явным или скрытым финансовым потерям, сопоставимым со стоимостью самой ИС. Основными предварительными действиями при подготовке к организации технического обслуживания ИС являются следующие: ∙ выделение наиболее ответственных узлов системы и определение для них критичности простоя. Это позволит выделить наиболее критичные составляющие ИС и оптимизировать распределение ресурсов для технического обслуживания; ∙ определение задач технического обслуживания и их разделение на внутренние (решаемые силами обслуживающего подразделения) и внешние (решаемые специализированными сервисными организациями). Таким образом
89 производится четкое определение круга исполняемых функций и разделение ответственности; ∙ проведение анализа имеющихся внутренних и внешних ресурсов, необходимых для организации технического обслуживания в рамках описанных задач и разделения компетенции. Основные критерии для анализа: наличие гарантии на оборудование, состояние ремонтного фонда, квалификация персонала; ∙ подготовка плана организации технического обслуживания, в котором необходимо определить этапы исполняемых действий, сроки их исполнения, затраты на этапах, ответственность исполнителей.
Обеспечение качественного техобслуживания ИС требует привлечения специалистов высокой квалификации, которые в состоянии решать не только каждодневные задачи администрирования, но и быстро восстанавливать работоспособность системы при сбоях. Вспомогательные процессы Среди вспомогательных процессов одно из главных мест занимает управление конфигурацией, поддерживающее основные процессы ЖЦИС, прежде всего процессы разработки и сопровождения.
При разработке проектов сложных ИС, состоящих из многих компонентов, каждый из которых может разрабатываться независимо и иметь несколько версий одной реализации, возникает проблема учета из связей и функций, создания единой структуры и обеспечения развития всей системы. Управление конфигурацией позволяет организовывать, систематически учитывать и контролировать внесение изменений в различные компоненты ИС на всех стадиях ее ЖЦ.
Организационные процессы Управление проектами связано с вопросами планирования и организации работ, создания коллективов разработчиков и контроля за сроками и качеством выполняемых работ. Техническое и организационное обеспечение проекта включает: ∙ выбор методов и инструментальных средств для реализации проекта; ∙ определение методов описания промежуточных состояний разработки; ∙ разработку методов и средств испытаний созданного ПО; ∙ обучение персонала.
Обеспечение качества проекта связано с проблемами верификации, проверки и тестирования компонентов ИС. Верификация – это процесс определения соответствия текущего состояния разработки, достигнутого на данном этапе, требованиям этого этапа. Проверка – это процесс определения соответствия параметров разработки исходным требованиям. Проверка отчасти совпадает с тестированием, которое проводится для определения различий между действительными и ожидавшимися результатами и оценки соответствия характеристик ИС исходным требованиям.
Источник: studfile.net