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

 

 

Содержание

Ведение……………………………………………………………3

1. Проектирование программного обеспечения…………….…………….5
1. Основы проектирования…………………………………………………5
2. Ключевые вопросы проектирования……………………………………8
3. Структура и архитектура программного обеспечения………………..10
4. Анализ качества и оценка программного дизайна…………………….13
5. Нотации проектирования………………………………………..….…...14
6. Стратегии и методы проектирования программного обеспечения…..18
2. Качество программного обеспечения…………………………………..20
1. Основы качества программного обеспечения…………………………20
2. Культура и этика программной инженерии……………………………21
3. Модели и характеристики качества…………………………………….21
4. Процессы управления качеством программного обеспечения……….24

Список используемой литературы

 

 

Введение

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

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

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

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

Одним из подходов для оценки программных средств является оценка соответствующих атрибутов качества, определённых в серии международных стандартов ГОСТ Р ИСО МЭК 9126 «Информационная технология – Оценка программной продукции».

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

 

 1.    Проектирование программного обеспечения

1.1 Основы проектирования

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

Проектирование подразумевает выработку свойств системы на основе анализа постановки задачи, а именно: моделей предметной области, требований к ПО, а также опыта проектировщика. Требования к ПО определяют внешние (видимые) свойства программы, рассматриваемой как чёрный ящик.

Определению внутренних свойств системы и детализации её внешних свойств собственно и посвящено проектирование. Проектирование ПО является частным случаем проектирования продуктов и проектирования систем. В зависимости от класса создаваемого ПО, процесс проектирования может обеспечиваться как «ручным» проектированием, так и различными средствами его автоматизации. В процессе проектирования ПО для выражения его характеристик используются различные нотации - блок-схемы, ER-диаграммы, UML-диаграммы, DFD-диаграммы, а также макеты.

Проектированию обычно подлежат:

- Архитектура ПО;

- Устройство компонентов  ПО;

- Пользовательские интерфейсы.

В российской практике результат проектирования представляется в виде комплекса документов под названием «Эскизный проект», «Технический проект», в зарубежной - Software Architecture Document, Software Design Document.

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

Для таких методов характерно:

- Разбиение системы на  уровни с ограничением числа  элементов.

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

- Использование сторонних  формальных правил записей.

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

Принципы структурного метода: - принцип «разделяй и властвуй»; - принцип «иерархического упорядочивания»; - принцип абстрагирования - выделение существенных аспектов системы и отвлечение от несущественных; - принцип непротиворечивости; - принцип структурирования данных.

 Виды проектирования:

Функционально-ориентированное или структурное проектирование

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

 Объектно-ориентированное  проектирование.

Представляет собой множество методов проектирования, базирующихся на концепции объектов. Данная область активно эволюционирует с середины 80-х годов, основываясь на понятиях объекта (сущности), метода (действия) и атрибута (характеристики). Здесь главную роль играют полиморфизм и инкапсуляция, в то время, как в компонентно-ориентированном подходе большее значение придается мета-информации, например, с применением технологии отражения. Хотя корни объектно-ориентированного проектирования лежат в абстракции данных (к которым добавлены поведенческие характеристики), так называемый responsibility-driven design или проектирование на основе функциональной ответственности по SWEBOK (такое противопоставление – достаточно спорный вопрос, так как функциональная ответственность столь же близка принципам современного объектно-ориентированного проектирования, сколь и абстракция данных. Это вопрос эволюционирования взглядов и степени их консерватизма) может рассматриваться как альтернатива объектно-ориентированному проектированию.

 Проектирование на  основе структур данных (Data-Structure-Centered Design). В данном подходе фокус сконцентрирован в большей степени на структурах данных, которыми управляет система, чем на функциях системы. Инженеры по программному обеспечению часто вначале описывают структуры данных входов (inputs) и выходов (outputs), а, затем, разрабатывают структуру управления этими данными (или, например, их трансформации).

Компонентное проектирование (Component-Based Design).

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

Компонентно-ориентированное проектирование является одной из наиболее динамично развивающихся концепций проектирования и может рассматриваться как предвестник и основа сервисно-ориентированного подхода (Service-Oriented Architecture, SOA) в проектировании, не рассматриваемого, к сожалению, в SWEBOK, но все более активно использующегося в индустрии и смещающего акценты с аспектов организации связи интерфейс-реализация к обмену информацией на уровне интерфейс-интерфейс (то есть – межкомпонентному взаимодействию). По мнению автора книги, уже наступил тот момент, когда необходимо вводить отдельную тему, посвященную сервисно-ориентированному подходу в проектировании и сервисно-ориентированным архитектурам, как моделям. В частности, нотация UML 2.0 уже позволяет решать ряд вопросов, связанных с визуальным представлением соответствующих архитектурных решений, где сервисы (службы) могут рассматриваться как публикуемая функциональность одиночных компонентов и групп компонентов, объединенных в более «крупные» блоки, обеспечивающие предоставление соответствующей сервисной функциональности.

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

1.2 Ключевые вопросы проектирования

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

Параллелизм.

Эта тема охватывает вопросы, подходы и методы организации процессов, задач и потоков для обеспечения эффективности, атомарности, синхронизации и распределения (по времени) обработки информации.

Контроль и обработка событий

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

Распределение компонентов.

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

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

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

Взаимодействие и представление.

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

 

 

1.3 Структура и архитектура программного обеспечения

В строгом значении архитектура программного обеспечения -описание подсистем и компонент программной системы, а также связей между ними. Архитектура пытается определить внутреннюю структуру получаемой системы, задавая способ, которым система организована или конструируется. В середине 90-х, на волне распространения клиент-серверного подхода и начала его трансформации в “многозвенный клиент-сервер”, призванный обеспечить централизованное развертывание и управление общей (для клиентских приложений) бизнес-логикой, вопросы организации архитектуры программного обеспечения стали складываться в самостоятельную и достаточно обширную дисциплину. В результате, сформировалась точка зрения на архитектуру не только в приложении к конкретной программной системе, но и развился взгляд на архитектуру, как на приложение общих принципов организации программных компонент. В итоге, уже на сегодняшний день, на фоне такого развития понимания архитектуры, накоплен целый комплекс подходов и созданы (и продолжают создаваться и развиваться) различные архитектурные “фреймворки”, то есть систематизированные комплексы методов, практик и инструментов, призванные в той или иной степени формализовать имеющийся в индустрии опыт (как положительный – например, design patterns, так и отрицательный – например, anti-patterns).

Примеры такой систематизации в форме фреймворков:

• TOGAF [TOGAF81, 2003] – The Open Group Architecture Framework (на момент написания данной главы доступен в версии 8.1, впервые опубликованной в декабре 2003 года)

Модель Захмана – Zachman Framework [Zachman]

Руководство по архитектуре электронного правительства E-Gov Enterprise Architecture Guidance [E-Gov, 2002]

Архитектурные структуры и точки зрения

Любая система может рассматриваться с разных точек зрения – например, поведенческой (динамической), структурной (статической), логической (удовлетворение функциональным требованиям), физической (распределенность), реализации (как детали архитектуры представляются в коде) и т.п. В результате, мы получаем различные архитектурные представления (view). Архитектурное представление может быть определено, как частные аспекты программной архитектуры, рассматривающие специфические свойства программной системы. В свою очередь, дизайн системы – комплекс архитектурных представлений, достаточный для реализации системы и удовлетворения требований, предъявляемых к системе. SWEBOK не дает явного определения, что такое “архитектурная структура”. В то же время это понятие достаточно важно. Я хотел бы предложить его толкование как применение архитектурной точки зрения и представления к конкретной системе и описания тех деталей, которые необходимы для реализации системы, но отсутствуют (в силу достаточно общего взгляда) в используемом представлении. Таким образом, представление (view), концентрируясь на заданном подмножестве свойств является составной частью и/или результатом точки зрения, а архитектурная структура -дальнейшей детализацией в отношении проектируемой системы.

Архитектурные стили

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

Шаблоны проектирования.

Наиболее краткая формулировка того, что такое шаблон проектирования, может звучать так «общее решение общей проблемы в заданном контексте». Что это значит в реальной жизни? Если мы хотим организовать системы таким образом, чтобы существовал один и только один экземпляр заданного ее компонента в процессе работы с данной системой – мы можем использовать шаблон проектирования “Singleton”, описывающий такое общее поведение.