Учреждение образования

«Гомельский торгово-экономический колледж» Белкоопсоюза

МЕТОДИЧЕСКИЕ РЕКОМЕНДАЦИИ

по прохождению технологической практики

для учащихся

специальности 2«Программное обеспечение информационных технологий»

Разработала:

Гомель 2011

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

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

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

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

Руководителю практики от организации необходимо:

­  изучить программу практики;

­  ознакомить учащегося с правилами внутреннего распорядка, порядком пользования документами, техническими устройствами;

­  организовать ознакомление учащегося с организацией;

­  создать необходимые условия для выполнения учащимся всех видов работ в соответствии с календарно-тематическим планом;

­  помогать учащемуся в сборе необходимой информации и разработке программного продукта;

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

­  регулярно давать задания учащимся в соответствии с календарно-тематическим планом, а также разъяснять их выполнение;

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

­  осуществлять контроль за качеством и сроками выполнения работы;

­  ежедневно проверять и подписывать дневник-отчет;

­  привлекать учащихся к участию в общественной жизни коллектива;

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

Учащийся-практикант обязан соблюдать следующие требования:

­  знать до отъезда на практику место и время ее прохождения;

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

­  прибыть своевременно к месту практики с тем, чтобы начать ее в установленный срок;

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

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

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

­  отвечать за выполненную работу и ее результаты наравне со штатными работниками организации (предприятия);

­  участвовать в обсуждении вопросов автоматизированной обработки информации на семинарах, конференциях, собраниях работников организации (предприятия);

­  в период практики вести дневник-отчет в соответствии с установленным порядком. Руководитель технологической практики на основании записей в дневнике-отчете определяет объем выполненной за день работы и ежедневно подписывает его;

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

Аналогично необходимо делать записи и по другим темам календарно-тематического плана.

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

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

Форма раздела 4 приведена в приложении 7.

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

Выводы подписываются практикантом.

В приложениях 8 и 9 представлены форма и пример оформления раздела 5.

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

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

В приложениях 10 и 11 представлены форма и пример оформления раздела 6.

После окончания прохождения практики руководитель практики от предприятия должен дать характеристику на учащегося-практиканта.

В ней должно быть отражено:

-  отношение практиканта к работе (интерес, инициатива, самостоятельность, аккуратность, дисциплинированность, исполнительность и т. д);

-  уровень теоретической подготовке учащихся, выявившийся во время прохождения практики;

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

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

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

Пример оформления характеристики приведен в приложении 12.

Примечание: в итоге в дневнике-отчете должно быть 3 печати:

1.  в календарно-тематическом плане;

2.  в разделе «Заключение руководителя практики от организации по дневнику-отчету;

3.  в характеристике.

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

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

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

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

4.2.  Изучение характера работ в аналитических отделах. Разработка заданий на вновь проектируемую систему. Проектирование структуры бизнес-плана.

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

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

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

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

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

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

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

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

Наиболее известный стандарт разработан IEEE и называется IEEE/ANSI [IEEE, 1993] предполагает следующую структуру спецификации:

1. Введение

1.1. Цели документа

1.2. Назначение программного продукта

1.3. Определения, акронимы и аббревиатуры

1.4. Список литературы и других источников

1.5. Обзор спецификации

2. Общее описание

2.1. Описание программного продукта

2.2. Функции программного продукта

2.3. Пользовательские характеристики

2.4. Общие ограничения

2.5. Обоснования, предположения и допущения

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

4. Приложения

В этом же разделе необходимо спроектировать структуру бизнес-плана на разрабатываемую программную систему и разработать ее раздел «Описание продукции, услуг».

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

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

Структура бизнес-плана

1.Резюме

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

Резюме обычно содержит следующую информацию:

-  Название инвестиционного проекта и его цель.

-  Инициатор и другие участники проекта.

-  Общая стоимость проекта, в том числе по этапам его реализации.

-  Срок реализации проекта.

-  Суть проекта и текущее состояние.

-  Этапы реализации проекта.

-  Источники финансирования проекта.

-  Критерии эффективности и финансовые показатели проекта.

-  Выводы.

2.Сведения о компании

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

2.1.Наименование предприятия-инициатора, форма его собственности, организационно-правовая форма, дата регистрации, номер свидетельства о регистрации.

2.2.Профиль деятельности предприятия-инициатора, характеристики его положения на рынке.

2.3.Уставный капитал, учредители и их доли в уставном капитале.

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

2.5.Основные технико-экономические показатели (объем производства, численность работающих, стоимость и структура активов).

2.6.Наименование аудиторов и дата последней аудиторской проверки.

2.7.Полные реквизиты предприятия-инициатора проекта.

3. Цели и задачи проекта

Описание реализации проекта, его смета, сроки и пр.

3.1.Подробное описание сути проекта, этапов его реализации, задач и результатов каждого этапа.

4. План маркетинга

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

Содержит следующие подразделы:

4.1. Анализ рынка

4.1.1. Характеристика деловой среды

4.1.2. Анализ спроса на исследуемых рынках

4.1.3. Анализ предложения на исследуемых рынках

4.2. Выбор целевых сегментов

4.2.1. Анализ местоположения

4.2.2. Позиционирование

4.2.3. Обоснование выбора целевых сегментов

4.3.Обоснование прогноза продаж и бюджета маркетинга

4.3.1. Доходы от сдачи площадей в аренду

4.3.2. Доходы от продажи объектов недвижимости

4.3.3. Программа и бюджет маркетинга проекта

5. Описание продукции, услуг

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

Раскрывает следующие пункты:

5.1. Описание производимой продукции / услуг

5.2. План сбыта продукции и услуг

6. Инвестиционный план

Поэтапное составление сметы затрат на реализацию проекта.

6.1. Прогноз затрат по этапам предпроизводственной стадии

6.2. Сводный календарный график реализации проекта.

7. Производственный план

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

7.1. Описание инфраструктуры проекта

7.2. Поэлементная себестоимость основной продукции/ услуг

7.3. Себестоимость сопутствующих услуг

8. Организационный план

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

8.1. Принципы организации

8.2. Структура компании, описание роли каждого подразделения

8.3. Организационная схема

8.4. План персонала

9. Финансовый план

Рассматривает денежные затраты и доходы, предполагающиеся в ходе реализации проекта.

9.1. Схема финансирования проекта

9.2. Параметры сценариев реализации проекта

9.2.1. Реалистический сценарий

9.2.2. Пессимистический сценарий

9.2.3. Оптимистический сценарий

9.3. Финансовые расчеты и показатели

9.3.1. Исходные данные для расчетов

9.3.2. Результаты финансовых расчетов

9.4. Предложения по оптимизации налогообложения

10. Анализ рисков проекта

Оценка оптимальности проекта и вероятности его реализации:

10.1. Качественный анализ рисков

10.2. Анализ чувствительности (Финансовый анализ рисков)

10.3. Мероприятия по снижению рисков

10.4.Стратегия поведения при возникающих рисках

11. ВЫВОДЫ

об экономической целесообразности проекта.

ПРИЛОЖЕНИЯ

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

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

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

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

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

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

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

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

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

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

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

Определение состава и структуры данных, которые должны быть загружены в базу данных, осуществляется на основе анализа предметной области. Структура дан­ных предметной области может отображаться информационно-логической моде­лью (ИЛМ). Если при построении такой модели обеспечены требования нормализа­ции данных и она соответственно представлена в каноническом виде, далее легко опре­деляется проект логической структуры нормализованной базы данных. На ос­нове канонической модели можно создать реляционную базу без дублирования дан­ных.

Пусть разработана ИЛМ предметной области "Поставка товаров":

Рис. 1. Информационно-логическая модель предметной области "Поставка то­варов"

Логическая структура реляционной базы данных является адекватным отображением полученной информационно-логической модели предметной области. Для канонической модели не требуется дополнительных преобразований. Каждый ин­формационный объект модели данных отображается соответствующей реляцион­ной таблицей. Структура реляционной таблицы определяется реквизитным составом соот­ветствующего информационного объекта, где каждый столбец (поле) соответст­вует одному из реквизитов объекта. Ключевые реквизиты объекта образуют уникаль­ный ключ реляционной таблицы. Для каждого столбца таблицы (поля) задается тип, размер данных и другие свойства. Строки (записи) таблицы соответствуют экзем­плярам объекта и формируются при загрузке таблицы.

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

В СУБД может быть создана схема данных, наглядно отображающая логиче­скую структуру базы данных. Определение одно-многозначных связей в этой схеме должно осуществляться в соответствии с построенной моделью данных. Топо­логия проекта схемы данных практически совпадает с топологией информационно-логической модели. Для модели данных предметной области, построенной в рассмот­ренном примере, логическая структура базы данных в виде схемы данных приведена на рис. 2. На этой схеме прямоугольники отображают таблицы базы данных с пол­ным списком их полей, а связи показывают, по каким полям осуществ­ляется взаимо­связь таблиц. Имена ключевых полей для наглядности выделены и на­ходятся в верх­ней части полного списка полей каждой таблицы.

Рис. 2. Логическая структура базы данных "Поставка товаров"

Нужно разработать и описать интерфейс пользователя, представить форму главного модуля.

Нужно построить и описать графические схемы отдельных модулей программы.

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

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

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

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

Тестирование — процесс выполнения программы с целью обнаружения ошибок. Шаги процесса задаются тестами (тестовыми вариантами).

Каждый тест определяет:

-  свой набор исходных данных и условий для запуска программы;

-  набор ожидаемых результатов работы программы.

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

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

Целью проектирования тестовых вариантов является систематическое обнаружение различных классов ошибок при минимальных затратах времени и стоимости.

На входе процесса тестирования три потока:

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

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

-  ожидаемые результаты.

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

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

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

4.6.  Интеграция разработанного программного средства в автоматизированную систему предприятия (учреждения). Выполнение пилотного проекта. Опытная эксплуатация. Анализ качества выполненного программного средства. Расчет себестоимости программного средства

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

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

Нужно произвести анализ качества выполненного программного средства.

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

Функциональные возможности детализируются:

-  пригодностью для применения по назначению;

-  корректностью (правильностью, точностью) реализации требований;

-  способностью к взаимо­действию с компонентами и средой;

-  защищенностью – безопасностью функционирования.

Надежность характеризуется:

-  уровнем завер­шенности – отсутствием дефектов и ошибок;

-  устойчивостью при наличии дефектов и ошибок;

-  восстанавливаемостью после проявления дефектов;

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

Эффективность рекомендуется отражать:

-  временной эффективностью реализации комплекса программ;

-  используемостью вычислительных ресурсов.

Применимость (практичность) предлагается описывать:

-  понятностью функций и документации;

-  простотой использования комплекса программ;

-  изучаемостью процессов функционирования и применения.

Сопровождаемость представляется:

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

-  изменяемостью компонентов и комплекса программ;

-  тестируемостью изменений при сопровождении.

Мобильность (переносимость) предлагается отражать:

-  адаптируемостью к изменениям среды;

-  простотой установки – инсталляции после переноса;

-  замещаемостью компонентов при корректировках комплекса программ.

Нужно произвести расчет себестоимости разработанного программного средства.

Определение трудоемкости разработки программного продукта:

Определение трудоемкости разработки программного продукта производится на основании опытно-статистического метода, в целом на всю разработку, исходя из того, что ее выполняет один техник-программист. Определение трудоемкости осуществляется в соответствии с ГОСТ 19.102-77 «Стадии разработки» ведется исходя из ориентировочного распределения затрат времени.

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

Таблица 1 Структура времени на создание программного продукта

Время рассчитывается в человеко-часах, причем Тпо берется по фактически отработанному времени, а время остальных этапов определяется расчетно по условному числу команд .

Условное число команд определяется по формуле:

, (1)

где  – коэффициент, учитывающий условное число команд в зависимости от типа задачи, для данной задачи коэффициент принимается = 1450;

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

Выбрать значение коэффициента можно из табл. 2.

Таблица 2 Определение коэффициента, учитывающего условное число команд

Программные продукты по степени новизны могут быть отнесены к одной из 4-х групп:

группа А — разработка принципиально новых задач;

группа Б — разработка оригинальных программ;

группа В — разработка программ с использованием типовых решений;

группа Г — разовая типовая задача.

Для данной задачи степень новизны — Б

По степени сложности программные продукты могут быть отнесены к одной из 3-х групп:

1)  1 — алгоритмы оптимизации и моделирования систем;

2)  2 — задачи учета, отчетности и статистики;

3)  3 — стандартные алгоритмы.

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

Коэффициент определяется из таблицы 3 на пересечении групп сложности и степени новизны.

Таблица 3 Определение коэффициента, учитывающего группу сложности и степень новизны

Для данной задачи коэффициент = 1,26

Теперь, исходя из формулы (1) можно определить условное число команд

(2)

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

1) Tпо (время на подготовку описания задачи), берется по факту и составляет:

Tпо = (3)

2) Tо ( время на описание задачи ) определяется по формуле:

Tо = , (4)

где — коэффициент учета изменений задачи, коэффициент в зависимости от сложности задачи и числа изменений выбирается в интервале от 1,2 до 1,5.Для данной задачи = 1,4;

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

Таблица 4 Определение коэффициента, учитывающего квалификацию программиста

Применяя формулу (4) подсчитаем время на описание задачи:

Tо = (5)

3) Tа (время на разработку алгоритма) рассчитываем по формуле:

Tа = (6)

Применяя формулу (6) подсчитываем время на разработку алгоритма.

Tа = (7)

4)  Tбc (время на разработку блок-схемы) определяется аналогично Tа по формуле (5.6) и составляет

Tб = (8)

5)  Tн (время написания программы на языке программирования) определяется по формуле:

Tн = (9)

Применяя формулу (9), подсчитываем время написания программы на языке программирования:

Tн = (10)

6)  Tнп (время набивки программы ) определяется по формуле :

Tнп = (11)

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

Tнп = (12)

7) Tот (время отладки и тестирования программы) определяется по формуле:

Tот = (13)

Подставляем значения в формулу и получаем:

Tот = (14)

Теперь, зная время, затраченное на каждом этапе, можно подсчитать общее время на создание программного продукта:

T = Tпо + Tо +Tа +Tбс +Tн +Tнп+Tот+ Tд =30 + 51,1 + 36,5 + 36,5 + 54,8 + 36,5 + 153,4 + 40 = 415.8 чел/ час

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

Таблица 5 – Структура – Структура общего времени и трудоемкость разработки программного продукта

Примечание: рабочий проект – машинное время является перекрываемым, т. е. учитывается и в немашинном времени для расчета оплаты труда техника-программиста.

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

Определение стоимости машинного времени:

Составим таблицу 6 с исходными данными для выполнения расчетов.

а) Определение стоимости потребляемой электроэнергии, руб.:

(15)