УТВЕРЖДАЮ

Зам. директора КЭИ по УР

___________/М.Н.Бабкина/

«___»______________2012 г.

Задание для прохождения производственной практики для студентов, обучающихся по специальности 230105 51 «Программное обеспечение вычислительной техники и автоматизированных систем»

1 Раздел

I. Функциональная структура деятельности предприятия (организации):

• организационно-штатная структура;

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

• порядок технического обеспечения, общие требования к нему;

• отчетность по трудовой деятельности;

• структура рабочего времени;

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

II. Информационная безопасность предприятия (организации):

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

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

• информационная политика безопасности.

2 Раздел

1. Определение жизненного цикла программного продукта предприятия (организации).

2. Планирование работ по созданию программного продукта.

3. Этапы разработки программного продукта.

4. Управление поставками программных продуктов.

5. Инструментальные средства разработки программных продуктов.

6. Защита программных продуктов от несанкционированного использования.

7. Сетевые ресурсы.

8. Технология «Клиент-Сервер».

9. Концентраторы и коммутаторы.

10. Передача данных по сети. Пакеты.

Согласовано на заседании П(Ц)К

«Вычислительная техника и программирование»

Протокол № 2 от «26»февраля 2012 г.

Председатель ______________ / В.Г. Брежнев /

МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ

РОССИЙСКОЙ ФЕДЕРАЦИИ

Государственное образовательное учреждение высшего профессионального

образования

Ульяновский государственный технический университет

КОЛЛЕДЖ ЭКОНОМИКИ И ИНФОРМАТИКИ

Отчёт

о прохождении квалификационной практики

230105 51

«Программное обеспечение вычислительной техники и автоматизированных систем»

Выполнили:

студенты группы ПКдУ 42-10

Шарафутдинов А.З.

Бычков Е.С.

Проверил руководитель

практики:

Мартынова С.С.

Оценка_________________

Ульяновск 2012 г.

1 Раздел

I.Функциональная структура деятельности предприятия (организации):

ОРГАНИЗАЦИОННО-ШТАТНАЯ СТРУКТУРА

«Современное предприятие – будь то коммерческая компания, государственное учреждение, больница или университет, - так же нуждается в четкой организационной структуре, как любой биологический организм, поднявшийся по эволюционной лестнице на следующую после амебы ступень!»

(Питер Ф. Друкер. Задачи менеджмента в 21 веке»)

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

ПОСТРОЕНИЕ ОРГАНИЗАЦИОННО-ФУНКЦИОНАЛЬНОЙ МОДЕЛИ.

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

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

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

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

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

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

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

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

Первой задачей при этом является получение точно идентифицированного функционала, после чего может быть поставлен вопрос об оптимальности его закрепления за звеньями «организационной структуры» и/или проведения реструктуризации компании с цель изменения этой структуры. Номенклатура возможных типов структур в общем известна. (см. «Типология организационных структур»). Общепринятым утверждением стало и то, что подходящей для всех компаний «идеальной» структуры не бывает. Кроме того, Выбор оптимальной для компании «организационной структуры» является предметом стратегического выбора.

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

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

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

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

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

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

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

Можно определить следующие шаги рабочего процесса определения требований*:

• Перечисление возможных требований;

• Осознание контекста системы;

• Определение функциональных требований;

• Определение нефункциональных требований.

Перечисление возможных требований

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

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

• состояние предложения (например, предложено, одобрено, включено в план, утверждено);

• трудоемкость в человеко-часах или стоимость реализации;

• приоритет (например, критический, важный или вспомогательный);

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

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

 Определение функциональных требований

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

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

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

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

 Определение нефункциональных требований

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

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

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

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

Характеристики компьютера:

Процессор – Intel(R) Pentium(R) 4 CPU 3.20GHz

Оперативная память 512 Mb DDR

Видеоадаптер – Intel(R) 82915G Expres Chipset Family 128 Mb

Сетевая плата – Realtek RTL8139/810x Family Fast Ethernet NIC

DVD-CD-RW -Sony CRX320EE

Floppy дисковод

Жесткий диск – WDC WD1600JS-88MHBO 160Gb

Стандартная клавиатура (101/102 клавиши) или Microsoft Natural

Монитор – Belinea –19 дюймов

Программное обеспечение:

Microsoft Office 2007

Операционные система:

Windows XP Professional версия 2008 Serves Pack 3

Структура рабочего времени

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

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

Основным объектом нормирования является рабочее время — продолжительность рабочей смены, которое имеет достаточно сложную структуру (рис1).

Рис. 1. Структура рабочего времени в нормировании труда

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

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

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

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

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

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