Технология программирования Николай Николаевич

Лекция 1

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

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

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

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

1. структурной декомпозиции системы;

2. введение определенных стандартов на интерфейс между ее собственными частями;

В этот период создается идеология восходящего и нисходящего программирования или проектирования.

3)разработка принципов модуляции;

4)разработка структурного программирования, появляются теория и практика отладки программ, тестирование и верификация (доказательство правильности работы программ)

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

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

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

1. определение дисциплины программирования;

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

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

4. планировать и управлять стоимостью и трудоемкостью разработки;

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

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

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

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

• Понимание программы

• Надежность

• Трудоемкость написания

• Отладка

• Тестирование

• Сопровождение

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

Сколько стоит программа?

Какой язык выбрать?

Как оценить материально-технические ресурсы?

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

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

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

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

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

РАНЕЕ СЕЙЧАС

Кодирование 20% Кодирование 6%

Конструирование40% Тестирование12% Тестирование 40% Конструирование 12%

Сопровождение 70%

Отсутствие хорошо составленной в едином стиле программной документации приводит к низкой познаваемости программы, в результате чего из всего объема ПО активно используются 1-3%

В настоящее время в базе данных автоматизированных систем для организации управления экономическими объектами (заводы, фабрики и др) должен содержать 10¹⁵-10¹⁸ бит информации. Эта информация имеет сложную иерархическую структуру, отражающую тенденции к интеграции и интентификации в производства. Самой сложной проблемой является создание ПО для накопления и обработки этой информации. Хорошей основой и базой для работ по технологии программирования могут быть следующие напрваления:

1) Теория автоматов и алгоритмов

2) Новые принципы построения ЭВМ

3) Принципы построения автоматизированных систем

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

1. о единстве программного обеспечения и аппаратного обеспечения

2. о единстве проблем проектирования. Целесообразность состоит в том, чтобы не различать эти проблемы, поскольку:

а) они поддержаны общностью математических методов или моделей, которые возникают при проектировании ПО и АпО

б) взаимное проникновение идей и метод программ и устройств.

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

Лекция 2

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

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

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

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

Технология программ. как новое и прогрессивное направление (промышлен. разработка ПО) в настоящее время начало использовать фундаментальные принципы автоматизированных систем (АСУ) для производства программного продукта.

Такие АСУ должны решать следующие три задачи:

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

2. Переработка информации.

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

Такие АСУ имею 2 особенности или св-ва:

1. Большая часть информации об объекте управления может быть получена автоматически из программ, введенных в ЭВМ для обработки. Для эффективного функционирования таких АСУ требуется min объем информации об объекте управления.

2. АСУ для производства программ mах удовлетворяет принципу «новых задач» т.е. сам объект управления, находится в начальной стадии своего развития и следовательно много областей еще не исследовано. В силу того, что всегда решаются новые проблемы, всегда будут новые задачи.

Общая характеристика технологического процесса разработки ПО

Программное изделие как результат разработки ПО

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

Кроме того для оценки ПО необходимо рассмотреть, к какому типу относится ПО:

1)Режимы функционирования ПО

Реальный, пакетный, интерактивный.

2)Тип ПО

1. Инструментальное.

2. Системное

3. Прикладное

3)Будет ли тиражироваться или оставаться индивидуальным программным продуктом. Основным критерием разделения результата деятельности разработки программы, является не просто программа или ПО, и не должны служить такие критерии, как объем программы и сложность, а критерий – трудоемкости разработки ПО.

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

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

Аспекты классификации программного обеспечения.

Как правило по этим аспектам они классифицируются и изучаются.

1. Сфера применения

2. Использование ресурса вычислительного комплекса.

3. Технология изготовления

4. Назначения

5. Качество

6. Сложность

7. Товарная продукция и тд.

Сфера применения ПО

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

1)для научных исследований

2) коммерческое (прикладное) ПО

3. системное ПО

4. программно- аппаратное обеспечение или программное обеспечение ЭВМ, которое вписано в контур управления ЭВМ.

Для научных исследований ПО состоит в основном из

1. Разрабатывается как правило для инженерного и научного исследования.

2.ПО обычно не велики и индивидуальны.

3. Функционирование не связано с работой в реальном моменте времени

4. Главное они носят индивидуальный (экспериментальный) характер.

5. Они не ориентированы на массового пользователя.

6. Не снабжены технической и технологической документацией.

7. Разрабатываются как правило специалистом данной предметной области.

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

1) большие программные системы, оформленные в виде пакета прикладных программ ПО

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

3) Данный класс реализуется на разных типах ЭВМ в том числе и на универсальных. типах ЭВМ с развитой операционной системой.

4) Объем такого ПО измеряется в командах 10⁵, 10⁶.

5) Оно функционирует как правило в реальном масштабе времени.

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

Системное ПО.

Имеет много общего с коммерческим программным обеспечением, но

1) оно более универсально.

2) Постоянно тиражируется.

3) Главное предназначено для автоматизированной разработки ПО первых 2-х типов ПО.

4) Осуществляется управление ресурсами ЭВМ вместе с кот. как правило и представляет собой единое целое, иначе говоря продукция. Он не включает туда трансляторы, перег. виды прогр. обеспеч.

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

1) оно функционирует в реальном масштабе времени.

2) Полностью использует ресурсы ЭВМ

3) Предъявляются жесткие требования к качеству - быстродействие, надежность, живучесть

4) Оно снабжается в полном объеме документацией технической и технологической.

5) В большинстве своем это функционирует только на чтение

В ПО первого класса, как правило отсутствует документация оформленная по ГОСТу или ОСТу но всегда комментируется до такого уровня, чтобы предметник данного исследования смог разобраться в данном ПО.

Технологические аспекты разработки 2-го и 3-го класса ПО имеют много общего, как то: 1) Объем команд

2) Сложность изготовления

3) Коллективный характер разработки

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

1) Полное отсутствие у таких ЭВМ операционной. системы.

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

Программное обеспечение

Под ПО будем понимать

1)комплекс, взаимосвязанных модулей.

2) Предназначенных для решения конкретной задачи или определенного класса задач

3) Отчуждаемый от программистов разработчиков.

4) Снабженный в соответствии с заданными требованиями необходимой технической и технологической документацией.

5) Удовлетворяющий заданным требованиям качества.

6) Обладающий товарной стоимостью.

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

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

1) Определение, анализ требований к программному изделию.

2) Разработка архитектуры к спецификации ПО.

3) Детальное проектирование моделей.

4) Программирование (кодирование)

5) Тестирование (верификация)

6) Внедрение и сопровождение.

Лекция 3.

Технология программирования

Этапы взаимодействия

Простейшая каскадная модель

Каскадная модель с пошаговым уточнением

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

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

1) Завершение каждого этапа заканчивается его проверкой (верификацией) доказательства правильности и подтверждения достижения поставленных целей.

2) Циклическое взаимодействие каждого этапа с предыдущим и последующим.

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

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

Как подтвердить результаты, какой документацией оформить этап.

Конечные цели каждого этапа.

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

1 этап.

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

2)Проверить их на полноту и противоречивость и осуществимость

3)Составить план разработки программного изделия, с указанием параметров, показателей завершения этого этапа.

4) Организовать структуру управления и график разработки программного. изделия с указанием всех видов деятельности на этапе.

5) Составить план обучения персонала, переноса программ из одной среды в другую. внедрения и сопровождение программного изделия.

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

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

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

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

2) Описание межмодульных интерфейсов по данным и по управлению.

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

4) Разработать предварительный план комплексирования и отладки.

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

На 3-м этапе, на этапе детального проектирования и начала программирования (кодирование) необходимо

1) Завершить сквозной структурный контроль всего проекта.

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

3) Выполнить детальное описание базы данных проекта.

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

5) Согласовать с заказчиком план приема сдаточных испытаний для пользователя.

6) Разработать полное руководство для пользователей.

7) Завершить полное представление плана комплексирования и отладки всего программного изделия.

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

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

3) Для завершения стадии требуется документировать внутреннюю структуру каждого модуля.

4)проверить выполнение стандартов программирования.

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

1) Проверку правильности происхождения теста.

2) Проверку удовлетворения всех требований технического задания к программному изделию.

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

4) На этом этапе производится приемка заказчиком всей технической и технологической документации программного изделий.

6 этап.

Условия завершения этапа и сопровождения( эксплуатации).

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

7 этап. Сопровождение.

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

Циклическая схема разработки жизненного цикла по.

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

Виды деятельности при разработки программного изделия.

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

Определение видов деятельности.

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

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

В состав этой информации входят:

1) описание требований к ПО.

2) описание проекта ПО.

3) Тексты и загрузочные модули программ.

4) Описание используемых текстов и тестовые данные.

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

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

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

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

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

Лекция 4

Анализ правильности проектной информации

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

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

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

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

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

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

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

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

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

Анализ качества разработки ПО

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

Единых методов оценки этих показателей также не существует

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

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

1) Определение необходимых потребностей в выполнении данной работы в части ресурсов.

2) Способы организации коллектива разработчиков и распределение работ между ними . 3) Методы объективной оценки разрабатываемого ПО.

4) Учет индивидуального вклада каждого разработчики.

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

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

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

Выделяется 2 аспекта в этой деятельности:

1) накопление всей информации о разработке, необходимой для его последующей модификации и эксплуатации.

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

1) фиксация результатов.

2) Процессы разработки ПО, в том числе принимаемые решения.

3) Создание компонент проектной информации и технология их связи

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

Проблема автоматизации разработки

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

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

Причины создания автоматиз систем

к таким работам относятся виды работ, носящие рутинный характер.

1) ведение проектной и программной документации в ходе разработки ПО, введение согласованности проектной документации и программ на всем протяжении разработки.

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

3) Подготовка исходных данных для тестирования. Организация работы тестов. и анализ результатов.

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

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

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

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

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

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

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

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

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

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

1) Создание проектной информации и ввод ее в централизованную базу данных на различных этапах разработки жизненного цикла ПО.

2) Автоматическая генерация некоторых компонентов ПО или проекта.

3) Анализ правильности и согласованности проектной информации и ее замкнутости и полнота информации.

4) Оценка текущего состояния разработки и качества выполнения работ.

5) Планирование хода разработки и контроль за выполнением плана.

6) Общая организация работ в соответствии с некоторой технической схемой.

7) Подготовка и выдача результатов разработки. разработчиком ПО и руководителям разработки. Определение информ. …. разработок.

8) Оформление всей документации в наглядном виде, оформленной в соответствии . со стандартами.

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

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

2) Формальное доказательство правильности программы (верификация).

3)Символьное исполнение программ.

4) Тестирование.

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

Инструменты технологического комплекса

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

Лекция 5

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

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

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

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

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

Известны 2 технологических комплекса ARGUS и РИТМ, в которых оценки качества разработки основана на простейшем математическом аппарате. В ряде технологических комплексов есть технологические средства персонального контроля сроков работы(1) планирование сроков выполнения работы конкретными исполнителями. 2) Контроль за соблюдением сроков выполнения работы). Такие процедуры как правило имеются в большинстве технологических комплексах, в некоторых технологических комплексах в частности ARGUS и РТК имеются средства автоматизации и построения сетевых графиков, всех этапов выполнения разработки.