В процессе создания любой программы, будь то небольшая учебная программа, предназначенная для демонстрации учителю информатики, или серьезный проект, над которым работают десятки (а то и сотни) программистов, можно выделить несколько этапов. Затраты труда и времени на их выполнение различны, различаются эти затраты и для разных программ. Некоторые из этапов могут быть опущены или пройдены «незаметно», однако анализ процесса разработки приводит к выводу о том, что почти всегда, явно или неявно, приходится проходить следующие этапы разработки программы:
постановка задачи; анализ, формализованное описание задачи, выбор модели; выбор или разработка алгоритма решения задачи; проектирование общей структуры программы; кодирование; отладка и верификация программы; получение результата, его интерпретация и, возможно, последующая модификация модели; публикация или передача заказчику результата работы; сопровождение программы.
Постановка задачи выполняется заказчиком, в качестве которого может выступать внешняя организация, организация, в которой работает программист, начальник программиста, преподаватель, сам программист. На этом этапе задача, которую необходимо решить посредством составления программы для компьютера, формулируется на естественном языке (русском, китайском, языке племени мбвонга-твонга).
Жизненный цикл разработки. SDLC (2020)
При этом важно осознать, что решение данной задачи с помощью компьютера действительно оптимальный способ получения результата. Вряд ли стоит составлять программу для вычисления суммы двух чисел в этом случае достаточно воспользоваться калькулятором. При решении вычислительной задачи может оказаться, что уравнения, описывающие математическую модель явления, могут быть решены точно, аналитически (так, что решение записывается с помощью элементарных или специальных функций). В этом случае также не нужен компьютер. Если же речь идет о расчете аэродинамических характеристик новой модели самолета, без суперкомпьютера не обойтись!
Анализ задачи включает определение входных и выходных данных, выявление возможных ограничений на их значения и обычно завершается формализованным описанием задачи, которое часто предполагает ее математическую формулировку. Если речь идет о моделировании каких-либо явлений или процессов, на этом этапе разрабатывается математическая модель процесса (явления). В этом случае определяются факторы, которые играют основную роль, и отбрасываются те факторы, действие которых незначительно и которыми поэтому можно пренебречь. Так, при моделировании полета снаряда в поле тяготения Земли на небольшой высоте основное значение имеют сила тяжести и сопротивление воздуха, а неоднородности поля тяжести, кривизну поверхности Земли и действие ветра можно не учитывать.
Выбор или разработка алгоритма и численного метода решения задачи имеют важнейшее значение для успешной работы над программой. Тщательно проработанный алгоритм решения задачи необходимое условие эффективной работы по составлению программы.
Просто о SDLC (Жизненный цикл разработки ПО)
Проектирование общей структуры программы. На этом этапе происходит «архитектурная» проработка проекта. Определяются те части алгоритма, которые целесообразно оформить в виде подпрограмм, модулей. Определяется и способ хранения информации в виде набора простых переменных, массивов или других структур.
Кодирование это запись алгоритма на языке программирования. Если алгоритм решения задачи, структура программы и структура данных тщательно продуманы и аккуратно записаны, затраты времени на кодирование уменьшаются, а вероятность ошибок на этом этапе снижается.
Отладка и верификация программы представляют собой очень важную часть процесса разработки программы. Отладка заключается в устранении ошибок программирования, ошибок перевода алгоритма на язык программирования. Верификация это доказательство того, что программа работает «правильно», дает правильный результат.
Для этого разрабатывается система тестов, которые могут представлять собой специально подобранные наборы параметров, для которых задача может быть решена точно. Это могут быть, например, какие-нибудь предельные случаи.
Если результат, полученный с помощью программы, совпадает (с учетом погрешности машинного счета) с ожидаемым, есть основание полагать, что программа работает корректно. Но это всего лишь основание, а не абсолютная уверенность! Среди начинающих программистов распространено убеждение, что если программа успешно откомпилирована и, будучи запущена на выполнение, выдает на экран ряды цифр, задача решена. На самом же деле программа готова, если разработчик смог доказать заказчику (да и самому себе), что результат работы программы является решением поставленной задачи.
Получение результата, его интерпретация с возможной последующей модификацией модели. Вот, наконец, программа проверена, большая часть ошибок устранена и есть обоснованная надежда на то, что, по крайней мере в рамках выбранной модели, она дает правильный результат. Этот результат необходимо проанализировать.
Если речь идет о моделировании какого-то природного процесса, следует сравнить полученные с помощью компьютера результаты и результаты наблюдений. Процесс такого анализа мы и называем интерпретацией результатов расчета. Здесь программиста может ожидать разочарование — результат может отличаться от требуемого. В этом случае, возможно, придется изменить саму модель, сделав ее более реалистичной.
Публикация или передача заказчику результата работы это важнейший момент, момент рождения качественной программы. В научных исследованиях значение имеют результаты моделирования, которые публикуются в научных журналах. В других случаях конечным результатом работы может быть сама программа, которая передается заказчику для дальнейшей эксплуатации или выкладывается на ftp-сервер для свободного распространения и прославления автора программы!
Сопровождение программы предполагает консультации заказчику по работе программы, устранение замеченных в процессе ее эксплуатации недостатков (а возможно, и ошибок), обучение пользователей работе с программой. Этот, заключительный этап имеет особое значение для больших и сложных программ.
Источник: mykonspekts.ru
Стандарты, стадии и этапы разработки программ
Стандарты давно используются в технике и программировании. Создание сложной системы немыслимо без стандартов. Они нужны для борьбы с хаосом и неразберихой, но вместе с этим стандарт не должен быть слишком «узким» и мешать техническому прогрессу.
Государственные стандарты отслеживают тенденции развития программирования и дают обязательные рекомендации по их соблюдению. Сегодня используются обозначения ГОСТ (государственный стандарт) со времен Советского Союза и СТБ (стандарт Беларуси) новые стандарты Республики Беларусь. Помимо государственных стандартов действуют отраслевые стандарты (ОСТ), стандарты предприятий (СТП).
Группа стандартов ГОСТ «Единая система программной документации» (ЕСПД) претерпела мало изменений с момента ее создания, пережила несколько поколений ЭВМ и революционных изменений технологий разработки программ. При этом она до настоящего времени никогда не затрудняла новаций.
Помимо вышеизложенных стандартов де-юре имеются стандарты де-факто. Ряд стандартов устанавливается де-факто ведущими фирмами-разработчиками программ и вычислительной техники. Стандарты де-факто появляются на основе идей какой-то широко известной разработки.
Выгодно делать продукты в стиле разработки какой-то фирмы, так как пользователи уже имеют навыки работы с меню в стиле «Lotus», электронными таблицами, текстовыми редакторами. Обычно стандартом де-факто определяются используемые операционные системы, трансляторы с языков программирования, организация файлов и средний уровень качества, достигаемый по окончании тестирования программ. Конкретному разработчику выгодно следовать таким стандартам.
В области программирования общепризнанной ведущей организацией по разработке стандартов является институт ANSI (Американский национальный институт стандартов). Данный институт является лидером по установке стандартов языков программирования, кодовых таблиц клавиш и символов, выводимых на экран, и еще многих других. Необходимо также отметить стандарты ISO.
К сожалению, самое благородное дело стандартизации – достижение всеобщей унификации и взаимозаменяемости – может также стать тормозом развития. Вводя новый стандарт, надо учитывать последствия ввода, особенно если стандарт является опережающим и опережает практику развития или если стандарт является слишком «узким» и тормозит эволюцию прогресса. Во всем мире руководствуются следующим отношением к стандартам: или полностью им следуй, или делай свой собственный стандарт. Стандарты дают дополнительные ограничения.
Программист должен уметь не только использовать готовые стандарты, но и разрабатывать новые. Так, например, правила однотипного оформления исходного текста программы определяются стандартом проекта, который может быть изменен при начале разработки нового проекта. Однако в течение выполнения одного проекта оформление всех частей программы должно быть однотипным. Поэтому зачастую перед началом нового проекта конкретным программистам следует разрабатывать свои стандарты, которые не нарушают ГОСТ, ОСТ и СТП и действуют в пределах конкретного проекта.
«ГОСТ 19.102-77. Единая система программной документации. Стадии разработки» регламентирует стадии и этапы программных разработок в течение всего жизненного цикла. Данный стандарт сформировался на основе анализа удачных и неудачных программных разработок и содержит основные рекомендации по проведению новых разработок.
Стандарт уже пережил несколько технологий программирования. При этом, практически не изменяясь, он не являлся тормозом прогресса. Помимо наименований стадий и этапов проектирования ГОСТ 19.102-77 фактически содержит описание аналитико-синтетического эвроритма (алгоритма действий проектировщика с использованием методов анализа и синтеза) по временным этапам проекта.
Стадия проекта – одна из частей процесса создания программы, установленная нормативными документами и заканчивающаяся выпуском проектной документации, содержащей описание полной, в рамках заданных требований, модели программы на заданном для данной стадии уровне, или изготовлением программ. По достижении окончания стадии заказчик имеет возможность рассмотреть состояние проекта и принять решение по дальнейшему продолжению проектных работ. Например, заказчик может принять решение о продолжении работ по одному из согласованных вариантов.
Этап проекта — обычно часть стадии проекта, выделенная по соображениям единства характера работ и (или) завершающего результата или специализации исполнителей. Иногда выделяют этапы (фазы), которые охватывают несколько стадий. Например, этап проектирования программы включает стадии ЭП и ТП. Описания этапов регламентируют порядок выполнения отдельных видов работ для достижения стадии. Одни и те же виды работ могут продолжаться ряд этапов.
Программный документ «Техническое задание» (ТЗ) помимо основных требований к программному изделию содержит проект порядка взаимодействия заказчика и исполнителя по окончании конкретных этапов, т. е. перечень необходимых стадий и этапов и требований к их выполнению. ТЗ может сразу не устанавливать всех требований, которые могут быть уточнены и согласованы с заказчиком на последующих стадиях. Однако сама возможность изменения требований должна закладываться в ТЗ. В ТЗ определяется стратегия выполнения проекта.
«Эскизный проект» (ЭП), как правило, необходим для разработки нескольких альтернативных вариантов реализации будущего изделия и уточнения требований на основе их анализа. Степень проработки при этом должна быть достаточной лишь для достижения возможности сравнения вариантов.
«Технический проект» (ТП) выполняется для получения однозначного описания конечного (оптимального) варианта построения программного изделия и порядка его реализации.
«Рабочий проект» (РП) необходим для реализации изделия в соответствии с ранее намеченным планом.
Стадия «Внедрение» необходима для размножения программной документации в нужном количестве, обучения пользователей, помощи в освоении программы, сопровождения программы.
Научно-исследовательская работа (НИР) может быть самостоятельным этапом. НИР в основном проводится для выявления последних научных достижений с целью их использования в проекте, проверки реализуемости изделия и уточнения отдельных его характеристик.
В соответствии с ГОСТ 19.102-77 допускается исключать стадию ЭП, а в технически обоснованных случаях – стадии ЭП и ТП.
Пример 1. Разработка наукоемкой подпрограммы может вестись по следующим стадиям:
• ТЗ (ТЗ основное плюс ТЗ на отдельную НИР);
• ожидание результатов НИР, выполняемой в другой организации специалистами-математиками (срок от месяца до нескольких лет);
• РП (около месяца);
Пример 2. Требуется разработать программное изделие средней или большой сложности. При средней сложности изделия необходимо проведение ТП, а при большой сложности – и ЭП, и ТП. В отличие от примера 1 в данном случае ТЗ может не содержать законченных требований.
Пример 3. Требуется создать программные средства, автоматизирующие отдельные виды работ. Разработка такого проекта может проводиться по следующим стадиям:
• ЭП с НИР по исследованию существующих программных средств, автоматизирующих выполнение отдельных видов работ;
• РП по разработке только документации без реализации каких-либо программ, если НИР показала, что можно обойтись только существующими программными средствами;
Пример 4. Разработка таких информационных систем, как САПР или АСУ должна осуществляться в соответствии с соответствующими стандартами. ТП САПР или АСУ может содержать технические задания на разработку отдельных программных изделий. Как правило, такие ТЗ очень конкретны. На этапе РП САПР или АСУ сначала ведется контроль над разработкой программных изделий по всем необходимым для этого стадиям разработки программных изделий, затем проводится совместная проверка всех разработанных программ.
Обычно основанием для заключения договора между заказчиком и исполнителем служит гарантийное письмо заказчика. На основании гарантийного письма составляется договор. Обязательным приложением к договору является ТЗ.
Некоторые отечественные и зарубежные источники предлагают выделять следующие этапы:
1) анализ требований, предъявляемых к системе (системный анализ). (Обычно проводится на основе первичного исследования потоков информации при традиционном проведении работ с фиксацией видов этих работ и их последовательности);
2) определение целей, достигаемых разрабатываемыми программами;
3) выявление аналогов, обеспечивающих достижение подобных целей, их достоинств и недостатков;
4) постановка задачи на разработку новых программ, определение внешних спецификаций (т. е. описаний входной и выходной информации, а иногда и их форм) и способов (алгоритмов, методов) обработки информации;
5) оценка достижения целей разработки (Далее, при необходимости, этапы 1-5 могут быть итеративно повторены до достижения удовлетворительного облика изделия с описанием выполняемых им функций и некоторой ясностью реализации его функционирования);
6) рассмотрение возможных вариантов структурного построения программного изделия: или в виде нескольких программ, или нескольких частей одной программы; результатом этой работы являются варианты архитектуры программной системы и (или) требования к структуре отдельных программных компонент; организация файлов для межпрограммного обмена данными;
7) разработка окончательного варианта архитектуры системы и разработка окончательной структуры программных компонент;
8) составление и проверка спецификаций модулей;
9) составление описаний логики модулей;
10) составление окончательного плана реализации программ;
11) кодирование и тестирование отдельных модулей и совокупности готовых модулей до получения готовой программы;
12) комплексное тестирование;
13) разработка эксплуатационной документации на программу;
14) проведение приемо-сдаточных и других испытаний;
15) корректировка программ по результатам испытаний;
16) окончательная сдача программного изделия заказчику;
17) тиражирование программного изделия;
18) сопровождение программы.
Современные технологии проектирования программного обеспечения направлены на частичную автоматизацию этапов и на совмещение их во времени с целью сокращения сроков выполнения проектов.
В литературных источниках применяются наименования этапов, которые охватывают ряд приведенных этапов и по времени охватывают даже несколько стадий. Например, этап разработки программы.
Выводы
• Проектирование — высокоинтеллектуальный процесс. Для понятия теории проектирования необходимо оперировать множеством терминов и определений, такими как проектная ситуация, технология, оптимизация программных разработок. Все это говорит о необходимости тщательно подходить к изучению словарного аппарата теории проектирования.
• Разработка архитектуры – это процесс разбиения большой системы на более мелкие части. Процесс разработки архитектуры – этап, необходимый при проектировании систем или комплексов, но необязательный при создании программы. Если внешние спецификации (экранные формы, организация файлов. ) описывают программную систему с точки зрения пользователя, то следующий шаг проектирования состоит в разработке архитектуры, а за ним следует проектирование структуры каждой программы.
• Программы в основном представляют собой сложные системы из миллионов машинных инструкций. Сложность определяется четырьмя основными причинами: сложностью задачи; сложностью управления процессом разработки; сложностью описания поведения отдельных подсистем; сложностью обеспечения гибкости конечного программного продукта.
• Одной из важнейших составляющих успешного проектирования является системный подход, предусматривающий всестороннее исследование сложного объекта.
• При создании и развитии ПО рекомендуется применять следующие общесистемные принципы: включения; системного единства; развития; комплексности; информационного единства; совместимости; инвариантности.
• Необходимо помнить, что проектирование неотъемлемо от различных стандартов (ГОСТ, ANSI, проекта) и их следует соблюдать как при оформлении документации, так и для унификации вашего проекта.
• Программы создаются, эксплуатируются и развиваются во времени, проходя свой жизненный цикл. Характерная особенность жизненного цикла ПО — отсутствие этапа утилизации.
• В процессе выполнения проекта предусматриваются отдельные моменты времени, которые характеризуются законченным оформлением результатов всех работ, выполненных разработчиками до данного момента. Согласно ГОСТ возможны следующие стадии разработки: ТЗ; ЭП; ТП; РП; внедрение. Возможны также и нестандартные этапы, и стадии. Набор этапов и стадий отражает результаты проектирования самого процесса проектирования.
Контрольные вопросы
1. Дайте определения: программная продукция, программное обеспечение, информационная и автоматизированная система.
2. Какими основными причинами определяется сложность задачи?
3. Дайте определения: проектирование, проект, проектная задача.
4. Что такое метод проектирования и методики проектирования?
5. Какими свойствами характеризуется алгоритм?
6. Что такое эвристика? В чем состоит схожесть и различие алгоритма и эвроритма?
7. Что такое архитектура программ?
8. Какие виды анализа используются при системном подходе?
9. Что такое принцип совместимости?
10. Для чего необходима стандартизация проектирования и программирования?
11. Назовите основные этапы жизненного цикла программных изделий.
12. Назовите основные стадии и этапы разработки программ по ГОСТ 19.102-77.
Дополнительная литература и источники
1. IEEE Std 610.12-1990, IEEE Standard Glossary of Software Engineering Terminology.
2. IEEE Std 1074-1995, IEEE Standard for Developing Software Life Cycle Processes.
3. «Руководство к своду знаний по программной инженерии». The Guide to the Software Engineering Body of Knowledge, SWEBOK, IEEE Computer Society Professional Practices Committee, 2004.
4. «PMBOK. Руководство к Своду знаний по управлению проектами», 3-е изд., PMI, 2004.
Дата добавления: 2018-05-02 ; просмотров: 846 ; Мы поможем в написании вашей работы!
Источник: studopedia.net
Стадии разработки программных средств по ЕСПД
Теперь рассмотрим набор типовых стадий создания ПС, изучение которого позволит понимать процесс разработки и более осознанно относиться к созданию качества ПС. Эти стадии предусмотрены ГОСТ 19.102-77 ЕСПД. Стадии разработки.
Стадии – наиболее укрупненные составляющие процесса разработки, для завершения которых характерно получение ПО в определённой стадии готовности.
Выделяют следующие стадии разработки программного обеспечения:
1 Стадия технического задания (предпроектная стадия) состоит из:
— сбора исходных данных;
— определения цели разработки – желаемого набора основных свойств и функций разрабатываемого ПС;
— обоснования и выбора критерия эффективности и качества разработки;
— формирования на верхнем уровне состава входной и выходной документации по решаемой задаче;
— выбора принципиальных методов решения задач;
— определения требований к комплексу технических средств и операционному окружению;
— определения инструментальных средств, используемых для разработки;
— планирования, т.е. декомпозиции процесса на стадии и этапы с установлением сроков их выполнения;
— разработки документа, называемого «Техническое задание».
2 Эскизное проектирование
На данной стадии выполняется:
— детализация состава и структуры входной и выходной информации;
— детализация метода решения задач.
На этапе эскизного проектирования нужно создать предварительную версию программного средства (возможно в виде модели) и выяснить принципиальные вопросы, устраняя возможные разногласия между разработчиком и заказчиком. При этом выполняется:
— определение предварительной технологии решения задачи;
— прогнозирование эффективности решения задачи на конкретном объекте;
— ведется освоение инструментальных средств (апробирование, обучение персонала).
3 Техническое проектирование (технический проект)
На данном этапе:
— окончательно определяется состав и структура информации;
— разрабатывается интерфейс во всех его компонентах;
— технология решения задачи доводится автоматизма;
— полностью определяется конфигурация тех средств, на которых ведется разработка ПС;
— определяется структура базы данных, где храниться информация о работе ПС;
— разрабатывается тестовый набор для проверки правильности программной реализации;
— начинается разработка программной документации;
— полностью определяется структура ПС (модули, компоненты).
Технический проект может рассматриваться как постановка задачи, передаваемой специалистом-постановщиком специалисту по программной реализации.
4 Рабочее проектирование (рабочий проект)
Результат рабочего проектирования – получение ПС в состоянии операционной готовности, в котором устранены синтаксические и семантические ошибки, как в программном коде так и в программной документации.
Основные работы этой стадии:
— программная реализация (написание программного кода, привязка его к специфике конкретного объекта, адаптация и настройка программных модулей);
— отладка (автономная – в лабораторных условиях и комплексная – на объекте);
— разработка эксплуатационной документации;
— организация внедрения ПС.
5 Внедрение
На этапе внедрения осуществляют:
— подготовку персонала к эксплуатации;
— подготовку базы данных;
— проверку работоспособности ПС на реальных данных (опытная эксплуатация);
— доводку – окончательное устранение всех ошибок в коде и документации.
По отдельным компонентам может быть откат на предыдущие стадии.
В процессе разработки стадии могут объединяться. Объединяют эскизный и технический или технический и рабочий проекты. Иногда могут сразу объединять эскизный, технический и рабочий проекты. Обычно это производится, если в разрабатываемом ПС можно использовать значительный объём предыдущих разработок.
Модели жизненного цикла
2.1. Типичная схема управления процессом создания программного обеспечения
Управление процессами при разработке программного обеспечения в общем случае реализуется по спиральной схеме и состоит из следующих повторяемых действий [25]:
— создание инфраструктуры процесса (Establish Process Infrastructure). На данном этапе обеспечивается достижение согласия заинтересованных лиц (обычно это руководство организации) в работах по реализации или изменению процесса, определяется потребность в необходимых ресурсах и выполняется распределение обязанностей (ответственности);
— планирование (Planning), в ходе которого формулируются текущие бизнес-цели и потребности в процессе, необходимые отдельным специалистам, проекту и/или организации, в целом, определяются и описываются сильные и слабые стороны существующего процесса и планируемых на данной итерации нововведений и/или изменений и разрабатывается план реализации и изменения процесса;
— реализация и изменение процесса (Process Implementation and Change), предусматривающая выполнение разработанного плана по внедрению нового (усовершенствованного) процесса, в результате чего он процесс должен быть внедрен в практику организации;
— оценка процесса (Process Evaluation), позволяющая выяснить уровень качества реализации процесса, а также степень достижения ожидаемых эффектов от его внедрения, после чего происходит либо выход, либо возвращение к первой итерации.
Источник: lektsia.com