список использованных источников 2 страница

Затраты на обнаружение и устранение ошибок в каждой версии ПО – ;

Затраты на доработку и совершенствование ПО, формирование и испытание новых модернизируемых версий ПО – ;

Затраты на тиражирование каждой новой версии ПО и ее внедрение в эксплуатируемых и новых системах – .

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

(1)

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

. (2)

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

(3)

и почти не зависят от тиража ПО.

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

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

. (4)

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

При , руб. , ,

руб.

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

1.3.3.2 Затраты на эксплуатацию ИС «EBIS».

Основные затраты на эксплуатацию ИС «EBIS» включают:

1. Затраты на технические средства и общее программное обеспечение, используемые на этапе эксплуатации ИС «EBIS» ;

2. Амортизационные отчисления с технических средств ;

3. Стоимость текущего ремонта технических средств ;

4. Стоимость расходуемой электроэнергии ;

5. Стоимость вспомогательных материалов (картриджи, бумага, диски и др.) .

Таким образом, затраты на эксплуатацию ИС «EBIS» определяются как сумма отдельных затрат по формуле

. (5)

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

Комплект ЗИП ИС «EBIS» рассчитан на 3 года с учетом его возможной корректировки. С учетом ожидаемого количества отказов элементов ИС «EBIS» в его состав входит по 1 типовому элементу ПК (материнская плата, видеоплата, память, жесткий диск, процессор, сетевая плата, блок питания, электронный замок для защиты от НСД, устройство чтения записи CD/DVD, клавиатура, манипулятор «мышь», монитор). Стоимость типовых элементов составляет:

1) материнская плата – 1400 руб.;

2) видеоплата – 1200 руб.;

3) память – 2400 руб.;

4) жесткий диск – 2500 руб.;

5) процессор – 7000 руб.;

6) сетевая плата – 1600 руб.;

7) блок питания – 2800 руб.;

8) электронный замок для защиты от НСД – 900 руб.;

9) устройство чтения записи CD/DVD – 1100 руб.;

10) клавиатура – 600 руб.;

11) манипулятор «мышь» – 300 руб.;

12) монитор – 4500 руб.

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

Таким образом, стоимость комплекта ЗИП составляет

=24500 руб.

Предположив, что ЗИП расходуется в течение трех лет равномерно, получим затраты в течение каждого года =24 500/3=8 167 руб.

Следовательно, руб.

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

, (6)

где – стоимость технических средств;

– норма амортизации, принята равной 30 %;

– время использования технических средств, дни, равное 250 (количество рабочих дней в году)

Таким образом, для ИС «EBIS»

руб.

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

руб.

Расчет годовых затрат на электроэнергию при эксплуатации и техническом обслуживании средств ПАНПП определяется из соотношения

, (7)

где W – мощность, потребляемая техническими средствами (киловатт/час);

– среднее время работы технических средств в течение года;

– тариф за 1 киловатт/час электроэнергии.

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

Величина расходов на стоимость вспомогательных материалов зависит от объема и установленных норм расхода. Для предварительных расчетов можно принять стоимость материалов равной от 2 % до 3 % от стоимости технических средств.

Таким образом, при средней доле затрат (2,5 %),

руб.

Общая годовая стоимость эксплуатации ПАНПП (без учёта расходов на расходуемую электроэнергию) на объекте информатизации составляет

руб.

1.3.4 Экономическая целесообразность разработки системы

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

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

При этом экономическую целесообразность и эффективность разработанной системы можно проиллюстрировать следующими цифрами:

Экономия финансовых и временных ресурсов на поиск необходимой информации по разработке программного обеспечения на 70%;

Увеличение повторного использования программного кода в проектах Заказчика и связанное с этим снижение себестоимости на 20-30%.

1.4 Сбор требований к разрабатываемой системе, выявление основных групп пользователей системы

На этапе анализа формировались требования к системе. Это происходило согласно следующему порядку.

Сначала выявлялись цели создания системы (бизнес-требования). Может сложиться впечатление, что фиксация данных требований не является обязательной для разработки. Но в этом случае у команды, как исполнителей, не будет возможности контролировать соответствие разработанной системы тем целям, для которых она создавалась, а так же – возможности устанавливать семантические зависимости между целями разработки системы и сценариями ее использования;

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

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

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

1. Сформулировать требования заказчика понятным языком, полно и без противоречий. Т.е. превратить поток сознания клиента в набор формализованных требований.

2. В некоторых случаях, когда заказчик «сам не знает, чего хочет», предложить оптимальное решение или «подвести» к нему самого заказчика;

3. Проанализировать влияния новых требований на существующую архитектуру и функционал;

4. Задокументировать требования в виде документа или набора документов в требуемом виде. Затем согласовать их и утвердить.

5. Осуществлять верхнеуровневый контроль соответствия реализованного функционала требованиям;

6. Управлять изменениями требований;

7. Осуществлять все взаимодействие с заказчиками по вопросам требований;

Требования к системе, а также основные группы пользователей описаны в разделе 4.1 Технического Задания на систему EBIS.

1.5 Анализ рисков проекта, описание мер уменьшения их влияния на результат выполнения проекта

1.5.1 Описание угроз и возможностей, которые могут возникнуть в процессе работы над проектом

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

1. Необоснованная задержка согласования требований. Причина: несогласованные действия заказчика и исполнителя. Последствия: задержка начала разработки программного обеспечения.

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

3. Непредсказуемое изменение/расширение требований со стороны заказчика. Причина: изменение внешних факторов на стороне заказчика. Последствия: увеличение сроков разработки.

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

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

6. Распад команды разработки. Причина: конфликты на стороне исполнителя. Последствия: провал проекта.

7. Отвлечение сотрудников от текущего проекта к работам с других проектов. Причина: нехватка времени на другие проекты. Последствия: увеличение сроков разработки или провал проекта.

8. Низкая продуктивность на ранних этапах. Причина: «синдром студента» - наличие впереди длительных сроков и отсутствие чувства срочности в работе. Последствия: потеря времени в начале проекта и увеличение сроков разработки.

9. Ненужная оптимизация и оттачивание деталей. Причина: перфекционизм разработчиков. Последствия: увеличение сроков разработки, неверное функционирование продукта.

10. Потеря исходных кодов проекта. Причина: технические сбои или квалификация персонала. Последствия: увеличение сроков разработки или провал проекта.

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

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

К возможностям можно отнести следующие риски:

1. Повторное использование кода. Причина: наработки разработчиков в похожих проектах и иные источники. Последствия: сокращение сроков разработки.

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

1.5.2 Оценки рисков, проведённая аналитиком проекта

Шкала оценки воздействия угроз включает три градации:

1) умеренные;

2) критичные;

3) катастрофические.

Шкала оценки воздействия возможностей включает три градации:

4) умеренные;

5) выгодные;

6) очень выгодные.

Шкала оценки вероятности наступления риска также включает три градации:

7) маловероятно;

8) возможно;

9) очень вероятно.

Матрица рангов главных выявленных рисков приведена в таблице 1.6:

Таблица 6 - Матрица рангов главных выявленных рисков

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

1.5.3 Описание сценариев работы с рисками

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

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

2. Низкая продуктивность на ранних этапах. Симптомы риска: низкая продуктивность. Владелец риска: менеджер по продукту. Метод управления – избегание: короткие итерации, нужные люди в команде, лидерство и развитие команды.

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

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

5. Непредсказуемое изменение/расширение требований со стороны заказчика. Симптомы риска: изменение/расширение требований со стороны заказчика. Владелец риска: менеджер по продукту. Метод управления – принятие риска: ничего не делается для его избегания, передачи, разделения, уменьшения.

На основании полученных данных и приведённых решений, были проанализированы риски при работе над проектом «EBIS» и составлен план управления ими.

1.6 План проекта

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

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

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

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

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

Составление плана проекта включает в себя:

6. Присвоение имени задачам.

7. Указание начала выполнения действия.

8. Указание даты завершения выполнения.

9. Фиксирование фактической даты завершения выполнения действия.

10. Указание ответственного за выполнение (трудового ресурса) задачи.

11. Указание процента завершенности каждого действия.

12. Составление диаграммы Ганта по выполнению проекта.

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

План проекта приложен к сопроводительной документации в электронном виде: файл MS Project 2010 «Razrabotka_EBIS».

2 обоснование выбора основных решений

2.1 Функциональное описание системы

В соответсвии с требованиями, изложенными в техническом задании (приложение A), предлагается следующая структура разрабатываемой системы (рисунок 2.1):

Рисунок 2.1 - Структурная схема разрабатываемой системы

2.2 Формирование предложений по проектируемой системе

Для реализации системы предлагается использовать набор средств и технологий, описанных в п.п. 2.2.1 - 2.2.3.

2.2.1 Система управления базами данных

В качестве СУБД предлагается использовать SQLite.

SQLite - компактная встраиваемая реляционная СУБД. Слово «встраиваемый» означает, что SQLite не использует парадигму клиент-сервер, то есть движок SQLite не является отдельно работающим процессом, с которым взаимодействует программа, а предоставляет библиотеку, с которой программа компонуется и движок становится составной частью программы. Таким образом, в качестве протокола обмена используются вызовы функций (API) библиотеки SQLite. Такой подход уменьшает накладные расходы, время отклика и упрощает программу. SQLite хранит всю базу данных (включая определения, таблицы, индексы и данные) в единственном стандартном файле на том компьютере, на котором исполняется программа.

Основными доводами в пользу применения в проекте СУБД SQLite являются:

7) простота использования;

8) отсутствие необходимости настройки сервера СУБД;

9) возможность простого распространения со своим продуктом;

10) полностью свободная лицензия;

11) кроссплатформенность;

12) высокая скорость на простых операциях;

13) поддержка большого подмножества SQL92;

14) поддержка транзакций, триггеров, представлений (views), вложенных запросов;

15) безопасность использования (БД хранится в одном файле, права доступа к которому можно контролировать стандартными средствами ОС);

2.2.2 Сервер

В качестве сервера предлагается использовать встроенный в Django фреймворк отладочный сервер (см. п.п. 2.2.3 "Web-фреймворк" раздела 2 "Обоснование выбора основных решений"). Это позволит сосредоточится на разработке самого приложения, не углубляясь в тонкости настройки коммерческих web-серверов.

В случае необходимости, например, при увеличении аудитории сервиса, и, следовательно, нагрузки на сервер, существует возможность заменить отладночный сервер на реальный "боевой" сервер, например, Apache. Интеграция Django в Apache осуществляется посредством модуля для Apache именуемого mod python.

2.2.3 Web-приложение

В качестве фреймворка для разработки web-приложения предлагается использовать Django.

Django - свободный фреймворк для веб-приложений на языке Python, использующий шаблон проектирования MVC. Web-сервис на Django строится из одного или нескольких приложений, которые рекомендуется делать отчуждаемыми и подключаемыми. Это одно из существенных архитектурных отличий этого фреймворка от некоторых других (например, Ruby on Rails). Один из основных принципов фреймворка — DRY (англ. Don't repeat yourself).

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

Для работы с базой данных Django использует собственный ORM, в котором модель данных описывается классами Python, и по ней генерируется схема базы данных.

Основные преимущества в использовании Django:

10) язык программирования Python (простота и скорость разработки, большой опыт работы коллектива разработчиков с данным ЯП);

16) открытый исходный код;

17) большое количество качественной документации;

18) кроссплатформенность;

19) встроенный ORM; поддержка архитектурного шаблона MVC;

20) высокая скорость работы при больших нагрузках (Веб-фреймворк Django используется в таких крупных и известных сайтах, как Instagram, Disqus, Mozilla, The Washington Times, Pinterest и др.)

Для создания пользовательского интерфейса предлагается использовать Twitter-bootsrap.

Twitter-bootstrap - это свободный набор инструментов для создания сайтов и веб-приложений. Он включает в себя HTML и CSS шаблоны оформления для типографики, веб-форм, кнопок, меток, блоков навигации и прочих компонентов веб-интерфейсов, включая JavaScript расширения.

Дата добавления: 2015-11-14