Автор Анна Евкова
Преподаватель который помогает студентам и школьникам в учёбе.

Основы проектирования программ. Этапы создания программного обеспечения(Основы проектирования программ)

Содержание:

Введение

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

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

Глава первая.

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

Каждая программа, да и почти любое дело начинается с проекта.

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

После того как примерный проэкт согласован начинаются этапы проэкта.

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

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

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

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

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

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

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

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

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

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

3) принцип развития, предусматривающий в ПО возможность его наращивания и совершенствования компонентов и связей между ними;

4) принцип комплексности, заключающийся в том, что ПО обеспечивает связанность обработки информации как отдельных элементов, так и всего объема данных в целом на всех стадиях обработки;

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

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

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

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

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

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

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

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

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

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

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

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

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

Повторяемость — в использовании существующего опыта проектирования.

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

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

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

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

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

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

Конечность. Алгоритм всегда должен заканчиваться после выполнения конечного числа шагов.

Определенность. Каждый шаг алгоритма должен быть точно определен.

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

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

Эффективность. Алгоритм обычно считается эффективным, если его операторы достаточно просты для того, чтобы их можно было точно выполнить при помощи карандаша и бумаги в течение конечного промежутка времени.

Термин «эвроритм» науки эвристика образован от легендарного возгласа Архимеда «Эврика!», что в переводе с греческого означает «нашел, открыл». Алгоритм в процессе выполнения не изменяется бездумным исполнителем (процессором). В отличие от алгоритма эвроритм выполняется мыслящим человеком, который может усовершенствовать порядок своей работы в процессе ее выполнения. Эвроритм может включать алгоритмы. Например, инструкция пользования программой — это эвроритм, особенно если одни и те же действия можно выполнить разными способами (через пункт меню или нажатием кнопки).

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

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

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

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

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

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

При исследовании систем решаются задачи анализа и синтеза.

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

Синтез (от греч. synthesis— соединение, сочетание, составление) - метод научного исследования явлений действительности в их единстве и целостности, во взаимодействии их частей, обобщение, сведение в единое целое.

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

В теории проектирования используются следующие понятия анализа и синтеза.

Анализ —процесс определения функционирования по заданному описанию системы.

Синтез— процесс построения описания системы по заданному функционированию.

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

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

Программный продукт является разработанной программистом информационной технологией, которая материализуется у заказчика в виде изделия, становясь автоматизированными системами и инструментами их обслуживания. Это объяснение, по-видимому, снимает многие правовые проблемы, а также проблемы ценообразования. В каждой программе есть свои особенности и один человек много об этом пишет, давайте рассмотрим, Томас Кун в 1977г. определил термин «парадигма» как свод норм научного мышления. Парадигма — это правило (modus operandi) развития научного знания. Оно в течение определенного времени дает научному сообществу модель постановки проблем и их решений.

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

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

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

—процедурно-ориентированные — алгоритмы;

—объектно-ориентированные — классы и объекты;

—логически-ориентированные — цели, выраженные в исчислении предикатов;

—ориентированные на правила — правила «если…, то…»;

—ориентированные на ограничения — инвариантные соотношения;

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

Невозможно назвать какую-либо парадигму наилучшей во всех областях практического применения. Например, для проектирования баз знаний более пригодна парадигма, ориентированная на правила. Объектно-ориентированная парадигма является наиболее приемлемой для широкого круга задач, связанных с большими промышленными системами, в которых основной проблемой является сложность. Уже давно придуманы стандарты в программировании Создание сложной системы немыслимо без стандартов. Они нужны для борьбы с хаосом и неразберихой, но вместе с этим стандарт не должен быть слишком «узким» и мешать техническому прогрессу.

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

Группа стандартов ГОСТ «Единая система программной документации» (ЕСПД) претерпела мало изменений с момента ее создания, пережила несколько поколений ЭВМ и революционных изменений технологий разработки программ. При этом она до настоящего времени никогда не затрудняла новаций.

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

В области программирования общепризнанной ведущей организацией по разработке стандартов является институт ANSI (Американский национальный институт стандартов). Данный институт является лидером по установке стандартов языков программирования, кодовых таблиц клавиш и символов, выводимых на экран, и еще многих других. Необходимо также отметить стандарты ISO.

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

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

В заключительной части этой главы рассмотрим жизненный цикл программы

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

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

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

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

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

2. Глава вторая.

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

Начиная читать про этапы создания программ, я наткнулся на гост (ГОСТ 19.102-77 ЕСПД), а в нем написаны все требования и к стадии разработки программного обеспечения давайте ознакомимся. А там говорится, что начинается все с технического задания. Техническое задание - это постановка задачи - это точная формулировка решения задачи на компьютере с описанием входной и выходной информации. Вот последовательность этапов разработки по госту Техническое задание Обоснование необходимости разработки программы Постановка задачи. Сбор исходных материалов. Выбор и обоснование критериев эффективности и качества разрабатываемой программы. Обоснование необходимости проведения научно-исследовательских работ. Научно-исследовательские работы. Определение структуры входных и выходных данных. Предварительный выбор методов решения задач. Обоснование целесообразности применения ранее разработанных программ. Определение требований к техническим средствам. Обоснование принципиальной возможности решения поставленной задачи Разработка и утверждение технического задания Определение требований к программе Разработка технико-экономического обоснования разработки программы. Определение стадий, этапов и сроков разработки программы и документации на нее. Выбор языков программирования. Определение необходимости проведения научно-исследовательских работ на последующих стадиях. Согласование и утверждение технического задания Эскизный проект Разработка эскизного проекта Предварительная разработка структуры входных и выходных данных. Уточнение методов решения задачи. Разработка общего описания алгоритма решения задачи. Разработка технико-экономического обоснования Утверждение эскизного проекта Разработка пояснительной записки. Согласование и утверждение эскизного проекта Технический проект Разработка технического проекта Уточнение структуры входных и выходных данных. Разработка алгоритма решения задачи. Определение формы представления входных и выходных данных. Определение семантики и синтаксиса языка. Разработка структуры программы. Окончательное определение конфигурации технических средств Утверждение технического проекта Разработка плана мероприятий по разработке и внедрению программ. Разработка пояснительной записки. Согласование и утверждение технического проекта Рабочий проект Разработка программы Программирование и отладка программы. Разработка программной документации Разработка программных документов в соответствии с требованиями ГОСТ 19.101-77. Испытания программы Разработка, согласование и утверждение программы и методики испытаний. Проведение предварительных государственных, межведомственных, приемо-сдаточных и других видов испытаний. Корректировка программы и программной документации по результатам испытаний Внедрение Подготовка и передача программы Подготовка и передача программы и программной документации для сопровождения и (или) изготовления. Оформление и утверждение акта о передаче программы на сопровождение и (или) изготовление. Передача программы в фонд алгоритмов и программ теперь стали понятны все этапы создания программного обеспечения кроме одного есть еще гост ГОСТ 19.101-77, который регламентирует перечень программ и программных документов давайте ознакомимся с ним Вид программы Компонент Определение Программа, рассматриваемая как единое целое, выполняющая законченную функцию и применяемая самостоятельно или в составе комплекса Комплекс Программа, состоящая из двух или более компонентов и (или) комплексов, выполняющих взаимосвязанные функции, и применяемая самостоятельно или в составе другого комплекса Документация, разработанная на программу, может использоваться для реализации и передачи программы на носителях данных, а также для изготовления программного изделия. Вид программного документа. Спецификация содержание программного документа. Состав программы и документации на нее. Вид программного документа. Ведомость держателей. Содержание программного документа. Перечень предприятий, на которых хранят подлинники программных документов. Вид программного документа. Текст программы. Содержание программного документа. Запись программы с необходимыми комментариями. Вид программного документа. Описание программы. Содержание программного документа. Сведения о логической структуре и функционировании программы. Вид программного документа. Программа и методика испытаний. Содержание программного документа. Требования, подлежащие проверке при испытании программы, а также порядок и методы их контроля. Вид программного документа. Техническое задание. Содержание программного документа. Назначение и область применения программы, технические, технико-экономические и специальные требования, предъявляемые к программе, необходимые стадии и сроки разработки, виды испытаний. Вид программного документа. Пояснительная записка. Содержание программного документа. Схема алгоритма, общее описание алгоритма и (или) функционирования программы, а также обоснование принятых технических и технико-экономических решений. Вид программного документа. Эксплуатационные документы. Содержание программного документа. Сведения для обеспечения функционирования и эксплуатации программы, но есть и измененная редакция ознакомимся вид эксплуатационного документа Ведомость эксплуатационных документов Содержание эксплуатационного документа Перечень эксплуатационных документов на программу Вид эксплуатационного документа Формуляр Содержание эксплуатационного документа Основные характеристики программы, комплектность и сведения об эксплуатации программы Вид эксплуатационного документа Описание применения Содержание эксплуатационного документа Сведения о назначении программы, области применения, применяемых методах, классе решаемых задач, ограничениях для применения, минимальной конфигурации технических средств Вид эксплуатационного документа Руководство системного программиста Содержание эксплуатационного документа Сведения для проверки, обеспечения функционирования и настройки программы на условия конкретного применения Вид эксплуатационного документа Руководство программиста Содержание эксплуатационного документа Сведения для эксплуатации программы Вид эксплуатационного документа Руководство оператора Содержание эксплуатационного документа Сведения для обеспечения процедуры общения оператора с вычислительной системой в процессе выполнения программы Вид эксплуатационного документа Описание языка Содержание эксплуатационного документа Описание синтаксиса и семантики языка Вид эксплуатационного документа Руководство по техническому обслуживанию Содержание эксплуатационного документа Сведения для применения тестовых и диагностических программ при обслуживании технических средств В зависимости от способа выполнения и характера применения программные документы подразделяются на подлинник, дубликат и копию (ГОСТ 2.102-68), предназначенные для разработки, сопровождения и эксплуатации программы. Допускается объединять отдельные виды эксплуатационных документов (за исключением ведомости эксплуатационных документов и формуляра). Необходимость объединения этих документов указывается в техническом задании. Объединенному документу присваивают наименование и обозначение одного из объединяемых документов. В объединенных документах должны быть приведены сведения, которые необходимо включать в каждый объединяемый документ. На этапе разработки и утверждения технического задания определяют необходимость составления технических условий, содержащих требования к изготовлению, контролю и приемке программы. Технические условия разрабатывают на стадии «Рабочий проект». Необходимость составления технического задания на компоненты, не предназначенные для самостоятельного применения, и комплексы, входящие в другие комплексы, определяется по согласованию с заказчиком.

Ранее я упомянул еще один гост ГОСТ 2.102-68 в нем говорится о видах и комплектности конструкторских документов давайте ознакомимся с ним К конструкторским документам (именуемым в дальнейшем словом "документы") относят графические и текстовые документы, которые в отдельности или в совокупности определяют состав и устройство изделия и содержат необходимые данные для его разработки или изготовления, контроля, приемки, эксплуатации и ремонта документы подразделяют на виды вид документа чертеж детали определение документ, содержащий изображение детали и другие данные, необходимые для ее изготовления и контроля вид документа сборочный чертеж определение документ, содержащий изображение сборочной единицы и другие данные, необходимые для ее сборки (изготовления) и контроля. К сборочным чертежам, также относят чертежи, по которым выполняют гидромонтаж и пневмомонтаж. Вид документа - чертеж общего вида определение документ определяющий конструкцию изделия, взаимодействие его составных частей и поясняющий принцип работы изделия. Вид документа - теоретический чертеж определение документ, определяющий геометрическую форму (обводы) изделия и координаты расположения составных частей. Вид документа - габаритный чертеж, определение документа, содержащий контурное (упрощенное) изображение изделия с габаритными, установочными и присоединительными размерами. Вид документа - электромонтажный чертеж определение документ, содержащий данные, необходимые для выполнения электрического монтажа изделия. Вид документа - монтажный чертеж определение документа, содержащий контурное (упрощенное) изображение изделия, а также данные, необходимые для его установки (монтажа) на месте применения. К монтажным чертежам также относят чертежи фундаментов, специально разрабатываемых для установки изделия. Вид документа - упаковочный чертеж определение документа, содержащий данные, необходимые для выполнения упаковывания изделия. Вид документа - схема определение документа, на котором показаны в виде условных изображений или обозначений составные части изделия и связи между ними. Вид документа - спецификация определение документа, определяющий состав сборочной единицы, комплекса или комплекта. Вид документа - ведомость спецификаций определение документа, содержащий перечень всех спецификаций составных частей изделия с указанием их количества и входимости. Вид документа - ведомость ссылочных документов определение документа, содержащий перечень документов, на которые имеются ссылки в конструкторских документах изделия. Вид документа - ведомость покупных изделий определение документа, содержащий перечень покупных изделий, примененных в разрабатываемом изделии. Вид документа - ведомость разрешения применения покупных изделий определение документ, содержащий перечень покупных изделий, разрешенных к применению в соответствии с ГОСТ 2.124-85. Вид документа - ведомость держателей подлинников определение документ, содержащий перечень предприятий (организаций), на которых хранят подлинники документов, разработанных и (или) примененных для данного изделия. Вид документа - ведомость технического предложения определение документа, содержащий перечень документов, вошедших в техническое предложение. Вид документа - ведомость эскизного проекта определение документа, содержащий перечень документов, вошедших в эскизный проект. Вид документа - ведомость технического проекта определение документа, содержащий перечень документов, вошедших в технический проект. Вид документа - пояснительная записка определение документа, содержащий описание устройства и принципа действия разрабатываемого изделия, а также обоснование. Вид документа - технические условия определение документа, содержащий требования (совокупность всех показателей, норм, правил и положений) к изделию, его изготовлению, контролю, приемке и поставке, которые нецелесообразно указывать в других конструкторских документах. Вид документа - программа и методика испытаний. Определение: документ, содержащий технические данные, подлежащие проверке при испытании изделий, а также порядок и методы их контроля. Вид документа – таблица. Определение: документ, содержащий в зависимости от его назначения соответствующие данные, сведенные в таблицу. Вид документа – расчет. Определение: документ, содержащий расчеты параметров и величин, например, расчет размерных цепей, расчет на прочность и др. Вид документа - Эксплуатационные документы. Определение: документы, предназначенные для использования при эксплуатации, обслуживании и ремонте изделия в процессе эксплуатации. Вид документа - Ремонтные документы. Определение: документы, содержащие данные для проведения ремонтных работ на специализированных предприятиях. Вид документа – инструкция. Определение: документ, содержащий указания и правила, используемые при изготовлении изделия (сборке, регулировке, контроле, приемке и т. п.). Документы в зависимости от стадии разработки подразделяются на проектные (техническое предложение, эскизный проект и технический проект) и рабочие (рабочая документация). Наименования конструкторских документов в зависимости от способа их выполнения и характера использования приведены ниже. Наименование документа – оригиналы. Определение: документы, выполненные на любом материале и предназначенные для изготовления по ним подлинников. Наименование документа – подлинники. Определение: документы, оформленные подлинными установленными подписями и выполненные на любом материале, позволяющем многократное воспроизведение с них копий. Допускается в качестве подлинника использовать оригинал, репрографическую копию или экземпляр документа, изданного типографским способом, завизированные подлинными подписями лиц, разработавших данный документ и ответственных за нормоконтроль. Наименование документа – дубликаты. Определение: копии подлинников, обеспечивающие идентичность воспроизведения подлинника, выполненные на любом материале, позволяющем снятие с них копий. Наименование документа – копии. Определение: документы, выполненные способом, обеспечивающим их идентичность с подлинником (дубликатом) и предназначенные для непосредственного использования при разработке, в производстве, эксплуатации и ремонте изделий. Копиями являются, также микрофильмы-копии, полученные с микрофильма-дубликата Документы, предназначенные для разового использования в производстве (документы макета, стендов для лабораторных испытаний и др.), допускается выполнять в виде эскизных конструкторских документов.

2.2 Комплексность конструкторских документов

При определении комплектности конструкторских документов на изделия следует различать: основной конструкторский документ; основной комплект конструкторских документов; полный комплект конструкторских документов. Основной конструкторский документ изделия в отдельности или в совокупности с другими записанными в нем конструкторскими документами полностью и однозначно определяют данное изделие и его состав. За основные конструкторские документы принимают: для деталей - чертеж детали; для сборочных единиц, комплексов и комплектов - спецификацию. Изделие, примененное по конструкторским документам, выполненным в соответствии со стандартом Единой системы конструкторской документации, записывают в документы других изделий, в которых оно применено, за обозначением своего основного конструкторского документа. Считается, что такое изделие применено по своему основному конструкторскому документу. Основной комплект конструкторских документов изделия объединяет конструкторские документы, относящиеся ко всему изделию (составленные на все данное изделие в целом), например, сборочный чертеж, принципиальная электрическая схема, технические условия, эксплуатационные документы. Конструкторские документы составных частей в основной комплект документов изделия не входят. Полный комплект конструкторских документов изделия составляют (в общем случае) из следующих документов: основного комплекта конструкторских документов на данное изделие; основных комплектов конструкторских документов на все составные части данного изделия, примененные по своим основным конструкторским документам. Пример построения полного комплекта конструкторских документов комплекса приведен в приложении. В основной комплект конструкторских документов изделия могут входить также групповые конструкторские документы, если эти документы распространяются и на данное изделие, например, групповые технические условия. Давайте рассмотрим гост упомянутый выше ГОСТ 2.124-85, а в нем говорится о порядке применения покупных изделий ознакомимся Единый порядок применения покупных изделий устанавливается с целью обеспечения правильности применения этих изделий для достижения установленного качества разрабатываемых объектов. На покупные изделия, которые применяются в разрабатываемых объектах в полном соответствии с требованиями стандартов, технических условий и другой технической документации на эти изделия, разрешение на применение не требуется. Ответственным за обоснованность и правильность применения покупных изделий является разработчик объекта. В случае необходимости применения покупных изделий в режимах и условиях, расширяющих область их применения. А также при необходимости доработки покупных изделий для установки в разрабатываемом объекте, не связанных с ухудшением основных технических параметров покупных изделий, применение покупных изделий возможно только по разрешению предприятия - изготовителя покупного изделия или организации, на которую возложена обязанность по выдаче разрешения применения покупных изделий. В случае, когда предприятие-изготовитель неизвестен, или известен, но недоступен, или не установлена организация, выдающая разрешение на применение такого покупного изделия, то ответственность за применение такого покупного изделия возлагается на разработчика, который в одностороннем порядке оформляет протокол разрешения в соответствии с приложением. Разрешение на применение покупных изделий для случаев, указанных в указанных ранее полученное на любой стадии разработки конструкторской документации объекта, действительно для всех последующих стадий разработки. А также для производства, эксплуатации и ремонта объекта. Разрешенные режимы и условия применения покупного изделия являются дополнительными данными к гарантированным данным, указанным в документах на поставку покупного изделия. Организация, дающая разрешение на применение покупных изделий, является ответственной за правильность и обоснованность выданного разрешения. При передаче подлинников конструкторской документации объекта другому предприятию одновременно с ними должны быть переданы протоколы разрешения на применение в этих объектах покупных изделий или их копии.

Теперь скажем все это своими словами:

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

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

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

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

– управление режимами работы программы. Формулируются основные требования к способу взаимодействия пользователя с программой (интерфейс пользователь-компьютер).

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

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

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

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

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

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

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

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

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

Компиляция программы. После того как закончено кодирование (написание программы на языке программирования) и исходный текст программы введен в память компьютера, производят компилирование программы, т.е. перевод исходного текста в машинный код. Этот процесс осуществляется специальной программой – компилятором. На рисунке 1 представлена схема подготовки исполняемой программы.

Сначала программа передается препроцессору, который выполняет директивы, содержащиеся в ее тексте (например, #include - включение файла в текст программы).

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

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

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

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

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

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

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

- задание на разработку программного обеспечения (техническое задание);

- спецификация;

- прокомментированные исходные тексты (листинги) модулей программы и управляющего модуля;

- схема разбиения программного комплекса на программные модули;

- схема потоков данных программного комплекса;

- схема взаимодействия программных модулей;

- планы и данные для тестирования программного комплекса;

- другие материалы, иллюстрирующие проект, например: блок-схемы программного комплекса и программных модулей.

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

Заключение

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

Список литературы

http://docs.cntd.ru/document/gost-19-102-77

http://promnov.ru/assets/img/docs/19.101.pdf

http://www.jetcom.ru/PDF/GOST2.102-68.pdf

http://docs.cntd.ru/document/1200004401