Методологии проектирования. Типовое проектирование

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

Типовое проектное решение (ТПР) – тиражируемое (пригодное к многократному использованию) проектное решение.

Класс ТПР / Реализация ТПР	Достоинства	Недостатки
Элементные ТПР Т иповые решения по задаче или отдельному виду обеспечения задачи (инф-ному, программному, т ех., матем., организационному) Библиотеки методо-ориентированных программ	● обеспечивается применение модульного подхода к проектированию и документированию ИС	● большие затраты времени на сопряжение разнородных элементов вследствие информационной, программной и технической несовместимости ● большие затраты времени на доработкуТПР отдельных элементов
Подсистемные ТПР Элемент типизации – отдельные подсистемы, разработанные с учетом функциональной полноты и минимизации внешних информационных связей Пакеты прикладных программ (ППП)	● достигается высокая степень интеграции элементов ИС ● позволяют осуществлять: модульное проектирование; параметрич. настройку программных компонентов на различные объекты управления ● обеспечивают: сокращение затрат на проектирование и программирование взаимосвязанных компонентов; хорошее документирование отображаемых процессов обработки инф-ии	● адаптивность ТПР недостаточна с позиции непрерывного инжиниринга деловых процессов ● возникают проблемы в комплексировании разных функциональных подсистем, особенно в случае использования решений нескольких производителей программного обеспечения
Объектные ТПР Типовые отраслевые проекты, включают полный набор функциональных и обеспечивающих подсистем ИС.	● комплексирование всех компонентов ИС за счет методологического единства и информационной, программной и технической совместимости ● открытость архитектуры – позволяет устанавливатьТПР на разных программно-технических платформах ● масштабируемость — допускает конфигурацию ИС для переменного числа рабочих мест ● конфигурируемость – выбор необходимого подмножества компонентов	● проблемы привязки типового проекта к конкретному объекту управления, что вызывает в некоторых случаях даже необходимость изменения организационно-экономической структуры объекта автоматизации

5. Процессы жизненного цикла информационной системы. ГОСТ 12 207.

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

1) Процесс заказа (работа заказчика).

2) Процесс поставки (работа поставщика).

3) Процесс разработки (работа разработчика).

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

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

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

1) Процесс документирования (описание информации, выдаваемой в процессе ЖЦ).

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

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

4) Процесс верификации.

5) Процесс аттестации.

6) Процесс совместного анализа (оценка состояния и результатов какой-либо работы).

7) Процесс аудита (определение соответствия требованиям, планам и договору).

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

Организационные процессы ЖЦ применяются для создания и реализации основной структуры, охватывающей взаимосвязанные процессы ЖЦ и соответствующий персонал, а также для постоянного совершенствования данной структуры и процессов. Как правило, типовые процессы.

1) Процесс управления (управление проектом при реализации процессов ЖЦ).

2) Процесс создания инфраструктуры (создание основной структуры процесса ЖЦ).

3) Процесс усовершенствования.

4) Процесс обучения персонала.

6. Процессы жизненного цикла информационной системы. Процессы планирования.

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

Планирование позволяет:

- эффективнее использовать ресурсы информационной системы;

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

- быть уверенным в том, что ИС будет соответствовать общему направлению развития организации;

- учесть мнение конечных пользователей;

- создавать условия для правильного реагирования на непредвиденные ситуации.

Цели процесса планирования ПО:

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

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

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

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

В процессе планирования ПО должны быть выполнены следующие работы:

- разработка планов создания ПО и передача их исполнителям;

- определение и выбор стандартов разработки ПО;

- необходимо скоординировать планы разработки ПО и планы интегральных процессов, чтобы получить согласованные стратегии выполнения различных процессов ЖЦ;

- определение процедуры пересмотра и уточнение планов по мере развития проекта;

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

В процессе планирования ПО должны быть разработаны следующие планы:

- План разработки ПО (используемые модели ЖЦ ПО и среду разработки ПО);

- План верификации ПО (средства, с помощью которых будут удовлетворены цели процесса верификации ПО);

- План квалификационного тестирования ПО (порядок его выполнения);

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

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

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

- План передачи ПО (аппаратное и ПО, а также другие ресурсы, необходимые для поддержки ЖЦ передаваемого ПО).

Планы ПО должны указывать:

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

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

- необходимые инструментальные средства, методов, стандартов и процедур.

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

7. Процессы ЖЦ ИС. Процессы определения требований к ИС.

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

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

Анализ требований включает три типа деятельности:

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

- Анализ требований: определение, являются ли собранные требования неясными, неполными, неоднозначными (противоречащими) и затем решение этих проблем.

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

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

Цели процесса определения требований к ПО:

- разработать требования верхнего уровня;

- оценить производные требования верхнего уровня с т.з. безопасности системы.

Входные данные: системные требования, описания аппаратного интерфейса и архитектуры системы, определяемые процессами ЖЦ системы, План разработки ПО и стандарты на разработку требований к ПО, определяемые процессом планирования. Входные данные используют для разработки требований верхнего уровня к ПО. Требования верхнего уровня: функциональные требования, требования к эффективности, требования к интерфейсу и требования, связанные с безопасностью. Выход: документы «Спецификация требований к ПО» и «Спецификация требований к интерфейсу». Определение требований к ПО считают завершенным, когда достигнуты его цели и цели связанных с ним интегральных процессов.

Процесс определения требований к ПО должен обеспечить следующее:

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

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

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

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

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

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