- •Содержание
- •1.13. Задания для самопроверки 59
- •1.17. Задания для самопроверки 88
- •1.19. Задания для самопроверки 108
- •1.23. Задания для самопроверки 116
- •1.27. Задания для самопроверки 125
- •1.37. Задания для самопроверки 144
- •1.48. Задания для самопроверки 159
- •Перечень рисунков
- •Перечень таблиц
- •Введение
- •Принятые сокращения
- •1.Жизненный цикл разработки по
- •Программные проект и его атрибуты
- •Ролевые модели в программном проекте
- •Размер и сложность программного проекта
- •Характеристики программного проекта
- •Качество программного продукта
- •Экран проекта и сводка о подходе
- •Критерий smart для формулирования целей
- •Критерии успешности программного проекта
- •Модели жизненного цикла
- •Водопадная модель
- •Модель быстрой разработки приложения
- •Пошаговая модель
- •Спиральная модель Боэма
- •Прототипная модель
- •Выбор модели жизненного цикла
- •Задания для самопроверки
- •2.Типовой каркас для разработки по
- •Программная разработка
- •Планирование проекта
- •Модель cocomo для оценки трудозатрат в проекте
- •Модель slim для оценки трудозатрат в проекте
- •Разработка спецификации требований
- •Отслеживание и контроль
- •Верификация и валидация
- •Обеспечение качества
- •Конфигурационное управление
- •Метрики
- •Повышение квалификации
- •Задания для самопроверки
- •3. Модели зрелости способностей cmm/cmmi
- •Ключевые области процесса в модели cmm
- •Характеристика уровней зрелости в модели cmm
- •Интегрированная модель зрелости способностей cmmi
- •История возникновения
- •Уровни зрелости и области процесса
- •Уровни способностей процесса в модели cmmi
- •Специальные и общие цели и практики процессных областей
- •Характеристики уровней зрелости в модели cmmi
- •Задания для самопроверки
- •4.Управление рисками в программном проекте
- •Модели esi и pmi управления рисками
- •Выявление рисков
- •Анализ рисков
- •Расстановка приоритетов для рисков
- •Планирование рисков
- •Исполнение ответных стратегий
- •Оценивание результатов исполнение ответных стратегий
- •Документирование действий по рискам
- •Заключительное оценивание рисков
- •Задания для самопроверки
- •5.Стандарты качества iso в применении к по
- •Структура и принципы семейства стандартов iso 9000
- •Модели iso 9000 на базе процессов
- •Самооценивание по ключевым элементам iso 9000
- •Задания для самопроверки
- •6.Формальные методы в разработке по
- •Инструменты формализации и верификации
- •Взаимодействие функциональностей
- •Интегрированная технология анализа и верификации
- •Задания для самопроверки
- •7.Некоторые общие технологические приемы
- •Инспекции по Фейгану
- •Диаграммы Исикавы («рыбий скелет»)
- •Инструменты
- •Swot-анализ
- •Сбалансированный экран результативности
- •Технологическая дорожная карта
- •Метод Дельфи
- •Деревья решений
- •Сравнительное ранжирование
- •Методология подвижного программирования
- •Принципы подвижного программирования
- •Рабочий цикл и роли участников
- •Рабочие документы и обстановка
- •Задания для самопроверки
- •8.Сертификация программного обеспечения в авиации
- •История создания серии документов do-178 и ed-12
- •Уровни программного обеспечения
- •Процессы жизненного цикла по авиационных систем
- •Цели процессных деятельностей
- •Рабочие документы и категории их контроля
- •Процесс планирования по
- •Процессы разработки по
- •Определение требований
- •Проектирование
- •Кодирование
- •Верификация
- •Конфигурационное управление
- •Обеспечение качества
- •Контакт с органом сертификации
- •Выводы и рекомендации
- •Задания для самопроверки
- •9.Задания для самостоятельной работы
- •Темы, связанные с единым каркасом для разработки по
- •Перечень тем
- •Краткое описание каждой темы
- •Тема 2. Программная архитектура базового инструмента для распределенного управления программными проектами
- •Тема 3. Профили типовых рабочих компонентов для разработки приложений
- •Тема 1. Прототип метрической базы данных для управления разработкой приложений
- •Тема 5. Репозиторий повторно используемых компонентов
- •Тема 6. Сквозной пример для единого каркаса разработки приложений
- •Темы, связанные применением формальных методов перечень тем
- •Тема 1. Сравнительный анализ систем верификации
- •Тема 2. Формализация протоколов связи краткое описание каждой темы
- •Тема 1. Сравнительный анализ систем верификации
- •Тема 2. Формализация протоколов связи
- •10.Литература
- •11.Приложения
- •Шаблон для одностраничного экрана проекта
- •Примерная структура положения о работе и тз
- •Примерная форма еженедельного отчета
- •Примерная форма презентации на ежемесячном операционном обзоре
- •12.Указатель
Повышение квалификации
Обычно в организации-разработчике имеется выделенное лицо – координатор программы повышения квалификации (training program coordinator), которое несет ответственность за планирование и координацию технического обучения, и повышение квалификации всех сотрудников во всех проектных группах. Этот координатор обычно готовит и проводит большинство курсов обучения для сотрудников, используя как внутренние ресурсы организации, так и привлекая внешние источники, в рамках единой для организации программы технического обучения. Эта программа, как правило, составляется на несколько лет вперед и регулярно обновляется.
Цель деятельностей по повышению квалификации заключается в создании условий для развития навыков и знаний у исполнителей проектов для более эффективного выполнения ими поставленных задач. Непрерывное плановое повышение квалификации является важным элементом организационной дисциплины и состоит в планомерном развитии навыков и знаний конкретных лиц, чтобы они могли исполнять свои роли в проектах действенно и разумно (effectively and efficiently).
В каждом проекте отдельно должны быть определены, какие специальные навыки необходимы для его успешного выполнения, и должно быть обеспечено необходимое обучение в соответствии с выявленными недостатками в наличных знаниях. Координатор программы повышения квалификации согласовывает эти проектные требования по повышению квалификации с общей программой технического обучения и обеспечивает их выполнение максимально эффективным и экономным образом.
Задания для самопроверки
Создайте положение о работе для известного Вам проекта.
Сделайте предварительную оценку трудоемкости Вашего проекта на основе модели COCOMO, сравните эти оценки с реальными данными и объясните расхождения.
Определите структуру разбиения работ для этого проекта и обоснуйте ее.
Для каждого из следующих функциональных требований укажите его свойства (неоднозначность, составность, элементарность, условность, выводимость):
пользовательский интерфейс должен быть дружественным;
система должна быть высоко функциональной;
радиосвязь должна отвечать спецификациям ST152D и ST204D;
тестовое оборудование должно быть совместимо по шине;
устройство должно быть совместимо с RS232;
должен применяться короткий производственный цикл;
каждый экран должен отображать номер и дату заказа;
Установка должна завершаться за 45 минут;
плотность дефектов должна быть меньше 5,7 сигма;
соединение должно быть через болт диаметром 6 типа А;
надпись «M&M» должна быть красного цвета №2;
дата должна быть в стандартном формате.
Возьмите какой-либо реальный проект и 20-30 требований из него, найдите в тексте этих требований все места неоднозначности и перепишите эти места так, чтобы найденные неоднозначности устранить. В качестве альтернативы можно взять следующий набор из 21 формулировки:
The network management system must provide the following capabilities:
Management applications to monitor, diagnose, and correct network faults. Real-time monitoring of network nodes requires standard topology and fault management functions, and a state-of-the-art user interface design to support those applications for very large networks.
Network data whether dynamic (e.g., events, status) or relatively static (e.g., configuration), must be stored in a flexible data base at the management system. This information must be employed by all management applications in an intelligent fashion, and must be available to standard PC, workstation, and/or mainframe reporting system.
As much integration of data bases and applications as possible should be provided, but not at the expense of time to market. At a minimum, a window between the systems must be provided, and data bases which are not consolidated should be compatible; i.e., share a common format or the ability to export to a common format.
The system will be based on a new management hardware and software platform. As such, it must be designed to support any network devices that will be integrated beyond the system’s nodes.
The system will be the only tool with the ability to test, check status, reconfigure, and gather statistics on the networks in real time. Therefore, these management applications are a critical element of the system.
The system must be able to accept inventory, configuration, and performance data from other systems since these systems are targeted to provide the nodal and network optimization functions. In addition, the system must be able to provide this information to these same systems to re-optimize the network or validate hypotheses.
The user interface for the system must:
Prioritize graphical application implementations over text-based displays wherever possible and appropriate. A particular example is selecting a physical or logical component below the node level in order to perform a snapshot, create a trouble ticket, run a test, etc.; the operator should be able to click on the component (or representation) rather than typing in component identifiers.
Ensure that window multiple active applications simultaneously, without restrictions; any performance issues relative to multiple applications are clearly documented for uses.
Support active applications as icons; i.e., running without an active window.
Support cut and paste between all management applications; e.g., the ability to paste test results, event text, snapshot data, or configuration information into a trouble ticket.
Synchronize real-time data between applications; i.e., if multiple status windows are active simultaneously, a parameter of status change in one window will be immediately updated in all other windows.
Update all windows while displayed, even though only one window will accept user input.
Allow simultaneous access to any and all system capabilities for multiple operators at one or many locations.
Minimize the use of «locking» features, which restrict multiple operators from using the same applications.
Support an optional text-entry interface with scripting and programming capability.
Demonstrate a common look and feel for all functions without the use of text-based files.
Provide a customer-usable audit trial of all operator actions, with the option to save and view multiple session files; the trial must not be limited to disruptive operations, but rather must contain a listing of all operator activity.
Provide «Tutor mode» with simulation.
Provide status of ongoing actions and background tasks such as downloads, uploads, and archives.
Multiple device actions (views, aggregates, and multiple mouse selections); use for event logs and queries, tests on multiple devices, stats collection setups, trouble tickets, extraction filters, etc.
Support customization where possible (help text, event text, tags and priorities, icons, screens, etc.)
Определите, какие управленческие и поддерживающие процессы необходимы в Вашей организации-разработчике, и дайте обоснование Вашего перечня.
Представьте Ваш пошаговый план перехода на требующийся Вашему проекту процесс разработки и обоснуйте его.