Особенности современных крупных проектов ис

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

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

* наличие совокупности тесно взаимодействующих компонентов (подсистем), имеющих свои локальные задачи и цели функционирования;

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

* необходимость интеграции существующих и вновь разрабатываемых приложений;

* функционирование в неоднородной среде на нескольких аппаратных платформах;

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

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

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

2. Факторы, способствующие появлению CASE-средств.

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

* неадекватная спецификация требований;

* неспособность обнаруживать ошибки в проектных решениях;

* низкое качество документации, снижающее эксплуатационные качества;

* затяжной цикл и неудовлетворительные результаты тестирования.

Перечисленные факторы способствовали появлению программно-технологических средств специального класса — CASE-средств, реализующих CASE-технологию создания и сопровождения ИС. Термин CASE (Computer Aided Software Engineering).

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

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

* подготовка аналитиков и программистов, восприимчивых к концепциям модульного и структурного программирования;

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

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

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

Для успешного внедрения CASE-средств организация должна обладать следующими качествами:

* Технология. Понимание ограниченности существующих возможностей и способность принять новую технологию;

* Культура. Готовность к внедрению новых процессов и взаимоотношений между разработчиками и пользователями;

* Управление. Четкое руководство и организованность по отношению к наиболее важным этапам и процессам внедрения.

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

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

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

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

* отсутствие полного соответствия между теми процессами и методами, которые поддерживаются CASE-средствами, и теми, которые используются в данной организации, может привести к дополнительным трудностям;

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

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

* негативное отношение персонала к внедрению новой CASE-технологии может быть главной причиной провала проекта.

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

Успешное внедрение CASE-средств должно обеспечить такие выгоды как:

* высокий уровень технологической поддержки процессов разработки и сопровождения ПО;

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

* приемлемый уровень отдачи от инвестиций в CASE-средства.

4. Классификация CASE-средств.

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

В разряд CASE-средств попадают как относительно дешевые системы для персональных компьютеров с весьма ограниченными возможностями, так и дорогостоящие системы для неоднородных вычислительных платформ и операционных сред. Так, современный рынок программных средств насчитывает около 300 различных CASE-средств.

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

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

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

* использование специальным образом организованного хранилища проектных метаданных (репозитория).

Интегрированное CASE-средство (или комплекс средств, поддерживающих полный ЖЦ ПО) содержит следующие компоненты;

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

* графические средства анализа и проектирования, обеспечивающие создание и редактирование иерархически связанных диаграмм (DFD, ERD и др.), образующих модели ИС;

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

* средства конфигурационного управления; * средства документирования; * средства тестирования; * средства управления проектом; * средства реинжиниринга.

Все современные CASE-средства могут быть классифицированы в основном по типам и категориям. По типам отражает функциональную ориентацию CASE-средств на те или иные процессы ЖЦ. По категориям определяет степень интегрированности по выполняемым функциям и включает отдельные локальные средства, решающие небольшие автономные задачи (tools), набор частично интегрированных средств, охватывающих большинство этапов жизненного цикла ИС (toolkit) и полностью интегрированные средства, поддерживающие весь ЖЦ ИС и связанные общим репозиторием.

CASE-средства можно классифицировать по следующим признакам:

* применяемым методологиям и моделям систем и БД;

* степени интегрированности с СУБД;

Классификация по типам в основном совпадает с компонентным составом CASE-средств и включает следующие основные типы:

* средства анализа (Upper CASE), предназначенные для построения и анализа моделей предметной области (Design/IDEF (Meta Software), BPwin (Logic Works));

* средства анализа и проектирования (Middle CASE), поддерживающие наиболее распространенные методологии проектирования и использующиеся для создания проектных спецификаций (Vantage Team Builder (Cayenne), Designer/2000 (ORACLE), Silverrun (CSA), PRO-IV (McDonnell Douglas), CASE.Аналитик (МакроПроджект)). Выходом таких средств являются спецификации компонентов и интерфейсов системы, архитектуры системы, алгоритмов и структур данных;

* средства проектирования БД, обеспечивающие моделирование данных и генерацию схем баз данных (как правило, на языке SQL) для наиболее распространенных СУБД. К ним относятся ERwin (Logic Works), S-Designor (SDP) и DataBase Designer (ORACLE). Средства проектирования баз данных имеются также в составе CASE-средств Vantage Team Builder, Designer/2000, Silverrun и PRO-IV;

* средства разработки приложений. К ним относятся средства 4GL (Uniface (Compuware), JAM (JYACC), PowerBuilder (Sybase), Developer/2000 (ORACLE), New Era (Informix), SQL Windows (Gupta), Delphi (Borland) и др.) и генераторы кодов, входящие в состав Vantage Team Builder, PRO-IV и частично — в Silverrun;

* средства реинжиниринга, обеспечивающие анализ программных кодов и схем баз данных и формирование на их основе различных моделей и проектных спецификаций. Средства анализа схем БД и формирования ERD входят в состав Vantage Team Builder, PRO-IV, Silverrun, Designer/2000, ERwin и S-Designor. В области анализа программных кодов наибольшее распространение получают объектно-ориентированные CASE-средства, обеспечивающие реинжиниринг программ на языке С++ (Rational Rose (Rational Software), Object Team (Cayenne)).

Вспомогательные типы включают:

* средства планирования и управления проектом (SE Companion, Microsoft Project и др.);

* средства конфигурационного управления (PVCS (Intersolv));

* средства тестирования (Quality Works (Segue Software));

* средства документирования (SoDA (Rational Software)).

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

* Vantage Team Builder ( Westmount I-CASE); * Designer/2000; * Silverrun; * ERwin+BPwin; * S-Designor; * CASE. Аналитик .

5. Характеристика CASE-средств.

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

* использование специальным образом организованного хранилища проектных метаданных (репозитория).

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

6. Жизненный цикл по ИС.

ЖЦ ПО — это непрерывный процесс, который начинается с момента принятия решения о необходимости его создания и заканчивается в момент его полного изъятия из эксплуатации. Основным нормативным документом, регламентирующим ЖЦ ПО, является международный стандарт ISO/IEC 12207 (ISO — International Organization of Standardization — Международная организация по стандартизации, IEC — International Electrotechnical Commission — Международная комиссия по электротехнике). Он определяет структуру ЖЦ, содержащую процессы, действия и задачи, которые должны быть выполнены во время создания ПО.

Структура ЖЦ ПО по стандарту базируется на трех группах процессов:

* основные процессы ЖЦ ПО (приобретение, поставка, разработка, эксплуатация, сопровождение);

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

* организационные процессы (управление проектами, создание инфраструктуры проекта, определение, оценка и улучшение самого ЖЦ, обучение).

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

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

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

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

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

7.Каскадная модель жизненного цикла.

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

2-е модели: каскадная (70-85 гг.), спиральная (86-90гг.).

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

«+»: * на каждом этапе формируется законченный набор проектной документации, отвечающий критериям полноты и согласованности;

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

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

«-»: * существенное запаздывание с получением результатов;

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

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

8. Спиральная модель жизненного цикла.

В спиральной модели сделан упор на начальные этапы ЖЦ: анализ и проектирование.

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

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

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

9. Сравнение моделей жизненного цикла.

2-е модели: каскадная (70-85 гг.), спиральная (86-90гг.).

«-»: * существенное запаздывание с получением результатов;

В спиральной модели сделан упор на начальные этапы ЖЦ: анализ и проектирование.

1. В каскадной модели все этапы равноправные, в спиральной-акцент делается на первые этапы.

2. В каскадной на каждом этапе-полный комплект документации, в спир.-только после выпуска версии

3. В каск. модели пользователь учавствует на первом и последнем этапах разработки, в спир.-постоянно учавствует.

4. В каск. –жесткий график, в спир.-ограничения во времени

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

6. Каск. приемлема в сложных расчетных системах и системах реального времени.

7. В каск. переходы между этапами осуществляются в определенном порядке.

10.Общие требования к методологии и технологии.

Методологии и технологии и инструментальные средства проектирования ( case -средства) составляют основу проекта любой системы.

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

Технология проектирования определяется как совокупность 3-х составляющих:

1. Пошаговая процедура, определяющая последовательность технологических операций проектирования.

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

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

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

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

Технология проектирования должна удовлетворять следующим общим требованиям:

1. технология должна поддерживать полный жизненный цикл ПО.

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

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

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

5. должна обеспечивать min время получения работоспособной информационной системы.

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

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

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

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

11. Стандарты, разрабатываемые участниками проекта.

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

1) стандарт проектирования:

a) набор необходимых моделей на каждой стадии проек-ия и степень их детализации;

b) правила фиксации проектных решений на диаграммах(правила наимен. обьектов, набор атрибутов, правила оформл. диаграмм);

c) требования конфигурации РМ разработчиков;

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

2) стандарт оформления проектной документации:

a) комплексность, состав и структуру докум-ии на каждой стадии проек-ия, т.е. сод-ие разделов, таблиц и т.д.;

b) правила подготовки, согласования рассмотрения и утверждения документации с указанием предельных сроков для каждой стадии;

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

d) требования к настройке CASE -средств для обеспечения подготовки документации.

3) стандарт пользовательского интерфейса:

a) правила оформления экранов, состав и расположение окон и элементов управления

b) правила оформления текстов помощи;

c) перечень стандартных сообщений;

d) правила обработки реакции пользователя;

e) правила использования клавиатуры и мыши.

12. Принципы структурного подхода.

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

2 основных принципа: 1. разделяй и влавствуй — принцип решения сложных проблем путем их разбиения на множество мелких независимых задач, легких для понимания и решения. 2. принцип иерархического упорядочивания — принцип организации составных частей проблемы в иерархические древовидные структуры с добавлением новых деталей на каждом уровне.

Другие принципы: 3. принцип абстрагирования — заключается в выделении существенных аспектов системы и отвлечение от несущественных; 4. принцип формализации заключается в необходимости строгого методического подхода к решению проблемы; 5. непротиворечивости – обоснованность и согласованность элементов; 6. принцип структурирования данных — данные д.б. структурированы и иерархически организованны.

В структурном анализе используется две группы средств, иллюстрирующих функции, выполняемые системой и отношения между данными — 1. SADT — Structured Analysis and Design Technique 2. DFD-data Flowed Diagram. + ERD (Entity-Relationship Diagrams) диаграммы » сущность — связь «.

13. Методология функционального моделирования SADT

Разработана Дугласом Россом на ее основе разработана, в частности, методология IDEF 0- Integration Definition for Function Modeling . Данная методология является основной частью программы ICAM (интегрирования компют. и промышл. технологий). Разработано по инициативе ВВС США.

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

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

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

Правила SADT включают:

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

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

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

5. разделение входов и управлений, т.е. определение роли данных;

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

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

14. Особенности методологии IDEF 0.

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

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

Диаграммы – главные компоненты модели, все функции и интерфейсы на них представлены как блоки и дуги. Цель моделирования ( Purpose ). Модель не может быть построена без четко сформулированной цели. Цель должна отвечать на следующие вопросы: Почему этот процесс должен быть замоделирован? Что должна показать модель?

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

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

Взаимодействие работ между собой и внешним миром описывается в виде стрелок. Стрелки представляют собой некую информацию и именуются существительными (например, сырьё). В IDEF 0 различают пять типов стрелок:

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

Управление ( Control ) – правила, стратегии, процедуры или стандарты, которыми руководствуется работа. Каждая работа должна иметь хотя бы одну стрелку управления. Стрелка управления рисуется как входящая в верхнюю грань работы.

Выход ( Output ) – материал или информация, которые производятся работой. Каждая работа должна иметь хотя бы одну стрелку выхода. Работа без результата не имеет смысла и не должна моделироваться. Стрелка выхода рисуется как исходящая из правой грани работы.

Механизм ( Mechanism ) – ресурсы, которые выполняют работу. Стрелка механизма рисуется как входящая в нижнюю грань работы.

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

Любой процесс начинается с контекстной диаграммы. Название-глагол, или отглагольное существительное. Управление д.б. у каждой работы, выходы обязательны, входы и механизмы могут отсутствовать (их можно не показывать по договоренности) А-префикс работы, 0-самая верхняя работа. Декомпозиция.

Стрелки м.б. 1.выход-вход 2. выход-механизм 3. выход-управление 4. возврат. При декомпозиции А1:А11,А12,А13.Если разбить дальше:А121,А122.После функциональной модели нужно создать информационную модель. Для автоматизации продукции, для стоимостного анализа (цель).

15.Особенности методологии IDEF 3.

Данная методология описывает работы с точки зрения последовательности выполнения работ. Не имеет граней в отличие от IDEF 0. IDEF 3 представляет инструментарий для наглядного исследования и моделирования сценариев выполнения процессов. Метод позволяет проводить описание с необходимой степенью подробности посредством использования декомпозиции. IDEF 3 как инструмент моделирования фиксирует следующую информацию о процессе:

* Объекты, которые участвуют при выполнении сценария;

* Роли, которые выполняют эти объекты (например, агент, транспорт и т.д.);

* Отношения между работниками в ходе выполнения сценария процесса;

* Состояния и изменения, которым подвергаются объекты;

* Время выполнения и контрольные точки синхронизации работ;

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

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

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

Единицы работы – Unit of Work ( UOW ): также называемые работами, являются центральными компонентами модели. В IDEF 3 работы изображаются прямоугольниками с прямыми углами и имеют имя, обозначающим процесс действия, и номер (ид e нтификатор);

Связи показывают взаимоотношение работ. Все связи в IDEF 3 однонаправлены и могут быть направлены куда угодно, но обычно диаграммы IDEF 3 стараются построить так, чтобы связи были направлены слева направо.

Старшая ( Precedence ) – сплошная линия, связывающая единицы работ. Рисуется слева направо или сверху вниз. Показывает что работа — источник должна закончиться прежде, чем работа-цель начнется.

Отношения ( Relational Link ) – пунктирная линия, использующаяся для изображения связей между единицами работ (работа-цель начинается, когда работа-источник еще не закончилась), а так же между единицами работ и объектами ссылок.

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

В отличие от IDEF 0 и DFD в IDEF 3 стрелки могут сливаться или разветвляться только через перекрестки.

Есть логические переходы- перекрестки. Бывают трех типов: And -и, XOR — -либо, OR — -или. Бывают синхронные и асинхронные- , слияния и разветвления . X не может быть синхронным. , , , , ,

Объект ссылки Idef 3 может использоваться в имитационном моделировании. Можно перебросить в BP Simulator .

16. Особенности методологии DFD .

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

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

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

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

В отличие от стрелок IDEF 0, которые представляют собой жесткие взаимосвязи, стрелки DFD показывают, как объекты (включая данные) двигаются от одной работы к другой. Это представление потоков совместно с хранилищами данных и внешними сущностями делает модели DFD более похожими на физические характеристики системы – движение объектов, хранение объектов, поставка и распространение объектов.

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

Таким образом, основными компонентами диаграмм потоков данных являются:

* работы; * внешние сущности; * стрелки (потоки данных); * хранилище данных.

Появляется новый объект – внешняя сущность (внешняя организация, должность либо отдел организации, но кот-ые не выполняют описываемые функции).Внешние по отношению к функциям. стрелка может идти от отдела. Хранилище данных еще один объект. Могут выступать любые носители информации.

17. Жизненный цикл ПО по методологии RAD .

Одним из возможных подходов к разработке ПО в рамках спиральной модели ЖЦ является методология быстрой разработки приложений RAD (Rapid Application Development). Под данным термином подразумевается процесс разработки ПО, содержащих 3 основных элемента:

— небольшая команда программистов 2-10 чел;

— короткий, но тщательно проработанный график производственный 2-6 мес.;

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

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

1. анализ и планирование требований;

2. фаза проектирования;

3. фаза построения;

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

2. Часть пользователей принимает участие в техническом проект-ии сисетмы под руководством специалистов –разработчиков. CASE -средства исп. для быстрого получения прототипов приложений. Польз-ли уточняют и дополняют треб-ия к системе, к-ые не были выявлены на предыдущ. фазе. Более подробно рассматр. процессы системы. Корректируется функциональная модель. При необходимости для каждого элементарного процесса создается частичный прототип. Определяются треб-я разграничения доступа к данным. Определяется набор необ-ой документации. Принимается решение о разделении сис-мы на подсистемы, на каждую из которых отводиться 60-90 дней и результатом данной фазы д.б.:

* общая инф. модель сис-мы;

* определенные с пом. CASE -средств интерфейсы м/д автономно разрабатываемыми подсистемами;

* построены прототипы экранов, отчетов, диалогов с системой;

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

3. На этой фазе вып-ся непосредственно сама быстрая разработка приложения. Разр-ки производят итеративное построение реальной системы на основе моделей, получ. на пред. фазах; прогр. код частично формируется при помощи автомат. генераторов, кот-ые являются встроенной частью CASE -средств. А конеч. пользователи оценивают получаем. рез-ты и вносят коррективы на этой фазе. Тестирование системы осущ-ся непосредственно в процессе разработки. После окончания работ кажд. команды разр-ов произв. постепенное интегрир. данной части сис-мы с остальн. Формируется полный прогр. код, вып-ся тестирование совместной работы данной части приложения с остальными, а также сис-мы в целом. Завершается физич. проектирование системы:

1. определяется необходимость распределения данных;

2. произв-ся анализ исполь-я данных;

3. произв-ся физич. проектир. БД-ых;

4. определяется треб. к аппаратн.ресурсам;

5. определяется способы увелич. произ-сти;

6. завершается раз-ка документац. проекта ;

Результатом является готовая система, удолетворяющая всем соглас. требованиям.

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

Описание фаз не явл. абсолютным(вносятся коррективы).

18. Основные принципы методологии RAD

— небольшая команда программистов 2-10 чел;

— короткий, но тщательно проработанный график производственный 2-6 мес.;

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

1. Разработка приложений итерациями(спиральная модель жизненного цикла)

2. Необязательность полного завершения работ на каждом из этапов жизн.цикла

3. Обязательное вовлечение пользователей в процесс раз-ки ИС-мы

4. Необходимое применение CASE -средств, обеспечивающих целостность проекта

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

6. Использование генераторов кода

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

8. Тестирование и разв-е проекта осущ. одновременно с разработкой

9. Ведение работ немногочисленной, хорошо управляемой командой профес-ов 2-10чел

10. Короткий срок разработки 2-6 мес.

11. Грамотное руководство разработкой системы.Четкое планирование и контроль выполнения работ.

19. CASE -метод Баркера.

Целью моделирования данных является обепечение разработчика ИС-мы концептуальной схемой БД-ых в форме одной модели или нескольких локальных моделей, которые относительно легко м.б. отображены в любую систему баз данных. Наиболее распространенным средством для построения концептуальных схем БД явл-ся ERD -модели (сущность-связь). Нотация ERD впервые была введена Ченом, дальнейшее развитие получила в работах Баркера. Сущность ( Entity ) — реальный либо воображаемый объект, имеющий существенное значение для рассматриваемой предметной области, и информация о котором подлежит хранению. Изобр-ся в виде прямоугольника с закругленными краями, внутри пишется имя сущности .Каждая сущность должна иметь уникальное имя и к одному и тому же имени должна всегда применять 1 и та же интерпретация. Кажд. сущность д. обладать уникальн. идентификатором. Кажд. экземпляр сущности должен однозначно идентифицироваться и отличаться от всех остальныых экземпляров сущности. Сущность д.обладать 1 или неск.атрибутами, которые либо принадлежат сущности, либо наследуются через связь. И кажд. сущность может обладать любым количеством связей с др.сущностями модели.

1. Выделение сущностей(автомастерская)

2. Определение связей. Связь( Relationship ) — это поименованная ассоциация между 2-мясущности, значимая для рассматриваемой предметной области, при которой каждый экземпляр одной сущности, называемой родительской сущностью ассоциирован с произвольным, в том числе и нулевым кол-вом экземпляров 2-ой сущности, называемой сущностью-потомком(дочерней сущностью).А кажд. экземпляр сущности потомка ассоциирован в точности с одним экземпляром сущности родителя. Связи может даваться имя, выраженной грамматическим оборотом глагола и помещается возле линии. Имя связи между 2-мя сущностями д.б. уникальным, но имена связей в модели не обязаны быть уникальными. Имя связи формируется всегда с т.зр. родителя, так что предложение должно быть образовано соединением: имя сущности родителя, имя связи, выражение степени(кол-ва) и имени сущности потомка. Степень связи графически изобр. след. образом: -один, -много. Связь может быть обязательной и необязательной —-.

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

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

Дополнит.конструкции, кот. м.б. отражены в базе:

1. Подтипы и супертипы (одна сущность является обобщающим понятием для группы подобных сущностей). 2. Взаимоисключающие связи (подразумеваются кажд. экземпляр сущности учавствует только в 1 связи из группы взаимоисключающих связей. Если А вза-ет с С, то не вза-ет с В). 3. Рекурсивная связь (сущность м.б. связана сама с собой-пассажир м.б. одновременно водителем и наоборот).

Неперемещаемые (non-transferrable) связи: экземпляр сущности не может быть перенесен из одного экземпляра связи в другой.

20. Подход, используемый в CASE -средстве Vantage Team Builder .

В CASE-средстве Vantage Team Builder (Westmount I-CASE) используется один из вариантов нотации П. Чена. На ER-диаграммах сущность обозначается прямоугольником, содержащим имя сущности, а связь — ромбом, связанным линией с каждой из взаимодействующих сущностей. Числа над линиями означают степень связи.

Связи являются многонаправленными и могут иметь атрибуты (за исключением ключевых). Выделяют два вида связей:

* необязательная связь (optional);

* слабая связь (weak).

В необязат.связи м. участвовать не все экземпляры сущности . В полной связи участвуют все экземпляры хотя бы одной из сущностей. Полная связь м.б. 4-видов: -обязательная; — слабая; -супертип подтип; -ассоциативная.

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

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

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

Ассоциативная связь(связ между неск. независимыми сущностями и одной зависимой). Каждый экземпляр связи (ассоциативный объект-объект, являющийся одновременно и сущностью и связью) только при условии существования определенных экземпляров каждой из взаимосвязанных сущностей. Самолет выполняет посадку на взлетную полосу в заданное время при определенной скорости. Эти характеристики применимы только к конкр. посадке, то они явл. атрибутами сущности «посадка», а не самолета и взлетной полосы.

Правила, кот. д. подчинятся ER -диаграмма:

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

2. имя сущности д.б. уникальным в пределах моделей

3. имена атрибутов д.б. уникальны в рамках сущности

4. имена связей д.б. уникальны, если для них генерируется таблица БД

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

6. сущность в необязат. связи должна иметь ключевой атрибут

7. в ассоц. или слабой связи м.б. только 1 слабая сущность

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

21. Нормализация данных.

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

1 NF Бойса-Кодда. Сущность находиться в 1НФ, когда все арибуты содержат атомарные значения. Выделяем те атрибуты, кот. содержат неатомарные значения, создаем новые сущности. FK — flow key –мигрирующий ключ.

2 NF . Сущность находиться во 2НФ, если она уже нах. в 1НФ и каждый неключевой атрибут зависит от первичного ключа. Дата начала и окончания зависит от названия и независит от таб№.

2НФ позволяет избежать следующих аномалий при выполнении операций:

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

2. вставка (невозможно ввести данные о сотруднике, если он на данный момент не руководит никаким проектом)

3. удаление (если сотрудник временно прекращает работу с проектом, то данные о сотруднике теряются)

ЗНФ. Сущность находится в 3НФ, если она уже находиться во 2 НФ и никакой неключевой атрибут не зависит от другого неключевого атрибута. Неключевой атрибут «оклад» зависит от другого неключевого атрибута «должность». Аномалии при операциях:

1. обновление (дублируется информация о окладе, если одну и ту же должность занимают несколько сотрудников, если оклад измениться, то необходимо изменять несколько записей);

2. вставка (невозможно ввести данные об окладе соответствующей должности, если на данный момент нет сотрудника, который занимет эту должность);

3. удаление (если удаляем из таблицы сотрудника, занимающего уникальную должность, то данные об окладе теряются).

22. Диаграммы языка UML .

Unified Modeling Language , UML — язык для определения, представления, проектирования и документирования программных систем, а также для организационно-экон., технич. и др. систем. Стандарт UML предполагает след. набор диаграмм:

1. диаграмма вариантов использования ( use cased ) — Данная диаграмма предназначена для моделирования бизнес-процессов организаций и требований к создаваемой системе;

2. диаграмма класса class diagram для моделирования статической структуры классов системы и связей между ними.

3. диаграммы поведения системы behavior diagrams которые подразделяются на:

a. диаг. последовательности sequence diagr ;

b. кооперативные диаграммы collaboration diag . Эти диаг. служат для моделирования процесса обмена сообщениями между объектами. Вместе а и б называются диаграммы взаимодействия ( interaction diagram );

c. диаграммы состояний statechart diagram для моделирования поведения объектов системы при переходе из 1 сост. в др;

4. диаграммы реализации implementation diag.

a. диаграммы компонентов ( component diag ) для моделирования иерархии компонентов системы;

b. диаграммы размещения ( deployment diag ) для моделирования физич. архитектуры системы;

23. Диаграммы ваиантов использования.

Use cased diagr . Впервые это понятие ввел Ивар Якобсон и представляет собой последовательность действий (транзакций), выполняемых системой в ответ на события, инициируемые некоторым внешним объектом (действующее лицо). Вариант использования превратился в основной элемент разработки и планирования проекта. Вариант использования описывает взаимодействия между польз-ем и ситемой. Действующее лицо (актер) — это роль, кот-ую поль-ль играет по отношению к системе. Действ. лица предст. Из себя роль, а не конкр. людей или наименования работ. Действ. лицо также м.б. внешней системой, кот. необходима некоторая информация от данной системы, а также действующим лицом может выступать время, если от него зависит запуск каких-либо событий в системе.

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

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

Связь расширения применяется при описании изменений в нормальном поведении системы.

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

Разраб.диаграммы д. придерживаться след. правил:

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

2. Не соед-ся коммуник. связью 2 варианта использовния непосредственно. Диаграмма вар-ов исп. описывает только те варианты, кот. допустимы в ситеме, а не их последовательность.

3. Каждый вариант исп. д.б. инициирован действ. лицом

Каждый вар.исп. д.б. описан в документе «поток событий». Целью явл. документирование процесса обработки данных, реализуемого в рамках варианта исп. Докк-ент опис. что будет делать система, а что пользователь. Описание не должно зависеть от реализации. Данный документ вкл. в себя: 1. краткое описание 2. предусловия, кот. д. выполнятся перед запуском вар-та использования 3. основной поток событий 4. альтернативный поток событий 5. постусловия. 1. пр:для варианта использования перевести деньги 2. предусловия-условия, к-ый д.б. выполнены прежде чем вариант исп-ия начнет выполнятся сам. Напр: вып. др. вар. исп.: наличие прав пол-ля. Не у всех вар. исп. есть предусловия.

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

Чтобы фактически разработать систему, однако, потребуются более конкретные детали. Эти детали описываются в документе, называемом «поток событий» (flow of events). Целью потока событий является документирование процесса обработки данных, реализуемого в рамках варианта использования. Этот документ подробно описывает, что будут делать пользователи системы, и что — сама система. Хотя поток событий и описывается подробно, он также не должен зависеть от реализации. Цель — описать, что будет делать система, а не как она будет делать это. Обычно поток событий включает:

* основной поток событий;

* альтернативный поток событий (или несколько альтернативных потоков);

24. Связи в диаграмме вариантов использования.

В языке UML на диаграммах вариантов использования поддерживается несколько типов связей между элементами диаграммы. Это связи коммуникации (communication), включения (include), расширения (extend) и обобщения (generalization). Связь коммуникации – это связь между вариантом использования и действующим лицом. На языке UML связи коммуникации показывают с помощью однонаправленной ассоциации (сплошной линии со стрелкой). 1. communication связь коммуникаций 2. include св. включения 3. extend св. расширения 4. generalization св. обобщения. Первая связи м/д действующим лицом и вариантом использования показывает простую инициализацию вариантов использования(наиболее частая). Вторая применяется в тех сл-ях, когда имеется к/л фрагмент в поведении системы, который повторяется более чем в одном варианте использования. Третий применяется при описании изменений в нормальном поведении системы. Данная связь позволяет варианту использования только при необходимости использовать функциональные возможности другого. Четвертая показывает что у нескольких действ. лиц есть общие черты. Данная связь необходима когда поведение д. лица одного типа отличается от поведения другого, если это затрагивает саму систему. Данная диаграмма строится на стадии формирования требований к ПО, и пока эти требования не выявлены к реализации не приступают.

25. ДИАГРАММЫ ВЗОИМОДЕЙСТВИЯ.

Диаграммы взаимодействия (interaction diagrams) описывают поведение взаимодействующих групп объектов. Как правило, диаграмма взаимодействия охватывает поведение объектов в рамках только одного варианта использования. На такой диаграмме отображается ряд объектов и те сообщения, которыми они обмениваются между собой.

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

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

Сообщение — запрос (interrogative) — это сообщение, запрашивающее выдачу некоторой информации об объекте — получателе.

Императивное (imperative) сообщение — это сообщение, запрашивающее у объекта — получателя выполнение некоторых действий.

Существует два вида диаграмм взаимодействия: диаграммы последовательности (sequence diagrams) и кооперативные диаграммы (collaboration diagrams).

— описывает поведение взаимодействующих гр об-в и охватывает поведение об-в в рамках только 1-го вар-а исп-ия. На этой диаграмме отображ-я бо-ы и сообщения, кот они обмениваются. Сообщения – средство, с пом кот-о об – отправитель запрашивает об – получателя выполнения одной из его операций. Сообщения м.б.: 1.Информ-ое-снабжающее об-получ нек-й инфой для обнов-я его сост-я;2.Сообщ-е — запрос – сообщ-е запрашивающее нек-ю инфу об об-те — получ-е ; 3. Императивное – сообщение запраш-е у об — получателя вып-я нек-х действий.

26. Диаграмма классов. Стериотипы классов. Мех-ы пакетов

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

Каждый класс на диаграмме выглядит в виде прямоугольника, разделенного на три части. В первой содержится имя класса, во второй – его атрибуты. Классы имеют стереотипы – мех-зм, позволяющий раздел-ть их на категории, 3 осн-х стереотипа: 1. Boundary (граница);2. Entity (сущность);3. Control (управление). Граничными классами наз-я такие, кот располож на границе системы и всей окр среды и каждому взоимодействию меж действ ицом и вар исп-я д.б. хотя бы 1 гран-й класс.

Пакеты применяются чтобы сгруппир. классы, облад. некот. общностью: B — boundery ; C — control ; E — entity ;

27. Диаграммы классов. Класс. Атрибуты.

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

Верх секция сод-т имя класса, имя класса пиш. с прописн. буквы, а если сост из 2 слов и второе тоже пишестся с прописной. Во второй секции записываются атрибуты. Если имя состиз неск-х слов, то слова объед-ся и каждое слово, за искл первого пиш-я с прописной буквы. В 3-й секции орерации – сущ-ть опред-яя нек-е действ-я кот м.б. вып-ы представителем класса или над ним.. Классы – суч-ти содержат хранимую инфу и имеют наиб знач-е для польз-ля, управ-ие классы отвечают за коорд действ др классов. У каждого вар исп-я д.б. хотябы 1 упр-й класс, кот отвечает за координацию, но несет в себе ни какой F -ти, а посылает на ХУЙ множ-о сообщений БЛЯЯ. Т.к. атрибуты нах-ся внутри классов, то они скрыты от др классов и в связи с этим необходимо указ-ть какие классы имеют право искать и измен-ть атрибуты; это св-во наз-ся видимость атрибута: 1. Public (предполагает что атр виден всем остальным, а также отер для измен-я);2. Private (Закр, Секретный; не виден ни каким др классам и чтобы его изменить др класс д. запросить разреш на измен-ие);3. Protected (Защищаемый; доступен только самомы классу и его потомкам);4. Pacage or implementation (пакетный; яв-ся общим в приделах пакета)

28. Диаграмма классов.Операции.

Диаграмма классов определяет типы классов системы и различного рода статистические связи, которые существуют м/д ними. Операции реализуют связ-е с классом поведение вкл в себя: 1.Имя;2.Параметры;3.Тип возвращаемого значения. Различают 4 типа операций: 1.Реализации (реализ-т нек бизнес f -ии);2.Управления(упр-ет создание и уничт-м об-в);3.Доступа;4.Вспом-ые(необход-е классу для вып-ия его ответственности, но о кот-х др классы не должны ни чего знать)

29-30. Базовые принципы ООП(ассоциации, наследование, зав-ть, агрегация)

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

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

Наследование – класс может не иметь родителей, в эт. сл-е он базовый или корневой. Класс, который не имеет дочерних классов – листовой. Если класс имеет 1го род. то говорят об одном наследовании, если неск. – о множественном.

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

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

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

Передача сообщений. 1об. посыл. сообщ. о необх-ти выполнить к-л опер. другому об. а принявший выполняет данную ф-ю.

Принцип Ассоциации.определяет нек. связь м/д об-ми. Ас. может быть однонаправленной и 2-направл-й, иногда ассоц. м/д 2-мя классами должна удовлетвор. правилу – ограничение, помещ. вдоль линии ассоц. Кратность связи: 0..*-ноль или много;1..*-один или много; 0..1-ноль или один; 1-один. Атрибут ассоциации – квалификатор.

Агрегирование. это отношение м/д классами типа целое-часть.

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

Зависимость. В некоторых сл-ях 2 или более элементов модели м.б. синаптически связаны.

31. Диаграмма состояний.

Rational Rose — CASE-средство фирмы Rational Software Corporation (США) — предназначено для автоматизации этапов анализа и проектирования ПО, а также для генерации кодов на различных языках и выпуска проектной документации.

Диаграммы состояний ( State chart Diagram ) определяют все возможные состояния, в которых может находиться конкретный объект, а также процесс смены состояний объекта в результате наступления некоторых событий. На диаграмме имеются два специальных состояния – начальное (start) и конечное (stop). Начальное состояние выделено черной точкой, оно соответствует состоянию объекта, когда он только что был создан. Конечное состояние обозначается черной точкой в белом кружке, оно соответствует состоянию объекта непосредственно перед его уничтожением. На диаграмме состояний может быть одно и только одно начальное состояние. В то же время, может быть столько конечных состояний, сколько вам нужно, или их может не быть вообще. Когда объект находится в каком-то конкретном состоянии, могут выполняться различные процессы.

Процессы, происходящие, когда объект находится в определенном состоянии, называются действиями (actions). С состоянием можно связывать данные пяти типов: деятельность, входное действие, выходное действие, событие и история состояния.

Деятельностью (activity) называется поведение, реализуемое объектом, пока он находится в данном состоянии. Деятельность – это прерываемое поведение. Оно может выполняться до своего завершения, пока объект находится в данном состоянии, или может быть прервано переходом объекта в другое состояние.

Входным действием (entry action) называется поведение, которое выполняется, когда объект переходит в данное состояние. Таким образом, данное действие осуществляется не после того, как объект перешел в это состояние, а, скорее, как часть этого перехода. В отличие от деятельности, входное действие рассматривается как непрерываемое.

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

Поведение объекта во время деятельности, при входных и выходных действиях может включать отправку события другому объекту: Do: ^Цель .Событие (Аргументы )

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

Переходом (Transition) называется перемещение из одного состояния в другое. Совокупность переходов диаграммы показывает, как объект может перемещаться между своими состояниями.

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

Ограждающие условия (guard conditions) определяют, когда переход может, а когда не может осуществиться.

32. Диаграмма компонентов и размещения.

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

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

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

Можно выбирать: Processor (Процессор), Device (Устройство), Connection (Связь).

33. Основные этапы развития UML .

Отдельные языки О-О моделирования стали появляться в середине 70- кон.80х гг.

В 90-е гг.их общее число возросло до 50-ти. Это вызвало трудности для пользователей при выборе языка О-О анализа и проектирования т.к. ни один из них не удовлетворял всем требованиям, предъявляемым к построению моделей сложных систем. Были приняты отдельные методики и стандарты, но это не изменило ситуации, которая носила название «война методов». К сер.90-х гг. самыми известными методами стали:

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

* метод Рамбо: который подходил для анализа процесов боработки данных в ИС;

* метод Джейкобсона: содержал средства представления вариантов использования, которые необходимы на этапе анализа требований в процессе проектирования бизнес-приложений.

Rational Rose использует синтез-методологию объектно-ориентированного анализа и проектирования, основанную на подходах трех ведущих специалистов в данной области: Буча, Рамбо и Джекобсона. Разработанная ими универсальная нотация для моделирования объектов (UML — Unified Modeling Language) претендует на роль стандарта в области объектно-ориентированного анализа и проектирования.

Язык УМЛ начал развиваться в 1994 году в октябре, когда Буч и Рамбо (Румбах) начали унификацию своих методов. 1-ая версия была опубликована в окт.1995 г., когда к ним присоединился Джекобсон. Данную разработку поддержаи Oracle , MS , IBM . В резльтате в 1998 г . Была представлена окончательная версия ПП Rational Rose .

Термин «У» — унифицировать, в названии УМЛ имеет 2-а аспекта:

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

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

34. Общая структура языка UML . Назначение языка.

Rational Rose – семейство объектно-ориентированных CASE-средств фирмы Rational Software Corporation – предназначено для автоматизации процессов анализа и проектирования ПО, а также для генерации кодов на различных языках и выпуска проектной документации. Rational Rose использует метод объектно-ориентированного анализа и проектирования, основанный на языке UML.

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

* снабдить исходные понятия языка УМЛ возможностью расширения и специализации для более точного представления в конкретной предметной области;

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

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

Описание языка сосотит из 2-х частей:

— семантика: представляет собой некоторую метамодель, которая определяет абстрактный синтаксис и семантику понятий объектного моделирования на языке УМЛ.

— нотации: графическая нотация для визуального представления семантики языка УМЛ;

Описание языка УМЛ имеет иерархическую структуру модельных представлений (4 уровня):

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

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

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

4) пользовательские объекты: определенные объекты конкретной предметной области.

35.Определение потребностей в CASE-средствах (анализ возможностей организации, определение организационных потребностей, анализ рынка CASE-средств).

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

Определение потребностей в CASE-средствах

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

Формальные подходы определяются моделью оценки зрелости технологических процессов организации CMM (Capability Maturity Model), разработанной SEI (Software Engineering Institute), а также стандартами ISO 9001: 1994, ISO 9003-3: 1991 и ISO 9004-2:1991. В центре внимания этих подходов находится анализ различных аспектов происходящих в организации процессов.

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

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

Готовность: Целью оценки готовности организации является определение того, насколько она способна воспринять как немедленные, так и долгосрочные последствия внедрения CASE-средств.

Персонал: Главной целью оценки персонала является определение его отношения к возможным изменениям (позитивного, нейтрального или негативного).

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

Проекты, ведущиеся в организации; Общие вопросы.

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

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

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

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

36.Определение потребностей в CASE-средствах (определение критериев успешного внедрения, разработка стратегии внедрения CASE-средств).

Определение потребностей в CASE-средствах

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

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

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

* согласованность проектных результатов;

* точность стоимостных и плановых оценок;

* изменчивость внешних требований;

* соблюдение стандартов организации;

* степень повторного использования существующих компонентов ПО;

* объем и виды необходимого обучения;

* типы и моменты обнаружения проектных ошибок;

* вычислительные ресурсы, используемые CASE-средствами.

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

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

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

* подразделения организации, в которых должно выполняться внедрение CASE-средств;

* влияние, оказываемое на другие подразделения организации;

* стратегии и планы оценки и выбора, пилотного проектирования и перехода к полномасштабному внедрению;

* основные факторы риска;

* ориентировочный уровень расходов и источники финансирования процесса внедрения CASE-средств;

* ключевой персонал и другие ресурсы.

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

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

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

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

* небольшая автоматизация может быть выполнена при минимальных затратах;

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

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

37.Оценка и выбор CASE-средств.

Цели процесса оценки и выбора:

* оценка нескольких CASE-средств и выбор одного или более из них;

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

* выбор одного или более CASE-средств с использованием результатов предыдущих оценок.

Как видно из рисунка, входной информацией для процесса оценки является:

* определение пользовательских потребностей;

* цели и ограничения проекта;

* данные о доступных CASE-средствах;

* список критериев, используемых в процессе оценки.

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

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

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

* выбор критериев для использования из приведенного далее перечня;

* определение дополнительных критериев;

* определение области использования каждого критерия (оценка, выбор или оба процесса);

* определение одной или более метрик для каждого критерия оценки;

* назначение веса каждому критерию при выборе.

38. Критерии оценки и выбора.

Оценка и выбор CASE-средств:

Цели процесса оценки и выбора:

* оценка нескольких CASE-средств и выбор одного или более из них;

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

* выбор одного или более CASE-средств с использованием результатов предыдущих оценок.

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

* определение пользовательских потребностей;

* цели и ограничения проекта;

* данные о доступных CASE-средствах;

* список критериев, используемых в процессе оценки.

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

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

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

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

В процессе выбора возможно получение двух результатов:

* рекомендаций по выбору конкретного CASE-средства;

* запроса на получение дополнительной информации к процессу оценки.

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

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

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

* двоичные меры (истина/ложь, да/нет), например, способность генерации документации в формате Postscript;

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

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

Функции, ориентированные на фазы жизненного цикла:

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

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

39. Определение характеристик пилотного проекта.

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

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

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

Функция П.ПР.: принятие решения относительно приобретения или отказа от использования CASE-средства.

П.Пр. должен обладать следующими хар-ами:

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

Масштабируемость. Результаты, полученные в П.Пр., должны показать масштабируемость средства. Цель — получить четкое представление о масштабах проектов, для которых данное средство применимо.

Шаги пилотного проекта

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

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

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

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

Организация должна учитывать продолжительность пилотного проекта (и в целом процесса внедрения). Слишком продолжительный проект связан с риском потери интереса к нему со стороны руководства.

40. Планирование и выполнение пилотного проекта.

Функция П.ПР .: принятие решения относительно приобретения или отказа от использования CASE-средства.

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

* цели, задачи и критерии оценки; * персонал; * процедуры и соглашения; * обучение; * график и ресурсы.

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

* описать проект в терминах ожидаемых результатов (т.е. конечного продукта). Описание должно включать форму представления и содержание результатов. Должны быть четко определены договорные требования и соответствующие стандарты.

* определить общие цели проекта. Примером цели м.б. определение степени улучшения качества проектной документации в результате применения CASE-средств.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

41. Оценка пилотного проекта.

Функция П.ПР .: принятие решения относительно приобретения или отказа от использования CASE-средства.

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

В процессе оценки П.Пр. организация должна определить свою позицию по трем вопросам: Целесообразно ли внедрять CASE-средство? Какие конкретные особенности П.Пр. привели к его успеху (или неудаче)? Какие проекты или подразделения в организации могли бы получить выгоду от использования средств?

Принятие решения о целесообразности внедрения CASE-средств:

На данном этапе процесса внедрения организация должна сделать существенные инвестиции в CASE-средства. Если средства удовлетворили или даже превысили ожидания организации, то решение о внедрении м.б. принято достаточно просто и быстро.

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

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

Выгода от использования CASE-средств:

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

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

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

Принятие решения о внедрении: Возможным решением должно быть одно из следующих:

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

Выполнить дополнительный П.Пр ., если остались конкретные неразрешенные вопросы относительно внедрения CASE-средства в организации. Новый П.Пр. должен быть таким, чтобы ответить на эти вопросы.

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

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

42. Переход к практическому использованию CASE -средств.

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

Разработка плана перехода: должен включать следующее:

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

* Информацию относительно приобретения, установки и настройки CASE-средств.

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

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

* Определение стандартных процедур использования средств.

Цели, критерии оценки, график и риски, связанные с планом перехода

Данная информация должна включать следующее:

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

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

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

* Возможные риски и непредвиденные обстоятельства.

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

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

Приобретение, установка и настройка средств

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

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

* Механизм получения новых версий.

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

* Лицо или подразделение, ответственное за установку, интеграцию, настройку и эксплуатацию средства.

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

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

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

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

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

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

* Виды и доступность поддержки.

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

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

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

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

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

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

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

Чтобы определить, насколько эффективно новое CASE-средство повышает продуктивность и/или качество, организация должна опираться на некоторые базовые данные. Использованное время, Время, выделенное персонально для конкретных специалистов, Размер, сложность и качество ПО, Удобство сопровождения.

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

Результатом данного этапа является внедрение CASE-средств в повседневную практику организации, при этом больше не требуется какого-либо специального планирования. Кроме того, поддержка CASE-средств включается в план текущей поддержки ПО в данной организации.

43. Реинжиниринг бизнес-процессов.

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

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

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

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

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

Рассмотрим, как реинжиниринг изменяет реконструируемые бизнес-процессы.

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

44. Реинжиниринг. Что не является реинжинирингом.

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

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

45. Сравнительные характеристики методологий структурного моделирования.

1) С точки зрения функциональности системы. В рамках методологии IDEFO (Integration Definition for Function Modeling) бизнес-процесс представляется в виде набора элементов-работ, которые взаимодействуют между собой, а также показывается информационные, людские и производственные ресурсы, потребляемые каждой работой.

2) С точки зрения потоков информации (документооборота) в системе. Диаграммы DFD (Data Flow Diagramming) могут дополнить то, что уже отражено в модели IDEF3, поскольку они описывают потоки данных, позволяя проследить, каким образом происходит обмен информацией между бизнес-функциями внутри системы. В тоже время диаграммы DFD оставляют без внимания взаимодействие между бизнес-функциями.

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

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

DFD – диаграммы потоков данных

Диаграммы потоков данных ( Data flow diagramming , DFD ) используются для описания документооборота и обработки информации.

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

Метод описания процессов IDEF 3

Диаграммы IDEF 3 могут быть использованы в моделировании бизнес – процессов для анализа завершенности процедур обработки информации. С их помощью можно описывать сценарии действий сотрудников организации.

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

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

В отличие от IDEF 0 и DFD в IDEF 3 стрелки могут сливаться или разветвляться только через перекрестки.

46. Структура ИС.

Структура ИС — совокупность отдельных частей информационной системы, необходимых подсистемам.

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

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

Документацию можно разделить на 3 группы:

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

* Специализированная, соединяющая комплекс методик по всем этапам разработки технического обеспечения;

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

Все ПО делятся на 3 группы:

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

* Специализированное – совокупность программ, разработанных при создании конкретной ИС.

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

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

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

Источник

Особенности современных крупных проектов ис

Характерные особенности современных крупных проектов ИС

Информационная система