Модель sadt. Основные диаграммы модели sadt.

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

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

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

• ограничение количества блоков на каждом уровне декомпозиции (правило 3-6 блоков);

• связность диаграмм (номера блоков);

• уникальность меток и наименований (отсутствие повторяющихся имен);

• синтаксические правила для графики (блоков и дуг);

• разделение входов и управлений (правило определения роли данных).

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

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

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

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

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

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

Основы IDEF3

Геннадий Верников

Предназначение IDEF3

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

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

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

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

• Содействовать принятию оптимальных решений при реорганизации технологических процессов.

• Разрабатывать имитационные модели технологических процессов, по принципу "КАК БУДЕТ, ЕСЛИ..."

Два типа диаграмм в IDEF3

Существуют два типа диаграмм в стандарте IDEF3, представляющие описание одного и того же сценария технологического процесса в разных ракурсах. Диаграммы относящиеся к первому типу называются диаграммами Описания Последовательности Этапов Процесса (Process Flow Description Diagrams, PFDD), а ко второму - диаграммами Состояния Объекта в и его Трансформаций Процессе (Object State Transition Network, OSTN). Предположим, требуется описать процесс окраски детали в производственном цеху на предприятии. С помощью диаграмм PFDD документируется последовательность и описание стадий обработки детали в рамках исследуемого технологического процесса. Диаграммы OSTN используются для иллюстрации трансформаций детали, которые происходят на каждой стадии обработки.

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

Рисунок 1. Пример PFDD диаграммы.

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

- Старшая (Precedence) - сплошная линия, связывающая UOB. Рисуется слева направо или сверху вниз.

- Отношения (Relational Link)- пунктирная линия, использующаяся для изображения связей между UOB

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

Объект, обозначенный J1 - называется перекрестком (Junction). Перекрестки используются для отображения логики взаимодействия стрелок (потоков) при слиянии и разветвлении или для отображения множества событий, которые могут или должны быть завершены перед началом следующей работы. Различают перекрестки для слияния (Fan-in Junction) и разветвления (Fan-out Junction) стрелок. Перекресток не может использоваться одновременно для слияния и для разветвления. При внесении перекрестка в диаграмму необходимо указать тип перекрестка. Классификация возможных типов перекрестков приведена в таблице.

Все перекрестки в PFDD диаграмме нумеруются, каждый номер имеет префикс "J".

Сценарий, отображаемый на диаграмме, можно описать в следующем виде:

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

Каждый функциональный блок UOB может иметь последовательность декомпозиций, и, следовательно, может быть детализирован с любой необходимой точностью. Под декомпозицией мы понимаем представление каждого UOB с помощью отдельной IDEF3 диаграммы. Например, мы можем декомпозировать UOB "Окрасить Деталь", представив его отдельным процессом и построив для него свою PFDD диаграмму. При этом эта диаграмма будет называться дочерней, по отношению к изображенной на рис. 1, а та, соответственно родительской. Номера UOB дочерних диаграмм имеют сквозную нумерацию, т.е., если родительский UOB имеет номер "1", то блоки UOB на его декомпозиции будут соответственно иметь номера "1.1", "1.2" и т.д. Применение принципа декомпозиции в IDEF3 позволяет структурировано описывать процессы с любым требуемым уровнем детализации.

Рисунок 2. Пример OSTN диаграммы

Если диаграммы PFDD технологический процесс "С точки зрения наблюдателя", то другой класс диаграмм IDEF3 OSTN позволяет рассматривать тот же самый процесс "С точки зрения объекта". На рис.2 представлено отображение процесса окраски с точки зрения OSTN диаграммы. Состояния объекта (в нашем случае детали) и Изменение состояния являются ключевыми понятиями OSTN диаграммы. Состояния объекта отображаются окружностями, а их изменения направленными линиями. Каждая линия имеет ссылку на соответствующий функциональный блок UOB, в результате которого произошло отображаемое ей изменение состояния объекта.

24. Проектирование ИС []

Основной Текст и Дополнения Милы

Архитектура - это организационная структура системы. (IEEE Std. 610.12-1990).

Архитектура - это концептуальное описание структуры системы, включающее описание элементов системы, их взаимодействия и внешних свойств (David McAfee).

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

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

Под архитектурой программных систем понимается совокупность решений относительно:

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

• выбора структурных элементов, составляющих систему и их интерфейсов;

• поведения этих элементов во взаимодействии с другими элементами;

• объединение этих элементов в подсистемы;

• архитектурного стиля, определяющего логическую и физическую организацию системы: статические и динамические элементы, их интерфейсы и способы их объединения.

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

Элементы могут быть вычислительными объектами, связанными потоком управления или бизнес-объектами, связанными семантическими ограничениями.

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

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

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

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

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

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

Есть немало примеров использования архитектуры в стратегических целях. Один из самых известных — Common Object Request Broker Architecture; эта архитектура служит для связи унаследованных систем, для интеграции систем, написанных на разных языках, и поддержки взаимодействия между компьютерами с различными аппаратными архитектурами. CORBA позволяет дать новую жизнь унаследованным системам и в то же время быстро интегрировать в них новые приложения, что обеспечивает предприятиям стратегические преимущества перед конкурентами, модифицирующими унаследованные системы.

Более свежий пример — свободно распространяемая интегрированная среда разработки Eclipse. Цель проекта Eclipse (http://www.eclipse.org) — создание свободно распространяемой платформы, которая может послужить основой для той или иной интегрированной среды разработки. Реализованная в ней архитектура призвана увеличить качество поддержки распределенной разработки и реализации разных сценариев использования платформы. Подобные сценарии, расширяющие основную функциональность, добавляются к Eclipse посредством определения и реализации подключаемых модулей. Такой модуль представляет собой пакет, который объединяет в себе код, реализующий добавляемую в Eclipse функциональность, и декларацию на языке XML, содержащую информацию о конфигурации. Декларация описывает расширения к меню, функциональность, необходимую для корректной работы подключаемого модуля, и новые окна, которые будут частью представления Eclipse.

Стратегическое использование программной архитектуры

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

Стратегическое планирование

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

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

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

Корпоративная архитектура

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

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

Эталонные архитектуры

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

Главное, на что следует обратить внимание при выборе архитектуры, — ее готовность и

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

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

Архитектура ПО обычно содержит несколько видов, которые аналогичны различным типам чертежей в строительстве зданий. В онтологии, установленной ANSI / IEEE 1471-2000, виды являются экземплярами точки зрения, где точка зрения существует для описания архитектуры с точки зрения заданного множества заинтересованных лиц.

Примеры видов:

* Функциональный/логический вид

* Вид код/модуль

* Вид разработки (development)/структурный

* Вид параллельности выполнения/процесс/поток

* Физический вид/вид развертывания

* Вид с точки зрения действий пользователя

* Вид с точки зрения данных

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

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

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

* Blackboard

* Клиент-серверная модель (client-server)

* Архитектуры, построенные вокруг базы данных (database-centric architecture)

* Распределенные вычисления (distributed computing)

* Событийная архитектура (event-driven architecture)

* Front end and back end

* Неявные вызовы (implicit invocations)

* Монолитное приложение (monolithic application)

* Peer-to-peer

* Пайпы и фильтры (pipes and filters)

* Plugin

* Representational State Transfer

* Rule evaluation

* Поиск-ориентированная архитектуры

* Сервис-ориентированная архитектура

* Shared nothing architecture

* Software componentry

* Space based architecture

* Структурированная

* Трехуровневая

Дополнение Дениса

ADD-метод

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

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

• Выберите элемент системы к дизайну.

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

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

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

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

• Повторите деятельность пока все драйверы не будут удовлетворены. 

Ответ прошлых лет (Ден)

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

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

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

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

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

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

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

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

25. Проектирование ИС []

Готовый ответ Милы

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

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

Процесс управления конфигурацией включает:

• идентификацию конфигурации;

• контроль конфигурации;

• учёт состояния конфигурации;

• оценку конфигурации;

• управление выпуском и поставку.

При создании проектов сложных ИС, состоящих из многих компонентов, каждый из которых может иметь разновидности или версии, возникает проблема учёта их связей и функций, создания унифицированной структуры и обеспечения развития всей системы. Управление конфигурацией позволяет организовать, систематически учитывать и контролировать внесение изменений в ПО на всех стадиях ЖЦ. Общие принципы и рекомендации конфигурационного учёта, планирования и управления конфигурациями ПО отражены в проекте стандарта ISO/IEC 12207.

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

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

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

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

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

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

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

В плане управления конфигурацией в компании следует:

• установить и поддерживать базовые конфигурации;

• иметь опись (карту) ИС, актуализируемую с учетом жизненного цикла, в которую входят аппаратура, программное обеспечение и документация;

• установить и обеспечить практическое применение настроек для конфигурирования средств безопасности в продуктах, входящих в ИС.

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

Управление конфигурацией: контроль изменений конфигурации. Документируются и контролируются изменения в информационной системе; соответствующие должностные лица санкционируют изменения ИС в соответствии с принятыми в организации политикой и процедурами.

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

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

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

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

Цели:

* контроль вносимых изменений;

* улучшение качества продукта или услуги;

* повышение степени удовлетворенности пользователей и/или заказчиков;

* организация взаимодействия различных рабочих групп. Действия:

* создание или обновление рабочего пространства по заданному профилю;

* внесение изменений в файлы проекта;

* интеграция изменений с изменениями, внесенными другими участниками;

* фиксирование базовой линии текущих версий файлов проекта;

* регистрация запросов;

* назначение исполнителей и сроков;

* контроль исполнения (периодический контроль).

Важные составляющие процессов:

* автоматизированная процедура сборки версии программного средства;

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

* возможность количественной и качествен ной оценки проделанной разработчиками работы;

* совместный доступ к информации о запросах на изменения.

Эффект от внедрения на уровне руководства

Рассмотрим основные преимущества внедрения этих дисциплин с точки зрения руководства:

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

2. Четкое представление о том, кто и чем занимается в проекте, сколько ошибок исправлено, сколько ошибок найдено и т.д.

3. Полное документирование всех ключевых изменений.

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

5. Графическое представление метрик проекта, формируемых при определении процесса (типы, количество и т.д.).

6. Формирование статистических отчетов по проекту (часто называемых срезами). Сформированные метрики проекта ранжируются в зависимости от уровня руководства: руководитель департамента, начальник отдела, менеджер проекта и т.д.

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

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

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

Ответ прошлых лет (Ден)

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

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

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

• Идентификация конфигурации - Процесс идентификации конфигураций требует выполнения следующих шагов:

  • Определение объектов конфигурации

  • Выбор схемы наименования объектов конфигурации

  • Определение утверждаемых схем

  • Определение внутренних схем

• Управление конфигурациями – Управление конфигурациями непосредственно взаимодействует с процессом управления изменений. Первоначально этот шаг обеспечивает информацией управление изменениями о влиянии предлагаемого изменения. Когда (и если) это изменение принимается, процесс управления конфигурациями гарантирует, что объекты конфигурации, на которые влияет данное изменение, будут пересмотрены, для чего он подготовит соответствующие идентификационные номера, а затем будет модифицирована и схема, на которую изменение оказало влияние. Таким образом, управление конфигурациями обрабатывает объекты конфигурации и контролирует редакции и схемы. Эти два шага обсуждаются более детально в следующих подразделах. Еще более детальную информацию можно найти в Digital Program Methodology Technique: Change Control. Процесс обработки изменений управляется Подразделением Контроля за Конфигурациями.

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

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

Очень подробно об этом на http://k98-224.narod.ru/conf_man.htm

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

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

Ответ прошлых лет (Мадина)

Управление конфигурациями

26. Проектирование ИС []

Готовый ответ Милы

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

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

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

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

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

Основные концепции управления персоналом, которые присущи условия рыночной экономики:

• концепция управления персоналом по результатам (Management by results);

• концепция управления песроналом на основе интеграции и контроля (Management by integration and self-control);

• концепция делегирования полномочий (Management by delegation);

• концепция вмешательства в исключительных случаях (Management by exception);

• концепция через постановку целей (Management by objectives);

• концепция управления персоналом посредством информационной системы (Management by system).

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

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

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

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

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

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

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

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

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

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

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

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

Еще одна особенность - обеспечение лояльности персонала как к самому проекту, так и к компании в целом.

Успех проекта значительно зависит от скорости принятия управленческих решений в команде. Чтобы быстро и своевременно оповещать о данных решениях всех заинтересованных сотрудников, необходимо осуществить распределение ролей в рамках проекта. Если все каналы связи и взаимодействия замкнутся на руководителе, вероятность того, что произойдет потеря информации, составляет 95%. Поэтому следует создать внутригрупповые, "горизонтальные" каналы коммуникации.

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

Руководитель - контролер "правильного" использования ресурсов проекта.

Достаточно частая и позитивная роль руководителя - "координатор" всех действий участников проекта для достижения результата.

Имеет смысл отнестись к подбору команды как к самостоятельному проекту со всеми его традиционными этапами.

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

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

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

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

Основу концепции управления персоналом проекта составляют следующие компоненты:

• возрастающая роль личности работника;

• знание его мотивационных установок;

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

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

• определение общей стратегии формирования команды проекта;

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

• привлечение, отбор и оценка персонала;

• повышение квалификации и переподготовка персонала команды проекта;

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

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

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

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

1) соответствие персонала целям и миссии проекта (уровень образования, квалификация, понимание миссии, отношение к работе);

2) эффективность системы работы с персоналом — соотношение затрат и результатов, потребность в инвестициях, выбор критериев оценки результатов работы с персоналом;

3) избыточность или недостаточность персонала, расчет потребности, планирование количества и качества;

4) сбалансированность персонала по определенным группам профессиональной деятельности и социально-психологических характеристик;

5) структура интересов и ценностей, превалирующих в группах персонала управления, их влияние на отношение к труду и его результаты;

6) ритмичность и напряженность деятельности, определяющие психологическое состояние и качество работы;

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

Особенности поведения персонала:

Стратегия формирования команды проекта

Часто успех проекта напрямую зависит от взаимоотношений, сложившихся между его участниками.

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

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

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

1. Планирование системы коммуникаций - определение информационных потребностей участников проекта (состав информации, сроки и способы доставки).

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

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

4. Документирование хода работ - сбор, обработка и организация хранения документации по проекту.

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

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

2. Доступностью технологий.

3. Квалификацией и подготовленностью кадров.

Как наладить общение между участниками проекта:

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

• Уменьшайте сообщения, выражайтесь как можно проще.

• Постройте сообщение как последовательность простых частей.

Ответ прошлых лет (Ден)

Управление персоналом (англ. Human Resource Management, HRM) – область знаний и практической деятельности, направленная на обеспечение организации «качественным» персоналом и оптимальное его использование. Оптимальное использование персонала с точки зрения «управления персоналом» достигается за счёт выявления положительных и отрицательных мотивов индивидуумов и групп в организации и соответствующего стимулирования положительных мотивов и «погашения» отрицательных мотивов, а также анализа таковых воздействий. Управление персоналом является неотъемлемой частью качественных систем управления (менеджмента) в концепции контроллинга.

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

• Предварительные работы по поиску персонала:

  • Поиск персонала

  • Предварительная оценка персонала

  • Подбор и отбор персонала

• Оперативную работу с персоналом:

  • Оперативная оценка персонала

  • Обучение и развитие персонала

  • Управление бизнес-коммуникациями

  • Мотивацию персонала

  • Организацию труда

• Стратегическую (только долгосрочную) работу с персоналом:

  • Управление корпоративной культурой.

К основным методам управления персоналом относят:

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

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

Социально-психологические методы (мотивация, моральное поощрение, социальное планирование и т. п.).

Коммуникации в проекте

Содержание плана управления коммуникациями

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

• требования к коммуникациям со стороны участников проекта;

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

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

• имя сотрудника или группы - получателей данной информации;

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

• частоту коммуникации (например, еженедельно);

• процедуры согласования документов;

• схему эскалации проблем;

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

• глоссарий общепринятой терминологии.

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

27. Проектирование ИС []

Готовый ответ Тони

ГОСТ 12207-99 «Информационная технология ПРОЦЕССЫ ЖИЗНЕННОГО ЦИКЛА ПРОГРАММНЫХ СРЕДСТВ» устанавливает, используя четко определенную терминологию, общую структуру процессов жизненного цикла программных средств, на которую можно ориентироваться в программной индустрии. Настоящий стандарт определяет процессы, работы и задачи, которые используются: при приобретении системы, содержащей программные средства, или отдельно поставляемого программного продукта; при оказании программной услуги, а также при поставке, разработке, эксплуатации и сопровождении программных продуктов. Понятие программных средств также охватывает программный компонент программно-аппаратных средств.

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

ГОСТ Р 15271-2002 содержит рекомендации по применению ГОСТ 12207-99. В стандарте особое внимание уделено особенностям, подлежащим учету при прикладном применении ГОСТ Р 12207 в условиях реальных проектов создания программных средств.

Управление процессом создания

Уровни управления: руководитель организации и его заместитель, планово-производственный отдел, руководители функциональных подразделений, руководители проектов, главные конструкторы, ответственные исполнители- руководители групп.

Функции процесса управления: прогнозирование, планирование...

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

Состав малых предприятий по созданию и.с.: руководитель (менеджер)- который занимается портфелем заказов, системный аналитик, поставщики, главный программист, системный программист, прикладные программисты, текстовик, дизайнер, тот, кто внедряет.

Этапы управления:

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

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

Процессы жизненного цикла

Основные процессы жизненного цикла

В настоящем разделе определены следующие основные процессы жизненного цикла:

1) процесс заказа;

2) процесс поставки;

3) процесс разработки;

4) процесс эксплуатации;

5) процесс сопровождения.

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

Вспомогательные процессы жизненного цикла

В данном разделе определены следующие вспомогательные процессы жизненного цикла:

1) процесс документирования;

2) процесс управления конфигурацией;

3) процесс обеспечения качества;

4) процесс верификации;

5) процесс аттестации;

6) процесс совместного анализа;

7) процесс аудита;

8) процесс решения проблем.

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

Организационные процессы жизненного цикла

1. Управление

2. Создание инфраструктуры

3. Усовершенствование

4. Обучение

Ответ прошлых лет (Ден)

Уровни управления: руководитель организации и его заместитель, планово-производственный отдел, руководители функциональных подразделений, руководители проектов, главные конструкторы, ответственные исполнители- руководители групп.

Функции процесса управления: прогнозирование, планирование...

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

Состав малых предприятий по созданию и.с.: руководитель (менеджер)- который занимается портфелем заказов, системный аналитик, поставщики, главный программист, системный программист, прикладные программисты, текстовик, дизайнер, тот, кто внедряет.

Этапы управления:

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

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

Основные процессы ЖЦ по ГОСТ’ам

Заказ – Acqusition

Поставка – Supply

Разработка – Development

Эксплуатация – Operation

Сопровождение – Maintenance

Инфраструктура проекта ???

28. Проектная документация []

Готовый ответ Дины

ГОСТ 51904-2002

12.1 – 12.8. – основное. Плюс Разделы 6.3, Таблица А1.

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

Цели:

1. Определить конкретные модели виды работ

2. Определить модели жизненного цикла (ЖЦ) ПО

3. Выбрать среду поддержки ЖЦ

4. Определить стандарты разработки

5. Разработать документы процесса планирования

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

Типы планов (док-ты) и разделы, которые они должны в себя включать

• П.сертификации в части ПО

• обзор системы,

• обзор ПО,

• вопросы сертификации,

• ЖЦ ПО (модель),

• документы ЖЦ ПО (которые нужно будет разработать),

• план-график,

• доп.вопросы

• П. разработки ПО

• идентификация стандартов на разработку,

• описание процессов ЖЦ ПО,

• обоснование среды разработки

• П. верификации ПО

• орг.ответственность внутри процесса верификации,

• методы верификации,

• среда верификации - оборудование для тестирования,

• критерии перехода к процессу верификации,

• проверка разбиения на части,

• допустимость использования компилятора,

• руководство по повторной верификации,

• ранее разработанное ПО,

• версионное ПО

• П. квалификационного тестирования ПО

• Идентификация – перечень и используемы версии ПО

• Идентификация – перечень и используемы виды аппаратных средств

• Права собственности и лицензирование

• Задействованные организации

• П. упр-я конфигурацией ПО

• Среда

• Состав работ

• Идентификация конфигурации

• Базовая линия и трассируемость (??!)

• Отчетность о дефектах

• Контроль изменений

• Просмотр изменений

• Отчет о состоянии конфигурации

• Архивирование

• Контроль загрузки ПО

• Конторль среды ЖЦ ПО

• Контроль док-в ЖЦ ПО

• Критерии перехода

• Док-ты упр-я конфигурациями

• Контроль поставщика

• П. обеспечения качества ПО

• Среда

• Полномочия

• Состав работ (методы, сами работы и их описание)

• П. установки ПО

• Перечень пользовательских мест

• Запланированные сроки

• Методы установки

• Орг.сведения

• Технические средства поддержки

• Орг-ция процесса обучения

• П. передачи ПО

• Краткий обзор док-в и системы

• Описание ресурсов, необходимых для поддержки

• Рекомендуемые мероприятия

• Описание процесса подготовки персонала

• Област изменений передаваемого ПО

• Порядок передачи ПО

29. Проектная документация []

Готовый ответ Ани

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

Примечание: ЭКПО – элемент конфигурации ПО

30. Проектная документация []

Ответ Тони

Гост Р 51904-2002

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

Минимальный состав документов жизненного цикла ПО, передаваемых сертифицирующей организации на утверждение:

• План сертификации в части ПО;

• Указатель конфигурации ПО;

• Итоговый документ разработки ПО.

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

• Спецификация требований к ПО;

• Описание проекта ПО;

• Исходный код ПО;

• Исполняемый объектный код ПО;

• Указатель конфигурации ПО;

• Итоговый документ разработки ПО.

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

Характеристики документов ЖЦ По являются:

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

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

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

-согласованность, если не существует противоречий внутри информации.

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

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

Дополнительные требования:

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

Проектирование системы

Документ «Описание проекта системы/подсистемы»

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

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

- проект архитектуры системы, содержащий идентификацию компонентов системы, их назначение, статус/тип разработки, аппаратные ресурсы;

- компетенцию совместного функционирования компонентов, описание их динамических связей;

- описание интерфейсов между компонентами;

- анализ трассируемости проекта системы к системным требованиям.

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

Процесс кодирования

Документ Исходный код По

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

Документ Исполняемый программный код

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

31. Проектная документация []

Готовый ответ Лены

КУСОК ИЗ ГОСТА СВЕРХУ

• План верификации ПО

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

а) Организация: организационная ответственность внутри процесса верификации ПО и ин­терфейсы с другими процессами жизненного цикла ПО.

б) Независимость: описание методов для обеспечения независимости верификации, когда это требуется.

в) Методы верификации: описание методов верификации, которые будут использованы на каждом этапе процесса верификации ПО:

1. методы просмотра, включающие в себя контрольные листы и другие средства поддержки;

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

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

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

д) Критерии перехода: критерии перехода к процессу верификации ПО, определяемому в этом плане.

е) Проверка разбиения: если используют разбиение на части, то описывают метод верифика­ции целостности.

ж) Допустимость использования компилятора: описание соглашений относительно коррект­ности применения компилятора, редактора связей или загрузчика (6.4.2).

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

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

к) Многоверсионное ПО: при использовании многоверсионного ПО необходимо описание работ процесса верификации для него.

• План квалификационного тестирования ПО

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

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

• идентификация, перечень и используемые версии ПО, для которых будет выполнено тестирование на данной установке, их назначение;

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

• права собственности и лицензирование;

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

Кроме того, в данном документе должны быть представлены план-график тестирования и матрица трассирования тестов к требованиям к ПО.

Допускается включение перечисленной в настоящем подразделе информации в документ «План верификации ПО>> (см. 12.3), если заказчик не требует разработки отдельного документа, описывающего план квалификационного тестирования.

• Спецификация системы/подсистемы

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

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

Должны быть описаны требования:

• к режимам работы;

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

• к внешнему интерфейсу системы;

• к внутреннему интерфейсу системы;

• к внутренним данным системы;

• по адаптации;

• по безопасности;

• по обеспечению защиты и секретности;

• к системному окружению (среде);

• к ресурсам вычислителя (к аппаратуре, коэффициенту использования ресурсов аппаратуры, ПО вычислителя, организации сети компьютеров, если она необходима);

• по ограничениям проекта;

• по обучению персонала.

Должны быть также определены:

• относительная важность и критичность требований;

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