Бизнес-информатика. Введение в специальность

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

ванными

зависит от того, каким языком оно написано, насколько

оно четкосторонамиточно отражает

насколько требование может быть представ-

лено

виде некоего элемента,суть,которым удобно устанавливать связи от других

требований. Использование четкого и ясного языка (согласованных терминов)

при написании требований позволяет существенном образом облегчить после-

дующее понимание требований

х классификацию.

Для стандартизации

унификации процесс в м делирования, разработки

тр бований. Простым

примером

шаблона может служить использование

тек-

и управления требования

целесообразно

испо ьзовать шаблоны описания

сте слов «должен» («должна», «должно»), «рекомендуется», «возможно»

как

ключевого слова,

бозначающего наличие

. Тогда типичный шаблон

«пользовательские требования»требованиявыгл дит

образом:

представления<Т пользователя> должен иметь возможность <описаниследующимвозможно-

сти> [10].

системных требований основной акцент делается на

При

описание

функцииформулировкепостроение ограничений. Конкретная формулировка

-

бования зависит

т т

па ограничения, которые связ ны с этим

требованием.

Примеры

шаблонов системных требований:

<Система> должна <выпол яемая

функция>

в течение <производительность> <единица

измерения> с

момента <событие<объект>.

Пример ·························

·························

Для иллюстрации модели ования процесса проектирования программно-

го продукта рассмотрим

пример

писания архитектуры программной системы

упра ления и контроля работы скорой помощи с использованием диаграмм по-

токов данных (рис. 2.14).

На первом шаге выделим главные внешние сущности для системы: зво-

нящие – люди, которые звонят, чтобы сообщить об экстренных ситуациях,

машины скорой помощи, работой которых управляет сист ма [10]. Внешние

сущности записи являются выходом сист мы и отражают требование зак

ода-

тельства

являются средством для измерения нефункционального требования –

«производительность

системы». Другие возможные внешние сущности систе

мы,

едставленные на диаграм

е, тоже обязательны, но для простоты в дан-

ном примере не будут далее

рассматриваться.

Контекстная диаграмма

Другие возможные

Звонящие

внешние сущности

Полиция

П ограммная система

Пожарные

управления и контроля

Другие службы

скорой помощи

работы скорой помощи

Гражданская

Записи

оборона

Машины скорой

помощи

Рис. 2.14 –

Контекст ая диаграмма для системы управления

и контроля скорой помощи

функ-

Следующим шагом является оп еделение процессов –

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

функции верхнего уровня: обработка звонков, управление

машинамисущностейскоро

помощи, хранение записей, – получая таким бразом минимальную функцио-

нальную декомпозицию системы. После этого отображают

сновные данные,

которые должны транслироваться между функциями верхнего уровня: текущие

происшествия, состояния машин скорой помощи (рис. 2.15) [10].

я

Далее функции верхнего уровня разбиваются на более мелкие сост

(рис. 2.16) [10]. Полученная детализированная модель системы

правле

ющиения к нтроля работы скорой помощи позволяет определить архитектуру

про-

граммного продукта

на ее основе разработать перечень функциональных

и

нефункциональных требований к каждому из компоненто ПП (рис. 2.17) [10].

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

требование

к реализации программного модуля (компонента) получения по

дробностей происшествия можно сформулирова

в следующем виде: Диспет-

чер скорой помощи должен иметь

возможность

отрабатывать

информацию т звонящего о проис

ествии. В своюполучатьочеред

требование

к про-

граммному

м дулю

назначение машины скорой помощи можно записать так:

Диспетчер

скорой помощи должен иметь возможность назначить машину для

выезда на происшествие. Пример системного требования времени ре кции на

звонок может быть представлено в следующем виде: Система должна

обеспе-

Обработка

Звонящие

звонков

Текущие

машинаУправлениескорой

происшествия

Хранение

помощи

записей

Машины скорой

Состояния машин

Записи

помощи

Рис. 2.15 – Модель системы управления и контроля скорой помощи

Обработка

Переговоры

Звонящие

звонков

со звонящими

одробностПолученией

Анализ

Немедленные

Управление

происшествия

советы

происшествия

машинами скорой помощи

Текущие

Наз ачение

машины

скорой

происшествия

Переговоры

помощи

машинами

Мониторинг

Обеспечен е

Хранение

скорой помощи М нитор нг

состояний

происшествий

статистики

записей

машин скорой

помощи

Состояния аш н

Записи

Машины скорой

скорой помощи

помощи

Переговоры со звонящими

Получение подробностей

Обработка

происшествия

Анализ происшествия

звонков

Немедленные советы

Система

Управление

Назначение машины

скорой помощи

управленияконтроля

скорой

скорой помощи

машинами

Переговоры с машинами

помощи

Мон торинг состояний

машин скорой помощи

Хранение

Мониторинг происшествий

Обеспечение статистики

записей

Рис. 2.17 – Архитектура ПП «Управление и контроль

работы скорой помощи»

·······································································

Таким образом, использование при

диаграммы потоков

данных позволяет разработчикам: отобразитьмоделированиипотоки анных и функциональ-

ность системы; определить функции, потоки и хранилища данных; определить

интерфейсы между функциями; реализовать процедуры

олучения системных

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

программного обеспе-

чения.

·····························································

Контрольные вопросы по главе 2

1.

·····························································

Раскройте содержание моделей «К к есть» «Как должно быть», что

2.

такое ключевой показатель результативности?

Раскройте содержание объектно-ориентированного подхода при опи-

3.

сании бизнес-процессов п едметной области.

Раскройте содержание структурного (функционального) подхода при

описании бизнес-процессов предметной области.

3 Вывод на рынок нового программного продукта

3.1 Жизненный цикл вывода на рынок программного продукта

3.1.1 Содержание фазы инициации

В соответствии с рекомендацией ГОСТ Р ИСО/МЭК 12207–2010 «Ин-

формационная технология. Процессы жизненного цикла

средств»

под жизне ым циклом вывода на рынок программногопрограммныхродукта понимается

упорядоченная

совокупность фаз (стадий,

работ), охватывающ х

изменение программного прпроцессов,дуктамомента возникновения

эволюционноепотребности нем либо идеи его создания до полного изъятия ПП из эксплуа-

тации (рис. 3.1).

На первых двух стадиях фазы инициации создается творческое ядро ко-

манды проекта по разработке нового пр граммного продукта; формируются

привлекательные идеи производится их оценивание; на основе отбора наибо

лее привлекательных идей разрабатывают я концепции программного продук

та, в которых определяется целесообразность

эффективность разработки, вы-

бирается продуктово-рыночное направление

продвижени

ПП, определяются

источники привлечения инвестиций будущего ПП,

еделяется

стратегия вы-

вода его на рынок. Концепция создается в виде некотопрого структурированного

описания нового ПП, в котором должны найти отражение

вопросы:

•

какова идея нового ПП; обладает ли продукт следующиекакимиибо новыми

уникальными особенностями; какой полезный эффект можно извлечь

из использования ПП; знаете ли производителей аналогичных продук-

тов; чем тличается ваш продукт от продуктов конкурентов; если в

вашем

продукте нет ничего особенно выдающегося, то что же в нем

может привлечь покупателя;

• кому собираетесь продавать ваш продукт; каким образом вы собирае-

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

покупателю; как вы собираетесь привлечь

пателей;

• какую рыночную цену назначите

ваш продукт;

сколько и каких ис

полнителей понадобится для реализации

ваших идей;

акова стои

мость

разработки вашего продукта; какова величина накладных рас-

ходов.

Жизненный цикл вывода на рынок ПП

Вывод ПП

Инициация

Разрабо ка

Разработка реализац

продукта

программы продвижения

на рынок

Генерация и

Планирование

Рост

З елость

Упадок

Вывод из

отбор идеи

работ

рынка

рынка

рынка

эксплуатации

Разработкапроведена

по проекту

Реализация программы продвижения

Форм рование

проверкаНе

и спецификация

концепции

Анализ

требований

рынка

Техническое

Разработка

задание

бизнес-плана

Проектиро-

вание

Конструиро-

вание

Рын чное

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

релиз (выпуск)

Ввод

эксплуатацию

сопровождение

продукта

Рис. 3.1 – Структура жизненного цикла вывода на рынок ПП

Анализ потенц ального рын

и основных онкурентов является

вой с дией фазы инициации проекта по

разработке ПП. На данной стадииключесл -

дует также провести SWOT-анализ, выявить сильные и

абые стороны нового

продукта по отношению к ПП конкурентов. При этом

следует определить ко-

личество конкурентов, изучить методы, используемые ими в борьбе за рынок.

Кроме

основных конкурентов необходимо провести оце ку

альногоанализарын

таким показателям, как количество потенциальных потреб -

На основании требований

ПП разрабатывается подробное техническое

(ТЗ). Именно этот

документ

будет определять

ехнические

заданиепрограммного продукта, его функциональность и

требования кспецификаэксплуат -

ционным характеристикам. Любая

шибка или любое упущение, допущенные

при разработке ТЗ, приводят к до олнительным

затратам на исправление или

доработку готов го прог аммного продукта.

Проектирование программных

продуктов можно рассматрива ь как дея-

тельность, результат которой содержит две

ставные части:

или высокоур вневый, дизайн – описание высокоуровневой структурыархитектурный,орга

низации компонентов системы, в том числе внутренних и внешних интерфей-

сов; детализированную архитектуру – описание каждого компонента в объеме,

необходимом для конст

.

дизайна ПП вк

следу

Процесс проектируирования

ющие виды деятельности:

азработкуархитектурногодокументальное оформленлючаетархитек-

туры ПП, опис вающей

верхний

уровень его структуры и идентиф цирующей

все программные компоненты последующих уровней; разработку и

тальное офо мление проекта верхнего уровня для внешних инт рфейсовдокуменп

граммного продукта и его

интерфейсовоформ ие

с программными компонентами;

разра-

ботку и

документальное

проекта

в рхнего уровня для

базы

данных;

разработку

льное

е

предварительных верс

документации;

оформленидокументирование требований

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

определениеграфику работ по комплексированию про-

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

целом.

При разработке архитектуры все

к программному продукту

распредел ются по программным компонентамтребованиядальнейшем уточняются для

облегчения детального проектир ван я. Процесс детализированного

рования

заключается

дек мпозиции

его структуры до элемен арныхпроекти-

граммных компонентов,

орые

мог

быть

верифицированы

установленных требованийкот архитектуре программного продукта.относительноСостав со-

держание

идов деятельности при реализации процесса аналогичны процессу

архитектуры ПП.

разработке исполняемых

проектированияСтадия нструир вания ПП заключ ется

программных модулей посредством комбинации, кодирования, верификации,

модульного тестирования, интеграционного тестирован я и отладки. При еа

лизации процесса необходимо выполнять следующие

виды

раз-