Цели и задачи технологий разработки ПО. Особенности современных крупных проектов ИС

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

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

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

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

- Встроенное: часть уникального приложения с привлечением аппаратного обеспечения; пример - автомобильный контроллер.

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

- Сетевое: состоит из частей, взаимодействующих через сеть; пример - основанная на вебтехнологии видеоигра.

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

 

Модели ЖЦ ПО. Каскадная модель. Содержание этапов создания ПИ.

Стандарт ISO/IEC 12207 не предлагает конкретную модель ЖЦ и методы разработки ПО (под моделью ЖЦ понимается структура, определяющая последовательность выполнения и взаимосвязи процессов, действий и задач, выполняемых на протяжении ЖЦ. Модель ЖЦ зависит от специфики ИС и специфики условий, в которых последняя создается и функционирует). Его регламенты являются общими для любых моделей ЖЦ, методологий и технологий разработки. Стандарт ISO/IEC 12207 описывает структуру процессов ЖЦ ПО, но не конкретизирует в деталях, как реализовать или выполнить действия и задачи, включенные в эти процессы.

К настоящему времени наибольшее распространение получили следующие модели ЖЦ:

- каскадная (водопадная) модель (70-85 г.г.);

- спиральная модель (86-90 г.г.).

- инкрементальная модель

Каскадная модель процесса

Анализ требований - сбор требований к продукту. Результатом анализа, как правило, является некоторый текст/документ(ТЗ).

Проектирование - описывает внутреннюю структуру продукта. Обычно такое описание дается в форме диаграмм и текстов.

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

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

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

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

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

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

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

 

Модели ЖЦ ПО. Спиральная модель. Содержание этапов создания ПИ.

Стандарт ISO/IEC 12207 не предлагает конкретную модель ЖЦ и методы разработки ПО (под моделью ЖЦ понимается структура, определяющая последовательность выполнения и взаимосвязи процессов, действий и задач, выполняемых на протяжении ЖЦ. Модель ЖЦ зависит от специфики ИС и специфики условий, в которых последняя создается и функционирует). Его регламенты являются общими для любых моделей ЖЦ, методологий и технологий разработки. Стандарт ISO/IEC 12207 описывает структуру процессов ЖЦ ПО, но не конкретизирует в деталях, как реализовать или выполнить действия и задачи, включенные в эти процессы.

К настоящему времени наибольшее распространение получили следующие модели ЖЦ:

- каскадная (водопадная) модель (70-85 г.г.);

- спиральная модель (86-90 г.г.).

- инкрементальная модель

Спиральная модель процесса

В случае спирального процесса (автор Барри Боэм,1988) последовательность анализ требований - проектирование - реализация - тестирование выполняется более одного раза.

Для этого может быть несколько причин:

- необходимость предупреждения рисков;

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

Версии продукта называют прототипами. Каждый виток спирали соответствует созданию фрагмента или версии ПО.

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

Дополнительное преимущество: на каждом витке спирали можно собрать метрические характеристики проекта (трудоемкость затрат, затраты на проект, длительность, документированность).

Т.о. уточняется план-график дальнейшей работы.

Минусы:

1. Требуется более искусное управление

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

3. Трудность в определении момента перехода на следующий этап.

4. Переход осуществляется в соответствии с планом даже если не все работы выполнены.

5. Слишком большое количество витков потребует увеличения затрат, больших затрат.

Типичный проект:

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

 

Модели ЖЦ ПО. Инкрементальная модель. Содержание этапов создания ПИ.

Стандарт ISO/IEC 12207 не предлагает конкретную модель ЖЦ и методы разработки ПО (под моделью ЖЦ понимается структура, определяющая последовательность выполнения и взаимосвязи процессов, действий и задач, выполняемых на протяжении ЖЦ. Модель ЖЦ зависит от специфики ИС и специфики условий, в которых последняя создается и функционирует). Его регламенты являются общими для любых моделей ЖЦ, методологий и технологий разработки. Стандарт ISO/IEC 12207 описывает структуру процессов ЖЦ ПО, но не конкретизирует в деталях, как реализовать или выполнить действия и задачи, включенные в эти процессы.

К настоящему времени наибольшее распространение получили следующие модели ЖЦ:

- каскадная (водопадная) модель (70-85 г.г.);

- спиральная модель (86-90 г.г.).

- инкрементальная модель

Инкрементальная модель

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

Например, Кукумано и Сэлби [21] подготовили доклад по процессу, используемому в некоторых отделениях корпорации Microsoft, где обновления программного кода и документации предоставляются ежедневно к конкретному времени для интеграции и ночного тестирования. Другие организации используют для этого недельные циклы. Для поддержания соответствующего уровня инкрементальной разработки необходимo иметь четко установленную архитектуру проекта и исключительно синхронизированную систему документации (рис. 1.10). Для организации инкрементальной разработки обычно выбирается характерный временной интервал, например неделя. Затем в течение этого интервала происходит обновление исходного проекта (документации, набора тестов, программного кода и т.д.). Теоретически шаги разработки (increments) могут выполняться и параллельно, но такой процесс очень сложно скоординировать. Инкрементальная разработка проходит лучше всего, если следующая стадия п+1 начинается по возможности после того, как обновление всех модулей на стадии п закончено, и хуже всего, если время, требуемое на обновление модулей, значительно превышает выбранный интервал. Для того чтобы убедиться в этом, представьте, что необходимо изменить модуль 789, который зависит от семи других модулей: 890, 23, 489, 991, 7653, 2134 и 2314. Если изменение занимает девять недель, то модуль 789 должен быть построен исходя из предполагаемого состояния всех семи модулей через девять недель. Эту работу очень трудно скоординировать, так как каждая из семи частей может быть изменена до девяти раз (еженедельно), причем каждое новое изменение может основываться на исследовании эффективности предыдущих изменений.

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

2 Проектная документация программного обеспечения

3 Спецификация требований к программному обеспечению

 

Методология функционального моделирования SADT. Состав функциональной модели. Иерархия диаграмм. Типы связей между функциями. Примеры функциональных моделей в стандарте IDEF0.

Предложена Дугласом при работе над военными проектами.

На основе SADT разработана методика IDEF0 (для описания предметной области) комитетом ICAM.

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

Основные элементы методологии:

1. блочное моделирование:

- функции - это блоки

- интерфейсы входа/выхода - дуги (стрелки)

2. строгость и точность

Существует определенные правила SADT:

- количество блоков на диаграмме 3-6

- связанность диаграмм (номера блоков)

- уникальность наименования (повторений не д.б.)

- синтаксические правила для блоков и дуг

- разделение входов и управлений

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

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

Состав функциональной модели

Функция - это действие; формулируется в виде глагола в неопред. Форме, либо - отглагольного сущго.

Вход - это информация/ресурсы, подлежащие преобразованию

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

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

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

Признак блокировки

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

1. ресурсы, которые не блокируются - ресурсы общего пользования

2. блокируемые - может использоваться только одной функцией в один момент времени (пр.: входы и инструменты).

Иерархия диаграмм

1. контекстная диаграмма

название блока - название всех модели

на диаграмме д.б.:

цель составления работы

точка зрения - должность человека (как min), который строит данную диаграмму, либо со слов которого строится

2. далее след. диаграмма (главная в контекстной диаграмме)

Типы связей между функциями

Одним из важных моментов при проектировании ИС с помощью методологии SADT является точная согласованность типов связей между функциями. Различают по крайней мере семь типов связывания:

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

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

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

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

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

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

6 Диаграмма отражает полную функциональную связность, при наличии полной зависимости одной функции от другой

Значимость Тип связности Для функций Для данных

0 Случайная Случайная Случайная

1 Логическая Функции одного и того же множества или типа (например, "редактировать все входы") Данные одного и того же множества или типа

2 Временная Функции одного и того же периода времени (например, "операции инициализации") Данные, используемые в каком-либо временном интервале

3 Процедурная Функции, работающие в одной и той же фазе или итерации (например, "первый проход компилятора") Данные, используемые во время одной и той же фазы или итерации

4 Коммуникационнная Функции, использующие одни и те же данные Данные, на которые воздействует одна и та же деятельность

5 Последовательная Функции, выполняющие последовательные преобразования одних и тех же данных Данные, преобразуемые последовательными функциями

6 Функциональная Функции, объединяемые для выполнения одной функции Данные, связанные с одной функцией

Глоссарий

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

Принципы ограничения сложности IDEF0

- Количество функциональных блоков 3-6

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

 

16. Моделирование потоков данных (процессов). Внешние сущности. Системы и подсистемы. Процессы. Накопители данных. Потоки данных. Построение иерархии диаграмм потоков данных.

Ее основой послужила диаграмма Гейна-Сарсона.

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

Компоненты диаграммы:

1. внешняя сущность

2. системы и подсистемы

3. процесс

4. накопители данных

5. потоки данных

Внешняя сущность

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

Пр.: заказчик, клиент, поставщик

Системы и подсистемы(С/ПС)

Сложная ИС всегда декомпозируется на ряд ПС.

Поле имени формулируется в виде подлежащего и дополнения (нет глаголов)

Процессы

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

Физически это: отдел организации, автоматизированная система, аппаратное устройство и т.д.

Пр. поля физич. реализации: 1С-бухгалтерия

Накопители данных

Это абстрактное устройство для хранения данных.

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

Накопитель данных физически это:

- Ящик в картотеке

- Файл на магнитном носителе, Таблица в бД и т.д.

Накопитель данных для проектировщика является прообразом будущей БД.

Потоки данных

Информация, передаваемая ч/з некоторое соединение от источника к приемнику.

Каждый поток данных должен иметь имя.

Построение иерархии диаграмм потоков данных

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

Правила детализации:

a. Правило балансировки

На детализирующей диаграмме внешние источники/приемники данных - это

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

b. Правило нумерации - иерархическая нумерация.

Миниспецификация - это описание логики процесса.

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

Для создания миниспецификации у DFD д.б. не более 2-3 потоков, описание которых не более 30 строк.

 

Проектирование ИС на основе объектно-ориентированного подхода. Объектно-ориентированная разработка программ. Объектно-ориентированные языки программирования. Объектно-ориентированные методологии разработки программных систем. CASE - средства разработки ПО.

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

- объектно-ориентированные технологии разработки программных систем;

- инструментальные средства, поддерживающие эти технологии.

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

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

Различные объектно-ориентированные методологии разработки программного обеспечения:

- RUP (Rational Unified Process)

- OMT (Object Modeling Technique)

- SA/SD (Structured Analysis/Structured Design);

- JSD (Jackson Structured Development);

- OSA (Object-Oriented System Analysis)

Объектно-ориентированные языки программирования

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

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

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

Но достоинства языка Simula 67 были замечены некоторыми программистами, и в 70-е годы было разработано большое число экспериментальных объектно-ориентированных языков программирования: например, языки CLU, Alphard, Concurrent Pascal и др. Эти языки так и остались экспериментальными, но в результате их исследования были разработаны современные объектно-ориентированные языки программирования: C++, Smalltalk, Eiffel и др.

Наиболее распространенным объектно-ориентированным языком программирования безусловно является C++. Разработка новых объектно-ориентированных языков программирования продолжается. С 1995 года широко распространен новый объектно-ориентированный язык программирования Java, ориентированный на сети компьютеров и, прежде всего, на Internet.

 

Внешние

1.1. корректность (правильность)

1.2. устойчивость

1.3. расширяемость

1.4. многократность использования

1.5. совместимость

1.6. эффективность

1.7. переносимость

1.8. поддержка целостности

1.9. легкость использования

Внутренние

2.1. верификация

2.2. читабельность кода

2.3. модульность

2.4. структурированность

2.5. документированность (кода)

Внутренние характеристики являются ключом и причиной внешних характеристик качества.

Корректность и устойчивость

Корректность - правильная обработка на правильных данных

Устойчивость - не только правильность, это способность обрабатывать ситуации незапланированные проектом.

Устойчивые системы терпят неудачу без потери критических данных, т.е. предусмотрены непредвиденные ситуации в коде.

Расширяемость

Это важнейшее свойство для больших проектов.

Принципы создания расширяемого ПО:

Простота проекта

Децентрализация - разбиение сложных проблем на малые

Управляемость и независимость фрагментов (модульное программирование)

Многократность и совместимость

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

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

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

Совместимость - мера того, на сколько просто объединить различные программные изделия вместе для повторного применения.

Основы совместимости вытекают, как правило, из общих проектных решений.

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

 

Цели и задачи технологий разработки ПО. Особенности современных крупных проектов ИС

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

Современные крупные проекты ИС характеризуются, как правило, следующими особенностями:

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

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

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

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

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

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

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

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

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

 

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

Введение в процесс разработки программного обеспечения

Разработка программного обеспечения является очень молодой и быстро развивающейся отраслью инженерной науки. Она подвержена постоянным и быстрым изменениям. Так, всего лишь в начале 90-х годов Британское сообщество вычислительной техники (British Computer Society) начало присваивать разработчикам программ звание инженера (Chartered Engineer), а в Соединенных Штатах только в 1998 году стало возможным хоть где-то (а точнее, в штате Техас) зарегистрироваться в качестве профессионального инженера программного обеспечения. Но по-прежнему, даже в начале двадцать первого века, общепризнанным остается тот факт, что разработке программного обеспечения не достает достаточно развитой научной базы. По некоторым оценкам, 75 % организаций, занимающихся разработкой программ, делают это на примитивном уровне. С другой стороны, в этой области сформировалось немало интересных идей, и знакомство с ними

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

Программное обеспечение (Software) - полный набор или часть программ, процедур, правил и связанной с ними документации системы обработки информации. (ИСО/МЭК 2382-1 1993) Примечание. ПО - интеллектуальный продукт, не зависящий от среды, на которой он записан.

Программные средства (Software product) -набор компьютерных программ, процедур и, возможно, связанных с ними документации и данных. Примечание. Объем понятия, выражаемого термином "программные средства" включает в себя как частный случай объем понятия 'программное обеспечение".определяемого по Г'ОСТ 19781. [см. ГОСТ 28806-90. приложение 1 ]

Программный продукт (Software product) - набор компьютерных программ, процедур и, возможно, связанных с ними документации и данных, предназначенных для передачи пользователю [ИСО/МЭК 12207]. Примечание. Продукты включают промежуточные продукты и продукты, предназначенные для пользователей типа разработчиков и персонала сопровождения

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