Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
ГОСЫ / Proektirovanie_informatsionnykh_sistem_Logunova.doc
Скачиваний:
199
Добавлен:
15.02.2016
Размер:
277.5 Кб
Скачать
  1. Определение жизненного цикла программного обеспечения. Этапы ЖЦПО. Модели ЖЦПО.

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

    К подсистемам ИС относятся:

  • Технические средства;

  • Средства связи;

  • Программное обеспечение.

    Технические средства - средства, на физическом уровне обеспечивающие ввод, хранение, обработку и вывод информации. Состав: модемы, Hub`ы, сетевые карты, винчестеры, CD, DVD, сканеры, принтеры, плоттеры, клавиатуры и т.д. Особенности: в большинстве своем технические средства унифицированы и не подлежат настройке под конкретную ИС

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

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

  • Системное ПО (операционная система, драйверы технических средств и средств связи)

  • Системы управления базами данных СУБД (Microsoft SQL Server, InterBase, Firebird и другие);

  • База данных-БД;

  • Клиентское ПО (программа или совокупность программ, обеспечивающих ввод, извлечение, обработку информации из БД, а также ее представление в необходимом виде).

    Особенности: Системное ПО и СУБД унифицированы и не подлежат внутреннему перепроектированию под конкретную ИС. Клиентское ПО и БД проектируются и настраиваются на решение специфических задач отдельных ИС.

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

ЖЦ ПО– это период времени от момента принятия решения о создании ПО до полного изъятия его из эксплуатации.

Этапы ЖЦПО:

1)Анализ требований заказчика.

2)Анализ рынка.

3)Анализ рисков.

4)Формализация требований.

5)Проектирование.

6)Разработка.

7)Тестирование.

8)Отладка.

9)Ввод в действие.

10)Эксплуатация и сопровождение.

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

Главная особенность индустрии ПО состоит в концентрации сложности на начальных этапах ЖЦ (анализ, проектирование) при относительно невысокой сложности и трудоемкости последующих этапов. Более того, нерешенные вопросы и ошибки, допущенные на этапах анализа и проектирования, порождают на последующих этапах трудные, часто неразрешимые проблемы и, в конечном счете, приводят к неуспеху всего проекта. Рассмотрим эти этапы более подробно. АНАЛИЗ ТРЕБОВАНИЙ является первой фазой разработки ПО, на которой требования заказчика уточняются, формализуются и документируются. Фактически на этом этапе дается ответ на вопрос: "Что должна делать будущая система?". Список требований к разрабатываемой системе должен включать:

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

  2. Описание выполняемых системой функций;

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

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

  1. Архитектура системы, ее функции, внешние условия, распределение функций между аппаратурой и ПО;

  2. Интерфейсы и распределение функций между человеком и системой;

  3. Требования к программным и информационным компонентам ПО, необходимые аппаратные ресурсы, требования к БД, физические характеристики

ЭТАП ПРОЕКТИРОВАНИЯ дает ответ на вопрос "Как (каким образом) система будет удовлетворять предъявленным к ней требованиям?". Задачей этого этапа является исследование структуры системы и логических взаимосвязей ее элементов, причем здесь не рассматриваются вопросы, связанные с реализацией на конкретной платформе. Проектирование определяется как итерационный процесс получения логической модели системы вместе со строго сформулированными целями, поставленными перед нею, а также написания спецификаций физической системы, удовлетворяющей этим требованиям". Обычно этот этап разделяют на два подэтапа:

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

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

В результате деятельности на этапах анализа и проектирования должен быть получен проект системы (ПС), содержащий достаточно информации для реализации системы на его основе в рамках бюджета выделенных ресурсов и времени. (ПС - совокупность документов, содержащий необходимую и достаточную информацию для реализации системы. Одним из основных документов которого является техническое задание) ЭТАП КОДИРОВАНИЯ (ПРОЕКТИРОВАНИЯ) - этап программной реализации требований заказчика. Осуществляется на основе технического задания полученного на предыдущем этапе. В виду того, что техническое задание содержит необходимую и достаточную информацию по реализации проекта, техникам - программистам остается немного места для творчества. Однако необходимо отметить, что выбор средств реализации ПО может зависеть от пожеланий заказчика, указаний руководителей проекта, либо от самого программиста. ТЕСТИРОВАНИЕ И ОТЛАДКА - этап итоговых проверок ПО на предмет содержания несоответствий:

  1. Требований заказчика и итоговой реализации ПО;

  2. Итоговой реализации ПО и технического задания;

  3. Действительной работоспособности алгоритмов в итоговой реализации ПО.

Модели ЖЦ:

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

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

Достоинства:

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

  • легкая передача проекта от одной группы разработчиков к другой.

Недостатки:

  • модель не работает в связи с наличием обратных связей;

  • затягивание процесса по времени.

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

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

Достоинство:межэтапные корректировки обеспечивают меньшую трудоемкость по сравнению с каскадной моделью.

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

3. спиральная модель – переход с одной стадии на другую происходит по истечении времени, независимо от завершенности процесса.

Недостатки:

  • неоконченность пакетов документов на каждой стадии;

  • большое количество копий.

Можно отметить следующие преимущества спиральной модели:

  • Накопление и повторное использование программных средств, моделей и прототипов;

Ориентация на развитие и модификацию ПО в процессе его проектирования;

  • Анализ риска и издержек в процессе проектирования.

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

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

Т.е. эта модель делает упор на начальные этапы ЖЦ:

  • анализ требований;

  • проектирование спецификаций;

  • предварительное проектирование;

  • детальное проектирование.

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

  1. Нет такого вопроса. Определение структурного анализа. Основные принципы структурного анализа.

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

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

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

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

  • спецификация системы из-за объема и технических терминов часто непонятна для заказчика;

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

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

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

  • ограниченный контекст, включающий лишь существенные на каждом уровне детали;

  • дуальность данных и операций над ними;

  • использование строгих формальных правил записи;

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

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

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

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

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

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

  5. Принцип полнотызаключается в контроле на присутствие лишних элементов.

  6. Принцип непротиворечивостизаключается в обоснованности и согласованности элементов.

  7. Принцип логической независимостизаключается в концентрации внимания на логическом проектировании для обеспечения независимости от физического проектирования.

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

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

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

Соблюдение указанных принципов необходимо при организации работ на начальных этапах ЖЦ независимо от типа разрабатываемого ПО и используемых при этом методологий.

Точка зрения – взгляд на систему специалиста ответственного за систему в целом.

  1. Понятие бизнес модели. Этапы построения бизнес модели. AS IS модели, SHOULD BE модели, TO BE модели.

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

Цели построения бизнес моделей.

Бизнес-модели как правило строятся с двумя целями:

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

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

При переходе от модели AS-IS к модели TO-BE необходимо зафиксировать точку зрения и не менять ее в процессе проектирования.

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

Этапы построения бизнес - модели

  1. Построение структурной модели БП Структурная модель - модель БП описывающая номенклатуру (список) подпроцессов, отношения между ними а также алгоритмы преобразования ресурсов в продукцию. Для проектирования структурной модели бизнес-процессов существует большое количество специальных методологий, к ним относятся нотации IDEF0, IDEF3, DFD, ARIS VAD, ARIS eEPC и другие(более подробную информацию см. далее) Среди разработчиков бизнес моделей наибольшее распространение получили следующие языки структурного моделирования - IDEF0, DFD и IDEF3, позволяющие анализировать бизнес-процесс с трех ключевых точек зрения:

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

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

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

  • Построение модели данных Модель данных - совокупность логической и физической моделей данных;

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

    • Построение физической модели данныхФизическая модель данных содержит информацию о всех объектах базы данных (Реализация логической модели данных применительно к конкретной СУБД)

    Для проектирования моделей данных бизнес-процессов используется язык моделирования IDEF1X