694_Metodicheskie_rekomendatsii_po_podgotovke_Kanev_V.S

ное приложение и т.п.) и должен осуществляться и обосновываться в предыдущем разделе ВКР.

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

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

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

При необходимости (по усмотрению руководителя ВКР) следует применить специальные методы и средства тестирования разработанных программных средств.

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

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

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

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

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

По объему заключение должно быть не более 5 страниц. Заключение не считается разделом ВКР и не нумеруется.

21

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

Приложение «Библиография» располагают последним (см. приложение И). В нем указываются все использованные при подготовке работы источники (как правило, 20-30 источников, но не менее 10), включая законодательные и нормативные акты, монографии, научные сборники, статьи, электронные ресурсы и т.д. При подготовке работы недопустимо использование устаревших статистических данных и нормативных документов. Должны использоваться источники, изданные в течение последних пяти лет, исключение составляют основополагающие теоретические труды по выбранной теме. На каждый источник в тексте работы должна быть приведена библиографическая ссылка.

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

Приложения нумеруются в порядке ссылки на них, а в тексте делается соответствующая ссылка на данное приложение (аналогично ссылкам на рисунки, формы и т.д.).

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

стовых сокращений его оформляют в виде отдельного приложения (см. приложение К).

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

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

Демонстрационный материал

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

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

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

22

В общем случае в качестве демонстрационного материала могут быть представлены:

актуальность выбранной темы;

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

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

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

схема взаимосвязи решаемой задачи с другими задачами системы в

целом;

полученные теоретические и практические результаты;

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

ний и др.;

выводы по работе.

Рекомендуемая структура доклада на защите ВКР

1Представление темы ВКР.

2Актуальность проблемы.

3Объект и предмет исследования.

4Цель и задачи ВКР.

5Методика исследования.

6Характеристика организации.

7Причины, мешающие эффективному функционированию рассматриваемого объекта.

8Основные выводы по анализу предмета исследования.

9Рекомендации и предложения по совершенствованию предмета исследования.

10Социально-экономическая или социальная эффективность проекта.

11Мероприятия по внедрению проекта.

12Перспективность развития направления.

13Ответы на замечания руководителя ВКР.

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

Приведем пример задания на ВКР и возможное содержание пояснительной записки к ней по теме «Проектирование информационной системы отдела корпоративных продаж телекоммуникационной компании».

Постановка задачи.

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

23

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

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

В любой момент времени потенциальный клиент/заказчик может подать заявку на подключение объекта к услуге компании в письменном или электронном виде. Своевременно получив заявку, менеджер должен отреагировать на нее незамедлительно, уточнив у заказчика необходимые параметры нового «проекта по подключению», а именно: адрес подключения, подключаемую услугу/услуги, контактные данные. После этого менеджер заполняет предопределенную форму «Заявка на подключение юридического лица», подает заявку на новый проект по подключению услуги и ведет его до заключения договора с заказчиком. Далее клиентом занимаются менеджеры службы формирования лояльности ключевых клиентов, которые работают с ним и после принятия в эксплуатацию объекта заказчика.

Заявка на новый проект передается в отдел ТУиПС, где начинается работа над новым проектом по подключению (определяются точки подключения). На основе этих данных ПТО составляет предварительный проект, который передает в ОКС для оценки предварительной стоимости проекта и определения сроков строительства (подключения) клиента.

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

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

24

Содержание работы. Введение

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

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

1.2Анализ существующих систем CRM класса. Аналитическая информационная система «Monitor-CRM»

1.3Технология и методология проектирования ЭИС

2 Постановка задачи на создание ЭИС для отдела корпоративных продаж телекоммуникационной компании

2.1Цели создания ЭИС

2.2Организация документооборота

2.3Функциональная структура ЭИС

2.4Требования к обеспечивающей части ЭИС 3 Создание ЭИС для отдела корпоративных продаж телекоммуникационной компании

3.1Жизненный цикл процесса разработки ЭИС

3.2Глоссарий ИС отдела корпоративных продаж

3.3Применение структурного подхода к проектированию информационной системы

3.4Применение объектно-ориентированного подхода к проектированию ИС

3.5Выбор системных и прикладных программ для создания и эксплуатации ЭИС

3.6Разработка информационной базы ЭИС

3.7Выбор средства разработки специального программного обеспечения ЭИС

3.8Реализация ЭИС для отдела корпоративных продаж в системе 1С:Предприятие

3.9Выбор конфигураций ЭВМ для построения ЭИС

3.10Организация компьютерной сети

3.11Анализ результатов и тестирование ЭИС для отдела корпоративных продаж телекоммуникационной компании

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

3аключение Приложение А Макеты документов, задействованных в

функционировании ЭИС Приложение Б Структура базы данных ЭИС

Приложение В Программные модули приложения ЭИС Приложение Г Технические характеристики АРМ ЭИС

25

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

актуальность и постановка задачи;

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

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

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

модели, разработанные с применением объектно-ориентированного

подхода;

программно-техническая реализация продукта;

краткие результаты расчета экономической и/или какого-либо другого вида эффективности;

выводы, полученные в ходе работы над ВКР.

26

7 Оценка экономической эффективности информационных систем

В данном разделе рассматривается технико-экономическое обоснование (ТЭО) проекта разработки программного средства – методика оценки трудовых, временных и финансовых ресурсов с учетом требований заказчика [20].

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

Последовательность ТЭО определяется следующими этапами:

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

1.2.Для каждого функционального блока проводится оценка сложности кода (как правило, методом экспертных оценок, а в качестве метрики сложности используется число строк кода-LOC).

2.1.В соответствии с выбранной методикой / моделью проводится оценка трудозатрат на разработку каждого блока и всего программного средства (используются различные ресурсные модели или нормативные методы, например, [30]) (трудоемкость).

2.2.В соответствии с выбранной методикой / моделью проводится оценка длительности разработки всего ПС и отдельных его этапов (временные ресурсы).

2.3.В соответствии с выбранной методикой / моделью проводится оценка потребного штатного расписания (трудовые ресурсы).

2.4.Определяется фонд оплаты труда (финансовые ресурсы).

2.5.В соответствии с выбранной методикой / моделью проводится оценка дополнительных ресурсов (в случае необходимости).

1.1. Выделяя функциональные блоки, необходимо проводить детализацию до уровня реализации конкретной простой бизнес-функции. При этом образуется иерархия функциональных блоков в соответствии с покрываемыми бизнес-процессами [20]:

программный компонент (программный код элементарной функции);

сложный программный компонент (программный код, поддерживающий комплексированные функции бизнес-процессов);

программный комплекс (программные компоненты, поддерживающие конкретный бизнес-процесс);

программная система (реализует совокупность бизнес-процессов);

интегрированная программная система.

27

1.2. В качестве метрики сложности, учитывая, что различные языки программирования и, соответственно, компиляторы и среды разработок при решении одинаковой задачи приводят к коду различной длины, рекомендуется использовать LOC языка низкого уровня целевой платформы (байт-код в случаи Java, платформы NET и т.п.; ассемблер – в случаи компиляции в исполняемый файл и т.д.).

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

2.1. Располагая значением LOC, можно оценить затраты ресурсов на реализацию проекта ПС.

На первых итерациях и при предварительных оценках можно воспользоваться имеющимися статистическими данными. Так в соответствии с [42] при разработке ПС первого класса сложности преимущественно на языке Ассемблер – 60-80 строк/чел.-месяц; при разработке ПС второго класса сложности (ИПС) на языках высокого уровня – 250-260 строк/чел.-месяц.

Таблица 7.1 – Оценки трудоемкости разработки проекта ИС [42]

Располагая значениями трудоемкости и LOC, можно определить трудозатраты:

Затраты Размер , Трудоемкость

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

Штат Затраты . Время

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

При построении COCOMO II для обработки статистических данных использовался байесовский анализ, который дает лучшие результаты для про-

28

граммных проектов, характеризующихся неполнотой и неоднозначностью, в отличие от многофакторного регрессионного анализа, примененного в COCOMO. Также в ней допускается измерять размер проекта не только числом строк кода, но и более современными функциональными и объектными точками. Помимо прочего, при расчете показателей COCOMO II учитывает уровень зрелости процесса разработки в соответствии с моделями SEI CMM/CMMI.

Модель COCOMO II условно разделяют на три класса проекта: ограниченные, полуинтегрированные и встроенные системы.

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

Полуинтегрированные проекты (промежуточные) – системы среднего размера и сложности, разрабатываемые группами разработчиков с различным опытом, требования к ПО более жесткие. Примерами таких проектов могут быть СУБД, мощные системы управления производством.

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

Существует три вида модели COCOMO II (иерархия моделей), выбор которых зависит от типа проекта и стадии разработки.

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

Затраты NOP ,

PROD f (опыт / возможности разработчика;

зрелость / возможности среды разработки),

где NOP– количество новых объектных указателей;

PROD – производительность/скорость разработки, выраженная в единицах измерения объектных указателей.

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

29

Затраты a Размер b M e Затраты auto ,

b f(PREC, FLEX, RESL,TEAM,PMAT ),

Me f ( PERS,RCPX,RUSE,PDIF,PREX,FCIL,SCED ),

где a 2,5 – масштабный коэффициент; Размер – размер системы, тыс. LOC;

PREC – наличие опыта аналогичных разработок; FLEX – гибкость процесса разработки;

RESL – архитектура и управление рисками; TEAM– сработанность команды;

PMAT– зрелость процессов; PERS – возможности персонала;

RCPX – надежность и сложность продукта;

RUSE – требуемая повторная используемость; PDIF– трудность платформы;

PREX – опыт персонала;

FCIL – средства поддержки;

SCED – требуемый график разработки;

Затратыauto – затраты на автоматическую генерацию кода (при ее наличии).

Модель постархитектуры сопряжена с эксплуатацией программной системы и непосредственно кодированием программного средства, использует оценки с распределением их по этапам жизненного цикла, по отдельным подсистемам и модулям программного средства:

Затраты a k Размерb M p Затратыauto ,

BRAK k 1 ,

100

Размер Размерnew Размерreuse,

b f(PREC, FLEX, RESL,TEAM,PMAT ),

M p f(RELY, DATA,CPLX,REUSE, DOCU;

TIME, STOR,PVOL;

ACAP, PCAP,AEXP, PEXP, LTEX, PCON; TOOL, SITE,SCED),

где a 2,5 – масштабный коэффициент;

k – коэффициент, учитывающий возможные изменения в требованиях;

BRAK – процент отброшенного кода;

Размер – размер системы, тыс. LOC;

PREC – наличие опыта аналогичных разработок; FLEX – гибкость процесса разработки;

30