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

• Название: Сокращения, определения, используемые в отчете
• Дата: 27.06.2022
• Размер: 480.19 Kb.
• Имя файла: Otchet_Samarin_E.docx
• Тип: Отчет; #616759

Оглавление

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

АИС – автоматизированная информационная система.

АФР – архитектор функциональных решений.

БД – база данных. БД – некоторый набор перманентных (постоянно хранимых) данных, используемых прикладными программными системами какого-либо предприятия.

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

НСИ – нормативно –справочная информация.

ПО – программное обеспечение.

РМ – реляционная модель.

РБД – реляционная база данных.

СУБД – система управления базой данных

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

Спринт – итерация в методологии Scrum, в ходе которой создается версия продукта.

2. Введение

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

Мной была пройдена производственная практика в компании АО «Геликон Про», в должности системного аналитика. Период производственной практики с 17.06.2019 по 16.07.2019.

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

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

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

• 
  углубить теоретические и практические знания.
  
• 
  Изучить внутренние документы компании.
  
• 
  Изучить систему «АвтоКонтроль».
  
• 
  Изучить теорию реляционных баз данных.
  
• 
  Разработать реляционную базу данных.
  
• 
  Оформить отчет по результатам производственной практики.
  

3. Характеристика предприятия

Компания «Геликон Про» работает на рынке информационных технологий с 1994 года.

Основное направление деятельности – разработка программных продуктов различного назначения и сложности:

• 
  автоматизация уникальных бизнес-процессов;
  
• 
  решения для автоматизации предприятий водоснабжения и водоотведения;
  
• 
  разработка платежных систем, включающих различные инструменты для работы с клиентами: платежные терминалы, web-ресурсы, мобильные и стационарные телефоны;
  
• 
  создание различных интернет-решений, в том числе корпоративных порталов, разработка личных кабинетов;
  
• 
  создание мобильных приложений;
  
• 
  интеграция различных информационных систем (обмен данными между системами, создание единой системы отчетности и т.д.);
  
• 
  сбор данных из территориально распределенных подразделений (создание центральных хранилищ данных, синхронизация данных между филиалами или подразделениями, получение консолидированной отчетности);
  
• 
  интеграция информационных систем с ГИС;
  
• 
  решения для пенсионных фондов;
  
• 
  интеграция информационных систем с разнообразным оборудованием, в том числе уникальным;
  

4. Должностные обязанности системного аналитика

В компании АО «Геликон Про» есть отдел системного анализа. Отдел состоит из руководителя отдела и 11 системных аналитиков.

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

Системный аналитик с учетом исполняемых ролей на проектах:

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

5. Жизненный цикл, этапы и методология разработки ПО

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

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

• 
  определение стратегии,
  
• 
  анализ,
  
• 
  проектирование,
  
• 
  реализация,
  
• 
  тестирование и отладка,
  
• 
  внедрение, эксплуатация и сопровождение.
  

Рассмотрим подробнее каждый из этапов.

1. 
   Определение стратегии
   

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

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

2. 
   Анализ
   

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

Вся информация о системе, собранная на этапе определения стратегии, формализуется и уточняется на этапе анализа.

3. 
   Проектирование
   

На этапе проектирования формируется модель данных. Проектировщики получают входные данные анализа. Конечным продуктом этапа проектирования являются схема базы данных (если таковая существует в проекте) или схема хранилища данных (ER-модель) и набор спецификаций модулей системы (модель функций).

Задачами проектирования являются:

• рассмотрение результатов анализа и проверка их полноты;

• семинары с заказчиком;

• определение критических участков проекта и оценка ограничений проекта;

• определение архитектуры системы;

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

•проектирование хранилища данных: модель базы данных, бета-версия базы данных;

• проектирование процессов и кода: окончательный выбор средств разработки, определение интерфейсов программ, отображение функций системы на ее модули и определение спецификаций модулей;

• определение требований к процессу тестирования;

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

4. 
   Разработка
   

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

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

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

5. 
   Тестирование
   

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

Собственно, тесты систем можно разделить на несколько категорий:

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

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

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

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

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

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

• отказ отдельного компонента информационной системы;

• отказ группы компонентов информационной системы;

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

• отказ операционной системы;

• жесткий сбой (отказ питания, жестких дисков).

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

6. 
   Внедрение
   

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

Ввод в эксплуатацию проходит как минимум три стадии:

• первоначальная загрузка информации;

• накопление информации;

• выход на проектную мощность (то есть собственно переход к этапу эксплуатации).

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

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

Этот этап является также наиболее серьезным тестом — тестом одобрения пользователем (customer acceptance tests). Если этого не было сделано на этапе тестирования, то на этапе внедрения это непременно произойдет, и тестировщиком фактически будет ваш собственный заказчик, что не всегда приемлемо, особенно если для последнего это будет несколько неожиданно.

Выход системы на проектную мощность в хорошем варианте — это доводка мелких ошибок и редкие серьезные ошибки.

7. 
   Эксплуатация и техническая поддержка
   

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

Условия технической поддержки и ситуации, которые попадают под понятие «техническая поддержка», а также условия оплаты определяются, как правило, в отдельном документе.

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

1. Методологии разработки ПО

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

1. Waterfall

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



Рис. 1 Каскадная методология разработки

Преимущества:

• 
  Полная и согласованная документация на каждом этапе;
  
• 
  Простота использования;
  
• 
  Стабильные требования.
  
• 
  Бюджет и дедлайны заранее определены
  

Недостатки:

• 
  Большое количество документации;
  
• 
  Не очень гибкая система;
  
• 
  Нет возможности вернуться на шаг назад.
  

2. Scrum

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



Рис. 2 Scrum методология

Вся разработка делится на спринты (зачастую 2-3 недели). Есть backlog (список задач) для всего периода разработки и для каждого спринта отдельно. Каждая задача имеет свой story point (оценку сложности). У каждого участника процесса есть своя роль:

Scrum-команда – это команда, работающая над проектом (разработчики, тестеры, дизайнеры).

Scrum-мастер – человек, который следит, чтобы соблюдались принципы скрама.

Product owner – заказчик.

Так как в этой системе ставка сделана на общение, то присутствует большое количество митингов (совещаний):

Stand-up – короткий митинг, проводится каждый день, принимают участие все члены команды и каждый участник отвечает на 3 вопроса: что делал? Что будет делать? И какие есть трудности?

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

Ретроспектива – проводится в конце спринта и её суть – выяснить, что было сделано хорошо и что можно было улучшить.

Преимущества:

• 
  Заказчик может наблюдать результат в процессе разработки.
  
• 
  Ежедневный контроль над процессом разработки.
  
• 
  Возможность вносить коррективы во время разработки.
  
• 
  Налаженные коммуникации со всеми членами команды.
  
• 
  Малое количество документации.
  

Недостатки:

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

3. Kanban

Kanban – система, построенная на визуализации процесса выполнения задач команды. Основная идея в этой системе - уменьшать количество задач, выполняющихся в данный момент (в колонке «in progress»). В scrUm ориентация команды на успешное выполнение спринтов, в Kanban на первом месте задачи. Хорош для проектов, которые в стадии поддержки где основной функционал уже разработан и остались минимальные доработки и устранение ошибок. В Kanban задачи сдаются индивидуально. Задача независимо от других задач проходит по всем этапам на доске и как только она выполнена её можно показать заказчику. Канбан доска состоит из колонок, каждая из которых это отдельный процесс разработки. На некоторые столбцы (например, in progress) вводят ограничения по количеству задач, которые там могут находиться. Это помогает легко и быстро находить проблемные места в распределении задач. На рис. 3 пример самой просто такой доски.



Рис. 3. Канбан-доска

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

To do – список задач, которые надо сделать.

In progress – задачи над которыми ведется работа в данный момент.

Code review – задачи, которые сделаны и отправлены на проверку.

In testing – задачи, готовые к тестированию.

Done – сделанные задачи.

Преимущества:

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

Недостатки:

Нестабильный список задач.

Сложно применять на долгосрочных проектах.

Отсутствие жестких дедлайнов.

6. Автоматизированная система по управлению транспортом «АвтоКонтроль»

На период прохождения практики в АО «Геликон Про» велась разработка АС «АвтоКонтроль». Методология разработки была выбрана Scrum. Как аналитик я должен был изучить систему, и разрабатывать различные функции в соответствии с требованиями. Система «АвтоКонтроль» предназначена для управления транспортом сетевой коммунальной компании. Система состоит из нескольких подсистем. Это подсистемы: отображения, API, хранения, подсистема интеграции с внешними системами. Модули, объединены в «Контуры» по принципу общих характеристик. Например, контур НСИ содержит справочники необходимые для работы в системе. В течение производственной практики в рамках проекта АС «АвтоКонтроль», мне были поставлены следующие задачи:

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

7. Реляционная база данных

В основе любой промышленной системе лежит БД. Существует огромное количество разновидностей БД, отличающихся по различным критериям. В основе системы «АвтоКонтроль» лежит РБД, поэтому в рамках моей практики я изучил теорию, связанную с РБД.

1. Теория РБД

РБД основана на РМ данных. РМ - это способ представления данных и правила работы с такими представлениями. РМ связанна с 3 аспектами данных: структура, целостность, обработка данных.

1. Структура РБД

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

2. Целостность реляционных данных

   1. Ключи

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

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

Уникальность предполагает что в произвольный момент времени никакие две различные строки в Т не имеют одни и те же значения , … .

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

Все ключи отличные от первичного – альтернативные.

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

2. Правила целостности

Выделают 2 правила целостности

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

Целостность по ссылкам. Если таблица содержит внешний ключ на таблицу , то каждое значение FK в таблице должно либо быть равным значению PK для некоторой строки . Либо быть неопределенным

3. Правила внешних ключей

Чтобы обеспечить целостность РБД удаление (обновление) данных из таблиц должно подчиняться одному из двух правил.

Каскадное удаление (обновление). Если удалятся строка из , то удаляются все строки из … соответствующей строке из по внешнему ключу.

Ограниченное удаление (обновление). При удалении строки из проверяется наличие в … строк соответствующим из по внешнему ключу. Если такие строки в … имеются, то удаление отменяется.

3. Обработка данных

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

2. Практика

В рамках задания, полученного на практике я разработал РБД для проекта «Домашний бюджет». РБД должна хранить данные о бюджете отдельной семьи.

Разработка РБД состояла из нескольких этапов, а именно: логическое проектирование и физическое.

1. Логическое проектирование

Логическое проектирование состоит в определение количества таблиц (сущностей) их структуры и связи. Используя MS Visio, я разработал диаграмму сущность связь в нотации Чена (рис. 4).



Рис. 4 ER диаграмма

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

1. 
   Физическое проектирование
   

Физическое проектирование состоит в определение типов и размеров полей таблиц. Физическое проектирование было выполнено в программе MySql (рис. 5).



Рис. 5. РМД «Домашний бюджет»

8. Вывод

Во время практики в АО «Геликон Про» я изучил внутренние документы компании, изучил систему «АвтоКонтроль», разрабатывал постановки на разработку новых функций. Изучил теорию реляционных баз данных, разработал собственную реляционную базу данных «Домашний бюджет», а также освоил программы MySQL и MS Visio.

9. Список литературы

1. 
   Дейт К. Введение в системы баз данных. – Киев: Диалектика, 1998.
   
2. 
   Диго С.М. Проектирование и использование баз данных. – М.: Финансы и статистика, 1998.
   
3. 
   URL: https://habr.com/ru/company/edison/blog/267569/ [дата обращения – 10.07.2019]
   
4. 
   URL: https://habr.com/ru/company/edison/blog/269789/ [дата обращения – 12.07.2019]