Эволюция программных систем 1 страница

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

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

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

3. Этап разработки ПО - проектирование и реализация (кодирования). Программирование и отладка ИС.

Согласно словарю Даля слово “проект” толкуется так:

ПРОЕКТ (лат) – план, предположение, задуманное дело, или само изложение этого плана на письме или в чертеже.

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

Проект – это ограниченное временем и финансированием создание или изменение системы с заранее определенными целями в рамках конкретной организационной структуры.

Вообще проект понятие сложное и поэтому дать полное и исчерпывающее его определение проблематично.

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

Проектирование бывает оригинальным и типовым.

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

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

Типовое проектирование означает создание очередной модификации готового ПП(продукта).

Пропущены один или все начальные этапы жизненного цикла.

Рис.1. Этапы жизненного цикла ИС

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

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

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

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

4. Проблемы сбора требований, формирование требований, их специфицирование и аттестация.

Требование - это:

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

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

Проблемы сбора требований

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

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

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

3. Для корректного формирования требований необходимо знать методы их сбора

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

Методы описания требований

Как уже говорилось, главной проблемой формирования требований является взаимопонимание между пользователями и разработчиками. Язык UML был специально создан для обеспечения связи между участниками проекта. Некоторые аспекты языка нацелены на установку связи между потребителями и разработчиками; другие — на общение проектировщиков системы и разработчиков баз данных; третьи — на связи между разработчиками, создающими разные части системы. Предлагая набор хорошо определенных диаграмм и точно определенные пояснения к ним, UML позволяет всем членам команды в любой момент понимать, что происходит в системе, и сводит к минимуму риск неправильного понимания. Де факто данный язык уже является стандартом при проектировании ИС.

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

Более того, этот язык ориентирован не только на этап анализа (описания требований), но и на этап синтеза разработки проекта ИС.

Основные положения языка приведены в приложении А.

Спецификация требований

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

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

Аттестация требований

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

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

1. Проверка правильности требований. Пользователь может считать, что сис

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

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

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

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

2. Проверка на непротиворечивость. Спецификация требований не должна

содержать противоречий. Это означает, что в требованиях не должно быть

противоречащих друг другу ограничений или различных описаний одной и

той же системной функции.

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

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

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

5. Формирование и анализ требований. Классификация требований.

Формирование требований.

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

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

Более того, этот язык ориентирован не только на этап анализа (описания требований), но и на этап синтеза разработки проекта ИС.

Функциональные и нефункциональные требования

Требования к программной системе классифицируются как функциональные и нефункциональные.

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

Системные (нефункциональные) требования. Описывают характеристики

системы и ее окружения, а не поведение системы. Здесь также может быть при-

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

Все системные требования можно разбить на три большие группы.

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

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

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

6. Технологии выявления требований: опорные точки зрения, сценарии, прототипирование.

Методы сбора требований

Для достижения лучшего понимания потребностей пользователя надо хорошо изучить предметную область.

Для этого используются:

Интервьюирование и анкетирование Мозговой штурм и отбор идей Сценарии (прецеденты) Прототипирование Обыгрывание ролей

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

Интервьюирование и анкетирование

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

1) Обычные клиенты банка, пользующихся услугами банкоматов.

2) Представители других банков, имеющих взаимные соглашения с данным

банком о совместном использовании банкоматов.

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

4) Сотрудники филиалов банка, вовлеченные в повседневную работу системы банкоматов, обрабатывающие рекламации клиентов и т.д.

5) Администраторы баз данных, ответственные за связь банкоматов с базой данных клиентов.

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

7) Отдел маркетинга банка, использующий систему банкоматов как средство маркетинга.

8) Разработчики аппаратных и программных средств, ответственные за сопровождение и модернизацию аппаратных и программных средств.

Сценарии.

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

1. Описание состояния системы в начале сценария.

2. Описание нормального протекания событий.

3. Описание исключительных ситуаций и способов их обработки.

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

5. Описание состояния системы после завершения сценария.

Прототипирование.

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

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

7. Спецификация требований. Разделы спецификации, ее значение в разработке проекта. Документирование спецификации требований.

Спецификация требований

Учитывая, что системе будут предъявлены сотни, если не тысячи, требований (например, при разработке системы управления самолетом Боинг 777 было 300 000 требований), очень важно организовать их. Поскольку невозможно удерживать в памяти более нескольких десятков фактов, для успешного взаимодействия различных участников процесса, необходимо обеспечить документирование требований. Требования следует записать так, чтобы они были доступны для ознакомления; это может быть документ, модель, база данных или листок на доске объявлений. Документ, содержащий упорядоченное множество требований называется спецификацией.

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

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

----

Техническое задание

Этап анализа проекта заканчивается разработкой ТЗ.

Наиважнейшим начальным этапом проектирования ИС является разработка техническое задание (ТЗ).

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

Стандарт 19.201-78 устанавливает порядок построения и оформления технического задания на разработку программного обеспечения (ПО).

ТЗ – основной документ, который сопровождает проект от его начала до его завершения.

Только после подписания ТЗ начинаются работы над проектом и финансирование.

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

ТЗ подписывается руководством заказчика и разработчика.

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

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

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

После окончания работы над ТЗ начинается этап проектирования.

8. Классификация нефункциональных требований: требования к ИС, организационные требования, внешние требования. Качественные показатели нефункциональных требований.

Системные (нефункциональные) требования. Описывают характеристики

системы и ее окружения, а не поведение системы. Здесь также может быть при-

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

Все системные требования можно разбить на три большие группы.

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

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

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

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

Показатель Единицы измерения

1. Скорость - Количество выполненных транзакций в секунду; время реакции на действия пользователя; время обновления экрана

2. Размер - Килобайты; количество модулей памяти.

3. Простота эксплуатации - Время обучения персонала; количество статей в справочной системе

4. Надежность - Средняя продолжительность времени между двумя последовательными проявлениями ошибок в системе; вероятность выхода системы из строя; коэффициент готовности системы.

5. Устойчивость к сбоям - Время восстановления системы после сбоя; процент событий, приводящих к сбоям; вероятность порчи данных при сбоях

6. Переносимость - Процент машинно-зависимых операторов; количество машинно-зависимых подсистем

9. Аттестация требований. Управление требованиями. Матрица оперативного контроля

Аттестация требований

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

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

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

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

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

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

2. Проверка на непротиворечивость. Спецификация требований не должна

содержать противоречий. Это означает, что в требованиях не должно быть

противоречащих друг другу ограничений или различных описаний одной и

той же системной функции.

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

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

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

Управление требованиями

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

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

10. Проектирование: архитектурное и детальное проектирование. Состав архитектуры проекта: структурирование, модели управления, модульная декомпозиция.

Проектирование можно рассматривать как два взаимосвязанных этапа:

1) архитектурное или эскизное проектирование

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

Итогом этого этапа является технический проект.

Архитектурное проектирование

Обычно архитектурное проектирование предполагает разработку трех аспектов программируемой системы:

1) Структурирование системы

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

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

2) Моделирование управления

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

3) Модульная декомпозиции в случае ФС – методологии или построение потоков данных в случае ОО – методологии.

11. Методологии архитектурного проектирования – структурно – функциональная и ООП, их сравнительная характеристика. Нотации.

Разные методологии предполагают различные нотации для описания системы.

Рассмотрим две основные методологии создания программного обеспечения:

1) ОО методология

2) Функционально – ориентированная методология

ОО методология

Е? основой является объект.

Объект – это сущность, которая используется при выполнении некоторой функции или операции.

Объекты могут быть динамическими (заказы, счета на оплату, платежи) и статические

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

Когда строится внешний уровень, то выявляется собственно объекты, например, сырь? и

Дата добавления: 2015-04-24