Технология создания программной системы

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Введение

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

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

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

перечисление условий, при которых выполняется та или иная операция

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

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

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

Основные тенденции образования и развития технологии программирования

1й этап: Стихийное программирование от начала 60х годов.

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

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

не соблюдались сроки создания

проект устаревал раньше, чем был готов

увеличивалась его стоимость

Многие проекты так и не были запущены!

2й этап: Структурный подход к программированию 60-70гг.

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

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

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

3й этап: Объектный подход к программированию 80-90гг

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

Развитие технологий программирования основанных на объектном подходе позволило создать визуальное программирование. Результатом ориентированного программы является заготовка программы в которую уже вмещены. Объектный метод имеет ряд недостатков:

Отсутствуют стандарты компоновки, объектов в единое целое

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

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

Компонентный подход и CASE - технологии.

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

Компонентный подход лежит в основе технологий разработанный на базе COM (component object model) и технологии распределённых систем COBRA общая архитектура с посредником обработки запросов. Технологи СОМ определяет общие правила взаимодействия программ любых типов: библиотек, приложений, ОС. И позволяет одной части ПО использовать функции другой в пределах одного процесса. Технология COBRA можно использовать для создания определённого ПО в разнородной вычислительной среде, принцип такой же как и у СОМ. Отличительной особенностью современного этапа развития технологий является создание и внедрение автоматизированных технологий которые назвали KASSE технологии/ На сегодня поддерживающий как объектный так и структурный. В течении последних лет появился и получил развитие унифицированный язык модулирования UML - он является основой, для целого спектра различных средств программирования.

Проблемы разработки сложных программных систем

Сложные ПО:

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

коллективная разработка

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

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

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

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

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

Коллективная разработка

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

Жизненные циклы разработки ПО.

Жизненным циклом ПО называют период с момента появления идеи ПО до момента завершения его поддержки фирмой разработчиком. Состав процессов жизненного цикла регламентируется международным стандартом ISO/IEC 12207, который называется информационные технологии.

ISO - международная организации по стандартизации

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

Основные процессы: приобретение, поставка, разработка, эксплуатация, сопровождение.

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

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

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

1. подготовительная работа - план работы, определяются стандарты и методы разработки

2. анализ требуемый к системе - пользоват треб, треб по безопасности

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

4. детальное проектировании ПО - определяются интерфейсы, разработка и тестинг

5. кодирование и тестирование ПО

6. интеграция ПО - все компоненты собираются в единое целое

7. тестирование ПО

8. квалификационное тестирование системы - оформление полноты документации

9. Установка ПО на оборудование заказчика

10. Приём ПО (подписание договоров)

Все указанные действия можно условно выделить в стадии разработки по ГОСТу 19.102-77

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

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

Различают:

- функциональные

- эксплуатационные

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

Проектирование - стадия технического проекта. Проектирование включает в себя:

- проектирование общей структуры

- декомпозицию компонентов

- проектирование этих компонентов

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

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

Существует 5 этап - сопровождение (сейчас не входит) - создание и внедрение новых версий.

Для всех этапов разработки существует 3 модели жизненного цикла программного обеспечения.

1. Каскадная

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

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

Достоинства:

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

простота планирования процесса разработки.

Недостатки:

при неточных спецификациях приводят к пересмотру уже принятых решений.

Изменение требования заказа непосредственно в процессе разработки.

2. Модель с промежуточным контролем.

В данной схеме можно вернуться на любой уровень.

3. Спиральная модель

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

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

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

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

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

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

Поддержка полного жизненного цикла ПО

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

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

Минимальное время получения работоспособной системы

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

Независимость выполняемых проектных решений от средств реализации.

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

Анализ и планирование требования пользователя

Проектирование

Реализация

Внедрение

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

Нормы определяющие количество человек для разработки человек: менее 1000 функциональных точек - 1 человек, от 1-4000 точек - команда (3-7 человек). На каждые 4000 точек - 1 команда.

На этапе реализации выполняется интерактивное построение реальной системы. На этом этапе активно работают с заказчиками.

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

Оценка качества процессов создания ПО

В Текущий период рынок ПО характеризуется переходом от штучного производства ПО к промышленному.

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

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

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

Пять уровней технологической зрелости

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

Уровень 1: Начальный (Initial) -- технология разработки ПО характеризуется как произвольная (импровизированная), в некоторых случаях -- даже хаотическая. Лишь некоторые процессы определены, успех всецело зависит от усилий отдельных сотрудников.

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

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

Уровень 4: Управляемый (Managed) -- детальные метрики (объективные данные) о качестве исполнения процессов и выходной продукции собираются и накапливаются. Управление процессами и выходной продукцией осуществляется по количественным оценкам.

Уровень 5: Оптимизируемый (Optimized) -- совершенствование технологии создания ПО осуществляется непрерывно на основе количественной обратной связи от процессов и пилотного внедрения инновационных идей. На этом уровне идёт постоянное улучшение существующих процессов, т.е. постоянно вводятся новые технологии для эффективности разработки ПО. стандарт ISO/IES 15504 (SPACE) - она определяет возможности для улучшения процесса создания ПО. В основе стандарта лежит оценка процесса. Оценка выполняется путём сравнения процесса разработки ПО в данной организации с описанной в стандарте модели. Этот анализ помогает определить сильные и слабые стороны процесса, а также внутренние риски присущие данному процессу. Это помогает оценить эффективность процессов, определить причины ухудшения качества и связанные с этим издержки во времени и стоимости. В основе стандарта так же лежит определения возможности процесса, т.е. возможности его улучшения.

Понятие технологичности ПО

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

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

1 точка входа

1 точка выхода.

Отдельная компиляция

Соответствие принципу вертикального управления

Выполнение одной функции

Небольшой размер (50-70 операторов)

Возможность вызова других модулей

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

Существует 5 типов сцепления модулей:

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

сцепление по образцу - модули обмениваются данными, объединённые в некоторые структуры (элементы массива)

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

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

Сцепление по содержимому - один модуль содержит обращение к внутренним компонентам другого. Такой вид сцепления тоже не допустим.

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

Функциональная

Последовательная

Информационная (коммуникативная)

Процедурная

Временная

Логическая

Случайная

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

Последовательная - выход одной функции служит исходными данными для другой функции.

Информационная - считается функция обрабатывающая одни и те же данные.

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

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

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

Случайная - связь между элементами мала или отсутствует.

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

Нисходящая и восходящая разработка ПО

При проектировании, реализации и тестировании ПО применяют 2 подхода: восходящий и нисходящий.

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

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

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

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

Проблемы:

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

ранняя разработка модулей вывода результатов

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

Комбинированный метод учитывает следующие факторы влияющие на последовательность разработки:

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

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

обеспечение возможности выдачи результатов

готовность вспомогательных модулей.

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

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

Возможность показать продукт заказчику на ранних стадиях разработки

Возможность нисходящего тестирования.

Эффективность и технологичность ПО

Эффективными считаются программы, которые требуют минимального времени выполнения, и минимального объёма оперативной памяти.

Для экономии памяти предлагается:

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

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

Уменьшение времени выполнения программы:

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

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

3. минимизировать преобразование типов в выражение

4. оптимизировать запись условных выражений

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

Программирование с защитой от ошибок

Любая ошибка программирования которая не обнаруживается на этапах компиляции и компоновки в конечном счёте всё равно может проявиться:

способ: выдача системного сообщения об ошибке

способ: зависание компьютера

способ: получение не верных результатов

программный система интерфейс

Способы проявления ошибок

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

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

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

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

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

Проверка допустимость индекса массива.

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

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

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

Избегать вычитания близких чисел.

Избегать деление больших чисел на малые

Снижать длинную последовательность чисел

По возможности уменьшить количество операций с числами

Использовать методы уже с известными оценками погрешности

Не использовать условия равенства вещественных чисел, особенно с одинарной точностью

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

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

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

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

К каждому типу ПО при разработке предъявляют функциональные и эксплуатационные требования. Эти требования определяют некоторые характеристики разрабатываемого ПО, предъявляемые к нему в процессе его функционирования. К этим характеристикам относится:

1. Правильность - функционирование в соответствии с техническим заданием, это требование является обязательным для любого ПО, т.е. всё что указано в ТЗ дБ реализовано.

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

3. Надёжность - обеспечение полной повторяемости результатов и обеспечения их правильности при различного рода сбоев оборудования.

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

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

6. Защищённость - обеспечение конфиденциальности информации. Для защищённости применяют программные средства защиты (коды, алгоритмы), кодирование информации, идентификация пользователя.

7. Программная совместимость - возможность функционирования с другим ПО.

8. Аппаратная совместимость - возможность совместного функционирования с разным оборудованием

9. Эффективность - использование минимального возможного количества ресурсов технических средств (время ответа системы, объём оперативной памяти, количество обслуживаемых внешних устройств)

10. Адаптируемость - возможность быстрой модификации для приспособления к изменяющимся условиям функционирования.

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

Разработка технического задания

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

Схема: факторы определяющие параметры разрабатываемого ПО.

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Основными факторами определяющими характеристики разрабатываемого ПО являются:

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

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

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

Разработка ТЗ ведётся в следующей последовательности:

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

Определяют перечень результатов и способы их представлений

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

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

На разработку ТЗ существует ГОСТ 19.201-78 «Техническое задание. Требования к содержанию и оформлению». В соответствии с этим ТЗ должно содержать следующие разделы:

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

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

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

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

Требования к функциональным характеристикам. Что должна делать система.

Требования к надёжности.

Условия эксплуатации.

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

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

Требования к маркировки и упаковки.

Требования к транспортировки и хранении.

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

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

Технико-экономические показатели. Указывается экономическая эффективность и экономические преимущества по сравнению с существующими аналогами.

Стадии и этапы разработки. Указываются стадии и этапы разработки и содержание работ с указанием сроков разработки и исполнителей.

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

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

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

Принципиальные решения начальных этапов проектирования

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

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

Разделяют:

-однопользовательскую архитектуру

-многопользовательскую архитектуру

К однопользовательским относят:

-программы

-пакеты программ

-программные компоненты

-программные Системы

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

Пакеты программ представляют собой совокупность программ, решающие задачи, некоторой прикладной области (AvtoCad)

Программ. Комплексы - совокупность программ совместно обеспечивающих решение небольшого класса сложных зад-ч 1 приклад. обл-и.

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

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

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

Многопользовательская архитектура испол-я при разр-и приложений по приему клиент - сервер

2)Выбор типа пользовательского интерфейса и технологии работы с документами.

Различают 4 типа пользовательского интерфейса:

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

меню - реализуют ти-во спе-в раб-ты, операции которых организованны в шрарх. стру-ры.

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

Прямого манипулирования - основные операции перемещения мышью.

Выбор под-а к разр-ки; какой пор-у выб-ют:

-структурный

-процедурный

- ОО (че за ОО х3, может и не ОО)

Если разраб-я инт-с со свобод. новит-ей и прям. манипул., то испол-я объективно-орентир. подход (использование классов)

Примитивный интерфейс (старый подход)

4) Выбор языка программирования

1. Язык может выбр-ть организ-я, вед-я раз-ку.

2.Выбор, осущест-я программистом

3.установ. мнением.

Выбор возможен, если все языки разделить на группы:

Универсальные языки высокого уровня

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

Специальные языки языки польз-ля - явл-я частью профессиональных сред. польз-ля и харак - я узкой напр-ю (1С)

Языки низкого уровня (Ассемблер)

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

Выбор и формирование стандарта разр-ки

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

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

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

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

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

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

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

При структурном подходе на этапе анализа и определения спецификации используют 3 типа модели:

Модель ориентированная на функции

Модель ориентированная на данные

Модель ориентированная на потоки данных

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

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Диаграммы переходов состояний

Является графической формы представлений конечной модели используемой для моделирования поведения технических объектов или объектов реального мира. Диаграммы переходов состояний моделирует поведение разрабатываемой системы при получении управляющих воздействий. Под управляющим воздействием понимают команды пользователя или сигналы датчика. Получив управляющее воздействие система может выполнить 3 действия:

Выполнить определённое действие

Остаться в том же состоянии

Перейти в новое состояние

Условное обозначение диаграмм переходов состояний:

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Терминальное состояние (начальное и конечное)

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Промежуточное состояние

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

переход

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

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Диаграммы переходов состояний ПО активно взаимодействующего с окружающей средой

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Пример построения диаграммы переходов состояний для программы построения графиков функций для кот было представлено ТЗ.

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

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

Функциональные диаграммы

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

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Блоки на диаграмме размещают по ступенчатой схеме в соответствии с последовательностью их работы или доминированию. Доминирование - оказывание одним блоком на другие. Различают 5 типов влияния:

Вход-выход

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Управление

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

обратная связь по выходу

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Выход исполнитель

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Обратная связь по управлению.

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

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

Символ обозначает тип связи:

I - входная информация

С - управляющая

М - механизм

R - результат

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

Все диаграммы связываются друг с другом и иерархической нумерацией блоков:

1й уровень нумеруется А0

2й уровень- А1, А2……

3й уровень - А11, А12, А21, А22……..

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

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

Термин: Алгоритм

Категория: Понятия предметной области

Описание: В данном проекте используется для обозначения команд

Пример: функциональная диаграмма для построения графиков:

Верхнего уровня

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Детализированная диаграмма

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

I1 - функция

I2 - отрезок

I3 - шаг

С1 - вид график/функция

R1 - график

R2 - таблица значений

Диаграмма потоков данных

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

В основе этой модели лежат понятия:

Внешняя сущность - материальный объект или физическое лицо выступающее в качестве источников или приёмников информации

Процесс - преобразование входных потоков данных в выходные в соответствии с определённым алгоритмом.

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

Хранилище данных - абстрактное устройство для хранения информации.

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

Поток данных - процесс передачи инфы от источника к приёмнику.

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

Для изображения диаграмм потоков данных используют 2 способа:

Понятие	Йордана Де Морга	Гейна-Сарсона
	Внешняя сущность

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

	Процесс

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

	Накопитель данных

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

	Поток

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

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

Диаграмма по Гейна-Сарсену

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Структура данных и диаграммы отношения компонентных данных

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

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

2. конкретные структуры - используются для представления данных в программах

Все абстрактные структуры делятся на 3 группы:

Не связанные - элементы которых не связаны между собой. К ним относятся множества и кортежи.

С не явными связями. К ним относятся вектор, матрица, массив, запись, строка и т.д.

С явными связями (графы). К ним относятся цепь, цикл, дерево, ориентированный граф, взвешенный граф, мультиграф.

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

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

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

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

Диаграмма Джексона

В основе диаграмм Джексона лежит предположение о том, что структуры данных, так же как и программ можно строить из элементов с использованием всего 3х основных конструкций (последовательности, выбора, повторения). Каждая конструкция представляется в виде 2х уровней иерархии. На верхнем расположен блок конструкция, на нижнем блоки элементов. Конструкции различают специальными символами в правом верхнем углу блоков элементов. При изображении последовательности символ не указывается. При изображении выбора ставится символ «О» - сокращённое от OR «ИЛИ». Конструкции последовательности и выбора обязательно должны содержать по 2 или более элементов 2го уровня. При изображении повторения в блоке единственного (повторяющегося) элемента ставится значок *

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Скобочные диаграммы Орра

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

Пример: Описать структуру данных файла «Электронная ведомость» которая отображает № группы, записи об успеваемости студентов (ФИО, предмет, оценка)

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Сетевые модели данных

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

Модель П.Чена

модель Баркера

модель IDEF1

Модель Баркера является наиболее распространённой.

Базовыми понятиями сетевой модели данных являются: сущность, атрибут и связь.

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

уникальное имя

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

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

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

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

...