Лабораторная работа, РГР на тему Прием в эксплуатацию нового транспортного средства
-
Оформление работы
-
Список литературы по ГОСТу
-
Соответствие методическим рекомендациям
-
И еще 16 требований ГОСТа,которые мы проверили
Введи почту и скачай архив со всеми файлами
Ссылку для скачивания пришлем
на указанный адрес электронной почты
Содержание:
Программно-аппаратные
средства, используемые при выполнении работы
Список используемых источников и литературы
Введение:
Цель
работы
Изучить
методологии функционального моделирования IDEF0 и IDEF3 на примере транспортной
отрасли.
Введение
Лабораторная
работа направлена на ознакомление с методологиями функционального моделирования
IDEF0 и IDEF3, получение навыков по применению данных методологий для
построения функциональных моделей на основании требований к информационной
системе.
IDEF0 (Integrated Definition Function Modeling) —
методология функционального моделирования. В основе IDEF0 методологии лежит
понятие блока, который отображает некоторую бизнес-функцию. Четыре стороны
блока имеют разную роль: левая сторона имеет значение "входа", правая
— "выхода", верхняя — "управления", нижняя —
"механизма" (аналогично схемы Цикла Деминга для процессного
менеджмента).
На сегодняшний день получили распространение три
основные методологии функционального моделирования (и сопутствующий им
инструментарий): IDEF (Integrated DEFinition), UML (Unified Modeling Language)
и ARIS (Architecture of Integrated Information Systems). Для каждой из них
существуют определенные программные продукты, которые помимо разработки
позволяют проводить преобразования и операции для последующей работы с
полученными моделями (Соммервиль Иан, 2002; Якобсон А., Буч Г., Рамбо Дж.,
2002; Константайн Л., Локвуд Л., 2004; Иванова Г.С., 2002; Солощук М.Н. и др.,
2010). Наибольшее распространение сегодня получили методологии IDEF и
программные продукты BPWin, содержащие методологии IDEF0, IDEF3, DFD (Data Flow
Diagrams) и ERWin (IDEF1x) от компании Computer Associates.
История IDEF начинается с 70-х годов ХХ века с
методологии SADT (Structured Analysis and Design Technique), разработанной
Дугласом Россом (Softtech INC). Изначально SADT применялось Министерством обороны
США для практического моделирования процессов в рамках программы ICAM
(Integrated Computer Aided Manufacturing). Принципиальным требованием при
разработке рассматриваемого семейства методологий была возможность эффективного
обмена информацией между всеми специалистами — участниками программы ICAM (Icam
DEFinition). В последующем эта методология была трансформирована в стандарт
IDEF0 (Function Modeling, FIPS №183). Семейство IDEF включает уже упомянутые
IDEF3 (Process Description Capture) и IDEF1x (Data Modeling, FIPS №184).
После опубликования стандарты были успешно применены в
самых различных областях бизнеса, показав себя эффективным средством анализа,
конструирования и отображения бизнес-процессов (к слову сказать, они активно
применяется и в отечественных госструктурах, например, в Государственной
Налоговой Инспекции). Более того, собственно с широким применением IDEF (и
предшествующей методологии SADT) и связано возникновение основных идей
популярного ныне понятия "реинжиниринг бизнес-процессов" (Business
Process Reengineering — BPR).
Информационный процесс — это устойчивый процесс
(последовательность работ и действий с данными и информацией), относящийся к
сопровождению производственно-хозяйственной деятельности компании и обычно
ориентированный на информационное обслуживание создания новой стоимости.
Бизнес-процесс включает в себя иерархию взаимосвязанных функциональных
действий, реализующих одну (или несколько) бизнес-целей компании и отражающий
результаты в информационной системе, например, информационное обеспечение
управления и анализа выпуска продукции или ресурсное обеспечение выпуска
продукции (под продукцией здесь понимают товары, услуги, решения, документы).
Работа с использованием метода IDEF начинается с
постановки цели моделирования. Мировой опыт свидетельствует, что ошибки при
постановке цели приводят в среднем к 50% неудач в процессе моделирования.
Формулирование цели изначально направляет работу в заданном направлении, а
значит, ограничивает круг вопросов для анализа. Практическая работа начинается
с определения контекста (Context, Context Diagram), то есть верхнего уровня
системы, в нашем случае — предприятия. После формулировки цели необходимо
очертить область моделирования (Scope), которая в последующем будет определять
общие направления движения и глубину детализации (Decomposition). Собственно,
сама методология IDEF определяет стандартизированные объекты для работы и
отображения. Например, к таковым относятся функция (Activity), интерфейсная
дуга (Arrow), заметка (Note), а также способ их расположения и трактования
(Semantics). В последнее время на российском рынке появился программный продукт
Business Studio, который специально создан для работы с методами IDEF и
обладает интуитивным и дружественным интерфейсом (User-friendly Interface), и
подкреплен нормативной базой (Р 50.1.028-2001).
В основе нотации и методологии IDEF0 лежит понятие
"блока", то есть прямоугольника, который выражает некоторую функцию
бизнеса (рис. 6.10). В соответствии со стандартом функция должна быть выражена
глагольным оборотом. В IDEF0 роли сторон прямоугольника (функциональные
значения) различны: верхняя сторона имеет значение "управление",
левая — "вход", правая — "выход", нижняя — "механизм
исполнения" (рис.1).
Заключение:
Изучен предлагаемый теоретический
материал и построено функциональную модель системы. Функциональная модель
системы, описанной в Лабораторной работе № 1-4, построена так, что она отвечает
всем предъявленным к системе требованиям, представляет полный функционал
системы и её основные бизнес-процессы.
Фрагмент текста работы:
Описание
Построение
контекстной диаграммы
Основу
методологии IDEF0 составляет графический язык описания процессов. Модель в
нотации IDEF0 представляет собой совокупность иерархически упорядоченных и
взаимосвязанных диаграмм. Каждая диаграмма является единицей описания системы и
располагается на отдельном листе.
Модель (AS-IS, TO-BE или SHOULD-BE)
может содержать 4 типа диаграмм (Вендров, А.М., 1998;
Д.А. Марка, К. МакГоуэн, 1993; С.В. Маклаков, 2005; В.В. Анисимов, 2020):
—
контекстную диаграмму;
—
диаграммы декомпозиции;
—
диаграммы дерева узлов;
—
диаграммы только для экспозиции (for exposition only, FEO).
Контекстная диаграмма (диаграмма
верхнего уровня), являясь вершиной древовидной структуры диаграмм, показывает
назначение системы (основную функцию) и ее взаимодействие с внешней средой. В
каждой модели может быть только одна контекстная диаграмма. После описания
основной функции выполняется функциональная декомпозиция, т. е. определяются
функции, из которых состоит основная.
Как было отмечено, построение модели
IDEF0 начинается с представления всей системы в виде простейшей компоненты
(контекстной диаграммы). Данная диаграмма отображает назначение (основную
функцию) системы и необходимые входные и выходные данные, управляющую и
регламентирующую информацию, а также механизмы.
Контекстная диаграмма для задачи
определения допускаемых скоростей показана на рис.1. Для построения модели
использовался продукт BPwin 4.0 фирмы Computer Associates.
Содержание:
Программно-аппаратные средства,
используемые при выполнении работы:
Список используемых
источников и литературы
Введение:
Лабораторная работа направлена на
ознакомление с основными элементами определения, представления, проектирования и
моделирования программных систем с помощью языка UML, получение навыков по применению
данных элементов для построения объектно-ориентированных моделей ИС на основании
требований.
Существует множество технологий и
инструментальных средств, с помощью которых можно реализовать в некотором смысле
оптимальный проект ИС (Константайн Л., Локвуд Л., 2004; Иванова Г.С., 2002) начиная
с этапа анализа и заканчивая созданием программного кода системы (Соммервиль Иан,
2002; Якобсон А., Буч Г., Рамбо Дж., 2002).
. В большинстве случаев эти технологии
предъявляют весьма жесткие требования к процессу разработки и используемым ресурсам,
а попытки трансформировать их под конкретные проекты оказываются безуспешными (А.
М. Гудов, С. Ю. Завозкин, С. Н. Трофимов. Кемерово, 2009). Эти технологии представлены
CASE-средствами (Computer — Aided Software Engineering) верхнего уровня, или CASE-средствами
полного жизненного цикла (upper CASE tools или fulllife-cycle CASE tools). Они не
позволяют оптимизировать деятельность на уровне отдельных элементов проекта, и,
как следствие, многие разработчики перешли на так называемые CASE-средства нижнего
уровня (lower CASE tools). Однако они столкнулись с новой проблемой – проблемой
организации взаимодействия между различными командами, реализующими проект, что
разрешается интегрированными CASE-средствами.
Унифицированный язык объектно-ориентированного
моделирования Unified Modeling Language (UML) явился средством достижения компромисса
между этими подходами.
Существует достаточное количество
инструментальных средств, поддерживающих с помощью UML жизненный цикл информационных
систем, и, одновременно, UML является достаточно гибким для настройки и поддержки
специфики деятельности различных команд разработчиков.
UML представляет собой объектно-ориентированный
язык моделирования, обладающий следующими основными характеристиками:
·
является языком визуального моделирования, который обеспечивает разработку репрезентативных
моделей для организации взаимодействия заказчика и разработчика ИС, различных групп
разработчиков ИС;
·
содержит механизмы расширения и специализации базовых концепций языка.
UML – это стандартная нотация визуального
моделирования программных систем, принятая консорциумом ObjectManagingGroup (OMG)
осенью 1997 г., и на сегодняшний день она поддерживается многими объектно-ориентированными
CASE-продуктами.
UML включает внутренний набор средств
моделирования, которые сейчас приняты во многих методах и средствах моделирования.
Эти концепции необходимы в большинстве прикладных задач, хотя не каждая концепция
необходима в каждой части каждого приложения. Пользователям языка предоставлены
возможности:
·
строить модели на основе средств ядра, без использования механизмов расширения
для большинства типовых приложений;
·
добавлять при необходимости новые элементы и условные обозначения, если они
не входят в ядро, или специализировать компоненты, систему условных обозначений
(нотацию) и ограничения для конкретных предметных областей.
Стандарт UML предлагает следующий
набор диаграмм для моделирования:
ü диаграммы вариантов использования (usecasediagrams)
– для моделирования бизнес-процессов организации и требований к создаваемой системе);
ü диаграммы классов (classdiagrams) – для моделирования статической структуры классов
системы и связей между ними;
ü диаграммы поведения системы (behaviordiagrams);
ü диаграммы взаимодействия (interaction diagrams);
ü диаграммы последовательности (sequence diagrams)
и
ü кооперативные диаграммы (collaborationdiagrams) – для
моделирования процесса обмена сообщениями между объектами;
ü диаграммы состояний (statechartdiagrams) – для моделирования
поведения объектов системы при переходе из одного состояния в другое;
ü диаграммы деятельностей (activitydiagrams) – для моделирования
поведения системы в рамках различных вариантов использования, или моделирования
деятельностей;
ü диаграммы реализации (implementationdiagrams):
ü диаграммы компонентов (componentdiagrams) – для моделирования
иерархии компонентов (подсистем) системы;
ü диаграммы развертывания (deploymentdiagrams) – для моделирования
физической архитектуры системы.
Заключение:
Изучены основные элементы определения,
представления, проектирования и моделирования программных систем с помощью языка
UML. Построены диаграммы вариантов использования, классов, взаимодействия, состояний
и размещений для разрабатываемой системы. Проанализированы современные
теоретические подходы и практика применения для транспортного сектора.
Фрагмент текста работы:
Описание
Диаграмма вариантов использования
CASE-средства
на разных этапах жизненного цикла (лекция 3, рис.1) предоставляют поддержку
средств разработки систем на последовательных этапах процесса разработки
программного обеспечения и управления проектами по направлениям:
o
составление и
текущий контроль (мониторинг) проектного плана
o
управление
ресурсами
·
сбор и анализ
требований:
o
сбор
информации: анализ анкет
o
моделирование
функциональных процессов (бизнес-процессов)
o
прототипирование,
т.н. создание решения с ограниченной функциональностью и на основе этого
получения откликов (обратной связи) от пользователей
o
управление
требованиями: документирование требований, ссылки, оснащение требований
атрибутами (ясность требований, источники требований и т.д.), приоритетность
требований, управление версиями требований (связь с заявителем изменения и
причины изменения) и т.д.
o
инструментальные
средства, поддерживающие анализ и сбор требований, должны допускать
коллективную работу, в том числе позволять нескольким пользователям изменять
требования одновременно, предоставлять возможность определять различные права
для разных ролей пользователей (менеджер (руководитель) проекта, аналитик,
архитектор, пользователь)
o
составление
модели данных и словаря, избегая таким образования неоднозначности и проблемы
качества данных (включая дублирование)
o
автоматическое
генерирование документации из существующего, недокументированного кода
Содержание:
Программно-аппаратные средства, используемые
при выполнении работы.
Основная часть (описание самой работы)
Пользовательские требования на основе диаграмм
Введение:
Лабораторная работа направлена на ознакомление с
процессом разработки требований к информационной системе и составления
технического задания на разработку программного обеспечения, получение навыков
по использованию основных методов формирования и анализа требований.
Требования к результатам выполнения лабораторного
практикума:
1. Представление
диаграммы идентификации точек зрения на основании метода VORD, и диаграммы иерархии точек зрения;
2. Наличие
пользовательских требований, четко описывающих будущий функционал информационной
системы;
3. Наличие
системных требований, включающих требования к структуре, программному
интерфейсу, технологиям разработки, общие требования к системе (надежность,
масштабируемость, распределённость, модульность, безопасность, открытость,
удобство пользования и т.д.);
4. Наличие
составленного технического задания, включающего все предусмотренные уровни модели, описание
функциональных блоков, потоков данных, хранилищ и внешних объектов.
Заключение:
В ходе
выполнения лабораторной работы построена диаграмма идентификации точек зрения и
диаграмма иерархии точек зрения, описаны пользовательские и системные
требования, проанализированы требования к информационной системе для
транспортного предприятия.
Информация является решающим фактором, который
определяет развитие технологии транспортного процесса и ресурсов в целом. Цель
реализации информационных технологий на транспорте — это повышение
эффективности транспортного процесса на базе использования современных
компьютеров, распределенной переработки информации, баз данных, различных
информационно- вычислительных сетей путем обеспечения циркуляции и переработки
информации. Информационные потребности на АТП являются структурированными, т.к.
специалистам в разных предметных областях требуется разнообразное, как по
содержанию, так и по форме информация. Однако их функциональное и процессное
согласование при разработке ПО требует применения современной методологии.
По результатам обследования опорных точек зрения и вычленения их
иерархии в функциональных (процессных) группах, аналитик на первой стадии
анализа выстраивает обобщенную логическую модель исходной предметной области,
отображающую ее функциональную структуру, особенности основной деятельности и
информационное пространство, в котором эта деятельность осуществляется. Бизнес-процесс в
масштабах предприятия реализуется в виде сети основных, вспомогательных,
поддерживающих и управленческих процессов. На этом материале аналитик строит функциональную
модель "Как есть" (As Is).
По результатам испытаний, вырабатывается окончательная модель ПО.
Фрагмент текста работы:
Разработка требований — это процесс, включающий
мероприятия, необходимые для создания и утверждения документа, содержащего
спецификацию системных требований. Анализ требований, разработка информационной модели будущей
системы и построение уровней модели для информационной системы «Транспорт»,
осуществлено с учетом Комплекса стандартов на автоматизированные системы, в
т.ч. ГОСТ 34.602-89 Техническое задание на создание автоматизированной системы.
Система «Транспорт»
должна обеспечивать добавление, изменение, удаление информации о компонентах
транспортно-логистической системы, как для внутренних и внешних пользователей
различных видов и уровней.
При помощи
системы составляется административно-производственная картотека. Аналитическая
карточка содержит затребованную информацию по избранному подразделению или
видам работ.
Следующей
стадией процесса формирования требований будет идентификация опорных точек
зрения и сервисов. Сервисы должны соответствовать опорным точкам зрения. Но
могут быть сервисы, которые не поставлены им в соответствие. Это означает, что
на начальном этапе "мозговой атаки" некоторые опорные точки зрения не
были идентифицированы. В связи с этим, используются 2 типа (рис. 1 а, б) построения
баз банных (БД) –иерархический и сетевой (Бородина А.И., 2019), комбинируемые
по отдельным модулям в виде реляционной СУБД, на основе процессных подходов по
уровням организационных задач (рис.1в).
Содержание:
Программно-аппаратные средства, используемые
при выполнении работы
Список используемой литературы
Введение:
Поставленной перед нами задачей
является создание автоматизированной информационной системы работы транспортной
организации.
На современном этапе развития
производительных сил и производственных отношений, информация стала товаром со
всеми присущими ей свойствами. Сегодня существуют информационная
промышленность, национальные информационные ресурсы, происходит переход от
индустриальной экономики к экономике, основанной на информации. Особенно это
актуально для транспорта, как отрасли народного хозяйства, которая все больше
расширяет свое значение не только для внутригородских, областных и межрегиональных,
но и для международных перевозок, выступая одной из ведущих составляющих
глобальной экономической интеграции (Мальганова И.Г., 2014). На переломе
тысячелетий, принципиально возрастает внимание к анализу исключительной роли
высокотехнологичного комплекса (ВТК) в развитии национальной экономики. Главный
тезис заключается в том, что технико-технологическая независимость и в целом
национальная безопасность страны в значительной степени определяются тем,
насколько хорошо развит в составе ее экономики ВТК (Николаева Т.П., 2005). Соответственно
возрастает дифференциация, диверсификация и многоуровневая ложность
информационных систем для отраслей ВТК, где средства радиоэлектроники и ПО
играют ведущую роль (О.
В. Демкина, Н.Г. Шаламова, 2019), в частности применительно
для транспорта.
Для того чтобы описать и проанализировать предметную область (И. Сммервиль,
2002; Якобсон А., Буч Г., Рамбо Дж., 2002), нам придется столкнуться с такими
аспектами данной работы, как:
·
понимание языка, на котором
говорят заказчики (терминология);
·
выявление цели их деятельности;
·
определение набора решаемых ими
задач;
·
определение набора сущностей, с
которыми приходится иметь дело при решении задач (Константайн Л., Локвуд Л.,
2004; Иванова Г.С., 2002).
Далее, по мере поступления новой информации о ходе выполнения проекта,
возможен пересмотр первоначальных оценок параметров проекта, с учетом
дифференциации видов транспортных средств и производственных операций.
Были
выделены следующие этапы разработки ПО для транспортной организации, более
детально проанализированные нами в основной части работы:
—
Написание предложений по созданию
ПО.
—
Планирование и составление
графика работ по созданию ПО.
—
Оценивание стоимости проекта.
—
Подбор персонала.
—
Контроль за ходом выполнения
работ.
—
Написание отчетов и
представлений.
Заключение:
В
ходе лабораторной работы мы получили основные навыки путем описания и анализа
информационной системы, а также распределили роли в группе разработчиков и
составили анализ осуществимости системы.
Установлено, что информация является решающим фактором,
который определяет развитие технологии транспортного процесса и ресурсов в
целом. Средства сбора, хранения, передачи и обработки информации относятся к
ВТП. Цель реализации информационных технологий на транспорте- это повышение
эффективности транспортного процесса на базе использования современных
компьютеров распределенной переработки информации, баз данных, различных
информационно- вычислительных сетей путем обеспечения циркуляции и переработки
информации. Информационные потребности на АТП являются структурированными, т.к.
специалистам в разных предметных областях требуется разнообразное, как по
содержанию, так и по форме информация.
Информационная система на транспорте- это, во-первых,
совокупность процессов циркуляции и переработки информации и, во-вторых,
описание этих процессов. Целью реализации информационной системы на транспорте
является повышение эффективности транспортного процесса на базе использования
современных компьютерных средств и технологий, распределенной переработки
информации, распределенных баз данных, различных информационно–вычислительных
сетей, путем обеспечения циркуляции и переработки информации. Отрабатываются
системные вопросы безопасности работы системы в многопользовательском режиме.
Создаются приложения, шаблоны, отчеты, клиентские формы доступа, распределяются
полномочия пользователей. Проводится "прогонка" всех систем в
"боевом режиме" с участием всех заинтересованных сторон. После
окончания фазы реализации проект внедрения считается законченным.
Информационная система передается в эксплуатацию.
Фрагмент текста работы:
Транспортной системе
присущи черты, свойственные любой другой производственной системе. Однако по
сравнению с другими отраслями народного хозяйства транспорт обладает
специфическими особенностями, порождаемыми характером производственного
процесса (Колесов
С.С., 2009). Производство и реализация
транспортной продукции осуществляются одновременно. Эта продукция не существует
отдельно от транспорта и не может производиться в запас. Средства производства
транспортной отрасли рассредоточены по всей стране и за её пределами, большая
часть их находится в постоянном перемещении. Все виды транспорта:
железнодорожный, морской, речной, воздушный, автомобильный и трубопроводный —
тесно связаны между собой, образуя единую транспортную систему. Она
представляет собой совокупность путей сообщения, транспортных узлов,
транспортных и погрузо-разгрузочных средств, которая обеспечивает перевозку
грузов и пассажиров из пунктов отправления в пункты назначения и выполнение
соответствующих грузовых операций. Масштабы деятельности отрасли,
рассредоточенность её объектов, динамический характер производственного
процесса, воздействие большого числа случайных факторов обусловливают
необходимость сбора, передачи, хранения информации и доведения её до
пользователя конкретных подразделений или внешних структур (В.Н. Луканин, Е.С. Кузнецов, Р.И.
Коробкова и др., 2001).
При этом подлежат
рассмотрению следующие задачи:
1. Представить организационную структуру управления
автотранспортного предприятия (АТП).
2. Рассмотреть процессы сбора, передачи, переработки,
хранения информации и доведения её до пользователя для отделов (подразделений)
внутри предприятий, занимающихся организацией работы автомобильного транспорта.
Содержание:
Программно-аппаратные средства, используемые при
выполнении работы:
Список
используемых источников и литературы
Введение:
Цель работы
Изучение методологии управления проектами. Получение навыков по
применению данных методологий для планирования проекта в транспортной отрасли.
Введение
Проблемы
управления программными проектами впервые проявилась в 60-х начале 70-х годов (Константайн Л., Локвуд Л., 2004;
Иванова Г.С., 2002). Руководители
программных проектов выполняют такую же работу, что и руководители технических
проектов (Соммервиль Иан, 2002; Якобсон А.,
Буч Г., Рамбо Дж., 2002). Вместе с тем
процесс разработки программного обеспечения (ПО) существенно
отличается от процессов реализации технических проектов, что порождает
определенные сложности в управлении программными проектами (А. М. Гудов, С. Ю. Завозкин, С. Н.
Трофимов, 2009). Основной
список отличий:
1.
Программный
продукт нематериален. Менеджер программного проекта не видит процесс “роста”
разрабатываемого ПО. Он может полагаться только на документацию, которая
фиксирует процесс разработки программного продукта.
2.
Не существует
стандартных процессов разработки ПО. Изучением процессов создания ПО
специалисты занимаются только несколько последних лет. Поэтому пока нельзя
точно предсказать, на каком этапе процесса разработки ПО могут возникнуть
проблемы, угрожающие всему программному проекту.
3.
Большие
программные проекты – это часто “одноразовые” проекты. Большие программные
проекты, как правило, значительно отличаются от проектов, реализованных ранее.
Поэтому, чтобы уменьшить неопределенность в планировании проекта, руководители
проектов должны обладать очень большим практическим опытом.
Эффективное
управление программным проектом напрямую зависит от правильного планирования
работ, необходимых для его выполнения.
«Необходимость
управления программными проектами вытекает из того "прискорбного"
факта, что процесс создания профессионального ПО всегда является субъектом
бюджетной политики организации, где оно разрабатывается, и имеет временные
ограничения. Работа руководителя программного проекта по большому счету
заключается в том, чтобы гарантировать выполнение этих бюджетных и временных
ограничений с учетом бизнес-целей организации относительно разрабатываемого
ПО.»
Написание предложений по созданию ПО. Предложения
должны содержать описание целей проектов и способов их достижения. Они также
обычно включают в себя оценки финансовых и временных затрат на выполнение
проекта. При необходимости здесь могут приводиться обоснования для передачи
проекта на выполнение сторонней организации или команде разработчиков.
План помогает
менеджеру предвидеть проблемы, которые могут возникнуть на каких-либо этапах
создания ПО, и разработать превентивные меры для их предупреждения или решения.
План, разработанный на начальном этапе проекта, рассматривается всеми его
участниками как руководящий документ, выполнение которого должно привести к
успешному завершению проекта. Этот первоначальный план должен максимально
подробно описывать все этапы реализации проекта.
Заключение:
Изучены основные элементы определения,
представления, проектирования и моделирования программных систем с помощью языка
UML. Построены диаграммы вариантов использования, классов, взаимодействия, состояний
и размещений для разрабатываемой системы. Проанализированы современные
теоретические подходы и практика применения для транспортного сектора.
Фрагмент текста работы:
Описание
Планирование и составление графика
работ по созданию ПО. На этапе планирования проекта определяются процессы,
этапы и полученные на каждом из них результаты, которые должны привести к
выполнению проекта. Реализация этого плана приведет к достижению целей
проекта. Определение стоимости проекта напрямую связано с его планированием,
поскольку здесь оцениваются ресурсы, требующиеся для выполнения плана.
Оценивание стоимости проекта.
Контроль
за ходом выполнения работ. Менеджер должен постоянно отслеживать ход реализации
проекта и сравнивать фактические и плановые показатели выполнения работ с их
стоимостью.
Подбор
персонала. Руководители — менеджеры проектов обычно обязаны сами подбирать
исполнителей для своих проектов. В идеальном случае профессиональный уровень
исполнителей должен соответствовать той работе, которую они будут выполнять в
ходе реализации проекта. Однако во многих случаях менеджеры должны полагаться
на команду разработчиков, которая далека от идеальной.
Написание
отчетов и представлений. Менеджер проекта обычно обязан посылать отчеты о ходе
его выполнения как заказчику, так и подрядным организациям. Это должны быть
краткие документы, основанные на информации, извлекаемой из подробных’ отчетов
о проекте. В этих отчетах должна быть та информация, которая позволяет четко
оценить степень готовности создаваемого программного продукта.
