Стадии и этапы разработки программ проектирование реализация

Содержание

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

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

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

Стадии и этапы разработки программ

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

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

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

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

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

Жизненный цикл IT проекта

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

2. Понятие «архитектура информационной системы»

Рассмотрим определение «архитектуры информационной системы», которое дают различные источники:

Архитектура – это организационная структура системы.

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

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

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

Читайте также:
Не отображаются кнопки в программе

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

Если все эти определения объединить, то получим следующее:

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

Под архитектурой программных систем будем понимать совокупность решений относительно:

· организации программной системы;

· выбора структурных элементов, составляющих систему и их интерфейсов;

· поведения этих элементов во взаимодействии с другими элементами;

· объединение этих элементов в подсистемы;

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

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

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

Воспользуйтесь поиском по сайту:

studopedia.org — Студопедия.Орг — 2014-2023 год. Студопедия не является автором материалов, которые размещены. Но предоставляет возможность бесплатного использования (0.006 с) .

Источник: studopedia.org

Стадии и этапы разработки

2.6 Порядок контроля и приемки

В процессе разработки программы «Обучающая программа построению запросов в процедурном виде» должны проводиться: 1) проектирование и отладка программы; 2) предварительные испытания; 3) опытная эксплуатация; 4) ввод в действие.

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

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

Продолжительность опытной эксплуатации составляет 2 недели.

Таблица 2.1 Стадии и этапы разработки

Реализация и отладка программ

Разработка программной документации

3 Проектирование программы обучения реляционной алгебре

3.1 Анализ предметной области

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

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

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

Объединением двух совместимых таблиц R1 и R2 называется таблица R, состоящая из всех строк, принадлежащих хотя бы одной из таблиц R1, R2.

Пересечением двух совместимых таблиц R1 и R2 называется таблица R, состоящая из всех строк, являющихся общими для таблиц R1, R2.

Разностью двух совместимых таблиц R1 и R2 называется таблица R, состоящая только из тех строк таблицы R1, которые отсутствуют в таблице R2.

Декартовым произведением двух таблиц R1 и R2 (необязательно совместимых) называется таблица R, состоящая из всех таких строк, каждая из которых есть конкатенация двух строк, по одной из таблиц R1 и R2, причем на первом месте должна быть строка из R1.

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

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

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

Проекция — реляционная таблица, полученная в результате создания проекций.

Соединение — операция реляционной алгебры, связывающая таблицы. У нее есть несколько версий:

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

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

JOIN (A,B: X d Y), где d обозначает операцию сравнения.

Если используется операция «=», то соединение также называется эквисоединением.

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

Затем, если какая-либо строка одной из исходных таблиц не подходит ни к какой строке второй таблицы, она включается в таблицу соединения, а все дополнительные столбцы заполняются пустыми значениями. Обозначение: OUTER JOIN (A,B). Возможно также левое и правое соединения, при которых в результирующую таблицу включаются только строки из одной таблицы.

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

Программа может работать в двух режимах: обучающем и контролирующем.

В обоих режимах необходимо наличие множества вопросов. Таким образом, необходим еще один компонент программы – формирования вопросов.

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

Читайте также:
Что такое программа плис

Ответ на вопрос должен вводиться в виде последовательности операций реляционной алгебры.

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

Например, пусть БД состоит из таблиц Товар (Идентификатор, Название) и Продажа (Дата, Идентификатор товара, Количество, Цена).

Необходимо получить результат запроса «Какой товар продавали в количестве более 100». Ответ можно представить в виде следующих последовательностей.

R1=JOIN (Товар, Продажа, Идентификатор товара=Товар)

R2= s (R1, Количество>100)

R3=p (R2, Название)

R1= s (Продажа, Количество>100)

R2=JOIN (Товар, R1, Идентификатор товара=Товар)

R3=p (R2, Название)

Необходимо получить результат запроса «Какой товар ни разу не продавали». Ответ можно представить в виде следующих последовательностей.

R1= LEFT JOIN (Товар, Продажа, Идентификатор товара=Товар)

R2= s (R1, Идентификатор товара=NULL)

R3=p (R2, Название)

R1=p (Продажа, Идентификатор товара)

R2=p (Товар, Идентификатор)

R4=JOIN (Товар, R3, Товар.Идентификатор = R3.Идентификатор)

R5=p (R4, Название)

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

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

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

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

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

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

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

Учебных БД может быть несколько.

К каждой БД может быть составлено множество запросов, на каждый запрос может быть множество ответов.

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

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

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

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

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

Например, для операции объединения порядок операндов несущественен, для операции внутреннего соединения тоже, но при выполнении операции левого соединения порядок существенен. При этом эквивалентны операции:

R1= LEFT JOIN (A, B, условие соединения)

R1= RIGHT JOIN (B, A, условие соединения).

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

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

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

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

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

Для этого программа должна уметь преобразовывать операцию (последовательность операций) в запрос к БД.

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

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

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

Источник: kazedu.com

Презентация на тему Жизненный цикл и этапы разработки программного обеспечения. (Лекция 2)

ЖИЗНЕННЫЙ ЦИКЛ ПО. Основным понятием программной инженерии является понятие жизненного цикла ПО. Жизненный цикл ПО (software lifecycle) – это период времени, который начинается с момента принятия решения о необходимости

  • Главная
  • Информатика
  • Жизненный цикл и этапы разработки программного обеспечения. (Лекция 2)

Слайды и текст этой презентации

Слайд 1ЖИЗНЕННЫЙ ЦИКЛ И ЭТАПЫ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

ЖИЗНЕННЫЙ ЦИКЛ И ЭТАПЫ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

Слайд 2ЖИЗНЕННЫЙ ЦИКЛ ПО.
Основным понятием программной инженерии является

понятие жизненного цикла ПО.

Жизненный цикл ПО

(software lifecycle) – это период времени, который начинается с момента принятия решения о необходимости создания ПО и заканчивается в момент его полного изъятия из эксплуатации.

Основной нормативный документ, регламентирующий ЖЦ ПО – стандарт ISO/IEC 12207 “Information Technology – Software Life Cycle Processes” (ГОСТ Р ИСО/МЭК 12207-99).

ЖИЗНЕННЫЙ ЦИКЛ ПО. Основным понятием программной инженерии является понятие жизненного цикла ПО.

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

действий, преобразующих некоторые входные данные в выходные.

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

Слайд 4СТРУКТУРА ПРОЦЕССОВ ЖИЗНЕННОГО ЦИКЛА ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
Основные процессы
Приобретение
Поставка
Разработка
Эксплуатация
Сопровождение
Вспомогательные

процессы
Документирование
Управление конфигурацией
Обеспечение качества
Верификация
Аттестация
Совместная оценка
Аудит
Разрешение проблем

Организационные процессы
Управление
Усовершенствование
Создание инфраструктуры
Обучение

СТРУКТУРА ПРОЦЕССОВ ЖИЗНЕННОГО ЦИКЛА ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ Основные процессы Приобретение Поставка Разработка Эксплуатация

Слайд 5Процесс разработки ПО

Процесс разработки ПО

Слайд 6ПРОЦЕСС РАЗРАБОТКИ
Процесс разработки в соответствии со стандартом

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

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

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

Читайте также:
Как узнать свой пароль от вайфая программа

ПРОЦЕСС РАЗРАБОТКИ Процесс разработки в соответствии со стандартом предусматривает действия и задачи,

Слайд 7ДЕЙСТВИЯ В ПРОЦЕССЕ РАЗРАБОТКИ ( по стандарту

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

и средств разработки, а также составление плана работ

☞ анализ требований к системе

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

☞ проектирование архитектуры системы

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

☞ анализ требований к программному обеспечению

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

ДЕЙСТВИЯ В ПРОЦЕССЕ РАЗРАБОТКИ ( по стандарту ) ☞ подготовительная работа выбор

Слайд 8ДЕЙСТВИЯ В ПРОЦЕССЕ РАЗРАБОТКИ ( по стандарту

)
☞ проектирование архитектуры программного обеспечения
определение структуры программного обеспечения,

документирование интерфейсов его компонентов, разработку предварительной версии пользовательской документации, а также требований к тестам и плана интеграции

☞ детальное проектирование программного обеспечения

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

☞ кодирование и тестирование программного обеспечения

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

☞ интеграция программного обеспечения

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

ДЕЙСТВИЯ В ПРОЦЕССЕ РАЗРАБОТКИ ( по стандарту ) ☞ проектирование архитектуры программного

Слайд 9ДЕЙСТВИЯ В ПРОЦЕССЕ РАЗРАБОТКИ ( по стандарту

)
☞ квалификационное тестирование программного обеспечения
тестирование программного обеспечения

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

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

☞ квалификационное тестирование системы

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

☞ установка программного обеспечения

установка программного обеспечения на оборудовании заказчика
проверка его работоспособности

☞ приёмка программного обеспечения

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

ДЕЙСТВИЯ В ПРОЦЕССЕ РАЗРАБОТКИ ( по стандарту ) ☞ квалификационное тестирование программного

Слайд 10Этапы разработки программного обеспечения

Этапы разработки программного обеспечения

Слайд 11ЭТАПЫ РАЗРАБОТКИ ПО
Указанные выше действия можно сгруппировать,

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

выделения этапов связана с тем, что на любом этапе возможно принятие решений, которые потребуют пересмотра решений, принятых ранее.
Каждому этапу можно поставить в соответствие стадию разработки по ГОСТ 19.102–77 «Стадии разработки».

ЭТАПЫ РАЗРАБОТКИ ПО Указанные выше действия можно сгруппировать, условно выделив основные этапы

Слайд 12Этапы и стадии разработки ПО

Этапы и стадии разработки ПО

Слайд 13Традиционно разработка также включала этап сопровождения (началу

этого этапа соответствует стадия «Внедрение» по ГОСТ).

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

Традиционно разработка также включала этап сопровождения (началу этого этапа соответствует стадия «Внедрение»

Слайд 14Постановка задачи
В процессе постановки задачи чётко формулируют

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

Постановка задачи В процессе постановки задачи чётко формулируют назначение программного обеспечения и

Слайд 15ТРЕБОВАНИЯ
Требование – это условие, которому должно удовлетворять

программное обеспечение, или свойство, которым оно должно

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

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

ТРЕБОВАНИЯ Требование – это условие, которому должно удовлетворять программное обеспечение, или свойство,

Слайд 16Этап постановки задачи заканчивается разработкой технического задания,

фиксирующего принципиальные требования, и принятием основных проектных

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

Слайд 17Анализ требований и определение спецификаций
Спецификация требований к

ПО является основным документом, определяющим план разработки

Анализ требований и определение спецификаций Спецификация требований к ПО является основным документом,

Слайд 18СПЕЦИФИКАЦИИ
Совокупность спецификаций представляет собой общую логическую модель

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

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

СПЕЦИФИКАЦИИ Совокупность спецификаций представляет собой общую логическую модель проектируемого программного обеспечения. Спецификация

Слайд 19АЛГОРИТМ ВЫРАБОТКИ СПЕЦИФИКАЦИЙ

АЛГОРИТМ ВЫРАБОТКИ СПЕЦИФИКАЦИЙ

Слайд 20Проектирование
Основной задачей этого этапа является определение подробных

спецификаций разрабатываемого программного обеспечения.

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

Слайд 21ПРОЦЕСС ПРОЕКТИРОВАНИЯ
Результатом проектирования является детальная модель разрабатываемого

программного обеспечения вместе со спецификациями его компонентов

всех уровней.

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

ПРОЦЕСС ПРОЕКТИРОВАНИЯ Результатом проектирования является детальная модель разрабатываемого программного обеспечения вместе со

Слайд 22ДВА АСПЕКТА ПРОЕКТИРОВАНИЯ
Принято различать два аспекта проектирования:
Логическое

проектирование
проектные операции, которые непосредственно не зависят от

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

ДВА АСПЕКТА ПРОЕКТИРОВАНИЯ Принято различать два аспекта проектирования: Логическое проектирование проектные операции,

Слайд 23Реализация
Реализация представляет собой процесс поэтапного написания кодов

программы на выбранном языке программирования (кодирование), их

тестирование и отладку.

Реализация Реализация представляет собой процесс поэтапного написания кодов программы на выбранном языке

Слайд 24Сопровождение
Сопровождение – это процесс создания и внедрения

новых версий программного продукта.
На этом этапе в

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

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

Слайд 25ПРИЧИНЫ ВЫПУСКА НОВЫХ ВЕРСИЙ
необходимость исправления ошибок, выявленных

в процессе эксплуатации предыдущих версий

необходимость совершенствования предыдущих

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

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

ПРИЧИНЫ ВЫПУСКА НОВЫХ ВЕРСИЙ необходимость исправления ошибок, выявленных в процессе эксплуатации предыдущих

Слайд 26С изменением модели жизненного цикла программного обеспечения

существенно возросла роль этапа сопровождения, так как

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

Источник: thepresentation.ru

Рейтинг
( Пока оценок нет )
Загрузка ...
EFT-Soft.ru