Главная Случайная страница Контакты | Мы поможем в написании вашей работы! | ||
|
В основе технологий баз данных, базирующихся на описанных выше МД, лежит статическая концепция хранения информации, сконцентрированная на моделировании данных. Однако новые области применения технологии со сложными, взаимосвязанными объектами БД, такими как:
- автоматизированное проектирование;
- автоматизированное производство;
- автоматизированная разработка программного обеспечения;
- офисные информационные системы;
- мультимедиа системы;
- геоинформационные системы;
- издательские системы и другие, - продемонстрировали ограниченные возможности статической концепции с точки зрения моделирования объектов реального мира.
Для новых типов сложных специализированных приложений БД эффективна динамическая концепция хранения информации, позволяющая параллельно моделировать данные и процессы, действующие на эти данные. Это позволяет учитывать семантику предметной области и потому наиболее адекватно описывать эти приложения. Такая концепция основывается на объектно-ориентированном подходе, широко используемом при создании программного обеспечения. МД, реализующая данную концепцию и базирующаяся на объектно-ориентированной парадигме (ООП), получила название объектно-ориентированной модели данных (ООМД).
Построение ООМД исходит из предположения о том, что предметную область можно описать совокупностью объектов. Каждый объект представляет собой уникально идентифицируемую сущность, которая содержит атрибуты, описывающие состояние объектов «реального мира», и связанные с ними действия. Текущее состояние объекта описывается одним или несколькими атрибутами, которые могут быть простыми или сложными. Простой атрибут может иметь примитивный тип (например, целое число, строка и т. д.) и принимать литеральное значение. Составной атрибут может содержать коллекции и/или ссылки. Ссылочный атрибут представляет собой связь между объектами.
Ключевым свойством объекта является уникальность его Идентификации. Поэтому у каждого объекта в объектно-ориентированной системе должен быть свой идентификатор.
Идентификатор объекта (OID - Object Identifier) - это внутренний для базы данных способ пометки индивидуальных объектов. Пользователи, работающие с диалоговой программой заданий запросов или просмотра информации, как правило, не видят этих идентификаторов. Они назначаются и используются самой СУБД. Семантика идентификатора в каждой СУБД своя. Она может быть как случайным значением, так и содержать информацию, необходимую для поиска объекта в файле базы данных, например, номер страницы в файле и смещение объекта от ее начала. Именно идентификатор должен использоваться для организации ссылок на объект.
Все объекты являются инкапсулированными, т. е. представление или внутренняя структура объекта остаются скрытыми от пользователя. Вместо этого пользователю известно только, что данный объект может выполнять некоторые функции. Так, для объекта СКЛАД могут применяться такие методы как ПРИНЯТЬ_ТОВАР, ВЫДАТЬ_TOBAP и т. д. Преимущество инкапсуляции состоит в том, что она позволяет изменять внутреннее представление объектов, не переделывая приложений, в которых используются эти объекты. Иначе говоря, инкапсуляция подразумевает независимость данных.
Объект инкапсулирует данные и функции (методы, согласно ООП). Методы определяют поведение объекта. Они могут использоваться для изменения состояния объекта путем изменения значений его атрибутов или для создания запросов к значениям избранных атрибутов. Например, могут существовать методы для добавления сведений о новом объекте недвижимости, предназначенном для сдачи в аренду, для обновления сведений о зарплате сотрудника или для распечатки сведений о конкретном товаре.
Объекты, которые имеют один и тот же набор атрибутов и отвечают на одни и те же сообщения, могут быть сгруппированы в класс (в литературе термины «класс» и «тип» часто используются как синонимы). У каждого такого класса имеется свой представитель - объект, который и является элементом данных. Объекты некоторого класса называются его экземплярами.
В некоторых объектно-ориентированных системах класс также является объектом и обладает собственными атрибутами и методами, которые называются атрибутами класса и методами класса.
Важными понятиями ООП служат иерархия классов и иерархия контейнеров.
Иерархия классов подразумевает под собой возможность наличия у каждого класса, называемого в таком случае суперклассом, своего подкласса. В качестве примера можно привести следующую цепочку: все программисты какого-либо предприятия являются его сотрудниками, следовательно, каждый программист, который в рамках ООМД является объектом класса ПРОГРАММИСТЫ, он является также и сотрудником, который, в свою очередь, является объектом класса СОТРУДНИКИ. Таким образом, ПРОГРАММИСТЫ будут подклассом, СОТРУДНИКИ - суперклассом. Но программисты могут также делиться на системных и прикладных. Следовательно, ПРОГРАММИСТЫ будут суперклассом к подклассам СИС_ПРОГРАМ-МИСТЫ и ПРИКЛ_ПРОГРАММИСТЫ. Продолжая эту цепочку далее, мы получим иерархию классов, при которой каждый объект подкласса наследует экземпляры переменных и методы соответствующего суперкласса.
Существует несколько видов наследования - единичное, множественное и избирательное. Единичное наследование представляет собой случай, когда подклассы наследуют не более чем у одного суперкласса. Множественное наследование - наследование более чем у одного суперкласса. Избирательное наследование позволяет подклассу наследовать ограниченное количество свойств его суперкласса.
Наследование экземпляров переменных называется структурным наследованием, наследование методов - поведенческим наследованием, а способность использовать один и тот же метод для разных классов или, скорее, применять разные методы с одним и тем же именем для разных классов называется полиморфизмом.
Объектно-ориентированной архитектуре присущ также и другой тип иерархии - иерархия контейнеров. Он состоит в том, что некоторые объекты могут концептуально содержаться внутри других. Так, объект класса ОТДЕЛ должен содержать общедоступную переменную НАЧАЛЬНИК, являющуюся ссылкой на соответствующий начальнику отдела объект класса СОТРУДНИКИ, а также должен содержать ссылку на совокупность ссылок на объекты, соответствующие работающим в данном отделе сотрудникам.
В некоторых объектно-ориентированных системах класс также является объектом и обладает собственными атрибутами и методами. Общие характеристики класса описываются его атрибутами. Методы объектного класса являются своего рода аналогом свойств объектов реального мира. Каждый объект, относящийся к какому-либо определенному классу, обладает этими свойствами. Следовательно, при создании объекта необходимо объявить класс, к которому он относится, чтобы таким образом определить присущие ему свойства.
Пользователь и объект взаимодействуют посредством сообщений. В ответ на каждое сообщение система выполняет соответствующий метод.
Все связи в объектной модели осуществляются с помощью ссылочных атрибутов, которые обычно реализуются как ОID-идентификаторы.
Связи в реляционной БД представлены сопоставлением первичных и внешних ключей. В самой базе нет структур для образования ассоциаций между таблицами, связи используются по мере необходимости при соединении таблиц. Напротив, связи составляют основу объектно-ориентированной базы данных, так как в каждый объект включаются идентификаторы объектов, с которыми он связан.
В ООМД могут быть реализованы не только традиционные связи, но и связи, обусловленные наследованием.
Связь типа один-к-одному (1: 1) между объектами А и В реализуется путем добавления ссылочного атрибута на объект В в объект А и (для поддержания ссылочной целостности) ссылочного атрибута на объект А в объект В.
Связь типа один-ко-многим (1: М) между объектами А и В реализуется путем добавления в объект А ссылочного атрибута на объект В и атрибута, содержащего набор ссылок на объект А, в объект В (например, в объект А добавляется ссылочный атрибут В{ОID2, OID3...}, и в экземпляры объекта В с OID2, OID3,... добавляется ссылочный атрибут А: OID1.
Связь типа многие-ко-многим (М: N) между объектами А и В реализуется путем добавления в каждый объект атрибута, содержащего набор ссылок.
В ООМД можно воспользоваться связью вида «целое-часть», описывающей, что объект одного класса содержит объекты других классов в качестве своих частей. В случае производственной БД между классом ИЗДЕЛИЕ и классами ДЕТАЛЬ и СБОРКА существовала бы связь «целое-часть». Данная связь - это вариант связи «многие-ко-многим», обладающий специальной семантикой. Связь «целое-часть» реализуется, как любая другая связь «многие-ко-многим», с помощью множества идентификаторов связанных объектов. Однако она, в отличие от обычной связи «многие-ко-многим», имеет другое смысловое значение.
Поскольку объектно-ориентированная парадигма поддерживает наследование, то в ООМД можно применять связь типа «является» и связь типа «расширяет». Связь «является», которую еще называют отношением обобщения-специализации, порождает иерархию наследования, в которой подклассы оказываются частными случаями суперклассов. Это позволяет не описывать повторно унаследованные признаки. При использовании связи «расширяет» подкласс развивает функциональность суперкласса, а не ограничивается его частным случаем.
Рассмотрим, как реализуются в ООМД такие компоненты, как ограничения целостности и операции над данными.
Особенности этих компонент определяются спецификой модели. Данная специфика в ООМД продиктована прежде всего такими своими внутренними концепциями, как инкапсуляция объектов, т. е. скрытость внутренней структуры, доступ к данным только через определенные заранее методы, иерархия классов и иерархия контейнеров.
Специфика ООМД диктуется и спецификой объекта. Она проявляется в необходимости группировки объектов в классы. Каждый объект входит в тот или иной класс в зависимости от задачи, причем один объект может принадлежать сразу нескольким классам (например, семейству ПРОГРАММИСТЫ и ВЫСОКОПЛАЧИВАЕМЫЕ). Другой спецификой объекта является то, что он может «перебегать» из одного класса (подкласса) в другой. Так, СИСТЕМНЫЙ ПРОГРАММИСТ может стать со временем ПРИКЛАДНЫМ. Таким образом, иерархия классов не является аналогом иерархической модели, как это могло показаться ранее, но требует от системы способности изменять расположение каждого объекта внутри иерархии классов, например перемещаться «вверх» или «вниз» внутри данной иерархии. Но возможен и более сложный процесс - система должна обеспечивать возможность объекта быть присоединенным (отсоединенным) к произвольной вершине иерархии в любой момент времени.
Важную роль в ООМД играют ограничения целостности связей. Чтобы связи в объектно-ориентированной МД могли работать, идентификаторы объектов по обе стороны связи должны соответствовать друг другу. Например, если имеется связь между СЛУЖАЩИМИ и их ДЕТЬМИ, то должна быть какая-то гарантия, что при вставке объекта, описывающего ребенка, в объект, отображающий служащего, идентификатор последнего добавляется в соответствующий объект. Такой вид целостности связей, в чем-то аналогичный ссылочной целостности в реляционной модели данных, устанавливается с помощью обратных связей. Чтобы гарантировать целостность связей, проектировщику предоставляется специальная синтаксическая конструкция, необходимая для задания места нахождения обратного идентификатора объекта. Обязанность задавать ограничения целостности связей (как и ссылочной целостности в реляционной БД) лежит на проектировщике.
В ООМД и описание данных, и манипулирование ими происходят с помощью одного и того же объектно-ориентированного процедурного языка.
Проблемами стандартизации технологии объектных БД занимается группа ODMG (Object Database Management Groop). Она разработала объектную модель (версия ODMG 2.0 была принята в сентябре 1997 г.), которая определяет стандартную модель для семантики объектов БД. Эта модель имеет большое значение, поскольку определяет встроенную семантику, которую понимает и может реализовать объектно-ориентированная СУБД (ООСУБД). Структура библиотек и приложений, использующих эту семантику, должна быть переносимой среди различных ООСУБД, которые поддерживают данную объектную МД. Основными компонентами архитектуры ODMG являются: объектная модель (ОМ), язык определения объектов (ODL), язык объектных запросов (OQL), а также способность связывания с языками C++, Java и Smalltalk.
Объектная модель данных в соответствии со стандартом ODMG 2.0 характеризуется следующими свойствами:
- базовыми конструктивными элементами являются объекты и литералы. Каждый объект имеет уникальный идентификатор. Литерал не имеет собственного идентификатора и не может существовать отдельно как объект. Литералы всегда встроены в объекты, и на них нельзя ссылаться индивидуально;
- объекты и литералы различаются по типу. Каждый тип имеет собственный домен, разделяемый всеми объектами и литералами данного типа. Типы могут также обладать поведением. Если тип имеет некоторое поведение, то таким же поведением обладают все объекты этого типа. На практике тип может быть классом, из которого создается объект, интерфейсом или простым типом данных (например, целым числом). Объект можно представить как экземпляр типа;
- состояние объекта определяется набором текущих значений, реализуемых множеством свойств. Этими свойствами могут быть атрибуты объекта или связи между объектом и одним или несколькими другими объектами;
- поведение объекта определяется набором операций, которые могут быть выполнены над объектом или самим объектом. Операции могут иметь список входных и выходных параметров, причем каждый из них строго определенного типа. Каждая операция может также возвращать типизированный результат;
- определение базы данных хранится в схеме, записанной на языке определения объектов Object Definition Language (ODL). База данных хранит объекты, позволяя их совместно использовать различным пользователям и приложениям.
СУБД, базирующиеся на ООМД, называют объектно-ориентированными СУБД (ООСУБД). Эти СУБД относят к СУБД третьего поколения* (* Историю развития моделей хранения данных часто разбивают на три этапа (поколения): первое поколение (конец 1960 - начало 70-х годов) - иерархическая и сетевая модели; второе поколение (приблизительно 1970-1980-е годы) - реляционная модель; третье поколение (1980-е годы - начало 2000-х годов) - объектно-ориентированные модели.).
Сегодня объектно-ориентированные БД применяются в различных организациях для решения широкого круга задач. Анализ и обобщение накопленного опыта в области данных информационных технологий дали возможность идентифицировать приложения, в которых оправданно применение объектно-ориентированных баз данных:
- приложение состоит из большого числа взаимодействующих частей. Каждая из них обладает своим поведением, которое зависит от поведения других;
- система должна обрабатывать большие объемы неструктурированных или имеющих сложную структуру данных;
- приложение будет осуществлять предсказуемый доступ к данным, поэтому навигационная природа объектно-ориентированных БД не будет являться существенным недостатком;
- потребность в незапланированных запросах ограничена;
- структура хранимых данных имеет иерархическую или сходную природу.
В настоящий момент на рынке ПО присутствует множество объектно-ориентирован-ных СУБД. В табл. 10.6 представлены некоторые из коммерческих систем данного класса.
Таблица 10.6
Современные коммерческие ООСУБД,
их фирмы-производители и области применения
Одним из принципиальных отличий объектных баз данных от реляционных является возможность создания и использования новых типов данных. Важная особенность ООСУБД состоит в том, что создание нового типа не требует модификации ядра базы и основывается на принципах объектно-ориентированного программирования.
Ядро ООСУБД оптимизировано для операций с объектами. Естественными операциями для него являются кэширование объектов, ведение версий объектов, разделение прав доступа к конкретным объектам. ООСУБД свойственно более высокое быстродействие на операциях, требующих доступа и получения данных, упакованных в объекты, по сравнению с реляционными СУБД, для которых необходимость выборки связных данных ведет к выполнению дополнительных внутренних операций.
Немалое значение для ООСУБД имеет возможность перемещения объектов из одной базы в другую.
При создании различных приложений на базе ООСУБД немаловажной является встроенная структура классов той или иной СУБД. Библиотека классов поддерживает, как правило, не только все стандартные типы данных, но и расширенный набор мультимедийных и других сложных типов данных, таких как видео, звук, последовательность анимационных кадров. В некоторых ООСУБД созданы библиотеки классов, дающие возможность хранения и полнотекстового поиска документальной информации (например, Jasmine, ODB-Jupiter). Пример базовой структуры классов приведен на рис. 10.17.
Основное положение в ней занимает класс TOdbObject, который содержит все необходимые свойства и методы для управления доступом к базе и выполнения индексации. Все остальные классы переопределяют его методы, добавляя проверку корректности реализуемого ими типа и специфический индексатор.
Как видно из рис. 10.17, в структуре существуют различные классы, ориентированные на обработку документальной информации - TOdbText, TOdbDocument, TODBTextDocument и др. Каждый документ представлен отдельным объектом. Таким образом обеспечивается естественность хранения документов. Одной из важнейших операций является поиск документов по запросу. Для большинства классов реализована возможность поиска объектов по значению определенного ключа. Для класса TOdbText реализована возможность формирования поискового запроса по фразе, записанной на естественном языке.
Класс TOdbDocument - особый, способный вмещать разнотипные объекты. Он состоит из полей, каждое из которых имеет имя и ассоциируется с объектом определенного типа. Наличие данного класса дает пользователю возможность расширить набор типов. Модифицируя объект-контейнер (документ), можно задавать определенный набор полей и получать при этом новый тип Документа.
На основе ODB-Jupiter разработчики ООСУБД создали полнофункциональную информационно-поисковую систему ODB-Text, обладающую универсальной структурой хранимых данных и мощным механизмом поиска. Система ODB-Text -средство коллективной обработки документов и ведения корпоративного архива. В числе возможных приложений назовем автоматизацию учета документооборота современного офиса, построение справочно-информационных систем (подобных известным Юридическим базам данных), ведение сетевых баз данных, учет кадров, библиографию и др.
41. Особенности проектирования прикладной ИС. Фазы развития ИС. (Тема 11, стр. 100-103).
11.1.3. Особенности системного проектирования прикладной ИС
При построении (выборе, адаптации) информационной системы можно использовать две основные концепции, два основных подхода (третья концепция - их комбинация):
1. ориентация на проблемы, которые необходимо решать с помощью этой информационной системы, т.е. проблемно-ориентированный подход (или индуктивный подход);
2. ориентация на технологию, которая доступна (актуализируема) в данной системе, среде, т.е. технологически-ориентированный подход (или дедуктивный подход).
Выбор концепции зависит от стратегических (тактических) и(или) долгосрочных (краткосрочных) критериев, проблем, ресурсов.
Если вначале изучаются возможности имеющейся технологии, а после определяются актуальные проблемы, которые можно решить с их помощью, то необходимо опираться на технологически-ориентированный подход.
Если же вначале определяются актуальные проблемы, а затем внедряется технология, достаточная для решения этих проблем, то необходимо опираться на проблемно-ориентированный подход.
При этом обе концепции построения информационной системы зависят друг от друга: внедрение новых технологий изменяет решаемые проблемы, а изменение решаемых проблем - приводит к необходимости внедрения новых технологий; и то, и другое влияет на принимаемые решения.
Системное проектирование (разработка) и использование любой прикладной (корпоративной) информационной системы должно пройти следующий жизненный цикл информационной системы:
– предпроектный анализ (опыт создания других аналогичных систем, прототипов, отличия и особенности разрабатываемой системы и др.), анализ внешних проявлений системы;
– внутрисистемный анализ, внутренний анализ (анализ подсистем системы);
– системное (морфологическое) описание (представление) системы (описание системной цели, системных отношений и связей с окружающей средой, другими системами и системных ресурсов - материальных, энергетических, информационных, организационных, людских, пространственных и временных);
– определение критериев адекватности, эффективности и устойчивости (надежности);
– функциональное описание подсистем системы (описание моделей, алгоритмов функционирования подсистем);
– макетирование (макетное описание) системы, оценка взаимодействия подсистем системы (разработка макета - реализации подсистем с упрощенными функциональными описаниями, процедурами, и апробация взаимодействия этих макетов с целью удовлетворения системной цели), при этом возможно использование "макетов" критериев адекватности, устойчивости, эффективности;
– "сборка" и тестирование системы - реализация полноценных функциональных подсистем и критериев, оценка модели по сформулированным критериям;
– функционирование системы;
– определение целей дальнейшего развития системы и ее приложений;
– сопровождение системы - уточнение, модификация, расширение возможностей системы в режиме ее функционирования (с целью ее эволюционирования).
Эти этапы - основные для информационного реинжиниринга систем.
Разработка корпоративной информационной системы, как правило, выполняется для вполне определенного предприятия. Особенности предметной деятельности предприятия, безусловно, будут оказывать влияние на структуру информационной системы. Но в то же время структуры разных предприятий в целом похожи между собой. Каждая организация, независимо от рода ее деятельности, состоит из ряда подразделений, непосредственно осуществляющих тот или иной вид деятельности компании. И эта ситуация справедлива практически для всех организаций, каким бы видом деятельности они ни занимались.
Таким образом, любую организацию можно рассматривать как совокупность взаимодействующих элементов (подразделений), каждый из которых может иметь свою, достаточно сложную, структуру. Взаимосвязи между подразделениями тоже достаточно сложны. В общем случае можно выделить три вида связей между подразделениями предприятия:
- функциональные связи - каждое подразделение выполняет определенные виды работ в рамках единого бизнес-процесса;
- информационные связи - подразделения обмениваются информацией (документами, факсами, письменными и устными распоряжениями и т. п.);
- внешние связи- некоторые подразделения взаимодействуют с внешними системами, причем их взаимодействие также может быть как информационным, так и функциональным.
Общность структуры разных предприятий позволяет сформулировать некоторые единые принципы построения корпоративных информационных систем.
В общем случае процесс разработки информационной системы может быть рассмотрен с двух точек зрения:
- по содержанию действий разработчиков (групп разработчиков). В данном случае рассматривается статический аспект процесса разработки, описываемый в терминах основных потоков работ: исполнители, действия, последовательность действий и т. п.;
- по времени, или по стадиям жизненного цикла разрабатываемой системы. В данном случае рассматривается динамическая организация процесса разработки, описываемая в терминах циклов, стадий, итераций и этапов.
Информационная система предприятия разрабатывается как некоторый проект. Многие особенности управления проектами и фазы разработки проекта (фазы жизненного цикла) являются общими, не зависящими не только от предметной области, но и от характера проекта (неважно, инженерный это проект или экономический). Поэтому имеет смысл вначале рассмотреть ряд общих вопросов управления проектами.
Проект - это ограниченное по времени целенаправленное изменение отдельной системы с изначально четко определенными целями, достижение которых определяет завершение проекта, а также с установленными требованиями к срокам, результатам, риску, рамкам расходования средств и ресурсов и к организационной структуре.
Обычно для сложного понятия (каким, в частности, является понятие проекта) трудно дать однозначную формулировку, которая полностью охватывает все признаки вводимого понятия. Поэтому приведенное определение не претендует на единственность и полноту.
Можно выделить следующие основные отличительные признаки проекта как объекта управления:
- изменчивость - целенаправленный перевод системы из существующего в некоторое
желаемое состояние, описываемое в терминах целей проекта;
- ограниченность конечной цели;
- ограниченность продолжительности;
- ограниченность бюджета;
- ограниченность требуемых ресурсов;
- новизна для предприятия, для которого реализуется проект;
- комплексность - наличие большого числа факторов, прямо или косвенно влияющих на прогресс и результаты проекта;
- правовое и организационное обеспечение - создание специфической организационной структуры на время реализации проекта.
Эффективность работ достигается за счет управления процессом реализации проекта, которое обеспечивает распределение ресурсов, координацию выполняемой последовательности работ и компенсацию внутренних и внешних возмущающих воздействий.
С точки зрения теории систем управления проект как объект управления должен быть наблюдаемым и управляемым, то есть выделяются некоторые характеристики, по которым можно постоянно контролировать ход выполнения проекта (свойство наблюдаемости). Кроме того, необходимы механизмы своевременного воз действия на ход реализации проекта (свойство управляемости).
Свойство управляемости особенно актуально в условиях неопределенности и изменчивости предметной области, которые нередко сопутствуют проектам по разработке информационных систем.
Каждый проект, независимо от сложности и объема работ, необходимых для его выполнения, проходит в своем развитии определенные состояния: от состояния, когда «проекта еще нет», до состояния, когда «проекта уже нет». Совокупность ступеней развития от возникновения идеи до полного завершения проекта принято разделять на фазы (стадии, этапы).
В определении количества фаз и их содержания имеются некоторые отличия, поскольку эти характеристики во многом зависят от условий осуществления конкретного проекта и опыта основных участников. Тем не менее, логика и основное содержание процесса разработки информационной системы почти во всех случаях являются общими.
Можно выделить следующие фазы развития информационной системы:
- формирование концепции;
- разработка технического задания;
- проектирование;
- изготовление;
- ввод системы в эксплуатацию.
Рассмотрим каждую из них более подробно. Вторую и частично третью фазы принято называть фазами системного проектирования, а последние две (иногда сюда включают и фазу проектирования) - фазами реализации.
Концептуальная фаза
Главным содержанием работ на этой фазе является определение проекта, разработка его концепции, включающая:
- формирование идеи, постановку целей;
- формирование ключевой команды проекта;
- изучение мотивации и требований заказчика и других участников;
- сбор исходных данных и анализ существующего состояния;
- определение основных требований и ограничений, требуемых материальных, финансовых и трудовых ресурсов;
- сравнительную оценку альтернатив;
- представление предложений, их экспертизу и утверждение.
Разработка технического предложения
Главным содержанием этой фазы является разработка технического предложения и переговоры с заказчиком о заключении контракта. Общее содержание работ этой фазы:
- разработка основного содержания проекта, базовой структуры проекта;
- разработка и утверждение технического задания;
- планирование, декомпозиция базовой структурной модели проекта;
- составление сметы и бюджета проекта, определение потребности в ресурсах;
- разработка календарных планов и укрупненных графиков работ;
- подписание контракта с заказчиком;
- ввод в действие средств коммуникации участников проекта и контроля за хо дом работ.
Проектирование
На этой фазе определяются подсистемы, их взаимосвязи, выбираются наиболее эффективные способы выполнения проекта и использования ресурсов. Характерные работы этой фазы:
- выполнение базовых проектных работ;
- разработка частных технических заданий;
- выполнение концептуального проектирования;
- составление технических спецификаций и инструкций;
- представление проектной разработки, экспертиза и утверждение.
Разработка
На этой фазе производятся координация и оперативный контроль работ по проекту, осуществляется изготовление подсистем, их объединение и тестирование. Основное содержание:
- выполнение работ по разработке программного обеспечения;
- выполнение подготовки к внедрению системы;
- контроль и регулирование основных показателей проекта.
Ввод системы в эксплуатацию
На этой фазе проводятся испытания, опытная эксплуатация системы в реальных условиях, ведутся переговоры о результатах выполнения проекта и о возможных новых контрактах. Основные виды работ:
- комплексные испытания;
42. Концепция жизненного цикла ИС. (Тема 11, стр. 103-105).
Дата публикования: 2015-02-03; Прочитано: 2231 | Нарушение авторского права страницы | Мы поможем в написании вашей работы!