|
| aa1 |
| aa2 |
| aa3 |
МИСПР
1.1. СОД КАК ОБЪЕКТ ПРОЕКТИРОВАНИЯ.
СОД как сложная система обладает следующими особенностями: 1. сложность системы; 2. делимость системы; 3. целостность системы – подчинено единой цели; 4. многообразие элементов системы; 5. структурированность. Современные СОД можно характеризовать: - сложность описания; - отсутствие прямых аналогов; - необходимость интеграции существующих и вновь разработанных приложений; - функционирование в неоднородной среде на нескольких аппаратных платфор-мах; - разобщённость и разнородность отдельных групп разработчиков по уровню ква-лификации и использованию инструментальных средств; - существующая временная протяжённость проектов.
1.2. ЦЕЛИ АВТОМАТИЗАЦИИ И ПОДХОДЫ К РЕАЛИЗАЦИИ СОД.
В качестве цели на автоматизацию можно использовать: 1. сокращение трудозатрат на выполнение типовых информационных процессов в заданной предметной области; 2. сокращение численности управляющего персонала; 3. внедрение новых информационных технологий; 4. создание и дальнейшее совершенствование автоматизированных информаци-онных систем. Цель автоматизации определяет широту охвата конкретного объекта. Существу-ют следующие основные подходы к реализации СОД: 1. создание новой СОД; 2. модернизация существующей СОД; 3. внедрение готовой СОД.
1.3. ПЕРДПРИЯТИЕ КАК ОБЪЕКТ АВТОМАТИЗАЦИИ.
Предприятие как объект автоматизации имеет ряд характери¬стик: - отраслевая принадлежность; - тип и характер производства; - технологические процессы производства продукции, работ и услуг; - организационная структура управления; - методы управления; - производственные ресурсы предприятия. Объект для автоматизации (пред¬приятие или его фрагмент) будем рассматри-вать как сис¬тему организацион¬ного типа, в состав которой входят следующие ос-новные составляющие: 1. Целевое назначение объекта – это одна или несколько целей, которые реали-зуются объек¬том в процессе его функционирования. 2. Организационная структура – это структурная организация ОА. Составными элемен¬тами структуры могут быть подраз¬деления ОА (отделы, службы и т.д.) между кото¬рыми существуют определенные инфор¬мационные, управ¬ляющие и матери¬альные связи. В свою очередь отдельное подразде¬ле¬ние может иметь свою структурную организацию. 3. Функциональная структура представляет собой перечень функций, за¬дач и т.д., которые реализуются объектом в це¬лом или компонентами струк¬туры в процессе его функционирования. Функции ОА необ¬ходимо рассматривать во взаимосвязи с его структур¬ной организацией. 4. Информационная система – это совокупность ручных и автомати¬зирован¬ных информацион¬ных технологий (ИТ) применяемых для организа¬ции, сбора, регист-рации, пере¬дачи, обработки, накоп¬ления, хранения, отображения и документиро-вания информации в процессе функционирова¬ния ОА, а также персонала, осуще-ствляющего эти действия. Основными источниками данных для обследования ОА (предприятия) явля¬ются: плановые и отчетные документы по ОА; результаты проводив¬шихся ра¬бот по изучению и совершенствованию про¬цесса функционирования ОА; суще¬ствующие должностные инст¬рукции, положения о подразделениях; нор¬мативно-справочные материалы и т.д.
1.4. НАЗНАЧЕНИЕ, СТРУКТУРА И СОСТАВ СОД.
Под-сис-тема №1 i-я под-ма N-я под-ма Обеспечить компоненты ПО ИО ТО ОО АО ПраО МеО МО Эр-гО Подсистемы СОД В подсистемы СОД входят следующие функциональные компоненты: - стратегическое управление; - управление кадрами; - оперативное управление; - БУ; - управление производством. СОД – это программное изделие, пригодное для использования на ЭВМ, прошед-шее испытания с зафиксированными показателями качества и снабженное ком-плектом документации, достаточной для квалифицированной эксплуатации по на-значению и использованию. СОД – это системы, которые обладают всеми свойст-вами сложных систем.
1.5. ПРИНЦИПЫ ПОСТРОЕНИЯ СОД.
Основополагающие принципы: - системности - развития - совместимости - стандартизации - унификации - эффективности Частные принципы: - принцип декомпозиции - первого руководителя - принцип новых задач - принцип автоматизации информационных потоков - принцип автоматизации проектирования Организационно-технологические принципы: - абстрагирования - формализации - концептуальной целостности - непротиворечивости и полноты - независимости данных - структурирования данных - доступа конечного пользователя
1.6 . КЛАССИФИКАЦИЯ И ОСНОВЫ АРХИТЕКТУРЫ СОД.
Классификация: Виды процессов управления: - АС управления технологическими процессами; - АС управления организационно-технологическими процессами; - АС организационного типа; - АС научных исследований; - обучающие и другие АС. Сфера функционирования объекта: - АС промышленности; -АС с\х; - АС транспорта; - АС связи и т.д. Уровень в системе гос управления: - отдельное предприятие; - объединение предприятий; - отраслевые АС; - территориальные АС; - межотраслевые АС. Виды архитектур: 1. централизованная обработка данных; 2. архитектура «файл-сервер»; 3. двухуровневый «клиент-сервер»; 4. многоуровневый «клиент-сервер».
1.7. ИНТЕГРИРОВАННАЯ АСУ КАК ПРИМЕР СЛОЖНОЙ СОД.
Уровни управле-ния Виды взаи-модей-ствую-щих АС Средства обеспе-чения взаимо-действ. АС в со-ставе ИАСУ Объ-еди-не-ние АСУО ТО ПО ИО Предпри-ятие АСНИ САПР АСУП Цех, уча-сток АСУТП АСУГПС
1.8. КЛАССИФИКАЦИЯ ТЕХНОЛОГИЧЕСКИХ ПОДХОДОВ.
Технологические подходы можно классифицировать следующим образом: 1. подходы со слабой формализацией. Эти подходы не используют явных техно-логий и их можно применять для очень маленьких проектов. К этим подходам от-носятся ранние технологические подходы (кодирование и исправление); 2. строгие (классические, жёсткие, предсказуемые) подходы. Данная группа под-ходов рекомендуется применять для средних крупномасштабных проектов с фик-сированным объёмом работ. Одно из основных требований к этим подходам предсказуемость. В эту группу входят: - каскадные технологические подходы (классический каскадный подход, каскад-но-возвратный подход, каскадно-итерационный подход, каскадный подход с пе-рекрывающимися процессами, каскадный подход с подпроцессами, спиральная модель); - каркасные подходы (рационально-универсальный процесс, модель процессов MSF). 3. формальные подходы. Они предусматривают особые формальные требования к процессу создания систем. Они делятся на: - генетичесие подходы (синтезирующее программирование, сборочное (расши-ряемое) программирование, конкретизирующее программирование) - подходы на основе формальных преобразований (технология стерильного цеха, формальные генетические подходы) 4. гибкие (адаптивные) подходы. Рекомендуется применять для небольших и средних проектов, в случае неясных и изменяющихся требований к системе. Ко-манда разработчиков должна быть ответственной и квалифицированной, а заказ-чик должен принимать участие в разработке. - ранние технические подходы быстрой разработки (эволюционное прототипиро-вание, итеративная разработка, постадийная разработка) - адаптивные подходы (экстримальное программирование, адаптивная разработка, семейство подходов Crystal) - подходы исследовательского программирования (компьютерный дарвенизм, фрагментарное программирование). 1.9. СТРОГИЕ ТЕХНОЛОГИЧЕСКИП ОДХОДЫ, ИХ НАЗНАЧЕНИЕ И КРАТ-КАЯ ХАРАКТЕРИСТИКА. Строгие (классические, жёсткие, предсказуемые) подходы. Данная группа подхо-дов рекомендуется применять для средних крупномасштабных проектов с фикси-рованным объёмом работ. Одно из основных требований к этим подходам пред-сказуемость. В эту группу входят: 1. каскадные технологические подходы - Классический каскадный подход. Каскадная модель предполагает строго детер-минированное следование стадий и этапов. Такая модель является идеализиро-ванной и пригодна лишь в том случае, когда можно заранее спланировать все пректные работы по созданию системы. (недостаток – отсутствие гибкости). - Каскадно-возвратный подход обеспечивает возврат к предыдущим стадиям и пересмотр или уточнение ранее принятых решений. Этот подход отражает итера-тивный характер разработки систем. Он в значительной степени отражает реаль-ный процесс создания систем, в том числе и существ. Запаздывание с достижени-ем результата. На задержку оказывает существенное влияние корректировки при возвратах. - Каскадно-итерационный подход предусматривает последовательные итерации каждого процесса до тех пор пока не будет достигнут желаемый результат. - Каскадный подход с перекрывающимися процессами позволяет некоторые про-цессы или их части выполнять параллельно. Каскадный подход с подпроцессами ориентирован на деление проекта на подпро-екты, которые могут разрабатываться параллельно. - Спиральная модель основана на использовании понятия прототип, которое реализует частичную функциональность создаваемой системы. Создание прототипов осуществляется за несколько витков спирали, каждый из которых состоит из определённой совокупности процессов. анализ каждого витка начинается с анализа риска, если риск превышает сроки и стоимость проекта, то разработка завершается, это позволяет предотвратить крупные денежные потери в будущем. Особенность спиральной модели в разработке итерациями, причём каждой следующий итерационный прототип будет обладать большой функциональностью. 2. Каркасные подходы (рационально-универсальный процесс, модель процессов MSF) представляют собой каркас для процессов. рациональный унифицированный процесс включает в себя лучшее из технологических подходов каскадной группы. 1.10. ФОРМАЛЬНЫЕ ТЕХНОЛОГИЧЕСКИЕ ПОДХОДЫ, ИХ НАЗНА-ЧЕНИЕ И КРАТКАЯ ХАРАКТЕРИСТИКА. Формальные подходы. Они предусматривают особые формальные требования к процессу создания систем. Они делятся на: 1. генетические подходы - Синтезирующее программирование предполагает синтез программы по её спе-цификации. В отличие от программ, которые написаны на алгоритмическом языке и предназначены для исполнения на ЭВМ после трансляции в исполняемый код, документ на языке спецификации является лишь базисом для последовательной реализации. Она обычно включает следующие задачи: - доопределить детали ко-торые нельзя выразить при помощи языка спецификации; - выбрать язык реализа-ции и аппаратно-программную платформу для реализации; - отладить и протес-тировать исполняемую программу. - Сборочное (расширяемое) программирование предполагает что программа со-бирается путём переисполнения уже известных фрагментов. Виды сборки: 1. мо-дульное сборочное программирование; 2. объектно-ориентированное сборочное программирование; 3. компонентное сборочное программирование; 4. аспектно-ориентированное сборочное программирование. Основные направления для соз-дания техники сборочного программирования: 1. выборка стиля программирова-ния, соответствующего с принятым принципам модульности; 2. повышение эф-фективности межмодульных интерфейсов; 3. введение баз программных модулей; 4. решение проблем идентификации модулей и описания интерфейсов. - Конкретизирующее программирование предполагает что частные программы извлекаются из универсальной. Наиболее известная технология этого вида про-граммирования – подход с применением паттернов проектирования. 2. Подходы на основе формальных преобразований (технология стерильного цеха, формальные генетические подходы)
1.11. ГИБКИЕ ТЕХНОЛОГИЧЕСКИЕ ПОДХОДЫ, ИХ НАЗНАЧЕНИЕ И КРАТКАЯ ХАРРАКТЕРИСТИКА.
гибкие (адаптивные) подходы. Рекомендуется применять для небольших и сред-них проектов, в случае неясных и изменяющихся требований к системе. Команда разработчиков должна быть ответственной и квалифицированной, а заказчик должен принимать участие в разработке. 1. ранние технические подходы быстрой разработки. - Эволюционное прототипирование применяется когда заказчик не может чётко сформулировать свои требования к системе или знает, что требования могут ко-ординально измениться. Этот подход включает создание пользовательского ин-терфейса , а затем разработка собственно самой системы. Недостаток этого под-хода6 невозможность определить продолжительность и стоимость проекта, а также неизвестно количество итераций по истечении которых пользователь со-чтёт изделие законченным. - Итеративная разработка предполагает создание первого прототипа, который включает завершённое ядро системы. В этом прототипе сосредоточена большая часть функций системы. Итерации разработки должны помочь пользователю оп-ределиться с пользовательским интерфейсом. - Постадийная разработка предназначена решать недостаток двух предыдущих подходов. Основная задача данного подхода предоставить заказчику работающую систему как можно раньше . данный подход требует тщательного тестирования каждой версии системы. 2. адаптивные подходы (экстремальное программирование, адаптивная разработ-ка, семейство подходов Crystal) 3. подходы исследовательского программирования (компьютерный дарвинизм, фрагментарное программирование).
1.12. КЛАССИФИКАЦИЯ ТЕХНОЛОГИЧЕСКИХ ПРОЦЕССОВ И СТАДИЙ.
Будем рассматривать 2 набора технологических процессов: 1. классический, включающий основные процессы, сложившиеся исторически в результате практического опыта разработки ПО. 2. стандартный, основан на стандарте ISO12207 В классическом наборе выделяется 9 технологических процессов: 1. возникновение и исследование идеи 2. управление (планирование) 3. анализ требований 4. проектирование 5. программирование 6. тестирование и отладка 7. ввод в действие 8. эксплуатация и сопровождение 9. завершение эксплуатации Стандартные технологические процессы делятся на 3 группы: 1. основные процессы: - процесс приобретения - поставки - разработки - эксплуатации (функционирования) - сопровождения 2. вспомогательные процессы - документирование - управление конфигурацией - обеспечение качества - верификация - аттестация - совместной оценки - аудита - решение проблем 3. организационные процессы - управление - создание инфраструктур - усовершенствование - обучение
1.13. КЛАССИЧЕСКИЙ НАБОР ТЕХНОЛОГИЧЕСКИХ ПРОЦЕССОВ И СТА-ДИЙ.
Классический, включающий основные процессы, сложившиеся исторически в ре-зультате практического опыта разработки ПО. В классическом наборе выделяется 9 технологических процессов: 1. возникновение и исследование идеи 2. управление (планирование) 3. анализ требований 4. проектирование 5. программирование 6. тестирование и отладка 7. ввод в действие 8. эксплуатация и сопровождение 9. завершение эксплуатации
1.14. СТАНДАРТНЫЙ НАДОР ТЕХНОЛОГИЧЕСКИХ ПРОЦЕССОВ.
Стандартный, основан на стандарте ISO12207. Стандартные технологические процессы делятся на 3 группы: 1.основные процессы: - процесс приобретения - поставки - разработки - эксплуатации (функционирования) - сопровождения 2. вспомогательные процессы - документирование - управление конфигурацией - обеспечение качества - верификация - аттестация - совместной оценки - аудита - решение проблем 3. организационные процессы - управление - создание инфраструктур - усовершенствование - обучение
1.15.ВЗАИМОСВЯЗЬ МЕЖДУ СТАНДАРТНЫМИ ПРОЦЕССАМИ
ТЕМА 1. 16. КЛАССИФИКАЦИЯ СТАНДАРТОВ ПО СОЗДАНИЮ И ИС-ПОЛЬЗОВАНИЮ СОД. Стандарты можно классифицировать по след. направлениям: 1) по масштабу: - международные - государственные - отраслевые - корпоративные 2) по степени юридического оформления: - принятые юридически - действующие фактически 3) по предмету стандартизации (стандарты на ЯП, протоколы, жизн. цикл) 4) по утверждающей организации: - ISO – международная организация по стандартизации - IEC – междунар. электро-техн. комиссия, - промышленные професс. или администрат. организации; - IEEE – институт инженеров по электротехн. и электронике - IAB – совет управления деятельностью интернета, - международные консорциумы: - OMG – группа управления объектами - X/OPEN – поставщики комп. техники - OSF – фонд открытого программного обеспечения 5) стандарты, касающиеся организации жизн. цикла информац. систем и ПО: - ГОСТ 34 - ISO/IEC 12207
ТЕМА 1. 17. НАЗНАЧЕНИЕ И КРАТКАЯ ХАРАКТЕРИСТИКА ГОСТов 34 ГРУППЫ.
1) ГОСТ 34.201 > Виды, комплектность и обозначение документов на АС v Виды документов: -ведомость -схема - инструкция - обоснование - описание - конструкторский документ(ГОСТ 2.201) -текст программы < - программный документ(ГОСТ 19.101) - описание программы - методика и прогр. испытаний - эксплуатац. док-ты > - описание применения - руководство сист. программ. - …………. стадии этапы 2) ГОСТ 34.601 > Стадии создания > 1 - 2 3 … 8 3) ГОСТ 34.602 > ТЗ на создание 4) РД 50-34.698 – Требование к содержанию документов > Степень адаптации стандарта ГОСТ 34 к конкр. разработкам определ. след. воз-можности: - возможн. отказ от этапа эск. проектирования и объединить этапы техн. проекта и рабочей документации - возможность отказаться от некотор. стадий разработки, а также объединить большенство документов и их разделов - возможность вводить дополнительные документы, разделы документов и работы - возможность динам. создавать частные техн. задания, что позволяет достаточно гибко формировать ЖЦ АС. ТЕМА 1. 18. НАЗНАЧЕНИЕ И ОСНОВНЫЕ ПОЛОЖЕНИЯ СТАНДАРТА ISO 12207 Данный стандарт был принят в 1995 году. По определению ISO 12207 – базовый стандарт процессов ЖЦ ПО ориентированный на различные виды ПО и типы проектов ИС в которых ПО является одной из составных частей. Стандарт опре-деляет стратегию и общий порядок в создании и эксплуатации ПО, он охватывает ЖЦ от концепции идей до завершения проекта. Согласно этому стандарту, систе-ма – объединение одного или нескольких процессов, аппаратн. средств, ПО, обо-рудования и людей для обеспечения возможностей удовлетворения определенных потребностей или целей. Стандарт ISO 12207 ориентирован на организацию дей-ствий каждой из двух сторон: поставщика(разработчик) и покупате-ля(пользователя). Этот стандарт может быть применен в том случае, когда обе стороны из одной организации. Общая структура стандарта: в ISO 12207 не предусматривает каких-либо этапов, стадий или фаз ЖЦ ИС. Данный стандарт определяет лишь ряд процессов. Каж-дый процесс подразделен на ряд действий, а каждое действие - на ряд задач. Все процессы делятся на 3 группы: основные, вспомогательные, организ. К особенностям стандарта можно отнести следующие: 1) стандарт имеет динамический характер, обусловленный способом определения последовательности выполнения процессов и задач, при котором один процесс при необходимости вызывает другой или его часть, это позволяет регулировать любую модель ЖЦ, 2) согласно этому стандарту модель ЖЦ – структура, содержащая процессы, дей-ствия и задачи, которые осуществл. в ходе разработки, функционирования (экс-плуатации) и сопровождения программн. продукта в течение всей жизни системы от определения требований до завершения ее использования 3) стандарт обеспечивает максимальную степень адаптивности, эта адаптация сводится к исключению процессов, видов деятельности и задач не применяемых в конкретном проекте, добавление уникальных или специфических процессов, дей-ствий и задач должно быть оговорено в контракте между сторонами 4) стандарт не содержит описание конкретных методов, действий, заготовок ре-шений или документации, он лишь описывает архитектуру процессов, но не кон-кретизирует в деталях как реализовать или выполнять услуги и задачи, включае-мые в процессы 5) хотя стандарт не предписывает конкр. модели ЖЦ или методы разработки, он определяет что стороны-участники при использовании стандарта отвечают за след.: -выбор модели ЖЦ для разработки проекта - адаптацию процессов и задач стандарта к этой модели - выбор и применение методов разработки ПО - выполнение действий и задач, подходящих для проекта ПО.
1.19 Понятие методологии создания СОД
Методология создания и использования СОД – это совокупность методов, приме-няемых в ЖЦ СОД, объединенных общефилософским подходом. Например, структурные методологии. Т.к. основу СОД составляет ПО, то и основу методологий создания и исполь-зования СОД определяет методология программирования. Основу методологии программирования определяет модель алгоритма. К наи-более известным относятся следующие модели алгоритмов: 1. Абстрактная вычислительная машина Тьюринга – определяет императивную (процедурную) методологию программирования. 2. Рекурсивные функции Гирбельта и Аккермана – определяет методологию структурного программирования. 3. Лямбда-исчисления Черча – определяет методологию функционального про-граммирования. 4. И др. модели. Методология процесса создания и использования СОД заключается в органи-зации и обеспечении управления этим процессом, чтобы гарантировать выполне-ние требований как к самой системе, так и к характеристикам процесса ее созда-ния и использования. К основным задачам, решение которых должна обеспечивать методология создания корпоративной СОД с помощью соответствующего набора инструмен-тальных средств, относятся следующие: 1. Обеспечение создания СОД, отвечающих целям и задачам предприятия и соот-ветствующим предъявленным к ним требованиям. 2. Гарантия создания системы с заданными параметрами в течении заданного времени в рамках оговоренного заранее бюджета. 3. Простота сопровождения модификаций и расширение системы с целью обеспе-чения её соответствия изменяющимся условиям работы предприятия. 4. Обеспечение создания корпоративной СОД, отвечающей требованиям открыто-сти, переносимости и масштабируемости. 5. Возможность использования в создаваемой системе разработанных ранее и применяемых на предприятии средств информационных технологий (ПО, БД, СВТ). Методологии, технологии и инструментарные средства составляют основу любой СОД.
1.20 Классификация методологий программирования
1. Императивное программирование 2. Объектно-ориентированное программирование 3. Функциональное программирование 4. Логическое программирование 4.1. Структурное императивное программирование 4.2. Императивное параллельное программирование 4.3. Логическое параллельное программирование. 5. Программирование, управляемое потоками данных 6. Доступ-ориентированное программирование. 7. Нейронное программирование.
1.21. Понятие технологии создания и использования СОД
Методология реализуется через конкретные технологии и поддерживающие их стандарты, методики и инструментальные средства, которые обеспечивают вы-полнение процессов ЖЦ СОД. Технология (технологический подход) определяется спецификой комбинаций стадий и процессов, ориентированных на различные классы СОД и на особенно-сти коллектива разработчиков. Например, основу содержания технологий проек-тирования составляют технологические инструкции, состоящие из описания по-следовательности технологических операций, условий в зависимости от которых выполняется та или иная операция, и описаний самих операций. Каждая технологическая операция должна обеспечиваться следующими мате-риальными и информационными ресурсами: 1. Данными, полученными от предыдущих операций (или исходные данные), ко-торые предоставляются в стандартном виде. 2. Методическими материалами, инструкциями, нормативами и стандартами. 3. Программными и техническими средствами. 4. Исполнителями. Технология создания и использования СОД должна удовлетворять следующим общим требованиям: 1. поддерживать полный ЖЦ системы; 2. обеспечивать гарантированное достижение целей разработки системы с задан-ным качеством и в установленное время; 3. обеспечивать возможность разделения крупных проектов на ряд подсистем, т.е. декомпозицию проекта на составные части, разработать группами исполнителей ограничение численности с последующей интеграцией составных частей.
1.22. Классификация методологий создания и использования СОД
1. Структурные методологии: 1.1. SADT – структурная методология анализа и проектирования систем (мини-стерство обороны, США) 1.2. SSADM – структурные методологии анализа и проектирования систем (Анг-лия, 1993, стандарт. ) 1.3. Структурный анализ и проектирование (Иодома / ДеМарко и Гейна-Сарсона) 1.4. Методологии, ориентированные на данные: - развития систем Джексона; - развития структурных систем Варнье-Орра. 1.5. Анализа и проектирования систем реального времени Уорда-Мехпора и Хартли 1.6. Информационные модели Мартина 1.7. Подходы отдельных фирм: - ORACLE – CDM - MS – MSF - R-технологии. 2. ОО: 2.1. Подход на основе UML - диаграмма классов; - диаграмма процессов; - диаграмма взаимод. 2.2. Подход Шлеер-Меллора 2.3. Подход Гради-Буча 2.4. Подход Джеймса Рамбо (OMT – Object Moduling Technique) 2.5. Подход Ивара Якобсона (OOSE – Object Orient Software Engineering)
1.23. Классификация структурных методологий создания и использования СОД
В рамках структурных методологий используются следующие техники и методи-ки: - IDEF0 – метод функционирования моделирования систем; - IDEF3 – метод описания бизнес-процессов; - DFD – диаграмма потоков данных; - ERD – диаграмма «сущность-связь»; - STD – диаграммы переходов в состояние; - структурные карты: 1. Константайна – для описания архитектуры ПО в виде совокупности моду-лей, подсистем, библиотек, областей данных; 2. Джексона – для описания структуры модуля в виде совокупности структур, процедур, библиотек, блоков и т.д.
1.24. Проекты, их классификация и оценка
СОД разрабатывается как некоторый проект. Можно выделить некоторые призна-ки проекта как объекта как объекта управления: 1. изменчивость (целенаправленный перевод системы из существующего в неко-торое желаемое состояние); 2. ограниченность конечной цели, продолжительности, бюджета требуемых ре-сурсов; 3. новизна для предприятия, для которого реализуется проект; 4. комплексность (наличие большого числа факторов, прямо или косвенно влияющих на результаты проекта). Выполнение работ по проекту обеспечивается наличием необходимых ресур-сов: - материалов; - оборудования; - человеческих ресурсов. Проекты могут сильно отличаться по сфере предложения, составу, предметной области, масштабам, длительности, составом участников, степени сложности, значимости результатов и т.д. Разработка СОД относится к тем проектам, которые имеют следующие осо-бенности: 1. главная цель проекта четко определена; 2. срок завершения и продолжительность проекта определены заранее. Масштаб проекта определяется по размеру бюджета и количеству участников: а) мелкие (<10 чел, 3-6 мес.);б) небольшие;в) средние (20-30; 1-2 года);г) крупно-масштабные (100-300 чел., 3-5 лет);д) гигантские (1000-2000 чел., 7-10 лет). Безнадежный проект – проект, параметры которого отклоняются от норм про-екта на 50%. Для прогр. систем это означает, что есть одно или более из следующих огра-ничений: 1. план выполнения проекта по времени сжат более, чем на половину; 2. число разработчиков уменьшено > чем на половину; 3. бюджет проекта и связанные с ним ресурсы урезаны более, чем на половину; 4. требования к функциям, возможности и производительности и к другим техни-ческим характеристикам в 2 раза превышают значения, которое они могли бы иметь при нормальных условиях. Для оценки проектов используются: 1. методы: 1.1. размерно-ориентированные метрики; 1.2. функционально-ориентированные метрики; 1.3. алгоритмические и имитационные модели; 1.4. оценки экспертов; 1.5. разработка прототипов для оценки; 2. средства: 3. услуги фирм по оценке затрат на производство СОД.
1.25 Участники процесса создания СОД и их роли
Участники: 1.заказчик 2.пользователь 3. разработчик: 3.1.коллективная разработка. Особенности: Бригада главного программиста 3.1.1. жесткая иерархия 3.1.2. равноправные исполнители 3.2. авторская разработка. Особенности: 3.2.1. целенаправленная разработка 3.2.2. разработка на основе открытых исходных текстов 3.2.3. большое количество внешних тестеров 3.3. общинная разработка 3.3.1. отсутствие межличностных коммуникаций 3.3.2. отсутствие разбиения. И еще какая-то схема: - руководитель проекта – заказчик - руководитель – изделие - разработчик - тестировщик - инструктор – пользователь - логистик – сопровождение.
1.26. Структура процесса создания, сопровождения и эксплуатации СОД (ГОСТ 34)
| bbb |
| bb1 |
| bb2 |
| bb3 |