Лекция 3

ПО.

ЕСПД. Схемы алгоритмов и программ. Обозначения условные графические.
ГОСТ 19.005-85. ЕСПД.

Р-схемы алгоритмов и программ. Обозначения условные графические и правила выполнения.
ГОСТ 19.101-77. ЕСПД. Виды программ и программных документов.
ГОСТ 19.102-77. ЕСПД. Стадии разработки.
ГОСТ 19.103-77. ЕСПД. Обозначение программ и программных документов.
ГОСТ 19.104-78. ЕСПД. Основные надписи.
ГОСТ 19.105-78. ЕСПД. Общие требования к программным документам.
ГОСТ 19.106-78. ЕСПД. Требования к программным документам, выполненным печатным способом.
ГОСТ 19.201-78. ЕСПД. Техническое задание. Требования к содержанию и оформлению.
ГОСТ 19.202-78. ЕСПД. Спецификация. Требования к содержанию и оформлению.
ГОСТ 19.301-79. ЕСПД. Программа и методика испытаний. Требования к содержанию и оформлению.
ГОСТ 19.401-78. ЕСПД. Текст программы. Требования к содержанию и оформлению.
ГОСТ 19.402-78. ЕСПД. Описание программы.

19.404-79. ЕСПД. Пояснительная записка. Требования к содержанию и оформлению.
ГОСТ 19.501-78.

ЕСПД. Формуляр. Требования к содержанию и оформлению.
ГОСТ 19.502-78. ЕСПД. Описание применения. Требования к содержанию и оформлению.
ГОСТ 19.503-79. ЕСПД. Руководство системного программиста. Требования к содержанию и оформлению.
ГОСТ 19.504-79. ЕСПД. Руководство программиста. Требования к содержанию и оформлению.
ГОСТ 19.505-79. ЕСПД. Руководство оператора. Требования к содержанию и оформлению.
ГОСТ 19.506-79. ЕСПД. Описание языка. Требования к содержанию и оформлению.
ГОСТ 19.507-79. ЕСПД. Ведомость эксплуатационных документов.
ГОСТ 19.508-79. ЕСПД. Руководство по техническому обслуживанию. Требования к содержанию и оформлению.
ГОСТ 19.601-78. ЕСПД. Общие правила дублирования, учета и хранения.
ГОСТ 19.602-78. ЕСПД. Правила дублирования, учета и хранения программных документов, выполненных печатным способом.
ГОСТ 19.603-78. ЕСПД. Общие правила внесения изменений.
ГОСТ 19.604-78. ЕСПД. Правила внесения изменений в программные документы, выполненные печатным способом.
ГОСТ 19.701-90 (ИСО 5807-85). ЕСПД. Схемы алгоритмов, программ, данных и систем. Условные обозначения и правила выполнения.

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

•  

 Техническое задание
•    Эскизный проект
•    Технический проект
•    Рабочий проект
•    Программная документация
   -    Спецификация
   -    Ведомость держателей подлинников
   -    Текст программы
   -    Описание программы
   -    Программа и методика испытаний
   -    Пояснительная записка
•    Эксплуатационные документы
   -    Ведомость эксплуатационных документов
   -    Формуляр
   -    Описание применения
   -    Руководство системного программиста
   -    Руководство программиста
   -    Руководство оператора (пользователя)
   -    Описание языка
   -    Руководство по обслуживанию (руководство администратора)

ISO 9126 определяет 6 характеристик качества ПО:

Функциональность (functionality),
Надежность (reliability),
Практичность или

удобство использования (usability),
Эффективность (efficiency),
Сопровождаемость (maintainability),
Переносимость или мобильность (portability).

определенных условиях.

Пригодность к определенной работе(suitability)
Точность, правильность (accuracy)
Способность к взаимодействию (interoperability)
Защищенность

(security)
Соответствие стандартам и правилам (compliance)

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

завершенность (обратна к частоте отказов) (maturity)
Устойчивость к отказам (fault tolerance)
Способность к восстановлению работоспособности при отказах (recoverability)
Соответствие стандартам надежности (reliability compliance)

изучаемым, применимым и привлекательным для пользователя в заданных условиях. 
Понятность (understandability)
Удобство

обучения (learnability)
Работоспособность (operability)
Привлекательность (attractiveness)
Соответствие стандартам практичности (usability compliance)

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

behaviour)
Использование ресурсов (resource utilisation)
Соответствие стандартам эффективности (efficiency compliance)

внесения изменений (changeability)
Риск возникновения неожиданных эффектов при внесении изменений или

стабильность (stability)
Тестируемость, удобство проверки (testability)
Соответствие стандартам сопровождаемости (maintainability compliance)

в другую. 
Адаптируемость (adaptability)
Устанавливаемость, удобство установки (installability)
Способность к сосуществованию с другим

ПО (coexistence)
Удобство замены другого ПО данным (replaceability)
Соответствие стандартам переносимости (portability compliance)

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

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

процессов, работ и задач в рамках модели жизненного цикла. Условно

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

окончания проекта) устранение основных рисков.
Концентрация на выполнении требований заказчиков к

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

работу с артефактами проекта, контролировать и управлять доступом к ним,

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

проекта.
Создается экономическое обоснование (business case).
Определяются основные требования, ограничения и ключевая

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

(включая детальное описание большинства вариантов использования).
Спроектированную, реализованную и оттестированную исполняемую

архитектуру.
Обновленное экономическое обоснование и более точные оценки сроков и стоимости.
Сниженные основные риски.

этой фазы происходит реализация большей части функциональности продукта.
Фаза Построение

завершается первым внешним релизом системы.
4. Внедрение (Transition)
Во время фазы Внедрение создается финальная версия продукта и передается от разработчика к заказчику. Это включает в себя программу бета-тестирования, обучение пользователей, а также определение качества продукта.

проекте, и их общение более важны, чем процессы и инструменты.
Работающая

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

ранней и бесперебойной поставки ценного ПО;
приветствие изменений требований, даже

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

системы
Простые проектные решения (simple design)
Разработка на основе тестирования (test-driven development)
Программирование

парами (pair programming)
Коллективное владение кодом (collective ownership)
Постоянная интеграция (continuous integration)
40-часовая рабочая неделя
Включение заказчика в команду (on-site customer)
Открытое рабочее пространство (open workspace)
Изменение правил по необходимости (just rules)

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

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

программирование завершено;
комплексная отладка завершена;
оборудование закуплено;
группа технических писателей

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

следует:
Определить источники запросов на изменение.
Установить порядок анализа, оценки

и утверждения/отклонения изменения содержания.
Определить порядок документирования изменений содержания.
Определить порядок информирования об изменении содержания.

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

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

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

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

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

Может быть наиболее наглядно представлено диаграммой Ганта.

образом:
С = ТхЦ,
где С — стоимость; Т — трудозатраты

(например, в человеко-часах или человеко-месяцах); Ц — их удельная стоимость, которую определяют, в основном исходя из заработной платы и связанных с ней начислений.
Трудозатраты вычисляют по следующей формуле:
Т = РхП.
Здесь Р — размер кода программы, чаше всего измеряется в строках (LOC — Lines Of Code); П — временная производительность.

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

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

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

веса (от 0 до 5) каждой характеристике проекта. Определяется
S — сумма всех весов.
И наконец, уточненный функциональный размер вычисляется по формуле УФР = ФР х (0,65 + 0,01 х S)

базовом уровне СОСОМО:
Т = ахРхb
где а и b —

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

по модели СОСОМО вычисляется по формуле
F= 2,5 х Т

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

три варианта использования — фактически это три разные модели для

решения различных задач, объединенные под одним общим названием