Технология разработки программного обеспечения

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

БПОУ СПО "Сибирский профессиональный колледж"

Специальность 09.02.03 "Программирование в компьютерных системах"

Контрольная работа

Технология разработки программного обеспечения

Ваулин А.Э. студент 3 курса заочной формы обучения

Абдуллаева Л.А. - преподаватель

1.Техническое задание на разработку ПО. Назначение. Этапы составления. Структура технического задания

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

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

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

Этапы составления ТЗ:

1. Цели проекта.

2. Промежуточные результаты работы.

3. Контрольные точки.

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

5. Ограничения и исключения.

6. Проверка выполнения работы совместно с клиентом.

1. Цели проекта. Первым этапом в определении ТЗ является определение основных целей для удовлетворения потребностей клиента. Например, в результате глубокого анализа рынка компания, занимающаяся компьютерными программами, решает разработать программу, способную автоматически переводить с английского на русский. Проект должен быть выполнен за три года при затратах, не превышающих $1,5 млн. Или такой проект -- спроектировать и выпустить полностью портативную систему термической переработки вредных отходов за 13 месяцев при затратах, не превышающих $13 млн.

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

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

4. Технические требования. Обычно товар или услуга для того, чтобы хорошо работать, должны отвечать техническим требованиям. Например, техническим требованием к ПК может быть способность работать от сети переменного тока в 120 вольт или от постоянного тока в 240 вольт без адаптеров. Еще одним известным примером является способность системы 911 определить местонахождение и номер телефона звонящего.

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

6. Проверка выполнения работы совместно с заказчиком. Контрольный список вопросов ТЗ проекта заканчивается совместной с заказчиком проверкой выполнения работы. Основной проблемой является понимание и согласие заказчика с ожидаемыми результатами. Получает ли заказчик в виде промежуточных результатов то, что он хочет? Указывает ли определение проекта ключевые достижения, сметы, сроки и требования к выполнению работ? Рассматриваются ли вопросы ограничений и исключений? Обсуждение всех этих вопросов крайне необходимо во избежание недопонимания.

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

Структура технического задания, основными разделами ТЗ являются:

1. Общие сведения.

2. Назначение и цели создания (развития) системы.

3. Характеристика объектов автоматизации.

4. Требования к системе.

5. Состав и содержание работ по созданию системы.

6. Порядок контроля и приемки системы.

7. Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие.

9. Источники разработки. Все эти разделы могут быть разбиты на подразделы и могут включать приложения, которые приводятся в конце документа и оформляются как приложения к ТЗ. Такой же состав имеет и ЧТЗ, которое может создаваться при итерационном подходе в больших проектах для уточнения требований. ТЗ на СЭД должно оформляться на листах формата А4 по ГОСТ 2.301-68* без рамки, основной надписи и дополнительных граф к ней. Номера листов (страниц) проставляют, начиная с первого листа, следующего за титульным листом, в верхней части листа (над текстом, посередине) после обозначения кода ТЗ на СЭД. Титульный лист ТЗ содержит следующие реквизиты: * гриф «Утверждаю»; * полное наименование СЭД; * наименование документа (в нашем случае - «Техническое задание» и «Частное техническое задание»); * код документа; * количество листов; * место составления документа. Также на титульном листе могут проставляться согласующие визы, либо они выносятся на отдельный лист согласования. Следующим после титульного листа идет лист с информацией о разработчиках документа - авторах, составивших текст документа или принявших технические решения, описанные в ТЗ. Лист согласования и информация о разработчиках документа могут оформляться на одном листе ТЗ - последнем, согласно рекомендациям ГОСТ 34.602-89 (Приложение 3 к ГОСТу). Код ТЗ на СЭД - это обозначение конструкторского документа, которое присваивается заказчиком или разработчиком документа согласно ГОСТ 2.201-80**. Код состоит из следующих частей: первые 4 символа - код организации-разработчика, следующие 6 символов - код классификационной характеристики, следующие 3 цифры - порядковый регистрационный номер. Например, номер ТЗ может выглядеть так: ЦНТП. 425180.048. Особенности написания некоторых разделов ТЗ Раздел «Общие сведения» должен включать сведения о заказчике и возможном исполнителе работ, о способе определения исполнителя, бюджете, из которого финансируется создание СЭД, и примерных сроках и этапах проведения работ по созданию СЭД. Например, в этом разделе может быть указано, что исполнитель определяется путем заключения государственного контракта. Раздел «Назначение и цели создания (развития) системы» должен содержать описание основной цели создания системы и результатов, которые заказчик предполагает получить от внедрения системы. Эти результаты должны быть экономически измеримы или могут быть указаны способы их измерения.

Например, целью внедрения СЭД может быть сокращение сроков согласования договоров до 1 рабочего дня по всем филиалам компании. Раздел «Характеристика объектов автоматизации» содержит описание процессов в организации, требующих автоматизации, и является итогом отчета об информационном обследовании, который составляется при обследовании процессов организации. Раздел «Требования к системе» является основным разделом ТЗ. Этому разделу следует уделить особое внимание, т. к. именно он регламентирует и закрепляет множество технических особенностей будущей системы. В данном разделе должны быть описаны следующие требования: 1. Требования к системе в целом, включая требования к архитектуре системы, составу рабочих мест, требования к персоналу системы, требования к надежности, требования к эргономике, требования к обеспечению режима секретности (если конфиденциальные документы обрабатываются в системе), требования к защите информации от несанкционированного доступа, требования к масштабированию системы и другие. 2. Требования к функциям (задачам), выполняемым системой, должны содержать описание функционала подсистем (модулей) СЭД. 3. Требования к взаимодействию подсистем (модулей) СЭД должны описывать механизмы взаимодействия подсистем (модулей). 4. Требования к взаимосвязи со смежными системами организации должны описывать, какие системы являются смежными и как они могут быть связаны с СЭД. Например, система кадрового учета может предоставлять списки пользователей для СЭД. 5. Требования к режиму функционирования СЭД должны содержать описание режима функционирования (например, 24 часа 7 дней в неделю) и порядок проведения профилактических работ по переустановке системы или по ее обновлению. Например, обновление системы должно проводиться без остановки функционирования системы. 6. Требования к видам обеспечения должны содержать: лингвистическое обеспечение системы, требования к входным и выходным формам СЭД, требования к базам данных, требования к организационному обеспечению, требования к информационному, программному и техническому обеспечению системы. 7. Требования к администрированию системы с описанием ролей и обязанностей администраторов системы. Раздел «Состав и содержание работ по созданию системы» целесообразно делать в виде таблицы с указанием наименования этапов работ по созданию СЭД, примерных сроков начала и окончания этапов, а также результатов окончания этих этапов.

Раздел «Порядок контроля и приемки системы» должен определять, какие виды испытаний необходимо провести для приемки системы, включая перечень документации, требуемой для проведения этих испытаний. Например, для ввода системы в действие могут быть проведены ведомственные испытания согласно разработанной и утвержденной заказчиком программе и методике испытаний. Раздел «Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие» описывает перечень мероприятий по обучению пользователей СЭД, по разработке пособий и методических материалов, требования к проведению конвертации данных или вводу первоначальных данных в СЭД, требования к созданию инфраструктуры для функционирования СЭД. Раздел «Требования к документированию» описывает общие правила составления рабочей документации к системе и может ссылаться на корпоративные стандарты или ГОСТы. Раздел «Источники разработки» является заключительным и перечисляет документы, которые послужили основой для разработки системы и принятия тех или иных технических решений. При этом в тексте ТЗ должны быть проставлены ссылки на все источники разработки. Указание того или иного источника должно быть обоснованным и подтверждаться в тексте ТЗ.

2. Организация процесса проектирования П.О. Декомпозиция системы. Методы проектирования структуры П.О.

проектирование проект программный

Последовательность процесса проектирования, вообще говоря, может различаться даже для одного и того же класса объектов. Причинами этого могут быть: исторический опыт и традиции" сложившиеся в проектной организации; наличие или отсутствие прототипа; установленные сроки и финансовые ресурсы и др.

На рис.1 приведена типовая логическая схема традиционного не автоматизированного проектирования.

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

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

Рис.1. Логическая схема традиционного неавтоматизированного проектирования

Рис.2. Структурная схема итерационного алгоритма процесса проектирования при декомпозиции процесса по уровням описания

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

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

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

При автоматизированном проектировании технология процесса проектирования в значительной мере определяется структурой и мощностью САПР.

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

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

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

Анализ методов размещения объектов со связями.

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

Трудности в автоматизации решения таких задач:

- решение их с достаточной точностью требует очень большого (невыполнимого) объема вычислений,

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

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

При решении задачи учитываются дополнительные ограничения:

- объекты не пересекаются с запрещенными областями,

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

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

Классификация задач компоновки:

- по количеству объектов - один или много;

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

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

- по мощности множества вариантов - непрерывные или дискретные задачи;

- размещение объектов характеризуется двумя параметрами - приведенной стоимостью связей и оценкой компактности;

- по количеству соединяемых объектов - соединение двух объектов, одного с тремя, соединение n объектов, наличие циклов в связях;

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

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

Список использованных источников

проектирование проект программный

1. Маклаков С.В. BPWin и ERWin CASE - средства разработки информационных систем / Маклаков С.В. - М: ДИАЛОГ МИФИ, 2001.-256с.;

2.ГОСТ 34.602-89 Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы

3.Инфопедия . Методы пректирования [Электронный ресурс]. Режим доступа: www.infopedia.su

4.Студопедия. Декомпозиция задачи проектирования. [Информационно студенческий ресурс]: www.studopedia.ru

5.Бойко В.В. Проектирование баз данных информационных систем / Бойко В.В., Савинков В.М. - 2-е изд. - М.: Финансы и статистика, 1989. - 350 с.

Размещено на Allbest.ru