Ответы_к_госам_final

Диаграмма обзора взаимодействия (Interaction overview diagram) —

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

Этот тип диаграмм включает в себя диаграммы Sequence diagram (диаграммы последовательностей действий) и Collaboration diagram (диаграммы сотрудничества). Эти диаграммы позволяют с разных точек зрения рассмотреть взаимодействие объектов в создаваемой системе.

Диаграмма синхронизации (Timing diagram) — альтернативное

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

Язык моделирования и документирования сложных систем

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

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

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

Несмотря на то, что UML достаточно широко распространѐнный и используемый стандарт, его часто критикуют из-за следующих недостатков:

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

иконструкций. Чаще это можно услышать в отношении UML 2.0, чем UML 1.0, так как более новые ревизии включают больше «разработанных-комитетом» компромиссов.

Неточная семантика. Так как UML определѐн комбинацией себя (абстрактный

синтаксис), OCL (языком описания ограничений — формальной проверки правильности) и Английского (подробная семантика), то он лишен скованности присущей языкам, точно определѐнным техниками формального описания. В некоторых случаях абстрактный синтаксис UML, OCL и Английский противоречат друг другу, в других случаях они неполные. Неточность описания самого UML одинаково отражается на пользователях и поставщиках инструментов, приводя к несовместимости инструментов из-за уникального трактования спецификаций.

 Проблемы при изучении и внедрении. Вышеописанные проблемы делают проблематичным изучение и внедрение UML, особенно когда руководство насильно

заставляет использовать UML инженеров при отсутствии у них предварительных навыков.[1]

Только код отражает код. Ещѐ одно мнение — что важны рабочие системы, а не

красивые модели. Как лаконично выразился Джек Ривс, «The code is the design» («Код и есть проект»).[2][3] В соответствии с этим мнением, существует потребность в лучшем способе написания ПО; UML ценится при подходах, которые компилируют моделидля генерирования исходного или выполнимого кода. Однако этого всѐ же может быть

сформулирован, и который сам является объектом критики.

Управление проектами

Управление проектом

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

Участники проекта

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

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

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

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

4. процессы анализа - определение соответствия плана и исполнения проекта поставленным целям и критериям успеха и принятие решений о необходимости применения корректирующих воздействий;

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

6. процессы завершения - формализация выполнения проекта и подведение его к упорядоченному финалу.

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

Контроль выполнения проекта.

Измерение и оценка хода выполнения проекта делают необходимым процесс контроля, состоящий из четырех этапов:

1.Разработка основного плана.

2.Измерение хода работы.

3.Сравнение плана и фактических результатов.

4.Принятие мер.

Этап 1: разработка основного плана

Основной план дает нам элементы измерения хода работ.

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

Этап 2: измерение хода работы

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

Этап 3: сравнение плана с фактом

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

Обычно отчеты о статусе заслушиваются каждые 1-4 недели, в этом случае они

эффективны и позволяют исправлять отклонения.

Этап 4: принятие мер

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

Команда проекта

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

Это более узкое понятие, чем участники проекта. Основными характеристиками команды являются:

состав;

структура;

групповые процессы.

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

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

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

Управление целями проекта

Цель проекта— важнейший элемент управления проектом, от которого в итоге во многом зависит успешность проекта.

Цели проекта должны соответствовать SMART(Specific;— Специализированные,

Mesurable— Измеримые, Actively Influencible Актуальные, Realistic— Реалистичные, Time LimitedОграниченные по времени).

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

Управление временем проекта.

определение состава работ – идентификация и документальное оформление отдельных работ, определенных в ИСП\ИСР (в ИСП декомпозиция производится до пакетов работ (80 час), здесь – до отдельных работ)

определение последовательности работ – определение и документирование зависимостей между работами

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

разработка расписания – определение даты начала и даты конца каждой работы

– основной процесс управления временем

контроль расписания

Управление ресурсами проекта

Типовые примеры ресурсов:

Трудовые ресурсы

Машины, оборудование

Материалы

Денежные средства

Энергетические ресурсы

Информационные ресурсы

Вычислительная и орг.техника

Производственные площади

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

Ресурсы могут быть:

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

не возобновляемыми (расходуемыми) – материалы и оборудование, которые на операциях расходуются.

Для удобства возобновляемые ресурсы называют просто ресурсами, а расходуемые – материалами.

ПО для управления проектами

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

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

Планирование

Расчѐт критического пути

Управление данными и предоставление информации Типы программного обеспечения для управления проектами

Desktop (Десктопные)

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

Cerebro - многопользовательское ПО для управление медиа проектами

GanttProject

KPlato - приложение для управления проектами под ОС Linux

Microsoft Project

OpenProj

Open Workbench

TaskJuggler

Web-based (Веб-приложения)

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

спомощью браузера. Следующие приложения являются примерами веб-приложений:

Basecampэто онлайн-инструмент для управления проектами

TeamLabплатформа для организации совместной работы и общения

Мегаплан - система управления проектами

Kommandcore - веб-сервис для командного управления проектами

LifeTask.ru - система управления проектами.

ActiveCollab

Bontq

S10: Система управления бизнесом

www.conject.com - он-лайн платформа для взаимодейтсвия в строительных проектах

Персональные

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

Однопользовательские

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

Многопользовательские

Предназначены для координации действий нескольких десятков или сотен пользователей. Обычно строятся по технологии клиент-сервер. К многопользовательским системам относятся:

FogBugz

OpenProj

ProjectMate

Redmine

Trac

LifeTask

Интегрированные

Управление проектами в MS Project

Средства поддержки процесса проектирования

Техническое предложение

Техническое предложение — совокупность конструкторских документов, которые должны содержать уточненные технические и технико-экономические обоснования целесообразности разработки документации изделия на основании:

анализа технического задания заказчика и различных вариантов возможных конструктивных решений;

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

Техническое задание

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

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

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

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

Как инструмент коммуникации в связке общения заказчик-исполнитель, техническое задание позволяет:

обеим сторонам

представить (вообразить) готовый продукт

выполнить попунктную проверку готового продукта (приѐмочное тестирование

— проведение испытаний)

уменьшить число ошибок, связанных с изменением требований в результате их

неполноты или ошибочности (на всех стадиях и этапах создания, за исключением испытаний)

заказчику

осознать, что именно ему нужно

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

требовать от исполнителя соответствия продукта всем условиям, оговорѐнным

в ТЗ

исполнителю

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

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

отказаться от выполнения работ, не указанных в ТЗ

ГОСТ 19.201-78 Единая система программной документации. Техническое задание. Требования к содержанию и оформлению ГОСТ 34.602-89 Информационная технология. Комплекс стандартов на

автоматизированные системы. Техническое задание на создание автоматизированной системы

Средства документирования проекта

Система управления версиями (от англ. Version Control System, VCS или Revision Control

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

Такие системы наиболее широко применяются при разработке программного обеспечения, для хранения исходных кодов разрабатываемой программы. Однако, они могут с успехом применяться и в других областях, в которых ведѐтся работа с большим количеством непрерывно изменяющихся электронных документов, в частности, они применяются в САПР, обычно, в составе систем управления данными об изделии (PDM).

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

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

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

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

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

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

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

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

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

Также известны как англ. Distributed Version Control System, DVCS. Такие системы используют распределѐнную модель вместо традиционной клиент-серверной. Они, в общем случае, не нуждаются в централизованном хранилище: вся история изменения документов хранится на каждом компьютере, в локальном хранилище, и при необходимости отдельные фрагменты истории локального хранилища синхронизируются с аналогичным хранилищем на другом компьютере. В некоторых таких системах локальное хранилище располагается непосредственно в каталогах рабочей копии.

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