Теоретические вопросы
1.Кризис программного обеспечения (по). Проблемы и цели программной инженерии. Определение инженерии по.
Инженерия программного обеспечения — сравнительно молодая научная дисци-плина. Термин software engineering был впервые предложен в 1968 году на конферен-ции, посвященной так называемому кризису программного обеспечения.
Кризис 1968 был вызван появлением мощной (по меркам того времени) вычисли-тельной техники. Новая техника позволяла воплотить в жизнь не реализуемые ранее про-граммные приложения. В результате программное обеспечение достигло размеров и уровня сложности, намного превышающих аналогичные показатели у программных си-стем, реализованных на вычислительной технике предыдущих поколений.
Проблемы:
1.Неформальный подход, применявшийся ранее к построению программных систем, недостаточен для разработки больших систем.
2.На реализацию крупных программных проектов иногда уходили многие годы. Стоимость таких проектов многократно возрастала по сравнению с первоначальными расчетами, сами программные системы получались ненадежными, сложными в эксплуатации и сопровождении.
3.Более того, возрастает как объем производства программного обеспечения, так и его сложность. А также, сближение вычислительной и коммуникационной техники ставит новые требования перед специалистами по программному обеспечению.
4.Еще одним фактором является то, что многие компании, занимающиеся производством ПО, не уделяют должного внимания эффективному применению современных методов, разработанных в рамках инженерии программного обеспечения.
Целью инженерии программного обеспечения является эффективное создание программных систем. Однако у ПО, как у медали, есть две стороны. С одной стороны, программное обеспечение абстрактно и нематериально. Оно не имеет физической при-роды, не подчиняется физическим законам и не подвергается обработке произ-водственными процессами. Такой упрощенный взгляд на ПО показывает, что не суще-ствует физических ограничений на потенциальные возможности программных систем. С другой стороны, отсутствие материального наполнения порой делает ПО чрезвычайно сложным и, следовательно, трудным для понимания "объектом".
Инженерия программного обеспечения — это инженерная дисциплина, которая охватывает все аспекты создания ПО от начальной стадии разработки системных требований через создание ПО до его использования. В этом определении присут-ствует две ключевые фразы.
1. "Инженерная дисциплина". Инженеры — это те специалисты, которые выполняют практическую работу. Они применяют теоретические построения, методы и средства там, где это необходимо, но делают это выборочно и всегда пытаются найти решение за-дачи, даже если не существует подходящей теории или методов решения. Специалисты-инженеры также всегда понимают, что они должны работать в организационных и финансовых рамках заключенных контрактов, т.е. ищут решение поставленной перед ними задачи с учетом условий контракта.
2. "Все аспекты создания программного обеспечения". Инженерия программного обеспечения не рассматривает технические аспекты создания ПО (например, используе-мый язык) — в ее ведении такие вопросы, как управление проектом создания ПО и раз-работка средств, методов и теорий, необходимых для создания программных систем.
2.Что такое ПО. Типы программных продуктов, их отличие друг от друга.
Программное обеспечение — это программы, вся сопутствующая документация, а также конфигурационные данные, необходимые для корректной работы программ. Программные продукты де-лятся на два типа.
1. Общие программные продукты. Это автономные программные системы, ко-торые созданы компанией по производству ПО и продаются на открытом рынке программных продуктов любому потребителю, способному их купить. Примерами этого типа программных продуктов могут служить все программы, которые есть на ва-шем любимом трекере.
2. Программные продукты, созданные на заказ. Это программные системы, ко-торые создаются по заказу определенного потребителя. Такое ПО разрабатывается специально для данного потребителя согласно заключенному контракту. Программ-ные продукты этого типа включают системы управления для электронных устройств, си-стемы поддержки определенных производственных или бизнес-процессов (системы «Почта России», СБРФ и др.).
Важное отличие между этими типами программных продуктов заключается в том, что при создании общих программных продуктов спецификация требований на них разрабатывается компанией-производителем. Для заказных программных продук-тов спецификация обычно разрабатывается организацией, покупающей данный продукт. Спецификация необходима разработчикам ПО для создания любого про-граммного продукта.
3.Характеристики качественного ПО.
Кроме функциональных возможностей, присущих программным продуктам по определению, эти продукты обладают и другими показателями, характеризующими их качество. Данные показатели не вытекают непосредственно из того, какие действия может выполнять программный продукт. Они характеризуют поведение программы во время выполнения ею своих действий, структуру и организацию исходного кода программы, ее документированность.
Примером таких показателей (иногда называемых нефункциональными показателями) может служить время ожидания пользователем ответа на свой запрос или понятность программного кода.
4.Основные проблемы, стоящие перед специалистами по ПО.
Основные проблемы, стоящие перед специалистами по программному обес-печению
1. Проблема наследования ранее созданного ПО. Многие большие программные системы, эксплуатируемые в настоящее время, созданы много лет назад, но до сих пор выполняют свои функции надлежащим образом. Проблема наследования означает поддержку и модернизацию таких систем, причем при минимальных финансовых и временных затратах. Хотя в настоящее время зачастую гораздо проще купить новую более мощную железку и сделать новое ПО с нуля.
2. Проблема все возрастающей разнородности программных систем. В настоя-щее время программное обеспечение должно быть способно работать в качестве систем, распределенных в компьютерных сетях, состоящих из компьютеров разных типов и ис-пользующих различные операционные системы. Проблема возрастающей разнородно-сти программных систем состоит в том, что необходимо разрабатывать надежные программные системы, способные работать совместно с ПО разных типов. Вот ведь загнули, надежное ПО да еще и на разные платформы.
3. Проблема, порожденная требованием уменьшения времени на создание ПО. Многие традиционные технологии создания качественного программного обеспечения требуют больших временных затрат. Поскольку сегодня запросы рынка ПО и требо-вания к программным системам меняются очень быстро. Поэтому и ПО должно
меняться с соответствующей скоростью. Проблема, порожденная требованием уменьшения времени на создание ПО, заключается в том, чтобы сократить время на разработку больших и сложных программных систем без снижения их качества. Пример со строителями – сроки поджимают. Фигачим в три смены в дождь и мороз – от-сюда зачастую несоблюдение технологии.
Конечно, перечисленные проблемы связаны друг с другом. Например, возможна та-кая ситуация, когда необходимо быстро разработать на основе существующей системы ее сетевой вариант. Или же появилась новая версия операционной системы, и необходи-мо в сжатые сроки создать (адаптировать уже имеющееся) антивирусное ПО для нее.
5.Профессиональные и этические требования к специалистам по программному обеспечению
1. Конфиденциальность. Специалист должен соблюдать конфиденциальность, т.е. не разглашать никаких сведений о работодателе и клиентах, независимо от то-го, подписывал он или нет какое-либо соглашение о соблюдении конфиденциально-сти.
2. Компетентность. Специалист не должен скрывать (или ложно представ-лять) свой уровень компетенции и не должен браться за работу, которая этому уровню не соответствует.
3. Защита прав интеллектуальной собственности. Специалист не должен нарушать соответствующее законодательство о защите авторских прав при исполь-зовании чужой интеллектуальной собственности (патентов и т.п.). Он также должен защищать интеллектуальную собственность работодателя и клиентов.
4. Злоупотребление компьютером. Специалист не должен, используя свой про-фессиональный уровень, наносить вред компьютерам других людей. Злоупотребле-ния компьютером могут быть как относительно тривиальными (скажем, игра в компьютерные игры на машине, принадлежащей работодателю), так и очень серь-езными (например, распространение компьютерных вирусов).
АСМ и IEEE (еще в 1999 году) совместно создали кодекс, соединяющий этические нормы и профессиональную практику. Этот кодекс существует в двух версиях: краткой и полной.
6.Определение «система». Основные признаки системы. Понятие подсистемы.
Система - это совокупность взаимодействующих компонентов, работающих совместно для достижения определенных целей.
Определяющим признаком системы является то, что свойства и поведение системных ком-понентов влияют друг на друга чрезвычайно сложным и запутанным образом. Корректное функ-ционирование каждого системного компонента зависит от функционирования многих других компонентов. Так, операционное обеспечение может выполнять свои функции, если только рабо-тает процессор и соответствующие аппаратные средства. Процессор может выполнять вычисле-ния, если только корректно инсталлированы программные системы, задающие эти вычисления.
Системы часто имеют иерархическую структуру, т.е. в качестве компонентов содержат дру-гие системы. Например, компьютерная система полиции содержит географическую информаци-онную систему, которая предлагает информацию о месте, где случилось или может случиться ка-кое-либо происшествие. Эта же подсистема может быть использована в различных муниципаль-ных системах - контроля земель, благоустроенности, управления коммунальных служб и т.д.
Системы, которые являются компонентами других систем, называются подсистемами. Определяющее свойство подсистем заключается в том, что они могут функционировать само-стоятельно, независимо от тех систем, в состав которых входят. Поэтому географическую ин-формационную систему можно использовать также в других системах. Вместе с тем их поведение в составе какой-либо конкретной системы зависит, конечно, от взаимодействия с другими подсистемами.
Сложность взаимодействия между системными компонентами означает, что система не сво-дится просто к сумме ее составных частей. Она имеет определенные свойства, которые присущи ей именно как целостной системе.
7.Интеграционные свойства систем. Их типы, примеры.
Такие интеграционные свойства не могут быть свойствами какой-либо отдельной части си-стемы. Более того, они проявляются тогда, когда система рассматривается как единое целое. Не-которые из этих свойств можно вывести из аналогичных свойств отдельных подсистем, но чаще они являются комплексным результатом взаимодействия всех подсистем и их невозможно оце-нить, исходя из анализа отдельных системных компонентов. Например, система автомобиль - об-ладает свойством перемещаться, если объединить все системы – мотор, коробка передач, кузов и т.д.
Приведем примеры интеграционных свойств.
1. Суммарный размер системы. Это пример интеграционного показателя системы, который
можно вычислить, исходя только из свойств отдельных компонентов.
2. Безотказность системы. Это свойство зависит от безотказности отдельных компонентов и взаимосвязи между ними.
3. Удобство эксплуатации системы. Это очень сложное многопараметрическое свойство, ко-торое зависит не только от программного обеспечения и аппаратных средств системы, но также от окружения, в котором эксплуатируется система, и от системных операторов.
4. Производительность системы.
Существует два типа интеграционных свойств.
1. Функциональные свойства, которые проявляются только тогда, когда система работает
как единое целое. Например, велосипед имеет функциональные свойства транспортного средства толь-ко тогда, когда собран из своих компонентов.
2. Нефункциональные свойства: безотказность, производительность, безопасность и защищенность (ограничение несанкционированного доступа к системе), которые зависят от поведения системы в операционном окружении. Такие свойства часто критичны для вычислительных систем, поскольку если они не достигают определенного минимального уровня, то система не будет работоспособной.
Существует три тесно связанных между собой фактора, которые влияют на общую без-отказность системы.
1. Безотказность аппаратных средств. Этот показатель определяется вероятностью выхода из строя отдельных аппаратных компонентов и временем, необходимым па их замену.
2. Безотказность программного обеспечения. Это показатель работы компонента ПО без сбо-ев и ошибок. Программные ошибки обычно не оказывают влияния на аппаратные средства си-стемы. Поэтому система может продолжать функционировать даже тогда, когда ПО выдает не-корректные результаты.
3. Ошибки операторов. Операторы, эксплуатирующие систему, также могут допускать ошибки в своей деятельности.
Безотказность системы также зависит от окружения, в котором она эксплуатируется. То есть трудно предвидеть системное окружение, в котором будет эксплуатироваться система, и сложно описать окружение в виде ограничений, которые должны учитываться при разработке системы.
8.Определение системных требований к системе. Типы требований к системам. Множество целей системы.
9.Процесс разработки требований, этапы. Какие преимущества обеспечивают хорошие СТПО.
Схема процесса разработки требований показана на рисунке 3.3.1. Результатом его выполнения является разработка документации, формализующей требования, предъявляемые к системе, т.е. создание системной спецификации.
Процесс разработки требований включает четыре основных этапа.
1. Предварительные исследования. Оценивается степень удовлетворенности пользователей
существующими программными продуктами и аппаратными средствами, а также экономическая эффективность будущей системы и возможность уложиться в существующие бюджетные ограничения при ее разработке. Этот этап должен быть по возможности коротким и дешевым.
2. Формирование и анализ требований. Формируются системные требования путем изучения существующих аналогичных систем, обсуждения будущей системы с потенциальными пользователями и заказчиками, анализа задач, которые должна решать система, и т.п. Этот этап может включать разработку нескольких моделей системы и ее прототипов, что помогает сформировать функциональные требования к системе.
3. Специфицирование требований. Осуществляется перевод всей совокупности информации, собранной на предыдущем этапе, в документ, определяющий множество требований. Этот документ обычно содержит два типа требований: пользовательские – обобщенные представления заказчиков и конечных пользователей о системе; системные – детальное описание функциональных показателей системы.
4. Утверждение требований. Проверяется выполнимость, согласованность и полнота множества требований. В процессе формирования ограничений неизбежно возникновение каких-либо ошибок. На этом этапе они должны быть по возможности выявлены и устранены.
Хорошие спецификации требований ПО (СТПО) должны обеспечить клиентам, поставщи-кам и другим индивидуумам несколько определенных преимуществ, таких как:
1. Установить основание для соглашения между клиентами и поставщиками о том, что про-граммное обеспечение должно делать. Полное описание функций, которые будут выполнены про-граммным обеспечением, указанным в СТПО поможет потенциальному пользователю опреде-лить, выполняет ли программное обеспечение их потребности или как программное обеспечение должно быть изменено, чтобы выполнить их потребности.
2. Уменьшить усилия на разработку. Подготовка СТПО вынуждает различные заинтересо-ванные группы в организации клиента строго рассматривать все требования до начала разработ-ки проекта и уменьшает в дальнейшем объем работ по перепроектированию, перекодированию, и повторному тестированию. Внимательное рассмотрение требований в СТПО может выявить упущения, недоразумения и нелогичности на ранних стадиях разработки, когда эти проблемы бо-лее легко исправляются.
3. Обеспечить основание для оценки затрат и календарного плана. Описание изделия, кото-рое будет разработано так, как определено в СТПО является реалистическим основанием для оценки проектных затрат и может использоваться для согласования предложений или оценки стоимости.
4. Обеспечить основу для испытаний (validation) и проверок. Организации могут развивать собственные планы испытаний и проверок намного более продуктивно при наличии хороших СТПО. Как часть контракта на разработку, СТПО обеспечивает основу, у которой соответствие может быть измерено.
5. Облегчить передачу. СТПО обеспечивают более легкую передачу изделия программного обеспечения новым пользователям или установку на новые машины. Таким образом, заказчикам более легко передавать программное обеспечение другим частям их организации, а поставщикам более легко передавать программное обеспечение новым клиентам.
6. Служить основанием для улучшения. Поскольку СТПО описывают изделие, но не проект, который развивается, то СТПО могут служить основой для дальнейшего улучшения готового из-делия. СТПО могут быть изменены, но это обеспечивает фундамент для непрерывной оценки производства.
10.Проектирование ПО. Процесс проектирования. Wicked problem.
Реализация программного обеспечения — это процесс перевода системной спецификации в работоспособную систему. Этап реализации всегда включает процессы проектирования и программирования.
На этапе проектирования ПО определяется его структура, данные, которые являются ча-стью системы, интерфейсы взаимодействии системных компонентов и иногда используемые ал-горитмы. Проектировщики сразу никогда не получают законченный результат – процесс проек-тирования обычно проходит через разработку нескольких промежуточных версий ПО. Проекти-рование предполагает последовательную формализацию и детализацию создаваемого ПО с воз-можностью внесения изменений в решения, принятые на более ранних стадиях проектирования.
Процесс проектирования как правило включать разработку нескольких моделей системы различных уровней обобщения. Поскольку проектирование — это процесс декомпозиции, такие модели помогают выявить ошибки, допущенные на ранних стадиях проектирования, а, следова-тельно, позволяют внести изменения в ранее созданные модели. На рисунке 2.4.1 показана схема процесса проектирования ПО с указанием результата каждого этапа проектирования. Эта схема построена в предположении, что все этапы процесса проектирования выполняются последова-тельно. На практике эти этапы как правило перекрываются.
Результатом каждого этапа проектирования является спецификация, необходимая для вы-полнения следующего этапа. Эта спецификация может быть абстрактной и формальной, т.е. та-кой, какая необходима для детализации системных требований. В процессе проектирования спе-цификации постепенно становятся все более детализированными. Конечными результатами про-цесса проектирования являются точные спецификации на алгоритмы и структуры данных, кото-рые будут реализованы на следующем этапе создания ПО.
Отдельные этапы процесса проектирования:
1. Архитектурное проектирование. Определяются и документируются подсистемы и взаи-мосвязи между ними.
2. Обобщенная спецификация. Для каждой подсистемы разрабатывается обобщенная специ-фикация на ее сервисы и ограничения.
3. Проектирование интерфейсов. Для каждой подсистемы определяется и документируется ее интерфейс. Спецификации на эти интерфейсы должны быть точно выраженными и однознач-ными, чтобы использование подсистем не требовало знаний о том, как они реализуют свои функ-ции.
4. Компонентное проектирование. Проводится распределение системных функций (сер-висов) по различным компонентам и их интерфейсам.
5. Проектирование структур данных. Детально разрабатываются структуры данных, не-обходимые для реализации программной системы.
6. Проектирование алгоритмов. Детально разрабатываются алгоритмы, предназначенные для реализации системных сервисов.
Описанная схема процесса проектирования является достаточно общей и на практике может (и должна) адаптироваться применительно к разработке конкретного программного продукта.
11.DF диаграммы.
Несомненно, диаграммы потока данных (data flow diagrams – DFD) являются одной из наибо-
лее популярных технологий моделирования в истории программной инженерии. Сегодня они ис-пользуются нечасто из-за того, что не соответствуют объектно-ориентированному подходу. Одна-ко в некоторых обстоятельствах DFD остается приемлемой технологией.
Краеугольный камень DFD – функциональная декомпозиция. Рис. 2.4.2.1.1 иллюстрирует эту идею. Функциональная декомпозиция – метод постепенного определения функциональных
процессов системы. Это – нисходящая операция, которая начинается с контекстной диаграммы и заканчивается спецификациями модулей.
Контекстная диаграмма представляет только один процесс – процесс, который соответству-ет разрабатываемой системе. Цель ее состоит в том, чтобы определить место системы по отноше-нию к окружающей среде. Контекстная диаграмма задает границы системы, определяя ее входы и выходы по отношению к внешним сущностям. Внешние сущности – это организации, отделы, люди, другие системы и т. д., которые при разработке системы находятся вне нее и которые по-ставляют входные данные системе или ожидают от нее выходные данные, или делают и то, и дру-гое. Потоки данных изображаются стрелками, которые так и называются потоками данных.