 |
Объектно-ориентированный анализ.
|
|
|
|
На объектный подход оказали влияние предыдущие этапы развития программных средств. Традиционные приемы структурного анализа основаны на потоках данных в системе.
Объектно-ориентированный анализ (ООА) направлен на создание моделей, более близких к реальности, с использованием объектно-ориентированного подхода; это методология, при которой требования формируются на основе понятий классов и объектов, составляющих словарь предметной области.
На результатах ООА формируются модели, на которых основывается объектно-ориентированное проектирование; объектно-ориентированное проектирование в свою очередь создает основу для окончательной реализации системы с использованием методологии объектно-ориентированного программирования
Основными понятиями объектно-ориентированного подхода являются объект и класс.
Объект — предмет или явление, имеющее четко определенное поведение и обладающие состоянием, поведением и индивидуальностью. Структура и поведение схожих объектов определяют общий для них класс.
Класс – это множество объектов, связанных общностью структуры и поведения
Операцией называется определенное воздействие одного объекта над другим, с целью вызова соответствующей реакции
Атрибут – это свойство класса, которое может принимать множество значений.
17. Определите и охарактеризуйте основные принципы объектно-ориентированного подхода к разработке ПО. Разъясните, что послужило толчком к развитию объектно-ориентированного подхода
Увеличение размеров программ приводило к необходимости привлечения большего числа программистов, что, в свою очередь, потребовало дополнительных ресурсов для организации их согласованной работы. В процессе разработки приложений заказчик зачастую изменял функциональные требования, что еще более усложняло процесс создания программного обеспечения.
|
|
|
Как показала практика, традиционные методы процедурного программирования не способны справиться ни с нарастающей сложностью программ и их разработки, ни с необходимостью повышения их надежности. Во второй половине 80-х годов возникла настоятельная потребность в новой методологии разработки ПО, которая была бы способна решить весь этот комплекс проблем. Ею стал объектно-ориентированный подход.
К основным понятиям объектно-ориентированного подхода относятся объект и класс.
Объект — предмет или явление, имеющее четко определенное поведение и обладающие состоянием, поведением и индивидуальностью. Структура и поведение схожих объектов определяют общий для них класс.
Класс – это множество объектов, связанных общностью структуры и поведения
К основным принципам ОО подхода относятся:
Абстрагирование - это выделение таких существенных характеристик объекта, которые отличают его от всех других видов объектов и таким образом чётко определяются особенности данного объекта с точки зрения дальнейшего его рассмотрения. Абстрагирование позволяет отделить самые существенные особенности поведения от несущественных.
Инкапсуляция — свойство, позволяющее объединить данные и код в объект и скрыть реализацию объекта от пользователя. При этом пользователю предоставляется только спецификация (интерфейс) объекта. Пользователь может взаимодействовать с объектом только через этот интерфейс.
Полиморфизм может быть интерпретировано как способность класса принадлежать более чем одному типу.
Наследование означает построение новых классов на основе существующих с возможностью добавления или переопределения данных и методов
|
|
|
Модульность - это свойство системы, связанное с возможностью декомпозиции на ряд внутренне связанных, но слабо связанных между собой модулей.
Типизация - ограничение предъявляемых классу объектов, препятствующих взаимозамене различных классов и в большинстве случаев сильно сужающих возможность такой замены. Концепция типизации строится на понятии абстрактных типов данных.
Сохраняемость /устойчивость - это свойство объекта существовать во времени и/или пространстве, вне зависимости от процессов, породивших данный объект.
Иерархия – ранжированная (упорядоченная) система абстракций
Параллелизм-свойство, отличающее активные объекты от пассивных. Для систем, построенных на основе объектно-ориентированного проектировании, реальность может быть представлена, как совокупность взаимодействующих объектов, часть из которых - активна.
18. Объясните сущность унифицированного языка моделирования UML (Unified Modeling Language). Охарактеризуйте основные понятия языка: диаграмма, класс, объект, атрибут, операция.
UML - язык визуального моделирования для решения задач общего характера, который используется при определении, визуализации, конструировании и документировании системы. С помощью языка UML можно фиксировать решения, принятые при создании различных систем. Он используется для того, чтобы лучше понимать, проектировать, поддерживать и контролировать эти системы.
Язык UML – это средство описания бизнес-процессов, которое представляет собой набор инструментальных средств, позволяющих проводить всесторонний анализ сложных проектов как с технической точки зрения, так и с точки зрения потребностей бизнеса. Данный язык упрощает процесс проектирования, снижает его стоимость и повышает эффективность.
UML не является языком программирования. Программный код можно получить на основе созданной модели с помощью инструментальных средств, поддерживающих UML и содержащий генераторы кода. С другой стороны, на основе исходного кода можно вставить UML-модели уже существующих программ.
UML позволяет отображать и статическую структуру, и динамическое поведение системы. Система моделируется как группа дискретных объектов, которые взаимодействуют друг с другом таким образом. В статической структуре задаются типы объектов, значимые для системы и ее реализации, а также отношения между этими объектами. Динамическое поведение определяет историю объектов и их взаимодействие для достижения конечно цели.
|
|
|
Язык UML служит для составления чертежей программного обеспечения, визуализации, специфицирования, конструирования и документирования систем, в которых большая роль принадлежит программному обеспечению.
Применяется язык UML для разработки детального плана создаваемой системы, отображающего не только ее концептуальные элементы, такие как системные функции и бизнес-процессы, но и конкретные особенности реализации, в том числе классы, написанные на специальных языках программирования, схемы баз данных и программные компоненты многократного использования.
Классы – это базовые элементы любой объектно-ориентированной системы. Классы представляют собой описание совокупностей однородных объектов с присущими им свойствами — атрибутами, операциями, отношениями и семантикой.
Объект — предмет или явление, имеющее четко определенное поведение и обладающие состоянием, поведением и индивидуальностью. Структура и поведение схожих объектов определяют общий для них класс.
Атрибут – это свойство класса, которое может принимать множество значений
Операция – реализация функции, которую можно запросить у любого объекта класса. Операция показывает, что можно сделать с объектом. Исполнение операции часто связано с обработкой и изменением значений атрибутов объекта, а также изменением состояния объекта.
19. Перечислите и кратко охарактеризуйте основные типы диаграмм, используемые в UML. Проанализируйте, какие диаграммы относятся к статическому описанию поведения системы, а какие к динамическому.
UML позволяет отображать и статическую структуру, и динамическое поведение системы. Система моделируется как группа дискретных объектов, которые взаимодействуют друг с другом таким образом. В статической структуре задаются типы объектов, значимые для системы и ее реализации, а также отношения между этими объектами. Динамическое поведение определяет историю объектов и их взаимодействие для достижения конечно цели.
|
|
|
С помощью диаграмм UML разработчики создают различные модели системы. Разнообразие моделей позволяет разработчикам отразить различные аспекты системы:
· Диаграмма вариантов использования (use case diagram)
Варианты использования и их диаграммы применяются для визуализации функциональных возможностей системы.
Диаграммы использования описывают функциональность ИС, которая будет видна пользователям системы. "Каждая функциональность" изображается в виде "прецедентов использования" (use case) или просто прецедентов. Прецедент — это типичное взаимодействие пользователя с системой.
· Диаграмма классов (class diagram)
Диаграмма классов используется для отображения объектов системы и их отношений.
· Диаграмма состояний (statechart diagram)
Диаграммы состояний используются для описания поведения сложных систем. Они определяют все возможные состояния, в которых может находиться объект, а также процесс смены состояний объекта в результате некоторых событий
С помощью диаграмм классов и состояний разработчики получат представление о фрагментах системы и их взаимодействии друг с другом.
· Диаграмма деятельности (activity diagram)
На диаграмме деятельности представлены переходы потока управления от одной деятельности к другой внутри системы. Диаграмма деятельности показывает как эти потоки зависят друг от друга Этот вид диаграмм обычно используется для описания поведения, включающего в себя множество параллельных процессов.
· Диаграммы взаимодействия (interaction diagrams)
Диаграммы взаимодействия показывают, как объекты работают совместно, обеспечивая требуемые функциональные возможности. Делятся на: Диаграммы последовательности (sequence diagram) и Диаграммы кооперации (collaboration diagram). Из диаграмм последовательности и кооперативных диаграмм аналитики и разработчики уяснят, насколько логично работает система, поймут ее объекты и соотношения между ними.
· Диаграмма компонентов (component diagram)
Диаграммы компонентов иллюстрируют, как классы соотносятся с готовыми физическими компонентами системы. Д. компонентов показывают, какие компоненты есть в данной системе и какие между ними существуют зависимости. Компонентами системы называют отдельные программные блоки, из которых состоит вся система.
· Диаграмма развертывания (deployment diagram)
Диаграммы развертывания применяют для визуализации проекта распределенных систем
Из диаграмм компонентов и развертывания эксплуатационный персонал сможет узнать, какие.EXE и.DLL файлы и другие компоненты будут созданы, а так же где в сети они должны быть размещены.
|
|
|
Статические диаграммы представляют либо постоянно присутствующие в системе сущности и связи между ними, либо суммарную информацию о сущностях и связях, либо сущности и связи, существующие в какой-то определенный момент времени. Они не показывают способов поведения этих сущностей. Динамические диаграммы описывают происходящие в системе процессы.
| Статические диаграммы | Динамические диаграммы: |
| Диаграмма вариантов использования (use case Диаграмма классов (class diagram) Диаграмма компонентов (component diagram) Диаграмма развертывания (deployment diagram) | Диаграмма состояний (statechart Диаграмма деятельности (activity diagram) Диаграммы взаимодействия (interaction diagrams) Диаграмма последовательности (sequence diagram) Диаграмма кооперации (collaboration diagram) |
20. Дайте определение CASE-технологии. Выделите основные достоинства CASE-средств. Охарактеризуйте основные компоненты CASE-средств.
CASE-технология представляет собой методологию проектирования информационных систем, а также набор инструментальных средств, позволяющих в наглядной форме моделировать предметную область, анализировать эту модель на всех этапах разработки и сопровождения системы и разрабатывать приложения в соответствии с информационными потребностями пользователей.
Под термином CASE-средства понимаются программные средства, поддерживающие процессы создания и сопровождения информационных систем, включая анализ и формулировку требований, проектирование прикладного программного обеспечения (приложений) и баз данных, генерацию кода, тестирование, документирование, обеспечение качества, конфигурационное управление и управление проектом, а также другие процессы.
Основная цель CASE состоит в том, чтобы отделить проектирование ПО от его кодирования и последующих этапов разработки, а также скрыть от разработчиков все детали среды разработки и функционирования программного обеспечения
Таким образом, среди достоинств CASE можно выделить следующие:
· улучшают качество создаваемого ПО за счет средств автоматического контроля;
· позволяют за короткое время создавать прототип будущей системы, что дает возможность на ранних этапах оценить ожидаемый результат;
· ускоряют процесс проектирования и разработки;
· освобождают разработчика от рутинной работы, позволяя ему целиком сосредоточиться на творческой части;
· поддерживают развитие и сопровождение разработки;
· поддерживают технологии повторного использования компонент системы.
Интегрированный CASE-пакет содержит четыре основных компонента:
1. Репозиторий – основа CASE-пакета. Представляет собой средство централизованного хранения всей информации о проектируемом ПО в течение всего ЖЦ. Репозиторий должен обеспечивать:
· поддержку большой системы описаний и характеристик;
· распространение действия нового или скорректированного описания на информационное пространство всего проекта;
· синхронизацию поступления информации от различных пользователей;
· хранение версий проекта и его отдельных компонент;
· сборку любой запрошенной версии;
· проверка информации на корректность, полноту и состоятельность;
· надежные меры по защите от ошибок и потерь информации.
2. Средства ввода – предназначены для ввода данных в репозиторий, а также для организации взаимодействия с CASE-пакетом. Должны поддерживать различные методологии и использоваться на всем ЖЦ разными категориями разработчиков: аналитиками, проектировщиками, инженерами, администраторами и т. д.
3. Средства анализа, проектирования и разработки – предназначены для того, чтобы обеспечить планирование и анализ различных описаний, а также их преобразование в процессе разработки.
4. Средства вывода – служат для документирования, управления проектом и кодовой генерации.
Примеры CASE-средств:
BPwin (AllFusion Process Modeler), Erwin (AllFusion Data Modeler), IBM Rational Rose, Silverrun, Designer/2000 (Oracle), PowerBuilder, CASE.Аналитик, DataBase Designer (Oracle), Vantage Team Builder.
21. Дайте определение и перечислите принципы методологии создания программных продуктов RAD (Rapid Application Development). Выделите основные элементы данной методологии. Приведите примеры сред программирования, использующих методы RAD.
В начале 80-х годов появилась методология, по которой разработка программы начиналась не после завершения процесса выработки окончательных требований к ней, а как только устанавливались требования на первый, “стартовый” (пилотный) вариант прикладной программы, позволяющий начать содержательную работу по ее реализации на компьютере.
RAD (от англ. rapid application development — быстрая разработка приложений) — концепция создания программных продуктов, уделяющая особое внимание быстроте и удобству программирования, созданию технологического процесса, позволяющего программисту максимально быстро создавать компьютерные программы. С конца XX века RAD получила широкое распространение и одобрение. Методологию RAD также часто связывают с концепцией визуального программирования.
Методология RAD предполагает использование специальных программных средств быстрой разработки, а также CASE-средств. Благодаря этому значительно ускоряется разработка графического интерфейса, и создание прототипов.
Элементы RAD:
· небольшая команда программистов (от 2 до 10 человек);
· короткий, но тщательно проработанный производственный график (от 2 до 6 мес.);
· повторяющийся цикл, при котором разработчики, по мере того, как приложение начинает обретать форму, запрашивают и реализуют в продукте требования, полученные через взаимодействие с заказчиком.
Основные принципы методологии RAD
· разработка приложений итерациями;
· необязательность полного завершения работ на каждом из этапов жизненного цикла;
· обязательное вовлечение пользователей в процесс разработки ИС;
· необходимое применение CASE-средств, обеспечивающих целостность проекта;
· применение средств управления конфигурацией, облегчающих внесение изменений в проект и сопровождение готовой системы;
· необходимое использование генераторов кода;
· cоздание прототипа для уточнения требований заказчика.
· минимизация времени разработки версии, за счёт переноса уже готовых модулей и добавления функциональности в новую версию.
· тестирование и развитие проекта, осуществляемые одновременно с разработкой;
· ведение разработки немногочисленной хорошо управляемой командой профессионалов;
· грамотное руководство разработкой системы, четкое планирование и контроль выполнения работ.
Среды разработки, использующие принципы RAD:
· Borland C++ Builder
· Borland Delphi
· Microsoft Visual Studio
· Macromedia Flash
Macromedia Dreamweaver
22. Охарактеризуйте методологию экстремального программирования XP (Extreme Programming). Выделите основные приемы, воплощенные в данной методологии.
Экстремальное программирование (Extreme Programming), часто обозначаемое аббревиатурой ХР, – это дисциплина разработки программного обеспечения и ведения бизнеса в области создания программных продуктов, которая фокусирует усилия обеих сторон (программистов и бизнесменов) на общих, вполне достижимых целях.
ХР – это упрощенный, эффективный, гибкий, предсказуемый, научно обоснованный и весьма приятный способ разработки программного обеспечения, предусматривающий низкий уровень риска
От других методик ХР отличается по следующим признакам.
· Благодаря использованию чрезвычайно коротких циклов разработки ХР предлагает быструю, реальную и постоянно функционирующую обратную связь.
· В рамках ХР используется планирование по нарастающей, в результате общий план проекта возникает достаточно быстро, однако при этом подразумевается, что этот план эволюционирует в течение всего времени жизни проекта.
· В рамках ХР используется гибкий график реализации той или иной функциональности, благодаря чему улучшается реакция на изменение характера бизнеса и меняющиеся в связи с этим требования заказчика.
· ХР базируется на автоматических тестах, разработанных как программистами, так и заказчиками. Благодаря этим тестам удается следить за процессом разработки, обеспечивать корректное эволюционирование системы и без промедления обнаруживать существующие в системе дефекты.
· ХР основана на оральном обмене информацией, тестах и исходном коде. Три этих инструмента используются для обмена сведениями о структуре системы и ее поведении.
· ХР базируется на процессе эволюционирующего дизайна, который продолжается столь же долго, сколько существует сама система.
· ХР базируется на тесном взаимодействии программистов, обладающих самыми обычными навыками и возможностями.
· ХР основывается на методиках, которые удовлетворяют как краткосрочным инстинктам отдельных программистов, так и долгосрочным интересам всего проекта в целом.
Основные приемы:
Парное программирование предполагает, что весь код создается парами программистов, работающих за одним компьютером. Один из них работает непосредственно с текстом программы, другой просматривает его работу и следит за общей картиной происходящего. При необходимости клавиатура свободно передается от одного к другому. В течение работы над проектом пары не фиксированы: рекомендуется их перемешивать, чтобы каждый программист в команде имел хорошее представление о всей системе. Таким образом, парное программирование усиливает взаимодействие внутри команды.
Коллективное владение означает, что каждый несёт ответственность за весь код. Таким образом, каждый вправе вносить изменения в любой участок кода. Парное программирование поддерживает эту практику: работая в парах, все программисты получают доступ ко всем частям кода. Важное преимущество коллективного владения кодом — в том, что оно ускоряет процесс разработки, поскольку при появлении ошибки её может устранить любой программист.
Заказчик всегда рядом
XP утверждает, что заказчик должен быть всё время на связи и доступен для вопросов.
Игра в планирование
Основная цель игры в планирование — быстро сформировать приблизительный план работы и постоянно обновлять его по мере того, как условия задачи становятся всё более чёткими.
Рефакторинг
Рефакторинг — это методика улучшения кода без изменения его функциональности. XP подразумевает, что однажды написанный код в процессе работы над проектом почти наверняка будет неоднократно переделан.
Частые небольшие релизы
Версии продукта должны поступать в эксплуатацию как можно чаще. Работа над каждой версией должна занимать как можно меньше времени. При этом каждая версия должна быть достаточно осмысленной с точки зрения полезности для бизнеса.
23. Дайте определение понятиям «Тестирование» и «Отладка» программного обеспечения. Охарактеризуйте тестирование белого и черного ящика. Проанализируйте основные этапы тестирования.
Отладка ( debug, debugging)– процесс поиска, локализации и исправления ошибок в программе
Тестирование ПС - это процесс выполнения его программ на некотором наборе данных, для которого заранее известен результат применения или известны правила поведения этих программ
Тестирование ПО – процесс анализа пункта требований к ПО с целью фиксации различий между существующим состоянием ПО и требуемым (что свидетельствует о проявлении ошибки) при экспериментальной проверке соответствующего пункта требований
Тестирование является одним из наиболее устоявшихся способов обеспечения качества разработки программного обеспечения.
Таким образом, отладку можно представить в виде многократного повторения трех процессов: тестирования, в результате которого может быть констатировано наличие в ПС ошибки, поиска места ошибки в программах и документации ПС и редактирования программ и документации с целью устранения обнаруженной ошибки. Другими словами:
Отладка = Тестирование + Поиск ошибок + Редактирование
Тестирование – процесс многократного повторения программы с целью обнаружения ошибок. Тестирование – составная часть отладки.
При тестировании белого ящика (англ. white-box testing, также говорят — прозрачного ящика), разработчик теста имеет доступ к исходному коду и может писать код, который связан с библиотеками тестируемого ПО. При таком тестировании тестируется логика программы, внутренняя структура программы
При тестировании чёрного ящика (англ. black-box testing), тестировщик имеет доступ к ПО только через те же интерфейсы, что и заказчик или пользователь, либо через внешние интерфейсы, позволяющие другому компьютеру либо другому процессу подключиться к системе для тестирования. В этом случае тестируется спецификация, т.е. вход/выход без учета знаний о структуре программы.
Этапы тестирования
· Определение целей (требований к тестированию), включающее следующую конкретизацию: какие части системы будут тестироваться, какие аспекты их работы будут выбраны для проверки, каково желаемое качество и т. п.
· Планирование: создание графика (расписания) разработки тестов для каждой тестируемой подсистемы; оценка необходимых человеческих, программных и аппаратных ресурсов; разработка расписания тестовых циклов. Важно отметить, что расписание тестирования обязательно должно быть согласовано с расписанием разработки создаваемой системы.
· Разработка тестов (тестового кода для тестируемой системы).
· Выполнение тестов: реализация тестовых циклов.
· Анализ результатов: решается вопрос об устранении ошибок и йелесообразности тестирования на другом наборе тестовых данных
24. Дайте определение понятия «Документирование программного обеспечения». Выделите и охарактеризуйте основные виды документации на программное обеспечение
25. Опишите понятие «Модульное программирование». Выделите основные характеристики программного модуля. Проанализируйте преимущества и недостатки модульности при разработке ПО.
Модульное программирование – это организация программы как совокупности небольших независимых блоков, структура и поведение которых подчиняется заранее определенным правилам.
Программный модуль - это любой фрагмент описания процесса, оформляемый как самостоятельный программный продукт, пригодный для использования в описаниях процесса.
Это означает, что каждый программный модуль программируется, компилируется и отлаживается отдельно от других модулей программы, и тем самым, физически разделен с другими модулями программы.
Каждый разработанный программный модуль может включаться в состав разных программ, если выполнены условия его использования, описанные в документации по этому модулю.
Программы разбиваются на модули для того, чтобы:
· упростить их разработку и реализацию;
· облегчить чтение программ;
· упростить их настройку и модификацию;
· облегчить работу с данными, имеющими сложную структуру;
· избежать чрезмерной детализации алгоритмов;
· обеспечить более выгодное размещение программ в памяти ЭВМ.
К основным характеристикам программного модуля относят:
Размер модуля измеряется числом содержащихся в нем операторов или строк. Модуль не должен быть слишком маленьким или слишком большим. Маленькие модули приводят к громоздкой модульной структуре программы и могут не окупать накладных расходов, связанных с их оформлением. Большие модули неудобны для изучения и изменений, они могут существенно увеличить суммарное время повторных трансляций программы при отладке программы. Обычно рекомендуются программные модули размером от нескольких десятков до нескольких сотен операторов.
Прочность(связность) модуля - это мера его внутренних связей. Чем выше прочность модуля, тем больше связей он может спрятать от внешней по отношению к нему части программы и, следовательно, тем больший вклад в упрощение программы он может внести.
Выделяют:
Функционально прочный модуль - это модуль, выполняющий (реализующий) одну какую-либо определенную функцию. При реализации этой функции такой модуль может использовать и другие модули. Такой класс программных модулей рекомендуется для использования.
Информационно прочный модуль - это модуль, выполняющий (реализующий) несколько операций (функций) над одной и той же структурой данных (информационным объектом), которая считается неизвестной вне этого модуля.
Сцепление модуля - это мера его зависимости по данным от других модулей. Характеризуется способом передачи данных. Чем слабее сцепление модуля с другими модулями, тем сильнее его независимость от других модулей.
Рутинность модуля - это его независимость от предыстории обращений к нему. Модуль будем называть рутинным, если результат (эффект) обращения к нему зависит только от значений его параметров (и не зависит от предыстории обращений к нему). Модуль будем называть зависящим от предыстории, если результат (эффект) обращения к нему зависит от внутреннего состояния этого модуля, изменяемого в результате предыдущих обращений к нему.
| + | – |
| Модульные программы легко составлять и отлаживать. Функциональные компоненты такой программы могут быть написаны и отлажены порознь. | Модульность требует большей дополнительной работы |
| Модульную программу легче сопровождать и модифицировать. Функциональные компоненты могут быть изменены, переписаны или заменены без изменений в остальных частях. | Модульный подход иногда требует большего времени процессора |
| Разработкой модульной программы легче управлять. | Сложности в проектировании большого количества модулей |
26. Охарактеризуйте стандарт ISO/IEC 12207. Перечислите группы процессов жизненного цикла ПО и опишите основные процессы жизненного цикла программного обеспечения.
Существует целый ряд стандартов, регламентирующих ЖЦ ПО, а в некоторых случаях и процессы разработки. Самым известным стандартом является стандарт ISO/IEC 12207 – стандарт на процессы и организацию жизненного цикла. Распространяется на все виды заказного ПО. Стандарт не содержит описания фаз, стадий и этапов. Последняя редакция стандарта – 2008 год.
Стандарт определяет процессы, виды деятельности и задачи, которые используются при приобретении программного продукта или услуги, а также при поставке, разработке, применении по назначению, сопровождении и прекращении применения программных продуктов.
В соответствии с базовым международным стандартом ISO/IEC 12207 все процессы ЖЦ ПО делятся на три группы:
| 1. Основные процессы: · заказ; · поставка; · разработка; · эксплуатация; · сопровождение. | 2. Вспомогательные процессы: · документирование; · управление конфигурацией; · обеспечение качества; · разрешение проблем; · аудит; · аттестация; · совместный анализ; · верификация | 3. Организационные процессы: · создание инфраструктуры; · управление; · обучение; · усовершенствование. |
Стандарт ISO/IEC 12207 детально определяет перечень работ каждого процесса ЖЦ, однако не устанавливает конкретной модели ЖЦ ПО в виде последовательности фаз, стадий и этапов.
27. Охарактеризуйте этап сопровождения программного обеспечения. Проанализируйте значимость данного этапа в структуре жизненного цикла ПО.
Сопровождение программного обеспечения — процесс улучшения, оптимизации и устранения дефектов программного обеспечения (ПО) после передачи в эксплуатацию. Сопровождение ПО — это одна из фаз жизненного цикла программного обеспечения, следующая за фазой передачи ПО в эксплуатацию. В ходе сопровождения в программу вносятся изменения, с тем, чтобы исправить обнаруженные в процессе использования дефекты и недоработки, а также для добавления новой функциональности, с целью повысить удобство использования и применимость ПО.
Сопровождение – это внесение изменений в эксплуатируемое ПО. Цели изменений:
· исправление ошибок;
· адаптация к изменениям внешней для ПО среды;
· усовершенствование ПО по требованиям заказчика.
Сопровождение ПО состоит в повторном применении каждого из предшествующих шагов (этапов) ЖЦ к существующей программе, но не разработке новой программы.
Согласно стандарту 34.601 «АВТОМАТИЗИРОВАННЫЕ СИСТЕМЫ. СТАДИИ СОЗДАНИЯ» этап сопровождения включает в себя:
· Выполнение работ в соответствии с гарантийными обязательствами:
осуществляются работы по устранению недостатков, выявленных при эксплуатации ИС в течении установленных гарантийных сроков, внесению необходимых изменений в документацию по ИС.
· Послегарантийное обслуживание:
анализ функционирования системы;
выявление отклонений фактических эксплуатационных характеристик ИС от проектных значений;
установление причин этих отклонений;
устранение выявленных недостатков и обеспечению стабильности эксплуатационных характеристик ИС;
внесение необходимых изменений в документацию на ИС.
Сопровождение ПО может подразумевать как постоянное (24х7), так и периодическое обслуживание (по запросу). Первый вариант поддержки и сопровождения ПО больше подходит для высоконагруженных систем, второй вариант необходимо применять на проектах, которые могут содержать большой функционал или проекты, на которых необходимо отслеживать всевозможные действия пользователей, которые периодически приводят к некорректной работе (будь то неверное построение отчетов или статистики, некорректно выставленные статусы какой-либо заявке или товару и т.д.).
28. Дайте характеристику CASE-средствам BPwin (AllFusion Process Modeler) и ERwin (AllFusion Data Modeler). Опишите их назначение и возможности в разработке программных продуктов.
Типичными представителями интегрированных средств моделирования являются программные средства BPwin и ERwin.По своей функциональной ориентации они относятся к Case-средствам предназначенным для анализа и проектирования.
С использованием BPwin строятся диаграммы бизнес-процессов (блоки), ясно показывающие результаты их работы и ресурсы, необходимые для их функционирования. BPwin используется для анализа, документирования и реорганизации сложных бизнес-процессов. Модель, созданная средствами BPwin, позволяет четко документировать различные аспекты деятельности – действия, которые необходимо предпринять, способы их осуществления, требующиеся для этого ресурсы и т.д.
Модель в BPwin рассматривается как совокупность работ, каждая из которых оперирует с некоторым набором данных. Работа изображается в виде прямоугольника, данные – в виде стрелок.
BPwin поддерживает три методологии – IDEF0, IDEF3 и DFD, каждая из которых предназначена для решения своих специфических задач. В BPwin возможно построение смешанных моделей, т.е. модель может содержать одновременно как диаграммы IDEF0, так и IDEF3 и DFD. Состав палитры инструментов изменяется автоматически, когда происходит переключение с одной нотации на другую.
Модель в BPwin представляет собой совокупность SADT-диаграмм, каждая из которых описывает отдельный процесс в виде разбиения его на шаги и подпроцессы. С помощью соединяющих дуг описываются объекты, данные и ресурсы, необходимые для выполнения функций.
Встроенный в BPwin механизм вычисления стоимости позволяет оценивать и анализировать затраты на осуществление различных видов деловой активности.
BPwin может импортировать фрагменты информационной модели из средства проектирования баз данных ERwin (при этом сущности и атрибуты информационной модели ставятся в соответствие дугам SADT-диаграммы). Таким образом, BPwin объединяет три ключевых подхода к моделированию бизнес-процессов, что вполне удовлетворяет потребности как системных аналитиков, так и специалистов-технологов.
|
|
|
