Файл: Основы проектирования программ. Этапы создания программного обеспечения.pdf

ВУЗ: Не указан

Категория: Курсовая работа

Дисциплина: Не указана

Добавлен: 03.04.2023

Просмотров: 223

Скачиваний: 2

ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.

– обучающие программы;

– программы математических расчетов, моделирования и анализа;

– коммуникационные программы;

– игры.

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

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

– трансляторы;

– непосредственную среду разработки программ;

– отладчики;

– библиотеки справочных программ (процедур и функций);

– редакторы связей и др. [8, c. 109].

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

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

К технологии программирования применяют следующие требования:

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

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

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

4. Все этапы работы коллектива программистов должны быть охвачены средствами автоматизации.

5. Технология программирования не должна зависеть от языка программирования.

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

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


В заключение главы можно сделать следующие выводы:

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

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

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

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

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

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

2 Этапы создания программного обеспечения

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

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


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

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

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

После определения требований к программному обеспечению разработчиком будут получены согласованный четкий план действий, график сроков и оплат. В то же время разработчик может сократить время разработки и повысить ее качество, а также позволяет предусмотреть любые другие нюансы разработки, к примеру, юридические (передача авторских прав на проектируемое программное обеспечение) [12, c. 165].

При проектировании ПО заранее разработчик имеет возможность:

– оценить время разработки и стоимость программного продукта;

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

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

Подготовительный этап.

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

– подготовки;

– проектирования;

– создания, включающего дизайн, кодирование, тестирование, документирование;

– поддержки, включающей внедрение и сопровождение.

В процессе подготовки к проектированию должны быть решены организационные вопросы:

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

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

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

Этапы и результаты проектирования.

Проектирование состоит из следующих этапов:

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


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

3. Разработки технического задания (ТЗ). ТЗ составляет архитектор в соответствии с описанием и ответами на вопросы заказчика. Затем ТЗ согласовывают с менеджером проекта, далее передают клиенту и производят правки.

4. Этапа разработки макетов, которые затем добавляются к ТЗ. На данном этапе разрабатывают макеты принципиальных схем устройства, интерфейсов, диаграмм структуры базы данных, схем взаимодействия компонентов.

5. Контроля. В ходе этого этапа архитектором устраняются замечания менеджера проектов.

6. Утверждения. На данном этапе заказчиком проверяется и меняется самостоятельно ТЗ, либо сообщается список правок проект-менеджеру. После устранения замечаний ТЗ утверждают и прилагают к контракту.

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

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

– как делать (содержит описание архитектуры)?

– как проверить, достигнута ли цель (варианты тестирований, критерии оценки)? [6, c. 43].

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

Требования к ТЗ на разработку программного обеспечения.

Приведем минимальные требования, достаточные для ТЗ, в соответствии с которыми оно должно:

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

– исключить противоречивые сведения;

– быть юридически точно оформленным (согласно ГОСТу), так как наряду с контрактом и прочими документами ТЗ приобретет юридическую силу.

В техническом задании должны содержаться:

– общие данные по проекту (название продукта, категория пользователей и назначение использования);

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


– детальный план работ, содержащий перечень этапов и сроки по каждому из них;

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

– перечень действий, осуществляемых при запуске продукта;

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

В составе ТЗ важно уделить внимание описаниям:

1) конкретных деталей:

– пользователей программного продукта (их роли, права и функции);

– алгоритмов обработки данных;

– перечня закрытых и открытых протоколов;

– требований к безопасности данных в ходе всего жизненного цикла;

– списка используемых в разработке компонентов (свободных, платных);

2) примеров:

– аналогов, интегрируемых систем с указанием ссылок на них;

– типичных сценариев взаимодействия системы с пользователем;

– входящих данных и форматов данных взаимодействия подсистем (таблиц, баз, страниц и др.);

– исходящих данных (видов отчетов и экспортируемых файлов);

3) надежности и производительности:

– уровней нагрузки системы (день, месяц, максимальный);

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

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

2.2 Этапы проектирования базы данных

Процесс проектирования базы данных делится на следующие этапы:

1) инфологическое проектирование базы данных;

2) изложение требований к той операционной обстановке, в которой планируется использование информационной системы;

3) определение с СУБД и другого программного обеспечения;

4) логическое проектирование базы данных;

5) физическое проектирование базы данных;

6) инфологическое проектирование [5, c. 89].

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

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