№1 Поколения языков программирования

– языки первого поколения: машинно–ориентированные с ручным управлением памяти на компьютерах первого поколения.

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

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

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

– языки программирования пятого поколения: языки декларативные, объектно–ориентированные и визуальные. Например, Пролог, ЛИСП (используется для построения программ с использованием методов искусственного интеллекта), Си++, Visual Basic, Delphi.

№2 Top-Down технология программирования, основные этапы.

Буквально - программирование сверху вниз, от вершины к подножию. Вершиной является сама задача: «Создать программу, которая …», подножием является документированный текст программы.

Является общепризнанной, все современные интегрированные среды ориентированы на нее.

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

1.Составление спецификаций.

На первый взгляд к программированию не имеет никакого отношения.

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

1.1 описание назначения проектируемой программы;

1.2 подробное описание входных данных с указанием их типов, размерностей и прочих ограничений, особенностей;

1.3 подробное описание входных данных и результатов;

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

1.5 примеры входных данных и соответствующих им результатов. ЕСПД

В настоящее время значимость спецификаций резко возросла – верхние CASE, средства прототипирования.

2.Разбиение на модули.

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

Первые два этапа будем называть постановочной частью (постановка задачи). Данный этап на 90-95% определяет качество разрабатываемой программы.

Очевидно, этапы 1 и 2 взаимосвязаны. Результаты постановочной части:

2.1спецификация на разрабатываемую программу в целом;

2.2выбор метода решения (инженерные задачи);

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

2.4спецификации на каждый отдельный модуль с тщательной проработкой внутренней структуры;

2.5блок-схемы наиболее логически сложных частей программы;

3. Проектирование модулей.

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

4. Тестирование программы.

Готовятся данные для проверки каждого модуля в отдельности и всей программы в целом. Цель тестирования – обнаружение ошибок.

5. Отладка программы.

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

Каждая последняя ошибка на самом деле предпоследняя.

6. Оптимизация программы.

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

7.Документирование программы.

Вопрос №3. Жизненный цикл программного обеспечения

Жизненным циклом ПО называют время от момента появления идеи ПО до момента завершения его поддержки фирмой-разработчиком.

Основные этапы:

-постановка задачи;

-анализ требований и разработка спецификаций;

-проектирование;

-реализация (эволюция);

-модификация (сопровождение);

Анализ требований и определение спецификаций.

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

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

Часть спецификаций может быть определена на первом этапе и зафиксирована в ТЗ.

Проектирование.

Задача – определение подробных моделей разрабатываемого ПО.

Различают:

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

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

Логическое проектирование обычно включает в себя:

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

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

-проектирование компонентов.

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

Реализация-процесс поэтапного написания кодов программы на выбранном языке программирования, их тестирование и отладка.

Сопровождение – процесс выпуска и внедрение новых версий ПО.

Причинами могут быть:

-необходимость исправления ошибок;

-необходимость совершенствования, например ПИ;

-изменение среды функционирования

№4 Разработка технического задания на разрабатываемое ПО

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

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

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

№5 Спецификации ПО при структурном подходе. Диаграммы переходов состояний, потоков данных, функциональные диаграммы, отношений компонентов данных.

Спецификации программного обеспечения при структурном подходе.

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

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

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

● требование точности означает, что спецификации должны однозначно восприниматься как заказчиком, так и разработчиком;

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

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

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

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

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

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

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

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

● диаграмма потоков данных (DFD - Data Flow Diagrams), описывающих взаимодействие источников и потребителей информации через процессы, которые должны быть реализованы в системе;

● диаграмма “сущность-связь” (ERD - Enity Relationhship Diagrams), описывающих базы данных разрабатываемой системы;

● диаграмма переходов состояний (STD - State Transition Diagrams), характеризующих поведение системы во времени;

● спецификаций процессов;

● словаря терминов.

Взаимосвязь элементов такой обобщенной модели показана на рис.2