Формирование требований к программному продукту
22. основы проектирования программных систем. Особенности этапа проектирования.
Структурный подход к разработке программ. Комбинация базовых структур.
24. структурирование. Методы структурирования прорамм. Декомпозиция подсистем на модули. Модульность.
25. цели модульного программирования. Основные характеристики программного модуля.
Типовая структура программного модуля
27. локальные и глобальные переменные
28. ошибки программного обеспечения. Ошибки, возникающие на стадии разработки
29. ошибки программного обеспечения. Виды ошибок.
30. отладка, инструментальные средства отладки
31. тестирование
Структурное тестирование программного обеспечения
Разновидности тестирования «белого ящика». Способ базового пути.
Разновидности тестирования «белого ящика». Способ тестирования условий.
Разновидности тестирования «белого ящика». Способ тестирования ветвей и операторов отношений.
Разновидности тестирования «белого ящика». Тестирование циклов.
Тестирование «черного ящика»
38. организация процессов тестирования программного обеспечения
Драйвер тестирования
Тестирование интеграций. Нисходящее тестирование.
Тестирование интеграций. Восходящее тестирование.
42. объектно-ориентированный подход в информационных технологиях.
43. объекты и классы в среде Windows.
44. методы и свойства объекта в среде Windows.
45. использование виртуальных компонентов.
Унифицированный процесс разработки ООПС. Этапы унифицированного процесса разработки
объектно-ориентированное тестирование
48. проектирование объектно-ориентированных тестовых вариантов.
49. общее понятие методики RAD. Использование визуальных компонентов.
50. структура и формат данных
51. стили программирования.
1. технология: понятия, особенности создания программного продукта разработки программного продукта 3
2. жизненный цикл программного продукта (ЖЦПП) 4
3. каскадная модель жизненного цикла 5
4. V-образная модель жизненного цикла 6
5. RAD-модель, многопроходная, спиральная модели жизненного цикла. 8
6. основные процессы ЖЦПП 12
7. вспомогательные принципы ЖЦПП 13
8. организационные процессы ЖЦПП 14
9. основные этапы работ по созданию программного продукта 15
10. единая система программной документации. Общие определения 16
11. единая система программной документации. Виды программных документов 17
12. единая система программной документации. Стадии разработки 19
13. примерная структура организации, занимающаяся разработкой ПП 21
14. управления качеством разработки ПП с помощью системы стандартов ISO 22
15. обеспечение качества разработки. Модель CMM-SEI. 23
16. метрики. Роль метрик в процессах разработки ПП 25
17. метрики и модели CMM-SEI. Парадигмы Бейзили 27
18. функционально-ориентированные метрики. 31
19. эффективные алгоритмы. Оптимизирующие компиляторы 32
20. выполнение оценки в ходе руководства проектом. Конструктивная модель стоимости COCOMO 33
22. основы проектирования программных систем. Особенности этапа проектирования. 35
24. структурирование. Методы структурирования прорамм. Декомпозиция подсистем на модули. Модульность. 36
- технология: понятия, особенности создания программного продукта разработки программного продукта
«Технология - совокупность методов обработки, изготовления, изменения состояния, свойств, форм сырья, материала или полуфабрикатов в процессе производства; наука о способах воздействия на сырье, материалы или полуфабрикаты соответствующими орудиями производства»
Словарь иностранных слов
«Технология – способ реализации людьми конкретного сложного процесса путем разделения его на систему последовательных взаимосвязанных процедур, операций, которые выполняются более или мене однозначно и имеют целью достижения высокой эффективности»
Под процедурой понимается набор действий (операции), по средствам которых осуществляется тот или иной главный процесс, выражающий суть конкретной технологии.
Операция – непосредственное практическое решение задачи в рамках главной процедуры,
т. е. однородная логически неделимая часть конкретного процесса.
Наш продукт – программное обеспечение информационных систем, медиасистем и т.д. Это результат интеллектуального труда – интеллектуальный продукт, но, несмотря на творческий характер труда программиста, этот труд необходимо правильно организовывать, ввести правила для облегчения работы, для возможности передачи программного продукта на сопровождение и эксплуатацию.
ТКПО
Т ехнология К онструирования П рограммного О беспечения – система инженерных принципов для создания экономичного ПО, которая надежно и эффективно работает.
Программный продукт (software product) – набор машинных программ, процедур и возможно связанных с ним документаций и данных.
Утилиты – средства для автоматизированного проектирования.
Объединение различных утилит называют CASE (Computing Access System Engineering) – утилитами.
Процесс конструирования ОП состоит из последовательности шагов, использующих методы, утилиты, процедуры. Эти последовательности шагов называются парадигмами
2. жизненный цикл программного продукта (ЖЦПП)
Ж изненный Ц икл ПП – непрерывный процесс, который начинается с момента принятия решения о необходимости создания программы и заканчивается моментом полного изъятия его из эксплуатации.
Основным нормативным документов, регламентирующим жизненный цикл программы является международный стандарт ISO/IEC 12207.
Принят в 1999 году.
Он определяет структуру жизненного цикла, который базируется на 3 группах процессов:
1. основные процессы;
2. вспомогательные процессы;
3. организационные процессы.
3. каскадная модель жизненного цикла
Принципиальная особенность каскадного подхода состоит в том, что пока не закончен один этап нельзя переходить к следующему, возвраты на предыдущие этапы не рассматриваются. Требования к программному продукту оформляются в техническое задание, которое на изменяется до окончания всех этапов. Критерием качества разработки является строгое следование по модели и точное выполнение требований в техническом задании.
Преимущества: на каждой стадии формируется законченный набор документации, отвечающий критериям полноты и согласованности; выполняемые в логической последовательности этапы позволяют планировать сроки выполнения всех работ и соответствующие затраты.
Недостатки: каскадная модель не гибкая, не итерационная.
Так как в жизни постоянно возникает потребность вернуться на предыдущие этапы, то возникает каскадная модель с возвратом.
Требования к программному продукту фиксируется в техническом задании на все время создания продукта, а согласование производится после каждого этапа.
- V-образная модель жизненного цикла
Эта модель была разработана как разновидность каскадной. От каскадной модели v-образная модель унаследовала последовательную структуру, в соответствии с которой каждая последующая фаза начинается только после успешного завершения предыдущей фазы. В этой модели определены четыре базовых этапа:
· анализ;
· проектирование;
· разработка;
· обзор.
Проектирование подразделяется на высокоуровневое и детальное (низкоуровневое). При выполнении анализа производится планирование проекта.
Разработка включает в себя кодирование. Обзор это различные виды тестирования.
Модели включают в себя следующие фазы:
1. составление требования к проекту и планирование – определяются системные требования и определяется планирование работ;
2. составление требования к продукту и их анализ – составляется полная спецификация требований к программному продукту;
3. высокоуровневое проектирование - определяется структура ПП, взаимосвязи между его компонентами и реализуемые ими функциями;
4. детальное – определяется алгоритм работы каждого компонента;
5. модульное тестирование – выполняется проверка каждого модуля, каждого компонента;
6. интеграционное тестирование – осуществляется интеграция ПП и его тестирование;
7. системное тестирование – выполняется проверка функционирования ПП после помещения его в программную среду в соответствии со спецификацией требований;
8. эксплуатация и сопровождение – запуск ПП в производство, внесение поправок и модернизация.
Преимущества:
1. большое значение придается верификации, аттестации не только самого ПП, но и всех полученных внутренних и внешних данных
2. удобное прослеживание хода работ, так как завершение каждой фазы является контрольной точкой;
3. все действия можно планировать.
Недостатки:
- не учитывается итерация между фазами;
- нельзя вносить изменения на разных этапах жизненного цикла;
- тестирование требований происходит слишком поздно, поэтому внесение изменений влияет на выполнение графика работ.
Целесообразно использовать с теми программными продуктами, для которых требуется высокая надежность.
- RAD-модель, многопроходная, спиральная модели жизненного цикла.
RAD – модель
В RAD-модели пользователь играет решающую роль, он участвует в разработке и формировании требований, апробации их в работе
В традиционном ЖЦПП разработки наибольшую часть времени затрачивают на программирование и тестирование, а в RAD-модели большую часть времени занимают планированием и проектированием.
Модель включает следующие фазы:
- составление требований и планирование – осуществляется с использованием метода совместного планирования требований;
- создание – детальное проектирование, кодирование, тестирование, поставка, сдача в эксплуатацию и сопровождение;
- сопровождение.
Достоинства:
- использование современных инструментальных средств позволяет сократить время цикла разработки;
- привлечение пользователя к разработке на ранних стадиях сводят к минимуму риск того, что он не останется недовольным готовым ПП;
- повторно используются компоненты уже существующих программ.
Недостатки:
- если заказчик не может постоянно участвовать в процессе разработки, то это может негативно сказаться на качестве ПП;
- для работы нужны высококвалифицированные кадры, умеющие пользоваться современными инструментальными средствами;
- существует риск, что программа не будет решена.
Можно применять при разработке ПП, которая хорошо поддается моделированию, когда требования к ПП хорошо известны, а заказчик может принять непосредственное участие в процессе разработки.
Многопроходная модель
Многопроходная модель - несколько итераций процесса построения прототипа ПП с добавлением на каждой следующей итерации новых функций или повышением эффективности.
Предполагается, что на первый трех стадиях выполняется конструирование ПП в целом, здесь определяется количество итераций (инкрементов) и относящихся к ним функции. Каждый инкремент проходит через этапы кодирования и тестирования.
Преимущества: в начале разработки требуются средства только на анализ и проектирование.
Основные функции ПП: после каждого инкремента получается готовый продукт; снижается риск неудачи и изменения требований, улучшается понимание, как разработчика, так и пользователя ПП требований для более поздних итераций. Инкременты функциональных возможностей легко тестируются.
Недостатки: не предусмотрены итерации внутри инкремента; определение полной функциональности должно быть определено в самом начале ЖЦПП, может возникнуть желание оттянуть решение сложных задач; общие затраты на создание не будут снижены по сравнению с другими моделями; обязательными условиями является наличие хорошего планирования.
Применяем если большинство требований будет сформулировано заранее, а для выполнения проекта выделен большой отрезок времени.
Спиральная модель
Принципиальной особенностью спиральной модели заключается в том, что ПП создается не сразу, а по частям с использованием метода прототипирование. Под прототипом понимается действующий программный компонент, реализующий некоторые функции и внешние интерфейсы пользователя. Создание прототипов, осуществляется за несколько итераций или витков модели.
Основная проблема спирального цикла – определение момента перехода на следующую стадию. Для ее решения необходимо ввести временные ограничения на каждую из стадий ЖЦ разработки. Переход осуществляется даже, если запланированная работа не завершена. План составляется на основе статистических данных, полученных в предыдущих проектах и личного опыта разработчика.
Достоинства:
· заказчик имеет возможность увидеть ПП на ранних стадиях разработки;
· заказчик принимает активное участие в разработке;
· в модели воплощены преимущества каскадной и многопроходной модели.
Недостатки:
· усложненная структура модели;
· спираль может продолжаться до бесконечности, т.к. каждая ответная реакция заказчика может породить новый виток итерации.
Качестве модели разработки ПП большое распространение получила улучшенная спиральная модель.
В отличие от простой спиральной модели эта модель использует каскадный процесс на завершающих стадиях разработки.
Применяют, если существует, хотя бы одна из причин:
1. целесообразно создание прототипов;
2. организация обладает навыками, требуемыми для адаптации модели;
3. заказчики не уверены в своих потребностях;
4. требования слишком сложные;
5. проект слишком большой;
6. требуется выполнить проект со средней или высокой степенью риска.
- основные процессы ЖЦПП
Основные процессы жизненного цикла состоят из 5 процессов, которые реализуются под управлением основных сторон, вовлеченных в жизненный цикл программных средств, основными сторонами являются: заказчик, поставщик, разработчик, оператор, персонал сопровождения ПП.
1. процесс заказа;
2. процесс поставки;
3. процесс разработки;
4. процесс эксплуатации (оператор);
5. процесс сопровождения.
Процесс состоит из работ и задач.
Процесс заказа
| Заказчик | Поставщик, разработчик |
| Процесс заказа: 1.подготовка; задачи: a. потребность в заказе; b. определение требований (он может поручить анализировать требования поставщику); c. варианты реализации заказа; d. документально оформить план заказа; план должен содержать: требования к системе, планируемую загрузку системы, тип реализуемого договора, обязанности организаций, участвующих в договоре, анализ возможных рискованных ситуаций, а также методы управления такими ситуациями. 2. подготовка и корректировка договора (соглашение), задачи: a. выбор поставщика; b. обсуждение условия договора с заказчиком (в договоре должны быть объявлены права собственности, права использования, лицензирование, связанные с используемыми в заказе готовыми программными продуктами); c. надзор за разработчиком; d. приемка и закрытие договора. | Процесс поставки:
|
Работа планирования состоит из следующих задач: провести анализ требований к заказу в целях создания структуры управления реализации проекта и обеспечения качества поставляемого программного продукта; выбрать модель жизненного цикла программных средств, в соответствии с областью применения, объемом и сложностью проекта, в модели жизненного цикла должны быть выбраны и структурированы процессы, модели и задачи из стандарта, установить требования к планам управления и обеспечения проекта в целом. Рассмотрение вариантов разработки ПП, сопоставив анализа риска реализации каждого варианта, оформить план управления проектом: организационная структура проекта, полномочия и обязанности каждого участника проекта, включая сторонние организации; техническая среда, включая условия проведения испытаний, оборудования, организацию архивной библиотеки, средства, стандарты, процедуры и инструментарий.
- вспомогательные принципы ЖЦПП
Вспомогательные процессы ЖЦ: процесс документирования, процесс управления конфигурацией(configuration management), процесс управления качеством (quality assurance process), процесс верификации (verification), процесс совместного анализа (join review process), процесс аудита, процесс разрешения проблем
Процесс документирования является процессом формализованного описания информации, созданной в процессе или работе ЖЦ. Это те документы, в которых нуждаются все заинтересованные лица, такие как администраторы, инженеры и пользователи программного продукта. Процесс документирования включает в себя следующие работы: подготовительные работа к документированию (необходимо разработать, документально оформить и реализовать план обозначения документов, выпускаемых в процессах ЖЦ). Для каждого обозначаемого документа должны быть определены: заголовок или наименование, назначение пользователя документа, процедуры и обязанности по подготовке исходных материалов, разработки, проверки, изменению, утверждению, выпуску, хранению, распространению, сопровождению и управлению конфигурацией, определяются сроки выпуска промежуточных и окончательных редакций. Проектирование и разработка документации; данная работа состоит из следующих задач: документы должны быть избраны и утверждены в соответствии с планом, при издании и распространении можно использовать любые носители, оригиналы документов должны храниться в соответствии с требованиями по учету, хранению, защите, обращению и дублированию.
Средства управления документированием должны быть определены в соответствии с процессом управления документации, сопровождение – внесение изменений, под конфигурацией ПП (IEEE-90) понимается совокупность функциональных и технических характеристик, установленных в технической документации и реализованных в ПП.
Процесс управления конфигурацией является процессом применения административных и технических процедур на всем протяжении жизненного цикла ПП для: обозначения, определения, установления состояния программных объектов в системе. Процесс включает в себя следующие работы: подготовка процесса, определение конфигурации, учет состояния конфигурации, оценка конфигурации, управление выпуском и поставка.
- организационные процессы ЖЦПП
Организационные процессы жизненного цикла состоят из следующих процессов: процесс управления (персоналом, проектом), процесс создания инфраструктуры (количество человек, машин), процесс усовершенствования, процесс обучения.
Взаимосвязь между процессами жизненного цикла ПП
Процессы могут быть использованы разными способами, различными организациями и сторонами с разных точек зрения и с различными целями, поэтому рассмотрим процессы их взаимосвязи с ключевых точек зрения
Штриховые линии указывают связь действующих лиц с конкретными процессами, а сплошные стрелки указывают на связь между собой.
В договорном аспекте заказчик и поставщик вступают в договорные отношения и реализуют процессы приобретения и поставки. В аспекте управления участвуют все, каждый выполняет свои процессы, менеджер является связующим звеном между организующими и основными процессами.
В процессе эксплуатации оператор, использующий систему, предоставляет необходимые услуги пользователю, в инженерном аспекте, разработчик решает соответствующие технические задачи, разрабатывая или модернизируя ПП.
В процессе поддержки предоставляет необходимые услуги остальным участникам работ. В рамках аспекта поддержки можно выделить аспект управления качеством ПП.
Организационные процессы выполняются на корпоративном уровне в целом. Процессы и реализующие их организации связаны между собой чисто функционально, при этом внутренняя структура и статус организации никак не регламентируются.
Одна и та же организация может выступать в роли поставщика или разработчика.
- основные этапы работ по созданию программного продукта
При создании программного продукта можно выделить 6 основных этапов:
1. планирование ПП (программный проект);
2. составление требований заказчика;
3. проектирование ПП;
4. разработка ПП;
5. тестирование ПП;
6. сопровождение ПП.
Первые 2 этапа создания начинаются практически одновременно при этом этап планирования заканчивается всегда раньше, чем этап составления требований (2). Большая длительность этапов объясняется тем, что в процессе работы над ПП приходится вносить коррективы в план, а иногда и в требования. На этих двух этапах определяются сроки и содержание работы по созданию будущего ПП. Этап тестирования начинается практически одновременно с этапами (1) и (2). На ранних стадиях тестируется не сам ПП, а разрабатываемая проектная документация.
Планирование ПП. В течение этапа планирования определяются все основные задачи, которые должны быть выполнены в процессе разработки, производится оценка финансовых, людских, технических и нетехнических ресурсов. Объемов и сложности, разрабатываемого ПП. Определяются методы тестирования и критерий приемки ПП. Методы и технология выполнения работы, строятся временные графики выполнения работ.
Составление требования заказчика. С течение этого этапа разработчики анализируют требования к ПП (форма представления информации), необходимые функции, желательные интерфейсы, существующие ограничения и т.д.
Требования тестируемой в такой степени, в какой разработчик тестов может построить ясный тест, дающий однозначный ответ «да» или «нет». И определяющий соответствие разрабатываемое ПП в данной спецификации требований.
Проектирование ПП. Этап проектирования предназначен для выработки и реализации модели разрабатываемого ПП. Процесс проектирования должен производиться в соответствии с теми методами и технологиями разработки, которые были определены в плане проекта. Проектирование может состоять из двух частей: высокоуровнего и низкоуровнего.
Разработка программного продукта (кодирование). На этом этапе производится еще и разработка технической документации. Также разработчики взаимодействует с инженерами по тестированию для создания надлежащих условий по тестированию.
Тестирование ПП. На этом этапе работает инженер-тестировщик, он разрабатывает тесты, проводит их и составляет отчеты о результатах тестирования.
Сопровождение ПП. Сопровождение – процесс внесения изменений в программный продукт и техническую документацию.
- единая система программной документации. Общие определения
Единая система программной документации - комплекс государственных стандартов, устанавливающих взаимоувязанные правила разработки, оформления и обращения программ и программной документации.
В стандартах ЕСПД устанавливают требования, регламентирующие разработку, сопровождение, изготовление и эксплуатацию программ, что обеспечивает возможность:
· унификации программных изделий для взаимного обмена программами и применения ранее разработанных программ в новых разработках;
· снижения трудоемкости и повышения эффективности разработки, сопровождения, изготовления и эксплуатации программных изделий;
· автоматизации изготовления и хранения программной документации.
Сопровождение программы включает анализ функционирования, развитие и совершенствование программы, а также внесение изменений в нее с целью устранения ошибок.
- единая система программной документации. Виды программных документов
К программным относят документы, содержащие сведения, необходимые для разработки, изготовления, сопровождения и эксплуатации программ.
Виды программных документов и их содержание приведены в табл. 2.
Таблица 2
| Вид программного документа | Содержание программного документа |
| Спецификация | Состав программы и документации на нее |
| Ведомость держателей подлинников | Перечень предприятий, на которых хранят подлинники программных документов |
| Текст программы | Запись программы с необходимыми комментариями |
| Описание программы | Сведения о логической структуре и функционировании программы |
| Программа и методика испытаний | Требования, подлежащие проверке при испытании программы, а также порядок и методы их контроля |
| Техническое задание | Назначение и область применения программы, технические, технико-экономические и специальные требования, предъявляемые к программе, необходимые стадии и сроки разработки, виды испытаний |
| Пояснительная записка | Схема алгоритма, общее описание алгоритма и (или) функционирования программы, а также обоснование принятых технических и технико-экономических решений |
| Эксплуатационные документы | Сведения для обеспечения функционирования и эксплуатации программы |
12. единая система программной документации. Стадии разработки
| Стадии разработки | Этапы работ | Содержание работ |
| 1. Техническое задание | Обоснование необходимости разработки программы | Постановка задачи Сбор исходных материалов Выбор и обоснование критериев эффективности и качества разрабатываемой программы. Обоснование необходимости проведения научно-исследовательских работ. |
| Научно-исследовательские работы | Определение структуры входных и выходных данных. Предварительный выбор методов решения задач. Обоснование целесообразности применения ранее разработанных программ. Определение требований к техническим средствам. Обоснование принципиальной возможности решения поставленной задачи | |
| Разработка и утверждение технического задания | Определение требований к программе. Разработка технико-экономического обоснования разработки программы. Определение стадий, этапов и сроков разработки программы и документации на неё. Выбор языков программирования. Определение необходимости проведения научно-исследовательских работ на последующих стадиях. Согласование и утверждение технического задания. | |
| 2. Эскизный проект | Разработка эскизного проекта | Предварительная разработка структуры входных и выходных данных. Уточнение методов решения задачи. Разработка общего описания алгоритма решения задачи Разработка технико-экономического обоснования. |
| Утверждение эскизного проекта | Разработка пояснительной записки. Согласование и утверждение эскизного проекта. | |
| 3. Технический проект | Разработка технического проекта | Уточнение структуры входных и выходных данных. Разработка алгоритма решения задачи. Определение формы представления входных и выходных данных. Определение семантики и синтаксиса языка. Разработка структуры программы. Окончательное определение конфигурации технических средств. |
| Утверждение технического проекта | Разработка плана мероприятий по разработке и внедрению программ. Разработка пояснительной записки. Согласование и утверждение технического проекта. | |
| 4. Рабочий проект | Разработка программы | Программирование и отладка программы. |
| Разработка программной документации | Разработка программных документов в соответствии с требованиями ГОСТ 19.101-77. | |
| Испытания программы | Разработка, согласование и утверждение порядка и методики испытаний. Проведение предварительных государственных, межведомственных, приёмо-сдаточных и других видов испытаний. Корректировка программы и программной документации по результатам испытаний. | |
| 5. Внедрение | Подготовка и передача программы. | Подготовка и передача программы и программной документации для сопровождения и (или) изготовления. Оформление и утверждение акта о передаче программы на сопровождение и (или) изготовление. Передача программы в фонд алгоритмов и программ. |
- примерная структура организации, занимающаяся разработкой ПП
Для организации предсказуемого и управляемого процесса разработки ПП компании необходимы организационные, технические и не технические средства.
Организационные средства включают в себя определенный перечень различных должностей и иерархию подчинения сотрудников вышестоящему руководству.
Общее выполнение работы программы выполняет директор. Вопросы, связанные с ходом различных проектов курирует исполнительный директор. А вопросы, связанные с организацией и обеспечением процесса компании, т.е. свода правил, процедур, рекомендаций и других руководящих документов, в соответствии с которыми компания действует, и работы обеспечения качества ПП – заместитель генерального директора.
Технические средства предназначены для организации соответствующих условий для работы над проектом. Технические средства включают себя разработанные или принятые к использованию стандарты, планы, а также книгу процесса, которая содержит подробное описание процесса компании. По метрикам процесса оценивают его основные характеристики (ключевые процессы) и результаты оценки заносят в паспорт процесса, этот паспорт позволяет отслеживать соблюдение процесса, а также планировать действия по его совершенствованию.
- управления качеством разработки ПП с помощью системы стандартов ISO
Международная организация по стандартизации разработала систему стандартов ISO 9001, которая регламентирует вопросы управления качеством. Целью ISO 9001 является построение системы сквозного управления качеством TQM (Total Quality Management), которая должна обеспечивать управление качеством на всех этапах разработки.
В ISO 9001 и SMM-SEI приведены процедуры сертификации организаций в соответствии системам стандартах качеством. Система стандартов ISO 9001 определяет минимальный набор требований по управлению качеством. Условно этот набор разбивается на три части требований: к менеджменту компании, контролю продукции, к процессу разработки.
Эффективная система качества не возможна, если менеджмент компании не осознает ее значения и не ставит цель ее построить.
От руководства компании требуется подписать формальное письмо. В письме указываются основные документы, на которые следует опираться при контроле качества.
Можно создавать группы контроля качества.
Управление качеством продукции
Управление качеством продукции включает в себя контроль за версиями систем, приобретением готовых продуктов, модернизации ПО. Управление процессом разработки включает в себя требования к построению и документированию всего процесса разработки ПП.
По классификации ISO 9001 разработка программ относится к специальным процессам, т.е. дефекты продукции обнаруживаются не сразу.
- обеспечение качества разработки. Модель CMM-SEI.
Обеспечение качеством
ОК – выражается в проверку исполнения сотрудниками принятых компанией стандартов.
Каждая проектная группа должна иметь ответственного за обеспечение качества.
В процессе работы над проектом собираются различные статистические данные (метрики), которые позволяют вовремя обнаружить узкие места проекта и более точно спланировать работу над проектом.
Метрики являются количественной оценкой степени соответствия организационного процесса по созданию ПП, например, на решения задачи затратили 2 месяца, следующая задача несколько проще, поэтому можно затратить 1,5 месяца.
В работе используются метрики продукта, проекта, процесса.
Death march (смертельный марш) – ограничение работы программиста во времени
CMM-CEI (Capability Maturity Model)
Модель оценки зрелости технический процессов в организации. В начале 70 возник кризис программирования (SoftWare Crisis). В результате анализа причин этого кризиса пришли к выводу о необходимости контролировать процесс разработки ПП, прогнозировать и гарантировать стоимость разработки, что привело к необходимости перехода от кустарных к индустриальным способам создания ПП, появились совокупность инженерных методов и средств, объединенных общим названием «программная инженерия» (SoftWare Engineering). В основе программной инженерии лежит одна фундаментальная идея – проектирование ПП является формальным процессом, который можно изучать и совершенствовать.
Для хорошей организации процесса разработки необходимо иметь критерии, позволяющие оценить эффект усилий, вложенных в процесс разработки, т.е. качество и эффективность работы организации.
Понятие зрелости в модели означает эффективность, устойчивость, надежность процессов. В соответствии с этой моделью организация может находиться на одном из 5 уровней зрелости:
Для первого уровня характерен спонтанный, иногда хаотический процесс разработки программ. Процедуры разработки не определены, и успех зависит от индивидуальных усилий работника.
Незрелая организация не может предсказать ни срока завершения разработки, ни качества конечного продукта. Процесс управления если создается, то только в ходе выполнения проекта. Ему не следует особенно во время часто случающихся кризисов и авралов. На втором повторяемом уровне используются основные процессы управления, позволяющие отслеживать как функциональные характеристики, разрабатываемого ПП, так и график работ, а также их стоимость. Организация способна повторить успешную разработку нового проекта с аналогичными возможностями. Организации, находящиеся на третьем (определенном) уровне документируют, стандартизируют и интегрируют в общи<